[Top][All Lists]
[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
- network support, Vincent Guffens, 2005/03/11
- Re: network support, Tobias Wollgam, 2005/03/11
- Re: network support, Marco Gerards, 2005/03/11
- Re: network support, Vincent Guffens, 2005/03/11
- Re: network support, Marco Gerards, 2005/03/12
- Re: network support, Vincent Guffens, 2005/03/17
- Re: network support, Marco Gerards, 2005/03/24
- Re: network support, Vincent Guffens, 2005/03/25
- Re: network support, Marco Gerards, 2005/03/25
- Re: network support, Yoshinori K. Okuji, 2005/03/25
Re: network support,
Yoshinori K. Okuji <=