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, 25 Mar 2005 13:07:06 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)

Hi Vincent,

>> pci_register_driver or is it very specific to NICs?
>
> yes, all the etherboot drivers should just be fine after a small
> modification.

What does this have to do with etherboot drivers?

I was not too clear with what I meant, sorry.  GRUB 2 is very
portable.  For example there is a powerpc port already, but it will be
ported to other architectures.

It would be very nice if the PCI driver would work alike on every
architecture.  So you will have a pci bus driver like you have.  The
lspci tool is separate so it works on every arch without modification.

On some architectures we need to write our own video drivers and
perhaps even IDE drivers.  Those drivers also rely on PCI.  That's why
I asked about the support for other kinds of drivers from the PCI
interface.

Linux has a file to lookup which module should be used for which PCI
device.

(from /lib/modules/2.6.10-4-amd64-generic/modules.pcimap: )

# pci module         vendor     device     subvendor  subdevice  class      
class_mask driver_data
snd-ymfpci           0x00001073 0x00000004 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-ymfpci           0x00001073 0x0000000d 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-ymfpci           0x00001073 0x0000000a 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-ymfpci           0x00001073 0x0000000c 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-ymfpci           0x00001073 0x00000010 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-ymfpci           0x00001073 0x00000012 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-vx222            0x000010b5 0x00009050 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-vx222            0x000010b5 0x00009030 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
snd-trident          0x00001023 0x00002000 0xffffffff 0xffffffff 0x00000000 
0x00000000 0x0
...

We could do the same, I think.  In this case to map the PCIID, etc to
GRUB module names.  pcimodprobe could probe for modules when it is
started, load them and of course the module itself has to do the
(cheap) check again to be sure.


>>
>>>     * module : pcimodprobe
>>>           o provide grub command : ifconfig
>>>           o description : initialises the nic, probes for the config
>>>           o files :
>> Config files?
>
> Probing for the config here means looking for a dhcp server, obtaining
> an IP address, the gateway and the next-server. It does not yet look
> for the dhcp option-150 for the menu.

Okuji, I have seen a discussion about this option 150 on bug-grub.
How should this work for GRUB 2?

> Now, at that point, the idea is that when you type a filename looking like
>
> (nd0,tftp)/dir/file or (nd0)/dir/file
>
> grub2 uses its IP address to contact the next-server with tftp to
> download the file /dir/file
>
> For that purpose, I register a netfs file system. When the open method
> of the fs is called, the file is downladed and all the tftp blocks are
> stored in a linked list. The read method simply goes throught these
> blocks and reads a given lenght of data.
>
> The tftp option in (nd0,tftp) is there for the future if we want to
> add some more download protocols like http or nfs as they do in
> etherboot.

Can't you just the tftp server for the block grub_file_read wants?
This would save some memory I think.

Thanks,
Marco





reply via email to

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