Date: Fri, 13 Oct 1995 11:06:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG Subject: Re: IPX now available Message-ID: <199510131806.LAA17852@phaeton.artisoft.com> In-Reply-To: <8378.813553555@time.cdrom.com> from "Jordan K. Hubbard" at Oct 12, 95 08:05:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510131806.LAA17852>