This is doable, certainly, but it can cause major delays, especially
if you expect bursty interrupts. I have been working on stuff that also
needs to write to disk (well, write to a socket, which ends up going to
disk once a userland process chews on it) data that i get off of an 
interrupt, but after hitting some pretty heavy performance problems with
a straightforward write out of the bottom half, i moved to keeping a 
queue of buffers and having a kernel thread flush them to the socket as
it gets the time to. it works much better. 
Also, yes, it is possible that you might have to block on the file i/o. 
that code was not designed to be run out of the bottom half, and blocking
or scheduling dont exist in there. you might run fine for a while, just 
lucky, but under moderate load, it will explode or wedge and be a pain in 
the ass to debug...

happy hacking,
isildur

On Tue, 4 Feb 2003, Paul Sommerhein wrote:

> Ok, this might not be feasible, but what I want to do is to write
> a 64kB chunk of data to the end of a disk file from within the
> network stack in the bottom half of the kernel (incoming data
> path, no process context).
> 
> Some assumptions
> 
>     o Not required to work with all filesystems, but need to work
>       with UFS/FFS.
>     o Only one writer (bottom half of kernel) and no readers (yet).
>     o The file has been opened for writing by a process which
>       we have a pointer to.
>     o The buffer cache should not be used (for writing).
>     o The 64kB chunk will (always) extend the file (appending).
>     o The file system has a 64kB block size.
>     o The maximum disk request is 64kB (is it?).
> 
> The idea is to allocate a buffer structure and point its data
> buffer pointer to my 64kB data chunk.  Then I initialize
> b_iodone to point to a function that will take care of the
> buffer when the write has completed.  The other members
> of the buffer structure is initalized to proper values.
> The buffer is then sent to the disk driver (VOP_STRATEGY?).
> 
> If I have understood things correctly, my main problem will be
> that some of the file system code might block, which I can't
> tolerate since I am in the bottom half of the kernel.  More
> specifically, I have a feeling that since I need to extend the
> file, the process of allocating a physical disk block might block.
> Is this feeling right?
> 
> Are there any other issues involved which may make this impossible?
> 
> Any pointers highly appreciated.
> 
> Best regards,
> Paul Sommerhein
> 
> PS
>     I am currently taking my first stumbling steps in kernel land,
>     so bear with me...
>