Bartlomiej Zolnierkiewicz wrote:
On Saturday 15 September 2007, Adrian Bunk wrote:
On Sat, Sep 15, 2007 at 11:44:59AM -0400, Jeff Garzik wrote:
Stefan Richter wrote:
Adrian Bunk wrote:
On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote:
Perfect is in the eye of the beholder. You would consequently have to
add such options into all menus which contain scsi low-level providers.
Kconfig is a user interface, so perfect is what is best for the
kconfig users.
Duplicate options with different names in different menus, but which all
do the same, --- is this the best for users?
I recognize it's a rhetorical question :) The answer is of course "no".
I hope the other participants of this thread register the severe
disinclination of the maintainers to change this stuff, as this is a
classic case of making a mountain out of a molehill[1].
For the -vast majority- of people configuring the kernel, this is not a
problem. Kernel people are -expected- to know what they're doing,
I doubt your claim is true since the vast majority of kconfig users
are most likely not kernel developers.
Yes, we shouldn't be needlessly raising the bar for power users.
In this case, no bar is being "raised," for any user.
@Greg:
Do you have any numbers regarding how your "Linux Kernel in a Nutshell"
is selling?
Even download numbers?
especially when switching from one major subsystem to another.
It's not only about switching, the same problems awaits people when
configuring a kernel for their hardware the first time.
*nods*
Therefore, all this is IMO wasted effort and hot air. There are far more
important issues to deal with.
Why don't we dump kconfig and write the .config by hand? ;-)
More seriously:
Yes, there are many other important issues in the kernel.
But not fixing kconfig UI problems doesn't fix these issues faster.
Agreed, and actually not fixing Kconfig UI problems will make the other
issues being fixed *slower* (because they result in *increased* workload
on developers' side).
Irrelevant in this case, because there is no increased workload on the
developer's side.
I have seen people running into problems because some required
option wasn't set - in the simplest cases things like IDE without DMA
because a help text wasn't updated when more hardware support was added
to a driver.
This is why nowadays IDE DMA support is automatically selected by IDE
host drivers that need it - a big relief for everybody.
Please don't take this any more off-topic than it already is.
IDE DMA option was vastly different. The options in question here
affect whether or not you have a block device to use -- something that
is immediately obviously and corrected quickly.
You might not care about the kconfig users.
But other people do.
...and even if their attempts/solutions may not be proper yet they should
not be discouraged to work on these problems...
There is no problem, in this case.
Otherwise, there would be more than a complaint or two per year.
Jeff
-
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]
