> o Beta Serial driver restructure (Russell King)
Regarding the above line from the 2.5 STATUS report, what is the nature of
the planned restructuring? I have a CompactPCI hot swap serial mux card
that I need to support with hot swap functionality on Linux. Has anybody
already worked on issues like locking port names to physical slots, etc.?
Any basic advice?
Thanks in
Ed Vance
Ed Vance [email protected]
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
On Wed, Feb 06, 2002 at 10:32:11AM -0800, Ed Vance wrote:
>
> > o Beta Serial driver restructure (Russell King)
>
> Regarding the above line from the 2.5 STATUS report, what is the nature of
> the planned restructuring? I have a CompactPCI hot swap serial mux card
> that I need to support with hot swap functionality on Linux. Has anybody
> already worked on issues like locking port names to physical slots, etc.?
> Any basic advice?
You can checkout a copy of the code - see http://www.arm.linux.org.uk/cvs
It basically started out by pulling 65K worth of the duplicated code out
of various serial drivers. Its currently moving towards allowing the
input layer to talk to serial devices (needed for things like iPAQ
keyboards and IrDA-based keyboards), as well as allowing things like
USB serial devices to use the core code. Some people would also like
to see a "serial major" where all serial devices live.
On Wed, Feb 06, 2002 at 10:32:11AM -0800, Ed Vance wrote:
> I have a CompactPCI hot swap serial mux card that I need to support
> with hot swap functionality on Linux. Has anybody already worked on
> issues like locking port names to physical slots, etc.? Any basic
> advice?
There is some CompactPCI hot swap controller code that was written by
MontaVista, but isn't in the main kernel tree right now. I was talking
with the author of it to move their code into the existing pci hotplug
structure that is in the kernel, but haven't heard back from them for a
while.
However, I don't think anyone has looked at device naming based on PCI
physical slots yet. I know some attempts have been done for physical
location in the USB tree, so some of that old code might be helpful.
The hardest thing you will probably have is getting the physical slot
name from your pci driver.
Hope this helps,
greg k-h
On Thu, Feb 07, 2002 at 10:21:44AM +0000, Russell King - ARM Linux wrote:
> It basically started out by pulling 65K worth of the duplicated code out
> of various serial drivers. Its currently moving towards allowing the
> input layer to talk to serial devices (needed for things like iPAQ
> keyboards and IrDA-based keyboards), as well as allowing things like
> USB serial devices to use the core code.
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?
This would need to keep some basic ioctls for changing baud rate etc.
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.
> Some people would also like to see a "serial major" where all serial
> devices live.
Gets my vote.
--
Nick Craig-Wood
[email protected]
> 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
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.
--
** [email protected] ** 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.
> The flip buffer and output tmp_buf logic is not particularly
> friendly to packetized serial data streams, which are normal
> with most synchronous serial communications or IP over
> asynchronous link setups -- especially when the
> serial interface chip understands PPP frames.
There I disagree with dumber devices
> The current TTY formalism is not particularly
> friendly to dial-on-demand synchronous WAN
> communications. It is not impossible that
> a /dev/ttyraw device, which could easily shift
> between asynchronous and synchronous modes,
> might be a better approach.
I think thats misunderstanding how to use the existing interfaces. If you
have an ioctl to switch the mode of your device, you can exist dually as
a network interface (DMA into skbuff, fire at network stack through generic
PPP or the cisco hdlc layer) and as a tty interface in async mode.
The byte by byte PPP code we currently have exists primarily for the normal
dumb or minimally intelligent devices. If your device is smaller you can
simply give it a dual personality. The Z85230 driver I wrote did
this although the generic 8530 async code never got ported into the final
device and released in that form.