> > Without any planing or forethought. It's procfs all over again.
>
> ???
> pcihpfs is well planned. So are all of the different filesystems
> that are now present. They do one thing, and one thing only. Much
> unlike procfs. That's why driverfs was not implemented within procfs.
All the filesystems in themselves are probably planned.
But there's no overall concept to it. Unchecked
growth of special purpose filesystems is not the answer.
> > > > We need some centralised point for doing
> > > > device configuration.
> > >
> > > That's what userspace tools are for :)
> >
> > Nope. There's no sanity found if you need half a dozen
> > filesystem with strange failure modes if one happens to be mounted
> > on a different place or with strange permissions.
> > We need unification. There's nothing hotplug specific
> > about node<->device correspondence. It belongs
> > in driverfs. We need to get rid of special cases.
>
> Wait, node<->device correspondence is currently done in /dev and has
> nothing to do with driverfs. driverfs is to represent the devices in
> the kernel, and show their hierarchy to allow power management to be
> implemented sanely.
node<->device correspondence is done nowhere or scattered throughout
proc eg /proc/scsi/scsi.
/dev does name/permissions<->node. This is insufficient with hotplugging
and was always a problem. It is there in all devices, thus deserves to
be solved in the place central to all devices.
Or even simpler would be a common way to ask if you only had a filehandle,
which would have to be an ioctl.
> However, the /sbin/hotplug interface can be used... But that's an
> argument for a later time, after some more design work is done :)
No, it cannot. It's event based. We need a simple and robust way
to get that information.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
