grub-devel
[Top][All Lists]
Advanced

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

Re: network support


From: Yoshinori K. Okuji
Subject: Re: network support
Date: Sat, 12 Mar 2005 00:49:13 +0100
User-agent: KMail/1.7.1

On Friday 11 March 2005 11:33 am, Vincent Guffens wrote:
> 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 ?

Each driver should be one module. You can preload as many modules as you want 
with grub-mkimage. But I think you should not load all modules, because this 
might overflow the loaded memory region.

Normally, it is safe to probe PCI devices, thanks to PCI IDs. So it should be 
enough to iterate all probing routines of device drivers, to detect a device.

> 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 ?

It should not be a command, but a network device should be associated with a 
GRUB device (say, nd0). The interface should be consistent between disk 
devices and network devices for the user.

I don't think ramfs is useful. When you open a file, whether it is on a disk 
or a network, you read data to a buffer, don't you?

> 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 ?

Do not hesitate to break the code. Any piece of source code has bugs, anyway.

Network support is divided into two parts: a network device framework and 
device drivers. The framework is more important at the moment, because it is 
not implemented. The current code has a template written by me, but we must 
design it seriously.

The fundamental difference between disk devices and network devices is that 
disks consist of blocks and have unique filesystems, while network devices 
consist of paths and can support multiple filesystems at a time. So, unlike 
disks, the user must specify what protocol should be used to network devices, 
and the cache system must be differently implemented.

The template code supposes that the user "bind"s a filesystem to a network 
device. I don't know if this is really good, but probably it is acceptable. 
The default filesystem should be tftp, because this is the most common for 
netbooting.

The cache system would be designed to use the set of a network device 
identifier, a filesystem idenfier, a path and a starting offset as a key.

Okuji




reply via email to

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