Re: 2.6.11-rc1-mm1

[Andi Kleen <ak@muc.de>]

On Fri, Jan 14, 2005 at 02:58:38PM -0800, Tim Bird 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.

This is a strong cue that they are unneeded. 

> > 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?

Just make it a global single define in the source.

> 
> > 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.

I think all for which not an clear need is demonstrated should
be removed. If there is a real need it can be still readded later.
But in the current form it is far too complicated and too fat.

> 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).

No, no, it far less APIs not more. 

-Andi