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

[Jeff Garzik <jeff@garzik.org>]

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)