linux-kernel - Re: What still uses the block layer?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Oct 2007 13:55:07 -0700 (PDT)
From:	david@...g.hm
To:	Matthew Wilcox <matthew@....cx>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Rob Landley <rob@...dley.net>,
	David Newall <david@...idnewall.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Nick Piggin <piggin@...erone.com.au>
Subject: Re: What still uses the block layer?

On Tue, 16 Oct 2007, Matthew Wilcox wrote:

> On Tue, Oct 16, 2007 at 12:54:58PM -0700, david@...g.hm 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/