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.
Daniele Lugli discovered a strange reserved-word situation in the kernel,
when he tried to name one of the fields of a struct in her module, 'current'.
After several days of anguished hunting, he tracked the problem down to
asm/current.h, indirectly included in his 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.
He 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.
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.
Corey Minyard announced version 7 of the IPMI driver,
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.
Linus Torvalds announced 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.
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 <linux-kernel@vger.kernel.org> Post anything related to Linux kernel here, but nothing else :-) Andre Hedrick <andre@linux-ide.org> [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 <jgarzik@mandrakesoft.com> [24 sep 2002] I am the network-card-drivers guy (8139 for instance). CC me and Andrew Morton <akpm@zip.com.au> on network driver patches. Jan-Benedict Glaw <jbglaw@lug-owl.de> [18 sep 2002] I'm responsible for Alpha's srm_env driver, providing access to SRM's firmware variables. Stuart MacDonald <stuartm@connecttech.com> [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 <vojtech@ucw.cz> [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 <rml@tech9.net> [12 sep 2002] Preemptible kernel maintainer. I am also interesting in anything related to scheduling or locking primitives. Jan Kara <jack@suse.cz> [22 aug 2002] quota subsystem maintainer Paul Larson <plars@linuxtestproject.org> [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 <engebret@vnet.ibm.com> [15 aug 2002] PPC64 architecture maintainer. Please send PPC64 patches to me and our mailing list at <linuxppc64-dev@lists.linuxppc.org> Ingo Molnar <mingo@elte.hu> [30 jul 2002] Ingo wrote the new scheduler for 2.5. Ralf Baechle <ralf@uni-koblenz.de> [30 jul 2002] I am maintainer of the AX.25 code Victor Yodaiken <yodaiken@fsmlabs.com> [30 jul 2002] RTLinux patches, updates, contributions, drivers. Please send first to the list: rtl@rtlinux.org Pavel Machek <pavel@ucw.cz> [27 jul 2002] I am network block device maintainer. Visit http://nbd.sf.net. (see Steven Whitehouse <steve@gw.chygwyn.com> entry) I am working on software suspend. William Irwin <wli@holomorphy.com> [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 <riel@surriel.com> Andrea Arcangeli <andrea@suse.de> Martin Bligh <Martin.Bligh@us.ibm.com> Andrew Morton <akpm@zip.com.au> Dave Jones <davej@suse.de> [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 <andrea@suse.de> [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 <Martin.Bligh@us.ibm.com> entry Mail also: Arjan van de Ven <arjanv@redhat.com> Martin J. Bligh <Martin.Bligh@us.ibm.com> [28 mar 2002] I'm interested in VM issues with lots (>4G for i386) of RAM, lots of CPUs, NUMA Steven Whitehouse <steve@chygwyn.com> [27 mar 2002] I am the Linux DECnet network stack maintainer Visit http://www.chygwyn.com/decnet/ Arnaldo Carvalho de Melo <acme@conectiva.com.br> [26 mar 2002] IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org, cyclom2x sync card driver John Cagle <jcagle@kernel.org> [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 <device@lanana.org>. Tigran Aivazian <tigran@veritas.com> I am author and maintainer of BFS filesystem and IA32 microcode update driver. Rogier Wolff <R.E.Wolff@BitWizard.nl> [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 <martin@dalecki.de> [11 mar 2002] IDE subsystem maintainer for 2.5 (mail Vojtech Pavlik <vojtech@suse.cz> too) Ed Vance <serial24@macrolink.com> [05 mar 2002] Maintainer for the generic serial driver, serial.c, for 2.2 and 2.4 kernels. Please post patches to linux-serial@vger.kernel.org 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 serial24@macrolink.com netfilter/iptables development <netfilter-devel@lists.samba.org> [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 <reiser@namesys.com> [16 feb 2002] Send me all reiserfs related patches with a cc to reiserfs-dev@namesys.com, send bug reports to reiserfs-dev@namesys.com, send paid support requests to support@namesys.com after going to www.namesys.com/support.html to pay, send discussions (not bug reports unless they are interesting to most persons) to reiserfs-list@namesys.com. 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 <paul@paulbristow.net> [16 feb 2002] I am an ide-floppy driver maintainer (ATAPI ZIP, LS-120/240 Superdisk, Clik! drives). Mike Phillips <phillim2@comcast.net> [15 feb 2002] Token ring subsystem and drivers. Anton Altaparmakov <aia21@cam.ac.uk> [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 <alan@lxorguk.ukuu.org.uk> [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 <alsa-devel@alsa-project.org> [12 feb 2002] Jaroslav Kysela <perex@perex.cz> [12 feb 2002] Advanced Linux Sound Architecture ALSA patches are available at ftp://ftp.alsa-project.org/pub/kernel-patches/* Neil Brown <neilb@cse.unsw.edu.au> [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 <maxk@qualcomm.com> [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 <riel@conectiva.com.br> [07 feb 2002] Send me VM related stuff, please CC to linux-mm@kvack.org Geert Uytterhoeven <geert@linux-m68k.org> [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 <hpa@zytor.com> [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 <ftpadmin@kernel.org> [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 <greg@kroah.com> [07 feb 2002] I am USB and PCI Hotplug maintainer. Trond Myklebust <trond.myklebust@fys.uio.no> [07 feb 2002] I am NFS client maintainer. James Simmons <jsimmons@transvirtual.com> [07 feb 2002] Console and framebuffer sybsustems. I also play around with the input layer. Richard Gooch <rgooch@atnf.csiro.au> [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 <rmk@arm.linux.org.uk> [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 rmk+serial@arm.linux.org.uk Andrew Morton <akpm@zip.com.au> [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 <vandrove@vc.cvut.cz> [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 <reiserfs-dev@namesys.com> [05 feb 2002] Send all reiserfs-related stuff here including but not limited to bug reports, fixes, suggestions. Oleg Drokin <green@linuxhacker.ru> [05 feb 2002] SA11x0 USB-ethernet and SA11x0 watchdog are mine. ======= These entries are suggested by lkml folks ======== Ralf Baechle <ralf@gnu.org> [27 mar 2002] I am mips/mips64 maintainer. David S. Miller <davem@redhat.com> [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 <urban@teststation.com> [13 feb 2002] smbfs video4linux list <video4linux-list@redhat.com> [12 feb 2002] Gerd Knorr <kraxel@bytesex.org> [12 feb 2002] video4linux Tim Waugh <twaugh@redhat.com> [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 <viro@math.psu.edu> [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 <esr@thyrsus.com> [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 <groudier@free.fr> [5 feb 2002] I am SCSI guy. Jens Axboe <axboe@suse.de> [5 feb 2002] I am block device subsystem maintainer. Linus Torvalds <torvalds@transmeta.com> [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 <davej@suse.de>, see his entry). Sorry, I can't do everything. Marcelo Tosatti <marcelo@conectiva.com.br> [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 <alan@lxorguk.ukuu.org.uk>, - Rusty Russell <trivial@rustcorp.com.au>. Rusty Russell <rusty@rustcorp.com.au> [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 trivial@rustcorp.com.au.
James Simmons pointed out that his new email address was jsimmons@infradead.org
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.
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.gzThe big changes are:
- I have rebundled my tools so it is a little easier to get at:
- 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.
- I have added a call to device_shutdown so device drivers get a chance to shut up.
- 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.
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.
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.
Eric Altendorf asked which Kernel
book folks liked best. Jonathan Corbet recommended Understanding
The Linux Kernel and ia-64
Linux Kernel, as well as his own book, Linux
Device Drivers (also available for free at xml.com). Ron
Henry said, I'd also recommend "Unix
Internals: The New Frontiers". 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. Its not about Linux but its one of the best intros to the whole
topic.
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.
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.
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
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
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.
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
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.bz2For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.htmlOther links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
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.
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
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.
Rob Landley reported:
Okay, Linus has left for the Linux Lunacy Cruise (see 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:
- 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=2The 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.5Apparently 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.
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
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).