Re: Relayfs question

[Karim Yaghmour]

Jan Engelhardt wrote:
> Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which 
> moves a lot of data (depends) to userspace. It uses a ring buffer of "fixed" 
> size (set at module load time). Apart from that relayfs could use a dynamic 
> sized ring buffer, I would not see any need to move it to relayfs, would you?

First, please note that the info on Opersys' site is out-of-date. While
it was relevant while we were still maintaining relayfs separately, it
has somewhat lost its relevance since we started posting the most up-to-
date code directly to LKML. For one thing, the dynamic resizing was
dropped very early in relayfs' inclusion review.

What relayfs does, and does very well, is move very large amounts of
data out of the kernel and make them available to user-space with very
little overhead. In the actual case of your tty logger, I've browsed
through the code briefly, and I think that with relayfs you should be
able to:
- Get rid of half the code:
  - No need to manage your own user/kernel-buffer boundary (Most of the
    code in uio_*()).
  - No need to do any buffer management at all.
- Get better performance out of your logging functions.
- Get per-cpu buffers for free.

Basically, all the transport code you are doing in the kernel side of
your logger would be taken care of by relayfs. And given that there are
a lot of people doing similar ad-hoc buffering code, it just makes
sense to have one well-tested yet generic mechanism. Have a look at
Documentation/filesystems/relayfs.txt for the API details.

On a separate yet related topic:
Looking closer at rpldev.c, I believe that you'll be able to get rid of
it entirely (or very close to) once I actually get the time to refactor
the tracing code in LTT to make it generic. What I intend to do is to
obsolete the need for functions like your kio_*, and make it all
automatically generated at build time (you'll still to add the
instrumentation, but won't need to hand-code the callbacks). This is
still on the top of my to-do list and I should be able to get to this
shortly.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@xxxxxxxxxxx || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/