Date: Wed, 22 Jul 2009 08:37:49 +0200 From: Marc Loerner <marc.loerner@hob.de> To: freebsd-drivers@freebsd.org Subject: Re: Driver development question Message-ID: <200907220837.49615.marc.loerner@hob.de> In-Reply-To: <20090722000713.GZ49724@elvis.mu.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907211743.12667.jhb@freebsd.org> <20090722000713.GZ49724@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Mittwoch 22 Juli 2009 02:07:13 schrieb Alfred Perlstein: > * John Baldwin <jhb@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907220837.49615.marc.loerner>