Re: kernelspace -> userspace communication

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Polling is, well, ugly. In my case it makes no real difference, but in the 
:future, it would be nice to have a way to move large amounts of data (for 
:profiling, say) to userspace. Maybe a special device interface (that would 
:allow blocking) to the ktr buffers or something custom made. Well, if I ever 
:have a need for that I'll ask again about what people think.

    Well, do you care how efficient it is?  There's nothing stopping you
    from opening a file with the fp_*() functions and writing your logging
    data to that :-).  This is just for debugging, right?

:BTW, do you think moving the tsc-specific bits in kern_ktr.c to platform/ 
:would be worthwhile? (I'm not volunteering to do it now, just asking for 
:future reference)

    I think no... the actual TSC access is via an inline (rdtsc()), which
    IS in platform/.  Either platforms support an equivalent inline or
    they don't.  The problem is that the KTR code can be called from
    anywhere... with spinlocks held, in crazy interrupt contexts... anywhere.
    We can't afford to call any normal clock functions from that code.

>     It would take maybe an hour for a good programmer to modify ktrdump to
:>     do that.  It isn't difficult at all.  I eagerly away your patch! :-)
:
:Is this the part where I'm supposed to present a patch and claim "It only took 
:me twenty minutes"? :-) Actually, I was looking into modifying ktrdump when I 
:stopped ("Wait. ktr wasn't designed for this, there must be a better way") 
:and sent the previous mail. I'll try and do it sometime in the next few days.
:
:Aggelos

    Heh.  It's up to you.  I don't think it's that bad.  ktrdump sorts and
    dumps the entire FIFO.  If you modify it to loop you can just cache the
    FIFO start indices and use those instead of the ones from kernel memory.
    So when you loop, it will only sort and dump the pieces that were added
    to the FIFO since the previous dump.

    I recommend using KTR if you need to be efficient.  If you don't need
    to be efficient then you can just use the fp_*() kernel API to open a
    file.  Note that the file will be opened/created with the process's
    creds, not root creds.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>