From: Greg KH <greg@kroah.com>
To: Grant Edwards <grant.b.edwards@gmail.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: New serial card development
Date: Tue, 23 Oct 2012 13:10:16 -0700 [thread overview]
Message-ID: <20121023201016.GA3408@kroah.com> (raw)
In-Reply-To: <k66rv4$4ir$1@ger.gmane.org>
On Tue, Oct 23, 2012 at 07:42:28PM +0000, Grant Edwards wrote:
> On 2012-10-23, Greg KH <greg@kroah.com> wrote:
> > On Tue, Oct 23, 2012 at 06:45:51PM +0000, Grant Edwards wrote:
> >
> >> 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.
>
> > 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.
> > 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
next prev parent reply other threads:[~2012-10-23 20:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-09 18:43 New serial card development Matt Schulte
2012-10-14 9:37 ` Theodore Ts'o
2012-10-15 19:08 ` Matt Schulte
2012-10-15 23:26 ` Alan Cox
2012-10-16 2:32 ` Theodore Ts'o
2012-10-17 20:24 ` Matt Schulte
2012-10-19 21:21 ` Theodore Ts'o
2012-10-23 16:27 ` Matt Schulte
2012-10-23 16:31 ` Matt Schulte
2012-10-23 18:38 ` Greg KH
2012-10-29 20:04 ` Matt Schulte
2012-10-31 21:55 ` Matt Schulte
2012-11-01 22:03 ` Matt Schulte
2012-11-01 22:26 ` Alan Cox
2012-11-02 18:47 ` Matt Schulte
2012-11-02 20:21 ` Alan Cox
2012-10-23 18:06 ` Grant Edwards
2012-10-23 18:26 ` Alan Cox
2012-10-23 18:45 ` Grant Edwards
2012-10-23 19:16 ` Greg KH
2012-10-23 19:42 ` Grant Edwards
2012-10-23 20:10 ` Greg KH [this message]
2012-10-23 19:24 ` Alan Cox
2012-10-23 19:48 ` Grant Edwards
2012-10-23 20:31 ` Theodore Ts'o
2012-10-23 20:41 ` Grant Edwards
[not found] ` <CAJp1Oe6k7NWqdbYkJnd787JiT55-wSbG+tX1tP7Cy-oPShdVaA@mail.gmail.com>
2012-10-17 20:23 ` Matt Schulte
2012-10-17 21:53 ` Alan Cox
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=20121023201016.GA3408@kroah.com \
--to=greg@kroah.com \
--cc=grant.b.edwards@gmail.com \
--cc=linux-serial@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).