Date: Thu, 11 Sep 2008 10:13:34 -0700 From: vehemens <vehemens@verizon.net> To: freebsd-current@freebsd.org Cc: Kostik Belousov <kostikbel@gmail.com>, Robert Watson <rwatson@freebsd.org> Subject: Re: cdefpriv usage (was: bsd versus linux device drivers) Message-ID: <200809111013.34194.vehemens@verizon.net> In-Reply-To: <20080911090449.GV39652@deviant.kiev.zoral.com.ua> References: <200809080202.00664.vehemens@verizon.net> <200809102307.31209.vehemens@verizon.net> <20080911090449.GV39652@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 11 September 2008 02:04:49 am Kostik Belousov wrote:
> 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.
Keyboard slip. Needed sleep :]
> > 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.
It was for an out of tree driver (i.e. drm).
> 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.
Looks like the ioctl get randomly fails with ENOENT.
Something else is going on with mmap get which fails with EBADF almost all of
the time..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809111013.34194.vehemens>