Benjamin Herrenschmidt writes:
> On Thu, 2005-05-19 at 10:09 -0400, Andrew Gallatin wrote:
> > Hado Hein writes:
> > > I want to implement a device interfacing api in /dev that is already
> > > done in linux.
> >
> > Bear in mind that the BSD /dev interface does not provide you with
> > any easy way to keep track of per-open information. Eg, there
> > is no file_ptr->private_data.
> >
> > The only easy way to do this is to have a whole slew of minors, allow
> > only one open per minor, and to lookup your per-open information based
> > on the minor number.
>
> I'm not specialist of FreeBSD at all, but what about file->f_data ?
The problem is that a BSD ioctl takes a detour through the vnode layer
on its way to the driver, and all you get is:
ioctl(dev_t dev, u_long cmd, caddr_t data, int fflag, struct proc *p);
>From there, there is no way back to the file pointer.
FreeBSD 5.x and newer has a device cloning mechanism now which is
horribly buggy & quite bizzare, but which at least allows you to
create a new device node on-demand each opener and hang per-open info
off that character device node. Eg, you ask to open /dev/foo0, and
the cloning code creates /dev/foo0.1 just for you. Then you can hang
stuff off of cdev->si_drv{1,2}.
Back before this existed in FreeBSD, I did a really nasty hack
involving creating a new vnode and overridding its f_ops in my
open call so that my driver's fo_ioctl was called rather than
the normal one (vn_ioctl I think). In order for all that to work,
you need to return a special value from open, which makes magic
things happen. I did all this in FreeBSD so as to support running
linux binaries.
I remember reading the source and thinking that this vnode-conjouring,
fo_ops replacing approach could work in MacOSX (this was before KPIs).
But since MacOSX doesn't support linux binaries, there was no point in
taking the risk, and so I just used the many-minors approach there.
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
