Thanks for your responses. The one with open/close seems to be the most reasonable.
23 сентября 2011, 23:06 от Jilles Tjoelker <[email protected]>: > On Wed, Sep 21, 2011 at 04:23:28PM +0200, Ivan Voras wrote: > > On 21 September 2011 16:09, geoffrey levand <[email protected]> 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 >
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
