[Top][All Lists]

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

Re: Time to fork the netboot code?

From: Mario Klebsch
Subject: Re: Time to fork the netboot code?
Date: Wed, 9 May 2001 19:05:28 +0200


On Wednesday,  9. May 2001 08:53, Chip Salzenberg wrote:
> According to OKUJI Yoshinori:
> > > > So transition to a more powerful set of device drivers
> > > > would be necessary.
> > >
> > > Hm.  Has anyone started on this?
> >
> > No, AFAIK. However, you cannot do this alone. It is necessary to
> > implement real memory management and handle protected-mode
> > interrupts and real-mode ones concurrently, using v86-mode. That is
> > exactly the plan which should be done after 1.0 release.
> OK, good to know.  I do have some short-term goals which can only be
> met by further hacking on the Etherboot drivers.

Just out of interest:

How much do the netboot (etherboot?) developers know about grub? Did
they ever use their drivers with grub?

If I understood the code right, the etherboot people are calling the
functions in config.c, which is then calling the various drivers.

I think, it should be possible to change the interface between config.c
and the network drivers to better fit grub's needs. Grub could use the
drivers either through config.c (in this case probably nothing is won)
or using the new interface. etherboot could either continue to use the
config.c interface or merge this code with the rest of their project
and switch to the new interface, too.

The goal would be to convert the situation from

        the grub people using the drivers of the etherboot people


        the grub and etherboot people are using common drivers.

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

Version: PGPfreeware 5.0i for non-commercial use
MessageID: lmiHhpwTLGOGJ6fz5SnKnpx/CmLp7VCu


reply via email to

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