From: Russell King <rmk+lkml@arm.linux.org.uk>
To: moreau francis <francis_moreau2000@yahoo.fr>
Cc: Denis Vlasenko <vda@ilport.com.ua>,
Frederik Deweerdt <dev.deweerdt@laposte.net>,
linux-kernel@vger.kernel.org
Subject: Re: [TTY] exclusive mode question
Date: Fri, 10 Jun 2005 17:24:20 +0100 [thread overview]
Message-ID: <20050610172420.B18927@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20050610093654.94565.qmail@web25806.mail.ukl.yahoo.com>; from francis_moreau2000@yahoo.fr on Fri, Jun 10, 2005 at 11:36:54AM +0200
On Fri, Jun 10, 2005 at 11:36:54AM +0200, moreau francis wrote:
>
> --- Denis Vlasenko <vda@ilport.com.ua> 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@laposte.net> 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
next prev parent reply other threads:[~2005-06-10 16:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-09 8:49 moreau francis
2005-06-09 9:36 ` Frederik Deweerdt
2005-06-09 9:59 ` moreau francis
2005-06-09 10:41 ` Frederik Deweerdt
2005-06-09 11:41 ` moreau francis
2005-06-09 12:16 ` Frederik Deweerdt
2005-06-09 14:22 ` moreau francis
2005-06-09 15:12 ` Russell King
2005-06-10 7:03 ` Denis Vlasenko
2005-06-10 7:11 ` moreau francis
2005-06-10 9:36 ` moreau francis
2005-06-10 16:24 ` Russell King [this message]
2005-06-09 12:16 ` moreau francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050610172420.B18927@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=dev.deweerdt@laposte.net \
--cc=francis_moreau2000@yahoo.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@ilport.com.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®