Sharing device driver between kernel and user space

[geoffrey levand]

Thanks for your responses.
The one with open/close seems to be the most reasonable.


23 сентября 2011, 23:06 от Jilles Tjoelker <jilles at stack.nl>:
> On Wed, Sep 21, 2011 at 04:23:28PM +0200, Ivan Voras wrote:
> > On 21 September 2011 16:09, geoffrey levand <geoffrey.levand at mail.ru> wrote:
> > > Sure i can use the synchronization primitives, the problem is that
> > > the response to a request sent to PS3 VUART port is not available
> > > immediately, and i have to disallow kernel access to the PS3 VUART
> > > while i'm waiting for the response in user space. I send request
> > > with write syscall from user space and wait for response with read
> > > syscall. In the period of time between sending request and receiving
> > > response i could receive some other packets from VUART port, e.g.
> > > some kind of event notification,  i have to skip them. But kernel
> > > should not interfer until i get my response.  So i would need to
> > > lock out the kernel during this time. I think i found a good
> > > solution for this problem, just use a IOCTL which tells kernel
> > > device driver to stop processing kernel requests and events,
> > > something like SET_USER_MODE.  After that i can use it in user
> > > space.
> 
> Perhaps it is better to lock out kernel activity (and further opens)
> while userland has the device open.
> 
> In any case, a close should probably release the device (possibly after
> some sort of cleanup), so that a crash of the userland program does not
> necessitate a reboot before the device can be used again.
> 
> > Have you read sema(9)?
> 
> sema(9) is best avoided in new code. It is not used much in existing
> code, and it would be useful to be able to remove some day in order to
> reduce redundancy in the provided synchronization primitives.
> 
> Instead, see mutex(9) and condvar(9).
> 
> The implementation of sema(9) is not very optimized, using a mutex and a
> condition variable. (This is unlike the userland sem_post(3) and friends
> which only require a single atomic op in the uncontested case, except
> for named semaphores in 8.x and earlier.)
> 
> > Or if returning EBUSY is acceptable when the resource is in use by
> > $whatever, maybe you just need a boolean variable.
> 
> --
> Jilles Tjoelker
>