Skip to contentSkip to conversation

A Kernel Configuration Tale of Woe

DISCUSSION Dennis Grant 7 participants 9 messages Nov 25, 2002 – Nov 29, 2002

lore
Share & tools
lore
#0 lore raw
Quoted 4 lines
Quoted 2 lines · Richard B. Johnson

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

#1 lore raw
Quoted 7 lines · Dennis Grant
Quoted 4 lines
Quoted 2 lines · Richard B. Johnson

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.

Quoted 2 lines

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.

Quoted 2 lines

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"

Quoted 1 line

that abstracts away most of the lower level items based on what low-level

<added wrap> stuff

Quoted 1 line

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..."

Quoted 2 lines

I'm pretty sure any time you're invoking the kernel Makefile that you're

<added wrap> discussing

Quoted 2 lines

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.

Quoted 1 line

Point #2 has to do with the messages that drivers, modules, and other bits

<added wrap> of

Quoted 2 lines

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.

Quoted 8 lines

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

Quoted 1 line

in what kernel version, and where drivers not currently contained in the

<added wrap> vanilla

Quoted 2 lines

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.

Quoted 7 lines

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

#2 lore raw
Quoted 5 lines · Richard B. Johnson

...
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

Signature · 4 lines
       "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
#4 lore raw
In reply to Dennis Grant

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.

Quoted 61 lines
Quoted 4 lines
Quoted 3 lines

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/

#3 lore raw
In reply to Adrian Bunk
Quoted 4 lines

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

#5 lore raw
In reply to Andrew Walrond

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

Quoted 12 lines

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.]

#6 lore raw
Quoted 4 lines · LA Walsh

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

Signature · 1 line
.Numeric stability is probably not all that important when you're guessing.
#7 lore raw

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

Quoted 12 lines · Miles Bader
Quoted 4 lines · LA Walsh

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

#8 lore raw
Quoted 2 lines · Andrew Walrond

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

Signature · 1 line
Run away!  Run away!