Re: [RFC] netboot changes

[OKUJI Yoshinori]

From: "Eugene A. Doudine" <address@hidden>
Subject: Re: [RFC] netboot changes
Date: Mon, 15 Jan 2001 00:41:13 +0700 (KRAT)

>  added new field to pci_device struct - pointer to correct probe 
>  routine:
> struct pci_device {
>         unsigned short  vendor, dev_id;
>         const char      *name;
>         unsigned int    membase;
>         unsigned short  ioaddr;
>         unsigned short  devfn;
>         struct nic      *(*eth_probe)(struct nic *, unsigned short *,
>                                       struct pci_device *);
> }; 
> and added code to call the correct probe function before trying
> all the drivers.

Your patch is good. Please write ChangeLog entries, and I'll apply
your patch.

> I was in doubt whom I shoud bug with it: Okuji or 
> Etherboot maintainers.

Perhaps me. I suspect that Ken Yap may not want to integrate your
patch with Etherboot, because it will not improve Etherboot and it
will just enlarge the binary size. Of course, this is what he should
decide rather than I, so it would be still a good idea to inform him
of the patch.

> By the way I looked into recent Etherboot distribution 
> and found that version in grub is quite dated 5 or 8 month old, 
> Etherboot has some new drivers, pci_device struct is also changed. 
> However this problem with non-optimal probing sequence of pci devices 
> still exists in Etherboot too.

That's right. The reason why we haven't updated it is mainly that
there is no urgent wish to do so, but another reason is the new
fine-grained timer interface defined in src/timer.[ch]. Because it
can interfere with BIOS, it isn't easy to implement it in GRUB safely
(But I doubt that it affects when booting DOS, if the user uses a
driver which calls it, even in Etherboot).

If you want to implement it in GRUB, you will have to follow one of
these:

1. Initialize the timer chip so that it will raise timer interrupts to
   call the real mode timer interrupt handler regularly, and make sure
   that the configuration of the timer chip will be restored once it
   is required (e.g. when booting an OS). As this includes that you
   implement protected mode interrupt handling, this is the most
   complicated approach.

2. Use the re-configured timer only for a short period, that is,
   initialize it, use it, and restore it, as soon as possible, so it
   won't interfere with BIOS timer handling significantly. This
   restricts its usage in drivers, but this should be enough for now,
   because only eepro.c uses it for sleeping for 40us.

3. Poll the timer and call the real mode timer handler whenever
   appropriate. This is the worst approach, because this adds a large
   overhead and makes the code too complicated.

4. Emulate it with the default configuration of the timer. This makes
   drivers which use it much slower, so this is not desirable but
   safe.

5. Don't implement it and give up installing drivers which use
   it. This is feasible, if nobody (or too few people) has an eepro
   card. Possibly this is a wrong assumption.


Anyway, I don't think it would be worth to update the network drivers
(unless you have a card GRUB doesn't support), because I'm planning
not to use Etherboot drivers. I'll explain my "near future plans"
soon.

Okuji