106 lines
5.9 KiB
Text
106 lines
5.9 KiB
Text
|
|
Some explanations of what the devschemes are for:
|
|
-------------------------------------------------
|
|
Copyright (c) 2001-2003 Hewlett-Packard Co
|
|
Contributed by Stephane Eranian <eranian@hpl.hp.com>
|
|
|
|
|
|
Whether or not EDD3.0 is enabled, EFI uses a device naming scheme which is
|
|
somewhat detailed. It tries to follow the hardware path from the System bus
|
|
down to the actual partition on the media. The following example shows
|
|
a typical block device path from a SCSI disk:
|
|
|
|
blk2 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig00000000).
|
|
|
|
Elilo allows the user to load files from any device. This means that it
|
|
must provide a way for the user to specify a file path which include
|
|
the device name. While it is theoritically possible to specify the
|
|
path mentioned above, it is far from practical because the names
|
|
are too long. There is too much details which the user (especially of
|
|
a boot loader) does not care about.
|
|
|
|
So Elilo, just like the EFI shell, must have a way of assigning logical
|
|
names to device names (paths). The EFI shell uses the fsX notation wherever
|
|
it finds a block devices for which it has detected a valid EFI filesystem
|
|
(i.e. a Fat32+ filesystem). This assignment is done on the fly, and depending
|
|
on the status of the removable media (like CDROM or floppy) the mapping can
|
|
change.
|
|
|
|
Those fsX: names are a pure abstraction of the EFI shell and have nothing to
|
|
do with the EFI specification.
|
|
|
|
Now Elilo could try to emulate then, i.e. try to reproduce the way the EFI shell
|
|
assigns names. However the problem is that, AT THIS POINT, Elilo recognized more
|
|
device from which it can load files from than the Shell does. This comes from the
|
|
fact that it can load files from the network or from an Ext2fs, for instance.
|
|
We plan on fixing those issues in the next releases of Elilo. Anyway, the problem
|
|
would still be to make sure that if we follow the same naming scheme, they match
|
|
at all times, i.e. fs0: maps to the same device in both the EFI shell and Elilo
|
|
which may be tricky as both EFI and Elilo continue to evolve. Also the Shell
|
|
naming schemes as some problems which removable devices which would not make it
|
|
easy from the bootloader.
|
|
|
|
Another possible solution would be to use the Linux kernel naming scheme, i.e.,
|
|
hda, hda1, fd0, sda... Of course, we would drop the /dev prefix in this case.
|
|
While it would make it very convenient for users and easy to configure from
|
|
a running system, it is even more difficult that the EFI Shell scheme. Again,
|
|
to succeed, the loader scheme would have to match EXACTLY what the Linux kernel
|
|
does for all possible devices. This is a very complicated task as his any
|
|
naming problem. The recent discussions about the devfs support in the kernel is
|
|
just yet another proof of the complexity. Another issue here is that this would
|
|
create a dependency between the loader and the kernel because we would need the
|
|
way the naming is done in the kernel. Again, this is very complicated, just thinnking
|
|
about how the PCI buses are scanned looking from devices.
|
|
|
|
So it looks like there is single solutions. Clearly, that is not easy and there are
|
|
multiple schemes possible. For now, we felt that it was better for Elilo to use its
|
|
own naming scheme independent from the EFI shell and the Linux kernel. While this introduces
|
|
yet another scheme, we believe its advantages outweight the software complexity associated
|
|
with the two schemes described above.
|
|
|
|
However, we recognize the need for flexibilty and that is exactly why, this version
|
|
of Elilo provide an internal interface which can used to develop custom naming schemes.
|
|
|
|
The way the filepaths are translated by Elilo is very basic and based on a simple
|
|
string matching algorithm. A full pathname is specified as follows:
|
|
|
|
dev_name:/path/to/my/file.
|
|
|
|
The 'dev_name' is created by Elilo and can be anything relevant to the user. There is
|
|
an internal binding from the name to the actual EFI device handle and more precisely
|
|
the filsystem interface associated to it (the device handle is never exposed to the
|
|
boot loader).
|
|
|
|
By default, Elilo uses an extremely simple scheme which is similar to the EFI shell.
|
|
if simply builds the device names as follows:
|
|
|
|
devXXX.
|
|
|
|
The XXX is just the number of the device. It is incremented by one each time recognized
|
|
filesystem is detected on that device. The clear advantage is simplicity. The downside
|
|
is that is creates a 'flat' namespace where every new device detected (like a floppy
|
|
is inserted) will show up anywhere in the set of devices and may push some fixed
|
|
devices up or down. So it hard to rely on devXXX to always mean the same things.
|
|
|
|
Now custom naming schemes can be added on top of this, which would partially or totally
|
|
replace this default scheme. Elilo is shipped with one such scheme called 'simple'.
|
|
It provides an example of how one can develop a new scheme. The main characteristic
|
|
of 'simple' is that it tries to group devices by controller (Messaging Device in
|
|
EFI terminology). Hence, all the ATAPI devices show up as atapiXXX and the SCSI
|
|
device show up as SCSIXXX. This implicitely shields the SCSI (fixed most likely) devices
|
|
from the removable media coming from ATAPI (like floppy or CDROM). So it is slightly
|
|
better but far from perfect.
|
|
|
|
Here is an example of what it looks like on an actual system:
|
|
|
|
scsi0 : vfat : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig00000000)
|
|
scsi1 : vfat : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part1,Sig00000000)
|
|
atapi0 : vfat : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Secondary,Master)/CDROM(Entry1)
|
|
scsi2 : ext2fs : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part2,Sig00000000)
|
|
scsi3 : ext2fs : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part2,Sig00000000)
|
|
net0 : netfs : Acpi(PNP0A03,0)/Pci(5|0)/Mac(00D0B7A6FC25)
|
|
|
|
|
|
The 'simple' scheme is not fully satifactory but developers are strongly encouraged
|
|
to enhance it or better create new schemes.
|
|
|