Re: [PATCH] libata: fix broken Kconfig setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 17 Oct 2005, Jeff Garzik wrote:
> Linus Torvalds wrote:
>
> > Btw, if you want to have the _question_ always be y/n only, that's easy
> > enough to do, just make that one do
> > 
> > 	config SATA_MENU
> > 		bool "Want to see SATA drivers"
> > 		depends on SCSI != n
> > 
> > 	config SCSI_SATA
> > 		tristate
> > 		depends on SCSI && SATA_MENU
> > 		default y
> > 
> > and now you have a totally sensible setup, where the low-level drivers can
> > depend on something sane. 
> > I don't think it _buys_ you anything, but hey, at least it's logical. 
> 
> That's a reasonable solution.  I think it does buy you reduced user confusion.

The thing that worries me is that while the question may appear a bit more 
straightforward that way, I actually think it makes the end result _less_ 
so.

Let's say that I'm a clueless user, and I just don't realize that SATA 
depends on SCSI. After all, to a user, SATA sure as hell isn't SCSI, 
that's just an implementation detail inside the kernel.

So I've happened to say "m" to SCSI (for whatever reason - don't ask why 
users do strange things, but maybe I realize that USB storage needs it), 
and now I see the question for SATA. And I say "y".

And then I wonder why I can only select my sata drivers as modules. I 
didn't ask for SATA as a module, but they refuse to say "m".

Now, with SCSI_SATA as a straight M/n choice (or whatever), if I had SCSI 
as a module, at least I'll see at SATA selection time that I can only 
compile SATA drivers as modules. I might wonder at that time why, but I 
think it's less confusing there (and we could even mention it in the 
help-text).

I dunno. 

The _best_ choice as far as I can tell, is to just dis-associate SATA from 
SCSI entirely. Even if it's an implementation choice, we could make it a 
"select SCSI" instead of "depends on SCSI", so that from a _logical_ 
standpoint the user could just select SATA support without even knowing 
that the kernel happens to need the SCSI layer for it.

I think that's what USB storage ended up doing, exactly because it 
confused people too badly that they had to select SCSI in order to be able 
to say "I want USB disk supprt".

Of course, eventually I still hope that SATA could be done on the block 
layer instead of even depending on SCSI at all, but hey, that's a totally 
different issue.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux