Kernel Traffic #196 For 16 Dec 2002

There were 385 different contributors. 208 posted more than once. 161 posted last week too.

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)

http://linux-acpi.bkbits.net:8080/linux-2.4-acpi/user=agrover/ChangeSet@-6M? nav=!-|index.html|stats|!+|index.html

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.

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."

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
NEOMAGIC

The 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."

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).

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.

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.

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.

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

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.

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."

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.bz2

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	2 Dec 2002 - 9 Dec 2002	(20 posts)	ACPI Fixes Delayed In 2.4
2.	2 Dec 2002 - 7 Dec 2002	(18 posts)	Framebuffer Updates And Status
3.	3 Dec 2002 - 11 Dec 2002	(78 posts)	Compatibility Syscall Layer
4.	4 Dec 2002 - 9 Dec 2002	(40 posts)	The Future Of Kernel Development
5.	4 Dec 2002 - 7 Dec 2002	(90 posts)	Non-PCI-Specific DMA API
6.	6 Dec 2002 - 9 Dec 2002	(11 posts)	ACPI Licensing Change
7.	6 Dec 2002	(1 post)	User-Mode Linux Updated To 2.5.50
8.	7 Dec 2002	(2 posts)	Support For The Via 8633 AGP Card
9.	7 Dec 2002	(4 posts)	Support For The Via 8233 Onboard Sound Card
10.	7 Dec 2002 - 9 Dec 2002	(5 posts)	New IDE Subsystem Code Going Into 2.4 Tree
11.	9 Dec 2002	(1 post)	Kernel Maintainer List
12.	10 Dec 2002	(1 post)	POSIX Test Suite 0.1.0 Released
13.	10 Dec 2002	(1 post)	Linux Test Project 20021210 Released
14.	10 Dec 2002	(1 post)	New 2.5 Status List Released
15.	11 Dec 2002	(2 posts)	procps 2.0.11 Released

Kernel Traffic #196 For 16 Dec 2002

By Zack Brown