On 29/05/2015 15:37, Konstantin Belousov wrote:
> On Fri, May 29, 2015 at 02:24:14PM +0200, Luigi Rizzo wrote:
>> in the kernel module for netmap we need to store some
>> private data associated to each open netmap file descriptor.
>> Our current design uses devfs_set_cdevpriv() during the open()
>> handler, but for some reason a subsequent devfs_get_cdevpriv(p)
>> returns *p = NULL in additional threads created by the process
>> that did the open().
>> The manpage devfs_set_cdevpriv() does not mention threads,
>> and so i am a bit puzzled why the cdevpriv is only good
>> for the original thread.
> Probably, due to a bug, and the bug is more likely in the consumer code,
> than in cdevpriv. The cdevpriv requires the current file context, i.e.
> you should be in the context of the syscall which is operating on the
> file, to get the file related private data.
> If you believe that the bug is in cdevpriv interface, please provide the
> minimal example to demonstrate the issue.
I know of one case where ZFS driver has to play tricks with
devfs_get_cdevpriv(), please see zfs_onexit_fd_hold().
>> In the linux version 'struct file' has a "private_data" field
>> that we use for that purpose, and remains valid on all threads.
>> i wonder if there is something similar we can use in FreeBSD.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"