locking a device for exclusive use by userspace process (or kernel thread)

[Malte Vesper]

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.
>