Subject: Re: m_defrag() addition
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 03/02/2005 17:11:19
--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 02, 2005 at 10:41:28PM +0100, Jaromir Dolecek wrote:
> On Wed, Mar 02, 2005 at 01:05:40PM -0800, Bill Studenmund wrote:
> > I can't.
>=20
> Cool.
>=20
> > But that's partly the point. You have a routine which does a=20
> > rather useful manipulation yet you're assuming how it will be used and=
=20
> > thus are limiting its use to only that area. You're also assuming that=
=20
> > there is no other error cleanup that needs to happen between noticing t=
he=20
> > error and freeing the chain.
>=20
> The purpose of subroutine is to encapsulate common behaviour. This
> improves code consistency and maintainability. For these reasons,
> IMO it's good to make m_defrag() do _exactly_ what we need it to
> do at this time.
>=20
> We can always add more complex interface to the functionality later
> if needed, and change m_defrag() to be a macro/inline around it.

Uhm, are we on the same page? All I'm suggesting is you let the caller=20
free the mbuf chain if there's a problem; you don't automagically free the=
=20
chain in the error case.

If I understand the "realloc()-like" interface comments, those folks are=20
saying the same thing. So most all of the comments about this change,=20
AFAICT, have said the same thing. We may have used different words, but=20
the code result is the same.

The reason I feel this is important is that I've been burned by routines=20
that, in the face of an error condition, free something they didn't=20
allocate. Truth be told, _I_ wrote some of these routines that burnt me!=20
i.e. I've had bad luck with overly-helpful routines, both ones I wrote and=
=20
ones I didn't. They are nice and easy at first, but they later get quite=20
irritating. And by then you'd have to change everything to get a different=
=20
behavior.

Take care,

Bill

--lrZ03NoBR/3+SXJZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCJmQ3Wz+3JHUci9cRAqA8AJ46vZKuSdk2gdH0YVbmv92Qo8UNFgCfYczf
/G1BOIcBbEzUc+SOIbwME6s=
=2/qD
-----END PGP SIGNATURE-----

--lrZ03NoBR/3+SXJZ--