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