Hello, James. James Bottomley wrote: > On Fri, 2008-06-20 at 13:06 +0900, Tejun Heo wrote: >> Hello, all. >> >> This item was on TODO list for years now. People all agree that it's >> necessary but it always had relatively low priority probably because >> it's a bit difficult and isn't really necessary to make disks and >> optical drives work. >> >> Anyways, I think it's about time to take some action as SAS-ATA >> integration (Brian, sorry about staying so silent about this for long >> time, I was following the threads but couldn't really think of a quick >> solution) and other ATA specific things including link power >> management and bunch of other deferred ones due to lack of proper >> sysfs interface or high level driver (parallel probing, parallel >> resume). >> >> Currently, my plan is... >> >> * Move high level driver handling to request_queue. > > Actually, I already did quite a lot of that here: > > commit 7f9a6bc4e9d59e7fcf03ed23f60cd81ca5d80b65 > Author: James Bottomley <James.Bottomley@xxxxxxxxxxxx> > Date: Sat Aug 4 10:06:25 2007 -0500 > > [SCSI] move ULD attachment into the prep function > > But there's still more to be done. The way I was thinking of it was > some type of protocol label (as in a ULD spits out protocols, like SCSI > or ATA) and then passes them to a LLD which uses libraries (what libata > and the scsi mid layer become) to process them. That was what I was thinking too in a similar way PC commands are carried. There are things to think about tho like splitting single request to multiple translated commands. >> * Implement queue quiescing and other state management on request_queue. >> * Implement block_queue_group which... >> - Handles command scheduling. >> - Handles grouped queue quiescing and EH handling > > There's the beginnings of this in Jens' unmerged block timers work Great, thanks for the pointer. >> In the process, I'm planning to remove ata_host requirement and break >> down libata EH into actions and sequencers so that SAS can use them >> easily. >> >> The biggest problem is how to keep userland happy. hdX -> sdX >> transition was painful enough and I have a strong feeling that >> everyone will come after and hunt down us if we try something like sdX >> -> bdX now. :-) > > In theory mounting by label or ID should have fixed a lot of this. Now that all the distros and users went through it once, maybe it's easier second time around but I think it's best to minimize the chance of breakage. One transition was painful enough. > However, if we need to head off a revolt, the sdX allocation algorithm > can be placed into it's own module so both sd and a ULD ata driver could > use it ... Yeap, that was what I was thinking. Separating out sdX allocation algorithm and making it the disk device node allocation logic such that /dev/sdX are the universal disk nodes, which is 90% true these days anyway. > Could you, perhaps, make the port multipler visible in this as a new > device, a bit like we do today for SAS expanders? I was thinking about doing... ata_link/P:0/P:0 : 1st fan-out /P:1/P:1 : 2nd fan-out /P:2/P:2 : 3rd fan-out ... /P:15/P:15 : port multiplier which is pretty much the internal representation. Do you think there's need for a separate PMP level inbetween? >> The SCSI side of interface will remain as functional as now as it will >> go through the same libata SAT layer. > > Actually, surely we can mostly dump the SAT layer? libsas should be > made capable of taking ATA protocol packets straight from your ULD ATA > driver and sending them out. Maybe in a long long time but the SAT layer will need to stay there for compatibility for now. ie. programs which use lsscsi to locate ATA devices and using matching /dev/sgX to issue SAT commands should keep working. > I could see us still needing it as an optional component so we can send > SCSI SG_IO to ATA devices. And for compatibility. We can definitely make it optional. >> So, what do you guys think? > > I think the devil will be in the details, but that it certainly won't be > obvious until the conversion is actually tried. Alright, thanks for your comments. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
