On Thu, Sep 27, 2012 at 05:00:37PM +0100, Alan Cox wrote:
> > > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > > in the pty.c code and note that not all platforms use asm-geneic TTY
> > > ioctls so check carefully they all build.
> >
> > I put it into tty_ioctl.c simp
> > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > in the pty.c code and note that not all platforms use asm-geneic TTY
> > ioctls so check carefully they all build.
>
> I put it into tty_ioctl.c simply because TIOCPKT was there already so
> I thought it's good idea t
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
> > Well, sure inside our tool before doing checkpoint we stop all
> > tasks which are part of dumpee process tree. This unfortunatly
> > doesn't apply to these ioctl calls. Peter, any idea how to deal
> > with that?
>
> I suspect you can't
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
> > Well, sure inside our tool before doing checkpoint we stop all
> > tasks which are part of dumpee process tree. This unfortunatly
> > doesn't apply to these ioctl calls. Peter, any idea how to deal
> > with that?
>
> I suspect you can't
> Well, sure inside our tool before doing checkpoint we stop all
> tasks which are part of dumpee process tree. This unfortunatly
> doesn't apply to these ioctl calls. Peter, any idea how to deal
> with that?
I suspect you can't deal with that. Which isn't to say you can't still
build something us
On 09/27/2012 07:48 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
If you can't guarantee that ALL those processes are stopped and
checkpointed/restarted, you have a huge problem.
Well, sure inside our tool before doing checkpoint we stop all
tasks w
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
> >>If you can't guarantee that ALL those processes are stopped and
> >>checkpointed/restarted, you have a huge problem.
> >
> >Well, sure inside our tool before doing checkpoint we stop all
> >tasks which are part of dumpee process tr
On 09/27/2012 07:21 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.
What bothers me (and the same applies t
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
> >While we easily can fetch termios settings and such, there are few bits which
> >are missed to expord. So this patch provides them to user-space.
> >
>
> What bothers me (and the same applies to termios) is that you have
> NO idea
On 09/27/2012 07:14 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios se
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
> > Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> > of termios settings, once fetched they can be changed immediately, and it's
> > up to caller what to do with termios settings. No?
>
> I think you need to e
> Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> of termios settings, once fetched they can be changed immediately, and it's
> up to caller what to do with termios settings. No?
I think you need to explain what you expect to be doing with it, and why
it is safe in th
On Mon, Sep 24, 2012 at 06:14:41PM +0400, Cyrill Gorcunov wrote:
>
> 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 th
On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
> Cyrill Gorcunov 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
On Sun, Sep 23, 2012 at 07:44:54AM -0700, H. Peter Anvin wrote:
>
> Funny... I gave you that feedback the last go around.
I'm sorry, Peter, I guess I simply missed it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Sun, Sep 23, 2012 at 07:46:24AM -0700, H. Peter Anvin wrote:
> >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.
Wait, Peter, this lock is se
Cyrill Gorcunov 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 value
Cyrill Gorcunov wrote:
>On Sat, Sep 22, 2012 at 06:43:37PM -0700, Eric W. Biederman wrote:
>>
>> I don't know where this conversation comes from but putting ptys in
>> sysfs in combination with the newinstance mount option is completely
>> broken unless the device name and device number duplic
On Sat, Sep 22, 2012 at 06:43:37PM -0700, Eric W. Biederman wrote:
>
> I don't know where this conversation comes from but putting ptys in
> sysfs in combination with the newinstance mount option is completely
> broken unless the device name and device number duplication is handled,
> which I don'
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
> > > > fi
I don't know where this conversation comes from but putting ptys in
sysfs in combination with the newinstance mount option is completely
broken unless the device name and device number duplication is handled,
which I don't see here.
Cyrill Gorcunov writes:
>
> Guys, you mean something like below
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
> > Guys, you mean something like below? Look, I must admit I'm not really
> > sure if I've done all locking right, and there is no need for additional
> > kref counting on tty_struct. Could you please check if it looks more-less
> > sane (I've tested it but still...)
This still doesn't answer th
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 b
On Sat, Sep 22, 2012 at 01:07:31PM -0700, Greg Kroah-Hartman wrote:
> > drivers/tty/pty.c | 45 -
> > 1 file changed, 44 insertions(+), 1 deletion(-)
> >
> > Index: tty.git/drivers/tty/pty.c
> >
On Sat, Sep 22, 2012 at 10:06:39PM +0400, Cyrill Gorcunov wrote:
> On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> > On Thu, 13 Sep 2012 16:54:01 +0400
> > Cyrill Gorcunov wrote:
> >
> > > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > > +static int pty_get_lock(str
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 16:54:01 +0400
> Cyrill Gorcunov wrote:
>
> > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > > +{
> > > > + int locked =
On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 16:54:01 +0400
> Cyrill Gorcunov wrote:
>
> > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > > +{
> > > > + int locked =
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov wrote:
> On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > +{
> > > + int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> > > + if (put_user(locked, arg))
> > >
On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > +{
> > + int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> > + if (put_user(locked, arg))
> > + return -EFAULT;
>
> Now explain exactly how this doesn
> +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> +{
> + int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> + if (put_user(locked, arg))
> + return -EFAULT;
Now explain exactly how this doesn't race with another thread chanigng
the lock setting ?
The other
On Thu, Sep 13, 2012 at 01:46:53PM +0200, Jiri Slaby wrote:
> On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote:
> > For checkpoint/restore we need to know if tty has
> > exclusive or packet mode set, as well as if pty
> > is currently locked. Just to be able to restore
> > this characteristics.
> >
>
On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote:
> For checkpoint/restore we need to know if tty has
> exclusive or packet mode set, as well as if pty
> is currently locked. Just to be able to restore
> this characteristics.
>
> For this sake the following ioctl codes are introduced
>
> - TIOGPKT
33 matches
Mail list logo
