--- Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> 說： > crazyrushstar@xxxxxxxxxxxx wrote: > > --- Karen Shaeffer <shaeffer@xxxxxxxxxxxxxxx> 說： > >> On Tue, Sep 19, 2006 at 09:48:46PM -0600, Matthew > >> Wilcox wrote: > >>> Documentation/scsi/scsi_mid_low_api.txt was of > >>> immense help to me. > > This document is indeed essential for low-level > driver development. > However it doesn't (can't) tell you how to avoid > some types of deadlocks. > > Crazyrushstar, I can't give specific advise about > scsi_scan_host() since > the code I'm maintaining (sbp2) doesn't use it. > However I have some > basic suggestions: > > - Consider your driver a layer between Linux' SCSI > core (higher level) > and the interconnect software/firmware/hardware, > e.g. PCI layer (lower > level). Make sure that you first bring up the lower > level, then the > higher level. Vice versa, bring down the higher > level before the lower > level on driver shutdown. > > - AFAIU your driver and everything below it has to > be fully able to > transfer commands, data and status before it calls > scsi_scan_host(). > > - Also keep the layer paradigm in mind when you > design the locking in > your driver. Watch out for the host lock which the > SCSI core will use on > several occasions and which your driver may have to > use on some > occasions. (The low-level driver I'm maintaining > doesn't touch the host > lock.) A clearly layered design helps to avoid > deadlocks. > > - Don't use the scsi_block_requests()/ > scsi_unblock_requests() API. > (The code I'm maintaining is using these, and it is > a nightmare because > it easily leads into deadlocks. I will rework that > driver to not use > these calls anymore.) The scsi_block_requests()/ > scsi_unblock_requests() > API manipulates host state on a low level, > subverting the SCSI core's > assumptions about host/ target/ LU states. This and > similar > manipulations of host/ target/ LU state are better > _not_ done in a SCSI > low-level driver. > > ... > >> I also would purchase the applicable scsi > standards. > >> > >> http://www.t10.org/ > > The drafts at http://www.t10.org/ftp/t10/drafts/ may > suffice too, at > least to get started. > > ... > > I have google out a link > > > "http://www.mjmwired.net/kernel/Documentation/scsi/scsi_mid_low_api.txt"; > ... > > "Documentation/" is a subdirectory of the Linux > kernel source distribution. > > Another essential resource are of course the sources > themselves. Good > tools to browse the code are Cscope or KScope or > LXR: > http://free-electrons.com/community/kernel/lxr > > You certainly already read the sources in > include/scsi/. > -- > Stefan Richter > -=====-=-==- =--= =--== > http://arcgraph.de/sr/ > Now I have make my driver work well under a environment without a lun(This is a RAID card). After insmod , inquery(12H) , report lun(A0H) received 8 times. Syetem is alive. If I insmod after make a lun, system will hangup within 2 secends. All message printed by printk wont show so that I dont know where is wrong. I Use "tail -f /var/log/messages &" to observe kernel log. I have debug two days, but no more ideas for this situation. ___________________________________________________ 您的生活即時通 － 溝通、娛樂、生活、工作一次搞定！ http://messenger.yahoo.com.tw/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
