Date: Wed, 27 Nov 2002 12:13:18 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <3DE5275E.9D3E9F9B@mindspring.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.NEB.3.96L.1021127095837.43889C-100000@fledge.watson.org> <15844.60298.44810.750373@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote: > What I (as a 3rd party driver author working in a GNUish > autoconf/gnumake environment) do is to require a user building from > source to specify the location of a configured kernel tree where make > depend has been run (defaulting to GENERIC). I then pickup the > various option and bus files out of that directory. When I build binary > modules, I build from source as a normal user (using a 4.1.1 system in > a chroot). Using an approach like this, a vendor could ship a MAC > aware driver by picking up the options files from a MAC kernel build > directory. I believe he was talking about modules for which source code is not available. > How is one supposed to build a 3rd party module these days? One is not. The vendor supplies only a binary. > > I think you under-estimate the complexity of variably sized key kernel > > data structures. mbuf.h is included all over the kernel, as well as in > > many user applications (although often for bogus reasons). My proposed > > strategy is the following: > > Bizzare. I had no idea userland apps used mbuf.h. That does indeed > sound bogus. On the contrary: it's a very clever thing to do. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE5275E.9D3E9F9B>