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: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200803120455.m2C4t4Aw010881@imap1.linux-foundation.org>
[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 ` + n_tty-loss-of-sync-following-a-buffer-overflow.patch added to -mm tree 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox