Date: Sat, 20 Mar 1999 14:33:30 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: sos@freebsd.dk (Søren Schmidt) Cc: gibbs@plutotech.com, mike@smith.net.au, rnordier@nordier.com, current@FreeBSD.ORG Subject: Re: How to add a new bootdevice to the new boot code ??? Message-ID: <199903201233.OAA22794@ceia.nordier.com> In-Reply-To: <199903200959.KAA35061@freebsd.dk> from =?ISO-8859-1?Q?S=F8ren_Schmidt?= at "Mar 20, 99 10:59:51 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt wrote:
> It seems Justin T. Gibbs wrote:
> > >> Why not have the boot blocks pass in a device 'name' rather than a
> > >> major number. If the goal is to ditch major numbers entirely with
> > >> a properly working DEVFS, then using major numbers in the new boot
> > >> loader seems to be the wrong way to go. Until DEVFS is a reality,
> > >> the kernel will still need to perform a name to major number translation,
> > >> but it should be left up to the kernel.
> > >
> > >Because there's no way to work out a name either.
> >
> > If I explicitly say:
> >
> > 1:foobar(0,a)/kernel
> >
> > there certainly is a way to work out the name. Perhaps in the autoboot
> > case you'll have to guess, but it would be nice if the current boot
> > mechanism allowed user intervention as a way to boot a kernel with an
> > unknown bdev.
>
> YES!! can we please have that ??
Until DEVFS is a reality, I think it makes sense to not break
compatibility with the existing boot interface.
What Justin suggests seems good, but why not postpone the big change
till the user has compelling reasons (like a working DEVFS) for
making it, and losing ability to (a) boot 2.x and 3.x kernels; (b)
use his existing bootblocks; and (c) use his existing netboot and
other external (fbsdboot.exe-like) programs?
For the short term, I'd suggest modifying the bootblocks to optionally
accept an arbitrary major# in place of a {"wd", "da", "ad", "fd", ...}
string
1:42(0,a)/kernel
since that can easily be accommodated by the existing arguments
passed to the kernel.
While not an optimal solution, this does have the virtue of adding
the ability to boot from any device not specifically provided for,
and without requiring customization of the bootblocks (or any more
work on the kernel than is presently required to add a device
driver).
--
Robert Nordier
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903201233.OAA22794>