From owner-freebsd-hackers Tue Mar 10 19:23:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05071 for freebsd-hackers-outgoing; Tue, 10 Mar 1998 19:23:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05024 for ; Tue, 10 Mar 1998 19:22:50 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id UAA04530; Tue, 10 Mar 1998 20:22:45 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd004481; Tue Mar 10 20:22:43 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id UAA09090; Tue, 10 Mar 1998 20:22:30 -0700 (MST) From: Terry Lambert Message-Id: <199803110322.UAA09090@usr04.primenet.com> Subject: Re: userconfig data -> linker set -> ELF segment To: eivind@yes.no (Eivind Eklund) Date: Wed, 11 Mar 1998 03:22:29 +0000 (GMT) Cc: hackers@FreeBSD.ORG, mike@smith.org.au In-Reply-To: <19980311031310.30458@follo.net> from "Eivind Eklund" at Mar 11, 98 03:13:10 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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