Driver development question

[Alfred Perlstein]

* John Baldwin <jhb at freebsd.org> [090722 06:21] wrote:
> On Tuesday 21 July 2009 8:07:13 pm Alfred Perlstein wrote:
> > * 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.
> 
> Kernel processes don't have file descriptor tables.

they do when you use an analogue to the old nfsd() syscall mechanism.

-- 
- Alfred Perlstein
VMOA #5191, 03 vmax, 92 gs500, ch250 - FreeBSD