The linux-usb-devel list has been added to the Cc on this
reply since it relates to USB naming conventions under DevFS...
Consequently, I have trimmed very little of this message so
that others on the USB list aren't lost wondering WTF...
Richard Gooch has been added to the Cc on this reply at his request.
On Wed, Oct 24, 2001 at 11:17:57PM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 24 Oct 2001, Michael H. Warfield wrote:
>
> > On Wed, Oct 24, 2001 at 10:23:19PM -0400, [EMAIL PROTECTED] wrote:
> >
> > > Yes. That locking mechanism locks, in effect, the leafname of the file
> > > the app is given to open. If you use devfsd, you can give the app
> > > (pppd, cu, minicom, whatever) the old style device name, which is a
> > > symbolic link to the devfs name, and it will be able to open it, and it
> > > will be different for the usb and plain serial ports, I think. If you
> > > do this, it is your responsibility to see that all apps use the symbolic
> > > link. An app that locks /dev/tts/0 will not stop another app from
> > > opening /dev/ttyS0 with somewhat disruptive results, but if both use
> > > /dev/ttyS0, their access will be properly serialized. You could also
> > > have the System Administrator make up an arbitrary symbolic link for
> > > each device, that way you wouldn't need devfsd. /serial/0 and
> > > /serial/usb0, if you like. If everybody agrees to use the same name for
> > > the same entity, locking works, but if not, not.
> >
> > What?
> >
> > Oh oh... This is not good...
> >
> > I'm the maintainer of the Computone Multiport serial board.
> >
> > That driver registers /dev/ttf/{n} and /dev/cuf/{n}, corresponding
> > to the classical definitions of /dev/ttyF{n} and /dev/cuf{n} where n can
> > be 0-256 (4 multiport boards each supporting 4 interface boxes with 16
> > ports per interface box). Even got the ttyf/{n} to ttyF{n} mapping
> > in devfsd. That driver has major numbers 71 for the ttyF{n} devices
> > and 72 for the cuf{n} devices.
> >
> > How is this suppose to work with this locking mechanism? It
> > looks like ttyS0 (ttys/0) will end up with the same lock file as ttyF0
> > (ttyf/0) which are most definitly NOT the same device!
> >
> > There is no correspondence or correlation between the drivers
> > and the lock files that are being created. That is NOT good at all.
> > Assuming that a simple number on the lock file extension completely
> > describes the driver and device is not good. Maybe I should have made
> > those names ttyf/f{n} and cuf/f{n} in devfs name space but that's not
> > what they are now.
>
> I don't think that would help. LCK..f0 is the same as LCK..f0, just as
> LCK..0 is the same as LCK..0. ttyf/f{n} and cuf/c{n} would work, maybe.
As I mentioned in another message, this is actually a good thing,
because you want LCK.f0 to lock both tts/F0 and cua/F0 since they really
ARE both the same thing. Although that is taking advantage of a hack
to do so. It's actually a cleaner hack than the convention on SCO Unix
systems where they uppercase and lowercase the last letter of the
name for the call-out or dial-in (tty0A / tty0a) and then always lowercase
the lock file name. Talk about a butt-ugly hack and a half.
Of course, I recognize that the "cua" devices are suppose to
be deprecated, anyways, but there is still the point.
> > Sounds like the classic "flat name space" names will have to
> > be used to avoid collisions in the devfs namespace due to that leaf
> > name reduction to the lock files. I should probably add something
> > to my documentation on this. Shit... I just got done sending patches
> > into Linux and Alan for the latest drivers. Somehow I don't think
> > they'll appreciate the humor in some last minute doco changes. :-/
> > Alan, in particular, is sure to have some witty comment for me (inside
> > joke).
> >
> > Mike
> >
> Well, devfs is still an option, and it is up to the sytem administrator
> if it wants to use it, OTOH she had warts, and the distros have
> effectively taken the role of system administrator. I think Mandrake
> at least has already decided to use it in some release.
I've been trading some E-Mail with Alan Cox, Richard Gooch, and
Linus about this. Richard just got back to me with the following:
Richard Gooch writes:
] Alan Cox writes:
] > Michael H. Warfield writes:
] > > character to the name ( ttf/f0 instead of ttf/0 ). The former, kind
] > > of defeats the whole purpose of devfs to begin with while the later
] > > will also require fixes to devfsd plus yet another patch to my driver
] > > (thanks for the warning Alan, it's raining rocks around here, you know).
] > >
] > > Any other thoughts or suggestions?
] >
] > For the 2.2 stuff there is no devfs so that doesn't seem a
] > problem. I'd say leave the problem to user space. Debian at least
] > has a lockfile lib that everyone is meant to go via - so its not
] > that hard to fix.
]
] I agree: it's a user-space problem. I'll note the problem is somewhat
] mitigated by recent patches which place all serial devices under
] /dev/tts, so you have:
] /dev/tts/%d standard serial driver
] /dev/tts/E%d Stallion serial driver
]
] and so on. So the Computone driver should use /dev/tts/F%d, which is
] consistent with the scheme Ted, Peter, Russell and I came up with at
] OLS.
So, I would gather from this that, the USB serial drivers, which
currently register ACM serial ports under usb/acm/%d should be registering
them under ttys/U%d instead, under the devfs standard that now appears
to have been agreed upon. I'm now preparing a patch for the Computone
driver, to match up as Richard described, and to use tts/F%d instead
of ttf/%d. I'll probably have those into Alan and Linus later today.
Richard asked me to raise this point on these lists and to Cc
him in on the thread. So be it.
] But it doesn't help for the clash between /dev/vc/0 and /dev/tts/0,
] for example. A couple of years ago Peter suggested the right way is to
] form the lockfile name based on the device number. That's better than
] using the leaf node name. If that's the scheme the Debian library
] uses, then just encourage everyone to use that instead. It's probably
] good to have that centralised, anyway.
> If it is any comfort to you, I think that locking mechanism is sort of
> obsolete, but I see with some chagrin that the pppd mentioned in
> <linux-2.4.10>/Documentation/Changes still uses it.
> Lawson
> ---oof---
Regards,
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
