AHCI finds disks; no /dev/sd inodes bound?

AHCI finds disks; no /dev/sd inodes bound?

[Jon Watte]

I ran out of PATA ports, and figured I'd use the un-used SATA ports on
the motherboard of the current machine (Intel G33/ICH9 based) to
expand storage that has run out again (like storage usually does). I
shut down the machine, put in the disks, booted up, made sure the BIOS
said enhanced/AHCI mode, and gave it a spin. Unfortunately, while the
AHCI system sees the disks, they appear to not get mapped to any block
devices in /dev, so I can't actually partition and mount them. What am
I missing, to make the devices bind to (I assume) /dev/sda and
/dev/sdb, or similar? (They also don't bind to /dev/sgX).

I've tried to google for this particular problem, but because I'm not
using a specific distribution, all I'm getting is various information
about how to write SCSI subsystem modules, or how to use tools when
the device binding has already happened -- nothing about what makes
that happen, and what's missing on my machine to make it so. (I'm
assuming it's something I'm missing in my init scripts here -- but
that assumption could be wrong, too)

Here is the output from dmesg that has to do with AHCI (before it is
PATA output; after it is 1394 output).

ahci 0000:00:1f.2: version 2.2
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 22 (level, low) -> IRQ 19
ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 4 ports 3 Gbps 0x33 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pmp pio slum part
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci
scsi5 : ahci
ata1: SATA max UDMA/133 cmd 0xf8822900 ctl 0x00000000 bmdma 0x00000000 irq 221
ata2: SATA max UDMA/133 cmd 0xf8822980 ctl 0x00000000 bmdma 0x00000000 irq 221
ata3: DUMMY
ata4: DUMMY
ata5: SATA max UDMA/133 cmd 0xf8822b00 ctl 0x00000000 bmdma 0x00000000 irq 221
ata6: SATA max UDMA/133 cmd 0xf8822b80 ctl 0x00000000 bmdma 0x00000000 irq 221
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: ST3500630SV, 3.ACH, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-7: WDC WD5000ABYS-01TNA0, 12.01C01, max UDMA/133
ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata2.00: configured for UDMA/133
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access     ATA      ST3500630SV      3.AC PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access     ATA      WDC WD5000ABYS-0 12.0 PQ: 0 ANSI: 5


Here is the output of # ls -l /sys/bus/scsi/devices
total 0
lrwxrwxrwx    1 root     root            0 Jan  8 22:48 0:0:0:0 ->
../../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/
lrwxrwxrwx    1 root     root            0 Jan  8 22:48 1:0:0:0 ->
../../../devices/pci0000:00/0000:00: 1f.2/host1/target1:0:0/1:0:0:0/

And the output of # ls -l
/sys/devices/pci0000\:00/0000\:00\:1f.2/host0/target0\:0\:0/0\:0\:0\:0/
total 0
lrwxrwxrwx    1 root     root            0 Jan  8 22:48 bus ->
../../../../../../bus/scsi/
--w-------    1 root     root         4096 Jan  8 22:48 delete
-r--r--r--    1 root     root         4096 Jan  8 22:48 device_blocked
-r--r--r--    1 root     root         4096 Jan  8 22:48 iocounterbits
-r--r--r--    1 root     root         4096 Jan  8 22:48 iodone_cnt
-r--r--r--    1 root     root         4096 Jan  8 22:48 ioerr_cnt
-r--r--r--    1 root     root         4096 Jan  8 22:48 iorequest_cnt
-r--r--r--    1 root     root         4096 Jan  8 22:48 modalias
-r--r--r--    1 root     root         4096 Jan  8 22:48 model
drwxr-xr-x    2 root     root            0 Jan  8 22:28 power/
-rw-r--r--    1 root     root         4096 Jan  8 22:48 queue_depth
-r--r--r--    1 root     root         4096 Jan  8 22:48 queue_type
--w-------    1 root     root         4096 Jan  8 22:48 rescan
-r--r--r--    1 root     root         4096 Jan  8 22:48 rev
lrwxrwxrwx    1 root     root            0 Jan  8 22:48
scsi_device:0:0:0:0 -> ../../../../../../class/scsi_device/0:0:0:0/
-r--r--r--    1 root     root         4096 Jan  8 22:48 scsi_level
-rw-r--r--    1 root     root         4096 Jan  8 22:48 state
lrwxrwxrwx    1 root     root            0 Jan  8 22:48 subsystem ->
../../../../../../bus/scsi/
-rw-r--r--    1 root     root         4096 Jan  8 22:48 timeout
-r--r--r--    1 root     root         4096 Jan  8 22:48 type
-rw-r--r--    1 root     root         4096 Jan  8 22:48 uevent
-r--r--r--    1 root     root         4096 Jan  8 22:48 vendor


