From owner-freebsd-hackers Fri Oct 13 11:13:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA07839 for hackers-outgoing; Fri, 13 Oct 1995 11:13:45 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA07834 for ; Fri, 13 Oct 1995 11:13:42 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17852; Fri, 13 Oct 1995 11:06:48 -0700 From: Terry Lambert Message-Id: <199510131806.LAA17852@phaeton.artisoft.com> Subject: Re: IPX now available To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 13 Oct 1995 11:06:48 -0700 (MST) Cc: terry@lambert.org, julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG In-Reply-To: <8378.813553555@time.cdrom.com> from "Jordan K. Hubbard" at Oct 12, 95 08:05:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2372 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > The gist of this is that he wants to work on putting simple linker code > > into the kernel, and I very much agree with him. > > Assuming that you and the anti-bloatists can work this out, this and > everything following it certainly sounds reasonable to me. > > dev_add_char (just dev_add?) > dev_remove_char (just dev_remove?) > > I prefer the latter, more generic, versions. If you're going to have > a nice standard API for talking to LKMs, you may as well try to make > as few assumptions about the kinds of data you'll be handing back > and forth as possible. Note: this is dependent on collapsing the character and block devices to a single registration with a potential of two name space exports in the devfs. This isn't really a *big* problem, but it *is* notable. What it means is that the device alias must handle 'n' vnodes, so it abstracts the device by one layer from what Julian has said that he's done. > Uh, speaking of which.. How do LKMs and the kernel expect to talk > back and forth in general? Is it like a roman orgy in there, where > LKMs and kernel share one, common global variable space and anybody > can fondle any variable they see, or.. ? I guess I need to go UTSL, > don't I? :-) Right now, it is a Roman orgy, which is order bound. The LKM's sysmbols are added to the kernel symbol space for subsequent loads. The LKM's themselves are free to access anything that they can see. With a light linker, this orgy is reduced, since one could specify that not all kernel symbols may be twiddled, nor may all symbols in an LKM be exported (ie: defined interfaces). > Anyway, it certainly seems like you have a direction in mind. How > would you see such a project being staffed and actually "managed" on a > day to day basis? Clearly, there's a lot of work represented here > and it'd take some coordination to actually pull it off. I don't see it as a big, hairy problem. The pieces would add incremental functionality in any case. One big issue would be to formalize the kernel file I/O interface, which is currently scattered all over the place and promiscuously used by things like the POSIX domain socket code, etc.. This is a code cleanup issue more than anything else. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.