From owner-freebsd-current Wed May 1 12:54:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13950 for current-outgoing; Wed, 1 May 1996 12:54:12 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13945 for ; Wed, 1 May 1996 12:53:58 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA10116; Wed, 1 May 1996 12:46:09 -0700 From: Terry Lambert Message-Id: <199605011946.MAA10116@phaeton.artisoft.com> Subject: Re: execve To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 1 May 1996 12:46:09 -0700 (MST) Cc: freebsd-current@FreeBSD.org, chuckr@Glue.umd.edu In-Reply-To: <199605010824.KAA09470@uriah.heep.sax.de> from "J Wunsch" at May 1, 96 10:24:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > 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.