grub-devel
[Top][All Lists]
Advanced

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

Re: network support


From: Marco Gerards
Subject: Re: network support
Date: Fri, 11 Mar 2005 19:46:43 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)

Vincent Guffens <address@hidden> writes:

Hi Vincent,

> I started to integrate network support into grub2 using the code from
> etherboot 5.3.14.

Oh, neat. :)

> Although it is still very basic, I sent it now as I saw the post
> "question" about network support, so it might be time to discuss about
> it.
>
> What I've done so far is simply to add a "lspci" command as a grub
> module, which seems to work on my pc. Because it uses the pci code
> from etherboot, it should be a good starting point to start porting
> all their drivers.

Cool.  My idea of PCI support in GRUB 2 is that we need to be able to
support every kind of bus using modules.  For example PCI could have
an interface so drivers/commands could query it for PCIIDs, vendor
ids and other information about the hardware, etc.

In that case every PCI driver (also on other architectures) export the
same interface.  The lspci utility could use that interface to get the
PCIIDs and look them up in a database (when available) so it can print
nice readable output.

> I was thinking that it could be a good idea to be able to use their
> drivers with no modification at all so that future management would be
> easier. New driver in grub would also mean new drivers in etherboot
> and the other way around.

How hard would that be and what disadvantages would that approach
have?

> In grub legacy, there was this problem when compiling a lot of drivers
> in. How do we avoid it here ? I was thinking that it could be possible
> to use the lspci to find out the device id and initialize only the
> right driver, but maybe it is not practical ? Is it done anywhere else
> like that or do they probe the card by trying the iniliazation routine
> of the driver ?

The problem with GRUB Legacy has is that extra drivers would mean that
GRUB gets bigger.  All drivers would, AFAIK, mean GRUB is too big.

For GRUB 2 every driver should become a module.  Perhaps we could make
a list of drivers and PCIIDs and lookup which driver to load using
that list.  Perhaps that can be a module called pcimodprobe.mod or so.

> Also, if we add a tftp command, what should we do with the downloaded
> file. Maybe it would be convenient to have some kind of ramfs to be
> able to copy the files there ?

Why?  The loader could load the file into memory, no?

> What should I do now ? It is not practical to send a patch as they are
> many news files coming directly from etherboot. Would it be an idea to
> have a new netboot branch in the cvs so that it would be possible to
> experiment with it without breaking anything else ?

Perhaps it would be better to wait until you have things working?  I
could test rtl8029, rtl8139 and some other cards I forgot about.

Okuji, what do you think of my ideas?  Are they a bit too crazy?

For me portability and flexibility is important, so other kinds of
drivers can be implemented on any architecture.

Thanks,
Marco





reply via email to

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