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