Date: Fri, 19 Feb 1999 12:48:46 +0100 (MET) From: Emmanuel DELOGET <pixel@DotCom.FR> To: tlambert@primenet.com (Terry Lambert) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Subject: Re: TEXT_SET() macro Message-ID: <199902191148.LAA26849@excalibur.oceanis.net> In-Reply-To: <199902130015.RAA28440@usr01.primenet.com> from Terry Lambert at "Feb 13, 1999 0:15:36 am"
next in thread | previous in thread | raw e-mail | index | archive | help
As the well known and respected Terry Lambert said...
->> ->> I wanna know how it's working both at compile time and at run time
->> ->> (for example, does a lkm (yes lkm, not kld, since I'm working on a
->> ->> 2.2.8 release...) can declare linker_sets, or add entries in a kernel
->> ->> linker_set, [for example , the sysctl_ one - seems that I'm very
->> ->> interested in sysctls :)]. Thaks a lot.
->
-> The answer is that it can declare linker sets for its own use, but
-> can not add entries to a kernel linker set, as in:
->
->> -> You can declare sysctls in modules, but the sysctl code will not pick
->> -> them up so it's pretty useless. There is work pending to make that
->> -> possible.
->> ->
->> This seems that the sysctl_order function is called only on
->> the system init (due to SYSINIT), but it may be possible
->> to find a workaroud (I'm working on this for 2.2.8,
->> on the base of the D. Rabson patch for -current).
->
-> The reason that this doesn't work is that linker sets are an artifact
-> of the linker.
But I still think that it is possible to find a workaround. In fact,
the kernel relies on the linker_set facilities to do the sysctl init.
Since lkm/kld linker_sets and kernel ones are not 'plug and play', the best
solution, I think, is to use another alternative - which is, in fact,
build a real tree in the kernel memory (maybe it's not a good idea,
I don't know). Doug Rabson done this on -current, and I do this on 2.2.8
(yes, I still use 2.2.8, for some reason I've allready explained -even
if these reasons are not valid, in fact, the main on is : my chief told
me to not use a 3.x based kernel :)...). The linker sets facilities are
still used in this new version, but they are used only for the registration
process. I suggest you look at the code of DR for a better understanding
of what I think (but I'm sure you have allready done this, isn't it ?).
->
-> [lots of very interesting info deleted - the best infos I've ever
-> read about linker_sets, in fact. Thx a lot]
->
-> In general, linker sets are a structure with an element count,
-> followed by an array of pointers of element count length, followed
-> be a NULL pointer.
->
-> In application, the element count is not used, and instead the
-> lists are traversed until the NULL pointer is encountered.
->
Well, this last assertion seems to not be really true (at least in
the 2.2.8 kernel, as I've not read the -current sources). A lot
of stuff in the kernel are still using the ls_count field, and seems
to not rely on the NULL entry at the end of ls_items.
-> [lots of very interesting info deleted (again)]
->
-> In order to make this work for KLD's, the linker set agregation would
-> need to occur at runtime. There are very good reasons for doing this,
-> the foremost being that an ELF section archiver could aggregate drivers
-> with a generic (tiny) kernel in order to support boot devices not
-> supported by the generic (tiny) kernel. It is very easy to envision a
-> distribution kernel without any drivers or even VFS modules by default.
->
-> Making KLD's linker sets work is another good reason.
->
That would be good, yes. The idea of a driver-less kernel is very very
good, since FreeBSD is a stable OS that can be used in embbeded systems
(like the one we're doing now).
->
-> There are two technology changes which have to occur to be able to
-> support runtime instead of linktime aggregation:
->
-> 1) The element count *must* be deprecated entirely, for all
-> cases. This may be a mildly complex change to the C++
-> compiler, if the element count is used instead of a list
-> traversal. This may be the case, if NULL is a valid tag
-> for a constructor/destructor place holder. A secondary
I'm not a master in C++ core design, but I think that NULL cannot
be a valid entry for C/Ds, since whenever you do not specify any
C or/and D, the C++ compiler creates one (if he can't, he generates
an error). I may be wrong, of course, son anyone that have more
informatiosn on this subject is welcome.
-> issue is all code relying on linker set technology. Making
-> these changes would fully normalize the lists.
-> 2) Agregation of linker sets needs to span ELF sections.
wouch ! I'm not mastering the ELF stuff, in fact. But it seems that
I don't have to, cos you are here :)
->
-> This last item is the most important, since the first item is like
-> removing an appendix.
Yes, but, as I said before, it's a very big appendix... Removing
all the occurence of ls_count in the code should be very long. Perhaps
I'll try to do this later on -current, but I have no time for this
on those days, so we'll have a FreeBSD 16.4.32 for year 2012 - a new
era, where Microsoft, hurted by the opensource stuff, begin to
give Windows 2012 with its source code under GPL licencing...
rahhh... I'll still use things that work ;)
->
-> The kernel code would have to treat the linker sets as a list of
-> data on which a procedure needs to be run, *and which can be later
-> rerun*, as needed.
->
-> This means the linker set data itself can not be treated as static.
->
-> Finally, the body of the kernel and the body of divisible drivers
-> within the kernel must be treated seperately. The way to do this
-> is to leverage the new ELF nature of the kernel, and implement the
-> kernel and the divisible drivers in seperate ELF sections. This
-> allows the driver to be later severed, if necessary, without
-> damaging what would otherwise be a static aggregate list.
->
-> I know that GCC supports ELF section attribution of code via a
-> #pragma, per the Visual C++ compiler, in its effort to supply a
-> compiler capable of compiling Windows 95/98/NT/CE code, though I
-> don't know if this has been echo'ed into compilers for all
-> platforms (e.g.: Linux and FreeBSD).
->
-> You would probably have to implement an inline function identification
-> semantic, or something similar, in order to apply section naming to
-> entire drivers.
->
-> FreeBSD would also have to relink objects that implemented a single
-> driver from multiple source files, into a single section-attributed
-> module.
->
-> At that point, you would be able to, at load time, treat the sysctl
-> linker set data atrributed sections as a continuation of the
-> initialization iteration that occurred at system load.
Well... Analyzing what you said may turn into : you have to work for
three years to finally add new sysctls in a lkm/kld... I think I prefer
the DR solution (despite it may looks like a hack) :)
-> Terry Lambert
-> terry@lambert.org
--
____________________________________________________________________
Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA
--------------------------------------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902191148.LAA26849>