Re: [RFC] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
> Cyrill Gorcunov <gorcunov@xxxxxxxxxx> wrote:
> 
> >On Sat, Sep 22, 2012 at 06:09:53PM -0700, Greg Kroah-Hartman wrote:
> >> On Sun, Sep 23, 2012 at 01:52:32AM +0400, Cyrill Gorcunov wrote:
> >> > On Sun, Sep 23, 2012 at 12:11:44AM +0400, Cyrill Gorcunov wrote:
> >> > >
> >> > > > Sysfs is one value per file, you have three values here, please
> >make 3
> >> > > > files.
> >> > > > 
> >> > > > And document them in Documentation/ABI/.
> >> > > 
> >> > > Hmm, sure Greg, I'll update. Thanks!
> >> > 
> >> > Something like below I suppose? Look, if there will be no complains
> >> > on tech aspects on the patch (locking and tty refs) -- I'll update
> >> > Documentation. Just want be sure I've made no mistakes here.
> >> > 
> >> > Another question -- would not it be worth to wrap code with
> >> > CONFIG_CHECKPOINT_RESTORE?
> >> 
> >> Alan's point stands, what's the use of this if it can instantly
> >> change after you read the value?
> >
> >We use it when we do a checkpoint, ie when tasks are stopped. I think
> >it's close to data obtained from procfs (ie valid once you read it but can
> >be changed right after that operation). Maybe I should put everything to
> >procfs, or stick back with ioctl calls?
> 
> The problem as I see it is that you don't know if your process is the lock holder.

Guys, after being trying sysfs approach I think ioctls is a bit better, because
it requires only local changes not propagated to devpts, also this calls are
allowed via file descriptor owner only.

Actually I thought what if extend existing set-(lock,packet-mode,exclusive)
calls to return previous state of appropriate variable, but this will break
abi so i had to refuse this idea.

As to Alan's point on "what's the use of this if it can instantly change
after you read the value" I guess it's the same as what we have when we
simply set the value. Imagine we have two tasks fork'ed, first task do
lock the pty while another task does unlock it immediately after that,
as far as I see there is nothing preventing user space to do that, thus
first task will think it has locked the peer while in real the peer remains
unlocked. Same here with reading this value -- it's valid once read but
can be changed right after. Isn't it?
--
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/