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)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
