From owner-freebsd-current Fri Jan 11 0:25:35 2002 Delivered-To: freebsd-current@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id D01EC37B41A; Fri, 11 Jan 2002 00:25:32 -0800 (PST) Received: from pool0127.cvx40-bradley.dialup.earthlink.net ([216.244.42.127] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Ox0F-0003kY-00; Fri, 11 Jan 2002 00:25:32 -0800 Message-ID: <3C3EA179.D143C116@mindspring.com> Date: Fri, 11 Jan 2002 00:25:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: current@freebsd.org Subject: Re: HEADS UP: module build process changed References: <20020110203908.A58789@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > In the book "Writing Linux DEvice Drivers", there is a neat bit > > on how Linux does this. Effectively, they export all symbols > > within the module load if there is no explicit symbol table > > export call, and they export only the symbols that are requested, > > if there is. > > I considered this approach, but couldn't work out a tidy way of making > it work for the case where the module is statically compiled into the > kernel. You need to look at their "module.h" in the 2.1.x kernel. They seem to use an alternate ELF section for most everything, and then leave only the main symbols for the init/deinit, which includes the symbol registration function, in the normal ELF section where you'd expect it. It's really tempting, since it avaids the problem with statically linked modules with colliding symbol names. > Effectively, you'd have to parse the linker set out of the .kld file, > then feed it to objcopy to localise the symbols before linking. I think this could be done, with a correctly arranged linker set, but it'd be pretty annoying. 8-). > There's no reason that, presuming a mechanism like this was devised, > we couldn't dispense with the EXPORT_SYMS declaration and generate the > list automatically, of course. Yup. > I'd be happier with something like __attribute__((__export__)) on the > declaration, of course. I'm also not fond of the "default to export > all symbols" approach, but that's just a detail. I think you could do this with a section other than "code" or "data"; best to try to copy Linux, I think. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message