Driver development question

[Attilio Rao]

2009/7/29 Chris Harrer <cjharrer at comcast.net>:
> Warning LONG message below, I figured I'd give as much information as
> possible to try and help me along.
>
>
>> 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.
>
> Hi All,
>
> I'm hoping you can provide a bit more guidance here as I'm still struggling
> with this and I'm running out of ideas.  Again, what I want to do is, some
> event (interrupt from an intelligent PCIe card indicating it's "dead") will
> cause me to:
>
> 1) Open/create a file
> 2) write raw/random/non-patterned/variable sized data to the file
> 3) close/save the file
>
> from within my device driver.  To this point, I've tried several things
> using vn_open, vn_open_cred, alq_open and cutting/massaging the code from
> alq_open with no success.  I've done this from within the context of my
> interrupt handler as well as a timer (callout_init, callout_reset) thread as
> well as from a thread I create with kproc_create.  In each and every
> instance, I get the following crash:

I think there is an important thing to consider.
vnode handling is all consider a sleepable operation so you can't
cater this inside a callout handler. The usual way to do that is to
use a character device and specify an ioctl interface that gates such
requests.
Said that, it seems you alredy used a kthread for such operation in
some cases? can you share the complete code?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein