Re: [PATCH] libata: fix broken Kconfig setup

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

 



On Wed, 19 Oct 2005, Alistair John Strachan wrote:

> On Monday 17 October 2005 18:25, Linus Torvalds wrote:
> > 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).
> >
> [snip]
>
> Pretty much this exact thing happened to me. SATA=y when SCSI=y, then I
> selected my mainboard's SATA chipset (NFORCE=y), then a few kernels later I
> went back to set SCSI=m (I can't remember the rationale, something to do with
> udev and me thinking I didn't need to compile SCSI into the kernel).
>
> Of course, without asking me, this changed my SATA chipset driver to a module,
> and the resulting kernel wouldn't get to init (because I was attempting to
> boot from a disc on the SATA controller).
>
> This particular issue is perhaps more difficult to resolve, but I think this
> illustrates that a conceptual link between SCSI and SATA is a bad idea at the
> KConfig level (even if, within the kernel, SATA depends on parts of SCSI).

I agree and it seems that Jeff expects to change that.
I think that what I said (or I guess I "asked") here makes sense:
  http://marc.theaimsgroup.com/?l=linux-kernel&m=112839490116475&w=2

-- 
~Randy
-
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