[lkml]   [1997]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: TTY changes to 2.1.65
    On Tue, 25 Nov 1997, Theodore Y. Ts'o wrote:

    > Date: Tue, 25 Nov 1997 22:58:59 +0100 (MET)
    > From: Tomasz Motylewski <>
    > 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 -

    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

     \ /
      Last update: 2005-03-22 13:40    [W:0.033 / U:55.256 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site