lkml.org 
[lkml]   [1998]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Writing driver for sync serial board
Date
From
Krzysztof Halasa wrote:
: Jan Kasprzak <kas@informatics.muni.cz> writes:
:
: [about a driver for (a)sync serial board]
: > The main question is how to structure the driver to allow these
: > modes. Should I register_netdev() three interfaces (rawip, sppp and hdlc)
: > for each channel I have, or should I have one net interface per channel
: > and switch modes on the fly (maybe via an ioctl() on the corresponding
: > character device).
:
: I've been hacking Riscom N2 drivers for some time, and I think it is best
: to have three interfaces per port, and while one is open - block the rest.
: That way you don't need to use any additional software - just ifconfig
: is enough.

I think I will abandon the raw-IP interface and use the way Alan
Cox used in its driver - what he has is in fact a support routines
for both sync PPP and Cisco HDLC including a SLARP keepalive support.
I just need (someone) to port the syncppp.c to the latest 2.1 kernel,
as this is the version I use for my development.

[...]
: I believe the hardware driver has to:
: - open/init the board
: - close the board
: - open a port (speed, options like clock source, etc)
: - close a port
: - send a frame (for example, a HDLC frame - queue it)
: - receive a frame (from internal queue)
: - get statistics?

This design will not allow the driver to work as a character device.
I have currently the following interface between the HW layer and the upper
layers:

- probe for the board[s], register_netdev() for each channel and
register_chrdev() for the driver.
- close the driver (cleanup_module()).
- queue the frame to the channel.

and three call-back routines which the upper layer can set for each channel:

- char *frame_received(int size) -- the hw layer calls this from the
interrupt routine. The upper layer should return a pre-allocated buffer
of a given size, the hw starts transfer to it. The upper layer can
return NULL telling the HW to reject/drop the frame.
- rx_done() - the frame has been received.
- tx_done() - the queued transmit has been finished (the upper layer can
for example set dev->tbusy to 0 or wake_up() the queue of writers
in chardev mode etc).

So configuring the channel of the sync serial board means only
to allocate a private structure for chardev, HDLC or PPP mode and sets
three pointers to the callback routines.

: There should be some serial core, and the hardware driver should register
: itself with it, like in case of sound drivers.

I am not sure how general this interface will need to be. There may be
some super-smart boards which could do a SLARP keepalive themselves,
or some dumb ones which even cannot do the start/end of frame marks.

: I've been thinking of (re)writing SDL driver that way, but got no time yet.

I think currently the best interface is the one Alan have in its
hostess_sv11 driver, so we should probably modify the other drivers to use it.
The only one thing I don't like on his interface is, that the driver
registers its own "hdlcX" netdev. I think there should be some
struct sppp_operations and the sppp/hdlc layer should register its own
interfaces. It looks very dirty to me when the hostess_sv11.c registers
the "hdlcX" interface (and even needs to try to get_dev("hdlcX") until
it founds the first unused "hdlcX" device :-| ). It should be
the similar way as the ethernet uses - ethernet low-level drivers
does not look for their own first free "ethX" name.
-Yenya

--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\ Czech Linux Homepage: http://www.linux.cz/ ///
If there are race conditions in programs fix them. The "my programs suck fix
something else" mentality leads you to things like Java. -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans