Date: Wed, 1 May 1996 12:46:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.org, chuckr@Glue.umd.edu Subject: Re: execve Message-ID: <199605011946.MAA10116@phaeton.artisoft.com> In-Reply-To: <199605010824.KAA09470@uriah.heep.sax.de> from "J Wunsch" at May 1, 96 10:24:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I can't figure out where the execsw array gets built. Could someone > > point me at the right file? > > A quick grep points to the TEXT_SET() macros. Looks like black magic > however. :) It's pretty simple. You have object files with a declared data object in them. All objects of the same name and "class" are gathered together into a single structure + pointer array, like so: int number_of_objects; void *object_array[]; The "number_of_objects" isn't (or shouldn't be) used -- the list "object_array" is NULL terminated. In practice, there is only one place in the kernel that cares about the "number_of_objects" field in the structure. This construct is called a "linker set". It comes out of C++ constructor/desctructor support in the linker. I believe that, because virtual base classes require initialization before use, that any object containing a linker set element is dragged in, even if no other references to object symbols exist. This means that the "KERN_INIT" stuff, which also uses linker sets, could allow you to option features in and out of the kernel *without* #ifdef's: just include or don't include the object file when you link. For loadable modules, if the initialization code is the same for a static vs. a loaded module, then the module loader can have knowledge of the KERN_INIT linker set for registration of the registration and deregistration and status routines. For execution classes, this means that you could distribute an object-only link kit and statically or dynamically option things in and out of the kernel. The execsw[] code references you quoted were for statically linked execution classes. In a more general sense, this is support for kernel modularization to allow for binary-only driver and component distributions (for instance, the Intel math coprocessor emulation library, Matrox Meteor or Diamond video drivers, a third-party port of the NetWare for UNIX server platform and Novell supplied IPX and SPX protocol stacks, etc., etc.). It's initially confusiong, but *extremely* flexible. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605011946.MAA10116>