Is there some implicit locking of device methods?

[Kostik Belousov]

On Thu, Apr 28, 2011 at 12:14:49AM +0200, Bartosz Fabianowski wrote:
> Indeed, I may have mixed up terminology. Sorry about that. What I am 
> doing (or trying to do) is very simple:
> 
> There is a single physical USB device. I have a single device node 
> representing it. This device can be opened for reading, concurrently, 
> any number of times. Everyone who open()s the device can read() it at 
> their own pace. I implemented this by maintaining an individual queue of 
> incoming data for each open() call. This queue resides in cdevpriv.
> 
> So open() instantiates a queue and adds it to the driver's global list 
> of queues. Whenever a packet arrives from the device, it is placed in 
> all the queues (I have a linked list of all queues for that purpose). 
> When the open() is eventually followed by a close(), the cdevpriv 
> destructor removes the queue from the global list and frees its memory.
> 
> In addition to this, I need to start the USB transfer when the first 
> open() occurs and stop it again when the last close() occurs. I am doing 
> this by checking the length of the global list. When the list is 
> zero-length on open(), I start the transfer. When the list i zero-length 
> in the cdevpriv destructor, I stop the transfer.
> 
> I cannot see how else to achieve this behavior (other than device 
> cloning which I was using before but which is more complicated and 
> probably more error-prone). If I am doing something wrong and there is a 
> more correct way to do it, I would love to hear about it.

This is a strange architecture, esp. amusing is the kernel-mode
traffic multiplier. Without knowing the details, and really not wanting
to know it, I could make two suggestions out of thin air:

- use usermode daemon that multiplies traffic for all connected clients;

- or, implement a ring buffer that cyclically stores the received data,
  and keep only the current read pointer in the cdevpriv. You need to
  handle the overflow case (eq. to the stuck reader) somehow in the
  current scheme anyway. Reader may now read from its current read
  position in the buffer up to the fill point. If the buffer wrapped
  for the reader, it should get some error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110427/83f3187d/attachment.pgp