lkml.org 
[lkml]   [1998]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 3.0 wishlist Was: Overview of 2.2.x goals?
Date
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_____________________/

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.042 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site