On Sat, 10 Apr 1999, Doug Ledford wrote:
> We decided not to ship an SMP kernel with Red Hat Linux 5.2 because we
> knew that there were some problems with 2.0.36 SMP. There were lots of
> people that could do OK with it, but then there were other systems that
> simply wouldn't work at all. Then there were the occasional lock up
> problems. Then there was the occasional SCSI sub-system goes belly up
> problem with my driver that's in the stock 2.0.36 (which I fixed in the
> 5.1.12 driver version just recently).
>
> Originally, if we released a 2.0.36 SMP kernel RPM, people would be mad
> that we shipped something that wasn't 100% "up to snuff" so to speak. I
> would also feel like we fell down if we did that. People rely on us to
> not only package things up, but to try and reasonably make sure those
> packages work. Shipping a known busted package would violate that
> expectation. At this point in time, with all of the patches there are
> for 2.0.36 it *might* be possible to do an SMP kernel and finally feel
> good about it.
Hmmmm, it might be worth noting that linux has never worked on
"everything" and probably never will -- the hardware side moves, the
software side moves, everything is dynamic and there are always bugs and
broken things. So your observation that there are occasional problems
with 2.0.36 (or any other revision) SMP isn't really an adequate excuse
for not supporting it even on a "at your own risk" basis with RPM's.
After all, 2.0.36 UP has occasional problems on at least some hardware
but it doesn't stop RH from selling Linux with 2.0.36 UP, and 2.0.x SMP
has run on "most" hardware combos for years now. I find the conservative
turn RH is taking to be a bit disturbing.
Still, corporate policy is corporate policy, so let's accept it for the
moment. The real question, Doug, is why doesn't RH provide "make
install"-ready kernel sources in /usr/src/linux, installed by default,
in the 5.2 installation? To quote from the GPL:
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
Now, you can argue that anybody who wants can get linux source from the
net, but not everybody has net access and many who do have 56K or slower
access. One of the major reasons for buying a distribution CD,
actually. Downloading kernel sources at 56K is painful to say the
least. It is also not clear how RH (or anybody else) can properly "show
them these terms so they know their rights" any more simply than by just
providing the source where it belong.
RH is complying with the letter, but not with the spirit, of the GPL and
linux itself by not providing the kernel sources (the sine qua non of
the package, of course) of all the sources possible, with each
distribution, whether or not a user knows enough or has the means to be
able to go find them or retrieve them by other means.
Of course, the main PRACTICAL reason to provide the sources in EXACTLY
the form used to build and install the RH kernel is that, given the
.config file and the mods to the Makefile required to make it install
according to the RH prescription (make all the modules, install in
/boot, create various symlinks and so forth) one could, if one wished,
go to the kernel source directory, edit the Makefile to uncomment the
SMP = 1 line, and type "make install". It's not just novices that would
appreciate this -- I wouldn't mind it myself. And of course it would
make supporting Dell's entire line of SMP servers straightforward, since
their hardware is known to work fine with the stock 2.0.36 kernel.
Isn't RH taking a terrible risk by NOT doing this that both Dell and
innocent users who buy high end Dell 2300 and 6300 systems with the not
unreasonable expectation of being able to run a supported SMP linux on
the systems will get irritated enough to bag linux altogether and RH in
particular? You've already heard from at least ONE user who bought from
Dell with precisely this expectation and was astounded to learn that
after all the media hooraw over RH linux on Dell servers, only one
processor worked of his many and neither Dell nor RH was prepared to
help him get the rest going!
I know for a fact that Dell can manage an SMP NT install on those
particular beasts...however poor it may be.
If you worry about users' ability to do a kernel rebuild with just one
line altered, one could easily enough build a few hundred line perltk
GUI to front end the whole thing for them so that they never even needed
to know what they were doing -- just click a checkbox for SMP, click a
button labelled "Reinstall Kernel" and wait. Why, you could even make
the GUI install a sane lilo.conf in prompt mode with the distribution
kernel, properly announced via lilo.msg, still available as a fallback.
Speaking from direct personal experience, one could write such a perltk
application in ten hours or less. In fact, since I have almost all the
code required already written in apps I'm working on which I'd be happy
to donate, you could probably cut the development time down to a couple
of hours.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
