Well, in this case it can all be handled in user space as apposed to
kernel space for quotas and network routing/config/firewall, etc.
> > Using devfs you would register by name for clearly identified
> > devices, by serial number for unknown devices having serial
> > numbers and by topology for completely unknown devices.
> >
> > The USB driver has to provide the names, devfs does not
> > set policy, it only provides a mechanism.
>
> and neatly allows users to manage policy in userland where policy should be dictated.
There's 2 portions to devfs, the kernel portion and the user space
portion. I'm talking about putting all of this into the user space
portion, devfsd.
> > Daemon: select on /dev/USB/status
> > Driver: Hey! I just registered /dev/USB/213987rywsl!
> > Daemon: What's that? I better ask my user what that is!
>
> reference above in core map. if it was used before, it can be plopped into the right
> place automatically. if not, config policy dictates the next slot to fill, or to
> request the user to advise.
>
> all in all, it seems that this scheme makes things wonderfully managable and usable.
> i can now plug/unplug a particular usb mouse and plug it back in in any other port
> and have it come back as it's supposed to. truely transparent for users. should
> policy place something in jar A and the user wants it in jar B, they can (warning!
> GUI enhanced example!) pop up their little management interface and drag it from jar
> A to jar B and the in core mapping is updated appropriately.
Actually this won't work. The only way you can differentiate 2 mice (if
they don't have serial numbers) is based on their topology. If you
unplug and move them, then they are essentially a new mouse and would be
assigned a new mouse device name.
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/