Jesse Barnes posted a patch, and announced:
Here's the lastest version of the lockassert patch. It includes:
- MUST_HOLD for all architectures
- MUST_HOLD_RW for architectures implementing rwlock_is_locked (only ia64 at the moment, as part of this patch)
- MUST_HOLD_RWSEM for arcitectures that use rwsem-spinlock.h
- MUST_HOLD_SEM for ia64
- a call to MUST_HOLD(&inode_lock) in inode.c:__iget().
I'd be happy to take patches that implement the above routines for other architectures and/or patches that sprinkle the macros where they're needed.
Joshua MacDonald pointed out that the ReiserFS developers were looking
forward to having a MUST_NOT_HOLD assertion. Jesse replied, Well, I had that in one version of the patch, but people didn't think
it would be useful. Maybe you'd like to check out Oliver's comments at http://marc.theaimsgroup.com/?l=linux-kernel&m=102644431806734&w=2
and respond? If there's demand for MUST_NOT_HOLD, I'd be happy to add it
since it should be easy.
Robert Love also suggested implementing
CAN_SLEEP and CANNOT_SLEEP assertions.
Since the new serial core code went into 2.5, David Gibson had been
trying to get it working on his PowerPC (EP405 board). But the 8250 serial
port on his system was giving him difficulties. He described the specific
symptoms and work-arounds he was using, and also remarked, The current plethora of similar-but-not-the-same structures describing
serial ports (serial_state, serial_struct, uart_port, old_serial_port) is also
rather confusing. I'm guessing some of these are deprecated and remain only as
an aid to transition, but I'm not sure which.
Russell King replied:
I don't see there being an easy way to kill this off:
- serial_struct is a userspace API.
- old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be changed because (mainly) ppc uses it elsewhere. Other architectures seem to do the same sort of thing.
Unless ppc and others are willing to put up with major breakage when I change asm/serial.h, I don't see this getting cleaned up. Comments on this area welcome.
Tom Rini asked what changes Russell had in mind, and Russell said:
1. Serial port initialisation
Firstly, one thing to bear in mind here is that, as Alan says "be nice to make sure it was much earlier". I guess Alan's right, so we can get oopsen out of the the kernel relatively easily, even when we're using framebuffer consoles.
I'm sure Alan will enlighten us with his specific reasons if required.
There have been several suggestions around on how to fix this table:
a. architectures provide a sub-module to 8250.c which contains the per-port details, rather than a table in serial.h. This would ideally mean removing serial.h completely. The relevant object would be linked into 8250.c when 8250.c is built as a module.
b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends each containing the parameters for the specific cards and handle it as above.
c. make it the responsibility of user space to tell the kernel about many serial ports, and leave just the ones necessary for serial console in the kernel. (see issue 2 below)
d. we keep serial.h, make it 8250-compatible ports only, and change CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT This is the simplest and least likely to break other code. On the other hand, we end up hauling the ISA table and struct old_serial_port into 2.6.
2. setserial API
This is actually tied closely into another issue; I'd like to get rid of this silly idea where we're able to open serial ports that don't exist (ie, their UART is "unknown"). This behaviour appears to be for the benefit of setserial to allow it to modify port base addresses and interrupt levels, etc. Removing this facility would require a new API for such things. The best suggestion made so far is to do something like:
# echo "add 0x2e8,3,autoconfig" >/dev/serialctl
# echo "remove 0x2e8" >/dev/serialctl(or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)
where we have "add ioport,irq,flags" and "remove ioport" (note that mmio ports aren't covered here since they require ioremap games which tends to be card specific!)
Why make this change? Well, we have quite a lot of baggage being dragged around to support configuration of an open port and being able to open a non-existent port. I'd really like to get rid of this excess baggage.
3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
All the above are serial ports of various types. It has been expressed several times that people would like to see all of them appear as /dev/ttyS* (indeed, there was an, erm, rather heated discussion about it a couple of years ago.) I'm going to be neutral on this point here.
There are several issues surrounding this:
a. The serial core.c is very almost capable of handling this abstraction, with one exception - a registered port can only be in one group at one time. This restriction is brought about because of the way the tty layer handles its tty ports.
(Handling dual registrations in two different majors gets _really_ messy - eg, you two built-in 16550A ports and two SA1100 ports taking up ttyS0 to ttyS3. You then add a 16550A PCMCIA modem, which becomes ttyS4. Oh, and the SA1100 ports are also appearing as ttySA0 and ttySA1. _really_ messy. No thanks.)
b. serial consoles. Each hardware driver handles its serial consoles by itself, and if you have two or more hardware drivers built in with serial console support, you need to be able to tell them apart with the console= kernel parameter.
Again, this could be solvable if we have one "ttyS" view of everything (core.c would then be responsible for registering the console with printk.c and passing the various methods off to the relevant hardware).
c. People with many serial ports. We _could_ change the device number allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc device numbers so we end up with the same number of port slots available for those with many many serial ports in their machines.
Various comments and criticisms followed this, but nothing was conclusively
decided. See
Tim Hockin ran drivers/char/nvram.c through Lindent, added a few manual cosmetics of his own, and posted the patch. Linus Torvalds replied:
Hmm.
If you're doing these kinds of Lindent changes, you might as well also fix another non-linuxism:
return (x); -> return x;I don't know why some people seem to think that "return" is a function with an argument..
I guess that one isn't mentioned in the CodingStyles thing. I'm lazy. Bad Bad Linus.
Tim did this, and submitted two new patches, one for 2.4 and one for 2.5. Pavel Machek also suggested updating CodingStyle while he was at it....
In the course of discussing whether or not various I/O operations (such as file reads) could be interrupted by signals, Linus Torvalds gave an opinion on POSIX:
POSIX is a hobbled standard, and does not matter.
We're not making a "POSIX-compliant OS". People have done that before: see all the RT-OS's out there, and see even the NT POSIX subsystem.
They are uninteresting.
Linux is a _real_ OS, not some "we filled in the paperwork and it is now standards compliant".
And being a real OS means taking the real world into account.
And the real world says that it's not acceptable to make up your own semantics, unless you have some _damn_ good reason for doing so.
Peter J. Braam said that his company really wanted to use files larger
than 16TB, and filesystems with more than a trillion files in them. He said,
I understand why people don't want to sprinkle
the kernel with u64's, and arguably we can wait a year or two and use 64
bit architectures, so I'm probably not going to kick up a fuss about it.
However, I thought I'd let you know that there are organizations that _really_
want to have such big files and file systems and get quite dismayed about
"small integers". And we will fail to deliver on a requirement to write a
50TB file because of this.
Andrew Morton pointed out that while it
might not be such a huge task to go through the code changing each relevant
'unsigned long' to a 'pgoff_t' and tweak a few other areas, there were still
some problems to getting such code accepted. He said:
Linus's objections are threefold: it expands struct page, 64 bit arith is slow and gcc tends to get it wrong. And I would add "most developers won't test 64-bit pgoff_t, and it'll get broken regularly".
The expansion of struct page and the performance impact is just a cost which you'll have to balance against the benefits. For a few people, 32-bit pagecache index is a showstopper and they'll accept that tradeoff.
Sprinkling `pgoff_t' everywhere is, IMO, not a bad thing - it aids code readability because it tells you what the variable is used for.
As for broken gcc, well, the proponents of 64-bit pgoff_t would have to work to identify the correct gcc version and generally get gcc doing the right thing.
Nico Schottelius suggested that, since the e100 network driver reported
connection status, speed, and other information; it would be great to export
that information to a file or directory in /proc/net. This would allow things
like a status light on a window manager control panel. There were a couple of
replies pointing out that the information Nico wanted was available through
ioctls. Jeff Garzik added that, Thou shalt not add to
the junk collection that is procfs :). Al Viro has talked about, long term,
making this information available through a filesystem. When that happens,
your request will have basically been implemented.
Marcin Dalecki posted his latest IDE patch, and listed:
- Integrate patches by Adam J. Richter, Alan Cox and Andre Hedrick for CMD640 PCI configuration space register access.
- cs5530 patches by Adam J. Richter. Small indent style adjustments.
- qd65xx cli()/sti() adjustments.
- Fix bogous command in ide.c pointed out by Peter Vendroviec.
- Eliminate ide_stall_queue(). For those worried: we didn't sleep at all.
- Eliminate support for "sector remapping". loop devices can handle stuff like that. All the custom DOS high system memmory loaded BIOS workaround tricks are obsolete right now. If anywhere it should be the FAT filesystem code which should be clever enough to deal with it by adjusting it's read/write methods.
- PCI "scather gather" allocation handling revamp by Adam J. Richter.
- Simplify do_ide_request after ->sleep removal.
- Make do_ide_request preferr to handle the device matching the request queue it was called for first. RQ-queues are unique for devices. In a next step queuedata will be changed to point to the device not the channel.
A couple folks objected to Marcin eliminating sector mapping support,
and Petr Vandrovec added that he was actually using that legacy feature on
one of his systems. He explained, it has BIOS
without LBA32, and without support for >30GB disks, but I needed to put
large disk with already existing system to it, and using some disk manager
was only choice (EZDrive, using 0_to_1 remap)... I know that 0_to_1 remap is
broken for nr_sectors > 1, but it is hard to use loop device if system does
not come up without boot manager at all.
Marcin still felt that the
IDE code was not the layer to handle this. He suggested, how about handling this at partition scan time then? Partitions are
after all nothing else then devices with remapped sectors in first place. Could
you manage to insert at the proper place in paritions/*.c the magical + 1.
It could then be turned in no instant in to a global kernel option - whch
it what it is after all.
He rooted around for a better understanding
of Petr's system and the best way to maintain support; and after a few more
posts the thread petered out.
Kevin Corry announced:
The EVMS team is announcing the next stable release of the Enterprise Volume Management System, which will eventually become EVMS 2.0. Package 1.1.0 is now available for download at the project web site:
http://www.sf.net/projects/evmsEVMS 1.1.0 has full support for the 2.4 kernel, and includes patches for most kernels up to 2.4.19-rc3. It also has nearly full support for the 2.5 kernel, and includes patches for kernels 2.5.25 and 2.5.27.
**** Important Note ****
As of this release, EVMS has been assigned a new, permanent major number: 117. The previous major number, 63, was reserved for experimental drivers. Before using 1.1.0, please read the README_Upgrade_To_1.1.0 file included in the source package for details on how you might be affected by the major number change. You can also view these instructions on the EVMS web site at
http://evms.sourceforge.net/new_major.html.************************
For on-going performance testing and analysis results for EVMS, please visit the Linux Scalability Effort site at:
http://lse.sourceforge.net/benchmarks/evms/Please send any questions, problem reports or bugs to the EVMS mailing list:
evms-devel@lists.sf.net.
There was no reply.
Muli Ben-Yehuda announced:
syscalltrack-0.73, the 9th _alpha_ release of the Linux kernel system call tracker, is now available. syscalltrack supports version 2.4.x of the Linux kernel on the i386 and UML architectures. Kernel versions 2.2.x and 2.5.x should work as well, but did not receive the same extensive testing. The current release contains a new experimental strace compatible tool, sctrace, a logging device file, several bug fixes and many new system calls, including all of the IPC syscalls. More details below.
* What is syscalltrack?
syscalltrack is made of a pair of Linux kernel modules and supporting user space environment which allow interception, logging and possibly taking action upon system calls that match user defined criteria. syscalltrack can operate either in "tweezers mode", where only very specific operations are tracked, such as "only track and log to delete /etc/passwd", or in strace(1) compatible mode, where all of the supported system calls are traced. syscalltrack can do things that are impossible to do with the ptrace mechanism, because its core operates in kernel space.
* Where can I get it?
Information on syscalltrack is available on the project's homepage: http://syscalltrack.sourceforge.net, and in the project's file release.
The source for the latest version can be downloaded directly from: http://osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.73.tar.gz or any of the other sourceforge mirrors.
* Call for developers:
The syscalltrack project is looking for developers, both for kernel space and user space. If you want to join in on the fun, get in touch with us on the syscalltrack-hackers mailing list (http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).
There was no reply.
Linus Torvalds announced 2.5.30 and posted the ChangeLog, saying:
Tons of stuff all over the map again. Lots of merging with various people.
The most noticeable fix (for me personally) was Trond fixing a nasty RPC problem that caused the NFS client to return bogus dentry pointers that hung the VFS layer hard on SMP machines.
But as you can see from the "short" changelog version (the full one is 63kB), there's a lot of other stuff there.
Continuing from
linux-2.5.30/include/linux/serialP.h needs struct async_icount, which is defined in <linux/serial.h>, causing linux-2.5.30/drivers/serial/8250.c not to compile, among other problems. In linux-2.5.30, you cannot compile a file that includes <linux/serialP.h> without including <linux/serial.h>. So, I think the solution is for serialP.h to #include serial.h. I have attached a patch that does this.
From the comments in serialP.h, it looks like there was some effort in linux-2.2 to allow inclusion of serialP.h without serial.h, but I see no indication of what benefit that was supposed to provide.
Ted (or whowever gathers drivers/serial patches for Linus), do you want to shepherd this change to Linus, do you want me to submit it directly, or do you want to do something else?
Russell King took a look, and said:
Ack. I've just found why I and many other people can build it, and other people can't. I can tell you that you're building 8250.c as a module.
Why?
When I build 8250.c into the kernel, linux/module.h doesn't include linux/version.h, so when we include linux/serialP.h, the compiler assumes that LINUX_VERSION_CODE is zero. So we end up including linux/serial.h.
However, when building as a module, linux/module.h does include linux/version.h, so when we don't include linux/serial.h.
Oh, the problems of trying to reduce the includes... I think we should re-include linux/serial.h and eliminate linux/serialP.h.
Hmm, I wonder how many other oddities like this are in the tree today. It sounds like we want to create a rule similar to the one for using CONFIG_* symbols. Does this sound reasonable: if you use LINUX_VERSION_CODE, you must include linux/version.h into that very same file to guarantee that it is defined.
Well, I took checkconfig.pl and created checkversion.pl (attached). Oh god, can I please put the worms back in the can? Now? I think there's lots of work to do here; lots of stuff including linux/version.h for the hell of it, and a comparitively small number not including it when they use LINUX_VERSION_CODE.
He posted his own fix and said that he was the person (Instead of Adam's idea of Theodore Y. Ts'o) to push these changes off to Linus. Russell warned folks not to send his patch to Linus but only to test it, as he had other stuff to include as well.
David Mosberger posted a patch for 2.5 and said, The patch below cleans up the cs4281 sound driver to compile cleanly
(no warnings) on 64-bit platforms such as ia64. Also, the patch updated the
calls to synchronize_irq() according to the new interface (which takes an
irq number as an argument). Someone who understands this driver might want
to double check that this is indeed working as intended.
Alan Cox
said he'd do the double checking, then port the whole patch back to 2.4.
Greg Ungerer announced:
I have a new set of uClinux (MMU-less) patches for 2.5.30 at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/
I have coded a generic MTD map driver to replace the old crufty blkmem driver. The blkmem driver will be going away in future patches.
Other than that it is still all working nicely.
Dave Jones didn't very closely examine the code, but said it looked as though more could be shared between Greg's code and the normal memory management code. Greg replied:
there is actually a lot in common. Probably something like 70%. This is really a question of organization.
I would much prefer to see the non-mmu support in with mm. But it would mean a few #ifdef's in there to allow for the differences.
Dave replied, Versus massive code duplication,
I think the ifdef's would be a better approach, especially if you can hide
them away in headers.
John Weber saw that Toshiba laptop support was broken in 2.5.30, and posted a patch to fix it. Alan Cox thought the patch looked "basically sound", and offered some implementation suggestions. John posted a new patch, and the thread ended.
Tom Rini posted his generic RTC driver patch, saying:
The is a slightly updated version of the patch that I've resent twice split up into 3 chunks, and 3 times as a single patch. The only changes this time are support for a 64bit kernel and a 32bit userland, from the parisc group, as well as include/asm-parisc/rtc.h, both from Randolph Chung.
Patch 1 is the current version of the driver (switched to C99-style initializers, done in the current m68k CVS tree) and needed changes to select/compile it in general. I had previously asked the m68k community if anyone objected to this being submitted by me, and I got Richard Zidlicky's (who's at the top of the file) approval, as well as Geert Uytterhoeven's approval.
Patch 2 is the PPC portion of the patch, which creates include/asm-ppc/rtc.h. This has been in the PPC bitkeeper tree for over a month now. I can have Paul Mackerras send this to you instead, if you prefer.
Patch 3 is my own slight bit of work, as well as some work by Randolph Chung. This changes set_rtc_time(struct *rtc_time) to return an int instead of void. This was done so that the arch-specific code here could do additional checks on the time and return an error if needed. This then introduces include/asm-generic/rtc.h, include/asm-i386/rtc.h and include/asm-alpha/rtc.h. include/asm-generic/rtc.h contains the get_rtc_time and set_rtc_time logic that is in drivers/char/rtc.c and has been tested on SMP i386. This also modifies include/asm-ppc/rtc.h to return -ENODEV if no rtc hardware is present.
Additionally, Dave Jones pointed out to me a place where we might not be safe when jiffies wraps, so this switches that to time_after().
From Randolph Chung, is supprt for a 64bit kernel and a 32bit userland.
And now onto the history of this driver.
This has been in the m68k tree for a number of years now, so the general code behind it is quite sound. This has also been abstracted to the point where it works on other archs (mainly due to m68k/PPC hybrid machines). This is quite useful since a number of archs cannot use drivers/char/rtc.c because they have very different hardware, or other issues.
This should also be useful on MIPS, who at one point in the past were about to copy the PPC rtc driver (drivers/macintosh/rtc.c) and quite probably useful on other archs as well.
This has been in use by the parisc-linux people as well for some time, and a version similar to this has been tested by them in 2.5.
Based on some private feedback, I believe with some additional enhancements, ia64 will make use of this as well. And if the MIPS community ever did make an rtc driver similar to drivers/macintosh/rtc.c, they should be able to use this one rather trivially.
There was no reply.
Jeff Dike announced:
UML has been updated to 2.5.30 and UML 2.4.18-49. Most of the UML-specific stuff has been in hppfs, which isn't in this patch. The exception is a fix for a crash caused by killing a UML xterm.
Since UML didn't make 2.5.30, I'll be sending this patch in to Linus.
The patch is available at http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.30-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
There was no reply.
Marcelo Tosatti announced 2.4.19,
being an unchanged copy of 2.4.19-rc5. James W. Laferriere noticed that
the tarball unpacked into a directory called linux-2.4.19/ instead of the
normal linux/ directory. Alan Cox said, Kernels until
recently did always unpack into linux/. Linus changed and I'm happy Marcelo
has followed suit, its much more sensible the new way.
And Bill
Davidsen added, Let's hope the major fix trees
like -aa and -ac follow the convention. I have no problem with the change
(since I keep my stuff that way) but I hope it is pervasive.
Andi Kleen announced:
A new linux/x86-64 snapshot based on linux 2.4.19 has been released. For more information on x86-64 see http://www.x86-64.org
Full tar ball: ftp://ftp.x86-64.org/pub/linux/v2.4/linux-x86_64-2.4.19-1.tar.bz2 (still uploading, will soon appear on server)
Patch against normal 2.4.19 from kernel.org ftp://ftp.x86-64.org/pub/linux/v2.4/x86_64-2.4.19-1.bz2
55331b0973fe86549102b0ca720be109 x86_64-2.4.19-1.bz2Changes:
- Merge to 2.4.19 final.
- Some minor bugfixes and cleanups.
There was no reply.
Wim Van Sebroeck said to Linus Torvalds:
I just sent you 6 bitkeeper patches for the i8xx series chipsets. The patches are:
- ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-1.txt This patch contains pci.ids updates for the i8xx chipsets
- ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-2.txt This patch makes the i810_rng Documentation the same as it is in 2.4.19
- ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-3.txt This patch adds a set of defines to pci_ids.h for 82801E and 82801DB I/O Controller Hub PCI-IDS. I could not add them all since two of them existed allready for the IDE controllers, but the naming was not ideal. That's why patch 5 and 6 corrects this.
- ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-4.txt This patch updates the i810-tco module to the same level as it is in 2.4.19 now.
- ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-5.txt This patch corrects the PCI-ID define for the 82801DB IDE controller.
- ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-6.txt This patch corrects the PCI-ID define for the 82801E IDE controller.
Linus replied, Please don't use "bk send" to
send me bitkeeper patches. They are totally unreadable, they are harder to
integrate than the alternatives (regular patches or BK trees to be pulled),
and they cause my inbox to have totally nondescript Subject: lines, so I
delete them automatically.
Pawel Kot announced:
New version of the NTFS-TNG backport is out. This version syncs with both: the latest NTFS driver -- 2.0.22 and the latest Linux kernel -- 2.4.19.
You can get the patch from the sourceforge servers. See the detailes at http://linux-ntfs.sf.net/downloads.html
There was no reply.
In the course of discussion, Tomas Szepe remarked, wouldn't it be useful to have dedicated errata pages for recent stable
kernels where important patches (such as the 2.4.18 personality fix, 2.4.18
samba oops fix or the upcoming 2.4.19 ide updates) would be published? Finding
a link to these in the kernel FAQ, people would just patch their kernels
instead of posting to lkml, which could cut on the amount of duplicate
bugreports significantly plus folks wouldn't have to wait 6 months+ for
an official update to get rid of an oops.
Alan Cox replied, I did that for some of the 2.2 trees. I can keep an errata
page on linux.org.uk for the 2.4.19 tree as well if people want. Right now
the errata would be pretty small so its easy to deal with.
An alarmed Felix Seeger noticed that his USB mouse stopped working after
upgrading to 2.4.19. Brad Hards pointed out that 2.4.19 added a new config
option, CONFIG_USB_HIDINPUT, which had to be set for USB mice. He added,
Checking the mailing list archives would have been
productive too.
Pavel Machek posted a short patch and said, This
fixes compilation and is actually right since we can't get SMP machine
suspending, anyway. We'll have to bring all other CPUs down for suspend in
future. Please apply.
Someone asked what part of the code ensured
that suspending an SMP machine could never happen. Pavel replied, It was broken before so I left it broken. Second CPU will
probably kill it fast enough not to corrupt data too badly.
The same
person suggested making the software-suspend code depend on CONFIG_SMP not
being set. There was no reply.
Anton Altaparmakov said:
Linus, please do a
bk pull http://linux-ntfs.bkbits.net/ntfs-tng-2.5
Thanks!
This is quite a massive bug fix update. I have a dual athlon with 3G RAM to play with at the moment so have been able to iron out a lot of races, recursive locking, and subsequent deadlocks.
This should also fix the reported ntfs over loopback i/o error problems. At least I can no longer reproduce the errors after I added the optimization barrier() in fs/ntfs/compress.c. I suspect gcc screws up without it...
There was no reply.
Wolfgang Pichler submitted a bug report against the 2.4.19 HFS code, adding
that it was the 4th time he'd submitted the identical report since 2.4.8; Alan
Cox replied, HFS is not maintained. It will probably
go away for 2.6 unless someone becomes its maintainer and fixes it.
And Benjamin Herrenschmidt added, I
noticed Al finally burned me on this as he did some locking fixes to HFS
in 2.5. I'm pretty sure more is needed, and I still have some plans to fix
some of it, in both 2.4 and 2.5, it's just that so far, I've always found
more important things to do of my linux dedicated time ;)
Paul Mackerras posted a patch and said, Here
is a patch which gets the offb and atyfb drivers to compile and run on PPC.
The patch is against 2.5.30. I also have patches for aty128fb and radeonfb but
they are more extensive and I want to work on them a little more.
There
was no reply.
Marcin Dalecki posted a patch and said:
The attached patch is updating the Maestro3 OSS sound chip driver to
- The changes in IRQ handling.
- C99 standard conformant initializers.
But Alan Cox said, This is insufficient. It has to
lock against card interrupts and other arbitary ill defined (in 2.4 anyway)
suspend things. Assuming the PM layer can mind its own business nowdays
you are at least going to want to take the card lock. I think thats mostly
sufficient for the maestro case. There is a long standing question about
whether the resume code should end by calling the irq handler to fake any
missed IRQ pending over the suspend of the card - but thats also true in
the 2.4 case.
End Of Thread (tm)
Tim Hockin posted a patch and said, This patch adds
support for Cobalt systems to the nvram driver. In the process, the nvram
symbols were exported, and a few other minor cleanup went in. This iwll
soon be available through bk, but I thought I'd solicit any gripes before
I push it up. :) This is another in a series of patches trying desperately
to get our tree synced :). If it all looks ok, I'll ask Marcelo and Linus
to pull it.
There was no reply.
Christoph Hellwig posted a patch and said, This patch against 2.4.20-pre1 converts /proc/partitions to the
seq_file interface as in 2.5, makes it report the sard-style extended disk
statistics condititional on CONFIG_BLK_STATS and disables the gathering of
those totally otherwise to not waste memory and processing power.
Kurt Garloff, author of the original code Christoph had back-written, added,
Actually, I was expecting criticism due to the
ifdef stuff I did and was prepared to come up with something better. But I
also learned never to put effort into something before being asked to ...
Your patch looks fine to me. Thanks for preparing it!
Andries Brouwer pointed out that /proc/partitions might not be the
best place for this data. He said, Maybe
/proc/partitions can go away eventually with all info available under
driverfs or so. But for the time being, /proc/partitions is used, and some
changes are planned to make identification of the devices involved easier.
It is really ugly to stuff a lot of garbage into a file just because it
happens to exist already. If you want disk statistics, why not put it in
/proc/diskstatistics?
Christoph replied that the user-space tools
expected to find the data in /proc/partitions, but Andries came back with,
You create a mess in the official kernel
because your user space tools are broken? And it is easier to patch the
kernel than to fix them, even though you'll have to fix them eventually?
And fixing these tools consists of replacing one filename?
Elsewhere, Randy Dunlap also thought the data should go in a different
place, and Christoph replied, Feel free to
implement it. This is the interface use by all major vendors for ages and
the -ac kernel series. It's supported by unpatched upstream performace tools.
I'll keept this patch around for the few poort soul complaining that they don't
get that's anymore after upgrading to the latest kernel.org source.
Chris Wright announced a Linux Security Modules update for 2.5:
The Linux Security Modules project provides a lightweight, general purpose framework for access control. The LSM interface enables security policies to be developed as loadable kernel modules. See http://lsm.immunix.org for more information.
2.5.30-lsm1 patch released. This is a rebase to 2.5.30 as well as the continuation of merging LSM with mainline.
Full lsm-2.5 patch (LSM + all modules) is available at: http://lsm.immunix.org/patches/2.5/2.5.30/patch-2.5.30-lsm1.gz
The whole ChangeLog for this release is at: http://lsm.immunix.org/patches/2.5/2.5.30/ChangeLog-2.5.30-lsm1
The LSM 2.5 BK tree can be pulled from: bk://lsm.bkbits.net/lsm-2.5
2.5.30-lsm1
- merge with 2.5.27 (Greg KH)
- merge with 2.5.28-30 (me)
- bk file merging to handle changes from mainline (Greg KH)
- removed BUS_ISA declaration (Greg KH)
- add settime hook (Robb Romans)
- SELinux: Bug fixes for the PSID mapping code. (Stephen Smalley)
- update initlialized to C99 sytle for cap and dummy modules. (Adam)
- Fix memory leaks in IPC LSM hooking. (Stephen Smalley)
- Fix file_lock hooks. (Matthew Wilcox)
- update modules according to file_lock hook change (me)
- DTE: logic cleanups (Serge Hallyn)
- SELinux: cleanup sysctl table (Chris Vance)
- __FUNCTION__ cleanup (Anton Blanchard)
- remove __exit attribute from selinux_nf_ip_exit (me)
There was no reply to this, but elsewhere, under the Subject: [ANNOUNCE] 2.4.19-lsm1, he announced an LSM update for 2.4:
2.4.19 lsm patch released. This is includes bugfixes and merging up to the current stable 2.4 Linux tree.
Full lsm-2.4 patch (LSM + all modules) is available at: http://lsm.immunix.org/patches/2.4/2.4.19/patch-2.4.19-lsm1.gz
The whole ChangeLog for this release is at: http://lsm.immunix.org/patches/2.4/2.4.19/ChangeLog-2.4.19-lsm1
The LSM 2.4 stable BK tree can be pulled from: bk://lsm.bkbits.net/lsm-2.4
2.4.19-lsm1
- merge through 2.4.19-rc5 (me)
- merge with 2.4.19 final (James Morris)
- SELinux: Bug fixes for the PSID mapping code. (Stephen Smalley)
- Fix memory leaks in IPC LSM hooking. (Stephen Smalley)
- Fix file_lock hooks. (Matthew Wilcox)
- update modules according to file_lock hook change (me)
- add settime() hook (Robb Romans)
- remove __exit attribute from selinux_nf_ip_exit (me)
There was no reply to that either.
Guillaume Boissiere linked to his August 7 status
page, saying, Getting fancy with colors
this week. I marked all the post-feature freeze items in grey in the list.
If I missed some, let me know.
There was no reply.
Keith Owens announced the
availability of kdb v2.3 for 2.4.18 and 2.4.19, at ftp://oss.sgi.com/projects/kdb/download/v2.3/.
He added, These patches are alpha quality, they
have had limited testing. The usb keyboard code crashes on ia64 for me,
set CONFIG_KDB_USB=n unless you feel like fixing the problem.
There was
no reply.
Petr Vandrovec announced:
I just sent changeset below to the Linus. If you are using my patches for TV-Out from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest, please note that V4L2 support for setting brightness/contrast and other features is NOT part of this patch. I'll send it to Linus after V4L2 interface finds its way into the 2.5 kernel.
And also, as you may guess, driver is not ported to the new fbdev API.
Patch and bkpatch were removed from this copy of message - it is 129KB file. You can download it from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/bkpatch-for-linus-2.5.30, or you can look at http://matroxfb.bkbits.net, or you can pull from bk://matroxfb.bkbits.net/linux-2.5 or ... It applies cleanly to the currently available 2.5 tree.
There was no reply.