From: Paul Fulghum <paulkf@microgate.com>
To: rupesh.sugathan@gmail.com
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
akpm@linux-foundation.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: + n_tty-loss-of-sync-following-a-buffer-overflow.patch added to -mm tree
Date: Wed, 12 Mar 2008 17:40:01 -0600 [thread overview]
Message-ID: <47D869D1.4040107@microgate.com> (raw)
In-Reply-To: <1205355283.8873.29.camel@estonia>
Rupesh Sugathan wrote:
> I have another suggestion to this subject. When the buffer oveflows in
> icaonon mode, it would be *best* if the application either gets a
> complete line or does not get it at all. On a buffer overflow, it would
> be good that the n_tty discard the whole line data in the buffer (part
> of which has overflown) and make more room in the buffer.
>
> Does it make sense to any of you?
I don't know if there is a standard behavior under
these conditions so it is hard to argue it should
be handled a particular way other than leaving the
device in a consistent and recoverable state.
I doubt there would be support for making such changes.
Making that decision in the kernel and
having an application depend on that non-portable
behavior does not make sense.
Given that a n_tty receive overflow is not possible in
the current kernel (though data can still be lost elsewhere),
I doubt even my patch merits inclusion.
--
Paul
prev parent reply other threads:[~2008-03-12 22:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 4:55 + n_tty-loss-of-sync-following-a-buffer-overflow.patch added to -mm tree akpm
[not found] ` <20080312102729.58956d2c@the-village.bc.nu>
[not found] ` <47D7F531.2070400@microgate.com>
[not found] ` <1205339539.8873.14.camel@estonia>
2008-03-12 17:39 ` Paul Fulghum
2008-03-12 21:01 ` Paul Fulghum
2008-03-12 20:54 ` Rupesh Sugathan
2008-03-12 23:40 ` Paul Fulghum [this message]
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=47D869D1.4040107@microgate.com \
--to=paulkf@microgate.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rupesh.sugathan@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.