From: James Simmons <jsimmons@edgeglobal.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux-mm@kvack.org
Subject: Re: mm->mmap_sem
Date: Sat, 25 Sep 1999 21:19:59 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.10.9909252050590.25425-100000@imperial.edgeglobal.com> (raw)
In-Reply-To: <Pine.LNX.4.10.9909251905110.4120-100000@laser.random>
> On Sat, 25 Sep 1999, James Simmons wrote:
>
> >Is their any way to do cooperative locking kernel side between two memory
> >regions? If one is being access you can't physically access the other. I
> >just want to process to sleep not kill it if it attempts this.
>
> Ah ok.
To be exactly I'm trying to do cooperative locking between a mmaping of
the accel region of /dev/gfx and the framebuffer region of /dev/fb. I
notice that after mmapping the kernel can no long control access to the
memory regions. So I need to block any process from accessing the
framebuffer while the accel engine is running. Since many low end cards
lock if you access the framebuffer and accel engine at the same time.
Note /dev/fb and /dev/gfx both can be opened by different processes.
> So just add a spinlock in userspace. As test_and_set_bit works in
> userspace also the spinlock will work fine in userspace.
Really. Thats a good idea.
> Just make sure to always have the lock held before touching the memory
> region you want to serialize the accesses to.
>
> You need to add the locking into userspace.
Will this work for mmap regions as well?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-09-26 1:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-22 21:02 mm->mmap_sem James Simmons
1999-09-24 0:07 ` mm->mmap_sem Stephen C. Tweedie
1999-09-24 14:59 ` mm->mmap_sem James Simmons
1999-09-24 18:09 ` mm->mmap_sem Stephen C. Tweedie
1999-09-25 1:24 ` mm->mmap_sem James Simmons
1999-09-25 14:55 ` mm->mmap_sem Andrea Arcangeli
1999-09-25 16:50 ` mm->mmap_sem James Simmons
1999-09-25 17:06 ` mm->mmap_sem Andrea Arcangeli
1999-09-26 1:19 ` James Simmons [this message]
1999-09-26 14:07 ` mm->mmap_sem Andrea Arcangeli
1999-09-27 8:55 ` mm->mmap_sem Marcus Sundberg
1999-09-27 19:31 ` mm->mmap_sem James Simmons
1999-09-29 23:00 ` mm->mmap_sem Stephen C. Tweedie
1999-09-30 0:17 ` mm->mmap_sem James Simmons
1999-09-30 0:23 ` mm->mmap_sem Benjamin C.R. LaHaise
1999-09-30 14:59 ` mm->mmap_sem James Simmons
1999-09-30 15:15 ` mm->mmap_sem Benjamin C.R. LaHaise
1999-09-30 16:05 ` mm->mmap_sem James Simmons
1999-09-30 14:54 ` mm->mmap_sem Stephen C. Tweedie
1999-09-27 14:16 ` mm->mmap_sem Stephen C. Tweedie
1999-09-27 20:22 ` mm->mmap_sem James Simmons
1999-09-27 14:13 ` mm->mmap_sem Stephen C. Tweedie
1999-09-27 8:08 ` mm->mmap_sem Neil Conway
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=Pine.LNX.4.10.9909252050590.25425-100000@imperial.edgeglobal.com \
--to=jsimmons@edgeglobal.com \
--cc=andrea@suse.de \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
/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