Table Of Contents
|1.||9 Jun 2004 - 23 Jun 2004||(33 posts)||High-Res Timer (HRT) Support For 2.6; Some Debate Over Alternatives|
|2.||15 Jun 2004 - 22 Jun 2004||(12 posts)||Support For RSA Crypto API In 2.6|
|3.||15 Jun 2004 - 19 Jun 2004||(40 posts)||Linux 2.6.7 Released; ESSID Bug Introduced; SiS900 Full-Duplex Fix Not Applied|
|4.||16 Jun 2004 - 17 Jun 2004||(5 posts)||Generic SCSI Build Target With Target Drivers|
|5.||16 Jun 2004 - 17 Jun 2004||(11 posts)||Linux 2.4.27-pre6 Released|
|6.||17 Jun 2004 - 21 Jun 2004||(7 posts)||Status Of Moxa Serial Card Support Under SMP|
|7.||18 Jun 2004 - 19 Jun 2004||(8 posts)||Input Patches; serio SysFS Integration|
|8.||18 Jun 2004||(1 post)||USB Updates; New Host Controller Driver For lh7a404 Deavices|
|9.||19 Jun 2004 - 20 Jun 2004||(3 posts)||Linux 2.4.27-rc1|
|10.||20 Jun 2004 - 22 Jun 2004||(23 posts)||Linux 2.6.7-mm1 Released|
|11.||21 Jun 2004||(1 post)||Videotext Driver Comment For SAA5246A Decoder Support|
|12.||21 Jun 2004 - 23 Jun 2004||(5 posts)||Status Of linux/802_11.h, Used By Some 3rd Party Drivers|
|13.||23 Jun 2004||(4 posts)||Precise CPU Accounting Patch Ported From 2.4 To 2.6.7|
|14.||23 Jun 2004 - 24 Jun 2004||(7 posts)||Status Of Preemption/Low-Latency In 2.6.7|
|15.||23 Jun 2004 - 24 Jun 2004||(17 posts)||Policy For Using GCC Built-Ins|
|16.||24 Jun 2004||(1 post)||Enhanced Linux System Accounting (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:
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:
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 <http://sourceforge.net/projects/high-res-timers/>. 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:
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
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:
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"
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: firstname.lastname@example.org
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:
Please pull from:
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:
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.
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
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.
V4L: saa5246a driver update, supports saa5281
Signed-off-by: Michael Geng <linux@MichaelGeng.de>
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 :
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"
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:
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:
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.