public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: Bill Huey <bhuey@lnxw.com>,
	dwalker@mvista.com, mingo@elte.hu, linux-kernel@vger.kernel.org,
	Esben Nielsen <simlo@phys.au.dk>
Subject: Re: FUSYN and RT
Date: Fri, 15 Apr 2005 21:38:30 -0400	[thread overview]
Message-ID: <1113615510.4294.113.camel@localhost.localdomain> (raw)
In-Reply-To: <16992.26700.512551.833614@sodium.jf.intel.com>

On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
> >>>>> Steven Rostedt <rostedt@goodmis.org> writes:
> >> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> 
> > I have to agree with Inaky too.  Fundamentally, PI is the same for
> > the system regardless of if the locks are user or kernel. I still
> > don't see the difference here.  But for other reasons, I feel that
> > the user lock should be a different structure from the kernel
> > lock. That's why I mentioned that it would be a good idea if Ingo
> > modulized the PI portion.  So that part would be the same for
> > both. If he doesn't have the time to do it, I'll do it :-) (Ingo,
> > all you need to do is ask.)
> 
> Can you qualify "different" here? I don't mean that they need to be
> interchangeable, but that they are esentially the same. Obviously the
> user cannot acces the kernel locks, but kernel locks are *used* to
> implement user space locks.
> 
> Back to my example before: in fusyn, a user space lock is a kernel
> space lock with a wrapper, that provides all that is necessary for
> doing the fast path and handling user-space specific issues.

I was actually thinking of just giving more flexibility to the user
locks, in case the application using them needed more information, for
debugging or whatever.  Honestly, I haven't looked at the fusyn code
yet, so I don't really know if there is a difference.  As I said, I
"feel" the user lock should be different. I really don't know if they
should.

So, to answer your question. Looking forward, I kind of see two
different structures for locking.  The rt_mutex and something that is
used by fusyn, then there being some common structure (or ops) that they
both use to implement the PI.  But the implementation of how the locks
work may as well be different. But this may not be the case, and there
still be two structures but the fusyn just contain a rt_mutex lock to do
the actual locking and the rest of the structure be used for showing
information or what not back up to user space. This stuff wouldn't be
necessary for the rt_mutex. We need to keep rt_mutex small since it is
used all over the place.

That's all I meant.


-- Steve



  reply	other threads:[~2005-04-16  1:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12 20:35 FUSYN and RT Perez-Gonzalez, Inaky
2005-04-12 23:11 ` Esben Nielsen
2005-04-13  0:27   ` Daniel Walker
2005-04-13 15:46     ` Steven Rostedt
2005-04-13 17:33       ` Daniel Walker
2005-04-13 18:38         ` Steven Rostedt
2005-04-15 22:51       ` Bill Huey
2005-04-15 23:37         ` Inaky Perez-Gonzalez
2005-04-16  1:14           ` Steven Rostedt
2005-04-16  1:20             ` Inaky Perez-Gonzalez
2005-04-16  1:38               ` Steven Rostedt [this message]
2005-04-16  1:53                 ` Inaky Perez-Gonzalez
2005-04-16  2:31                   ` Steven Rostedt
2005-04-16  3:00                     ` Sven Dietrich
2005-04-16  3:31                       ` Steven Rostedt
2005-04-16 13:05                       ` john cooper
2005-04-16 14:23                         ` Steven Rostedt
2005-04-16 14:51                           ` john cooper
2005-04-16  4:05                     ` Inaky Perez-Gonzalez
2005-04-18  5:30           ` Bill Huey
2005-04-18  7:37             ` Sven-Thorsten Dietrich
2005-04-18 11:33               ` Steven Rostedt
  -- strict thread matches above, loose matches on Subject: below --
2005-04-12 23:36 Perez-Gonzalez, Inaky
2005-04-12 23:09 Perez-Gonzalez, Inaky
2005-04-12 22:26 Perez-Gonzalez, Inaky
2005-04-12 22:33 ` Daniel Walker
2005-04-12 21:28 Perez-Gonzalez, Inaky
2005-04-12 19:35 Perez-Gonzalez, Inaky
2005-04-12 18:15 Daniel Walker
2005-04-12 20:29 ` Esben Nielsen
2005-04-12 22:15   ` Daniel Walker
2005-04-12 20:33 ` Joe Korty
2005-04-12 21:25   ` Daniel Walker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1113615510.4294.113.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=bhuey@lnxw.com \
    --cc=dwalker@mvista.com \
    --cc=inaky@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=simlo@phys.au.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox