DragonFly project Kernel Related mail

Markus Pfeiffer | 17 Jul 2012 10:11

devfs_get/set_cdevpriv functions from FreeBSD

Dear all,
(I think in particular Matt and Alex H.)

while porting drivers from FreeBSD some of us have stumbled over the functions
devfs_get_cdevpriv and devfs_set_cdevpriv, which store some
per-open-filedescriptor information for some devices.

I looked into the FreeBSD code and the implementation seems weird to me since
they store the filedescriptor on syscall in their thread struct and the functions
rely on that hidden state.

Question is now: Should we have similar functionality (i.e. per open
filedescriptor "private" data) and if yes how to best implement that. I know
that AlexH had made some suggestion but I cannot find it in the IRC logs and
it would probably be more efficient doing this by mail. 

Markus
--

-- 
Markus Pfeiffer, University of St Andrews
email: markus.pfeiffer <at> morphism.de | xmpp: markus.pfeiffer <at> jabber.morphism.de

headers

Francois Tigeot | 17 Jul 2012 10:25

Re: devfs_get/set_cdevpriv functions from FreeBSD

Hi,

On Tue, Jul 17, 2012 at 08:11:13AM +0000, Markus Pfeiffer wrote:
> 
> while porting drivers from FreeBSD some of us have stumbled over the functions
> devfs_get_cdevpriv and devfs_set_cdevpriv, which store some
> per-open-filedescriptor information for some devices.
> 
> I looked into the FreeBSD code and the implementation seems weird to me since
> they store the filedescriptor on syscall in their thread struct and the functions
> rely on that hidden state.
> 
> Question is now: Should we have similar functionality (i.e. per open
> filedescriptor "private" data) and if yes how to best implement that. I know
> that AlexH had made some suggestion but I cannot find it in the IRC logs and
> it would probably be more efficient doing this by mail. 

I encountered the same family of functions while looking at recent FreeBSD DRM
code; since it was ported from Linux in the first place, I also looked at the
Linux equivalent functions, and they seemed much more sane.

Private data was directly accessible from the filedescriptor if I remember
correctly.

--

-- 
Francois Tigeot

headers

Alex Hornung | 18 Jul 2012 12:33

Re: devfs_get/set_cdevpriv functions from FreeBSD

On 17/07/12 09:11, Markus Pfeiffer wrote:
> Question is now: Should we have similar functionality (i.e. per 
> open filedescriptor "private" data) and if yes how to best 
> implement that. I know that AlexH had made some suggestion but I 
> cannot find it in the IRC logs and it would probably be more 
> efficient doing this by mail.

My original suggestion, which is straight forward to implement, is to
just store the fp in each of the devfs_fo_* operations somewhere (e.g.
curthread like FreeBSD, although that isn't all that nice), and then
clean it up on devfs_fo_close.

Having that, you can easily implement the rest to set up some list or
tree or whatever inside a  cdev that is also passed to the function.
the search key would then be the fp that you stored somewhere whilst
in devfs_fo_*.

HTH,
Alex

headers

Francois Tigeot | 18 Jul 2012 13:53

Re: devfs_get/set_cdevpriv functions from FreeBSD

On Tue, Jul 17, 2012 at 08:11:13AM +0000, Markus Pfeiffer wrote:
> 
> while porting drivers from FreeBSD some of us have stumbled over the functions
> devfs_get_cdevpriv and devfs_set_cdevpriv, which store some
> per-open-filedescriptor information for some devices.
> 
> I looked into the FreeBSD code and the implementation seems weird to me since
> they store the filedescriptor on syscall in their thread struct and the functions
> rely on that hidden state.
> 
> Question is now: Should we have similar functionality (i.e. per open
> filedescriptor "private" data) and if yes how to best implement that.

Have a look at our existing drm infrastructure; there is already some code
doing this (a direct replacement of the FreeBSD version).

--

-- 
Francois Tigeot