From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: locking a device for exclusive use by userspace process (or kernel thread)
Date: Wed, 4 Mar 2015 10:43:30 -0800 [thread overview]
Message-ID: <20150304184330.GA31830@kroah.com> (raw)
In-Reply-To: <1425494332.3069.43.camel@opteya.com>
On Wed, Mar 04, 2015 at 07:38:52PM +0100, 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.
That's not very descriptive, what _exact_ type of device is this? What
existing driver supports it? Pointers to code would be helpful.
> 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.
What type of program? What type of user/kernel interface are you using?
Why wouldn't a simple "only allow one userspace program to open the
device node" work?
> > 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.
Who asked you to do this in this specific manner? What root problem are
you trying to solve? Why not just prevent userspace from talking to the
device at the same time, you have control over this, right?
> 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.
Should be easy to do on the close/release path, why isn't that working?
Or a simple reference count would also work, if you lock it properly.
Again, pointers to code would be best.
thanks,
greg k-h
next prev parent reply other threads:[~2015-03-04 18:43 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 [this message]
2015-03-04 18:50 ` Malte Vesper
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=20150304184330.GA31830@kroah.com \
--to=greg@kroah.com \
--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).