Re: What still uses the block layer?

From: david
Date: Tue Oct 16 2007 - 16:52:40 EST


On Tue, 16 Oct 2007, Matthew Wilcox wrote:

On Tue, Oct 16, 2007 at 12:54:58PM -0700, david@xxxxxxx wrote:
On Tue, 16 Oct 2007, Alan Cox wrote:
I wouldn't try dividing those by pata v sata. You'll cause all sorts of
problems in the process because of PATA-SATA and SATA-PATA bridges.

if you use a PATA-SATA bridge (IDE drive SATA controller), it would look
to the system like a SATA drive and be addressed and enumerated as SATA.

But you don't know where the bridge is. It might be on the drive's
board, it might be an explicit enclosure, or it might be on the
motherboard. Each of those scenarios is going to have a different user
expectation.

the only one of these that I would find unexpected would be the one on the motherboard.

why is this any different from the external enclosures? they have always appeared as the type of device that connects them to the motherboard, (and even with SCSI, there are some controllers that don't generate sdX devices)

the driver for the controller is what has historicly determined what the device appears as to the system. an example of this is the 3ware driver that is a SCSI drive but the drives attached to the card are IDE drives. another example is the I2O drivers (which give you access to the Raid array and to the individual drives, in different namespaces). while I may disagree with some of the selections that have been made (the 3ware has always seemed odd to me for example) it's pretty simple to figure out.

but in any case, historicly IDE (PATA) and SATA drives have been handled differently, IDE drives have had fixed device names based on how they are connected, SATA devices have had 'order found' device names from the SCSI heritige. mixing the two types into one namespace requires changing one or the other. while I would love to see SATA gain hardware path dependant names I'm not holding my breath, but I hate to loose the predictable nameing (even if the names change) for the IDE drives.

David Lang

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/