There are those who see the IP stack as a kind of logical bus ... :)
It's just not tied any specific hardware interface; it's "multipathed" in
some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0
would be wrong, since it can also be accessed through eth2.
Why shouldn't there be a $DRIVERFSemail@example.com/... style hookup
for iSCSI devices? Using whatever physical addressing the kernel uses
there, which I assume wouldn't necessarily be restricted to ipv4. (And
not exposing physical network topology -- routing! -- in driverfs.)
On a related topic ... if driverfs is going to be providing a nice unique
ID for the controller ($DRIVERFS/root/pci0/00:02.0/02:0f.0/03:07.0 for
Linus' behind-two-bridges case), why are people talking as if the SCSI
layer's arbitrary "controller number" should still be getting pushed as
part of user visible names?
That is, I'd sure hope the standard policy for assigning driverfs names
would avoid _all_ IDs that are derived from enumeration order. Otherwise
it'll be hard to store those names for (re)use by user mode tools.
To be sure, those IDs can still be exposed when needed, since in the
"very big picture" attribute-based names end up being the only really
scalable model. But putting unstable attributes into path names just
causes trouble. (Much like putting device types in path names.) If
they're really necessary (why?) driverfs makes it easy to expose them
in better ways.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/