NOTE: there is no "dev" entry for this device, so there's apparently
no mapped inode in /dev.

I have been running a home server for about 10 years (it started out
as a Pentium 120). Back then, "distributions" weren't really all that
fancy. This server has undergone many hardware and software upgrades,
but only ever the minimum to make it work at each time. Currently,
it's running kernel 2.6.22, but /dev/ has inodes from the 2.2 or 2.4
days, and rc scripts are whatever I've cobbled together. There are a
myriad services on the machine, many of which family and friends
depend on, and I fear that trying to migrate it all (including a large
storage array) to some "cooked" distribution would take days and be
very disruptive.

Any help or pointers to self-help would be appreciated!

Cheers,

                   / h+

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

Re: AHCI finds disks; no /dev/sd inodes bound?

[Andi Kleen]

"Jon Watte" <jwatte@gmail.com> writes:
>
> Any help or pointers to self-help would be appreciated!

The usual mistake is to not enable CONFIG_BLK_DEV_SD

-Andi

Re: AHCI finds disks; no /dev/sd inodes bound?

[Jon Watte]

Yes, that turns out to be the case. Thanks for the quick sanity check!
I wonder if it's possible to magically turn that on when selecting
AHCI support in menuconfig? That way, it'd be harder for someone else
to make the same mistake.

Cheers,

        / h+


On Jan 9, 2008 8:45 AM, Andi Kleen <andi@firstfloor.org> wrote:
> "Jon Watte" <jwatte@gmail.com> writes:
> >
> > Any help or pointers to self-help would be appreciated!
>
> The usual mistake is to not enable CONFIG_BLK_DEV_SD
>
> -Andi
>



-- 

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.

Re: AHCI finds disks; no /dev/sd inodes bound?

[James Bottomley]

On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote:
> Yes, that turns out to be the case. Thanks for the quick sanity check!
> I wonder if it's possible to magically turn that on when selecting
> AHCI support in menuconfig? That way, it'd be harder for someone else
> to make the same mistake.

We've had several discussions on this.  However, AHCI is used in a lot
of systems for CD-ROM support only.  The resolution last time was to add
this to the help text for ATA:

	  If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
	  any other ATA device under Linux, say Y and make sure that you know
	  the name of your ATA host adapter (the card inside your computer
	  that "speaks" the ATA protocol, also called ATA controller),
	  because you will be asked for it.

	  NOTE: ATA enables basic SCSI support; *however*,
	  'SCSI disk support', 'SCSI tape support', or
	  'SCSI CDROM support' may also be needed,
	  depending on your hardware configuration.

The bottom line is that working out how to configure your own kernel is
really hard (even I haven't done it from scratch for ages ... I usually
steal a distro config as the basis for my choices).

> On Jan 9, 2008 8:45 AM, Andi Kleen <andi@firstfloor.org> wrote:
> > "Jon Watte" <jwatte@gmail.com> writes:
> > >
> > > Any help or pointers to self-help would be appreciated!
> >
> > The usual mistake is to not enable CONFIG_BLK_DEV_SD
> >
> > -Andi

James

Re: AHCI finds disks; no /dev/sd inodes bound?

[Andi Kleen]

On Wed, Jan 09, 2008 at 11:29:26AM -0600, James Bottomley wrote:
> 
> On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote:
> > Yes, that turns out to be the case. Thanks for the quick sanity check!
> > I wonder if it's possible to magically turn that on when selecting
> > AHCI support in menuconfig? That way, it'd be harder for someone else
> > to make the same mistake.
> 
> We've had several discussions on this.  However, AHCI is used in a lot
> of systems for CD-ROM support only.

Those systems (servers) typically have enough memory to tolerate a few
extra KB of code without problems.  In fact most PCs these days have.

-Andi

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 11:29:26AM -0600, James Bottomley wrote:
>> On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote:
>> > Yes, that turns out to be the case. Thanks for the quick sanity check!
>> > I wonder if it's possible to magically turn that on when selecting
>> > AHCI support in menuconfig? That way, it'd be harder for someone else
>> > to make the same mistake.
>> 
>> We've had several discussions on this.  However, AHCI is used in a lot
>> of systems for CD-ROM support only.
> 
> Those systems (servers) typically have enough memory to tolerate a few
> extra KB of code without problems.  In fact most PCs these days have.

