[lkml]   [2005]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.11-rc1-mm1
    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.020 / U:8.016 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site