> Date: Tue, 25 Nov 1997 22:58:59 +0100 (MET)
> From: Tomasz Motylewski <motyl@stan.chemie.unibas.ch>
>
> Is there any chance for supporting synchronous serial devices - I mean some
> way of passing "this is the end of the frame" and not waking the upper
> layers earlier ?
>
> Most of the time, people who are interested in using synchronous device
> drivers are interested in using these devices for networking
> applications --- i.e., X.25, Frame Relay, ISDN, etc. In those cases,
> you usually want to interface the synchronous device directly into the
> networking layer. There are in fact several synchoronous devices in the
> kernel which are done in exactly this way, and so it doesn't touch the
> tty code at all.
No, no, no ! I think it is broken - you end up writing 3 or 4 drivers for
each synchronous card (one per protocol). For non-intelligent cards the data
needs to go through LAPB module (X.25) or DLCI virtual devices (for FR) or
some other decapsulator/demultiplexer (like ppp.c). This is a common code for
all the dumb devices. So we need some library of synchronous protocol
drivers, accessed as standard network device drivers from the top and linked
to the low level drivers through some (undefined yet!) interface.
I hoped that when common TTY code is removed from the low level serial
drivers, there will be some common interface between them and the "mid layer"
created. And one elegant solution for synchronous networking is then
replacing the mid TTY layer by the mid synchronous protocol layers like LAPB,
DLCI itd.
So you take hardware driver capable of both sync/async comm. You bind it to
TTY - you get character device. You bind it to LAPB - you get device capable
of X.25 communication etc.
I need just a flexible interface and a one example of driver using it.
> I am thinking about the adding some kind of functionality where the PPP
> line discipline could inform the low-level device driver what the
> "framing character" is, and this information would be used to determine
> whether or not the line discpline should be woken up immediately, or
> deferred to the next timer tick. The idea here is to reduce the latency
And what about devices which already know the "EOF" and moreover compute the
checksum in the hardware ?
> of the PPP line discpline in the cheapest way possible. This will
> probably be used mostly by asynchronous devices, since for the reasons
> stated above, synchronous devices will probably be always directly wired
> into the networking stack.
Well, if one defines ETH_P_SYNC packet type and writes a handler which checks
if the device is currently running X.25 or FR or PPP or Cisco HDLC (just put
it into dev->if_port IF_PORT_X25 IF_PORT_FR ...) and then passes it through
appropiate filter it will work (mod some complications on sending packets -
solvable).
Once we are talking about this problem - I have started considering RT-Linux
and RT-FIFOs as the desired interface (BTW - they have TTY interface to the
user space now). It could be the solution to 1 Mbit/s with 16 byte FIFO on
the synchronous chip.
Best regards,
-- Tomasz Motylewski