It would be a stupid solution nevertheless.

(We also don't "select EXT3".)

There are other possible solutions.  For example the split of the SCSI
Kconfig menu which has been proposed some times before.  Provide one
menu for highlevel protocol-type options, and one menu devoted to SCSI
transports and interconnects.  This underlines the central role of the
SCSI midlayer and SCSI highlevel in the kernel, and makes it easier for
people to spot that they need the SCSI highlevel even for their non-SCSI
hardware.


menuconfig "SCSI command sets (for HDDs, CD/DVD-ROM/R/W, tapes,
scanners, and more)"
	tristate SCSI
	help
		This is for [alls sorts of] internal and external
		devices, [e.g. this and that].

		This option is also required for a variety of hardware
		which isn't actually SCSI hardware.  You especially need
		this option for [such and such common kinds of non-SCSI
		hardware whose drivers make use of the SCSI subsystem].

		If unsure, say Y.

(SCSI midlayer options follow)
(SCSI highlevel options follow)

endmenu

if SCSI
menuconfig "SCSI transports and interconnects"
	bool SCSI_LOWLEVEL
	help
		Most of the SCSI transport protocols and interconnect
		drivers are configured here.  Some SCSI transports
		live in other menus.  [obligatory SBP-2 reference]

(SCSI lowlevel options follow)

endmenu
endif SCSI


PS:
It seems only libata users have difficulties to configure SD correctly.
USB users apparently and FireWire users definitely never had that
problem.  The "select SCSI" in libata's Kconfig option is not of great
help with that issue and is misguided and unnecessary as well.
-- 
Stefan Richter
-=====-==--- ---= -=--=
http://arcgraph.de/sr/

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Stefan Richter wrote:
>>> On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote:
>>> > I wonder if it's possible to magically turn that on when selecting
>>> > AHCI support in menuconfig? That way, it'd be harder for someone else
>>> > to make the same mistake.

