Driver development question

[Marc Loerner]

Am Mittwoch 22 Juli 2009 02:07:13 schrieb Alfred Perlstein:
> * John Baldwin <jhb at freebsd.org> [090721 14:44] wrote:
> > On Tuesday 21 July 2009 2:34:21 am Marc Loerner wrote:
> > > Am Dienstag 21 Juli 2009 00:38:56 schrieb Sam Leffler:
> > > > John Baldwin wrote:
> > > > > On Friday 17 July 2009 11:10:17 am Chris Harrer wrote:
> > > > >> Hi All,
> > > > >>
> > > > >> I'm hoping someone can point me in the right direction...  I'm
> > > > >> developing a FreeBSD driver for a PCIe card.  The driver controls
> > > > >> a hardware device that has DRAM and various state information on
> > > > >> it.  I'm trying to mimic functionality I have for other OS support
> > > > >> such that I can dump memory and state information from the card to
> > > > >> a file I create from within my driver (kernel module).
> > > > >>
> > > > >> For example, in a Linux driver I use filp_open to create the dump
> > > > >> file (represented by fp), then use fp->f_op->write to put
> > > > >> information into the file.
> > > > >>
> > > > >> FreeBSD doesn't have filp_* API's.  I've tried searching for
> > > > >> example drivers and googling for file API's from kernel modules to
> > > > >> no avail. Can someone please offer some guidance as to how I might
> > > > >> proceed here?
> > > > >>
> > > > >> Thanks in advance and any insight would be most appreciated!
> > > > >
> > > > > You can look at sys/kern/kern_ktrace.c to see how the ktrace()
> > > > > system call creates a file.  I think in general you will wind up
> > > > > using NDINIT/namei() (to lookup the vnode for a pathname) and then
> > > > > vn_open() / vn_rdwr() / vn_close().
> > > >
> > > > man alq(9).
> > >
> > > Why not use kern_open, kern_close, kern_preadv, kern_pwritev?
> >
> > Those affect the state of the current process by opening a new file
> > descriptor, etc.  That is generally bad practice for a device driver to
> > be interfering with a process' state, and it will not work for kernel
> > threads. You can rather easily have userland open a file and then pass
> > the file descriptor to a driver which can then do operations on a file
> > directly.
>
> If the vnode operations are annoying to wrap ones head around, one
> could have the driver defer this this to a kernel resident process
> that the driver would create on attach.

So when action on a "pseudo" driver is requested via IOCTL from the same 
userspace-thread the above kern_* functions can be used for file-io?