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