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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
