Messages in this thread | | | Date | Fri, 8 Oct 1999 16:46:20 -0400 | From | Johannes Erdfelt <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
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: > > > On Fri, 8 Oct 1999, Johannes Erdfelt wrote: > > > > > > > On Fri, Oct 08, 1999, danielt@digi.com <danielt@digi.com> wrote: > > > > > On Fri, 8 Oct 1999, Theodore Y. Ts'o wrote: > > > > > > > > > > > > > > > > > With a /devfs approach, you will still need to readdir() through all of > > > > > > /devfs, figure out what changed, and then stat the device to see what > > > > > > has differed. This also limits the information you can read out to what > > > > > > is the stat()-style interface can provide, and that may not be enough to > > > > > > give you the USB topology information. I suppose you could use > > > > > > directories to represent USB hubs, but now you will have to recursively > > > > > > search a directory tree to find the new devices! See what I mean? It's > > > > > > a bad way of communicating this kind of information to the user process. > > > > > > > > > > > > The advantage of /devfs is that for folks who don't care, they can > > > > > > simply overmount /dev and be done with it. But in the long term, if you > > > > > > accept the supposition that you *need* a user-mode daemon, /devfs is an > > > > > > inefficient interface. > > > > > > > > > > > Um, with devfs you do not need a user space daemon, so that daemon does > > > > > not need to keep track of all the changes to the /dev directory, which > > > > > promptly renders the rest of the argument irrelevent. > > > > > > > > > > If the user plugs in a USB modem, the user knows they plugged in a modem, > > > > > they run their getty/pppd/minicom on the new modem device. > > > > > > > > No, no, no. No one seems to understand the issues at stake here. > > > > > > > > I have 2 modems, I plug modem A in first, it becomes (hypothetical) > > > > device /dev/modem1. I plug in modem B second, it becomes /dev/modem2. > > > > > > > > Now, I unplug both and plug modem B in first, it becomes modem1 now with > > > > the current naming system. > > > > > > > > This is completely unacceptable. > > > > > > > > Does devfs solve this problem right now? No. Will it be easy to solve > > > > this problem with devfs when an appropriate algorithm to name PnP > > > > devices is created. Yes. > > > > > > > OK, I think I understand. This is a problem that is more difficult > > > to solve from a userspace daemon than it is from within the USB > > > driver itself. All a userspace component would be able to do > > > here is assign the appropriate name to the device, and with > > > 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?
> 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.
I have the feeling that we are on different wavelengths here.
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/
| |