Russell King said:
Ok, here's a major serial update. Items covered in this update:
unuse register_serial/unregister_serial. Instead, please use serial8250_register_port() and serial8250_unregister_port() to talk to the 8250 driver.
The old interfaces have several restrictions:
- do not allow the struct device associated with a port to be known to the tty layer.
- have various restrictions on the size of IO addresses (see the HIGH_BITS_OFFSET stuff - which incidentally 8250_pnp got wrong.)
- provide a mechanism for 8250 platform ports to be dynamically registered. We do this via platform devices - either one or multiple platform devices. You can have none, one, or as many as you desire. 8250.c couldn't care.
- any ports listed in include/asm-*/serial.h will still be intialised in preference to platform device based ports for the time being. It is intended that everyone will move to using the platform device method.
- this means that CONFIG_SERIAL_8250_NR_UARTS slightly changes definition. It is the number of _extra_ ports above those in include/asm-*/serial.h that 8250.h will support. If you have removed all ports from include/asm-*/serial.h, then it is obviously the total number of ports that 8250.c will support, and you need to make sure that it's large enough for your platform.
- ppc64 broke in this merge. That's expected because I backed out benh's changes to the serial drivers. A "get you working again" patch is with benh as of last night pending his attention.
The patch is about 50K, so won't fit through lkml, and is available here instead:
http://www.arm.linux.org.uk/~rmk/misc/linus-serial.diff
People who should test this patch as a minimum:
- ia64 people (ACPI port discovery)
- parisc people (GSC port discovery)
- pnp using people
Once this lot is in, I'll be following up with a set of patches which removes the serial device tables in include/asm-arm/arch-*/serial.h.
Some folks tested it with good success, while others had trouble
applying the patch to Linus Torvalds' current BitKeeper tree. There
were a few patches bandied back-and-forth, and at one point Russell
asked Andrew Morton, do you want this set of
serial changes to appear in one -mm release before hitting Linus?
Andrew replied, Not really - there's plenty
of time to shake out any problems.
And Russell said, Ok, I'll send a pull request imminently. For those
who don't want to wait, latest patch against Linus' tree is at: http://www.arm.linux.org.uk/~rmk/misc/linus-serial.diff
Timothy Miller asked why so much effort was being put into supporting
older GCC compiler versions. He asked, if folks were willing to upgrade their
kernel, wouldn't they also be willing to upgrade their compiler? Matti Aarnio
pointed out that the latest greatest compilers weren't always the greatest on
other architectures. Folks compiling Linux for SPARC and other hardware had
to deal with the fact that some compilers worked better than others. As he
put it, We weird people of other architechtures do
tend to get "somewhat" conservative over the years in finding, and finally
staying with a compiler that we have learned to work. Multiple burned,
forever shy...
Giacomo A. Catenazzi suggested that forcing people
to use the latest compilers would also expose the bugs in those compilers,
so they'd get fixed quicker. Chris Wedgwood countered, the problem is that I probably want to compile a working kernel
*now*, not when the GCC people finally get around to fixing the b0rkedness
they added for my architecture in gcc 3.2.3. So I get to keep 3.2.2 around
until it's fixed. (Feel free to replace 3.2.3 with whatever arch-dependent
value you like).
And Miles Bader added in support of this:
this is particuarly true with fringe architectures.
E.g., you're using a compiler for your CPU that has changes not in mainstream gcc, the vendor who made them is slow in updating to new gcc versions, and their changes are complex enough that you don't want to spend the manpower to port them yourself.
You've got the GPL, so of course it's of course _possible_ to do the work yourself and get a newer gcc working, but sometimes it's really nice to also have the option _not_ to do that...
Elsewhere, Christoph Hellwig boiled the whole problem down
to speed. People wanted to use the older compilers, he said, because the new compilers are a lot slower.
This ended up spawning a sizeable subthread. Adam Heath had to clean out his
ears before retorting, You can't be serious that
this is a problem.
But Martin J. Bligh said, Yes, it is. Mostly they produce larger, slower code too.
And Chris challenged, try it, say gcc 2.95 vs gcc
4.0 ... i think last i checked the older gcc was over twice as fast
.
Adam said he didn't dispute that there was a speed difference; only that it
really mattered. He asked, How often do you compile
your kernel?
This turned out to be the wrong thing to say on a kernel
developer mailing list. As Chris Friesen pointed out, many folks on the list
performed multipler kernel compiles in a day. And Valdis Kletnieks said that
a lot of kernel developers used old hardware that could take several hours to
compile a kernel from source. Adam insisted several times that the solution
was just to purchase better hardware; but this didn't go over so well either.
Several folks offered to accept hardware gifts from Adam, or suggested that
he send hardware to folks who couldn't afford faster systems.
At one point in that subthread, Ioan Ionita did point out that, newer versions of gcc, albeit slower at compiling, do tend
to generate binaries that have faster execution.
Elsewhere but close by, Linus Torvalds also took issue with Adam's assertion that compile time was not a serious issue. Linus said:
First off, for some people that is literally where _most_ of the CPU cycles go.
Second, it's not just that the compilers are slower. Historically, new gcc versions are:
- slower
- generate worse code
- buggier
For a _long_ time, the only reason to upgrade gcc was literally C++ support: basic C support was getting _worse_ with new compilers in pretty much every regard.
Things seem to have improved a bit lately. The gcc-3.x series was basically not worth it for plain C until 3.3 or so.
Adam once more reiterated that people should just get faster hardware
if they wanted faster compile times. Linus replied that not everyone could
get faster hardware, and that there were other values besides speed when
it came to choosing a computer. Even I tend to
prioritize things like "nice and quiet" over absolute speed,
he said.
But he also said, Your "use new versions of
gcc even if it is slower" argument doesn't make any _sense_. If the new
versions aren't any better, why would you want to use them?
Xose
Vazquez Perez replied, Maybe because older
gccs are not maintained.
Adam also replied to Linus, saying he had
no problem with people using older GCC versions if those versions produced
more correct code. His argument, he said, was only that speed of compilation
alone was not a good enough reason to use an older compiler. He said, If people don't bother using newer compilers, complaining
about their inefficiencies, then the issues will never be resolved.
Linus came back at him with:
The only thing that matters is "what is the best tool". And yes, performance _is_ an issue in selecting the best tool. It's not the only one, but it's a major one.
You said so yourself when you claimed people should just buy faster hardware. Again, the machine you use is just another tool. Why should you buy a faster machine if performance doesn't matter?
I don't understand why you first dismiss performance, and then go on to ignore all the _other_ issues I told you about too.
And your argument about "things will get fixed if you use the newer version" is also not actually true. First off, if it ain't broke in the older version, then things _literally_ will get fixed by not upgrading in the first place.
And telling a developer "I'm not using your new version because it sucks compared to the old one" is actually a perfectly valid thing to do, and is likely to be _more_ motivational for the developer to get it fixed than having users that just follow the newest version like stupid sheep.
There are people out there using Linux-2.0. There are probably people even using linux-1.2. And hey, that's OK. For older machines it may really be the right choice, especially if they are still doing the same thing they did several years ago. The notion that you somehow "have to" upgrade to the newest version of software is BOGUS.
Andrew Morton announced Linux 2.6.10-rc1-mm3, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/
- Added Andi's 4-level-pagetable patches. It's tested on x86, x86_64, ia64 and ppc64. These are fairly intrusive patches and I'll probably push them upstream soon.
- UML updates, ppc64 updates.
- Should fix a few bugs which people reported in 2.6.10-rc1-mm2.
A bunch of folks posted their various oopses, compilation problems, and various other bug reports as usual, which were promptly pounced upon by many developers, and fixes found.
Andries Brouwer noticed that a recent 2.6.9 bug fix had exposed a deeper problem with the PC110 mouse driver. A test performed by that driver had been broken up until 2.6.9, and so it had just failed to gain access to a region of memory or reserve its IRQ. With the test fixed, the mouse got the IRQ and the RAM, but the Ethernet card got a conflict, so networking wouldn't work. The mouse in turn, with its new RAM and IRQ powers, tried to do I/O but got errors and broke down. So the 2.6.9 bug fix ended up breaking both Andries' networking and mouse operations.
The quick remedy, he said, was to give 'CONFIG_MOUSE_PC110PAD=n' in the kernel config file, disabling the driver entirely; but he thought a better solution would be to detect the conflict at driver load time, and refuse to load the mouse driver if there would be any conflict. He couldn't see a way to detect the hardware, so he'd asked on the linux-kernel list in hopes that someone else knew how.
Linus Torvalds suggested perhaps making this driver link into the kernel
late in the game, giving other drivers the chance to claim the resources
first and avoid a serious conflict. But he said he had no idea how to probe
for the hardware himself. He asked Alan Cox if Alan knew of a way to detect
it. But Alan replied, I have some register info,
the driver is done by disassembly of the PC-DOS driver IBM shipped with the
PC110. It's a pre pci, pre dmi machine so there aren't any obvious sane ways
to probe. Its not something you'd want to build in as opposed to modular on
any other system but the PC110.
Linus replied:
Well, that actually _is_ something we can probe for: "does this machine have PCI".
IOW, we could have a trivial "if the list of PCI devices is non-empty, then return immediately" kind of thing, no?
That would mean that (pretty much) anybody loading that driver by mistake wouldn't get into trouble.
This sounded good to Alan, and Linus posted a short patch to do it, with a comment in the source code, "We try to avoid enabling the hardware if it's not there, but we don't know how to test. But we do know that the PC110 is not a PCI system. So if we find any PCI devices in the machine, we don't have a PC110.". Andries and Alan both confirmed that this solved the problem on their systems.
Adrian Bunk noticed that the drivers/char/rocket.c file listed two conflicting licenses. The first, at the top of the file, was the GPL. The second one read:
The following source code is subject to Comtrol Corporation's Developer's License Agreement.
This source code is protected by United States copyright law and international copyright treaties.
This source code may only be used to develop software products that will operate with Comtrol brand hardware.
You may not reproduce nor distribute this source code in its original form but must produce a derivative work which includes portions of this source code only.
The portions of this source code which you use in your derivative work must bear Comtrol's copyright notice:
Copyright 1994 Comtrol Corporation.
Adrian felt that the third paragraph of this license conflicted with the GPL, since it required that the code only be used to develop software for a particular brand of hardware. Adrian asked Theodore Ts'o to clarify the license, and Theodore replied:
I developed the Rocketport device driver under contract of Comtrol, with the understanding that the resulting device driver would be released under the GPL. So I believe the correct way of resolving the conflicting copyright statements is to delete the following lines.
It would be good to get positive confirmation from Comtrol as well that this is their understanding as well. Otherwise, we will need to remove the Rocketport driver from the mainline Linux kernel.
He got this confirmation from Jason Jorgensen of Comtrol, and posted a patch removing Comtrol's copyright notice from the code.
Marcelo Tosatti announced Linux 2.4.28-rc2, saying:
It contains a network update (which is composed of several smaller changes - IPVS, SCTP, Netfilter), a collection of ACPI bugfixes, a SMBFS client buffer overflow fix (which is very hard to exploit - the attacker needs to control packets from the server), amongst others.
This is going to be become 2.4.28 if nothing bad shows up.
Geert Uytterhoeven requested a BitKeeper feature, asking, Would it be possible to enable the `-p' option (Show which C
function each change is in) of diff for all patches sent to the bk-commits-*
mailing lists?
Larry McVoy replied:
This has been fixed in the following releases:
bk-3.2.3
bk-3.2.2c
bk-3.2.2bCorrect usage is "bk diffs -up" which will get you unified + procedural diffs. -p is currently a hack, it implies -u, but don't depend on that behaviour, a future release does this correctly and if you teach your fingers that diffs -p is the same as diffs -up you'll get burned later.
Jens Axboe said, Thanks! I requested this about
a year ago :-)
Jack O'Quin said:
The realtime-lsm Linux Security Module, written by Torben Hohn and Jack O'Quin with significant help from Chris Wright and Jody McIntyre, selectively grants realtime capabilities to specific user groups or applications. One typical use is low latency audio, and the patch has been extensively field tested by Linux audio users.
We developed this LSM in response to a serious need. Audio developers have been struggling for years with having to apply specialized kernel patches to get reliable realtime operation. Audio is very intolerant of scheduling glitches. They cause nasty pops in the output. Also, large audio applications should not run as `root'. The 2.4 "capabilities patch" was never a satisfactory solution for this problem, but it was the best we could do at the time.
Now, thanks to the good work being done on 2.6, we are now close to being able to do serious realtime work with standard kernels available everywhere. The LSM framework is an important element of that solution with the realtime LSM a small but essential component, because it makes these features available without excessive administrative burden. Many musicians have a Mac or Windows background, systems which grant realtime privileges to all tasks indiscriminantly. The realtime LSM allows us to grant similar privileges while maintaining better control over who gets them.
This version was originally applied against linux-2.6.10-rc1-mm2, and retested with linux-2.6.10-rc1-mm4.
Paul Mackerras announced, The linuxppc
mailing lists that were at lists.linuxppc.org have moved to ozlabs.org.
This patch updates the MAINTAINERS file to reflect that.