Hello Rahul, First of all please don't do top-posting rather do bottom-posting. For more information search google.
On 10/19/06, Rahul Theraja <[EMAIL PROTECTED]> wrote: > Hello Shakthi Kannan, > > Thanks for the reply . > > > > > driver. I could not understand why the "sbd_request " is called even > though > > > i have given only one read call from user space file. > > > > Block device I/O transfer is done in blocks. > > > > > And also in the driver, in the function sbd_request() how does the > driver > > > get the parameters like sector, current_nr_sectors and buffer. > > > > VFS <-> SCSI <-> Block device? > > I think its VFS<->Buffer-Cache<->Block-Device and if drive is mounted then VFS<->FS<->Buffer-Cache<->Block-Device > > > i could move > > > furhter fastly. > > > > Fastly? IMHO, learning kernel development involves lot of patience. > > > > SK > > > Is it necessary to use kernel_thread() in block drivers. In drivers/block > loop.c i could see kernel_thread() being used but in floopy.c it is not > used. When is this kernel_thread() function is supposed to be used ? In the > sbd_device also the kernel_thread() is not used. > First in kernel-2.6.x its better to use kthread_*() rather than kernel_thread if threading is needed. Threading isn't necessary in any device until unless you need it. For example if your driver is emulating a device or performing IO directly then you don't need it, but if your driver is sending request to a device which generates interrupts after completing IO and you want to do some extra work after getting IO completion interrupt then you must use thread. As threads work in process-context, hence can do sleep and lengthy processing but interrupt-context shouldn't sleep or nor do long processing. For getting more understanding about different contexts like process, interrupt, softirqs contexts do search google. > Anyone please kindly clarify my doubts. > I hope you doubts are not clear. > Thanks in Advance > > -Rahul > -- Fawad Lateef _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
