[lkml]   [2005]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: FUSYN and RT
    >>>>> Steven Rostedt <> writes:

    > On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
    >> >>>>> Steven Rostedt <> writes:
    >> I see--would the following fit your view?

    > I think it's time that I take a look at the fusyn code. I don't have
    > all the emails on this thread, could you point out to me where I can
    > see the latest fusyn patch. Thanks.

    There you have the a full patch against 2.6.10, against the previous
    stable release (2.3.1) and the patch broken up in parts (the first one
    001.msg has the index).

    You want 016.msg and 020.msg, the ones that implement fulocks (the
    mutexes) and user space fulocks.

    013.msg has all the priority change engine (along with the queues);
    __fuqueue_waiter_chprio() is the function.

    In the same page site, up a couple of levels, three is info on how to
    grab it from CVS. There is also the OLS 2004 stuff which explains
    things in detail.

    > It's getting late where I am, and I'm getting tired, so I'm a little
    > slow right now. Is what you are showing me here what is currently
    > in fusyn or a proposal with the merging of Ingo's rt_mutex? Reason
    > why I'm asking, is what's the difference between the owner here and
    > in fuqueue's spin_lock?

    This is all without taking into account Ingo's work (you could say it
    is kind of parallel/redundant/etc). In any case, to sum up w/ what
    Sven said, the spinlock would be a raw_spinlock_t when that makes it
    into the kernel. It just protects access to the fuqueue/fulock/ufulock

    >> This has an in kernel API so you can use it from modules or kernel
    >> code.
    >> ...

    > This above structure would represent the user space wrapper
    > structure that I meant with the fusyn structure containing the
    > rt_mutex lock. Right?


    > Also in the above, is the fuqueue_ops the ops we mentioned earlier
    > as the links into PI?

    Yes and no.

    Yes because the ops are there to be able to be able to do the kind of
    things that user space mutexes need done differently (look for the
    fu*_op_* functions--or fulock_ops and ufulock_ops).

    However, in the case of the PI handling--that is just priority change
    handling--the op is the same for both fulocks and user space fulocks.

    But the priority change handling is different for queues, so you need
    an op to distinguish.

    > Sorry about being totally ignorant here, but it's the end of the day
    > for me, and I'm starting to feel burnt out.

    That's when you do 'shutdown -h now' and go for a beer :)



    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-04-16 06:10    [W:0.025 / U:49.028 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site