Re: kprintf - Linux

This is a discussion on Re: kprintf - Linux ; PL> I'm currently making my kernel fully preemtible and thus run PL> into trouble with kprintf. PL> PL> My kprintf will basically lock a specific terminal and then write PL> onto this terminal. PL> PL> The problem with this is ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: kprintf

  1. Re: kprintf

    PL> I'm currently making my kernel fully preemtible and thus run
    PL> into trouble with kprintf.
    PL>
    PL> My kprintf will basically lock a specific terminal and then write
    PL> onto this terminal.
    PL>
    PL> The problem with this is that it can't be used in environments where
    PL> a kprintf must not sleep (interrupt handlers for instance).
    PL>
    PL> So the big question is, what would a sane way to implement kprintf
    PL> be? Allocate a global buffer to simply copy kprintf data into and
    PL> then after an iret / thread switch flush the buffer? This would still
    PL> be error prone since messages could be missed due to not enough
    PL> buffer space being left.

    Welcome to *exactly* the problems that face printk() in Linux. Linux
    uses roughly the approach that you outlined. (The buffer is flushed
    when the task holding the console lock comes to unlock it.)

  2. Re: kprintf


    Jonathan de Boyne Pollard wrote:

    > Welcome to *exactly* the problems that face printk() in Linux. Linux
    > uses roughly the approach that you outlined. (The buffer is flushed
    > when the task holding the console lock comes to unlock it.)


    You generally want to rate-limit printk's anyway. Being able to produce
    more than 129Kb of output in a fraction of a second is no more useful
    than being able to produce 128Kb. So you can use a fixed-sized buffer
    that's drained by a service thread. If the buffer fills, drop messages
    on the floor. If the service thread dies, 128Kb later, you stop
    logging.

    Odds are you'll capture the most useful information. If you don't die,
    you'll get the beginnings of whatever storm hit you, which is most
    likely what you need to fix it. If you do die, you'll capture how you
    died rather than your unlimited death throes.

    DS


  3. Re: kprintf

    davids@webmaster.com wrote:
    > Jonathan de Boyne Pollard wrote:

    ....
    > You generally want to rate-limit printk's anyway. Being able to
    > produce more than 129Kb of output in a fraction of a second is no
    > more useful than being able to produce 128Kb. So you can use a
    > fixed-sized buffer that's drained by a service thread. If the buffer
    > fills, drop messages on the floor. If the service thread dies, 128Kb
    > later, you stop logging.


    If not in there already, add numbers to the messages to see where the lost
    were supposed to be and have a global counter for the lost messages.

    Alex


+ Reply to Thread