Re: cdefpriv usage (was: bsd versus linux device drivers)

On Wed, Sep 10, 2008 at 11:07:31PM -0700, vehemens wrote:
> On Monday 08 September 2008 09:50:55 am vehemens wrote:
> > On Monday 08 September 2008 06:41:53 am Robert Watson wrote:
> > > On Mon, 8 Sep 2008, vehemens wrote:
> > > > On Monday 08 September 2008 03:04:15 am Kostik Belousov wrote:
> > > >> On Mon, Sep 08, 2008 at 02:02:00AM -0700, vehemens wrote:
> > > >>> In linux drivers, there is a one to one relationship to an open and a
> > > >>> calling argument structure called struct file.  It provides a private
> > > >>> data pointer that allows the driver to preserve unique state
> > > >>> information across other calls such as read/write/ioctl/mmap/close
> > > >>> etc.
> > > >>>
> > > >>> For bsd drivers, my understanding there is not an equivalent.  As a
> > > >>> result it is not possible to preserve different state information for
> > > >>> multiple opens by the same thread of the same device major/minor #'s.
> > > >>>
> > > >>> Is this correct, or did i miss something?
> > > >>
> > > >> There is devfs_{get,set}_cdevpriv() KPI. Still no manpage, I shall fix
> > > >> this ASAP.
> > > >
> > > > Just started looking at the firewire driver which has clone.  It looks
> > > > like it hooks into the event handler.
> > > >
> > > > Don't quite understand it all yet, so I'm going to look forward to that
> > > > man page.
> > >
> > > Many device drivers continue to use the old clone interface, but are
> > > gradually being converted over.  You can look at the definitions and list
> > > of converted drivers here:
> > >
> > >    http://fxr.watson.org/fxr/ident?im=bigexcerpts;i=devfs_set_cdevpriv
> > >
> > > Looking at some of the converted drivers, I find myself a bit worried by
> > > the extra error handling: in what situations do we expect that bpfioctl()
> > > might be called without its cdev-private data?
> >
> > Got it now.  Looks like the converted drivers are only in current, but the
> > KPI is in at least 7.x as well.
> 
> My first impression based on the modified drivers, was that I only needed to 
> add a get to open, and set's to ioctl, mmap, read, write, close etc.  Also 
> that the data release would occur after the close call via the function 
> provided to get.
I do not know whether this is an slip of keyboard, but most typically,
you need set in open, and get in the read/write/mmap.

> Don't have a problem with set, but some or all of the get's fail.   I see 
> lot's of error=2 in ioctl, and error=9 in mmap,  Going to instrument the code 
> next.  Any suggestions would be helpful.
> 
> On a side note, I had to first upgrade my 7.x system and was wondering if 
> there was a FreeBSD_version number for this feature?

I do not remember, and in fact I do not see a reason for bumping version
for this feature. In-tree drivers do not need the check, since they are
in _the_ tree. Moreover, the cdevpriv does not change existing KPI, it
only adds a bunch of functions. Increasing version for each KPI addition
is rather pointless, IMHO.

Also, see man(9) update at
http://people.freebsd.org/~kib/misc/man9.1.patch
that, among other items, contains start of the cdevpriv documentation.