Re: 2.6.11-rc1-mm1

[Tim Bird <tim.bird@am.sony.com>]

Karim Yaghmour wrote:
> Roman Zippel wrote: 
>>You don't think that's a little overkill?
>
>Based on the descriptions below, I think Roman is right.  There's
too much going on here for the average user.  I haven't looked closely,
but some of the stuff seems to be for esoteric use cases.  There are
two ways to approach it:
 - add a simplified API for the most common usage
 - strip out the stuff that's not really needed, and figure out
 workarounds for things (like tracing initialization) that need
 special assistance.

Some of these options (e.g. bufsize) are available to the user
via tracedaemon. I can honestly say I haven't got a clue what
to use for some of them, and so always leave them at defaults.

> 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.
Could these be simplified to a few enumerated modes?

> channel_flags, channel_callbacks:
> start_reserve, end_reserve, rchan_start_reserve:
> resize_min, resize_max:
> init_buf, init_buf_size:

It seems like you could remove these from relay_open() and move them to
get()/set() operations if you wanted to simplify the open API.
Or, you could create other (separate) APIs to pre-fill the buffer or
reserve space.  Do you want me to take a look at this and propose
some specific changes?  (I won't get to this until Monday, though).

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================