Date: Wed, 10 Sep 2008 23:07:31 -0700 From: vehemens <vehemens@verizon.net> To: Robert Watson <rwatson@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org Subject: cdefpriv usage (was: bsd versus linux device drivers) Message-ID: <200809102307.31209.vehemens@verizon.net> In-Reply-To: <200809080950.55528.vehemens@verizon.net> References: <200809080202.00664.vehemens@verizon.net> <alpine.BSF.1.10.0809081434200.37494@fledge.watson.org> <200809080950.55528.vehemens@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809102307.31209.vehemens>