Re: 2.6.11-rc1-mm1

[Karim Yaghmour]

Hello Roman,

Roman Zippel wrote:
> You don't think that's a little overkill?

I can see why you'd say this as a first impression, but really it isn't.

Here's a simple primer to this call's parameters:
channel_path, mode:
	Where does this appear in relayfs and what rights do
	user-space apps have over it (rwx).
bufsize, nbufs:
	Usually things have to be subdivided in sub-buffers to make
	both writing and reading simple. LTT uses this to allow,
	among other things, random trace access.
channel_flags, channel_callbacks:
	General channel management (should we write over unread data,
	is data delivered in bulk or in units, what granularity of
	timestamping is required, who should we call to initialize/
	finalize the content of a sub-buffer.) All of these are used
	by LTT, for example, in a number of ways.
start_reserve, end_reserve, rchan_start_reserve:
	Some subsystems, like LTT, need to be able to write some key
	data at sub-buffer boundaries. This is to specify how much
	space is required for said data.
resize_min, resize_max:
	Allow for dynamic resizing of buffer.
init_buf, init_buf_size:
	Is there an initial buffer containing some data that should
	be used to initialize the channel's content. If you're doing
	init-time tracing, for example, you need to have a pre-allocated
	static buffer that is copied to relayfs once relayfs is mounted.

As you can see, most of this is already used in one way or another by
LTT. The only thing LTT doesn't use is the dynamic resizing, but as was
said earlier in this thread, some people actually want to have this.
If it really came to it, we could drop this and resubmit when somebody
actually requests this, but my understanding is that the previous poster
did indeed indicate his need for this.

> BTW it should return a pointer not an id, at every further access it needs 
> to be looked up, killing the effects of any lockless mechanism.

Sounds reasonable. We will review this.

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/