Kernel Traffic #267 For 18 Jul 2004
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Czech Translation
* Mailing List Stats For This Week
* Threads Covered
1. 9 Jun 2004 - 23 Jun 2004 (33 High-Res Timer (HRT) Support For 2.6;
posts) Some Debate Over Alternatives
2. 15 Jun 2004 - 22 Jun 2004 (12 Support For RSA Crypto API In 2.6
posts)
(40 Linux 2.6.7 Released; ESSID Bug
3. 15 Jun 2004 - 19 Jun 2004 posts) Introduced; SiS900 Full-Duplex Fix Not
Applied
4. 16 Jun 2004 - 17 Jun 2004 (5 Generic SCSI Build Target With Target
posts) Drivers
5. 16 Jun 2004 - 17 Jun 2004 (11 Linux 2.4.27-pre6 Released
posts)
6. 17 Jun 2004 - 21 Jun 2004 (7 Status Of Moxa Serial Card Support
posts) Under SMP
7. 18 Jun 2004 - 19 Jun 2004 (8 Input Patches; serio SysFS Integration
posts)
8. 18 Jun 2004 (1 USB Updates; New Host Controller
post) Driver For lh7a404 Deavices
9. 19 Jun 2004 - 20 Jun 2004 (3 Linux 2.4.27-rc1
posts)
10. 20 Jun 2004 - 22 Jun 2004 (23 Linux 2.6.7-mm1 Released
posts)
11. 21 Jun 2004 (1 Videotext Driver Comment For SAA5246A
post) Decoder Support
12. 21 Jun 2004 - 23 Jun 2004 (5 Status Of linux/802_11.h, Used By Some
posts) 3rd Party Drivers
13. 23 Jun 2004 (4 Precise CPU Accounting Patch Ported
posts) From 2.4 To 2.6.7
14. 23 Jun 2004 - 24 Jun 2004 (7 Status Of Preemption/Low-Latency In
posts) 2.6.7
15. 23 Jun 2004 - 24 Jun 2004 (17 Policy For Using GCC Built-Ins
posts)
16. 24 Jun 2004 (1 Enhanced Linux System Accounting
post) (ELSA) Updated For Linux 2.6.7
Mailing List Stats For This Week
We looked at 2195 posts in 12920K.
There were 555 different contributors. 287 posted more than once. 173 posted
last week too.
The top posters of the week were:
* 84 posts in 512K by Greg KH
* 55 posts in 234K by Andrew Morton
* 53 posts in 250K by William Lee Irwin III
* 53 posts in 242K by Jeff Garzik
* 48 posts in 252K by Sam Ravnborg
* Full Stats
1. High-Res Timer (HRT) Support For 2.6; Some Debate Over Alternatives
9 Jun 2004 - 23 Jun 2004 (33 posts) Archive Link: "[ANNOUNCE] high-res-timers
patches for 2.6.6"
Topics: Microkernels: Adeos, POSIX, Real-Time: RTAI, Real-Time: RTLinux
People: Geoff Levand, William Lee Irwin III, George Anzinger, Arjan van de Ven
, Karim Yaghmour
Geoff Levand said:
Available at http://tree.celinuxforum.org/pubwiki/moin.cgi/
CELinux_5fPatchArchive
For those interested, the set of three patches provide POSIX high-res timer
support for linux-2.6.6. The core and i386 patches are updates of George
Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge . The ppc32 port is not available on
SourceForge yet.
William Lee Irwin III said he'd been under the impression that George
Anzinger's patches had already been merged into the 2.6 kernel. He added, "At
the very least there's already a kernel/posix-timers.c" . Someone else, in
reply to this, said that the POSIX interface of the timers was what had
actually been merged. The patches to obtain resolution on the order of 10
microseconds, the person said, had not been merged into the official 2.6 tree.
William replied, "That sounds useful. Any chance you could post them to lkml
for review? They're significantly less likely to actually be looked at and/or
included if ppl have to chase URL's."
Elsewhere, Arjan van de Ven complained about the large number of #ifdefs in the
patch. He suggested that if the code were made non-optional, but just a core
kernel feature, a lot of this could be cleaned up. George Anzinger replied,
"this would break all the archs that don't have the needed arch dependent code
yet. By making the high-res part depend on the arch config turning on a config,
we don't break the archs and they can sign up as they get their act together."
Arjan said, "if the price is this amount of uglyness then that's the wrong
approach imo. Would be nicer to make dummy helpers the arch people can just
take during the transition instead." George came back with, "I have another
solution, connected with the ability to turn it off at boot time. Unsupporting
archs would just not define a flag." At this point various folks descended into
technical issues.
Elsewhere, Karim Yaghmour said:
Just reading from the Posix 1003.1b section 14 spec referenced by the HRT main
project page, I see the following:
Realtime applications must be able to operate on data within strict timing
constraints in order to schedule application or system events. Timing
requirements can be in response to the need for either high system
throughput or fast response time. Applications requiring high throughput
may process large amounts of data and use a continuous stream of data
points equally spaced in time. For example, electrocardiogram research uses
a continuous stream of data for qualitative and quantitative analysis.
If this is really the goal here, then why not just integrate Adeos into the
kernel and make some form of HRT as a loadable module that uses Adeos to
provide its services?
Currently Adeos runs on x86, ARM (MMU-full and MMU-less), PPC, so portability
is not an issue. Plus, the interface provided can either be directly used by
drivers to get hard-rt interrupts or it can be used by another layer to provide
more elaborate services (like RTAI or, potentially, HRT.) Using the virtual
interrupts that can be dynamically allocated at runtime, it's rather easy to
send signals between domains.
Sure, you may not have the exact Posix 1003.1b API, but I don't remember there
being any persistent goal of having the kernel conform to any standard.
George replied, "I don't see how this delivers any added value to the user. I
suppose code running at the kernel level might gain something, but at the user
level we still have to deal with preemption latencies, which are the biggest
problem (and, aside from messing up the accuracy of the timers, are NOT timer
issues at all)." Karim said:
Actually I think the point I'm trying to make can't be fairly conveyed without
providing a lot of background of what can be done with Adeos. I would suggest
that those interested do some digging. Among other things, you may want to read
about RTAI/fusion:
http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/rtai-fusion.html
http://www.fdn.fr/~brouchou/rtai/modules.php?name=Content&pa=showpage&pid=1
George replied:
I think the real problem is an open source question. The RTAI and RTLINUX folks
are not exactly in the same camp (either with each other OR with LINUX) in this
regard. Should that change and one or more of these become truly open source
without others claiming "foul", there are vendors who are ready and willing to
work with the code. Vendors of open source (and their customers) don't want to
find themselves in law suits...
As such, this is really off topic... as is a discussion of the merits of this
sort of solution. On this list we are interested in working in the confines of
LINUX as found on linux.org possibly modified by truly open source patches and
packages.
Karim said that George's was an ignorant view, and said, "RTAI has always been
and will always been "open source". I'm not going to qualify other peoples'
claims against it, but let me just say that you've succumbed to FUD" . There
was no further discussion on that point, however.
2. Support For RSA Crypto API In 2.6
15 Jun 2004 - 22 Jun 2004 (12 posts) Archive Link: "RSA"
People: Joy Latten, Kristian S?rensen, Serge E. Hallyn, Tom St. Denis, James
Morris
Joy Latten asked, "Is anyone working on implementing RSA encryption/decryption
into the kernel's cryptoapi? If not, I was considering starting such a
project." Kartikey Bhatt said he'd like to contribute to such a project; and he
and Joy took that discussion to private email. Kristian S?rensen also said to
Joy:
The Umbrella project (umbrella.sf.net (http://umbrella.sf.net) ) also needs the
ability to use public key cryptography within the Linux kernel (though only to
verify signatures).
We were planing to implement RSA or ElGamal (porting some of GPG) to the kernel
for that purpose. However, if this project gets started, we will be very
interested. In the automn we might also have some development hours to
contribute with :-)
Elsewhere, James Morris asked if Joy, Serge E. Hallyn and the other folks on
the project were trying to create a generic asymmetric cryptographic API; Serge
replied:
Is a separate generic assymetric crypto API really necessary?
The cryptoapi usage model is to do a setkey before any encrypt or decrypt. The
setkey will be done with either a public or private key. So there is no need to
have a public_key_alg with separate public_encrypt and private_encrypt
functions, as this distinction is implied at the setkey time. So our plan was
to just add another crypto_alg for rsa_1024.
If anyone can point out why this is insufficient, then we will certainly
reconsider.
Tom St. Denis replied:
In essence for a digsig module you'll require the ability to
1. import a PK key [from a binary packet or a cert, preferably the former].
2. free a PK key from memory (no need to waste dynamic resources like bignums
while not being used).
3. ability to sign/verify/encrypt/decrypt which amounts to a exptmod and PKCS
#1 [v2.0 preferably] padding.
An API exactly mirroring the symmetric side won't really work 100%. For
instance, symmetric operations are not likely to fail [I don't know how error
handling is performed]. Also decrypt/verify ops may fail hard [due to lack of
heap] or soft [invalid packet].
It would probably make more sense to design a simple API for PK crypto [say
support RSA/ECC/DH/DSA ;-)] then to mash the symmetric crypto API into
something compatible.
On a side note I've been contacted about my interest in making this happen
[hence my reply here]. I'm offering my public domain LibTomCrypt [and
indirectly LibTomMath] for the task. Currently I'm working on reducing the
stack usage in LibTomCrypt's PK operations.
What I propose is we can port LibTomCrypt's [by stripping out stuff that isn't
required like symmetric crypto] PK code to a kernel module to be released under
the GPL. Since the code is already public domain [and I personally wrote all of
the relevent code myself == no copyright issues] there shouldn't be any
problems with this.
He and Serge went back and forth on the technical issues, and them possibly
took the conversation off-list. Serge was thrilled with Tom's contributions,
and especially with the availability of Tom's code.
3. Linux 2.6.7 Released; ESSID Bug Introduced; SiS900 Full-Duplex Fix Not
Applied
15 Jun 2004 - 19 Jun 2004 (40 posts) Archive Link: "Linux 2.6.7"
Topics: Kernel Release Announcement, Networking, PCI
People: Linus Torvalds, Tomas Szepe, Alexander Viro, Dominik Karall, Jeff
Garzik
Linus Torvalds announced Linux 2.6.7, saying, "The most notable change may be
the one-liner that should fix the embarrassing FP exception problem. Other than
that, we've had a random collection of fixes and updates since rc3. cifs, ntfs,
cpufreq. ide, sparc, s390." Tomas Szepe replied:
2.6.7's airo.ko (unlike 2.6.6's) won't allow the user to set ESSID via "echo
myessid >/proc/driver/aironet/ethX/SSID".
Changes like this shouldn't probably be made in the middle of a stable series.
Alexander Viro replied with a short patch, saying, "Changes like this are
called bugs. The thing is, original variant of function (actually, both read
and write) was also buggy and trivially exploitable, so fixing it was needed.
Fscking it up was not, obviously." Tomas tried Alexander's fix, and confirmed
that it worked.
Elsewhere, Dominik Karall asked, "Is there any reason why the
sis900-fix-phy-transceiver-detection.patch wasn't moved to the stable tree?
It's a now for a long time in -mm patches and without that patch, a lot of
sis900 cards does not work in full-duplex 100Tx-FD mode." Jeff Garzik replied,
"It still needs work, as the updated driver appears to scan the first phy
incorrectly, which IMO would break _other_ situations that are presently
working. I'll try to get to it in the next couple days; the short answer is to
look at other PCI ethernet drivers and note how they scan MII."
4. Generic SCSI Build Target With Target Drivers
16 Jun 2004 - 17 Jun 2004 (5 posts) Archive Link: "[ANNOUNCE] Generic SCSI
Target Middle Level for Linux (SCST) with target drivers"
Topics: Disks: SCSI, SMP
People: Vladislav Bolkhovitin, Matthew Wilcox, Christoph Hellwig
Vladislav Bolkhovitin said:
I would like to announce the first public release of a generic SCSI target
middle level subsystem for Linux (SCST) with Qlogic 2200/2300 target driver and
a patch for for UNH-iSCSI Target 1.5.3 to work over SCST.
SCST is designed to provide unified, consistent interface between SCSI target
drivers and Linux kernel and simplify target drivers development as much as
possible. It has the following features:
* Very low overhead, fine-grained locks and simplest commands processing
path, which allow to reach maximum possible performance and scalability
that close to theoretical limit.
* Incoming requests can be processed in the caller's context or in one of the
internal SCST's tasklets, therefore no extra context switches required.
* Complete SMP support.
* Undertakes most problems, related to execution contexts, thus practically
eliminating one of the most complicated problem in the kernel drivers
development. For example, a target driver for Qlogic 2200/2300 cards, which
has all necessary features, is about 2000 lines of code long, that is at
least in several times less, than the initiator one.
* Performs all required pre- and post- processing of incoming requests and
all necessary error recovery functionality.
* Emulates necessary functionality of SCSI host adapter, because from a
remote initiator's point of view SCST acts as a SCSI host with its own
devices. Some of the emulated functions are the following:
+ Generation of necessary UNIT ATTENTIONs, their storage and delivery to
all connected remote initiators (sessions).
+ RESERVE/RELEASE functionality.
+ CA/ACA conditions.
+ All types of RESETs and other task management functions.
+ REPORT LUNS command as well as SCSI address space management in order
to have consistent address space on all remote initiators, since local
SCSI devices could not know about each other to report via REPORT LUNS
command. Additionally, SCST responds with error on all commands to
non-existing devices and provides access control (not implemented yet),
so different remote initiators could see different set of devices.
+ Other necessary functionality (task attributes, etc.) as specified in
SAM-2, SPC-2, SAM-3, SPC-3 and other SCSI standards.
* Device handlers architecture provides extra reliability and security via
verifying all incoming requests and allows to make any additional requests
processing, which is completely independent from target drivers, for
example, device dependent exceptional conditions treatment or data caching.
Interoperability between SCST and local SCSI initiators (like sd, st) is the
additional issue that SCST is going to address (it is not implemented yet). It
is necessary, because local SCSI initiators can change the state of the device,
for example RESERVE the device, or some of its parameters and that would be
done behind SCST, which could lead to various problems. Thus, RESERVE/RELEASE
commands, locally generated UNIT ATTENTIONs, etc. should be intercepted and
processed as if local SCSI initiators act as remote SCSI initiators connected
to SCST.
Interface between SCST and target drivers is based on work, done by
InterOperability Lab (IOL) of University of New Hampshier (UNH).
In addition, the project contains a target driver for Qlogic 2200/2300 Fibre
Channel cards and a patch for for UNH-iSCSI Target 1.5.3 that makes it work
over SCST.
In the current version 0.9.1 SCST looks to be quite stable (for beta) and
useful. The same is for Qlogic 2200/2300 target driver. Only 2.4 kernels
currently supported, but update for 2.6 is coming soon. No kernel patches are
necessary. Tested on i386 only, but should work on any other supported by Linux
platform.
More information, including the source code and detail documentation, could be
found on http://scst.sf.net.
Matthew Wilcox asked, "Why does this need to be done in kernel space? My
impression was that an iSCSI target would best be done in userspace." But
Vladislav replied:
There is not only iSCSI target (i.e. software one) in the world. For hardware
targets if you were switch on each command (IRQ) to user space and back, it
would be huge performance penalty, especially for commands that request small
data transfers. Take a look on the Qlogic target: all job is done in the
tasklet, without ever context switch. The same is for upcoming iSCSI hardware,
like Qlogic QLA4010, which also supports target mode.
BTW, the processing is simple enough, the main SCST module is only about 60Kb
long. The main point is that this processing must be done in _each_ SCSI target
driver. So, consider SCSI target mid-level like a library (framework) for such
drivers, exectly as the regular SCSI mid-level for regular SCSI drivers.
Christoph Hellwig also remarked, "The code looks pretty neat to me, there's a
few issues I'd like to see addresses but that doesn't make sense before the 2.4
support is dropped and there's an actual LLDD for 2.6. But I think for most
interesting scenarios in the storage virtualization world your driver is pretty
much useless because it wants to dispatch directly to a scsi device and doesn't
go through the block layer. So no fancy volume managers/etc there to make
interesting storage virtualization boxes." To which Vladislav replied:
For that is intended upcoming block device handler with block layer/cache
support, which will be in its exec() method check, if requested blocks in
cache, and, if not, dispatch the commands to block layer, leaving regular
scsi_do_req() calls for tapes, changers, etc. In the similar way "_perf"
handlers work (they don't send READ/WRITE commands to SCSI devices for
performance studies).
This device handler is on our todo list. Actually, it's quite simple and if
anyone interested, he's help would be greatly appreciated.
5. Linux 2.4.27-pre6 Released
16 Jun 2004 - 17 Jun 2004 (11 posts) Archive Link: "Linux 2.4.27-pre6"
Topics: FS: JFS, USB
People: Marcelo Tosatti, Andreas Haumer
Marcelo Tosatti announced Linux 2.4.27-pre6, saying:
It contains a significant amount of USB fixes, JFS update, netfilter/sctp
fixes, CDROM driver update, tg3 update, SPARC/Alpha fixes.
And more importantly the FPU x86/x86-64 crash fix.
Andreas Haumer reported that 'make xconfig', broken also in -pre5, was still
broken. He posted a patch to fix it.
6. Status Of Moxa Serial Card Support Under SMP
17 Jun 2004 - 21 Jun 2004 (7 posts) Archive Link: "Use of Moxa serial card with
SMP kernels"
Topics: SMP
People: Bruce Marshall, Randy Dunlap, Stephen Lin, Jan-Benedict Glaw
Bruce Marshall wanted to use a Moxa serial card on his SMP system, but had been
told "back when 2.6.4 was new that the selection of a Moxa serial card was not
possible if an SMP kernel was selected." He asked if the situation had
improved, as he was anxious to reenable SMP on his system. Jan-Benedict Glaw
and Randy Dunlap confirmed that the problem had not been fixed, and that no one
was currently working on it. Randy said:
Both Moxa serial drivers (moxa & mxser) are BROKEN_ON_SMP because they use cli
() to disable interrupts for critical sections. See Documentation/
cli-sti-removal.txt for details. They will need some acceptable modern form of
protection there,
Is anyone working on this? not that I've heard of. Have you tried this email
address: support@moxa.com.tw
Bruce tried that address, and after a couple of private exchanges, received
this reply from Stephen Lin, a Moxa tech support fellow: "I've got updated news
from the R&D Div., they are testing the latest beta version of the driver for
all the Moxa cards, only they can not provide me with a precise schedule. Your
case will be remaining open until it is resolved, I will also keep you update
with the information."
7. Input Patches; serio SysFS Integration
18 Jun 2004 - 19 Jun 2004 (8 posts) Archive Link: "[PATCH 0/11] New set of
input patches"
Topics: FS: sysfs, Version Control
People: Dmitry Torokhov, Vojtech Pavlik, Jan-Benedict Glaw, Jan-Benedict, Linus
Torvalds
Dmitry Torokhov said, "Here is my new set of input patches, most important IMHO
is serio sysfs integration. It is not complete in sense that we need add
attributes to individual drivers (like rate and resolution and protocol to
psmouse) and create some platform devices for i8042, q40kbd, etc so serio ports
would have parents. But the core integration is done. Unfortunately I do not
have 90% hardware to test my changes so there could be some problems, although
I tried to compile everything I could. The patches are against Vojtech's tree
and should apply to -mm as well." Jan-Benedict Glaw complained that, as the
patches were created against Vojtech Pavlik's tree, they would not apply to
Linus Torvalds' version; making them harder to work with. Dmitry replied, "I do
not consider it tested enough to be ready for Linus yet :) I am thinking about
publushing my input-sysfs bk tree... Will there be an interest in it or you
just want a patch against the vanilla 2.6.7? I can do a wholesale patch but
splitting my changes from other stuff in Vojtech's tree does not sound very
appealing..." Jan-Benedict said that he'd really prefer a patch against the
Linus tree, but that he could try working on Vojtech's tree for the purposes of
this patch.
8. USB Updates; New Host Controller Driver For lh7a404 Deavices
18 Jun 2004 (1 post) Archive Link: "[BK PATCH] USB patches for 2.6.7"
Topics: USB, Version Control
People: Greg KH
Greg KH said:
Here are a number of various USB fixes and cleanups for 2.6.7. All of these
patches have been in the past few -mm releases.
There's lots of good stuff in here:
* gadget fixes
* new host controller driver for lh7a404 devices
* lots of hub locking rework to fix up the mess there.
* sparse markups to remove warnings
* loads of bugfixes.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/usb-2.6
Patches will be posted to linux-usb-devel as a follow-up thread for those who
want to see them.
9. Linux 2.4.27-rc1
19 Jun 2004 - 20 Jun 2004 (3 posts) Archive Link: "Linux 2.4.27-rc1"
Topics: Power Management: ACPI, USB
People: Marcelo Tosatti, Geert Uytterhoeven
Marcelo Tosatti announced Linux 2.4.27-rc1, saying, "It contains a handful of
ACPI bugfixes, HPFS update, USB fixes, amongst other smaller fixes." Geert
Uytterhoeven found some compile-time warnings that were introduced by this
patch, and posted another to get rid of them; which Marcelo accepted.
10. Linux 2.6.7-mm1 Released
20 Jun 2004 - 22 Jun 2004 (23 posts) Archive Link: "2.6.7-mm1"
Topics: FS: sysfs, Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.7-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/
* Added a new vm tunable: /proc/sys/vm/vfs-cache-pressure.
This allows tuning of the kernel's preference for reclaiming VFS caches
versus pagecache.
vfs-cache-pressure=0: dentry and inode caches aren't reclaimed at all
vfs-cache-pressure=100: default - current behaviour
vfs-cache-pressure > 100: reclaim the VFS caches harder.
It seems that large values of vfs-cache-pressure are needed to make much
difference: 1000 or more.
* Under some circumstances the current page reclaim code can hold interrupts
off for a long time. That is fixed here.
* I went through and dropped a bunch of patches which don't seem to be very
useful now - mainly debug stuff.
* Various driver updates and random fixes
11. Videotext Driver Comment For SAA5246A Decoder Support
21 Jun 2004 (1 post) Archive Link: "[PATCH][2.6][V4L] saa5246a Videotext driver
update"
People: Michael Geng
Michael Geng said:
I uploaded an update to the Videotext driver for the SAA5246A videotext decoder
in
http://www.michaelgeng.de/linux/saa5246a-2.6.7.patch
The update only changes comments showing that the driver also works for the
SAA5281 videotext decoder chip. This is not surprising because according to the
data sheet of the SAA5281 it is compatible to the SAA5246A. I have tested this
with a Siemens Multimedia Extension Board (MXB).
I also added MODULE_AUTHOR and MODULE_DESCRIPTION macros which were missing up
to now.
Patch comment:
V4L: saa5246a driver update, supports saa5281
Signed-off-by: Michael Geng
12. Status Of linux/802_11.h, Used By Some 3rd Party Drivers
21 Jun 2004 - 23 Jun 2004 (5 posts) Archive Link: "What happened to linux/
802_11.h?"
Topics: Version Control
People: Joshua Kwan, Andrew Morton, Jean Tourrilhes, James Ketrenos, David
Gibson
Joshua Kwan noticed that the linux/802_11.h file had disappeared from the
kernel sources; he asked what was up, since "The IPW2100 driver (http://
ipw2100.sourceforge.net) uses its definitions and now won't build against -bk
or -mm kernel source." Andrew Morton replied that the file had been removed
because nothing in the kernel had been using it. He asked Jean Tourrilhes,
"should we restore 802_11.h, or is there some alternative file which that
driver should be using?" Jean replied:
Well, Jeff explicitely said that we should not care about drivers outside the
kernel ;-)
Seriously, I see three solutions :
1. Convert ipw2100 to using drivers/net/wireless/ieee802_11.h, extend this
header as necessary
2. Have ipw2100 use a private version of 802_11.h
3. Convince us that this file is really needed (good luck) Obviously (1) is
better in the long term.
He also added that the linux/802_11.h file
was a remnant from the old aironet4500 driver that was removed during 2.5.X. It
was also confusing because there is a file called drivers/net/wireless/
ieee802_11.h that has a somewhat similar purpose and is used in various drivers
(Orinoco, Atmel). I think it was discussed on netdev.
I was not aware that IPW2100 was using it. I could not try this driver because
it doesn't compile with gcc 2.95.
James Ketrenos said of the first of Jean's three possible solutions listed
above (converting ipw2100 to use ieee802_11.h), that "This is the path I was
planning to take when I read about 802_11.h possibly going away a while ago.
The file finally going away will just raise the priority of that effort a bit
:) Changing the code to use the headers in drivers/net/wireless isn't a big
task -- I'll put the change into the next snapshot of ipw2100." Jean was fine
with this, and added, "BTW, I'm not the one maintaining ieee802_11.h, it was
originally created by David Gibson as part of the Orinoco driver. So, if there
is something you don't like in it, you may want to contact him."
13. Precise CPU Accounting Patch Ported From 2.4 To 2.6.7
23 Jun 2004 (4 posts) Archive Link: "PATCH: Precise Accounting for 2.6.7"
People: Timm Morten Steinbeck, Andi Kleen
Timm Morten Steinbeck said:
we have ported our x86 precise accounting patch from the 2.4 kernel series to
2.6.7.
The patch fixes a problem with the accounting via the "cpu*" lines from /proc/
stat. The standard kernels can produce misleading data for programs that give
up the rest of their timeslice, e.g. via usleep. This can lead to programs
using 90% or more CPU time which is not accounted. The computer is reported as
idle or another program seems to use up the time. The patch fixes the problem
by doing the accounting on the basis of the CPU's time stamp counter instead of
whole time slices. The patch as well as proof-of-principle programs
illustrating the problem can be downloaded at http://www.ti.uni-hd.de/HLT/
software/software.html#kernel.
Our original mail for the 2.4.20 patch is at http://lwn.net/Articles/24974/.
Please CC all comments to timm.steinbeck AT kip.uni-heidelberg.de and
arne.wiebalck AT kip.uni-heidelberg.de, as we are not subscribed to the LKML.
At first glance, Andi Kleen had some technical problems with this, but after
reexamining the code, he gave it his approval.
14. Status Of Preemption/Low-Latency In 2.6.7
23 Jun 2004 - 24 Jun 2004 (7 posts) Archive Link: "status of Preemptible Kernel
2.6.7"
Topics: Real-Time
People: Timothy Miller, Robert Love, Marcus Hartig
Marcus Hartig asked about the status of kernel preemption for real-time
processing in the 2.6 tree; and whether it was up to use on a normal desktop
system. Timothy Miller replied:
I vaguely recall someone recently talking about eliminating preempt by
improving low-latency. See, if everything were ideal, we wouldn't need preempt,
because all drivers would yield the CPU at appropriate times. Supposedly,
preempt introduces some undesirable overhead.
Perhaps we could turn preempt into some kind of watch-dog. If a kernel thread
doesn't behave, it gets killed. :)
Robert Love remarked, "If everything held locks for only sane periods of time,
we would not need gross explicit yielding all over the place." He also said to
Marcus that preempt would be fine on desktop systems. Later, he clarified, "it
seems better overall to me if we work to eliminate long lock hold times (which
then eliminates long non-preemption times) than litter the kernel with explicit
rescheduling statements." Timothy agreed that this would be a good thing.
15. Policy For Using GCC Built-Ins
23 Jun 2004 - 24 Jun 2004 (17 posts) Archive Link: "using gcc built-ins for
bitops?"
People: Arjan van de Ven, Linus Torvalds
Arjan van de Ven said:
gcc 3.4 gained support for several typical bitops as builtin directives. Using
these over inline asm has a few advantages:
* gcc can optimize constants into these better
* gcc can reorder and schedule the code better
* gcc can allocate registers etc better for the code
The question is if we consider it desirable to go down this road or not. In
order to help that discussion I've attached a patch below that switches the
i386 ffz() function to the gcc builtin version, conditional on gcc having
support for this. Before I go down the road of converting more functions and/or
architectures.... is this worth doing?
There was some initial support for this, until Linus Torvalds said:
unless the gcc code can be shown to be clearly better, it is NOT worth doing.
Adding support for built-ins generates a noticeable maintenance burden, since
we'll still have to support older gcc's and architectures where gcc does WORSE
than we do. And quite frankly, I doubt you'll find any cases where gcc does any
better in any measurable way.
In other words, the rule about gcc builtins should be:
* use them only if they are old enough that the huge majority (possibly all)
of users get them. This is partly because gcc has frankly been buggy, and
often makes assumptions that simply may not be true for the kernel (ie
"it's ok to use library routines").
* only use them if you can show a measurable improvement. Theoretical
arguments simply don't count. Theoretical arguments is why gcc-3.x is a lot
slower than 2.95 and is apparently still not generating appreciably better
code for the kernel (and no, don't bother pointing me to spec runs, I just
don't care. The kernel is what I care about).
So far, the only case where they have been worth it is likely the "memcpy()"
stuff, and even there our previous macros were doing an almost equivalent job
(but were arguably so ugly that it was worth making the change).
For something like ffs/popcount/etc, I do not see _any_ point to compiler
support. There just aren't any kernel uses that make it worth it. Sounds like a
total micro-optimization for some spec benchmark.
16. Enhanced Linux System Accounting (ELSA) Updated For Linux 2.6.7
24 Jun 2004 (1 post) Archive Link: "[Patch] Enhanced Linux System Accounting
for 2.6.7"
Topics: BSD, Ioctls
People: Guillaume Thouvenin
Guillaume Thouvenin said:
Here is a new patch for kernel 2.6.7. You can download it from sourceforge at
http://prdownloads.sourceforge.net/elsa/patch-2.6.7-elsa?download
This patch provides structures and functions to do accounting for a group of
process. There is two parts.
On one hand there is two APIs that allow the creation and the destruction of an
item called a "bank" that will contain an group of processes. There is also two
other routines that can add or remove processes in a bank.
On the other hand, you have the accounting mechanism that used bank to perform
BSD-like accounting for a group of process. We used ioctl() interface to create
/destroy a bank and also to add/remove a process in a bank. Currently, device
driver is dev/elsacct and the major number is dynamically allocated, therefore
you need to check the number in the /proc/devices and create the corresponding
device. A sample code is given at: http://cvs.sourceforge.net/viewcvs.py/elsa/
tests/elsa_cmd.c?rev=1.7&view=markup
Currently we do BSD-like accounting. The next step is to identify what kind of
metrics can be interesting for accounting. We started to describe that point on
a withpaper that is available at: http://sourceforge.net/docman/
display_doc.php?docid=23446&group_id=105806 This paper describes differences
between two accounting systems that are ELSA and CSA.
Every comments are welcome,
The ELSA poject team (http://elsa.sourceforge.net)
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License version 2.0.