Kernel Traffic #190 by Zack Brown
[email protected] Mon, 28 Oct 2002 06:38:42 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E186B2Q-0006lH-00@renegade> |
Kernel Traffic #190 For 28 Oct
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 9 Oct - 18 Oct (26 High Resolution Timers
posts)
2. 14 Oct - 18 Oct (21 Hard-To-Track Bugs Caused By Obscure Global
posts) Symbols
3. 15 Oct - 18 Oct (17 Major UNIXism Deprecated: FS Interfaces
posts) Preferred Over ioctls
4. 15 Oct - 22 Oct (6 Patent Problems Around IPMI Driver
posts)
5. 15 Oct - 19 Oct (31 Linux 2.5.43 Released
posts)
6. 16 Oct - 18 Oct (2 Maintainers List
posts)
7. 16 Oct - 18 Oct (2 New Linux Security Project
posts)
8. 17 Oct - 18 Oct (2 kexec Update For 2.5
posts)
9. 17 Oct - 21 Oct (24 Thread-Aware Coredumps In 2.5
posts)
10. 17 Oct - 21 Oct (14 CSA System Resource Accounting Tool
posts)
11. 17 Oct - 21 Oct (7 Linux Kernel Book Recommendations
posts)
12. 17 Oct - 18 Oct (3 Generic AGP 3.0 Device Detection Support In
posts) 2.5
13. 17 Oct - 18 Oct (6 Status Of Linux Trace Toolkit
posts)
14. 18 Oct (1 JFS 1.0.24 Released
post)
15. 18 Oct - 21 Oct (4 Voyager SMP Support For 2.5
posts)
16. 19 Oct (1 linux-2.5.44uc0 MMU-Less Kernel Released
post)
17. 19 Oct (1 User-Mode Linux Updated To 2.5.44
post)
18. 20 Oct (2 Kernel 2.5.44-mm1 Released
posts)
19. 20 Oct (5 Patch Management Scripts
posts)
20. 20 Oct (1 Linux Kernel conf 1.1
post)
21. 20 Oct - 21 Oct (11 Preparing For Final Merge Before 2.5 Feature
posts) Freeze
22. 21 Oct (6 Kernel 2.5.44-mm2 Released
posts)
23. 22 Oct (1 RSBAC 1.2.1 Released
post)
Mailing List Stats For This Week
We looked at 1448 posts in 8731K.
There were 440 different contributors. 231 posted more than once. 231 posted
last week too.
The top posters of the week were:
* 55 posts in 158K by Alan Cox
* 41 posts in 101K by "David S. Miller"
* 26 posts in 851K by Osamu Tomita
* 26 posts in 134K by Andrew Morton
* 25 posts in 184K by (Eric W. Biederman)
* Full Stats
1. High Resolution Timers
9 Oct - 18 Oct (26 posts) Archive Link: "[PATCH 2/3] High-res-timers part 2
(x86 platform code) take 5.1"
George Anzinger posted a patch and explained:
This patch, in conjunction with the "core" high-res-timers patch implements
high resolution timers on the i386 platforms. The high-res-timers use the
periodic interrupt to "remind" the system to look at the clock. The clock
should be relatively high resolution (1 micro second or better). This patch
allows configuring of three possible clocks, the TSC, the ACPI pm timer, or
the Programmable interrupt timer (PIT). Most of the changes in this patch
are in the arch/i386/time.c code.
This patch uses (if available) the APIC timer(s) to generate 1/HZ ticks and
sub 1/HZ ticks as needed. The PIT still interrupts, but if the APIC timer
is available, just causes the wall clock update. No attempt is made to make
this interrupt happen on jiffie boundaries, however, the APIC timers are
disciplined to expire on 1/HZ boundaries to give consistent timer latencies
WRT to the system time.
With this patch applied and enabled (at config time in the processor
feature section), the system clock will be the specified clock. The PIT is
not used to keep track of time, but only to remind the system to look at
the clock. Sub jiffies are kept and available for code that knows how to
use them.
Linus Torvalds was skeptical, remarking, "I really don't get the notion of
partial ticks, and quite frankly, this isn't going into my tree until some
major distribution kicks me in the head and explains to me why the hell we have
partial ticks instead of just making the ticks shorter."
A lot of people spoke up. Randy Dunlap said that Carrier Grade Linux, while not
an actual distribution, did use George's patches; and urged Linus to accept
them. Robert Love added, "Linus, please consider merging at least George's
latest patch set which provides just the new system calls to support POSIX
clocks and timers. There is no dependence on the high-resolution bits, so at
least Linux can provide the missing POSIX.4 system calls. George can then
provide the high resolution code separately which can be debated and optionally
merged."
Elsewhere, Jim Houston added that Concurrent had been using the patches, and
would like to see them in the main tree; and added, "To answer the partial tick
question, it's a trade off. If all you need is 1 milli-second resolution, it
might not be worth spliting the tick. It's a question of how the overhead to
set up a timer compares to the overhead of the higher frequency tick
interrupts. If you want micro-second resolution, you need to split the tick.
This is important to folks doing control systems. They get excited about timing
jitter and resolution. It is also interesting to folks doing games. It's nice
to be able to do short delays by blocking rather than having to spin in a delay
loop."
Also in reply to Linus, George explained:
the notion is to provide timers that have resolution down into the micro
seconds. Since this take a bit more overhead, we just set up an interrupt
on an as needed basis. This is why we define both a high res and a low res
clock. Timers on the low res clock will always use the 1/HZ tick to drive
them and thus do not introduce any additional overhead. If this is all that
is needed the configure option can be left off and only these timers will
be available.
On the other hand, if a user requires better resolution, s/he just turns on
the high-res option and incures the overhead only when it is used and then
only at timer expire time. Note that the only way to access a high-res
timer is via the POSIX clocks and timers API. They are not available to
select or any other system call.
Making ticks shorter causes extra overhead ALL the time, even when it is
not needed. Higher resolution is not free in any case, but it is much
closer to free with this patch than by increasing HZ (which, of course, can
still be done). Overhead wise and resolution wise, for timers, we would be
better off with a 1/HZ tick and the "on demand" high-res interrupts this
patch introduces.
2. Hard-To-Track Bugs Caused By Obscure Global Symbols
14 Oct - 18 Oct (21 posts) Archive Link: "unhappy with current.h"
Daniele Lugli discovered a strange reserved-word situation in the kernel, when
she tried to name one of the fields of a struct in her module, 'current'. After
several days of anguished hunting, she tracked the problem down to asm/
current.h, indirectly included in her module. This file contained the line '#
define current get_current()'. The result was that "my structure becomes the
owner of a function it has never asked for, while it looses a data member. gcc
has nothing to complain about that." She suggested that #defines should be
minimized in the kernel, to avoid this kind of obscure bug.
David S. Miller replied hard-nosedly, that a better solution would be to avoid
using member names that conflict with established global symbols. Elsewhere,
Andi Kleen suggested:
How about changing the definition to:
#define current ((struct task_struct *)get_current())
That should get the same effect as currently for kernel code, but will
guarantee a syntax error if it's used in a structure declaration.
Elsewhere, Chris Wedgwood suggested that Daniele try compiling with
'gcc -Wshadow', which would also catch the error at compile time. Rik van Riel
suggested adding that flag to the standard tree; and there was some support for
this. But Mikael Pettersson pointed out that Daniele's problem had been caused
specifically by her use of the C++ compiler instead of the normal C compiler.
He added, "I fail to see the utility of hacking in kludges for something that's
not supposed to work anyway." Daniele admitted she was indeed writing a kernel
module in C++, but added, "let me at least summarize my
poor-programmer-not-kernel-developer point of view: at present the kernel if a
mined field for c++ and i understand it is not viable nor interesting for the
majority to rewrite it in a more c++-friendly way. But why not at least keep in
mind, while writing new stuff (not the case of current.h i see), that kernel
headers could be included by c++?" Alexander Viro replied:
current.h is, indeed, a special case. #define i j would not be tolerated
simply because it's stupid. Abuses of preprocessor are generally frowned
upon, but there are passionate wa^H^Hpersons who just can't help themselves
and use e.g. ## for no good reason.
But as for C++... frankly, for all I care it doesn't exist. As long as
requirements of style happen to reduce problems of C++ programmers - they
are lucky. But other than that... watch me not care. In the linux kernel
context C++ is obscure language and it will stay that way. Ergo, no reasons
to spend any mental efforts on being nice to it. Deal.
3. Major UNIXism Deprecated: FS Interfaces Preferred Over ioctls
15 Oct - 18 Oct (17 posts) Archive Link: "[PATCH] Device-mapper submission 6/
7"
Joe Thornber posted a patch that included some new ioctls, and Jeff Garzik
said, "If you're adding a new interface, there should be no need to add new
ioctls and all that they entail. Just control via a ramfs-based fs..." Greg KH
agreed, and added, "With libfs now in 2.5, it's quite easy to make such a
filesystem."
4. Patent Problems Around IPMI Driver
15 Oct - 22 Oct (6 posts) Subject: "[PATCH] IPMI driver for Linux, version 7"
Corey Minyard announced version 7 of the IPMI driver (http://www.intel.com/
design/servers/ipmi/spec.htm) , saying, "cleanups and bug fixes, some from
Arjan van de Ven, and others from myself. This fixes some problems with
blocking operations while holding a lock. It has an unfortunate interface
change (but better now than later), the lun field is removed from the IPMI
message, and one is added to the system interface address. It's a minor change,
but it really needed to be done to make things consistent. It's only released
as a patch to the v6 version and it applies cleanly to all kernel versions. As
usual, you can download the driver from my home page at http://home.attbi.com/
~minyard."
Adrian Bunk pointed out that anyone implementing IPMI, IPMB, or ICMB, had to
sign a patent license, which included the text, "Adopter hereby grants to the
Promoters and to Fellow Adopters, and the Promoters hereby grant to Adopter, a
nonexclusive, royalty-free, nontransferable, nonsublicenseable, worldwide
license under its Necessary Claims to make, have made, use, import, offer to
sell and sell products which comply with the Specification; provided that such
license shall not extend to features of a product which are not required to
comply with the Specification or for which there exists a feasible,
noninfringing alternative." He asked, "Am I right that this makes it impossible
to include an IPMI driver into the kernel (this isn't GPL-compatible)?" Corey
replied, "I do not read it so, but perhaps you are right. I will ask. I'm sure
I will receive a resounding "maybe" as the answer. I was working with people at
Intel on this, and they had another driver they wanted to use for IPMI, and
wanted to push it into the kernel, but it had some problems so I wrote this as
a replacement. So I don't think Intel sees it this way (at least those at Intel
I was working with)."
Peter Chubb said, "I suspect the licence refers to the firmware bottom half,
not the driver to access it." Alan Cox asked someone from Intel to clarify the
situation, and Inaky Perez-Gonzalez from Intel replied (not actually speaking
for Intel), "Corey's IPMI driver is GPL, as are all the other components of the
kernel. People who are worried about patents on IPMI implementations can get a
royalty-free license any time by going to http://www.intel.com/design/servers/
ipmi/spec.htm and signing the Adopter's agreement. Yes, to get the royalty-free
patent license for implementations of the IPMI spec, you have to give a promise
not to sue other Adopters of IPMI, but I don't see why anyone who isn't
planning on going around suing people should have a problem signing this
agreement. In any case this is very similar to USB, which also has an Adopter's
agreement for patents, and USB has been in the kernel for years without causing
any IP problems."
5. Linux 2.5.43 Released
15 Oct - 19 Oct (31 posts) Subject: "Linux v2.5.43"
Linus Torvalds announced 2.5.43 (http://www.kernel.org/pub/linux/kernel/v2.5/
ChangeLog-2.5.43) , and said:
A huge merging frenzy for the feature freeze, although I also spent a few
days getting rid of the need for ide-scsi.c and the SCSI layer to burn
CD-ROM's with the IDE driver (it still needs an update to cdrecord, I sent
those off to the maintainer).
The most fundamental stuff is probably RCU and oprofile, but there's stuff
all over the map here..
Bill Davidsen remarked, "I hope you haven't broken running WITH ide-scsi,
because most people still run 2.4 kernels in real life and only test 2.5
because someone has to do it. Reconfiguring the system to use ide-scsi or not
is just one more PITA thing which needs to be done, or more likely forgotten,
with every new kernel." Shawn Leas felt it would be fine to break the old
stuff, since a single kernel argument or modification of /etc/modules.conf
would solve any problems that might crop up. Bill was not in favor of that, and
Linus replied to Shawn:
Anyway, ide-scsi should work as well as it ever did, which is not to say
too well. It's just that the IDE native implementation is cleaner and
simpler, and a _hell_ of a lot easier to use.
The scsi-generic layer is a total nightmare. If you want to write to the
device that is /dev/scd0, you can't just use /dev/scd0, you have to use the
right /dev/sgX, and the X depends on how many disks etc you have in the
system and where your controller is. The amount of crap you have to do with
things like "cdrecord -scanbus" to just figure out what the right device is
is just ludicrous.
With the native IDE setup, if your CD is /dev/hdc, then that's what you use
for cdburning too. Just do "cdrecord dev=/dev/hdc" and that's it. No
made-up SCSI bus numbers, no need to try to figure out what the right thing
is, no crap.
In fact, I hope that in linux-2.7.x the SCSI layer itself will start using
the same interface, so that we can drop scsi-generic some day completely.
The interface is totally generic, and doesn't have anything to do with IDE
per se - ide-cd.c just needed to be cleaned up enough to be able to use it.
The interface really just says "hey, you can push SCSI commands down the
request queue" (and ide-cd.c will take the SCSI command and convert it into
an ATAPI packet command - which is a pretty trivial transform).
So right now, you can do "cdrecord dev=/dev/hdc ..", but because I didn't
bother to try to figure out what the SCSI layer wants to do you can _not_
do the simple "cdrecord dev=/dev/scd0 .." if you have a SCSI disk. That's
nothing fundamental, I just don't think SCSI CD-RW's are very interesting
any more, since they are overpriced and hard to find. I hope some SCSI
fanatic will do the (probably trivial) addition to sr.c to accept the SCSI
ioctl interface.
(Hint for such SCSI users: you should just do:
+ call "scsi_cmd_ioctl()" in your ioctl routine, and if it returns ENOTTY
that means that it wasn't one of the SCSI generic commands.
+ make the request queue handler understand that requests with the
REQ_BLOCK_PC flag set are SCSI packet commands, and "req->cmd" contains
the command, while "req->data" and "req->data_len" are the data for the
command)
+ make sure that an open() with the O_NONBLOCK flag set will succeed even
if the medium is not accessible (and will succeed even if it's a
writable open).
and that should be pretty much it).
Elsewhere, Bill reported his own experience, "I'm happy to report that ide-scsi
is still working fine, both for CD, CD-RW and ZIP drives. Which makes life nice
on a system with both ATAPI and SCSI CD devices, since my scripts need only get
the bus and id, not use another device name format."
6. Maintainers List
16 Oct - 18 Oct (2 posts) Archive Link: "lk maintainers"
Denis Vlasenko posted his latest list of kernel maintainers:
So, you are new to Linux kernel hacking and want to submit a kernel bug
report or a patch but don't know how to do it and _where_ to report it?
Preparing bug report:
=====================
*** Remember: bad/incomplete bug report ONLY wastes bandwidth! ***
How To Ask Questions The Smart Way:
http://www.tuxedo.org/~esr/faqs/smart-questions.html
Anybody who has written software for public use will
probably have received at least one bad bug report.
Reports that say nothing ("It doesn't work!");
reports that make no sense; reports that don't give
enough information; reports that give wrong information.
How to Report Bugs Effectively:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Before asking a technical question by email, or in
a newsgroup, or on a website chat board, do the following:
* Try to find an answer by searching the Web.
* Try to find an answer by reading the manual.
* Try to find an answer by reading a FAQ.
* Try to find an answer by inspection or experimentation.
* Try to find an answer by reading the source code.
Compile problems: report GCC output and result of "grep '^CONFIG_' .config"
Oops: decode it with ksymoops.
Unkillable process: Alt-SysRq-T and ksymoops relevant part.
Yes it means you should have ksymoops installed and tested,
which is easy to get wrong. I've done that too often.
Sending bug report/patch:
=========================
* Some device drivers have active developers, try to contact them first.
* Otherwise find a subsystem maintainer to which your report pertains
and send report to his address.
* Small fixes and device driver updates are best directed to subsystem
maintainers and "small bits" integrators.
* It never hurts to CC: Linux kernel mailing list, but without specific
maintainer address in To: field there is high probability that your
patch won't be noticed. You have been warned.
* Do not send it to all addresses at once! This will annoy lots of people
and isn't useful at all. It's a spam.
* Do NOT send small fixes to Linus, he just can't handle _everything_.
He will eventually receive it from maintainers/integrators, send it
their way.
* If your patch is something big and new, announce it on lkml and try
to attract testers. After it has been tested and discussed, you can
expect Linus to consider inclusion in mainline.
Current Linux kernel people
Note that this list is sorted in reversed date order, most recent
entries first. This means than entries at bottom can be outdated :-(
Linux kernel mailing list <[email protected]>
Post anything related to Linux kernel here, but nothing else :-)
Andre Hedrick <[email protected]> [02 oct 2002]
ATA/ATAPI Storage Architect [2.0,2.2,2.4,2.5]
HBA interface developer
Serial ATA Architect [future release]
Voting NCITS member AT-Attachment Committee
Jeff Garzik <[email protected]> [24 sep 2002]
I am the network-card-drivers guy (8139 for instance).
CC me and Andrew Morton <[email protected]> on network driver patches.
Jan-Benedict Glaw <[email protected]> [18 sep 2002]
I'm responsible for Alpha's srm_env driver, providing access to
SRM's firmware variables.
Stuart MacDonald <[email protected]> [13 sep 2002]
Connect Tech's linux kernel guy. Currently includes hacking on
drivers/char/serial.c (Blue Heat, Xtreme, Dflex) and maintaining
drivers/usb/serial/whiteheat.c (WhiteHEAT)
Vojtech Pavlik <[email protected]> [13 sep 2002]
Feel free to send me bug reports and patches to input device drivers
(drivers/input/*, drivers/char/joystick/*)
I also want to receive bug reports and patches for following
USB drivers: printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
All other (not in the list) USB driver changes should go to USB
maintainer (hopefully there is one listed here :-).
Also CC me if you are posting VIA IDE driver related message
(although I am not IDE subsystem maintainer).
Robert Love <[email protected]> [12 sep 2002]
Preemptible kernel maintainer.
I am also interesting in anything related to scheduling or locking
primitives.
Jan Kara <[email protected]> [22 aug 2002]
quota subsystem maintainer
Paul Larson <[email protected]> [20 aug 2002]
I'm a maintainer for the Linux Test Project and it would be nice
if people knew to send their test programs, etc. to me. I see
a lot of them flying around on lkml and try to catch them when
I can, but it's a lot to keep up with. It would be even better
if people just knew to send them our way so we could clean
them up and put them in LTP for regression testing.
Dave Engebretsen <[email protected]> [15 aug 2002]
PPC64 architecture maintainer. Please send PPC64 patches to me
and our mailing list at <[email protected]>
Ingo Molnar <[email protected]> [30 jul 2002]
Ingo wrote the new scheduler for 2.5.
Ralf Baechle <[email protected]> [30 jul 2002]
I am maintainer of the AX.25 code
Victor Yodaiken <[email protected]> [30 jul 2002]
RTLinux patches, updates, contributions, drivers.
Please send first to the list: [email protected]
Pavel Machek <[email protected]> [27 jul 2002]
I am network block device maintainer. Visit http://nbd.sf.net.
(see Steven Whitehouse <[email protected]> entry)
I am working on software suspend.
William Irwin <[email protected]> [02 jul 2002]
Send bug reports and/or feature requests related to many tasks,
rmap, space consumption, or allocators to me. I'm involved in
* rmap
* memory allocators
* reducing space consumed by data structures (e.g. struct page)
* issues arising in workloads with many tasks
* kernel janitoring
See also:
Rik van Riel <[email protected]>
Andrea Arcangeli <[email protected]>
Martin Bligh <[email protected]>
Andrew Morton <[email protected]>
Dave Jones <[email protected]> [23 apr 2002]
I collect various bits and pieces for inclusion in 2.5,
especially small and trivial ones and driver updates.
I'll feed them to Linus when (and if) they
are proved to be worthy.
Andrea Arcangeli <[email protected]> [28 mar 2002]
Send VM related bug reports and patches to me.
I'm especially interested in VM issues with:
* lots of RAM and CPUs
* NUMA
* heavy swap scenarios
* performance of I/O intensive workloads (in particular
with lots of async buffer flushing involved)
See also Martin J. Bligh <[email protected]> entry
Mail also:
Arjan van de Ven <[email protected]>
Martin J. Bligh <[email protected]> [28 mar 2002]
I'm interested in VM issues with lots (>4G for i386)
of RAM, lots of CPUs, NUMA
Steven Whitehouse <[email protected]> [27 mar 2002]
I am the Linux DECnet network stack maintainer
Visit http://www.chygwyn.com/decnet/
Arnaldo Carvalho de Melo <[email protected]> [26 mar 2002]
IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org,
cyclom2x sync card driver
John Cagle <[email protected]> [19 mar 2002]
The current maintainer of devices.txt, the list of
assigned device numbers for LANANA. Consult the web
site (www.lanana.org) for instructions on submitting
requests for new device numbers. Send all device
related email to <[email protected]>.
Tigran Aivazian <[email protected]>
I am author and maintainer of BFS filesystem and IA32
microcode update driver.
Rogier Wolff <[email protected]> [12 mar 2002]
I do "specialix serial ports":
drivers/char/specialix.c (IO8+)
drivers/char/sx.c (SX, SI, SIO)
drivers/char/rio/*.c (RIO)
Martin Dalecki <[email protected]> [11 mar 2002]
IDE subsystem maintainer for 2.5
(mail Vojtech Pavlik <[email protected]> too)
Ed Vance <[email protected]> [05 mar 2002]
Maintainer for the generic serial driver, serial.c,
for 2.2 and 2.4 kernels. Please post patches to
[email protected] for tested bug
fixes or to add support for a new serial device.
Limited to time available. If I have not responded
in a week, yell at [email protected]
netfilter/iptables development <[email protected]> [23 feb 2002]
Please report all netfilter/iptables related problems
to this mailinglist, where all netfilter developers are present.
See also http://www.netfilter.org/contact.html
Hans Reiser <[email protected]> [16 feb 2002]
Send me all reiserfs related patches with a cc to
[email protected], send bug reports to
[email protected], send paid support requests to
[email protected] after going to www.namesys.com/support.html
to pay, send discussions (not bug reports unless they are
interesting to most persons) to [email protected].
If we sit on your patch for a week without responding,
yell at us, we deserve it. Look at our web page
at www.namesys.com for more about sending us code,
working with us, and our patch submission and tracking system.
Paul Bristow <[email protected]> [16 feb 2002]
I am an ide-floppy driver maintainer
(ATAPI ZIP, LS-120/240 Superdisk, Clik! drives).
Mike Phillips <[email protected]> [15 feb 2002]
Token ring subsystem and drivers.
Anton Altaparmakov <[email protected]> [15 feb 2002]
I am the NTFS guy.
https://bugzilla.redhat.com/bugzilla [14 feb 2002]
Reports of problems with the Red Hat shipped kernels.
Alan Cox <[email protected]> [14 feb 2002]
Linux 2.2 maintainer (maintenance fixes only).
Collator of patches for unmaintained things in 2.2/2.4.
Maintainer of the 2.4-ac (2.4 plus stuff being tested) tree.
I2O, sound, 3c501 maintainer for 2.2/2.4.
ALSA development <[email protected]> [12 feb 2002]
Jaroslav Kysela <[email protected]> [12 feb 2002]
Advanced Linux Sound Architecture
ALSA patches are available at
ftp://ftp.alsa-project.org/pub/kernel-patches/* (ftp://ftp.alsa-project.org/pub/kernel-patches/)
Neil Brown <[email protected]> [08 feb 2002]
I am interested in any issues with the code in:
NFS server (fs/nfsd/*)
software RAID (drivers/md/{md,raid,linear}*)
or related include files.
Maksim Krasnyanskiy <[email protected]> [08 feb 2002]
I'm author and maintainer of the Bluetooth subsystem
and Universal TUN/TAP device driver.
These days mostly working on Bluetooth stuff.
Rik van Riel <[email protected]> [07 feb 2002]
Send me VM related stuff, please CC to [email protected]
Geert Uytterhoeven <[email protected]> [07 feb 2002]
I work on the frame buffer subsystem, the m68k port (Amiga part),
and the PPC port (CHRP LongTrail part).
Unfortunately I barely have spare time to really work on these
things. My job is not Linux-related (so far :-). I can not
promise anything about my maintainership performance.
H. Peter Anvin <[email protected]> [07 feb 2002]
i386 boot and feature code, i386 boot protocol, autofs3,
compressed iso9660 (but I'll accept all iso9660-related
changes). kernel.org site manager; please contact me
for sponsorship-related issues.
kernel.org admins <[email protected]> [07 feb 2002]
Kernel.org sysadmins. Contact us if you notice something breaks,
or if you want a change make sure you give us at least 1-2 weeks.
Please note that we got a lot of feature requests, a lot of
which conflict or simply aren't practical; we don't have time to
respond to all requests.
Greg KH <[email protected]> [07 feb 2002]
I am USB and PCI Hotplug maintainer.
Trond Myklebust <[email protected]> [07 feb 2002]
I am NFS client maintainer.
James Simmons <[email protected]> [07 feb 2002]
Console and framebuffer sybsustems.
I also play around with the input layer.
Richard Gooch <[email protected]> [07 feb 2002]
I maintain devfs. I want people to Cc: me when reporting devfs
problems, since I don't read all messages on linux-kernel.
Send devfs related patches to me directly, rather than
bypassing me and sending to Linus/Marcelo/Alan/Dave etc.
Russell King <[email protected]> [06 feb 2002]
ARM architecture maintainer. Please send all ARM patches through
the patch system at http://www.arm.linux.org.uk/developer/patches/
New serial drivers maintainer for 2.5. Submit patches to
[email protected]
Andrew Morton <[email protected]> [05 feb 2002]
I'm receptive to any reproducible bug anywhere in the 2.4 kernel.
Specialising in ext2, ext3 and network drivers.
Not thinking about 2.5.x at this time.
Petr Vandrovec <[email protected]> [05 feb 2002]
ncpfs filesystem, matrox framebuffer driver, problems related
to VMware - in all of 2.2.x, 2.4.x and 2.5.x.
Reiserfs developers list <[email protected]> [05 feb 2002]
Send all reiserfs-related stuff here including but not limited to bug
reports, fixes, suggestions.
Oleg Drokin <[email protected]> [05 feb 2002]
SA11x0 USB-ethernet and SA11x0 watchdog are mine.
======= These entries are suggested by lkml folks ========
Ralf Baechle <[email protected]> [27 mar 2002]
I am mips/mips64 maintainer.
David S. Miller <[email protected]> [07 feb 2002]
I am Sparc64 and networking core maintainer.
======= These ones I made myself ========
======= I am waiting confirmation/correction from these people ========
Urban Widmark <[email protected]> [13 feb 2002]
smbfs
video4linux list <[email protected]> [12 feb 2002]
Gerd Knorr <[email protected]> [12 feb 2002]
video4linux
Tim Waugh <[email protected]> [08 feb 2002]
> Who is maintaining the linux iomega stuff?
For 2.4.x, me (in theory). I don't have time for 2.5.x at the moment.
Alexander Viro <[email protected]> [5 feb 2002]
I am NOT a fs subsystem maintainer. But I won't kill
you if you send me some generic fs bug reports and (hopefully) patches.
Eric S. Raymond <[email protected]> [5 feb 2002]
Send kernel configuration bug reports and suggestions to me.
Also I'll be more than happy to accept help enties for kernel config
options (Configure.help).
G?rard Roudier <[email protected]> [5 feb 2002]
I am SCSI guy.
Jens Axboe <[email protected]> [5 feb 2002]
I am block device subsystem maintainer.
Linus Torvalds <[email protected]> [5 feb 2002]
Do not send anything to me unless it is for 2.5, well tested,
discussed on lkml and is used by significant number of people.
In general it is a bad idea to send me small fixes and driver
updates, send them to subsystem maintainers and/or
"small stuff" integrator (currently Dave Jones <[email protected]>,
see his entry). Sorry, I can't do everything.
Marcelo Tosatti <[email protected]> [5 feb 2002]
Do not send anything to me unless it is for 2.4 and well tested.
If you are sending me small fixes and driver updates, send
a copy to subsystem maintainers and/or "small stuff" integrators:
- Alan Cox <[email protected]>,
- Rusty Russell <[email protected]>.
Rusty Russell <[email protected]> [5 feb 2002]
> Here are some cleanups of whitespace in .....
Want me to add this to the trivial patch collection for tracking?
If so just send (or cc:) it to [email protected].
James Simmons pointed out that his new email address was [email protected]
7. New Linux Security Project
16 Oct - 18 Oct (2 posts) Archive Link: "Linux Security Protection System"
Bosko Radivojevic announced:
LinSec team is proud to announce first stable release of LinSec.
LinSec, as the name says, is Linux Security Protection System. The main aim
of LinSec is to introduce Mandatory Access Control (MAC) mechanism into
Linux (as opposed to existing Discretionary Access Control mechanism).
LinSec model is based on:
+ Capabilities
+ Filesystem Access Domains
+ IP Labeling Lists
+ Socket Access Control
As for Capabilities, LinSec heavily extends the Linux native capability
model to allow fine grained delegation of individual capabilities to both
users and programs on the system. No more allmighty root!
Filesystem Access Domain subsystem allows restriction of accessible
filesystem parts for both individual users and programs. Now you can
restrict user activities to only its home, mailbox etc. Filesystem Access
Domains works on device, dir and individual file granularity.
IP Labeling lists enable restriction on allowed network connections on per
program basis. From now on, you may configure your policy so that no one
except your favorite MTA can connect to remote port 25
Socket Access Control model enables fine grained socket access control by
associating, with each socket, a set of capabilities required for a local
process to connect to the socket.
LinSec consists of two parts: kernel patch (currently for 2.4.18) and
userspace tools.
Detailed documentation, download & mailing list information - http://
www.linsec.org
Jakob Oestergaard asked Bosko to describe how LinSec differed from SELinux; but
there was no reply.
8. kexec Update For 2.5
17 Oct - 18 Oct (2 posts) Archive Link: "kexec for 2.5.42"
Eric W. Biederman announced:
O.k. My first pass at getting up to date with the current kernel is
available at:
http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.42.kexec.x86.diff
http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.0.tar.gz
The big changes are:
1. I have rebundled my tools so it is a little easier to get at:
2. I have included a test case kexec_test that tests the stranger cases,
so when the kernel doesn't boot, we can rule out the kexec code.
3. I have added a call to device_shutdown so device drivers get a chance
to shut up.
4. I have moved kexec into its one system call instead of treating
sys_reboot like an ioctl. The big reason is that while there is a lot
of generic code some very architecture specific code must be written
for each architecture, and having to register a system call means the
code won't become active by accident.
I will probably split this up before sending to Linus but anyway, here is
the patch so you can pick it apart and tell me what you don't like.
Werner Almesberger exclaimed, "Yipee! I was already having nightmares that we'd
have to live without it for another major kernel release cycle. I had a quick
glance at it, and it looks quite lovely."
9. Thread-Aware Coredumps In 2.5
17 Oct - 21 Oct (24 posts) Archive Link: "[patch] thread-aware coredumps,
2.5.43-C3"
Ingo Molnar said:
the attached patch is the second iteration of thread-aware coredumps,
against BK-curr. I think this patch is now ready for inclusion into
mainline.
Changes:
+ Ulrich Drepper has reviewed the data structures and checked actual
coredumps via readelf - everything looks fine and according to the
spec.
+ a serious bug has been fixed in the thread-state dumping code - it was
still based on the 2.4 assumption that the task struct points to the
kernel stack - it's task->thread_info in 2.5. This bug caused bogus
register info to be filled in for threads.
+ properly wait for all threads that share the same MM to serialize with
the coredumping thread. This is CLONE_VM based, not tied to
CLONE_THREAD and/or signal semantics, ie. old-style (or
different-style) threaded apps will be properly stopped as well.
The locking might look a bit complex, but i wanted to keep the
__exit_mm() overhead as low as possible. It's not quite trivial to get
these bits right, because 'sharing the MM' is detached from signals
semantics, so we cannot rely on broadcast-kill catching all threads. So
zap_threads() iterates through every thread and zaps those which were
left out. (There's a minimal race left in where a newly forked child
might escape the attention of zap_threads() - this race is fixed by the
OOM fixes in the mmap-speedup patch.)
+ fill_psinfo() is now called with the thread group leader, for the
coredump to get 'process' state.
+ initialize the elf_thread_status structure with zeroes.
the IA64 ELF bits are not included, yet, to reduce complexity of the patch.
The patch has been tested on x86 UP and SMP.
10. CSA System Resource Accounting Tool
17 Oct - 21 Oct (14 posts) Archive Link: "[PATCH] 2.5.43 CSA, Job, and PAGG"
John Hesterberg announced:
2.5.43 versions of CSA, Job, and PAGG patches are available at:
ftp://oss.sgi.com/projects/pagg/download/linux-2.5.43-pagg-job.patch
ftp://oss.sgi.com/projects/csa/download/linux-2.5.43-csa.patch
The CSA and job user-level code is in the same directories.
CSA (Comprehensive System Accounting) provides methods for collecting
per-process resource usage data, monitoring disk usage, and charging fees
to specific login accounts. CSA provides features which are not available
with the other Linux accounting packages. For more information, see:
http://oss.sgi.com/projects/csa/
Linux Jobs is an inescapable process container that is typically created by
point of entry processes like login, and inherited by children. PAGG
(Process Aggregates) is a generic framework for implementing process
containers such as Linux Jobs. For more information, see:
http://oss.sgi.com/projects/pagg/
CSA depends on Linux Jobs, and Linux Jobs depends on PAGG.
Various folks had minor technical problems with the patch, such as typedef
usage; but no serious objections were made.
11. Linux Kernel Book Recommendations
17 Oct - 21 Oct (7 posts) Archive Link: "Question: Favorite Linux kernel
book?"
Eric Altendorf asked which Kernel book folks liked best. Jonathan Corbet
recommended Understanding The Linux Kernel (http://www.bookfinder.com/search/?
author=Bovet%2C+Daniel+P.&title=understanding+the+linux+kernel&st=xl&ac=qr) and
ia-64 Linux Kernel (http://www.bookfinder.com/search/?author=Mosberger%2C+David
&title=ia-64+linux+kernel+design+and+implementation&st=xl&ac=qr) , as well as
his own book, Linux Device Drivers (http://www.bookfinder.com/search/?author=&
title=&new_used=*&binding=*&isbn=0596000081&keywords=&minprice=&maxprice=&
submit=Begin+Search¤cy=USD&mode=advanced&st=sr&ac=qr) (also available for
free at xml.com (http://www.xml.com/ldd/chapter/book/index.html) ). Ron Henry
said, "I'd also recommend "Unix Internals: The New Frontiers (http://
www.bookfinder.com/search/?author=Vahalia%2C+Uresh&title=
unix+internals+the+new+frontiers&st=xl&ac=qr) ". The sections on memory
management, particularly the slab allocator is worth understand seeing as how
the linux's current slab allocator is based on the concepts discussed in that
book." Alan Cox added, "If you are new to kernels and hardware the best book on
Linux is in some ways Andy Tanenbaum's Operating Systems (http://
www.bookfinder.com/search/?author=Tanenbaum%2C+Andrew+S.&title=operating&st=xl&
ac=qr) . Its not about Linux but its one of the best intros to the whole
topic."
12. Generic AGP 3.0 Device Detection Support In 2.5
17 Oct - 18 Oct (3 posts) Subject: "[PATCH] GART driver support for generic
AGP 3.0 device detection/ enabling & Intel 7505 chipset support"
Matthew E Tolentino announced:
Attached is a patch for generic AGP 3.0 device detection and enabling
routines as well as specific support for the Intel 7505 chipset against the
2.5.43 kernel.
This patch adds a new file agp3.c which contains generic enabling and
detection routines based on the AGP 3.0 spec. Some of the new features
include detection of multiple devices and proper isochronous bandwidth
allocation to each discovered device, as well as the typical host bridge
initialization. This patch also adds another file i7505-agp.c which
contains the chipset specific support. It is prudent to note that this
patch does not yet implement all of the capabilities defined by the AGP 3.0
spec.
13. Status Of Linux Trace Toolkit
17 Oct - 18 Oct (6 posts) Archive Link: "[ANNOUNCE] LTT 0.9.6pre2: Per-CPU
buffers, TSC timestamps, etc."
Karim Yaghmour announced:
A new development version of LTT is now available, 0.9.6pre2. Here's what's
new:
+ Per-CPU buffering
+ TSC timestamping
+ Use of syscall interface instead of char dev abstraction
The release includes a patch for 2.5.43 which is pretty much ready for
inclusion. I will be posting this patch raw ot the LKML with a more verbose
description.
You will find 0.9.6pre2 here:
http://www.opersys.com/ftp/pub/LTT/
LTT's web site is here:
http://www.opersys.com/LTT
Cose by, he added, "0.9.6pre2 is a development version, it's expected to have
rough spots." Elsewhere, Frank Rowand asked, "I noticed that the Linux 2.4.19
patch is not carried forward from pre1 to pre2. Are you planning to no longer
maintain support for LTT in the Linux 2.4 line?" Karim replied:
The problem is that the kernel patch is highly dependent on the kernel's
own development. The tracing infrastructure has to change as the kernel
changes. Incidently, the user tools also have to change to accomodate the
newer kernels. There's a point where keeping compatibility with older
kernels becomes increasingly difficult and would entail one of two things:
+ Burden the user tools with legacy support.
+ Backport all new features to older kernels.
Neither of these is really interesting. Of course, if someone wants to take
the time to backport some of the new features to older kernels I would
gladly publish their patch with the tools. The time it takes to work out an
LTT patch is non-negligeable and I don't have the bandwidth to maintain
multiple kernel patches in parallel. This is why I'm concentrating on
getting LTT to work with the latest and greatest.
Obviously things will be much simpler once the LTT patch is included in the
kernel.
14. JFS 1.0.24 Released
18 Oct (1 post) Archive Link: "[ANNOUNCE] Journaled File System (JFS) release
1.0.24"
Steve Best announced:
Release 1.0.24 of JFS was made available today.
Drop 62 on October 18, 2002 (jfs-2.4-1.0.24.tar.gz and
jfsutils-1.0.24.tar.gz) includes fixes to the file system and utilities.
Utilities changes
+ byte-swapping fixes for big-endian hardware (fixes in logredo and
fsck.jfs)
File System changes
+ readSuper() was incorrectly checking return status of sb_bread()
+ change name of get_index to read_index fixes MIPS build issue
+ Releasing LOGGC_LOCK too early
In txLazyCommit, we are releasing log->gclock (LOGGC_LOCK) before
checking tblk->flag for tblkGC_LAZY. For the case that tblkGC_LAZY is
not set, the user thread may release the tblk, and it may be reused and
the tblkGC_LAZY bit set again, between the time we release the spinlock
until we check the flag. This problem is easy to hit on a 2.5 kernel
with CONFIG_PREEMPT set, but it is a potential problem on SMP as well.
The fix is to hold the spinlock until after we've checked the flag.
For more details about JFS, please see the patch instructions or
changelog.jfs files.
JFS for Linux http://oss.software.ibm.com/jfs
15. Voyager SMP Support For 2.5
18 Oct - 21 Oct (4 posts) Archive Link: "[PATCH] Voyager subarchitecture for
2.5.44"
James Bottomley announced:
This patch adds SMP (and UP) support for voyager which is an (up to 32 way)
SMP microchannel non-PC architecture.
The current patch includes a swap around of the timer code defines
(available separately at http://linux-voyager.bkbits.net/timer-2.5) and a
new CONFIG_X86_TRAMPOLINE config option to avoid the trampoline vpath.
The patch (156k) is available here:
http://www.hansenpartnership.com/voyager/files/voyager-2.5.44.diff
And also via bitkeeper at
http://linux-voyager.bkbits.net/voyager-2.5
William Lee Irwin III remarked, "this patch is impressively isolated from
generic i386 code. Although I've not tested, it seems very clear from the form
of the code that it will have no impact on UP i386 or other subarches." Alan
Cox mentioned that the patch had been in his -ac tree for a long time; while
James also explained, "Well technically, there's the boot time GDT separation
(make boot GDT smaller and simpler than the runtime) which affects all x86."
William had also asked, in his initia reply, "This is a very interesting
architecture. Could you describe vaguely (for someone starved enough for time
he might have trouble finding time to examine your tree) how cpu wakeup with
the VIC proceeds?" And James replied:
You mean how the VIC boots? Certainly. Referring to the architecture in
http://www.hansenpartnership.com/voyager/L5arch.html
The VIC is basically a set of 8258 dyads (and voyager has up to 8 of them).
The boot CPU can send a cross processor interrupt (CPI) to any VIC
connected CPU. However, the boot CPU can only modify its own VIC 8258 dyad,
so theres a masquerade register that temporarily globally drives the VIC
processor ID lines so that the boot CPU can lower the interrupt mask in a
different VIC.
However, each CPU card has only one or two VIC connections, so booting the
Quad cards is a sort of one-two trick: you VIC boot the VIC connected CPU
(called the extended CPU) and then it QIC (Quad interrupt controller) boots
the remaining CPUs. The QIC works using a cache line interference mechanism
(so writes to a particular part of memory trigger the CPI). However, only
CPUs local to the Quad can masquerade as each other to lower the QIC
interrupt mask.
16. linux-2.5.44uc0 MMU-Less Kernel Released
19 Oct (1 post) Archive Link: "[PATCH]: linux-2.5.44uc0 (MMU-less support)"
Greg Ungerer announced:
An updated uClinux patch is available at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc0.patch.gz
Changelog:
1. patched against 2.5.44
Smaller specific patches:
+ FEC ColdFire 5272 ethernet driver
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-fec.patch.gz
+ m68k/ColdFire/v850 serial drivers
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-serial.patch.gz
+ 68328 frame buffer
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-fb.patch.gz
+ binfmt_flat loader
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-binflat.patch.gz
+ m68knommu architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-m68knommu.patch.gz
+ v850 architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-v850.patch.gz
+ mm (MMU-less) only patch
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
linux-2.5.44uc0-mm.patch.gz
17. User-Mode Linux Updated To 2.5.44
19 Oct (1 post) Archive Link: "uml-patch-2.5.44-1"
Jeff Dike announced:
This patch updates UML to 2.5.44.
The only UML-specific change in this patch is the merge of some of James
McMechan's ubd driver changes which make partitions work again.
The patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.44-1.bz2
For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html
Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
18. Kernel 2.5.44-mm1 Released
20 Oct (2 posts) Archive Link: "2.5.44-mm1"
Andrew Morton announced:
url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.44/2.5.44-mm1/
+ The shared pagetable code is back in. Seems to be stabilising. If
anyone has any weird problems, please see if a `patch -R -p1 <
shpte-ng.patch' fixes it up, thanks.
+ There have been ongoing travails in the direct-io code since the
introduction of bio_add_page().
It was all turning into a bit of a pickle, so I got down and rewrote
the file-walk, assembly and BIO submission phase in a manner which
suits the bio_add_page() semantics. This version is, IMO, significantly
clearer. And it now runs the modified-for-O_DIRECT fsx-linux code
without going BUG.
This of course broke the allow-512-byte-alignment patch; that needs to
be redone.
+ There is a series of debloat patches here. Expect to see the kernel use
100k less memory on UP and 300k less on SMP.
Well, more accurately 10k * (NR_CPUS - number_of_cpus).
+ A series of updates from Bill on the large page filesystem and shm
patches
+ I'm carrying ninety five diffs here. People who send me patches for
integration: please, keep it as small as is practical, and not trivial
stuff. Thanks.
19. Patch Management Scripts
20 Oct (5 posts) Archive Link: "patch management scripts"
Andrew Morton said:
I finally got around to documenting the scripts which I use for managing
kernel patches. See
http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.1/
These scripts are designed for managing a "stack" of patches against a
rapidly-changing base tree. Because that's what I use them for.
I've been using and evolving them over about six months. They're pretty
fast, and simple to use. They can be used for non-kernel source trees.
The implementation is pretty agricultural - I only know how to do three
things in /bin/sh scripts and I'm not sure that I want to learn #4, but
patches are accepted.
Hopefully these will be useful to some people. I'd expect that the ramp-up
time is half an hour or so.
Here's the fine manual:
This is a description of a bunch of shell scripts which I use for
managing kernel patches. They are quite powerful. They can be used on
projects other than the linux kernel. They are easy to use, and fast.
You end up doing a ton of recompiling with these scripts, because
you're pushing and popping all the time. ccache takes away the pain of
all that. http://ccache.samba.org/ - be sure to put the cache
directory on the same fs as where you're working so that ccache can use
hardlinks.
The key philosophical concept is that your primary output is patches.
Not ".c" files, not ".h" files. But patches. So patches are the
first-class object here.
Concepts
========
All work occurs with a single directory tree. All commands are invoked
within the root of that tree. The scripts manage a "stack" of patches.
Each patch is a changeset against the base tree plus the preceding patches.
All patches are listed, in order, in the file ./series. You manage the
series file.
Any currently-applied patches are described in the file
./applied-patches. The patch scripts manage this file.
Each patch affects a number of files in the tree. These files are
listed in a "patch control" file. These .pc files live in the
directory ./pc/
Patches are placed in the directory ./patches/
Documentation for the patches is placed in ./txt/
So for a particular patch "my-first-patch" the following will exist:
- An entry "my-first-patch.patch" in ./series
- An entry "my-first-patch" in ./applied-patches (if it's currently applied)
- A file ./pc/my-first-patch.pc which contains the names of the
files which my-first-patch modifies, adds or removes
- A file ./txt/my-first-patch.txt which contains the patch's
changelog.
- A file ./patches/my-first-patch.patch, which is the output of the
patch scripts.
Operation
=========
When a patch "my-patch" is applied with apatch, or with pushpatch
(which calls apatch), all the affected files (from ./pc/my-patch.pc)
are copied to files with ~my-patch appended. So if ./pc/my-patch.pc
contained
kernel/sched.c
fs/inode.c
then apatch will copy those files into kernel/sched.c~my-patch and
fs/inode.c~my-patch. It will then apply the patch to kernel/sched.c
and fs/inode.c
When a diff is regenerated by refpatch (which calls mpatch), the diff
is made between kernel/sched.c and kernel/sched.c~my-patch. How do the
scripts know to use "~my-patch"? Because my-patch is the current
topmost patch. It's the last line in ./applied-patches.
In this way, the whole thing is stackable. If you have four patches
applied, say "patch-1", "patch-2", "patch-3" and "patch-4", and if
patch-2 and patch-4 both touch kernel/sched.c then you will have:
kernel/sched.c~patch-2 Original copy, before patch-2
kernel/sched.c~patch-4 Copy before patch-4. Contains changes
from patch-2
kernel/sched.c Current working copy. Contains changes
from patch-4.
This means that your diff headers contain "~patch-name" in them, which
is convenient documentation.
Walkthrough
===========
Let's start.
Go into /usr/src/linux (or wherever)
mkdir pc patches txt
Now let's generate a patch
fpatch my-patch kernel/sched.c
OK, we've copied kernel/sched.c to kernel/sched.c~my-patch. We've
appended "my-patch" to ./applied-patches and we've put "kernel/sched.c"
into the patch control file, pc/my-patch.pc.
Now edit kernel/sched.c a bit.
Now we're ready to document the patch
Now write txt/my-patch.txt
Now generate the patch
refpatch
This will generate patches/my-patch.patch. Take a look.
Now remove the patch
poppatch
applied-patches is now empty, and the patch is removed.
Now let's add a file to my-patch and then generate my-second-patch:
Add "my-patch.patch" to ./series (no blank lines in that file please)
pushpatch
OK, the patch is applied again. Let's add another file
fpatch kernel/printk.c
Note that here we gave fpatch a single argument. So rather than
opening a new patch, it adds kernel/printk.c to the existing topmost
patch. That's my-patch.
Edit kernel/printk.c
Refresh my-patch (you end up running refpatch a lot)
refpatch
Now start a second patch:
fpatch my-second-patch kernel/sched.c
Now take a look at applied-patches. Also do an `ls kernel/sched*'.
Edit kernel/sched.c, to make some changes for my-second-patch
Generate my-second-patch:
refpatch
Take a look in patches/my-second-patch.patch
Don't forget to add "my-second-patch.patch" to the series file.
And remove both patches:
poppatch
poppatch
That's pretty much it, really.
Command reference
=================
Generally, where any of these commands take a "patch-name", that can be
of the form txt/patch-name.txt, patch-name.pc, just patch-name or
whatever. The scripts will strip off a leading "txt/", "patches/" or
"pc/" and any trailing extension. This is so you can do
apatch patches/a<tab>
to conveniently use shell tabbing to select patch names.
added-by-patch
Some internal thing.
apatch [-f] patch-name
This is the low-level function which adds patches. It does the
copying into ~-files and updates the applied-patches file. It
applies the actual patch.
apatch will do a patch --dry-run first and will refuse to apply the
patch if the dryrun fails.
So when you are getting rejects you do this:
pushpatch # This fails, due to rejects. Drat.
apatch -f patch-name # Force the patch
OK, you've now applied patch-name, but you have rejects. Go fix
those up and do
refpatch
And you're ready to move on.
cvs-take-patch
I forget.
fpatch [patch-name] foo.c
If patch-name is given, fpatch will start a new patch which
modifies (or adds, or removes) the single file foo.c. It updates
./applied-patches and creates pc/patch-name.pc. fpatch will copy
foo.c to foo.c~patch-name in preparation for edits of foo.c.
If patch-name is not given then fpatch will add foo.c to the
current topmost patch. It will add "foo.c" to ./pc/$(toppatch).pc.
It will copy foo.c to foo.c~$(toppatch).
inpatch
List the names of ths files which are affected by the current
topmost patch.
This is basically
cat pc/$(toppatch).pc
mpatch
A low-level thing to generate patches
new-kernel
Some thing I use for importing a new kernel from kernel.org
p0-2-p1
Internal thing to convert patch -p0 form into patch -p1
patchdesc
Generates a single-line description of a patch.
The txt/my-patch.txt files have the following format:
<start of file>
DESC
some short description
EDESC
The long description
<end of file>
I use
patchdesc $(cat series)
to generate short-form summaries of the patch series.
patchfns
Internal utilities
pcpatch
Standalone tool to generate a .pc file from a patch.
Say someone sends you "his-patch.diff". What you do is:
cp ~/his-patch.diff patches/his-patch.patch
pcpatch his-patch
This generates ./pc/his-patch.pc and you're all set. Add
"his-patch.patch" to ./series in the right place and start pushing.
p_diff
I forget
poppatch
Remove one or more patches fro the current stack. This command
does *not* use the series file. It works purely against
applied-patches.
Usage:
poppatch
Remove the topmost patch
poppatch 10
Remove ten patches
poppatch some-patch-name[.patch]
Remove patches until "some-patch-name" is top patch
ptkdiff
Two modes:
ptkdiff -
Run tkdiff against all the file affected
by $(toppatch). The diff is only for the changes made
by the top patch! ie: it's between "filename" and
"filename~toppatch-name".
ptkdiff filename
Just run tkdiff against that file,
showing the changes which are due to toppatch.
pushpatch
Apply the next patch, from the series file.
This consults ./applied-patches to find out the top patch, then
consults ./series to find the next patch. And pushes it.
pushpatch
Apply the next patch
pushpatch 10
Apply the next ten patches
pushpatch some-patch-name
Keep pushing patches until "some-patch-name" is toppatch
refpatch
regnerates the topmost patch. Reads all the affected files
from pc/$(toppatch).pc and diffs them against their tilde-files.
Also pastes into the patch your patch documentation and
generates a diffstat summary.
removed-by-patch
Some thing.
rename-patch
CVS rename for patches.
rolled-up-patch
Bit of a hack. Is designed to generate a rolled-up diff of all
currently-applied patches. But it requires a ../linux-2.x.y tree to
diff against. Needs to be redone.
rpatch
Internal command
split-patch
Some thing someone write to split patches up. I don't use it.
toppatch
Print the name of the topmost patch. From ./applied-patches
touched-by-patch patch-filename
List the names of files which are affected by a diff.
unitdiff.py
Rasmus Andersen's script to convert a diff into minimum-context
form. This form has a better chance of applying if you're getting
nasty rejects. But patch can and will make mistakes when fed
small-context input.
Work Practices
==============
I keep the kernel tree, the ./pc/, ./patches/ and ./txt/ contents under
CVS control. This is important...
I have several "series" files. I keep these in ./pc/foo-series and use
ln -s pc/foo-series series
when I'm working on foo.
If someone sends me a patch I'll do:
cp ~/whatever patches/his-patch.patch
pcpatch his-patch
apatch his-patch
If apatch fails then run `apatch -f his-patch' and fix the rejects.
refpatch
to clean up any fuzz.
poppatch
cvs add pc/his-patch.pc patches/his-patch.patch
cvs commit pc patches
Now edit ./series and place "his-patch.patch" in the appropriate place.
If you're working on a particular patch (say, "dud-patch") and you
balls something up, just run:
refpatch # Generate the crap patch
poppatch # Remove it all
rm patches/dud-patch.patch
cvs up patches/dud-patch.patch
and all is well.
Getting updates from Linus
==========================
What I do is to grab the latest -bk diff from
http://www.kernel.org/pub/linux/kernel/people/dwmw2/bk-2.5/
and do:
gzip -d < cs<tab> > patches/linus.patch
pcpatch linus
apatch linus | grep diff
Now fix up all the files which got deleted,
because there's something wrong with bitkeeper diffs:
cvs up -ko <missing files from the above diff>
apatch linus
$EDITOR linus/linus.txt
Add the changeset number to txt/linus.txt
refpatch
poppatch
Now add "linus.patch" as the first entry in your ./series file and
start pushing your other patches on top of that.
BUGS
====
Tons and tons. The scripts are fragile, the error handling is ungraceful and
if you do something silly you can end up in a pickle.
Generally the scripts are very careful to not wreck your files or your
patches. But they can get the ./applied-patches and ~-files into an
awkward state.
Usually you can sort it out by copying the ~-files back onto the originals
and removing the last line from ./applied-patches. Or do a "refpatch ;
poppatch ; rm patches/troublesome-patch.patch ; cvs up patches".
If it's really bad, just blow away the entire tree and do a new CVS checkout.
Working on non-kernel projects
==============================
Well it's the same thing. Say you've downloaded a copy of util-linux
and you want to make a change:
cd /usr/src
tar xvfz ~/util-linux.tar.gz
cd util-linux
mkdir pc patches txt
fpatch my-patch sys-utils/rdev.c
fpatch sys-utils/ipcs.8
<edit, edit>
refpatch
<ship patches/my-patch.patch>
How to balls things up
======================
Well here's one way. Suppose you have 20 patches applied, and three of
them (say, "p1", "p6" and "p11") all modify "foo.c".
Now you go and change foo.c.
Well, to which patch does that change belong? You need to decide.
Let's say you decide "p6".
If you run `refpatch' when "p11" is toppatch then you lose. The diff
went into p11.
What you can do is:
1:
poppatch p6
<edit>
refpatch
pushpatch p11
<test>
(See why ccache is looking good?)
or
2:
<edit>
<test>
poppatch p6 <hope like hell that the other patches remove cleanly>
refpatch
Another good way of ballsing up is to cheat. Say "oh I just want to make
this one-line change". And "oh, and this one".
Now you're getting in a mess. It's much, much better to just use the system:
fpatch junk file1
fpatch file2
<edit>
<play>
refpatch
poppatch
rm pc/junk.pc patches/junk.patch
Merging with -mm kernels
========================
Haven't tried this, but it should work:
- Grab all the patches from broken-out/, place them in your ./patches/
- Copy my series file into ./series (or ./pc/akpm-series and symlink it)
- pushpatch 99
And you're off and running. The nice thing about this is that you can
send me incremental diffs to diffs which I already have.
Or whatever. I'm fairly handy with diffs nowadays. Rejects are
expected. I just prefer to have "one concept per diff".
Oliver Xymoron was very impressed with all of this, and said, "My own personal
scripts (while obviously not getting nearly the workout yours are) make at
least one part noticeably simpler - I use a complete 'cp -al' for the current
"top of the applied stack" rather than your foo.c~bar files. This means I don't
have to explicitly keep track of which files I'm touching and just let diff
compare the entire tree (which is fast as diff apparently recognizes hard
links). My equivalent of refpatch spews out a diffstat so that I can easily
notice if I touched something I didn't mean to." Andrew replied:
That has always seemed unnatural to me. By keeping everything in the one
tree you can easily:
+ collapse patches together:
pushpatch first-patch
for i in $(cat pc/second-patch.pc)
fpatch $i
done
patch -p1 < patches/second-patch.patch
refpatch
+ Reorder patches (edit series file, poppatch 10; pushpatch 10)
+ Remove a patch which is partway down the stack:
rpatch patch-7-out-of-10
+ make changes to a not-topmost patch without having to do anything
special.
Dunno. There are probably ways of doing all these things with a whole-tree
copy, but I haven't tried to plot it all out.
Changelog tracking is fairly important to me also.
mnm:/usr/src/25> ls -l txt|wc -l
560
20. Linux Kernel conf 1.1
20 Oct (1 post) Archive Link: "linux kernel conf 1.1"
Roman Zippel announced:
At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of the
new config system. Smaller changes:
+ update to 2.5.44
+ new qconf option, which enables some debug output in the help window
The only big change this time is that I added a SWIG interface, which
allows to generate a extension library for your favourite script language.
I did this already for ruby, 'make ruby' builds the library kconfig.so in
the .ruby subdir. I also included some examples.
21. Preparing For Final Merge Before 2.5 Feature Freeze
20 Oct - 21 Oct (11 posts) Archive Link: "Crunch time -- Final merge
candidates for 3.0 (the list)."
Rob Landley reported:
Okay, Linus has left for the Linux Lunacy Cruise (see www.geekcruises.com (
http://www.geekcruises.com) ), which ends october 27. When he gets back,
he's implied that there will be EXACTLY ONE more set of last minute merges
before we switch over to the 3.0-pre (or 2.6-pre) series. Those of you
waiting for the last minute: this is it.
There are people patch-hoovering while Linus is off "lecturing" on a boat
in the carribean, but we don't know who those are, so that's not useful.
What IS useful is knowing what the candidate patches are. Not bug fixes,
but new features with one final shot at 2.5.45.
He posted a list of merge candidates culled from Guillaume Boissiere status
list (http://kernelnewbies.org/status/) :
+ in -ac PCMCIA Zoom video support (Alan Cox)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html
+ in -ac Device mapper for Logical Volume Manager (LVM2) (LVM2 team)
http://www.sistina.com/products_lvm.htm
+ in -mm VM large page support (Many people)
http://lse.sourceforge.net/
+ in -mm Page table sharing (Daniel Phillips, Dave McCracken)
http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
(or possibly here:)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
+ Ready - Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
+ Ready - Dynamic Probes (dprobes team)
http://oss.software.ibm.com/developerworks/opensource/linux/projects/
dprobes
+ Ready - Zerocopy NFS (Hirokazu Takahashi)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
+ Ready - High resolution timers (George Anzinger, etc.)
http://high-res-timers.sourceforge.net/
+ Ready - EVMS (Enterprise Volume Management System) (EVMS team)
http://sourceforge.net/projects/evms
+ Ready - Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
http://lkcd.sourceforge.net/
+ Ready - Rewrite of the console layer (James Simmons)
http://linuxconsole.sourceforge.net/
To the above can be added the following recent submission on the list:
+ Ready- Kexec, luanch ELF format linux kernel from Linux (Eric W.
Biederman)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
He went on:
That's currently it, that I'm aware of. If your patch isn't on that list,
and getting testing by people on linux-kernel (and getting a bunch of
satisifed users to go "worked for me!" at it), then you should speak up and
GET it on that list, or wait for the next development series.
When Linus comes back, at best he's going to give a thumbs up or thumbs
down to each patch currently sitting there in front of him, and then it's
on to the feature freeze. He may not take any of them, or he may just take
one or two. But the best we can hope to do is present him with a nice
(short) list of tested patches. (Remember, the less work Linus has to do,
the higher the percentage of it that will actually get done.)
So everybody, try the above patches. If they work for you, say so on this
list. It's no guarantee, but Linus has said endorsements from testers can
make him feel more comfortable about a patch. Possibly we can collect a
list of names of people for whom a patch "worked for me", to add to the
list.
If your patch isn't on the list, speak out now. Better yet, post a URL to
the latest version. It's "show me the code" time. (Yes, Hans Reiser, this
means you. :) There are still 7 days till the end of Linus's cruise, but
that's not much time to get guinea pigs to publicly pipe up with a hearty
"AOL!" of support for your work...
Again, some of the things on this list won't make it into 3.0. It's just
candidates. But everything that is NOT on this list in about 7 days is
probably going to become 3.1 material by default.
Speak now, or till 3.1 hold your peace...
Hans Reiser said his group would send Reiser4 out by around the 27th.
Denis Vlasenko suggested, "Well, maybe it makes sense to reduce flow of
non-features patches for a couple of days to let Linus feel less buried in
email? I think VM tweaking and such... It could be done after Linus say what
got in and what did not." Rob replied:
It would also be nice to buy the dude his own private jet, but I'm not sure
it's a practical suggestion in the short term. :)
Linus has already said he intends to read his mail with the "D" key when he
gets back. The point of collating the pending feature list is to pluck
stuff out of the mess, shake it off a bit, and present him with a nice menu
to make choices from on his return.
Deciding not to include stuff is Linus's perogative. (More than that, it's
more or less his JOB in kerneldom, acting as goalie for the main tree.)
Once again, we're just trying to make sure nothing gets dropped because he
didn't see it rather than because he saw it and went "no".
In the past half-hour, the MMU-less patch and unlimited groups support have
been fielded as "ready for 2.5", although I haven't seen URLs to either
yet. Add Rusty's three items and we're up to... 19? Plus Hans Reiser said
reiser4 will be ready around the 27th, so that's 20.
I don't think half that many will make it into 2.5, but some of them are
small, so...
Regarding the status of LTT, Karim Yaghmour said:
LTT has seen a number of changes since the posting above. Mainly, we've
followed the recommendations of quite a few folks from the LKML. Here are
some highlights summarizing the changes:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
The latest patch is available here:
http://opersys.com/ftp/pub/LTT/ExtraPatches/
patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
Use this patch with version 0.9.6pre2 of the user tools:
http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
Rob said:
Another thing I've noticed somebody still hoping to shoehorn into 2.5 is
Roman Zippel's new kernel configuration system, which is here:
Announcement:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
Code:
http://www.xs4all.nl/~zippel/lc/
That was listed as a "beta" on the status list, I guess at version 1.1, it
has now been promoted. (Anything else on the beta that's still trying to
make it into 2.5? The 27th is sunday, meaning Linus should be back at
transmeta on monday. Assuming 2.4.45 ships on the 31st, that would be the
following thursday...)
Ted Tso has also been posting new ext2/ext3 code with extended attributes
and access control lists.
Announcement:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
Code (chooe your poison):
bk://extfs.bkbits.net/extfs-2.5-update
http://thunk.org/tytso/linux/extfs-2.5
Apparently generic ACL support went into 2.5.3 (the status list again), but
I guess it wasn't added to EXT2. I suppose this makes this a good candidate
for inclusion then. :)
So, 11 items from the 2.5 status list (in -aa, in -mm, and "ready"), plus
kexec, kernelconfig, and ACL for EXT3. I believe this brings the total
number of pending patchsets still hoping for 2.5 inclusion to 14.
I can repost the full list if nobody beats me to it, but I think I'll wait
to see who else pipes up first. :)
Andreas Dilger said he thought Theodore Y. Ts'o's EA/ACL work had made it into
Andrew Morton's -mm kernel series. Rob asked if this meant it would definitely
make it into Linus Torvalds' tree. Andreas said no, it was no guarantee, but it
was a step in the right direction. Andrew also confirmed that his tree was not
a magic carpet into the kernel, saying:
It's mainly there for the other VM/MM/IO developers to integrate against.
Also for getting their more experimental work more testing and exposure.
Also for getting external testing of the performance work which is going
into it.
Also for maintainers of other architectures to pick up breakage before
things break.
I prefer to only send things which I understand and have tested. So that
excludes, say, dcache-rcu and the EA/xattr patches. I did send ext3-htree,
but it had big "I haven't tested this" labels all over it.
22. Kernel 2.5.44-mm2 Released
21 Oct (6 posts) Archive Link: "2.5.44-mm2"
Andrew Morton announced:
url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.44/2.5.44-mm2/
+ Some more work on the per-cpu memory arenas
+ Added a bunch of fixes to various things courtesy of davem
+ Merged up a later version of the EA+ACL code
+ Lots of little fixes everywhere.
+ Fixed a shared pagetable SMP deadlock
23. RSBAC 1.2.1 Released
22 Oct (1 post) Archive Link: "Announce: RSBAC v1.2.1 released"
Amon Ott announced:
Rule Set Based Access Control (RSBAC) version 1.2.1 has been released. Full
information and downloads are available from http://www.rsbac.org
RSBAC is a flexible, powerful and fast open source access control framework
for current Linux kernels, which has been in stable production use since
January 2000 (version 1.0.9a). All development is independent of
governments and big companies, and no existing access control code has been
reused.
This version comes with many smaller improvements against 1.2.0 and some
new features, e.g.:
+ New JAIL module, similar to the FreeBSD Jails functionality, but with
extensions like individual IPC compartments.
+ Support for all architectures (not all of them tested, feedback is
welcome).
We Hope You Enjoy Kernel Traffic
All Kernel Traffic and Cousin issues and summaries are copyright their original
authors, and distributed under the terms of the
GNU General Public License, version 2.0.