cdefpriv usage (was: bsd versus linux device drivers)

[vehemens]

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.

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?