On 9/7/06, Bahadir Balban <bahadir.balban@xxxxxxxxx> wrote:
On 9/7/06, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote:
> On 9/6/06, Bahadir Balban <bahadir.balban@xxxxxxxxx> wrote:
> >
> > In linux device drivers 3, block drivers chapter, for block device io
> > tranfers, a function is defined:
> >
> > int sbull_transfer_bio(struct sbull_dev *dev, struct bio *bio)
> > {
> > ...
> > bio_for_each_segment(bvec, bio, i) {
> > ...
> > __bio_kmap_atomic(...);
> > sbull_transfer(...);
> > __bio_kunmap_atomic(...);
> > ...
> > }
> > }
> >
> >
> > Here, the transfer is not done in process context, and
> > sbull_transfer() cannot sleep. How could I implement a sleeping
> > transfer?
> >
>
> The request function of block devices are called in process context
> and they can sleep (but end_io is called in interrupt context).
>
So do you mean in:
sbull_make_request()
{
sbull_transfer_bio();
bio_endio();
}
sbull_transfer_bio() can sleep? If so I didn't know that.
Ya, sbull_transfer_bio or sbull_make_request can sleep. Just think in
terms of actual block device: when device driver gets request it put
it-self into sleep (AFAIR might be on the page which currently it is
using) until it is woken up by the interrupt from real hardware device
that data is read/write and now driver can procede furthur. But in the
function called against interrupt from device (end_io) you are not
allowed __or__ at-least not recommended to sleep (through the way
mentioned by Anand).
Are you sure on this? Because in LDD3 page 475 says:
"... The invocation of the request function is entirely asynchronous
with respect to the actions of any user-space process. You cannot
assume that the kernel is running in the context of the process that
initiated the current request."
Perhaps this only applies to "bio_endio()" part of the request then?
Yes :) Although it sometimes might be in the context of file-system or
due to some other module/code __but__ that context is again a process
context not interrupt or any other context. (CMIIW)
--
Fawad Lateef
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