> (We also don't "select EXT3".)

Perhaps a better analogy:  Ethernet options don't automatically turn on
IP support.
-- 
Stefan Richter
-=====-==--- ---= -=--=
http://arcgraph.de/sr/

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Stefan Richter wrote:
> The "select SCSI" in libata's Kconfig option is not of great
> help with that issue and is misguided and unnecessary as well.

+comment "Serial and Parallel ATA need SCSI command sets"
+	depends on SCSI=n

 menuconfig ATA
 	tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
...
-	select SCSI
+	depends on SCSI
...
-	  NOTE: ATA enables basic SCSI support; *however*,
-	  'SCSI disk support', 'SCSI tape support', or
-	  'SCSI CDROM support' may also be needed,
-	  depending on your hardware configuration.
+	  NOTE: 'SCSI disk support', 'SCSI tape support', or
+	  'SCSI CDROM support' is also required if you have
+	  ATA disks, tapes, or CD/DVD-ROM/R/Ws respectively.
...

-- 
Stefan Richter
-=====-==--- ---= -=--=
http://arcgraph.de/sr/

Re: AHCI finds disks; no /dev/sd inodes bound?

[Jon Watte]

Stefan Richter wrote:
>> Those systems (servers) typically have enough memory to tolerate a few
>> extra KB of code without problems.  In fact most PCs these days have.
>>     
>
> It would be a stupid solution nevertheless.
>
> (We also don't "select EXT3".)
>   

It's not the prettiest solution, but it would reduce the number of 
"support incidents." And, after all, reducing the number of support 
incidents is the goal of usability.

Not selecting EXT3 is a little more understandable, because there are 
many options -- cramfs, xfs, reiserfs, etc, depending on target. 
However, the number of people who DO want SATA support but DO NOT want 
SD block device support is... uh.. anyone?

Solving the problem bigger and better, by factoring "SD" into a 
mid-level menu, and maybe calling it something non-SCSI, would probably 
be even better. And even more work.

OK, I'll go hide now and try not to fan any flames. And thanks again to 
Andi for nailing my problem right away!

Cheers,

          / h+

Re: AHCI finds disks; no /dev/sd inodes bound?

[Matthew Wilcox]

On Wed, Jan 09, 2008 at 12:36:26PM -0800, Jon Watte wrote:
> Stefan Richter wrote:
> >>Those systems (servers) typically have enough memory to tolerate a few
> >>extra KB of code without problems.  In fact most PCs these days have.
> >>    
> >
> >It would be a stupid solution nevertheless.
> >
> >(We also don't "select EXT3".)
> >  
> Not selecting EXT3 is a little more understandable, because there are 
> many options -- cramfs, xfs, reiserfs, etc, depending on target. 
> However, the number of people who DO want SATA support but DO NOT want 
> SD block device support is... uh.. anyone?
> 
> Solving the problem bigger and better, by factoring "SD" into a 
> mid-level menu, and maybe calling it something non-SCSI, would probably 
> be even better. And even more work.

OK, how about this?

config BLK_DEV_ATA_SD
	tristate "ATA disc support"
	select BLK_DEV_SD

config BLK_DEV_ATA_SR
	tristate "ATA CDROM support"
	select BLK_DEV_SR

Help text left as an exercise for the reader.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Matthew Wilcox wrote:
> OK, how about this?
> 
> config BLK_DEV_ATA_SD
> 	tristate "ATA disc support"
> 	select BLK_DEV_SD
> 
> config BLK_DEV_ATA_SR
> 	tristate "ATA CDROM support"
> 	select BLK_DEV_SR

It's probably OK for many uses.

However, this further obfuscates the fact that libata uses Linux' SCSI
midlayer and highlevel.  Which is a bad thing.  For example, there are
further configuration options in the SCSI menu which influence the SCSI
midlayer and highlevel, and therefore influence the software stack which
drives the ATA disks and ATA CD-ROMs.  Hence this change does not make
the configuration menu more logical.

> Help text left as an exercise for the reader.

A pro pos, the help texts and prompts for the SCSI midlayer and
highlevel options are... suboptimal.  At least as long as these help
texts and prompts aren't changed¹ to say what they really do, your
BLK_DEV_ATA_SD and BLK_DEV_ATA_SR are actually very nice to have.

-------
¹)  No patch attached.  I posted something a while ago.
-- 
Stefan Richter
-=====-==--- ---= -=--=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AHCI finds disks; no /dev/sd inodes bound?

[Andi Kleen]

On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote:
> Matthew Wilcox wrote:
> > OK, how about this?
> > 
> > config BLK_DEV_ATA_SD
> > 	tristate "ATA disc support"
> > 	select BLK_DEV_SD
> > 
> > config BLK_DEV_ATA_SR
> > 	tristate "ATA CDROM support"
> > 	select BLK_DEV_SR
> 
> It's probably OK for many uses.
> 
> However, this further obfuscates the fact that libata uses Linux' SCSI
> midlayer and highlevel.  Which is a bad thing.  For example, there are

People are not interested in how libata is implemented internally.
They just want their SATA interfaces to work.

Kconfig is also not an educational facility or high level
design description of the code, but a pragmatic tool to get the job
done.

> further configuration options in the SCSI menu which influence the SCSI
> midlayer and highlevel, and therefore influence the software stack which
> drives the ATA disks and ATA CD-ROMs.  Hence this change does not make
> the configuration menu more logical.

I think Matthew's patch with appropiate help texts is a good idea.

-Andi

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote:
>> However, this further obfuscates the fact that libata uses Linux' SCSI
>> midlayer and highlevel.  Which is a bad thing.  For example, there are
> 
> People are not interested in how libata is implemented internally.
> They just want their SATA interfaces to work.
> 
> Kconfig is also not an educational facility or high level
> design description of the code, but a pragmatic tool to get the job
> done.

I did not talk about education or design decription.  I did talk about
appropriately showing what the Kconfig options do.

Kconfig is the tool to configure the Linux build environment before
building the program.

In particular, we are talking about how to present the configuration of
the Linux ATA component, which happens
  - to have a build-time dependence on the Linux SCSI midlayer and
  - to be not very useful at runtime if certain Linux SCSI highlevel
    components aren't present as well.

The Kconfig menu layouts, prompts, and help texts are there to inform/
"educate"/ guide the user when configuring the build environment, with
the goal that he safely and efficiently gets to a working software
configuration.

If some "internals" of the implementation are not entirely invisible to
users at run-time, then we should provide information about them.  Or
change the implementation so that these internals become truly invisible
at runtime use, if that is preferable, all things considered.

Furthermore, people who use Kconfig are _not_ people who "just want
their SATA interfaces to work".  These are specifically people who need
to or want to create an own configuration before build time, for what
ever reason. /These/ are the people to which the Kconfig menus and texts
must be tailored for.

People who just want their SATA interfaces to work _and_ cannot or don't
want to spend time with configuring the kernel build environment can be
served to.  We give them ready-made .config files or kernels.


Or in short:

Setting BLK_DEV_SD=y does not mean "make my disk work".  It means
"enable building one of the program parts which are necessary to make my
disk work".  And however hard you try, you can't transform it to truly
take on the former meaning.  Therefore better stay true to the actual
meaning.
-- 
Stefan Richter
-=====-==--- ---= -=--=
http://arcgraph.de/sr/

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Stefan Richter wrote:
> The Kconfig menu layouts, prompts, and help texts are there to inform/
> "educate"/ guide the user when configuring the build environment, with
> the goal that he safely and efficiently gets to a working software
> configuration.

It might have been not entirely clear from my earlier postings, but I
(and others) actually made alternative suggestions how to improve the
menus.  Namely, split the SCSI menu and get to the following order of
prompts:

	"Do you have HDDs?"
	"(Then you need this option here, except in this and that very
	special case.)"

	"Do you have an IDE or SATA controller?"

	"I see your attention is beginning to slip, but let me ask one
	more thing --- do you have one of those SCSI controllers? No?
	Thought	so."

No need to use the buggy and conceptually problematic "select" keyword
anywhere.
-- 
Stefan Richter
-=====-==--- ---= -=-=-
http://arcgraph.de/sr/

Re: AHCI finds disks; no /dev/sd inodes bound?

[Andi Kleen]

On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote:
> Andi Kleen wrote:
> > On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote:
> >> However, this further obfuscates the fact that libata uses Linux' SCSI
> >> midlayer and highlevel.  Which is a bad thing.  For example, there are
> > 
> > People are not interested in how libata is implemented internally.
> > They just want their SATA interfaces to work.
> > 
> > Kconfig is also not an educational facility or high level
> > design description of the code, but a pragmatic tool to get the job
> > done.
> 
> I did not talk about education or design decription.  I did talk about
> appropriately showing what the Kconfig options do.

That's "high level design description"

-Andi

Re: AHCI finds disks; no /dev/sd inodes bound?

[Stefan Richter]

Andi Kleen wrote:
> On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote:
>>> Kconfig is also not an educational facility or high level
>>> design description of the code, but a pragmatic tool to get the job
>>> done.
>> I did not talk about education or design decription.  I did talk about
>> appropriately showing what the Kconfig options do.
> 
> That's "high level design description"

...of the Kconfig option.

But it's not a "design description of the code" which we are
configuring.  (Even though intelligent beings might be able to draw
conclusions about the code, based on what config options are offered.)
-- 
Stefan Richter
-=====-==--- ---= -=-=-
http://arcgraph.de/sr/

Re: AHCI finds disks; no /dev/sd inodes bound?

[Jeff Garzik]

Matthew Wilcox wrote:
> On Wed, Jan 09, 2008 at 12:36:26PM -0800, Jon Watte wrote:
>> Stefan Richter wrote:
>>>> Those systems (servers) typically have enough memory to tolerate a few
>>>> extra KB of code without problems.  In fact most PCs these days have.
>>>>    
>>> It would be a stupid solution nevertheless.
>>>
>>> (We also don't "select EXT3".)
>>>  
>> Not selecting EXT3 is a little more understandable, because there are 
>> many options -- cramfs, xfs, reiserfs, etc, depending on target. 
>> However, the number of people who DO want SATA support but DO NOT want 
>> SD block device support is... uh.. anyone?
>>
>> Solving the problem bigger and better, by factoring "SD" into a 
>> mid-level menu, and maybe calling it something non-SCSI, would probably 
>> be even better. And even more work.
> 
> OK, how about this?
> 
> config BLK_DEV_ATA_SD
> 	tristate "ATA disc support"
> 	select BLK_DEV_SD
> 
> config BLK_DEV_ATA_SR
> 	tristate "ATA CDROM support"
> 	select BLK_DEV_SR
> 
> Help text left as an exercise for the reader.

Speaking as one who strongly objects to CONFIG_ATA unconditionally 
selecting SD or SR...

I think you are on the right track.  IMO a more clean and future-proof 
solution would be

	config ATA_PROT_ATA
		select SD

	config ATA_PROT_ATAPI (or ATAPI_PROT)
		select SR

But that's just an example.  Maybe the choices could be ATA_DISK and 
ATA_EVERYTHING_ELSE.  :)  The main points are

* its not just CDROM support, but floppy/tape/etc. too for ATAPI

* do not include "sd" or "sr" in the config name, it should be more 
generic, because SCSI will eventually be an optional module for libata. 
  When libata talks to straight blkdev, we don't want this same problem 
to resurface!

	Jeff (very tired, so pardon any incoherence)