Gentlemen,
I have a tale to tell you. It is, I'm afraid, a little long, but it contains
within it a couple of messages that I really think need to be communicated from
us troops in the trenches up to you Generals of Kernel Hacking. I hope you'll
indulge me for a few minutes.
This past week, it was decided that the family P1-233 based Linux box (a RH5
box that had been upgraded through RH7.2) was no longer suitable for use as
a desktop workstation, and a replacement was in order. To that end, the following
system was specced out, ordered, and assembled:
- Asus A7V8X motherboard (10/100 onboard LAN, ATA 133, onboard sound, no RAID,
no Serial ATA)
- 512 Mb of 333MHz RAM
- Athlon 2100+
- Maxtor ATA133, 7200 RPM, 30 Gb hard drive
- some generic ATA CD-ROM capable of UDMA2
Into this box was brought over (from the previous machine)
- PCI-based GeForce MX 400
- DC10+ video capture card
RH8 was installed on this system (a brilliant distro BTW, my compliments to
the RH crew) and it booted and installed just fine. So far, so good.
Next it came to getting all the various devices working, and here's where the
tale of woe starts in earnest.
Let me first state that I am a UNIX professional. I am not at all intimidated
by having to configure and compile a kernel. While I don't have the internal
design of the kernal internalized like many of you do, I have enough of a clue
to be able to do troubleshooting and I can (and do) RTFM. In a pinch, I can
even open up a kernel source file and not be totally lost.
I also understand that the hardware I have is a little on the "bleeding edge"
end of the spectrum - perhaps not so much in terms of the technology, but rather
on the age of the underlying chipsets. So it doesn't bother me that (for example)
the onboard Ethernet chip didn't have a driver in the vanilla 2.4.19 source
that I downloaded. Those that wish to have the latest and greatest must be prepared
to accept that not everything they need is necessarily ready for them _right
now_.
But after this past weekend's horror movie, I wish to make 3 points and impassioned
pleas to all y'all.
1) The current kernel configuration process is overly complex for initial configuration
of new hardware. There needs to be some sort of higher-level configuration level
that addresses kernel subsystems on a "hardware component" level rather than
an individual chip driver level.
What I want is some sort of configuration interface that lets me enter or select
my hardware components on an "item" level by manufacturer and model number rather
than what the thing is actually made of.
This could be a GUI, but doesn't need to be.
For example, I want to be able to pick my motherboard model out of a list. I
then want to be presented with a list of components that are options on that
model on an ITEM basis (ie "gigabit ethernet controller" not "Broadcom FOOBAR73541")
and then select the options that I have. Then do the same thing for the hard
drives, PCI cards, etc. For some items (hard drives in particular) it may make
sense to generalize a little bit rather than specify exact model numbers, but
I'm thinking on terms of OPERATIONAL characteristics "ATA133, 80 pin cable"
And then the process beetles off and configures as much of the kernel as it
can according to these selections.
That probably would not be entirely sufficient to _fully_ configure the kernel,
and so it would still probably be necessary to do a usual "make xconfig" (or
whatever fooconfig) on top of that (to handle filesystem drivers, etc) but at
least I'd know that the hardware had been configured correctly.
I'm not asking that the current granularity be removed. I want another layer
on top of that current layer to abstract away a lot of the little niggling details
that turn out to be so bloody important in actually getting stuff to work.
2) The driver load messages that are retrieved via dmesg often lack proper indication
of state - and it makes troubleshooting a SERIOUS PITA. The offender that sticks
most in my craw at the moment is ATA - the motherboard supports ATA133. The
drive supports ATA133. I want the damned thing to function in an "ATA133" mode
but I cannot tell if it is doing that or not. All I know is that the drive is
reported as an ATA drive, and that 'hdparm -Tt /dev/hda' reports 7.5 Mb/sec
- which I think is low, but I don't know for sure.
What I want is the message that reports the drive and the interface to say things
like
"ATA133-capable interface ide0 detected
ide0 running in ATA33 mode (use ide0=ataxxx to change)
Drive hda is a FooBar 123abc (ATA33, ATA66, ATA100, ATA133)
hda is in ATA33 mode
Drive cable not autodetected - need 80 pin cable for ATA100+
Assuming 40 pin cable (use ide0_cable=80 to change)"
The actual verbage is subject for discussion, but if item FOO has more than
one possible state, then please please PLEASE specify what state it is in, and
if there is a way to change that state via a command line parameter or whatever,
state that too.
As it sits right now, it seems I can flip switches 'till doomsday and never
realize where the problem lies - if, indeed there even IS a problem.
3) There really needs to be some sort of centralized hardware database with
a web-based query mechanism that can point people to what drivers are availible
for which hardware, and if they are included in a given kernel version (or not)
and if not, where they can be found. If this already exists, it needs to be
made a hell of a lot more visible and crosslinked from more places, because
I sure never found it - and Google is my friend. I found the Broadcom-supplied
driver for the onboard LAN by pure stupid dumb luck, and I never did find a
sound driver (I had to go to opensound and download their binary drivers to
get sound working - ick!)
Thanks for reading this far on my little rant. I really do appreciate all the
work y'all do, and the quality and performance has come a long way since I first
dipped my toes into Linux back in '97. But damn, three days of my life are gone,
and I still don't have everything working and in many cases I don't know why.
(I'll cover individual issues in separate threads later on.)
Thanks again for reading,
DG
On Mon, 25 Nov 2002, Dennis Grant wrote:
This is the linux-kernel list. Nothing you said has anything to
do with the linux-kernel. Various distributions have various
kinds of installation menus. These are not anything that have
anything to do with the kernel. If you want to change your
configuration on-the-fly, you just use modules. It's that
easy.
Your tale of woe just shows that you are unfamiliar with
whatever Linux Distribution you are using and, your expectations
that somebody here should hear about it on this list shows that you
don't know what "kernel" means.
Next. Fix your line-wrap. Your mail is unreadable on `pine` and/or
the usual Unix tools like `mail`.
> But after this past weekend's horror movie, I wish to make 3 points and impassioned
> pleas to all y'all.
>
> 1) The current kernel configuration process is overly complex for initial configuration
> of new hardware. There needs to be some sort of higher-level configuration level
> that addresses kernel subsystems on a "hardware component" level rather than
> an individual chip driver level.
>
> What I want is some sort of configuration interface that lets me enter or select
> my hardware components on an "item" level by manufacturer and model number rather
> than what the thing is actually made of.
If you want one of these things, you just make one. You can use a kernel
compiled for modules and make a GUI or whatever that searches for the
correct module to install for your hardware. That's what the RH
distribution does for its initial configuration. It also checks for
new devices upon each startup. If you want something different, just
make one.
If you think you can make a kernel configuration program that will
work in text-mode as well as graphics, and you don't like the current
one, you just make one. If it's really good, you can get it to be
part of the kernel distribution. But I warn you, it is not as simple
as you seem to believe.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
Richard B. Johnson wrote:
>On Mon, 25 Nov 2002, Dennis Grant wrote:
>
>This is the linux-kernel list. Nothing you said has anything to
>do with the linux-kernel. Various distributions have various
>kinds of installation menus. These are not anything that have
>anything to do with the kernel. If you want to change your
>configuration on-the-fly, you just use modules. It's that
>easy.
>
>Your tale of woe just shows that you are unfamiliar with
>whatever Linux Distribution you are using and, your expectations
>that somebody here should hear about it on this list shows that you
>don't know what "kernel" means.
>
>
>
>
>
This more likely the place you might want to send this.
https://listman.redhat.com/mailman/listinfo/redhat-list
>Richard B. Johnson wrote:
>> This is the linux-kernel list. Nothing you said has anything
>> to do with the linux-kernel.
Oh really Richard?
Re-read the message.
Point #1 has to do with kernel configuration; ie, "cd /usr/src/linux ; make
xconfig" and the choices made thereafter. I want something like "make modelnumberconfig"
that abstracts away most of the lower level items based on what low-level stuff
is associated with which chunk of hardware.*
I'm pretty sure any time you're invoking the kernel Makefile that you're discussing
a "linux kernel issue"
Point #2 has to do with the messages that drivers, modules, and other bits of
kernel code print to the dmesg data store wrt how they are currently set up
- in other words, kernel state information. The last time I checked, these messages
were contained inside the kernel source - I remember looking through "ide.c"
looking to see what the "idebus=xx" parameter really controlled, and if it had
anything to do with the ATAxx values (as it turns out, it does not, although
my Googling indicates that this seems to be a common misconception)
So this, as well, is entirely appropriate material for linux-kernel.
Point #3 has to do with the issues in publishing where what hardware is supported
in what kernel version, and where drivers not currently contained in the vanilla
kernel are located. Put another way, point #3 is about locating the output of
the work of people "employed" on linux-kernel, and so is also entirely appropriate.
That you are knee-jerk flaming a legitimate message that is entirely on-topic
indicates that you didn't actually read the message, and instead fixated on
one or two statements contained within itand made assumptions from there. That
doesn't seem like good kernel developer practice - perhaps you were looking
for Slashdot?
-------------
* I saw one response from a gentleman who indicated that the low-level hardware
associated with a given "high-level" part number may well change during the
life of the part, and that this poses difficulty. I agree. I also think that
"perfect is the enemy of good enough" and that a case where you can abstract
away the underlying complexity for 90% of the people is probably good enough;
especially if there is some sort of feedback mechanism whereby running changes
to "high level" part numbers (and the related "low-level" kernel module associations)
can be updated in short order.
For the gentleman who posted examples of ATA dmesg output that duplicated very
nearly what I was asking for, mine didn't do that. I'll take that (very specific)
issue up in a later thread when I have access to the dmesg output from my machine.
DG
On Mon, 25 Nov 2002, Dennis Grant wrote:
> >Richard B. Johnson wrote:
>
> >> This is the linux-kernel list. Nothing you said has anything
> >> to do with the linux-kernel.
>
> Oh really Richard?
>
Well, if you are going to reply to me, you really should c.c. me.
I am beginning to understand that you are really just a troll looking
for trouble. However I will, again try to be nice and show you the
errors of your ways.
> Re-read the message.
>
I have read the message.
Of course, you didn't bother to fix your mailer as advised so you
didn't read my message either.
> Point #1 has to do with kernel configuration; ie, "cd /usr/src/linux ; make
> xconfig" and the choices made thereafter. I want something like "make modelnu
<added wrap > mberconfig"
> that abstracts away most of the lower level items based on what low-level
<added wrap> stuff
> is associated with which chunk of hardware.*
Now, let me get this straight; "I want something that abstracts away most
of the low-level items...." Damn! I want a Learjet! As I said, if you
want one, you make one and, as I stated before it isn't as easy as you
seem to think and I think you have proven that you are not too well
learned about kernel modules and configuration items when you want to.
I quote; "abstract away most of the lower level items..."
>
> I'm pretty sure any time you're invoking the kernel Makefile that you're
<added wrap> discussing
> a "linux kernel issue"
>
No. You are discussing a personal preference. Like I said, if you don't
like it, you make a new one. It's just that simple. Once you start
looking into what it takes to configure a kernel, if you have any
smarts at all, you will have some second thoughts about this.
> Point #2 has to do with the messages that drivers, modules, and other bits
<added wrap> of
> kernel code print to the dmesg data store wrt how they are currently set up
> - in other words, kernel state information. The last time I checked, these
<added wrap> messages
Drivers write the messages that the driver authors wanted them to write.
The kernel "state" at that time was that the driver was called. If you
have a problem with a specific driver message, you contact the author
and suggest something. The kernel only writes the messages that some
module author wanted. It tries to get the message out, even if the
kernel is very sick.
> were contained inside the kernel source - I remember looking through "ide.c"
> looking to see what the "idebus=xx" parameter really controlled, and if it had
> anything to do with the ATAxx values (as it turns out, it does not, although
> my Googling indicates that this seems to be a common misconception)
>
> So this, as well, is entirely appropriate material for linux-kernel.
>
> Point #3 has to do with the issues in publishing where what hardware is
<added wrap> supported
> in what kernel version, and where drivers not currently contained in the
<added wrap> vanilla
> kernel are located. Put another way, point #3 is about locating the output of
> the work of people "employed" on linux-kernel, and so is also entirely
<added wrap> appropriate.
>
>
> That you are knee-jerk flaming a legitimate message that is entirely on-topic
> indicates that you didn't actually read the message, and instead fixated on
> one or two statements contained within itand made assumptions from there. That
> doesn't seem like good kernel developer practice - perhaps you were looking
> for Slashdot?
You got no knee-jerk flaming from me. If you think you did, you are in a
world of hurt.
[SNIPPED...]
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
On Mon, Nov 25, 2002 at 12:33:18PM -0500, Dennis Grant wrote:
> For example, I want to be able to pick my motherboard model out of a
> list. I then want to be presented with a list of components that are
> options on that model on an ITEM basis (ie "gigabit ethernet
> controller" not "Broadcom FOOBAR73541") and then select the options
> that I have.
The major problem with this idea is the question: who will pay for
keeping this database of motherboard models, et. al, up to date?
If it is done purely on a voluntary basis, it will have huge gaps, and
then there will be people complaining about why the #!@$#@
configuration system doesn't list their motherboard. Even Microsoft
hasn't attempted to do what you have described, and for good reason
--- new motherboards and new chipsets appear far too often for any
software product to be able to track this with any hope of success.
- Ted
On Mon, Nov 25, 2002 at 12:33:18PM -0500, Dennis Grant wrote:
[ snip long bits ]
a while back giacomo catenazzi (probably spelled wrong) hacked up some
goodies to autodetect what hardware driver options are appropriate for
your system, based on contents of various bits of /proc. i haven't
heard anything about it in quite some time but it sure seems like this
would be the most appropriate tool for cases like yours.
i believe it generated a baseline .config with appropriate things
enabled; having done that you then went through menuconfig enabling
other things you wanted, like filesystems, non-autodetect-able hardware,
etc.
j.
--
toyota power: http://indigoid.net/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 26 Nov 2002 19:21, john slee wrote:
> On Mon, Nov 25, 2002 at 12:33:18PM -0500, Dennis Grant wrote:
> [ snip long bits ]
>
> a while back giacomo catenazzi (probably spelled wrong) hacked up some
> goodies to autodetect what hardware driver options are appropriate for
> your system, based on contents of various bits of /proc. i haven't
> heard anything about it in quite some time but it sure seems like this
> would be the most appropriate tool for cases like yours.
Giacomo Catenazzi is the author.
It copped some of the CML2 fallout. See
http://sourceforge.net/projects/kautoconfigure/
Brad
- --
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE94zI3W6pHgIdAuOMRAjoLAJ49zdTawEedPe++1LZG4d4lZv0agwCfQ3dt
mJW1+YduC+7TFcqmH2VF8EQ=
=U4VP
-----END PGP SIGNATURE-----
> I am beginning to understand that you are really just a troll looking
> for trouble. However I will, again try to be nice and show you the
> errors of your ways.
I don't see how Dennis Grant's original message can be
considered trollish. It was very politely written,
constructive, and on-topic. Perhaps it is true that
some of the features he wants should be left up to
distributors, but his request for driver log messages
to be more detailed is reasonable.
My advice to Richard is to try not to feel offended.
Of the thousands of people reading a list like this, there
are always going to be one or two who reply after remembering
that they were supposed to buy more coffee yesterday ...
--
Thomas Hood
On Mon, Nov 25, 2002 at 03:00:27PM -0500, Richard B. Johnson wrote:
>...
> I am beginning to understand that you are really just a troll looking
> for trouble. However I will, again try to be nice and show you the
> errors of your ways.
>...
???
In his mail Dennis gave a good description of problems and missing
features he was faced with. You might argue on a technical basis whether
everything he suggests is implementable but his mail was very
constructive and on-topic.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
The attitude of *some* people (even those considered senior) in this and
other mailing lists is down right shameful.
Anybody who are genuinely trying to help, contribute or just get
involved all too often have their efforts publicly belittled.
Polite criticism and guidance is always the better option and encourages
people to join in rather than frightening them off.
Arrogance (Ar"ro*gance) (#), n.
[F., fr. L. arrogantia, fr. arrogans. See Arrogant.]
The act or habit of arrogating, or making undue claims in an overbearing
manner; that species of pride which consists in exorbitant claims of
rank, dignity, estimation, or power, or which exalts the worth or
importance of the person to an undue degree; proud contempt of others;
lordliness; haughtiness; self-assumption; presumption.
>
>>>This is the linux-kernel list. Nothing you said has anything
>>>to do with the linux-kernel.
>>
>
> Oh really Richard?
>
> Re-read the message.
>
> Point #1 has to do with kernel configuration; ie, "cd /usr/src/linux ; make
> xconfig" and the choices made thereafter. I want something like "make modelnumberconfig"
> that abstracts away most of the lower level items based on what low-level stuff
> is associated with which chunk of hardware.*
>
> I'm pretty sure any time you're invoking the kernel Makefile that you're discussing
> a "linux kernel issue"
>
> Point #2 has to do with the messages that drivers, modules, and other bits of
> kernel code print to the dmesg data store wrt how they are currently set up
> - in other words, kernel state information. The last time I checked, these messages
> were contained inside the kernel source - I remember looking through "ide.c"
> looking to see what the "idebus=xx" parameter really controlled, and if it had
> anything to do with the ATAxx values (as it turns out, it does not, although
> my Googling indicates that this seems to be a common misconception)
>
> So this, as well, is entirely appropriate material for linux-kernel.
>
> Point #3 has to do with the issues in publishing where what hardware is supported
> in what kernel version, and where drivers not currently contained in the vanilla
> kernel are located. Put another way, point #3 is about locating the output of
> the work of people "employed" on linux-kernel, and so is also entirely appropriate.
>
>
> That you are knee-jerk flaming a legitimate message that is entirely on-topic
> indicates that you didn't actually read the message, and instead fixated on
> one or two statements contained within itand made assumptions from there. That
> doesn't seem like good kernel developer practice - perhaps you were looking
> for Slashdot?
>
> -------------
> * I saw one response from a gentleman who indicated that the low-level hardware
> associated with a given "high-level" part number may well change during the
> life of the part, and that this poses difficulty. I agree. I also think that
> "perfect is the enemy of good enough" and that a case where you can abstract
> away the underlying complexity for 90% of the people is probably good enough;
> especially if there is some sort of feedback mechanism whereby running changes
> to "high level" part numbers (and the related "low-level" kernel module associations)
> can be updated in short order.
>
> For the gentleman who posted examples of ATA dmesg output that duplicated very
> nearly what I was asking for, mine didn't do that. I'll take that (very specific)
> issue up in a later thread when I have access to the dmesg output from my machine.
>
>
> DG
> -
> 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/
>
> In his mail Dennis gave a good description of problems and missing
> features he was faced with. You might argue on a technical basis whether
> everything he suggests is implementable but his mail was very
> constructive and on-topic.
I think he missed the solution rather than missing the problem - in fact
much of the problem he reports comes from missing the real solution. The
problem though is that he's trying to solve the wrong problem. We don't
need to care about the "right kernel for box xyz" we just need to care
about "boots on box xyz".
What does that mean. Well it means you can take a pre-existing modular
everything script, set the CPU to be low enough to boot on the users
box, make the root device compiled in, make the root fs compiled in (or
use initrd as Red Hat does) and its done.
Alan
> I think he missed the solution rather than missing the
> problem
I think I may agree with you, to a point, in that (after further reflection)
I think there's an intermediate step between the current state and the magical
world of "make partsconfig" or even "make autoconfig"
The real problem is the difficulty in mapping a given hardware configuration
to a kernel version and a subsequent kernel configuration. There's no smooth
road to get from one to the other. Paving that road solves the problem; the
only question is of degree. The "make autoconfig" case is the ideal, but we
don't necessarily need the ideal. Perfect is the enemy of good enough.
I started doing a little doodling, and I came up with a very rough sort of relationship
map. I don't present this as the ideal data model - it's a start point at best.
A "box" is composed of "devices" and "subcomponents"
A "subcomponent" is composed of "chipsets"
A "chipset" provides a set of "capabilities"
A "device" requires a set of "capabilities"
A "chipset->capability::capablility<-device" pair defines an "interface"
An "interface" has associated with it:
a) the kernel version where it first became availible
b) the kernel config switches that activate it
So what is needed is some way to start at the "box" level, and given the set
of subcomponents and devices associated with it, spit out a list of a) and b)
Here's the mini-eureka I've had - that need not actually be a part of the kernel
config system, although the kernel config system might potentially make use
of it.
What would suffice would be some sort of online database, published in a highly
visible location, and crosslinked from hell and back to make it likely to be
discovered in a Google-driven troubleshooting session. Provide motherboard make
and model (a subcomponent) any expansion cards (also subcomponents) and the
make and model numbers of drives et al (devices) and then query the database
and present the report.
I'm envisioning something very much like the CDDB service. This is a little
more complex, but the concept is similar. And like the CDDB service, it could
be queried over the network by some future "make" option if somebody decided
to implement that.
Also like the CDDB service, it makes use of network effects. No one person has
to populate the _entire_ database. The association of "subcomponents" to "chipsets"
(or "devices" to "capabilities") might be done by the manufacturer, or it might
be done by the developer who actually debugged the original driver instance,
or it might even be done by someone like myself (a sufficiently clued-in sysadmin
who did it the hard way and wants to help those who will follow after him)
All that matters is that _somebody_ contribute one little portion of the mapping,
and then, given enough somebodies, the entire map assembles itself.
And if Microsoft hasn't dared attempt such a thing... well, then that would
make it an "innovation", wouldn't it? ;)
DG
> I started doing a little doodling, and I came up with a very rough sort of
relationship
> map. I don't present this as the ideal data model - it's a start point at
best.
>
>
> A "box" is composed of "devices" and "subcomponents"
> A "subcomponent" is composed of "chipsets"
> A "chipset" provides a set of "capabilities"
> A "device" requires a set of "capabilities"
> A "chipset->capability::capablility<-device" pair defines an "interface"
> An "interface" has associated with it:
> a) the kernel version where it first became availible
> b) the kernel config switches that activate it
>
> So what is needed is some way to start at the "box" level, and given the
set
> of subcomponents and devices associated with it, spit out a list of a) and
b)
>
>
> Here's the mini-eureka I've had - that need not actually be a part of the
kernel
> config system, although the kernel config system might potentially make
use
> of it.
>
> What would suffice would be some sort of online database, published in a
highly
> visible location, and crosslinked from hell and back to make it likely to
be
> discovered in a Google-driven troubleshooting session. Provide motherboard
make
> and model (a subcomponent) any expansion cards (also subcomponents) and
the
> make and model numbers of drives et al (devices) and then query the
database
> and present the report.
>
> I'm envisioning something very much like the CDDB service. This is a
little
> more complex, but the concept is similar. And like the CDDB service, it
could
> be queried over the network by some future "make" option if somebody
decided
> to implement that.
>
> Also like the CDDB service, it makes use of network effects. No one person
has
> to populate the _entire_ database. The association of "subcomponents" to
"chipsets"
> (or "devices" to "capabilities") might be done by the manufacturer, or it
might
> be done by the developer who actually debugged the original driver
instance,
> or it might even be done by someone like myself (a sufficiently clued-in
sysadmin
> who did it the hard way and wants to help those who will follow after him)
>
> All that matters is that _somebody_ contribute one little portion of the
mapping,
> and then, given enough somebodies, the entire map assembles itself.
>
So how would you deal with somebody contributing bogus mappings?
What if somebody was just wrong, or uploading a mapping in error?
> And if Microsoft hasn't dared attempt such a thing... well, then that
would
> make it an "innovation", wouldn't it? ;)
>
> DG
> So how would you deal with somebody contributing bogus
> mappings? What if somebody was just wrong, or uploading a
> mapping in error?
Well, then the next time somebody queried that mapping and got back the config,
it wouldn't work. And they'd either fix it, or complain to someone who would
fix it.
So its inherently self-correcting.
DG
On November 26, 2002 12:35 pm, Rusty Lynch wrote:
> So how would you deal with somebody contributing bogus mappings?
> What if somebody was just wrong, or uploading a mapping in error?
The same applies to the kernel code, or any other open source project:
How do you deal with somebody contributing bogus code?
Somehow things work out, as we have already witnessed.
--
Dimi.
[email protected] (Richard B. Johnson) wrote on 25.11.02 in <[email protected]>:
> On Mon, 25 Nov 2002, Dennis Grant wrote:
>
> This is the linux-kernel list.
Perfectly true.
> Nothing you said has anything to
> do with the linux-kernel.
Utter nonsense.
>Various distributions have various
> kinds of installation menus. These are not anything that have
> anything to do with the kernel.
And they're totally irrelevant to this.
> Your tale of woe just shows that you are unfamiliar with
> whatever Linux Distribution you are using and, your expectations
> that somebody here should hear about it on this list shows that you
> don't know what "kernel" means.
Your answer seems to indicate that you never compiled a Linux kernel in
your life. Now, I do not believe that you really didn't, but if I were
judging *only* from this reply, that conclusion would be inescapable.
Incidentally, I suspect his problems would mostly be solved by including
the autoconfigurator into Kconfig - not quite what he envisioned, but
probably a better solution.
Oh, and for the database - at least the LHD seems to be pretty close to
his description.
Welcome to my killfile.
MfG Kai
[email protected] (Dennis Grant) wrote on 26.11.02 in <[email protected]>:
> > I think he missed the solution rather than missing the
> > problem
>
> I think I may agree with you, to a point, in that (after further reflection)
> I think there's an intermediate step between the current state and the
> magical world of "make partsconfig" or even "make autoconfig"
Well ... it seems to me that the main difference is that (a significant
part of) "make autoconfig" *actually exists*.
MfG Kai
On Tue, 2002-11-26 at 18:04, Dimitrie O. Paun wrote:
> On November 26, 2002 12:35 pm, Rusty Lynch wrote:
> > So how would you deal with somebody contributing bogus mappings?
> > What if somebody was just wrong, or uploading a mapping in error?
>
> The same applies to the kernel code, or any other open source project:
> How do you deal with somebody contributing bogus code?
>
> Somehow things work out, as we have already witnessed.
For boards its not that simple. Many vendors release multiple utterly
different machines with the same box, bios and ident. The customer is
told "IDE CD, 100mbit ethernet", the customer gets random cheapest going
ethernet.
Alan
Contributors could be given a reliability rating (bit like ebay?). Same
thing for contributions; users could confirm successful results and
boost the rating of the info.
Dennis Grant wrote:
>>So how would you deal with somebody contributing bogus
>>mappings? What if somebody was just wrong, or uploading a
>>mapping in error?
>
>
> Well, then the next time somebody queried that mapping and got back the config,
> it wouldn't work. And they'd either fix it, or complain to someone who would
> fix it.
>
> So its inherently self-correcting.
>
> DG
> -
> 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/
>
Andrw Walrond wrote:
> Contributors could be given a reliability rating (bit like ebay?). Same
> thing for contributions; users could confirm successful results and
> boost the rating of the info.
>
Now that would be cool. Sounds like something that might be more
complex then it appears, but it would be fun to play with if somebody
else implemented it. :->
One way I would use such a database would be to help guide my
decission on what devices to put into a box I am building.
-rustyl
On Tue, 26 Nov 2002, Dennis Grant wrote:
> > I think he missed the solution rather than missing the
> > problem
>
> I think I may agree with you, to a point, in that (after further reflection)
> I think there's an intermediate step between the current state and the magical
> world of "make partsconfig" or even "make autoconfig"
>
> The real problem is the difficulty in mapping a given hardware configuration
> to a kernel version and a subsequent kernel configuration. There's no smooth
> road to get from one to the other. Paving that road solves the problem; the
> only question is of degree. The "make autoconfig" case is the ideal, but we
> don't necessarily need the ideal. Perfect is the enemy of good enough.
>
> I started doing a little doodling, and I came up with a very rough sort of relationship
> map. I don't present this as the ideal data model - it's a start point at best.
>
>
> A "box" is composed of "devices" and "subcomponents"
> A "subcomponent" is composed of "chipsets"
> A "chipset" provides a set of "capabilities"
> A "device" requires a set of "capabilities"
> A "chipset->capability::capablility<-device" pair defines an "interface"
> An "interface" has associated with it:
> a) the kernel version where it first became availible
> b) the kernel config switches that activate it
>
> So what is needed is some way to start at the "box" level, and given the set
> of subcomponents and devices associated with it, spit out a list of a) and b)
>
>
> Here's the mini-eureka I've had - that need not actually be a part of the kernel
> config system, although the kernel config system might potentially make use
> of it.
>
> What would suffice would be some sort of online database, published in a highly
> visible location, and crosslinked from hell and back to make it likely to be
> discovered in a Google-driven troubleshooting session. Provide motherboard make
> and model (a subcomponent) any expansion cards (also subcomponents) and the
> make and model numbers of drives et al (devices) and then query the database
> and present the report.
>
> I'm envisioning something very much like the CDDB service. This is a little
> more complex, but the concept is similar. And like the CDDB service, it could
> be queried over the network by some future "make" option if somebody decided
> to implement that.
>
> Also like the CDDB service, it makes use of network effects. No one person has
> to populate the _entire_ database. The association of "subcomponents" to "chipsets"
> (or "devices" to "capabilities") might be done by the manufacturer, or it might
> be done by the developer who actually debugged the original driver instance,
> or it might even be done by someone like myself (a sufficiently clued-in sysadmin
> who did it the hard way and wants to help those who will follow after him)
>
> All that matters is that _somebody_ contribute one little portion of the mapping,
> and then, given enough somebodies, the entire map assembles itself.
>
> And if Microsoft hasn't dared attempt such a thing... well, then that would
> make it an "innovation", wouldn't it? ;)
>
> DG
I thought Alan responded quite well, but now you have a "solution"
to a problem that doesn't exist. Really.
To make myself perfectly clear, Unix and Unix clones come to life
running one program called init. It reads some scripts that tells
it how to configure the machine the way an end-user wants it.
Look in /etc/rc.d. There are various scripts or links to scripts
for various 'run-levels'.
If you don't know this or understand this, then I can't help you.
To 'auto-configure', all you need is a kernel that is configured for
modules. As Alan pointed out, it's also helpful to have a kernel
that boots an initial RAM-Disk so that a driver to run your root-
file-system hard disk can be loaded.
All you need to do, to auto-configure, under these conditions is
to run shell-scripts or any kind of programs you want upon boot.
This scripts or programs can probe, query, cajole, or do anything
else you want, to find out what hardware you have, whether you want
to load a driver (module) and if you want to enable it. This can
all be done automatically upon boot. It doesn't require any special
kernel capabilities other than what already exists.
The auto-configure really, truly, doesn't have anything to do with
the kernel. If your distribution doesn't do what you want, you
can make it do what you want if you are capable, or you can contact
the distributor with your suggestions.
The 'auto-configuration' of the kernel proper, to load various
drivers is typically done to 'optimize' a particular system.
For this optimization, one would build-in the drivers so that
modules don't have to be loaded. One would also enable specific
code enhancements for specific processors. To do this, you really
need to tell some script or program what you are intending to do.
Currently, we have two ways of doing this. There is a graphical
kernel configuration and a text-mode kernel configuration. These
user configuration methods really have to believe what the user
tells it to do.
That said, you can write a program that looks at a properly functioning
system, and from what it sees, it could create a '.config' file that
could be used as input for `make old_config`. This could cut down
the amount of time necessary to optimize the kernel for a specific
system. But, then again, that program, although it makes a kernel-
configuration file, is not really a kernel issue.
Since I loaded my first distribution from, I think it was 57 floppy
disks, to the current ones, I have hoped that somebody would make
a kernel autoconfiguration utility but so far it hasn't been done,
probably because the kernel is usually configured to boot some
other machine. In that case, the existing manual configuration needs
to believe what the user says.
I'm going to bow out of this discussion before I get whacked
for not being on-topic myself. Contact me off the list for further
discussion. If somebody wants some help in setting up some boot-time
autoconfiguration that they don't already have, you can contact me
off-list, also.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
>On Tue, 2002-11-26 at 18:04, Dimitrie O. Paun wrote:
>> On November 26, 2002 12:35 pm, Rusty Lynch wrote:
>>> So how would you deal with somebody contributing bogus
>>> mappings? What if somebody was just wrong, or uploading a
>>> mapping in error?
>> The same applies to the kernel code, or any other open
>> source project: How do you deal with somebody contributing
>> bogus code?
>> Somehow things work out, as we have already witnessed.
> For boards its not that simple. Many vendors release multiple > utterly different
machines with the same box, bios and ident.
> The customer is told "IDE CD, 100mbit ethernet", the customer
> gets random cheapest going ethernet.
Agreed - so then the association between "board" and "chipset" must be capable
of being multi-valued, and when there is a mult-valued match there must be some
means of further interrogating the user (or user agent) for more information.
DG
On Tue, 2002-11-26 at 19:28, Dennis Grant wrote:
> Agreed - so then the association between "board" and "chipset" must be capable
> of being multi-valued, and when there is a mult-valued match there must be some
> means of further interrogating the user (or user agent) for more information.
Much simpler to just include "modular everything" and let user space
sort it out. Guess why every vendor takes this path
> > For boards its not that simple. Many vendors release multiple >
> > utterly different machines with the same box, bios and ident.
> > The customer is told "IDE CD, 100mbit ethernet", the customer
> > gets random cheapest going ethernet.
>
> Agreed - so then the association between "board" and "chipset" must
> be capable of being multi-valued, and when there is a mult-valued
> match there must be some means of further interrogating the user (or
> user agent) for more information.
This demonstrates a very important point - _any_ automatic
configuration program is likely to cause more traffic to this mailing
list, and create more work for users and developers that the current
automatic configuration process:
echo 'My box doesn't boot' | mail [email protected]
The kernel knows nothing about motherboards, cards, etc. It knows
about chipsets, and nothing else. By definition, you cannot have a
kernel configurator that works at a higher level than that.
Why don't we introduce a make allworkingmodules config, which compiles
everything as modules, except for the things that are broken as
modules, (for example IDE in the current 2.5.x tree would be compiled
in).
John.
> > goodies to autodetect what hardware driver options are appropriate for
> > your system, based on contents of various bits of /proc. i haven't
> > heard anything about it in quite some time but it sure seems like this
> > would be the most appropriate tool for cases like yours.
> Giacomo Catenazzi is the author.
> It copped some of the CML2 fallout. See
> http://sourceforge.net/projects/kautoconfigure/
>
Not very much at the website,
do you know its state and if it is included in kernel 2.5?
IMO each driver should be able (within resonable limits) to detect the
hardware it is written for, returning a simple true/false. This way any
driver could be asked if its hardware is available. With trial and error
it should be possible to autodetect any hardware. This way there is no
need for a centralize database. Of course if there is no driver one
could ask that hardware never gets detected.
O. Wyss
On Tue, Nov 26, 2002 at 08:05:31PM +0000, Alan Cox wrote:
> On Tue, 2002-11-26 at 19:28, Dennis Grant wrote:
> > Agreed - so then the association between "board" and "chipset" must be capable
> > of being multi-valued, and when there is a mult-valued match there must be some
> > means of further interrogating the user (or user agent) for more information.
>
> Much simpler to just include "modular everything" and let user space
> sort it out. Guess why every vendor takes this path
Is there a tool though to map bus (PCI,USB etc) id's back
onto modules which are likely[1] contain driver for them.
Given that many driver contain the Ids of the devices they will handle
within their source, if this tool doesn't exist it could be built
by ask modules to define a test_id function used both by themselves
in the normal (ie , called in place of the code it moves into a
seperate fucntion) way and compiled into a user space utility from the
same kernel source.
TTFN
[1] Only likely, having met the nasty case of different
hardware with the same PCMCIA id, and PCI hardware which has
a range of Ids associated with it.
--
Roger.
Master of Peng Shui. (Ancient oriental art of Penguin Arranging)
GPG Key FPR: CFF1 F383 F854 4E6A 918D 5CFF A90D E73B 88DE 0B3E
What ways would people like to implement such as system in?
Ie.. a website, a database, etc...
"Rusty Lynch" <[email protected]> scribbled something about Re: A Kernel Configuration Tale of Woe:
> Andrw Walrond wrote:
> > Contributors could be given a reliability rating (bit like ebay?). Same
> > thing for contributions; users could confirm successful results and
> > boost the rating of the info.
> >
>
> Now that would be cool. Sounds like something that might be more
> complex then it appears, but it would be fun to play with if somebody
> else implemented it. :->
>
> One way I would use such a database would be to help guide my
> decission on what devices to put into a box I am building.
>
> -rustyl
>
>
> -
> 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/
>
--
+----------------------------------+---------------------------------+
| Lee Leahu | voice -> 708-444-2690 |
| Internet Technology Specialist | fax -> 708-444-2697 |
| RICIS, Inc. | email -> [email protected] |
+----------------------------------+---------------------------------+
| I cannot conceive that anybody will require multiplications at the |
| rate of 40,000 or even 4,000 per hour ... |
| -- F. H. Wales (1936) |
+--------------------------------------------------------------------+
On Tue, 2002-11-26 at 19:59, Otto Wyss wrote:
> IMO each driver should be able (within resonable limits) to detect the
> hardware it is written for, returning a simple true/false.
Dream on
Also there is a GPL library to do the parts of this (and more) that can
be done as part of kudzu.
On Tue, Nov 26, 2002 at 11:21:22PM +0000, Roger Gammans wrote:
> On Tue, Nov 26, 2002 at 08:05:31PM +0000, Alan Cox wrote:
> > On Tue, 2002-11-26 at 19:28, Dennis Grant wrote:
> > > Agreed - so then the association between "board" and "chipset" must be capable
> > > of being multi-valued, and when there is a mult-valued match there must be some
> > > means of further interrogating the user (or user agent) for more information.
> >
> > Much simpler to just include "modular everything" and let user space
> > sort it out. Guess why every vendor takes this path
>
> Is there a tool though to map bus (PCI,USB etc) id's back
> onto modules which are likely[1] contain driver for them.
That's exactly what the hotplug package does.
See http://linux-hotplug.sf.net/ for more info. Odds are it's already
installed on your box :)
greg k-h
John Bradford wrote:
> This demonstrates a very important point - _any_ automatic
> configuration program is likely to cause more traffic to this mailing
> list, and create more work for users and developers that the current
> automatic configuration process:
>
> echo 'My box doesn't boot' | mail [email protected]
>
> The kernel knows nothing about motherboards, cards, etc. It knows
> about chipsets, and nothing else. By definition, you cannot have a
> kernel configurator that works at a higher level than that.
I disagree. When we have a booting kernel, finding out the used drivers
is not so difficult: kernel give us already enough informations (modules
loaded, in drivers that use some resources,...).
The problem is: what will be the use of such minimalistic/optimal but
non-modular kernel?
If I add a new device (such a modem, a printer, new USB device...) or
if I use a new disk with an other FS, the users of an autoconfiguration
will be lost, but not the users of the vendors kernels.
Thus the real problem is: where will use such autoconfiguration? Why?
IMHO it can be used only by expert, to find what drivers is need for
such device (when hotplug cannot help you).
ciao
giacomo
> > This demonstrates a very important point - _any_ automatic
> > configuration program is likely to cause more traffic to this mailing
> > list, and create more work for users and developers that the current
> > automatic configuration process:
> >
> > echo 'My box doesn't boot' | mail [email protected]
> >
> > The kernel knows nothing about motherboards, cards, etc. It knows
> > about chipsets, and nothing else. By definition, you cannot have a
> > kernel configurator that works at a higher level than that.
>
> I disagree. When we have a booting kernel, finding out the used drivers
> is not so difficult: kernel give us already enough informations (modules
> loaded, in drivers that use some resources,...).
OK, so you can analyse the data from a fully modular kernel, then use
that information to build a kernel with just the required hardware
support built in.
That will tell you what drivers are in use for the chipsets that are
present on your devices. If you remove your foobar ethernet adaptor,
and replace it with a foobar ethernet adaptor from the same
manufacturer, it may stop working. It doesn't achieve what the
original poster wanted.
The problem is that when it doesn't work, and somebody posts to this
list saying that it doesn't work, I strongly suspect that it's going
to be a lot more time consuming figuring out why, then just telling
them which option needs to be set in their .config.
> The problem is: what will be the use of such minimalistic/optimal but
> non-modular kernel?
Well, I use non-modular kernels by default, mainly because Linux
didn't have modular support when I first used it, and I don't really
find the need for them. Most desktop users find them indispenable,
though.
> If I add a new device (such a modem, a printer, new USB device...) or
> if I use a new disk with an other FS, the users of an autoconfiguration
> will be lost, but not the users of the vendors kernels.
>
> Thus the real problem is: where will use such autoconfiguration? Why?
> IMHO it can be used only by expert, to find what drivers is need for
> such device (when hotplug cannot help you).
There already is a kind of autoconfiguration - reading the help text
for each option in xconfig usually says, "If you're not sure say
[Y|N|M]". Why doesn't the new xconfig just have the ability to set
all of the options the the recommended ones?
John
On Tue, 26 Nov 2002 19:45:50 +0000 (GMT),
John Bradford <[email protected]> wrote:
>Why don't we introduce a make allworkingmodules config, which compiles
>everything as modules, except for the things that are broken as
>modules, (for example IDE in the current 2.5.x tree would be compiled
>in).
cat > .force_default <<EOF
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
EOF
make allmodconfig
That used to work, until 2.5.48. Being able to force selected options
and have the rest of the options default to all Y or all M was
extremely useful. What a pity that Kconfig removed this facility.
Hi,
On Wed, 27 Nov 2002, Keith Owens wrote:
> cat > .force_default <<EOF
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> EOF
> make allmodconfig
>
> That used to work, until 2.5.48. Being able to force selected options
> and have the rest of the options default to all Y or all M was
> extremely useful. What a pity that Kconfig removed this facility.
It's not that difficult to reimplement, but it was an undocumented
feature, so I'd rather concentrated on the rest and waited until one of a
few people who knew about this feature would complain.
bye, Roman
On Wed, 27 Nov 2002 13:03:23 +0100 (CET),
Roman Zippel <[email protected]> wrote:
>On Wed, 27 Nov 2002, Keith Owens wrote:
>
>> cat > .force_default <<EOF
>> CONFIG_BLK_DEV_IDE=y
>> CONFIG_BLK_DEV_IDEDISK=y
>> EOF
>> make allmodconfig
>>
>> That used to work, until 2.5.48. Being able to force selected options
>> and have the rest of the options default to all Y or all M was
>> extremely useful. What a pity that Kconfig removed this facility.
>
>It's not that difficult to reimplement, but it was an undocumented
>feature
Bullshit. It was fully documented in kbuild 2.5. Just because Kai
dropped the docs when he stole bits from kbuild 2.5 does not make
.force_default into an undocumented feature.
>so I'd rather concentrated on the rest and waited until one of a
>few people who knew about this feature would complain.
People do not know about it because Kai dropped the docs.
>On Tue, 2002-11-26 at 19:28, Dennis Grant wrote:
>> Agreed - so then the association between "board"
>> and "chipset" must be capable of being multi-valued,
>> and when there is a mult-valued match there must be
>> some means of further interrogating the user (or user agent)
>> for more information.
> Much simpler to just include "modular everything" and let
> user space sort it out. Guess why every vendor takes this path
Oh, OK... Now I see what you're getting at.
Build a kernel where everything is a module, boot with some sort of absolute-bare-minimum
bootloader kernel, and then self-configure dynamically. Either to, from there,
generate a specific kernel config file from which to build a box-specific kernel
- or just to hell with it, and self-configure every time at boot.
Well... yeah. Assuming all the modules can autodetect, or that there's some
sort of sane userspace module loader doing autodetection, reading from a config
file, or both... yeah, that works.
I'll be honest - certain aspects of this offends some of my asthetics... but
that's not a requirement. Functionality is.
And with the assumption that all the modules needed, plus the mechanism to determine
if a given module is/is not loaded (and if loaded, how it is to be configured)
are availible on the box, this is 100% functional.
But....
I don't think this would have solved any of my problems.
I haven't had the opportunity to test it yet, but I have every confidence that
my ATA speed problems are a product of an incompletely-supported motherboard
chipset (wrt the kernel I compiled), and that once the 20-pre3+ac patches are
applied, that I'll have the correct drivers availible and everything will Just
Work. Certainly this was the case with the onboard Ethernet (I had to track
down a vendor driver, as it appears there is no support anywhere in a 2.4 series
kernel as of yet).
So even if 2.4.19 _had_ the "everything as modules" option, plus the required
userspace glue, you'd still be hearing from me, because there is no module there
to be autoloaded that matches my hardware.
And then there's still the issue of enough information being presented out of
the modules to allow one to examine the dmesg output from a boot and actually
determine that modules were missing (or missing features, or whatever)
So I think there's still a need for the hardware->kernel version+config database.
Perhaps the need for the query mechanism to generate an actual working kernel
config is less than I first imagined, but certainly the ability to generate
(if nothing else) the minimum kernel version required to support a give set
of hardware has value - it would have kept me away at least. :)
DG
On Tue, 26 Nov 2002, Otto Wyss wrote:
[snip]
> IMO each driver should be able (within resonable limits) to detect the
> hardware it is written for, returning a simple true/false. This way any
> driver could be asked if its hardware is available. With trial and error
> it should be possible to autodetect any hardware. This way there is no
> need for a centralize database. Of course if there is no driver one
> could ask that hardware never gets detected.
Please, no. Try installing Microsoft Windows on some box if you want to
see this idea in action. They've done it that way for years: throw all
available drivers at the hardware and see which ones stick. Pick a time
when you have a couple of hours to waste -- the process is agonizingly
slow.
Much better to simply ask each bus what's sitting on it. Only non-PnP ISA
devices are unable to answer. If the box has no ISA slots, then the
configuration can be done without any user intervention in a few
milliseconds.
--
Mark H. Wood, Lead System Programmer [email protected]
MS Windows *is* user-friendly, but only for certain values of "user".
On Wed, Nov 27, 2002 at 12:52:45PM -0500, Dennis Grant wrote:
> >> Agreed - so then the association between "board"
> >> and "chipset" must be capable of being multi-valued,
> >> and when there is a mult-valued match there must be
> >> some means of further interrogating the user (or user agent)
> >> for more information.
> > Much simpler to just include "modular everything" and let
> > user space sort it out. Guess why every vendor takes this path
> So I think there's still a need for the hardware->kernel version+config database.
The kernel source pretty close resembles what the kernel supports
(except the broken drivers). Make the source your database. Propose
source code formatting rules, and let the userspace parse it (assuming
the proposal find the way into source). Make the hardware descriptions
readable in the object code, so the userspace can pick up new modules
and activate them if a new pci-id is seen. Etc...
It's already of such use for some of us, who are about to get a new
hardware and trying to figure out if it can be useful:
egrep -rn 'vendor|cardname' .
-alex
On Wed, Nov 27, 2002 at 11:19:00PM +1100, Keith Owens wrote:
> Bullshit. It was fully documented in kbuild 2.5. Just because Kai
> dropped the docs when he stole bits from kbuild 2.5 does not make
> .force_default into an undocumented feature.
I never seen this as a standalone patch from you - something i missed?
I do not remember exactly but I may have been the person
extracting this from kbuild-2.5 and feeding this patch to Kai,
in which case you should blaim me, not Kai.
If you were not properly attributed at that point in time, sorry for that.
If kconfig are extended with functionality similar to .force_default
then the file containing the defaults shall NOT be hidden.
There is no good reason to hide for the user that some options
are forced to a specific value.
IIRC the old implementation only impacted "make oldconfig", so
doing something like:
echo CONFIG_HOTPLUG=y > .force_default
make oldconfig
make menuconfig, enable HOTPLUG
Manually tweak .config and run make oldconfig
then I would behind my back loose the hotplug setting, without
any warning.
If implemented defaults should be effective in all frontends, not only
make oldconfig. Forced defaults should be unchangable in the frontends.
It is not intuitive for the user that at one point something is forced
enabled, and then later the user are anyway allowed to change it
without further notice.
Sam
On Wed, 27 Nov 2002, Keith Owens wrote:
> Bullshit. It was fully documented in kbuild 2.5. Just because Kai
> dropped the docs when he stole bits from kbuild 2.5 does not make
> .force_default into an undocumented feature.
$ bk changes -r1.403.20.3
[email protected], 2002-06-05 19:40:54-05:00, [email protected]
kbuild: Additional config targets for testing
This patch adds the following targets, which generate some configs
useful for testing - which kind should be clear from the names:
o allyesconfig
o allmodconfig
o allnoconfig
o randconfig
It also adds
o defconfig
which does the same as make oldconfig but uses the defaults for all
new options without asking.
The actual patch was done by Ghozlane Toumi, maintained in kbuild-2.5
by Keith Owens, and extracted by Sam Ravnborg and [email protected].
Don't you think accusing me of "stealing" from kbuild-2.5 is a bit
harsh???
--Kai
I thought arrogance was almost a prerequisite for being a Linux kernel
programmer?
Seriously, if one is working on a project for which you are the highest
authority, then in your world, you are the center of your knowledge.
Any
other knowledge or view is somehow less important. Trivializing and
marginalizing people with other views becomes standard practice. When
you
think you know so much, you can't even begin to take on another's view
for the sake of understanding. Instead, all you can do is tear them
down.
To even begin to try to understand takes great courage to *risk* being
wrong. If you are identified with your work, then any questioning about
the 'standard way of doing things' is an immediate threat that is to be
eliminated, expeditiously. The strength of reaction is a gauge to the
arrogant person's level of fear.
Some folks focus on the technology rather than identifying with it and
are actually
decent, reasonable people you can have a discussion with. Others are so
full
of themselves as to label dissenters as 'dangerous' people who shouldn't
be allowed
to share their opinions. One of the more ironic, self-evident
remarks a senior kernel contributor made: "they don't let their
ignorance get
in the way of their opinions". Ain't it the truth.
It's when we shut our minds that we become ignorant.
-l
> From: Andrew Walrond
> The attitude of *some* people (even those considered senior)
> in this and other mailing lists is down right shameful.
>
> Anybody who are genuinely trying to help, contribute or just get
> involved all too often have their efforts publicly belittled.
>
> Polite criticism and guidance is always the better option and
> encourages people to join in rather than frightening them off.
>
> Arrogance (Ar"ro*gance) (#), n.
> [F., fr. L. arrogantia, fr. arrogans. See Arrogant.]
"LA Walsh" <[email protected]> writes:
> If you are identified with your work, then any questioning about the
> 'standard way of doing things' is an immediate threat that is to be
> eliminated, expeditiously. The strength of reaction is a gauge to the
> arrogant person's level of fear.
The original message had a rather obnoxious (and arrogant) tone, I
thought, which certainly didn't help.
-Miles
--
.Numeric stability is probably not all that important when you're guessing.
If Linux is to fulfil its potential and become the OS of choice for
home, office and server applications, we need to conduct ourselves in a
gown up manner and be, well, nice.
If I have an idea, but put it forward in the wrong forum, I would expect
to be politely redirected. "What the f**k has this to do with the
kernel? Go away" is not nice and will see the unlucky recipient
scuttling back to Windows.
If I present my work for peer review, I would invite and respect any
politely given criticism or advice. "What is this strange *crap*? This
will only get into the kernel over my dead body" is not the way to
secure ongoing efforts and enthusiasm.
And remember that people posting here for maybe the first time are not
aware of what has gone before, the unspoken rules and conventions.
And now I am guilty of being arrogant, and off topic.
Andrew
Miles Bader wrote:
> "LA Walsh" <[email protected]> writes:
>
>>If you are identified with your work, then any questioning about the
>>'standard way of doing things' is an immediate threat that is to be
>>eliminated, expeditiously. The strength of reaction is a gauge to the
>>arrogant person's level of fear.
>
>
> The original message had a rather obnoxious (and arrogant) tone, I
> thought, which certainly didn't help.
>
> -Miles
Andrew Walrond <[email protected]> writes:
> And remember that people posting here for maybe the first time are not
> aware of what has gone before, the unspoken rules and conventions.
Sure, but in general such first-time posters are pretty polite, or at
least, non-inflammatory, and as a result the responses are (usually)
fairly polite and helpful.
So while I sympathize with what you're saying, I find it pretty hard to
feel sorry for the original poster in this case.
[On a forum _intended_ for user support answers will be restrained and
polite no matter how boneheaded the request, but you really can't expect
every forum to be like that -- it's just not human nature.]
-Miles
--
Run away! Run away!