>>>>> Steven Rostedt <[email protected]> writes:
> On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>> 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.
> ...
> 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.
I see--would the following fit your view?
This would be a kernel lock [from the fusyn patch, linux/fulock.h]:
/** A fulock, mutex usable from the kernel. */
struct fulock {
struct fuqueue fuqueue;
struct task_struct *owner;
unsigned flags;
struct plist olist_node;
};
This has an in kernel API so you can use it from modules or kernel
code.
And this would be kernel representation of a user space lock [from
linux/fulock_kernel.h]:
struct ufulock {
struct fulock fulock;
struct vlocator vlocator;
struct page *page;
};
This is exposed via system calls with fast-path as an option.
This is basically the kernel lock that provides the functionality and
an structure to keep a tab to where the thing is in user space (hash
queues a la futex). The ops are hidden in fulock.fuqueue.ops [fuqueue
is the waitqueue--just for reference, from linux/fuqueue.h].
/** A fuqueue, a prioritized wait queue usable from kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
--
Inaky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
