lkml.org 
[lkml]   [2002]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] /proc/scsi/map
    >>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
    levels of their stack. (And some network interfaces might well live in
    such a non-physical tree, not just iSCSI...)

    I think that problem wouldn't quite be isomorphic to multipath access to
    devices, though it seems to be related. "Driver stacking" is an area
    that "driverfs" doesn't seem to address quite yet ... not needed in the
    simpler driver scenarios, so that's what I'd expect at this stage.

    - Dave




    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.024 / U:2.024 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site