Re: Time to fork the netboot code?

[OKUJI Yoshinori]

From: Mario Klebsch <address@hidden>
Subject: Re: Time to fork the netboot code?
Date: Thu, 10 May 2001 18:32:40 +0200

> > Why "have to"? There is no reason that drivers must be simple.
> 
> I am sorry, I should have written 'should be simple'.

I agree that it would be better that drivers are simple, but I don't
think they _should_ be, as long as they are not too large or too
complicated for us. IMO, it is much more important if they satisfy
our needs.

> Isn't it the same problem? The developer of our driver does not regard
> our requirements (at least not that much, that we are satisfied).

In Japan, there is an aphorism like "A big thing covers a small one"
(my translation may be inappropriate, though). This means that even if
a thing has extra parts, it satisfies you. For example, even when a
small dish is enough for your meal, you can use a big dish with little
trouble instead.

I think our situation is very similar to this case. Normal OS drivers
have (maybe a lot of) extra code for us, but they have features enough
for us. They are designed to be used simultaneously (opposed to
Etherboot), and they very often work better than Etherboot, because of
the number of the users/developers. Anyway, most of GRUB users use
GRUB to boot Linux and/or *BSD, so if their drivers don't work with
their NICs, it isn't very important that GRUB works with their
NICs. In addition, AFAIK, there is no card that works better with
Etherboot than Linux or *BSD.

Another reason that I'd like to use Linux or *BSD drivers is that they
work on multiple architectures, while Etherboot is just an i386 boot
loader, so their drivers often assume only the i386
architecture. Unfortunately, GRUB is also just an i386 boot loader at
the moment, but I believe that GRUB should support multiple
architectures in the future. To satisfy this demand, it is very
important to find out a way to port GRUB code to other architectures
efficiently, and their drivers are far better from the point of this
view.

Okuji