Date: Wed, 11 Mar 1998 03:22:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: hackers@FreeBSD.ORG, mike@smith.org.au Subject: Re: userconfig data -> linker set -> ELF segment Message-ID: <199803110322.UAA09090@usr04.primenet.com> In-Reply-To: <19980311031310.30458@follo.net> from "Eivind Eklund" at Mar 11, 98 03:13:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I was basically planning to look at distributing the userconfig device > list as a linker set, to allow externally developed drivers to be > added without having to edit a static list. I know how to do this > now, but how easy is it to put it in a non-loaded segment later? This is hard. The problem is that you need to be able to agregate linker sets at run time, not at link time. This means that they can be in physically different ELF sections, but appear to be logically one set of data. Effectively, this means that the thing that loads the ELF sections into memory needs to build the linker set from pieces as it's loaded into memory, instead of the linker doing the agregation into a single set object. Part of this can be scoped out by noting that the count of items in a linker set is irrelevent, since the linker set always contains non-NULL pointers in a list terminated by a non-NULL pointer. At best, you can count the items when you agregate them, and fill in that number at runtime. At worst, you can linearly traverse from the first item to the NULL, and count the number of items in the linker set. This is a linker/loader technology problem. This is kind of complicated because you want a handle-based reference to the agregate set. This lets you reallocate it or extend it on the fly, without depending on the intervention of the linker/loader (consider the case of a loaded driver that supports the powerdown facilities, or a the vnode operations descriptor list being dynamically extended or shrunk at runtime as modules are loaded or unloaded). This is a problem that needs to be solved generally, regardless of difficulty (it's not *that* difficult a problem). This is useful for code dynamism for C++ (for example, pure virtual base classes implementing interfaces to objects not in your address space, which may be transient relative to your address space), so it should be acceptable to the gcc powers-that-be (linker sets were an outgrowth of C++ virtual base class construction/descruction for C++ shared libraries). It's also useful for C++ template classes, which may instance a derived class of a particular type in multiple dynamically linked units. For example, a template class instance of "int", for which a static member exists -- like a pthread_mutex_t. You would only want one mutex for all instances of the class, regardless of where there were instanced. Anyway, it's a linker/loader problem, so it has to be solved: o in ld o in ld.so o in the boot blocks o in kld Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199803110322.UAA09090>