From: malte.vesper@postgrad.manchester.ac.uk (Malte Vesper)
To: kernelnewbies@lists.kernelnewbies.org
Subject: locking a device for exclusive use by userspace process (or kernel thread)
Date: Wed, 04 Mar 2015 18:50:05 +0000 [thread overview]
Message-ID: <54F753DD.5080408@postgrad.manchester.ac.uk> (raw)
In-Reply-To: <1425494332.3069.43.camel@opteya.com>
Hi Greg, Hi Yann,
I have been actually more naive by implementing it this way (led on by
ldd3, page 176).
I have the issue for an FPGA board and reconfiguration.
Basically if a program has control of the FPGA it does want the FPGA do
its computations, without another program changing the design loaded
onto the FPGA.
For the time being I will settle on the user opening the device to be
smart enough to not duplicate the fd. But I think there are usecases for
the requested feature.
regards Malte
On 04/03/15 18:38, Yann Droneaud wrote:
> Hi Greg,
>
> Le mercredi 04 mars 2015 ? 10:11 -0800, Greg KH a ?crit :
>> On Wed, Mar 04, 2015 at 06:59:04PM +0100, Yann Droneaud wrote:
>>> Hi,
>>>
>>> I have a device and I have to write a driver that exposes the
>>> following three operations to kernel modules AND to userspace
>>> programs:
>> <snip>
>>
>> Why?
> I'm trying to improve the current driver for this device to allow the
> lock to be released when userspace program owning the lock is killed.
>
>> What type of device is this?
> It's a device with some kind of over complicated mailbox.
>
> A userspace program is supposed to feed the mailbox with multiple
> commands and no other userspace program should be allowed to play with
> the device during that time.
>
>> And who is asking you to do this homework assignment?
>>
> It's not a homework assignment. It's not even something a little penguin
> ask me to do.
>
> I was so sure I could map the semaphore sematics to open() and close()
> and use that file descriptor to represent the lock that I feel terribly
> sorry for not being able to do so.
>
> (At one point I felt like I was fighting against 40 years of Unix, and
> such a fight is not going to be won by myself :)
>
> So I'm back to step 0 and looking for a way to be able to release a
> lock in case of a userspace program is killed.
>
>> good luck,
>>
> Thanks :)
>
> Regards.
>
prev parent reply other threads:[~2015-03-04 18:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 17:59 locking a device for exclusive use by userspace process (or kernel thread) Yann Droneaud
2015-03-04 18:11 ` Greg KH
2015-03-04 18:38 ` Yann Droneaud
2015-03-04 18:43 ` Greg KH
2015-03-04 18:50 ` Malte Vesper [this message]
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=54F753DD.5080408@postgrad.manchester.ac.uk \
--to=malte.vesper@postgrad.manchester.ac.uk \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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;
as well as URLs for NNTP newsgroup(s).