If I remember correctly, sometime around the 2.1.44 - 2.1.50 era, when
kerneld was replaced by kmod, Linus had mentioned something to the fact that he
does not use modules. Those that are maintaining the part of module development
would know what to do with modules. Plus, that's where configuring comes in, in
a developmental series. YOU get to choose what YOU want to go into the kernel,
or what *YOU* want to have modularised. That is a choice everyone makes. I make
it. everyone else does too.
> > It works both ways, you see. You get to use the collective work of
> > the kernel developers, essentially for free, but when something fails
> > it is *your* responsibility to do your part to at least submit a bug
> > report. And submitting a bug report requires no particular skill, so
> > anyone can do it.
>
> This is not true.
> See the tons of "I compiled it, you know, and then I copied the kernel,
> you know, and then I ran lilo, you know, and then I booted, you know,
> and then it didn't work." 'bug reports'.
Once again, as someone else had previously listed, the whole bottom
third of /usr/src/linux/README covers what to do if something goes wrong. This
could fall under RTFM, but I won't go down that road. Same thing applies to the
2.2.x tree, when things are stable. you can't predict when a bug comes up, or
that everything will be idiotproof.. But Linus, Alan, and everyone else here,
does a damn good job of getting close to it. :)
> > Granted, on an officially stable kernel, compile errors should not
> > occur, but if they do it is simply because either no one (that means
> > us) bothered to try out the pre series of kernels leading up to it and
> > report the problem.
>
> I don't think it is too much to ask that before you release a kernel,
> you try to compile it. If it is a stable kernel, then compile it twice,
> once with everything as a module, once with everything linked it. That
> should be the bare minimum that just has to be done before you release a
> kernel. Should Linus really be unwilling to do that, then he should
> just post an URL to a /private/ directory here so someone can grab it
> and do both compiles.
You know.. he sort of does that. If you've noticed, there is
linux-kernel-announce, in which you are announced when kernels are released. If
you have the time to go on regarding this, it should take just as long to do
both of these compiles, on a 4-way pentium. Plus, you may also want to consider
doing that on all the architectures that is supported under Linux. (Note: I
still haven't seen an Atari 68000K machine running linux yet. VIC-20, yes.
Apple IIe, yes. anything else, no.) Plus, as mentioned before, Linus doesn't
use modules.
> > > 4. FAT. 2.3.7 does not compile with FAT file system. Excuse me?
> > > This is the single most frequently used file system besides ext2,
> > > and 2.3.7 does not compile with it? Because of a syntax error?!
> > Details? Details are the difference between a rant and something
> > helpful, useful, and constructive.
>
> It does not compile.
> Details won't help you, since even if I gave you details you would still
> need to verify them and try to compile it yourself and then you would
> notice that FAT does not compile. Please note that I said "does not
> compile" and not "does not work" or "panics at mount time". This is
> some objective bug report that anyone can verify immediately.
Isn't this what a mailing list, such as this, is for? Linus even
mentioned when 2.3.7 was released, that there may be compilation problems, due
to new things he was developing. Also.. what about those, who don't need to use
FAT at all? for the most, the bug report may not apply. My box is using
linux totally, but I have FAT compiled as a module. I took the notes that Linus
sent, as a warning when using the kernel. There's always going to be some
problem in a devel series. when they come up, we fix it. that's what
'developmental' is all about!
> > Also, does it really surprise you that a development kernel in
> > general, and one in which *major* changes have been made and well
> > publicized, in particular, might have some problems in the areas
> > directly involved in the changes.
>
> Sorry, but if the second most frequently used file system does not
> compile, then don't release it. I am not counting the pseudo file
> systems proc and pts here, obviously.
Once again, what about those that don't use it at all? should they
suffer a set back in development, because of this?
> > > Management summary: stuff like this sucks. I am but a programmer with a
> > > SMP box that likes to run the latest kernel. And yes, I expect all the
> > > kernels to compile out of the box. I don't think that this is too much
> > > to ask.
> > It is not too much to expect other people to give you something that you
> > want, without your incurring even minimal responsibilities?
> Huh?
> Please think your answer over.
> It is people like me who do the quality assurance for Linux.
> People like me who complain. And if there is just _one_ goof like the
> FAT problem, there are literally thousands of people who will run into
> this problem and be discouraged to upgrade their kernel in the future.
If you're doing quality assurance for linux, then doing it in a
Developmental series is _NOT_ the right place to do it. stick that, back with
2.2.x, or please be like others, and wait patiently, until things have settled
and the bug fixed, and resume. Or, do more above that, and HELP IN SOLVING it.
Ranting won't get the problem solved.
BL.
--
Brad Littlejohn | Email: tyketto@omnilinx.net
Unix Systems Administrator, | tyketto@acm.unomaha.edu
WebMaster, NewsMaster.. Smeghead! :) | http://www.omnilinx.net/~tyketto
PGP: 1024/E9DF4D85 67 6B 33 D0 B9 95 F4 37 4B D1 CE BD 48 B0 06 93
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/