Date: Sun, 6 May 2007 13:28:49 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Antonino Ingargiola" <tritemio@gmail.com>
Cc: "Oliver Neukum" <oliver@neukum.org>, "Paul Fulghum" <paulkf@microgate.com>,
       linux-usb-users@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial
 possible bug]
Message-ID: <20070506132849.62e1e218@the-village.bc.nu>
In-Reply-To: <5486cca80705060029p433c6acar22faaeced2d7da37@mail.gmail.com>
References: <5486cca80705040138r6ac16e9bp77e4f6217720ea8@mail.gmail.com>
	<1178381287.3379.8.camel@x2>
	<20070505173647.544f6707@the-village.bc.nu>
	<200705052007.16742.oliver@neukum.org>
	<20070505225241.54a5d01d@the-village.bc.nu>
	<5486cca80705060029p433c6acar22faaeced2d7da37@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1121
Lines: 22

> However, whatever policy the buffer uses, the fundamental point it's that
> when I flush the input buffer I should be sure that each byte read
> after the flush is *new* (current) data and not old one. This because

Define "new" and "old" in this case. I don't believe you can give a
precise definition or that such a thing is physically possible.

> when the input stream can be stopped I can check that there are 0 byte
> in the buffer, but when the stream can't be stopped I must use a
> flush-and-sleep (multiple times) heuristic before I can read a single
> *reliable* byte.

The hardware itself has buffers at both ends of the link, there may be
buffers in modems, muxes and the like as well. We can certainly flush
input buffers in the kernel but it isn't clear we can always do so at the
hardware level, let alone at the remote end or buffers on devices on the
link.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/