Date: Sat, 13 Jun 1998 17:21:03 -0700 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: jkh@time.cdrom.com (Jordan K. Hubbard), itojun@itojun.org, hackers@FreeBSD.ORG, tech-jp@jp.freebsd.org Subject: Modular kernel (was Re: new config ) Message-ID: <199806140021.RAA02222@antipodes.cdrom.com> In-Reply-To: Your message of "Tue, 09 Jun 1998 20:49:52 -0000." <199806092049.NAA09520@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) Commit the ELF/a.out bootblock changes, the location of which > was posted to the -current list some time ago. No. Let me/help me finish the new bootloader, which doesn't have these silly size restrictions. > Yes, I know this leaves only 28 bytes and you have to disable > the spashkit and the bad144 to build blocks that can boot both > a.out and ELF kernels. I don't care. The bootblock issue is > a boondoggle. It will go away when the a.out code is removed. Bollocks. Apart from the fact that the splash code was never committed, the bootblock size problems will never "go away". > 2) Switch -current to ELF by default. > > You shouldn't be running -current unless you are either > participating in or testing active developement work. ELF > is active developement work. Switching -current to ELF > *now* is within the charter for -current, as well as being > a good idea: shake out the ELF problems *now*, not just > prior to 3.0R, or you will regret it (the shakeout *must* > occur; whether this happens before or after 3.0 is released > is up to the people with commit priviledges). I'd want to give the integration folks a little longer on this, just because the volume of noise following the cutover will be *huge*, and the degree of *huge*ness depends on how well they've covered the bases. We also want current.freebsd.org back online before then, simply because for many people an upgrade install to an ELF world will be the easiest way to go when they screw themselves during the build upgrade. > 3) Load only specifically attributed ELF sections. > > Section attribution via #pragma, ala MS Visual C++, was added > by Cygnus support a while back, in their support of compilation > of WIN32 programs using gcc. Please write up some documentation on this (not in a mail message), including how to attribute a module to a section, and a list of sections that you'd recommend for the kernel. Also, how to differentiate between them when you're loading them, etc. > 4) Transition linker sets to inter-section loader agregates > instead of true linker agregation. > > This will allow "sysinit" set elements to live in seperate > ELF sections, yet function as if they were statically linked. > > I will be happy to help with this, but it's not brain surgery, > and it's an obvious win for supporting pure virtual bas classes > and Templates in ELF C++. You might even convince the Linux > people to do the work for you... Whether it's brainsurgery or not isn't so much relevant as that you have the information to hand and a belief that it should be realised. > 6) Make room in the bootblocks. > > The simplest method would be to delete the a.out code. If > someone doesn't want this to happen, then that "someone" > should implement a three stage boot loader to resolve the > problem, or the "someone" can lump it over the fact that > their a,out kernels will no longer load. I'm working on this. Usenix and exams have prevented me from committing a significantly modified adaption of the NetBSD 'libsa' (which I will be calling 'libstand'), which provides a fairly comfortable runtime environment for standalone applications. The x86-specific components are not really clean enough, and I am not yet sure whether they ought to be in a separate library yet. The 'boot' application is at the point where it loads and runs, and loads a.out kernels (thanks to Doug Rabson for this). It doesn't support running other standalone apps, nor ELF kernels at all, but I consider these secondary. When I get back from Usenix, I expect to be able to devote considerable time to getting this finished, and I'll make more noise at that point in time. > 7) Add code to the bootblocks to load the elf sections from > multiple files. > > Instead of just the kernel file itself, a "/modules/active" > directory containing discrete ELF modules (or call it whatever > the hell is the most politically correct thing to call it, I > don't care) is scanned, and all ELF images sections that meet > the criteria in (3), above, are loaded. Now adding a commercial > driver is as simple as copying an ELF module into a directory. Hmm, would you advocate the 'push' approach here over a 'pull' approach, ie. PCI/PnP/whatever id translates to module lookup, module lookup provides dependancies, dependancies list modules, modules are loaded, etc.? This avoids having modules loaded when they are/might not be needed. > 14) Document and firm up the interfaces used by drivers. > > Ideally, this will conform to the SCO/Novell/Sun driver > framework so that FreeBSD can use driver disks supplied > by hardware vendors. How do you feel about UDI (SCO/HP/Digital/etc.)? > 15) Implement a VxD environment emulation. > > This will allow use of NT miniport drivers. If done right, > you will be able to use drivers for PPC and Alpha hardware, > as well. Eyecch. Last time I looked these made large numbers of assumptions about the internal structure and behaviour of the kernel. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199806140021.RAA02222>