Hi!
> >>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... 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.)
> >
> >
> >You can very well use driverfs to expose those attributes, and is one of
> >the things that we've been discussing at the kernel summit. driverfs will
> >take over the world. But, I still think the device is best represented as
> >a child of the phsysical network device.
>
> Which one? I'd certainly hope that drivers wouldn't have to choose which
> of the various network interfaces to register under, or register under
> every network interface concurrently. (Or only the ones they might
> conceivably be routed to go out on...) Given a bonded network link (going
> out over multiple physical drivers) that'd get hairy. And what about
> devices that host several logical interfaces? Or when the interfaces get
> moved to some other device?
>
> That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> sensible in such cases. Which is not to say it's without additional issues
> (like how to establish/maintain driver linkages that are DAGs not single
> parent trees) but it wouldn't require drivers to dig as deeply into
> >>lower
Hmm, are dags enough?
I mean, cycles exist in IP based networks, and I don't see a reason
why it could not exist with some kind of advanced fibrechannel.
Pavel
-- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:11 EST