On Tue, Oct 23, 2012 at 07:42:28PM +0000, Grant Edwards wrote:

On 2012-10-23, Greg KH [off-list ref] wrote:

quoted

On Tue, Oct 23, 2012 at 06:45:51PM +0000, Grant Edwards wrote:

quoted

FWIW, in some products we're planning that will require support for
various industrial serial protocols, I'm leaning towards abandoning
the tty driver approach and writing a stand-alone character device
driver.  The byte-stream oriented tty/line-discipline layer just
doesn't fit well when dealing with frame-oriented industrial protocols
that depend on things like 9th bit addressing and detecting
sub-millisecond inter-byte timeouts.  When I add in the lack of
long-term stability in the tty API it seems like it might not be such
a bad idea to give up trying to make the tty abstraction fit a use
case that's just nothing like a teletype.

What do you mean "lack of long-term stability"?  The userspace tty api
hasn't ever changed or broken.

I meant the in-kernel api.

quoted

Don't focus on in-kernel api,

It's my job to focus on the in-kernel api.

It's my job to ensure that you don't have to.  Why are you caring?  Are
you trying to keep drivers outside of the kernel tree?  If so, there's
nothing we can do, except point out what a bad idea that really is to
try to do.

quoted

that's always going to change, no matter what interface you choose to
use in the kernel.

Maybe it's just my perception, but the the tty API seems to change a
more than the plain character-device API.

Recently, yes.  But, once that churn is over, it should settle down.

Oh, and watch out, the "plain" character-device api is going to change
in the next year or so, I've been working on lots of fixups in that
area, and hope to publish something in a month or so if I get it cleaned
up.

My point is, all of the kernel changes, all the time, so don't use the
lack of change, or the rate of change, for a specific api, as any
indication that it will not change again in the future, possibly in very
drastic ways.

thanks,

greg k-h