I still did not get a warm and fuzzy feeling out of this discussion, so
I called Alan Cox and chatted some with him. My kludge detector was going
off...
To begin with, this is really a generic problem, common to USB, PCMCIA,
and Hot swap PCI. I don't like one off solutions to generic problems.
Secondly, the proposed solution to poll(select) on a USB provided file
name is fragile, unless there is a guarantee the path exists.
Third: Alan pointed out to me that polling on a path isn't reliable: there
is a race from the time you return to poll again after you've finished
rescanning for new devices. While we might kludge around it, it would be
fraught with possible problems.
Alan's suggestion is that USB should work as they do with PCMCIA: the
kernel's internal interface sends a message to a user daemon, which runs
a script on a per device/device type basis. By using a messaging model,
you avoid the race condition that will occur in a polling design. This
script might, in this particular case, send a signal or a message over
a pipe to the X server to look for new input devices.
Note that you have all the same issues for USB ethernet and storage devices
that exists for PCMCIA: in the case of a disk, for example, you may want
to recognise which disk, and decide to mount it on some mount point, or
not, or bring up a network interface and change your routing.
So I believe strongly that Alan is right, that the suggestion X poll(select)
on your magic pathname is the WRONG solution, and that USB should adopt
the existing model for PCMCIA: the daemon process can be shared, and
we can do "the right thing" generically. USB and PCMCIA and HS PCI then
all work the same, and work correctly (which polling would not be able
to guarantee).
Comments?
- Jim Gettys
--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
