Sharing device driver between kernel and user space

Jilles Tjoelker jilles at stack.nl
Fri Sep 23 19:06:28 UTC 2011


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


More information about the freebsd-hackers mailing list