[lkml]   [2002]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 3 Serial issues up for discussion
       From: Russell King <>
    Date: Mon, 29 Jul 2002 18:17:02 +0100

    d. we keep serial.h, make it 8250-compatible ports only, and change
    This is the simplest and least likely to break other code. On the
    other hand, we end up hauling the ISA table and struct old_serial_port
    into 2.6.

    My only suggestion here is that, whatever you do, if you keep
    serial.h rename it to serial8250.h or similar thanks :-)

    b. serial consoles. Each hardware driver handles its serial consoles
    by itself, and if you have two or more hardware drivers built in
    with serial console support, you need to be able to tell them apart
    with the console= kernel parameter.

    Again, this could be solvable if we have one "ttyS" view of everything
    (core.c would then be responsible for registering the console with
    printk.c and passing the various methods off to the relevant

    On many platforms we know exactly which serial port is for
    the console because this is set in some firmware variable.
    For others we could say "it's ttyS0 unless stated otherwise
    in console=" as one possible solution.

    Hey while we're on this topic. While converting over the sparc
    drivers I've come to the conclusion that the serial console write
    should be interrupt driven just like any other serial port TX. The
    con->write() algorithm in such a scheme would look something like:

    static void
    fooserial_console_write(struct console *con, const char *s,
    unsigned int count)
    struct uart_fooserial_port *up = CON_TO_UART(con);
    unsigned long flags;
    int i, true_count;

    true_count = count;
    for (i = count - 1; i >= 0; i--) {
    if (s[i] == '\n')

    spin_lock_irqsave(up, flags);
    poll_until_xmit_buffer_bytes_free(up, true_count);
    append_con_buffer_to_xmit_tail(up, s, count);
    spin_unlock_irqrestore(up, flags);

    The reason it is done with this "poll until enough space" mechanism
    is because we can't sleep.

    Upon further consideration this does have some problems. Because of
    the silly '\n' handling this means we have to make sure printk
    console output cannot give us more than 1/2 the xmit buffer size
    in a single write call else we could potentially never have enough
    space free to do the whole write. We could size the xmit buffer
    appropriately for console uart instances, using some value from
    the console layer, to solve this. Or we could make con->write()
    calls limit how much they give at one call. We could indicate this
    limit in con->write_max or similar.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.036 / U:3.428 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site