Messages in this thread | | | From | Tom Zanussi <> | Date | Tue, 22 Apr 2003 22:58:21 -0500 | Subject | RE: [patch] printk subsystems |
| |
Perez-Gonzalez, Inaky writes: > > > From: Tom Zanussi [mailto:zanussi@us.ibm.com] > > Perez-Gonzalez, Inaky writes: > > > > From: Tom Zanussi [mailto:zanussi@us.ibm.com] > > > > > > > > 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(). >
It 'pops' out to user space through some protocol defined between a relayfs kernel client and the user space program. relayfs doesn't say anything about the protocol, but does provide the kernel client enough information about the state of the channel via relay_info(), which supplies among other things (these aren't the real names, they're changed here to make things maybe a little clearer):
n_subbufs - number of sub-buffers subbuf_size - size of each sub-bufer subbuf_complete[] - array of booleans basically the result of fillcount[subbuf_no] == subbuf_size subbufs_produced - by the channel subbufs_consumed - by userspace client, maybe
This is enough information for a userspace client to figure out what to log. How it gets there and when is up to the client. For instance, the kernel client could send a signal whenever a sub-buffer is full (which it's notified of, if it chooses to be, by a delivery callback). The user client could then do something like
buf = mmap(fd, n_bufs * bufsize); /* whole channel is mapped */
sighandler() { get_channel_info_from_kernel(&info); /* ioctl/procfs/sysfs/... */ subbufs_ready = subbufs_produced - subbufs_consumed; for(i=0; i<subbufs_ready; i++) { subbuf_no = (subbufs_consumed + i) % n_subbufs; if(!buffer_complete[subbuf_no]) break; /* Try again next sig */ write(log_fd, buf + subbufno * subbuf_size, subbuf_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? >
Wrapping is taken care of automatically in the above code.
-- Regards,
Tom Zanussi <zanussi@us.ibm.com> IBM Linux Technology Center/RAS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |