bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Time to fork the netboot code?


From: Christoph Plattner
Subject: Re: Time to fork the netboot code?
Date: Thu, 10 May 2001 10:07:03 +0200

I have a similar oppinion !

I think, the network driver stuff is not so bad as is. For our booting
(BOOTP, TFTP), the drivers are sufficient in polling mode. The only
thing is to have correct disbaling functions.

The only stuff, which has to be improved is the probing stuff.
Etherboot uses only on card in connection with one image (in the ROM,
etc...). In GRUB we want to compile in a set of drivers (up to all
drivers) and the probing should work correctly. Today probing routines
hang, if cards are not found.

Also some points concerning the environment of the drivers could be 
improved. For example having timers to time out control, or similar
things.

In my oppinion a good idea is to diskcuss together with the
etherboot group to define common aims, then Etherboot and GRUB can
use ther own protocol handling routines, but the driver base should
be usable for boot without changes, so that we can always insert
the current etherboot drivers in a `netboot/drivers' without having
overload with patching here and there.

With friendly regards
        Christoph

PS: Many boot monitors are working polling, and GRUB should become
(or is already) the "best" boot monitor, but no Operating System !!


Mario Klebsch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On Wednesday,  9. May 2001 21:19, Chip Salzenberg wrote:
> > According to Mario Klebsch:
> > > The goal would be to convert the situation from
> > >     the grub people using the drivers of the etherboot people
> > > to
> > >     the grub and etherboot people are using common drivers.
> >
> > If the Etherboot people would be happy with it, that would be an
> > improvement.  But I think it's inevitable that we'd be behind the
> > state of the art until we started using the driver set from an OS
> > that's actually maintained, like Linux or one of the BSDs.
> 
> The idea to have common drivers with a main stream OS looks good, at
> first glance. But I am not convinced, that it really is.
> 
> The reqirements for drivers of real estate OS are much different that
> our requirements.
> 
> Linux drivers have to be able to hande multicasts and lots of other
> stuff (ioctls, ...). Theses drivers have to use interupts and have to
> work on MP systems, they have bottom halves, thes uses the systems
> memory management and often they have to be thread safe.
> 
> OTOH, tghe drivers for booting have to be simple. None of the etherboot
> drivers uses interupts for the NIC, and the use of DMA leads to OS
> crashes, the the DMA channels are not deactivated prior to booting the
> OS.
> 
> Allthough the requirements differ, I am sure, it is possible to have
> both drivers in one source file, when using advanced preprocessor
> tricks. But this would at least require, that both driver flavours are
> maintained by the same set of people. If not, we will face the same
> problem, that we have today, with the etherboot drivers.
> 
> When I see, that even the Linux and the *BSD drivers do not use a
> common source file, I really cannot imagine GRUB and Linux (or *BSD)
> cooperating this was in THIS world. :-(
> 
> So my suggestion would be to define a 'non-OS' network driver API,
> which is usable for all bootstrap projects, agree with these projects
> upon this API and then convert the existing drivers to the new API.
> 
> Of course, to follow the other aproach (a common OS/bootstrap driver),
> we could get in touch with the linux/*BSD network driver people and ask
> then, what they do think about this idea? They know their code much
> better than I do, and perhaps they like this idea. Despite all my
> doubts, why should I not be an optimist? :-)
> 
> 73, Mario
> - --
> Mario Klebsch                                           address@hidden
> PGP-Key available at http://www.klebsch.de/public.key
> Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB  1483 30CE 9FB2 A047 9CE0
>  Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5  8B98 9464 53FF 9382 F518
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> MessageID: QIb5LND0zIFtl8cxwNZL1rc4z/jJsFHw
> 
> iQA/AwUBOvo/+TDOn7KgR5zgEQINzACeJQ4nI/EqO0tGmlw/yRU07bNIFj8AoOXI
> 8Vz+AJUSl767voawmhYRBpt8
> =isP7
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-grub



------------------------------------------------------------------
private:  address@hidden
company:  address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]