> On Fri, Oct 08, 1999, danielt@digi.com <danielt@digi.com> wrote:
> > On Fri, 8 Oct 1999, Johannes Erdfelt wrote:
> >
> > > On Fri, Oct 08, 1999, danielt@digi.com <danielt@digi.com> wrote:
> > > > devfs the USB driver can do that directly. The problem is strictly
> > > > with USB device naming so devfs is merely one possible solution.
> > >
> > > Yes, devfs is obviously not the only solution, but IMHO is probably the
> > > best solution since it already exists, is well thought out and would
> > > easy to modify to do the appropriate work to determine a name.
> > >
> > > Placing this naming in the USB kernel driver is not a good idea since
> > > it's complicated. USB devices have serial numbers, but only SOME devices
> > > have serial numbers. Naming based on topology information is possible,
> > > but is obviously not a perfect solution. Placing all of ths into the
> > > kernel is not a good idea nor will be it accepted (Linus has already
> > > stated this).
> > >
> > 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.
>
> Yeah, the user sets policy, devfs follows that policy.
>
> > > However, using devfs is just my opinion.
> > >
> > devfs is not a solution for the naming problem. It is
> > a convenient mechanism if the naming problem is to be solved
> > from the driver.
> >
> > If the naming problem is going to be solved from userspace, devfs
> > can help but it is not a "magic bullet" in that respect.
> > NOTE: while it cannot help with naming, it can ensure
> > that you at least have a device regardless of name.
>
> I don't understand what you mean. Why can't it help with naming?
>
Because devfs only forwards the name the driver gives it.
If the driver registers: /dev/USB/foo, 256 devices, then devfs
shows /dev/USB/foo[000-256]. (mangled widlcard, I know)
> > So to borrow from myself:
> > 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!
> >
> > > The need for a userspace daemon to name devices based off of the little
> > > amount of information that is possible to garner needs to be created.
> > >
> > The userspace daemon should probably not be responsible for primary
> > device creation in this case, if it gets confused we are still
> > falling back on arbitrary naming schema and may not get devices
> > without a manual mknod. At the very least with devfs we get
> > a topologicly named device that the user space daemon can ask
> > the user for directions on.
>
> devfs has the userspace. devfsd would be responsible for seeing that a
> new device got connected, obtaining information useful to naming it,
> and then naming it.
>
What does devfsd know about naming USB devices that the USB
driver doesn't? A daemon specificly USB aware would be needed
if the problem is really as intractable as Ted T'so asserts.
In which case the _actual_device_name_ isn't so relevant as what
is done with it. If you plug in a USB floppy you might get a device
named /dev/USB/b0h5n14, but if the daemon knows what kind of device
it is it can inform the user appropriately. Such information would
have to be passed to the daemon by syscall(), /dev/USB/status, or
ioctl(USB_STAT) on the device. I personally would favor the
/dev/USB/status solution because you can do a string search
on it for a desired device type instead of having to open(), ioctl(),
and close() each device until you found the right one. Ted is right
that as a method for identifying devices it is nasty.
If the daemon gets stumped, it can _ask_ the user "what did you
just plug into me Pietr?", then treat it appropriately.
Neither devfs nor the USB driver can or should have _that_
capability.
None of this means that devfs is irrelevant to the task
at hand, it just sounds like more is being asked of it
than it is explicitly designed to do.
> I have the feeling that we are on different wavelengths here.
>
Quite possibly.
-- Daniel Taylor Senior Test Engineer Digi International danielt@digi.com Open systems win.
- 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/