RE: [patch] printk subsystems

[Perez-Gonzalez, Inaky]

> From: Tom Zanussi [mailto:[e-mail]]
> Perez-Gonzalez, Inaky writes:
>  > > From: Tom Zanussi [mailto:[e-mail]]
>  > >
>  > > In relayfs, the event can be generated directly into the space
>  > > reserved for it - in fact this is exactly what LTT does.  There
aren't
>  > > two separate steps, one 'generating' the event and another copying it
>  > > to the relayfs buffer, if that's what you mean.
>  >
>  > In this case, what happens if the user space, through mmap, copies
>  > while the message is half-baked (ie, from another CPU) ... won't it
>  > be inconsistent?
> 
> There's a count kept, per sub-buffer, that's updated after each write.
> If this count doesn't match the expected size of the sub-buffer, the
> reader can ignore the incomplete buffer and come back to it later.
> The count is maintained automatically by relay_write(); if you're
> writing directly into the channel as LTT does though, part of the task
> is to call relay_commit() after the write, which updates the count and
> maintains consistency.

Hmmm, scratch, scratch ... there is something I still don't get here. 
I am in lockless_commit() - for what you say, and what I read, I would 
then expect the length of the sub-buffer would be mapped to user space, 
so I can memcpy out of the mmaped area and then take only the part that
is guaranteed to be consistent. But the atomic_add() is done on the 
rchan->scheme.lockless.fillcount[buffer_number]. So, I don't see how
that count pops out to user space, as rchan->buf to rchan->buf + rchan->
alloc_size is what is mapped, and rchan is a kernel-only struct that
is not exposed through mmap().

Where is the Easter bunny I am missing? Would you mind to give a little bit
of pseudocode? I am trying to understand how to do this:

/* in userspace */

char *buf;
int fd; /* for the channel */
int log_fd; /* for permanent storage */

/* open, blah ... */

buf = mmap (... fd ... 1M ...);

if (new stuff is ready /* how to detect, select() on fd? */) {
	/* bring the data to safety, copy only what is consistent */
	real_size = /* or where do I get this from? */
	write (log_fd, buf, real_size);
}

And then, once I have this, next time I read I don't want to read
what I already did; I guess I can advance my buf pointer to 
buf+real_size, but then how do I wrap around - meaning, how do I
detect when do I have to wrap?

>  > Yes, you have to guarantee the existence of the event data structures
>  > (the 'struct kue', the embedded 'struct kue_user' and the event data
>  > itself); if they are embedded into another structure that will dissa-
>  > pear, you can choose to:
>  > ...
> 
> Well, kmalloc() seems like the most straightforward and convenient way
> of managing space for all these individual events, if not the most
> efficient.  Are you thinking that sub-allocating them out of a larger
> buffer might make more sense, for instance?  If so, I'd suggest
> relayfs for that. ;-) Just kidding, ...

Good try :) As I said somewhere else, that'd be up to the client. Wanna
use kmalloc()? or kmem_cache_alloc()? or something else? I guess it'd 
be convenient to provide a pre-implemented circular buffer thingie ready
to use.

I guess the suballocation makes sense when you have a fixed message size
and you want to optimize the allocation; for that matter, kmalloc is no
different to any other pool, as they are just pools of base-2 sizes. In
some other sense, you are doing the same in relayfs, managing kind of
an allocation pool, but not as flexible (and thus probably faster) because
the usage model doesn't pose as many requirements as the memory pools have.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)