From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Nick Craig-Wood <ncw@axis.demon.co.uk>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: what serial driver restructure is planned?
Date: Tue, 12 Feb 2002 11:38:37 +0100 (MET) [thread overview]
Message-ID: <200202121038.LAA02103@cave.bitwizard.nl> (raw)
In-Reply-To: <E16aOVf-00084P-00@the-village.bc.nu> from Alan Cox at "Feb 11, 2002 10:01:15 pm"
Alan Cox wrote:
> > Could we also have an interface to serial devices which bypass the tty
> > layer? Ie a /dev/ttyraw* which just speaks to the serial port without
> > going through the labyrinthine tty layers?
>
> You've got one
>
> > 9 times out of 10 when I reach for /dev/ttyS* that is all I want and
> > the tty layer is just wasteful and gets in the way of a conceptually
> > very simple device.
>
> The only bits of the tty layer being used in raw data passing is the same
> buffer management logic you would need anyway. In short - the perceived
> waste is simply not there
IMHO, the main waste is "in the drivers".
A serial driver restructuring should have a simple driver just be
"pass a character to the hardware" and "get a character from the
hardware" as well as "read/write modem control" register. (And the
driver would be requested to call a "modem status changed, please
ask me what the new status is").
That way you can build a working serial driver in under 100 lines of
code.
Now most advanced serial drivers would want to also provide "pass a
bunch of characters to the hardware" routine. By default that would
just be a routine that calls the output one char function
repeatedly. But hardware with a larger buffer can really benefit from
the block-move.
All "tty-layer" things should then move out of the driver. For
instance: no calling of "hangup" if the flags allow that: The driver
should report that DCD went down, and then something generic should in
one place decide wether or not to call "hangup" (i.e. send the hangup
signal).
If someone wires "DCD" to "TXD", and then uses the port in CLOCAL, we
will call the "DCD changed" function WAY too often. But that is just
stupid. Let's not create a stupid architecture because it will be
inefficient in a stupid case.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
next prev parent reply other threads:[~2002-02-12 10:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-06 18:32 what serial driver restructure is planned? Ed Vance
2002-02-07 10:21 ` Russell King - ARM Linux
2002-02-11 16:30 ` Nick Craig-Wood
2002-02-11 22:01 ` Alan Cox
2002-02-12 10:38 ` Rogier Wolff [this message]
2002-02-07 16:11 ` Greg KH
[not found] <194.2606a8e.299fb282@aol.com>
2002-02-16 17:06 ` 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=200202121038.LAA02103@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=ncw@axis.demon.co.uk \
/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