Re: [TTY] exclusive mode question

[Russell King]

On Fri, Jun 10, 2005 at 11:36:54AM +0200, moreau francis wrote:
> 
> --- Denis Vlasenko <vda@xxxxxxxxxxxxx> a écrit :
> 
> > On Thursday 09 June 2005 18:12, Russell King wrote:
> > > On Thu, Jun 09, 2005 at 04:22:49PM +0200, moreau francis wrote:
> > > > --- Frederik Deweerdt <dev.deweerdt@xxxxxxxxxxx> a écrit :
> > > > > Le 09/06/05 13:41 +0200, moreau francis écrivit:
> > > > > > 
> > > > > > oh ok...sorry I misunderstood TIOEXCL meaning ;)
> > > > > > Do you know how I could implement such exclusive mode (the one I
> > described)
> > > > > ?
> > > > > > 
> > > > > This is handled through lock files, google for LCK..ttyS0
> > > > >
> > > > 
> > > > This lock mechanism is a convention but nothing prevent a user
> > application to
> > > > issue a "echo foo > /dev/ttyS0" command while "LCK..ttyS0" file exists...
> > > 
> > > Which is absolutely necessary to work if you think about an application
> > > like minicom and its file transfer helpers, which may need to re-open
> > > the serial port.
> > > 
> > > TTY locking is done via lock files only, and all non-helper applications
> > > must coordinate their access via the lock files.  There is no other
> > > mechanism.
> > 
> > I think original reporter is saying that TIOEXCL is nearly useless then.
> >
> 
> Why not using mandatory locks instead of this "weak" user lock mechanism ?

As I've already said - helper applications.

There's another case as well.  Consider the following:

- getty is listening on the serial port for an incoming modem call
  (eg, mgetty)
- you want to make an outgoing call (eg, minicom)

Both have to co-operate with each other via the lock files to ensure
that they don't stomp on each other - and the point at which they claim
the lock is most definitely not at serial port open time.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/