X-Authentication-Warning: 486dos.solucorp.qc.ca: jack owned process doing -bs
Date: Mon, 23 Sep 1996 17:02:48 -0400 (EDT)
From: Jacques Gelinas <jack@solucorp.qc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 22 Sep 1996, JF Martinez wrote:
> I think you should have frozen development in 2.0 on features who
> cannot reach production quality on it. I am as eager as everyone in
> getting SMP but this has broken 2.0 in at least one occasion and will
> be usable (that is robust and fast) only in 2.1. IMHO these parts
I suggest you ask one of the seven C++ programmer at my office if they
feel you can take one of the CPU out of the dual Pentium server for a
ride. All theses fellows are working with of X terminal out of this
machine. It is fast and reliable. I know, I have done it (Reboot with a
non SMP kernel just to see: They did not like it).
My view of the smp stuff in the late 2.0 series is exactly the opposite.
Some fixe have been made to hardware (IRQ) management to please some
special hardware and the SMP went broken because of that. Maybe I have
not understood the story.
> should be developped only in 2.1. In 2.0 work is supposed to focalize
> in fixing bugs on 2.0 features.
Life is not easy and market pressure is not either: This is the story
behind 2.0 (and the story of success also).
--------------------------------------------------------
Jacques Gelinas (jacques@solucorp.qc.ca)
Linuxconf: The ultimate administration system for Linux.
see http://www.solucorp.qc.ca:/linuxconf
By reading Documentation/SMP.txt I deduced SMP was very alpha because
it says to backup disks first (Alan Cox has mailed me SMP is stable).
And I have seen people having problems due to a remapping of
interrupts needed for SMP.
Perhaps the SMP exemple is not good but I think the general idea is
good: not letting development on 2.1 and 2.2 features breaking 2.0
Two months ago I had an exchange of mail with you I was enable to
continue due to mail bouncing repeatedly.
It was about modules: I complained some of CD drivers did not work
when loaded by kerneld. You told me you did not saw the difference
between kerneld and a maual insmod.
The problem is one of timing: it happens when a CD device is used
immediately after the driver is loaded. This happens when a mount
causes kerneld load the driver but also if you put in a script:
modprobe /mnt/cdrom
mount /mnt/cdrom
If you type it by hand all works but in a script the driver is loaded
resets the device and returns. The device then does asynchronously a
check to verify if there is a CD in drive. But now the mount command
is executed before the device has finished checkung and returns "no CD
in drive". That happens with my Mitsumi (mcd) at home and with my
Toshiba (scsi) at work. Both are double speed.
I also tested LinuxConf on RedHat great but:
1) I really like the way RedHat configures what has to start at boot
because it involves no file modification only file insertions and
deletions and that is a lot safer than editing files. And I like
their tool for this.
2) And more annoying it let me on US keyboard and I saw no choice to
revert to the french one.
3) I saw no clear way (and had no time) to make an RPM of it.
--Jean Francois Martinez
Join the Free World side in the holy war against Microsoft's Evil Empire. (Ronald Reagan)