This issue of Kernel Traffic is dedicated to the people who died in the World Trade Center buildings, the Pentagon, and the four hijacked planes.
I don't know anyone, in the US and abroad, who was not overwhelmingly affected by the attack. My roommate knew someone on one of the planes. My mother was in Manhattan at the time, half a mile away from the World Trade Center, and watched them from her window as they fell. I've heard dozens of stories over the past week, of people who knew people who by chance were spared, or who's fate is still not known.
Unfortunately, in the absense of a known or accessible enemy, many Americans are blaming Arab people in general, and street-violence against them has already increased. It's important, when confronted with violence against ourselves, that we not sink to the level of our attackers. Just as innocent people were struck at random on Tuesday, so now many Americans are striking innocent people at random today. Don't these Americans tend to legitimize that form of combat by engaging in it themselves?
Likewise, I feel it is important for the United States government to recognize and affirm the self-imposed limitations that give it much of its value as a government. If it decides to set aside a regard for human rights in its quest to stop these sorts of attacks, then the laws and precedents set in the coming weeks and months will remain in place for a long time to come, and will be very difficult to overturn later. And by discarding human rights even in part, will America not then be legitimizing other countries that do the same?
These are difficult days, requiring thought, introspection, and study. Hopefully America and the world will rise to the occassion.
Robert Love announced:
Available at (about 29K):
http://tech9.net/rml/linux/patch-rml-2.4.10-pre4-preempt-kernel-1
http://tech9.net/rml/linux/patch-rml-2.4.9-ac9-preempt-kernel-1for kernel 2.4.10-pre4 and 2.4.9-ac9, respectively.
Changes since previous post:
- update for new kernels
- fix newline/space format buglet
Changes since original patch:
- * fix compile bug -- CONFIG_HAVE_DEC_LOCK is set as needed, now.
This patch allows a new config setting, CONFIG_PREEMPT (set in `Processor Type and Features') that enables a fully preemptible kernel. Preemption is controled via SMP lock points. Control of execution is yielded to higher processes even if the currently running process is in kernel space.
This should increase response and decrease latency, and is a highly recommended patch for real-time, audio, and embedded systems. However, it is recommended for anyone. I use it on my everyday workstation.
An interesting new article on a preemptible kernel in linux is available at:
Phillip Susi asked, am I correct in assuming
that this only allows preemption during code that is called from user space?
For instance, it would be bad to preempt an ISR or BH, right? Actually... what
happens if say, the kernel called from user space is holding a lock, and gets
preempted?
Daniel Phillips replied, The
thread will eventually get rescheduled and release the lock.
Elsewhere, under the Subject: Linux Preemptive patch success
2.4.10-pre4 + lots of other patches, Christoph Lameter reported success
with the patch under 2.4.10-pre4, and said he wished it would get into the
kernel soon. He added, Given the minimal nature
of the patch I would suggest that it become part of 2.4.10 or 11
But Robert replied:
Are you kidding? We will be lucky to see this in during 2.5.
Its a pretty big change. It makes the Linux kernel preemptible. This is a fairly big move, one I don't think any of the major Unices have done. The only reason the patch is not _huge_ is because the Linux kernel is already setup for concurrency of this nature -- it does SMP.
I suggest you read
http://www.linuxdevices.com/articles/AT4185744181.html
http://www.linuxdevices.com/articles/AT5152980814.html
http://kpreempt.sourceforge.netand my previous threads on this issue, for more informaiton.
Daniel Phillips said it could always be made into a config option,
and added, The other Unices are at least
evenly split, or mostly preemptible. Typically, a more complex strategy
is used where spinlocks can sleep after a few spins. This patch is very
conservative in that regard, it basically just uses the structure we already
have, SMP spinlocks.
Elsewhere, Robert asked which UNICES were preemptible, since he'd been under
the impression Irix was the only one. Chris Ricker replied, Solaris is, and has been since good ol' Solaris 2.0. So's AIX and
even more obscure things like DG/UX. I'd think all SysVR4 derivatives have to
be, by virtue of the SysV schedular (threads have priorities from 0 to 159;
system threads run from 60 to 99, so the schedular must be able to preempt
system threads for the real-time threads from 100 to 159).
Elsewhere, under the Subject: Trouble with update Preemptive
patch for 2.4.9-ac9, Jordan Breeding reported an oops with an SMP
kernel 2.4.9-ac9, and Robert replied, I will take
a look at this, but note that currently the patch is experimental with SMP
enabled.
Stephen Frost volunteered to be an SMP guinea-pig for the
patch, and Robert said:
I would certainly take you up on that offer. I honestly don't think the patch is ready for SMP, yet -- but we have to start somewhere.
apply the patch and set CONFIG_SMP and CONFIG_PREEMPT to 'y' and let it run. Any errors, OOPS, etc, pass them this way.
Unfortunately, if the patch fails, its going to fall hard. If the preemption is imperfect during SMP, certainly you will hardlock.
It might help to enable CONFIG_DEBUG_SPINLOCKS and CONFIG_DEBUG_BUGVERBOSE -- these are present in the -ac tree. The NMI watchdog might prove useful, too.
But honestly, just telling me it locks on boot is useful, so whatever you can manage.
Alex Deucher announced, I just received the
documention for the IDE conrollers in may older Toshiba notebooks. These
controllers are capable of DMA, but at the moment do not have it implemented.
I know nothing about programming IDE drivers, so if anyone is interested in
developing these drivers shoot me an email and I can send you the docs and
help with testing (I have several notebooks to test on). I'd like to get
into it myself, but just don't have the time.
Andre Hedrick replied,
Sure send the docs over!
Andrew Morton announced his latest ext3 patch:
Patches against 2.4.10-pre4 and 2.4.9-ac9 are at
http://www.uow.edu.au/~andrewm/linux/ext3/
It's a fairly large change. The most significant parts are
- the inclusion of Stephen's error-handling work, which is designed to remount the fs read-only in the presence of software and hardware errors, rather than forcing a panic.
- Stephen's fix for the journal_revoke assertion failure which three people have reported.
There have been two reports of a possible interaction problem with vfat where a readdir on the vfat mountpoint returns ENOTDIR when ext3 is present in the kernel. This has proved elusive and in fact has been observed on systems where ext3 was never used. It is probably a vfat bug.
At the above website there is also a patch from Ted Ts'o which will provide significant speedups for accessing large directories. Ted's equivalent patch for ext2 has already been incorporated into the official kernel(s). If possible, please test Ted's patch on top of ext3 0.9.9.
Steve Kieu reported a system lockup when exiting X, if an Internet
connection was active. He listed among his system components, Lucent software modem using lt-modem driver version
5-99b
. Alan Cox replied, Please report problems
with binary only drivers to the driver vendor, it could be any kind of
incompatibility and as we have no source only they can help you.
Horst von Brand suggested checking out the latest driver, somewhere on
http://www.heby.de. Steve tried it and
it worked.
Shmulik Hen of Intel asked, When developing kernel
drivers (module) for ia64, is it necessary to do it on an ia64 machine?
Our product contains a pre-compiled core object (IP protection :-\ ) and a
set of wrapper source files, so for dual platform support the tar ball has to
contain both an ia32 and ia64 versions of the executable. Is there any way to
get an ia64 compiler (and libs) installed on an ia32 machine and use it to get
ia64 compatible binaries?
Arjan van de Ven replied, I would seriously recommend to intel to consider NOT doing
this. Binary only modules are generally frowned upon and there is (almost)
never a good reason for doing them.
David Woodhouse also replied
to Shmulik, This list is for people interested
in Linux, which is Free Software. If you are not working on Free Software,
then your message is off-topic, and offensive to many. You should not expect
to get any assistance here. Please go away.
Alan Cox also replied
to Shmulik, Our operating system contains a GPL license
(IP protection ...) that makes the whole issue questionable. Remember the GPL
forbids linking of non GPL code.
He added, If
you are doing proprietary software please take it off this list. Perhaps you
should get a paid support contract for the compiler.
Rik van Riel
also replied to Shmulik, Your email address has
been saved, bug reporters about any intel binary only driver will be told
to ask you.
At some point, Shmulik said, I would like to take
back my question regarding this closed source development. It is indeed not
the community role to support non GPL development and I'm sorry for bothering
you. The product I was referring to is not a hardware device driver (which
are all open source).
End Of Thread. Although the code in question was not a kernel module, the reaction it received shows the general attitude of linux-kernel to binary-only modules.