On 01/28/2014 07:17 AM, Stas Sergeev wrote:
28.01.2014 16:03, Pavel Machek пишет:
Hi!
How is this different from the unpatched kernel?
In the unpatched kernel, if you happen on reader side
to enable icanon while n_tty received all but VEOF (is this
possible at all?),
then the buffer will be
28.01.2014 16:03, Pavel Machek пишет:
> Hi!
>
How is this different from the unpatched kernel?
In the unpatched kernel, if you happen on reader side
to enable icanon while n_tty received all but VEOF (is this
possible at all?),
then the buffer will be flushed, and the
Hi!
> >>How is this different from the unpatched kernel?
> >>In the unpatched kernel, if you happen on reader side
> >>to enable icanon while n_tty received all but VEOF (is this
> >>possible at all?),
> >>then the buffer will be flushed, and the remaining VEOF
> >>will get you a nice EOF.
>
Hi!
How is this different from the unpatched kernel?
In the unpatched kernel, if you happen on reader side
to enable icanon while n_tty received all but VEOF (is this
possible at all?),
then the buffer will be flushed, and the remaining VEOF
will get you a nice EOF.
So, in the unpatched
28.01.2014 16:03, Pavel Machek пишет:
Hi!
How is this different from the unpatched kernel?
In the unpatched kernel, if you happen on reader side
to enable icanon while n_tty received all but VEOF (is this
possible at all?),
then the buffer will be flushed, and the remaining VEOF
will get
On 01/28/2014 07:17 AM, Stas Sergeev wrote:
28.01.2014 16:03, Pavel Machek пишет:
Hi!
How is this different from the unpatched kernel?
In the unpatched kernel, if you happen on reader side
to enable icanon while n_tty received all but VEOF (is this
possible at all?),
then the buffer will be
04.12.2013 03:53, Peter Hurley пишет:
On 12/03/2013 02:18 PM, Stas Sergeev wrote:
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the
04.12.2013 03:53, Peter Hurley пишет:
On 12/03/2013 02:18 PM, Stas Sergeev wrote:
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the
On 12/03/2013 02:18 PM, Stas Sergeev wrote:
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the termios so has no control over
the
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the termios so has no control over
the timing of when the input is received.
Also note
On 12/03/2013 04:01 AM, Stas Sergeev wrote:
03.12.2013 04:18, Peter Hurley пишет:
Unfortunately, this patch breaks EOF push handling.
Normally, when an EOF is found not at the line start, the output
is made available to a canonical reader (without the EOF) -- this is
commonly referred to as
03.12.2013 04:18, Peter Hurley пишет:
> Unfortunately, this patch breaks EOF push handling.
>
> Normally, when an EOF is found not at the line start, the output
> is made available to a canonical reader (without the EOF) -- this is
> commonly referred to as EOF push. An EOF at the beginning of a
03.12.2013 04:18, Peter Hurley пишет:
Unfortunately, this patch breaks EOF push handling.
Normally, when an EOF is found not at the line start, the output
is made available to a canonical reader (without the EOF) -- this is
commonly referred to as EOF push. An EOF at the beginning of a line
On 12/03/2013 04:01 AM, Stas Sergeev wrote:
03.12.2013 04:18, Peter Hurley пишет:
Unfortunately, this patch breaks EOF push handling.
Normally, when an EOF is found not at the line start, the output
is made available to a canonical reader (without the EOF) -- this is
commonly referred to as
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the termios so has no control over
the timing of when the input is received.
Also note
On 12/03/2013 02:18 PM, Stas Sergeev wrote:
03.12.2013 21:00, Peter Hurley пишет:
Any unit test is specifically designed to break the code under test.
This unit test does in fact break a possible input: note specifically
that the writer is not changing the termios so has no control over
the
On 11/25/2013 08:16 PM, Peter Hurley wrote:
On 11/24/2013 06:55 AM, Peter Hurley wrote:
On 11/23/2013 07:29 PM, One Thousand Gnomes wrote:
7) Rescan line discipline buffer when changing from non-canonical to canonical
mode. The real problem with this approach (besides the inefficiency) is that
On 11/25/2013 08:16 PM, Peter Hurley wrote:
On 11/24/2013 06:55 AM, Peter Hurley wrote:
On 11/23/2013 07:29 PM, One Thousand Gnomes wrote:
7) Rescan line discipline buffer when changing from non-canonical to canonical
mode. The real problem with this approach (besides the inefficiency) is that
On 11/24/2013 06:55 AM, Peter Hurley wrote:
> On 11/23/2013 07:29 PM, One Thousand Gnomes wrote:
>>> 7) Rescan line discipline buffer when changing from non-canonical to
>>> canonical
>>> mode. The real problem with this approach (besides the inefficiency) is
>>> that this
>>> solution could
On 11/24/2013 06:55 AM, Peter Hurley wrote:
On 11/23/2013 07:29 PM, One Thousand Gnomes wrote:
7) Rescan line discipline buffer when changing from non-canonical to
canonical
mode. The real problem with this approach (besides the inefficiency) is
that this
solution could break some
On 11/23/2013 07:29 PM, One Thousand Gnomes wrote:
7) Rescan line discipline buffer when changing from non-canonical to canonical
mode. The real problem with this approach (besides the inefficiency) is that
this
solution could break some (admittedly unknown) program that contrived to
exchange
On 11/23/2013 07:29 PM, One Thousand Gnomes wrote:
7) Rescan line discipline buffer when changing from non-canonical to canonical
mode. The real problem with this approach (besides the inefficiency) is that
this
solution could break some (admittedly unknown) program that contrived to
exchange
> 7) Rescan line discipline buffer when changing from non-canonical to canonical
> mode. The real problem with this approach (besides the inefficiency) is that
> this
> solution could break some (admittedly unknown) program that contrived to
> exchange
> data in non-canonical mode but read in
7) Rescan line discipline buffer when changing from non-canonical to canonical
mode. The real problem with this approach (besides the inefficiency) is that
this
solution could break some (admittedly unknown) program that contrived to
exchange
data in non-canonical mode but read in
On 11/21/2013 12:04 AM, Peter Hurley wrote:
On 11/17/2013 01:29 PM, Pavel Machek wrote:
Hi!
On Wed 2013-10-30 07:21:13, Peter Hurley wrote:
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
??Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over
On 11/21/2013 12:04 AM, Peter Hurley wrote:
On 11/17/2013 01:29 PM, Pavel Machek wrote:
Hi!
On Wed 2013-10-30 07:21:13, Peter Hurley wrote:
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
??Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over
On 11/17/2013 01:29 PM, Pavel Machek wrote:
Hi!
On Wed 2013-10-30 07:21:13, Peter Hurley wrote:
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
??Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over bug-readline and lkml archives and found no
On 11/17/2013 01:29 PM, Pavel Machek wrote:
Hi!
On Wed 2013-10-30 07:21:13, Peter Hurley wrote:
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
??Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over bug-readline and lkml archives and found no
HI,
On Sun, Nov 17, 2013 at 7:29 PM, Pavel Machek wrote:
> Any news?
I'm also not capable of doing the analysis requested, but I want to
add a link for the the fact that Canonical has applied the patch to
the kernels shipped in Ubuntu, and up to now there have been no
reports of problems:
Hi!
On Wed 2013-10-30 07:21:13, Peter Hurley wrote:
> On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
> >??Hola Arkadiusz!
> >
> >El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
> >>Was just going over bug-readline and lkml archives and found no continuation
> >>of this.
> >
>
Hi!
On Wed 2013-10-30 07:21:13, Peter Hurley wrote:
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
??Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over bug-readline and lkml archives and found no continuation
of this.
There was a patch
HI,
On Sun, Nov 17, 2013 at 7:29 PM, Pavel Machek pa...@ucw.cz wrote:
Any news?
I'm also not capable of doing the analysis requested, but I want to
add a link for the the fact that Canonical has applied the patch to
the kernels shipped in Ubuntu, and up to now there have been no
reports of
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
¡Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over bug-readline and lkml archives and found no continuation
of this.
There was a patch proposed but didn't get applied.
On 10/29/2013 09:50 AM, Maximiliano Curia wrote:
¡Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over bug-readline and lkml archives and found no continuation
of this.
There was a patch proposed but didn't get applied.
¡Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
> Was just going over bug-readline and lkml archives and found no continuation
> of this.
> There was a patch proposed but didn't get applied.
> https://lkml.org/lkml/2013/8/17/31
> Maybe it only needs proper patch
¡Hola Arkadiusz!
El 2013-10-24 a las 18:00 +0200, Arkadiusz Miskiewicz escribió:
Was just going over bug-readline and lkml archives and found no continuation
of this.
There was a patch proposed but didn't get applied.
https://lkml.org/lkml/2013/8/17/31
Maybe it only needs proper patch
On Tuesday 03 of September 2013, Arkadiusz Miskiewicz wrote:
> On Sunday 18 of August 2013, Margarita Manterola wrote:
> > Hi,
> >
> > On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek wrote:
> > >> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> > >> index 4bf0fc0..2ba7f4e 100644
> > >>
On Tuesday 03 of September 2013, Arkadiusz Miskiewicz wrote:
On Sunday 18 of August 2013, Margarita Manterola wrote:
Hi,
On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek pa...@ucw.cz wrote:
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 4bf0fc0..2ba7f4e 100644
---
On 09/03/2013 05:12 PM, Maximiliano Curia wrote:
¡Hola Peter!
El 2013-08-19 a las 08:25 -0400, Peter Hurley escribió:
My primary concern is canonical readers not become stuck with a full
read buffer, even with bogus input data (IOW, that an error condition will
not prevent a reader from making
On 09/03/2013 05:12 PM, Maximiliano Curia wrote:
¡Hola Peter!
El 2013-08-19 a las 08:25 -0400, Peter Hurley escribió:
My primary concern is canonical readers not become stuck with a full
read buffer, even with bogus input data (IOW, that an error condition will
not prevent a reader from making
¡Hola Peter!
El 2013-08-19 a las 08:25 -0400, Peter Hurley escribió:
> My primary concern is canonical readers not become stuck with a full
> read buffer, even with bogus input data (IOW, that an error condition will
> not prevent a reader from making forward progress). I believe that won't
>
¡Hola Peter!
El 2013-08-19 a las 08:25 -0400, Peter Hurley escribió:
My primary concern is canonical readers not become stuck with a full
read buffer, even with bogus input data (IOW, that an error condition will
not prevent a reader from making forward progress). I believe that won't
happen
On Sunday 18 of August 2013, Margarita Manterola wrote:
> Hi,
>
> On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek wrote:
> >> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> >> index 4bf0fc0..2ba7f4e 100644
> >> --- a/drivers/tty/n_tty.c
> >> +++ b/drivers/tty/n_tty.c
> >> @@ -149,7
On Sunday 18 of August 2013, Margarita Manterola wrote:
Hi,
On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek pa...@ucw.cz wrote:
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 4bf0fc0..2ba7f4e 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -149,7 +149,8 @@
On 08/08/2013 01:58 PM, Maximiliano Curia wrote:
Hi,
n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
From n_tty_set_room():
/*
* If we are doing input canonicalization, and there are no
* pending newlines, let characters through without limit, so
On 08/08/2013 01:58 PM, Maximiliano Curia wrote:
Hi,
n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
From n_tty_set_room():
/*
* If we are doing input canonicalization, and there are no
* pending newlines, let characters through without limit, so
On Sun, Aug 18, 2013 at 12:57 AM, Margarita Manterola
wrote:
> There were no replies to the previous mail asking for comments, and as
> far as I can see this has not been applied. I don't know who rjw is,
> could you be a bit more explicit, please?
"git grep rjw MAINTAINERS"
Rafael J. Wysocki
On Sun, Aug 18, 2013 at 12:57 AM, Margarita Manterola
margamanter...@gmail.com wrote:
There were no replies to the previous mail asking for comments, and as
far as I can see this has not been applied. I don't know who rjw is,
could you be a bit more explicit, please?
git grep rjw MAINTAINERS
Hi,
On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek wrote:
>> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
>> index 4bf0fc0..2ba7f4e 100644
>> --- a/drivers/tty/n_tty.c
>> +++ b/drivers/tty/n_tty.c
>> @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
>> *
Hi!
> > n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
>
> > From n_tty_set_room():
>
> > /*
> > * If we are doing input canonicalization, and there are no
> > * pending newlines, let characters through without limit, so
> > * that erase characters will be handled.
Hi!
n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
From n_tty_set_room():
/*
* If we are doing input canonicalization, and there are no
* pending newlines, let characters through without limit, so
* that erase characters will be handled. Other excess
Hi,
On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek pa...@ucw.cz wrote:
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 4bf0fc0..2ba7f4e 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
*
Hi,
> n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
> From n_tty_set_room():
> /*
>* If we are doing input canonicalization, and there are no
>* pending newlines, let characters through without limit, so
>* that erase characters will be handled. Other
Hi,
n_tty_set_room() in drivers/tty/n_tty.c (3.10 mainline)
From n_tty_set_room():
/*
* If we are doing input canonicalization, and there are no
* pending newlines, let characters through without limit, so
* that erase characters will be handled. Other excess
Please don't drop CCs.
[ +cc Margarita Manterola, Greg Kroah-Hartman, Jiri Slaby, linux-kernel ]
On 07/30/2013 08:41 AM, Maximiliano Curia wrote:
Peter Hurley wrote:
readline is fundamentally incompatible with an active writer.
This wasn't the case with older kernel versions. I don't see
Peter Hurley wrote:
> readline is fundamentally incompatible with an active writer.
This wasn't the case with older kernel versions. I don't see any POSIX
reference that claims user input could be lost setting termios so I think
this is a serious regression.
Also, consider the readline use
Peter Hurley wrote:
readline is fundamentally incompatible with an active writer.
This wasn't the case with older kernel versions. I don't see any POSIX
reference that claims user input could be lost setting termios so I think
this is a serious regression.
Also, consider the readline use
Please don't drop CCs.
[ +cc Margarita Manterola, Greg Kroah-Hartman, Jiri Slaby, linux-kernel ]
On 07/30/2013 08:41 AM, Maximiliano Curia wrote:
Peter Hurley wrote:
readline is fundamentally incompatible with an active writer.
This wasn't the case with older kernel versions. I don't see
On 07/25/2013 07:29 AM, Margarita Manterola wrote:
Hi,
The problem:
Large pastes (5k or more) into a readline enabled program fail when
running kernels larger than v2.6.31-rc5. "Fail" means that some lines
are incomplete. From v2.6.39-rc1 onwards, "some lines" become "almost
all lines after
Hi,
The problem:
Large pastes (5k or more) into a readline enabled program fail when
running kernels larger than v2.6.31-rc5. "Fail" means that some lines
are incomplete. From v2.6.39-rc1 onwards, "some lines" become "almost
all lines after the first 4k". This turns up at least in Fedora,
Hi,
The problem:
Large pastes (5k or more) into a readline enabled program fail when
running kernels larger than v2.6.31-rc5. Fail means that some lines
are incomplete. From v2.6.39-rc1 onwards, some lines become almost
all lines after the first 4k. This turns up at least in Fedora,
Debian,
On 07/25/2013 07:29 AM, Margarita Manterola wrote:
Hi,
The problem:
Large pastes (5k or more) into a readline enabled program fail when
running kernels larger than v2.6.31-rc5. Fail means that some lines
are incomplete. From v2.6.39-rc1 onwards, some lines become almost
all lines after the
62 matches
Mail list logo
