Messages in this thread | | | From | Werner Almesberger <> | Subject | Re: 3.0 wishlist Was: Overview of 2.2.x goals? | Date | Wed, 21 Jan 1998 10:03:35 +0100 (MET) |
| |
linux kernel account <linker@nightshade.z.ml.org> wrote: > * Either in-kernel support for enough PNP to boot a system with > a isa pnp boot device, or a viable userspace solution (like an improved > boot loader, initramdisks that must be rebuilt really dont cut it)
Why don't they count ? I guess what's really lacking is a set of tools that turn initrds into little black boxes that "just work". Currently, the main problems I've experienced are the need for libc (particularly on PCMCIA systems) and the silent system failures if /dev isn't right.
For the synchronization issues, some transaction mechanism attached to files or directories might be useful, e.g.
# cp new-driver.o /boot/initrd -> open("/boot/...") wakes up initrd-demon or launches some script for access verification -> file gets written to a temporary place (after all, cp may not complete the transaction and we might be overwriting an old driver) -> close(...) wakes up the demon/script again to "commit" the changes -> demon/script determines return code of close
I don't know much about userfs, but is might be a reasonable base for such a mechanism. (Optionally) being able to leave the data path in the kernel would also allow for other interesting uses (IFS, etc.).
Oh yes, with this, you'd of course also re-run LILO automatically :-)
ketil@ii.uib.no wrote: > Perhaps it would be possible to unify the bootloaders (LILO, MILO, > whatnot)? LILO is kindof simplistic.
You'd be surprised by how little all those boot loaders have in common. LILO is a reasonably generic map installer plus some very x86-specific boot code. I think SILO uses LILO's configuration file parser, but that's about it. The "BIOS" on SPARCs is rather different from PCs. MILO seems to be a bit of a little OS by itself.
Craig Milo Rogers <rogers@ISI.EDU> wrote: > If you have a network available, etc, a simple IP stack isn't hard.
But you still need drivers. Either you use the drivers you find in the crashed kernel, so you have to validate them, which might be hairy if they talk to lots of other kernel parts. Or you have to have an "isolated" version/section of/in each driver, which sounds like a sure way to run into nasty version management problems.
Wouldn't life be so much easier if the BIOS knew about networks ? :-(
Kalle Andersson <kalle.andersson@mbox303.swipnet.se> wrote in "Hot swap kernel": > I am sorry if I am the 57th asking for this but it would be great to be able > to hotswap kernels, ie change kernel without needing to reboot.
Actually, I'd already like to have some function to reboot into a new kernel, without going through the BIOS, even if we don't carry a lot of state from the old to the new kernel (expensive stuff like SCSI probe data might be worth preserving, though).
While we're at it: we could considerably speed up SCSI bus scanning (yes, I reboot my systems quite frequently) by telling the kernel what we already know about the bus, e.g. with a command-line option like scsi_expect=st15230,cdu-76
Then the kernel could start the scan and do a case-insensitive substring search on the model names, removing detected targets from the list. Once all listed targets are found, we can stop the scan. If a target is missing or if an undeclared target appears, the normal scan is done. Extended syntax for multiple hosts: scsi_expect=0,...,1,...
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-ICA,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
| |