Messages in this thread | | | Date | Sat, 13 Sep 2003 17:27:23 -0400 | From | Jeff Garzik <> | Subject | Re: 2.7 block ramblings (was Re: DMA for ide-scsi?) |
| |
On Sat, Sep 13, 2003 at 03:16:09PM -0500, James Bottomley wrote: > > Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles > and SCSI cdbs to a device. (for the uninitiated, this is lower level > than block devices / cdrom devices / etc.) > > ... AF_BLOCK is not out of the question ;-) > > > Well, I think the main issue to doing this is one of layering. What > SAM-3 did for SCSI was essentially give us a 3 layer stack which the > kernel represents as the upper, the mid and the lower layers (Note, > these layers are subdividable too). > > For SCSI commands, queuecommand() is a natural handoff point from the > mid to lower layer representing a pure scsi command with no transport > dependent details. > > For ATA, a task file does contain transport dependent knowledge, thus it > should enter the stack at a slightly lower level (and a level which the > current SCSI model doesn't even represent).
This is a good point, and I admit I don't have a good response.
On one hand, the current kernel interface presented to userland is the same for ATA and SCSI: "an ioctl, which sends packet to device" So from the standpoint of the userland ABI, that rebuts layering to a certain extent. We even have ioctls in today's ATA layer to send SCSI CDBs to ATA devices! ;-)
So from that angle, it all looks like a packet to me. Or struct request, shall I say. or skb. after a while they are all the same to me...
> Thus, the two ways of approaching this would seem to be either to derive > somehow a way of removing the transport dependence from the taskfile (a > sort of Task CDB for ATA), or redo the driver model stack to subdivide > the current low level drivers correctly. I think the latter will > probably be more productive, particularly if the subdivision is made > optional (and thus wouldn't affect most of the drivers currently in the > tree). Even in SCSI, there are certain register based SCSI Parallel > cards that would benefit from being driven at the same level as a task > file.
"the latter" is what I'm shooting for, with /dev/disk. Or maybe a better moniker is storage API. I think that parallels a theme I am pursuing in 2.7:
Make the low-level driver interface for ATA devices, RAID devices like cciss, etc. look strikingly similar to the SCSI low-level driver interface. At that point we call it the "storage LLD interface". This would IMO encompass the low-level driver subdivision you describe.
Ideally an ata/scsi/raid driver shouldn't be doing much more than h/w queue processing, and some hooks for unusual events like power management or h/w-specific device enumeration.
Overall I'd like to get "low level drivers" at pretty much the same level. ATA and SCSI drivers would be fairly small, with a lot of their functionality handled by helper functions. RAID drivers would be largers.
Another thorny tangent to throw out there:
IMO, we need to move users from a [probe-]order-based device and bus enumeration to some system based on unique ids. I'm of the opinion that _both_ block devices and filesystems need some sort of GUID. Luckily, a lot of blkdevs/fs's are already there.
If you look at current usage out there, order isn't _terribly_ important given today's tools (such as LABEL=). More important IMO is figuring out which spindle is your boot disk, and which is your root disk. Red Hat handles root disks by doing LABEL= from initrd. But discovering the boot disk is still largely an unsolved problem AFAIK...
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |