Fwd: sleeping in block device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



---------- Forwarded message ----------
From: Anand H. Krishnan <anandhkrishnan@xxxxxxxxx>
Date: Sep 7, 2006 12:31 PM
Subject: Re: sleeping in block device driver
To: Fawad Lateef <fawadlateef@xxxxxxxxx>


Hi,

> 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).

I think that you can sleep, provided
1) You release the request queue lock
2) You can accept the fact that because of your sleeping some other block device
   may get affected (kblockd workqueue...) which is not advisable..

Anand

Although in above example sbull_transfer is done in atomic context and
only doing memory transfer not the real IO operation. So you can do
sleep before or after transfering the data or simple use kmap and then
can go into sleep during transfer.

> char drivers can sleep and receive data fetched in an irq context, can
> I not do this for block drivers?
>

Sorry I won't able to understand your question, but I can say that you
can sleep in process context whether its char or block driver but if
you got/receive data in irq context either in block or char driver you
can sleep in that context rather can insert the data in a queue and
just return from irq context; later use queued data in process
context.

I hope this helps.

--
Fawad Lateef

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/



--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux