No edit summary |
(→Firewire (IEEE 1394) networks?: new section) |
||
| Line 4: | Line 4: | ||
We initially intended to just make it follow the biosdevname conventions, but then ended up following the conventions set forth by udev's own /dev/*/by-path/ logic instead. The reason for that is that biosdevname in various cases makes up its own numbering scheme instead of strictly sticking to the predictable low-level topology data of the device themselves. For some cases, it enumerates things based on what is available, thus requiring that the tool runs at a point where "all" hw is already found (such a point in time does not exist in reality), and where no devices appear/are removed later on anymore. By doing that it kinda defeats its own goal. This creates real problems, like for example this one: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 -- Note however that if biosdevname is installed it will always take precedence, this new udev-owned scheme is only the fallback if nothing else is configured. --[[User:Lennart|Lennart]] ([[User talk:Lennart|talk]]) 20:10, 23 January 2013 (UTC) | We initially intended to just make it follow the biosdevname conventions, but then ended up following the conventions set forth by udev's own /dev/*/by-path/ logic instead. The reason for that is that biosdevname in various cases makes up its own numbering scheme instead of strictly sticking to the predictable low-level topology data of the device themselves. For some cases, it enumerates things based on what is available, thus requiring that the tool runs at a point where "all" hw is already found (such a point in time does not exist in reality), and where no devices appear/are removed later on anymore. By doing that it kinda defeats its own goal. This creates real problems, like for example this one: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 -- Note however that if biosdevname is installed it will always take precedence, this new udev-owned scheme is only the fallback if nothing else is configured. --[[User:Lennart|Lennart]] ([[User talk:Lennart|talk]]) 20:10, 23 January 2013 (UTC) | ||
== Firewire (IEEE 1394) networks? == | |||
What about networks with firewire transport (PCI class 0c00 instead of 0200)? Is it simple to include those devices, too? | |||
Revision as of 16:04, 25 January 2013
biosdevname conventions
Is there a particular reason this feature doesn't follow the biosdevname convetions? Could it be made to? That scheme is already in production (in Fedora and in Enterprise Linux) and is carefully designed to cover many cases (both obscure and common). --Mattdm (talk) 21:36, 18 January 2013 (UTC)
We initially intended to just make it follow the biosdevname conventions, but then ended up following the conventions set forth by udev's own /dev/*/by-path/ logic instead. The reason for that is that biosdevname in various cases makes up its own numbering scheme instead of strictly sticking to the predictable low-level topology data of the device themselves. For some cases, it enumerates things based on what is available, thus requiring that the tool runs at a point where "all" hw is already found (such a point in time does not exist in reality), and where no devices appear/are removed later on anymore. By doing that it kinda defeats its own goal. This creates real problems, like for example this one: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 -- Note however that if biosdevname is installed it will always take precedence, this new udev-owned scheme is only the fallback if nothing else is configured. --Lennart (talk) 20:10, 23 January 2013 (UTC)
Firewire (IEEE 1394) networks?
What about networks with firewire transport (PCI class 0c00 instead of 0200)? Is it simple to include those devices, too?