On 01/17/2013 05:29 PM, Greg KH wrote:
> On Fri, Jan 11, 2013 at 01:18:02PM +, Alan Cox wrote:
>> IMHO - fix now for the -rc tree where its clearly low risk, after that
>> whatever people feel like doing 8)
>
> I agree. Jiri, should I take your posted patch for this?
Yeah, I think it's just
On Fri, Jan 11, 2013 at 01:18:02PM +, Alan Cox wrote:
> On Fri, 11 Jan 2013 13:44:22 +0100
> Jiri Slaby wrote:
>
> > On 01/11/2013 01:41 PM, Florian Westphal wrote:
> > > Jiri Slaby wrote:
> > >> On 01/10/2013 11:51 PM, Jiri Slaby wrote:
> > >>> On 01/10/2013 11:45 PM, Alan Cox wrote:
> > >>
On Fri, 11 Jan 2013 13:44:22 +0100
Jiri Slaby wrote:
> On 01/11/2013 01:41 PM, Florian Westphal wrote:
> > Jiri Slaby wrote:
> >> On 01/10/2013 11:51 PM, Jiri Slaby wrote:
> >>> On 01/10/2013 11:45 PM, Alan Cox wrote:
> So we should just fix TIOCGPTN on a pty with no suitable name
> an
On 01/11/2013 01:41 PM, Florian Westphal wrote:
> Jiri Slaby wrote:
>> On 01/10/2013 11:51 PM, Jiri Slaby wrote:
>>> On 01/10/2013 11:45 PM, Alan Cox wrote:
So we should just fix TIOCGPTN on a pty with no suitable name answer to
return -EINVAL
>>>
>>> Yes, I agree as I'm expressed in my
Jiri Slaby wrote:
> On 01/10/2013 11:51 PM, Jiri Slaby wrote:
> > On 01/10/2013 11:45 PM, Alan Cox wrote:
> >> So we should just fix TIOCGPTN on a pty with no suitable name answer to
> >> return -EINVAL
> >
> > Yes, I agree as I'm expressed in my second mail. Sorry for the confusion.
>
> Does th
On 01/10/2013 11:51 PM, Jiri Slaby wrote:
> On 01/10/2013 11:45 PM, Alan Cox wrote:
>> So we should just fix TIOCGPTN on a pty with no suitable name answer to
>> return -EINVAL
>
> Yes, I agree as I'm expressed in my second mail. Sorry for the confusion.
Does the attached patch help?
--
js
suse
On 01/10/2013 11:45 PM, Alan Cox wrote:
> So we should just fix TIOCGPTN on a pty with no suitable name answer to
> return -EINVAL
Yes, I agree as I'm expressed in my second mail. Sorry for the confusion.
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> getptsname expects EINVAL on failure to fall back to /dev/ttyp*... The
> same as unlockpt. We should definitely revert now and can teach glibc
> to accept also ENOTTY. After some years, we can try again :).
Strongly disagree for two reasons
1. We don't want to leave the other ioctls broken and
On 01/10/2013 06:23 PM, Jiri Slaby wrote:
> getptsname expects EINVAL on failure to fall back to /dev/ttyp*... The
> same as unlockpt. We should definitely revert now
Maybe not that strictly. It would be enough to revert TIOCGPTN and
TIOCSPTLCK to return EINVAL as suggested by Alan.
--
js
suse la
On 01/10/2013 05:29 PM, Florian Westphal wrote:
> Alan Cox wrote:
>> > On Thu, 10 Jan 2013 15:46:26 +0100
>> > Florian Westphal wrote:
>>> > > Frank Lichtenheld discovered that openpty() doesn't work anymore when
>>> > > /dev/pts is not present.
>>> > >
>>> > > We bisected this down to
>>> > >
Alan Cox wrote:
> On Thu, 10 Jan 2013 15:46:26 +0100
> Florian Westphal wrote:
> > Frank Lichtenheld discovered that openpty() doesn't work anymore when
> > /dev/pts is not present.
> >
> > We bisected this down to
> >
> > commit bbb63c514a3464342967237a51a21ea8f61ab951
> > Author: Wanlong Gao
On Thu, 10 Jan 2013 15:46:26 +0100
Florian Westphal wrote:
> Frank Lichtenheld discovered that openpty() doesn't work anymore when
> /dev/pts is not present.
>
> We bisected this down to
>
> commit bbb63c514a3464342967237a51a21ea8f61ab951
> Author: Wanlong Gao
> Subject: drivers:tty:fix up ENO
Frank Lichtenheld discovered that openpty() doesn't work anymore when
/dev/pts is not present.
We bisected this down to
commit bbb63c514a3464342967237a51a21ea8f61ab951
Author: Wanlong Gao
Subject: drivers:tty:fix up ENOIOCTLCMD error handling
The original program triggering the error was pptpd,
13 matches
Mail list logo
