Andrew Grover announced:
Now that 2.4.20 is out, I'd like to work with you on getting the ACPI code into 2.4.21-pre as soon as possible. This code has been continually tested by the 500+ people on the acpi-devel mailing list, and has been merged with 2.5.x as improvements have been made.
I feel we have done due diligence to minimize any issues and early inclusion in the prepatch series will give us time to address any that are reported.
You may want to refer to: (sorry for the URL line breakage)
Except for the very earliest changeset, these are all the incremental improvements we have been making over the last year. I count 69 substantive changesets.
the bk url is: http://linux-acpi.bkbits.net/linux-2.4-acpi
Arjan van de Ven objected strongly to this patch, and asked Marcelo
Tosatti not to merge it. He explained, This
patch removes existing, small, working, maintained functionality from the
kernel and "replaces" it with something else for which patches aren't even
accepted and that is a lot bigger and less readable code,
and added,
Not only is it rude on the side of the ACPI
people to remove "competing" functionality, but it will break all kinds of
existing setups that now have to change the way they configure their system. In
addition it's not even needed, the existing code can live together with the
code Andrew proposes just fine as the United Linux kernel proves.
Andrew replied that the new code simply unified the 2.4 ACPI code with
the code that had been in 2.5 for a long time. He asked, Is your concern with the code, or the cmdline option? We could
certainly keep the same cmdline option "acpismp=force" if that is the
issue, but that always seemed like kind of a strange name for the option,
to me.
Alan Cox replied, strange or otherwise
- changing it in 2.4 is a bad idea - keeping it as well as the 2.5 option
is safer. 2.4 should continue to work on upgrades as people expected it
to - conservatism is the key. I think thats why Arjan is arguing as he
does.
And Arjan also replied to Andrew, saying, actually my biggest concern is that you break existing setups,
or at least change it more than needed. There is ZERO need to remove the
existing working (and lean) code, even though your code might also be able
to do the same. It means people suddenly need to change all kinds of config
options, it's different code so will work slightly different... unifying 2.5
is nice and all but there's no need for that here since both implementations
can coexist trivially.
Andrew asked if the best option would be to use the patch from the United Linux kernel, and move incrementally from there to make any other desired changes. But Arjan said no, all that was necessary was to replace the code Andrew's initial ACPI patch removed. There was no need to abandon the entire patch.
At this point there was a bit of back-room maneuvering, and Andrew said:
Well after communicating with Marcelo it sounds like he'd like to hold off taking it in 2.4.21 because IDE changes take priority, and two big changes at once is too many for a stable kernel revision.
Fair enough. I'm just worried that 2.4.22 is a long ways away.
Maybe one way to address Marcelo's stability concerns and Arjan's "keep acpitable.[ch] around" preference is for me to submit a patch that I *know* don't affect anything besides ACPI -- i.e. only the changes that have been made under drivers/acpi, and then go from there, submitting UL-derived and other improvements incrementally after that.
He asked if this seemed like the right approach to folks, and Pavel Machek
replied that yes, Its certainly better than no ACPI
update at all.
However, Hanno Boeck was very disappointed with the
delay. He said, In my opinion, the ACPI-patch is
the most-needed kernel-patch at the moment. For many laptop-users that don't
know about this patch, Linux is nearly unuseable. And I already know at least
two desktop-pcs that don't have any power-management without the acpi-patch.
Andrew, I hope you can find a way to make a patch that the kernel-people
will accept as soon as possible.
Arjan replied that, since 2.4
didn't actually offer suspend/resume capabilities, there didn't seem to be
any pressing need for these patches. But Matthew Wilcox and Alan pointed out
that without them, many systems wouldn't even boot. Marcelo asked which systems
were affected by these problems. Alan said, New compaqs,
existing xmeta, new HP wont boot without the -ac IDE and the workarounds
for ATi or fixes for ALi IDE. (Users should try to avoid the ati igp stuff
for now btw - no X support, no pci routing support, most kernels wont run on
it, no docs).
Matthew also added, hp's
zx1-based ia64 machines (my personal interest..) and i thought some laptops
required updated ACPI to boot. also, aren't there some SMP x86 boxes with
buggy bios tables that won't boot without ACPI?
Jeff Garzik added,
There are several classes of machines that require
ACPI to boot... a big question is whether these machines need full ACPI or
just acpitable.c, too...
Arjan pointed out that at least HP's zx1-based ia-64 machines also required
several other patches in order to boot, but Bjorn Helgaas replied, Apart from ACPI, the non-ia64 patches required to boot a
zx1 should be relatively small: some IRQ changes, support in memmap_init for
discontiguous memory, etc.
And added, Having
a newer ACPI in 2.4.x (it currently has 20011018!) would make things much
easier for ia64.
James Simmons announced:
I have a new patch avaiable. It is against 2.5.50. The patch is at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
Have fun!!!!
Drivers ported are: (Give them a try)
ATI Mach 64
ATI 128
VESA
VGA16
HGA
NIVIDA
NEOMAGICThe BIG changes are:
- The seperation of the console code out of the fbdev drivers.
- Total modularity of the frmaebuffer console system. Yes that is right. You can build it has modules. Great for testing.
The following are results of the new changes which I have tested.
With my VIA laptop with my neomagic card I was able to build it with vgacon and no fbcon. Then I insmod neofb and the soft accel (cfb*.c) needed. It loading and did NOT change the video hardware state. At this point I could run fbdev apps including a X server using /dev/fb solely. On opening /dev/fb0 the graphics hardware state changed. In theory I could exit X and get vgacon back. In order to do this I have to reset the hardware back to vga text mode in the fb_release function. It can be done but I haven't done it yet.
With the second experiment I was able to insmod the fonts and fbcon.o. Then it switched from vgacon to fbcon. In theory I could again call the release function and reset the hardware back to a text mode state. All that is needed is the hardware specific code to do this.
Things to be done:
- A few bugs in fbcon to hammer out.
- Fbcon to support changing resolution via the console layer.
- Move the logo code out of fbcon.c to fbmem.c. With pure fbdev you need something to let you know things worked.
- Software rotation.
Christoph Hellwig asked, Any chance you
could sync with linus again? fb in mainline is pretty rotten.
And
James said, I think the time has come. Alot of
improvmenents have happened :-) The final api for the low level drivers is
done. Any further changes will be in fbmem.c and fbcon. I just synced up
the latest work.
Stephen Rothwell said:
Below is the generic part of the start of the compatibility syscall layer. I think I have made it generic enough that each architecture can define what compatibility means.
To use this,an architecture must create asm/compat.h and provide typedefs for (currently) compat_time_t, compat_suseconds_t, struct compat_timespec.
Hopefully, this is what you had in mind - ohterwise back to the drawing board.
I will follow this posting with the architecture specific patches that I have done but not tested.
There was general applause, and Linus Torvalds also approved, though he had some cosmetic complaints. In the course of an implementation discussion, Linus made the following related remark:
Alpha (and apparently sparc) simply do not save the registers that the signal handling wants on the stack _at_all_. There are too many registers to save at each system call entry point, and 99% of all system calls never need it.
The system call return that checks for signals anyway will end up saving a special stack frame when needed. As will the special signal-related system calls (sigsuspend() and friends). All of this is not only architecture- dependent, it is literally coded in assembly language for the architectures. See "do_switch_stack()" for alpha.
Anyway, if you wondered why Linux beats every other Unix out there on system call overhead, now you know. And yes, this is important.
Shane Helms asked if low-level kernel development had reached its end,
and if Linux would henceforth develop only in the peripheral areas of
optimization, slight enhancements, security, and things of that kind. On
linux-kernel, there was a general tittering of laughter at this, and folks
assured Shane that there was still much to be done. Amidst this reassurance,
Shane argued, if you're implying that we can start
once again from bottom, and come up with something better that unix (which
has been opensource, around for long while, tested and developed by many as
well) I _HIGHLY_ doubt, and disagree. This is unless main kernel developers
*confess* that some incorrect design decisions were made at the start (at a
major section or so), which now they're forced to comply with, and let such
bugs traverse through kernel versions, and there is no way to remove them,
unless start from scratch again.
Joseph D. Wagner replied:
Yes and no.
Unix (and Linux) developers are far too concerned with clinging to the 30-year-old outdated POSIX standard, which creates numerous problems when trying to advance new features. For example, the POSIX standard is the reason we have the three-by-three secure permissions on files (three users: owner, group, everyone; three permissions: read, write, execute) instead of Access Control Lists (ACL's).
Linus Torvalds replied:
No.
Only stupid people think they should throw away old proven concepts. What happens quite often in academia in particular is that you find a problem you want to fix, and you re-design the whole system around your fix.
This is how we get crap like microkernels. They have "an agenda", and that's the _worst_ thing you can have when designing software. You fixate on some perceived problem, and the end result is that yes, maybe you fixed _that_ problem, but in the meantime you also generated a whole new of issues - usually things that were solved by the original approach.
The UNIX/Linux approach is a very pragmatic thing - leave the things that work well alone. There's no point in re-inventing the whole system just because of some small perceived flaws.
Shane asked, since we're not changing much in
kernel core, and developement implies adding additional code and layers for
security, enhancements and support for further hardware and etc. Does this
not slow down the kernel ? or is the execution code still the same ??
And Linus replied:
Oh, some things do get slower. We try to avoid hitting the critical paths, and supporting new hardware for example (which tends to be a large portion of kernel development, even if it isn't as sexy as new features) doesn't impact the rest of the kernel negatively at all.
What we'll probably see in 2.6.x for example, is that many microbenchmarks show slight deprovement (fork() and execve() have become noticeably slower due to the rmap patches), but to at least somewhat offset that we get much nicer worst-case behaviour and better scalability.
And many things _can_ be done without throwing out old designs. Implementation improvements are quite possible without trying to make something totally new to the outside. That's how things like the dcache come about, for example - keeping the standard old boring UNIX filesystem approach, while internally caching it in new ways, improving performance tremendously.
Not throwing out the baby with the bath-water doesn't mean that you cannot improve the system. I'm only arguing against stupid people who think they need a revolution to improve - most real improvements are evolutionary.
James Bottomley proposed:
Currently our only DMA API is highly PCI specific (making any non-pci bus with a DMA controller create fake PCI devices to help it function).
Now that we have the generic device model, it should be equally possible to rephrase the entire API for generic devices instead of pci_devs.
This patch does just that (for x86---although I also have working code for parisc, that's where I actually tested the DMA capability).
The API is substantially the same as the PCI DMA one, with one important exception with regard to consistent memory:
The PCI api has pci_alloc_consistent which allocates only consistent memory and fails the allocation if none is available thus leading to driver writers who might need to function with inconsistent memory to detect this and employ a fallback strategy.
The new DMA API allows a driver to advertise its level of consistent memory compliance to dma_alloc_consistent. There are essentially two levels:
- I only work with consistent memory, fail if I cannot get it, or
- I can work with inconsistent memory, try consistent first but return inconsistent if it's not available.
The idea is that the memory type can be coded into dma_addr_t which the subsequent memory sync operations can use to determine whether wback/invalidate should be a nop or not.
Using this scheme allows me to eliminate all the inconsistent memory fallbacks from my drivers.
Adam J. Richter replied:
I'd really like to see a change like yours integrated soon to stop the spread of fake PCI devices (including the pcidev==NULL convention) and other contortions being used to work around this. Also, such a change would enable consolidation of certain memory allocations and their often buggy error branches from hundred of drivers into a few places.
As you know, I posted a similar patch that created a new field in struct bus_type, as Miles Bader suggested just now, although only for {alloc,free}_consistent. if the bus-specific variation can be confined to some smaller part of these routines or eliminated, then I'm all in favor of skipping the extra indirection and going with your approach. It will be interesting to see if your model allows most of the sbus_ and pci_ DMA mapping routines in sparc to be merged. I suspect that you will have to adopt some kind of convention, such as that device->parent->driver_private will have a common meaning for pci and sbus device on that platform.
Jeff Garzik also offered his support, saying, I'm
glad James is doing this work, it will clean up a lot of assumptions and
corner-case-uglies...
A big pile of developers swarmed around the technical details for awhile,
discussing naming, architecture, and other issues. At one point Russell King
offered some technical objections and remarked that the implementation would
get so ugly, that I'd rather keep our existing pci_*
API than be forced into this crap.
To which James replied:
Let me just clarify: I'm not planning to revoke the pci_* API, or to deviate substantially from it. I'm not even planning to force any arch's to use it if they don't want to. I'm actually thinking of putting something like this in the asm-generic implementations:
dma_*(struct device *dev, ...) { BUG_ON(dev->bus != &pci_bus_type) pci_*(to_pci_device(dev), ..) }The whole point is not to force another massive shift in the way drivers are written, but to provide a generic device based API for those who need it. There are very few drivers that actually have to allocate fake PCI devices today, but this API is aimed squarely at helping them. Drivers that only ever see real PCI devices won't need touching.
Andrew Grover reported:
The ACPI AML interpreter (i.e. code in directories under drivers/acpi, but not source in drivers/acpi directly) has been released by us (Intel) under the GPL. It has also been released separately under a looser license, so that other OS vendors may make use of it.
One consequence of this is that we have not been able to benefit directly from patches from other Linux contributors. The reason is, patches submitted to code only under the GPL must also be GPL, and therefore we cannot take them directly and still make our code available under a license other than the GPL. (We have to determine the problem the patch fixes and then do the fix ourselves.)
This has slowed development and lessened community participation in the development process.
In order to solve this, we are considering releasing the Linux version of the interpreter under a dual license. This would allow direct incorporation of changes. Any patches submitted against the ACPI core code would implicitly be allowed to be used by us in a non-GPL context. This is already done elsewhere in the Linux kernel source by the PCMCIA code, for example.
Christoph Hellwig was fine with this, and suggested, Please use a known license for the second option, i.e. MPL.
Alan Cox was also fine with Andrew's proposal, saying:
I think this is an extremely good idea. I certainly would have no problem contributing cleanup/fixes to the project under those terms. And if I did something large and mega cool with ACPI I can still GPL it only and you can still ignore it 8)
There is a tradition of contributing patches back under the license the project you are contributing to used (and ACPI is certainly big enough to be 'a project' not just a patch)
Suits me fine
Jeff Garzik also approved, saying:
Since pcmcia already set an example with their license, I think it's a great model to follow.
I also echo other comments to choose an already-known license like the MPL or BSD (etc.) so that lawyers don't have extra work ;-)
Greg KH was also fine with Andrew's proposal. Elsewhere, Adrian Bunk replied to Andrew's initial proposal:
two comments regarding the right of an author to freely choose under which license(s) he wants to make his patch available:
If a submitter wants to allow you to use his patch under both licenses he's already able to allow you to do so.
You can't forbid people to send GPL-only patches, so if a person doesn't want his patch under your looser license you can't enforce that he also releases it under your looser license.
Linus Torvalds replied:
That's true, but on the other hand we've had these dual-license things before (PCMCIA has been mentioned, but we've had reiserfs and a number of drivers like aic7xxx too), and I don't think I've _ever_ gotten a patch submission that disallowed the dual license.
In fact, I don't think I'd even merge a patch where the submitter tried to limit dual-license code to a simgle license (it might happen with some non-maintained stuff where the original source of the dual license is gone, but if somebody tried to send me an ACPI patch that said "this is GPL only", then I just wouldn't take it).
I suspect the same "refuse to accept license limiting patches" would be true of most kernel maintainers. At least to me a choice of license by the _original_ author is a hell of a lot more important than the technical legality of then limiting it to just one license.
So yes, dual-license code can become GPL-only, but not in _my_ tree.
Somebody else can go off and make their own GPL-only additions, and quite frankly I would find it so morally offensive to ignore the intent of the original author that I wouldn't take the code even if it was an improvement (and I've found that people who are narrow-minded about licenses are narrow-minded about other things too, so I doubt it _would_ be an improvement).
H. Peter Anvin remarked, This is good.
I'd like to keep klibc under a BSD/GPL license because some people (e.g. Al
Viro) have issued concerns about making a nondynamic user-space library GPL
or LGPL, and I pretty much agree with their concerns. The current klibc
tarball isn't completely "untainted", since it contains "fixed"/modified
kernel headers in a few places, but I'm hoping to migrate those changes back
into the kernel headers proper once the merge is done.
Jeff Dike announced:
This patch updates UML to 2.5.50. As far as UML itself is concerned, this is identical to 2.5.49.
NOTE: I get reproducable filesystem corruption with this version. Offhand, it doesn't look like my fault, so I'm releasing it anyway. I didn't notice any such complaints (or fixes) about 2.5.50 on lkml, but it's possible I wasn't paying enough attention. If there is a fix, apply it first. If not, then run this version on a filesystem that you can afford to have trashed.
The 2.5.50 UML patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.50-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
Nathaniel Russell announced, This patch add's
support for the Via 8633 AGP Card.
He added, it is diffed against Linux Kernel-2.4.20 and most likely applies
to current 2.5.x series kernel.
Nathaniel Russell announced, This patch
adds support for the Via8233 Onboard Sound Card. This patch applies
to Linux Kernel 2.4.20 cleanly. The only file this patch touch's is
drivers/sound/via82cxxx_audio.c. Please apply to current Linux Kernel
2.4.x
But Jeff Garzik replied, unfortunately
this only works sporadically, and only for some motherboards. There is a
reason why I removed this pci id from the driver, after foolishly adding
it :)
In a later post, he suggested, Dave
Jones did a really nice cleanup of agpgart in 2.5, so even though there is
no agpgart MAINTAINERS entry, I think he would be a good target for patches
:) Even thought 2.5 agpgart is clearly different, davej has a clue about
it and could probably ack or apply 2.4 patches...
Marc-Christian Petersen posted an IDE patch for 2.4, and J.A. Magallon
asked, does this mean that Andre's ide is going
into 2.4.21-pre1 ?
Marc-Christian confirmed that this was indeed
the case, with a big, finally!!!!!!!!!
:-))
Alan Cox also confirmed this, and added, though various bits seem to have vanished in the submission (system.h
bits and ide-scsi). Davem has some follow up bits I need to apply (the new
IDE broke some weird 64bit bigendian platform that he supports 8))
Denis Vlasenko posted his most recent list of kernel maintainers, saying:
This document is mailed to lkml regularly and will be modified whenever new victim wishes to be listed in it or someone can no longer devote his time to maintainer work.
If you want your entry added/updated/removed, contact me.
BTW, requests to move your entry to the top of the list without actually changing the text are fine too: that will indicate that entry is not outdated, so don't be shy ;-)
Julie N Fleischer announced:
Release 0.1.0 of the Open POSIX Test Suite is now available at http://posixtest.sourceforge.net. This early release contains only a small amount of the initial testing goals. It contains conformance tests for POSIX Timers, tags TMR and CS (except THR CS). The release notes that appear when downloading the project describe where to find information on compiling and running the test cases.
The README page and the Open POSIX Test Suite website (above) give more information on the project goals and progress as well as information on how to contribute or contact us if you are interested.
The Open POSIX Test Suite is an open source test suite with the goal of performing conformance, functional, and stress testing of the functions described in the IEEE Std 1003.1-2001 System Interfaces specification. Eventual testing of the full specification is desired; however, initial work is focusing on Timers, Message Queues, Threads, Semaphores, and Signals.
Jeff Martin announced:
The Linux Test Project test suite LTP-20021210.tgz has been released. Visit our website (http://ltp.sourceforge.net) to download the latest version of the testsuite, and for information on test results on pre-releases, release candidates & stable releases of the kernel. There is also a list of test cases that are expected to fail, please find the list at (http://ltp.sourceforge.net/expected-errors.php)
The highlights of this release are:
- Many new test from Wipro.
- New SPIE tests ported. Special thanks to Gerrit Huizenga and Narasimha Sharoff for getting us the SPIE tests.
We encourage the community to post results, patches, or new tests on our mailing list, and to use the CVS bug tracking facility to report problems that you might encounter. More details available at our web-site.
Guillaume Boissiere posted his latest 2.5 Status List, saying:
The stabilization work has begun. One item of interest this week is the update to the new framebuffer/console API. Full list is available at http://www.kernelnewbies.org/status/
Also, with more people testing different configurations, the number of bugs in bugzilla has increased quite a big since last week. 80 and counting.
Robert Love announced:
Rik and I are pleased to announce version 2.0.11 of procps, the package that contains ps, top, free, vmstat, etc.
Newer versions of procps are required for 2.5 kernels.
Most notable in this release is a handful of bug fixes, support for /proc/pid/wchan, and an all-new free(1) implementation.
Source tarball and RPM packages are available from:
http://tech9.net/rml/procps/Procps discussion, bugs, and patches are welcome at:
procps-list@redhat.comNEWS for 2.0.11:
- add CPU field to top (Dave Miller)
- ensure top CPU stat spacing is always aligned (Rik van Riel)
- vmstat divide by zero fix (Jens Axboe)
- support pre-decoded wchan from 2.5 in /proc/#/wchan (Robert Love)
- Makefile cleanups (Maciej W. Rozycki)
- removed XConsole from the package (Robert Love)
- removed kill and kill.1 - they are in util-linux (Robert Love)
- provide crucial typo fixes (Chris Rivera)
- all-new implementation of free (Robert Love)
- improved print_uptime and sprint_uptime (Robert Love)
- default install permissions are now 755 (Robert Love)