cleanup of sd driver in lk2.5
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Douglas Gilbert
Christoph,
My major concern in this area is the hot unplugging of IDE and 1394 disks. The natural thing for them to do is callsd_detach()but from which context? ** Also the block subsystem could be just about to send a command to that device (I make the assumption ifsd_detach()is called any scsi packets "in flight" will not callsd_rw_intr()thereafter).
Quoted 4 lines
Data integrity on the hot unplugged device is obviously compromised, however fsck can take care of that later. The challenge is to make the sd driver robust enough not to die a horrible death ...
Hmm, okay - I missed some other users from interrupt context than just the error handling.
Quoted 5 lines
** are we sure that couldn't be an interrupt context? One thought that crossed my mind is that since all scsi hosts have a scsi_eh_<n> thread in 2.5 then some device attaches and detaches could be sent/queued through that thread.
Either this or through keventd is the way to go, IMHO.
Quoted 5 lines
While I am musing, does anyone know whether the driverfs structure might be useful to put in
Scsi_Hostobjects? It might standardize information about HBAs or, for pseudo adapters, what other protocol stack to visit for more information.
I think we want driverfs all through the scsi layer, and that includes Scsi_Host.
Quoted 3 lines · [email protected] said:
I noticed that James Bottomley has a BK archive. Perhaps this driver could be put in there so others can hack it. There are lots more things I would like to do/fix with this driver.
I think a bitkeeper tree would be a very good idea. Unfortunately, it can't be mine since it sits behind a firewall. However, the Bitmover project will give us a publicly accessible one on bkbits.net.
If no one else volunteers, I'll set up a linux-scsi.bkbits.net for us. Does anyone have any specific thoughts on the layout of the subprojects? For bitkeeper to be useful, you should have as many sub-projects as there are lines of development in the tree. The incredibly rough split I thought of would be:
scsi-midlayer - any changes to the midlayer alone
sd, st, sg - obvious
drivers - most drivers are single .c and .h files that don't change very much, so splitting them out only makes sense if they're being updated on a regular basis
<evolving drivers> - need more input on this one, which drivers need separate sub-projects, the sub projects can be owned by the various driver maintainers?
misc - everything else.
This can be refined later on, but it is useful to get the split reasonably correct first time around.
Administering a bkbits.net tree is quite a bit different from looking after your own bitkeeper tree, so if anyone else has experience in this area, now would be a good time to volunteer.
James