All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <metgerards@student.han.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: network support
Date: Fri, 25 Mar 2005 13:07:06 +0100	[thread overview]
Message-ID: <877jjwszdh.fsf@student.han.nl> (raw)
In-Reply-To: <4243D51F.6090604@auto.ucl.ac.be> (Vincent Guffens's message of "Fri, 25 Mar 2005 10:08:47 +0100")

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	other threads:[~2005-03-25 12:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-11 10:33 network support Vincent Guffens
2005-03-11 12:22 ` Tobias Wollgam
2005-03-11 18:46 ` Marco Gerards
2005-03-11 20:09   ` Vincent Guffens
2005-03-12 13:40     ` Marco Gerards
2005-03-17 13:53       ` Vincent Guffens
2005-03-24 21:55         ` Marco Gerards
2005-03-25  9:08           ` Vincent Guffens
2005-03-25 12:07             ` Marco Gerards [this message]
2005-03-26  0:31               ` Yoshinori K. Okuji
2005-03-11 23:49 ` Yoshinori K. Okuji
2005-05-23 15:37 ` Tobias Wollgam
     [not found] <4293032C.3090404@inma.ucl.ac.be>
2005-05-25  9:31 ` Tobias Wollgam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877jjwszdh.fsf@student.han.nl \
    --to=metgerards@student.han.nl \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.