Kernel Traffic #287 For 1 Jan 2005

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Czech Translation
  * Mailing List Stats For This Week
  * Threads Covered

    1.  9 Nov 2004 - 23 Nov 2004  (44     Linux 2.6.10-rc1-mm4 Released
                                  posts)
    2.  11 Nov 2004 - 24 Nov 2004 (57     Out-Of-Memory Killer: Hunting For The
                                  posts)  Proper Layer
    3.  14 Nov 2004 - 24 Nov 2004 (87     Linux 2.6.10-rc2 Released
                                  posts)
    4.  16 Nov 2004 - 22 Nov 2004 (23     Linux 2.6.10-rc2-mm1 Released
                                  posts)
    5.  16 Nov 2004 - 24 Nov 2004 (18     Linux 2.4.28 Released
                                  posts)
    6.  17 Nov 2004 - 18 Nov 2004 (9      Status Of OSS Deprecation
                                  posts)
    7.  17 Nov 2004 - 18 Nov 2004 (9      Xen 2.0 Updates
                                  posts)
    8.  18 Nov 2004 - 21 Nov 2004 (30     Linux 2.6.10-rc2-mm2 Released
                                  posts)
    9.  18 Nov 2004 - 19 Nov 2004 (6      Kprobes Wrapper To Define
                                  posts)  jprobe.entry
    10. 18 Nov 2004               (1      LKST 2.2.0 For Linux 2.6.9 Released
                                  post)
    11. 18 Nov 2004 - 19 Nov 2004 (4      Linux 2.6.9-ac10 Released
                                  posts)
    12. 18 Nov 2004 - 19 Nov 2004 (6      Intel Thermal Monitor For x86_64
                                  posts)  Updated
    13. 18 Nov 2004               (2      Possible GPL Violation By Silicon
                                  posts)  Laboratories
    14. 18 Nov 2004 - 19 Nov 2004 (5      New Smaller /sbin/hotplug Tool
                                  posts)
    15. 18 Nov 2004 - 19 Nov 2004 (6      Documenting ioctls
                                  posts)
    16. 19 Nov 2004 - 20 Nov 2004 (5      Maintainership Of Orphaned Code
                                  posts)
    17. 20 Nov 2004 - 23 Nov 2004 (17     Some Discussion Of Compiler
                                  posts)  Extensions
    18. 24 Nov 2004               (1      kernel.org Hardware Troubles
                                  post)

Mailing List Stats For This Week

We looked at 2099 posts in 12934K.

There were 438 different contributors. 260 posted more than once. 162 posted
last week too.

The top posters of the week were:

  * 89 posts in 755K by Adrian Bunk
  * 82 posts in 476K by Andrew Morton
  * 63 posts in 281K by Greg KH
  * 54 posts in 974K by Roland Dreier
  * 50 posts in 280K by Linus Torvalds
  * Full Stats

1. Linux 2.6.10-rc1-mm4 Released

9 Nov 2004 - 23 Nov 2004 (44 posts) Archive Link: "2.6.10-rc1-mm4"

Topics: Framebuffer, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.10-rc1-mm4, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/
2.6.10-rc1-mm4/

  * The 4-level-pagetable code is hopefully finalised.
  * Various architecture updates.
  * Added the new FRV architecture.
  * v4l updates, fbdev updates.
  * A process matter: I'm now tracking any regressions since 2.6.9, with the
    intention that we not release 2.6.10 until they're all fixed. (Where
    "tracking" means shoving them into a folder called "bugs"). So if anyone is
    aware of any post-2.6.9 regressions, please make sure that I have a copy of
    the email.

    I'm less interested in bugs which existed prior to 2.6.9, as they're
    presumably minor and as long as we don't actually introduce regressions
    then we'll make decent progress across kernel releases.

2. Out-Of-Memory Killer: Hunting For The Proper Layer

11 Nov 2004 - 24 Nov 2004 (57 posts) Archive Link: "[PATCH] fix spurious OOM
kills"

Topics: Big Memory Support, OOM Killer

People: Marcelo Tosatti, Andrea Arcangeli, Andrew Morton

Marcelo Tosatti said:

This is an improved version of OOM-kill-from-kswapd patch.

I believe triggering the OOM killer from task reclaim context is broken because
the chances that it happens increases as the amount of tasks inside reclaim
increases - and that approach ignores efforts being done by kswapd, who is the
main entity responsible for freeing pages.

There have been a few problems pointed out by others (Andrea, Nick) on the last
patch - this one solves them.

First, Andrea noted that if progress had been made in the high zone, the OOM
killer would not be triggered. Now it conditions the triggering on "DMA+Normal"
reclaiming success.

Nick noted that the last patch would do wrong on the NUMA case (because of
per-node kswapd) - its not a problem now because we will only kill if there is
any task not being able to allocate and free pages. The memory allocation
fallback to other nodes will prevent that from happening.

Another drawback from the last patch was that it disable the
"all_unreclaimable" logic which attempts to avoid scanning storms - that way
kswapd was able to detect OOM condition.

What it does now is to disable the all_unreclaimable logic after 5 seconds that
its been set. This is enough time for the system to complete IO of (at least
some) pages which have been written-out for reclaiming purposes.

After that period (which can be sysctl'ed BTW), it then performs a full scan.
In case no progress has been made, and both DMA and normal zones are below the
pages_min watermark, the OOM killer is triggered.

It looks very reliable in my testing - but I need others to test it as well
(Martin and Thomas especially who have good test cases).

Andrea Arcangeli felt it was wrong to have kswapd kill anything. He said,
"kswapd is an async helper like pdflush and it has no knowledge on the caller
(it cannot know if the caller is ok with the memory currently available in the
freelists, before triggering the oom)." He went on to say that his own plan was
to move the OOM killing code out of vmscan.c, which he said could not know
which task was proper to kill, and into page_alloc.c, which could. He said,
"vmscan.c can only know if something is still freeable, but if something isn't
freeable it doesn't mean that we've to kill anything (for example if a task
exited or some dma or normal-zone or highmem memory was released by another
task while we were paging waiting for I/O). Every allocation is different and
page_alloc.c is the only one who knows what has to be done for every single
allocation."

Marcelo replied he had asked Andrea three times already whether Andrea had an
idea of how exactly the proper method would work, and received no concrete
answer each time. Andrea replied that his idea of moving the OOM killer into
page_alloc.c was his proper method, but that he wouldn't have time to work on
it for at least a week. Marcelo wished him luck. Apparently this means Andrea
will get to complete his work before Marcelo decides on any final solution for
2.4. Elsewhere, Chris Ross tested Marcelo's original patch, but found that it
would go haywire under certain circumstances.

Andrea said he'd get his patch out as soon as possible, but that in the mean
time debugging Marcelo's patch would also help clarify other problems in that
area of the kernel. The discussion continued, with Andrew Morton and others
joining in; Andrea did not post his improvement during that discussion,
however.

3. Linux 2.6.10-rc2 Released

14 Nov 2004 - 24 Nov 2004 (87 posts) Archive Link: "Linux 2.6.10-rc2"

Topics: Disks: IDE, FS: NTFS, Framebuffer, I2C, Kernel Release Announcement,
PCI, Sound: ALSA, USB

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.10-rc2, saying:

Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should now
calm down, so I do not want to see anything but bug-fixes until 2.6.10 is
released. Otherwise we'll never get there.

A lot of driver updates, many of them of the small and trivial kind, others
less so. USB, ALSA, fbdev, IDE, i2c, v4l, you name it. With a sprinking of core
device model and PCI updates thrown in for good measure.

Also, a number of architecture updates: ppc64, m68k, uml, parisc, arm.

And md, NTFS, and Documentation updates too.

The diffstat shows more of the story - not so much single really big changes,
more of a fairly wideranging thing.

4. Linux 2.6.10-rc2-mm1 Released

16 Nov 2004 - 22 Nov 2004 (23 posts) Archive Link: "2.6.10-rc2-mm1"

Topics: Kernel Release Announcement

People: Andrew Morton, Dave Airlie, Lee Revell

Andrew Morton announced Linux 2.6.10-rc2-mm1, with various fixes, but nothing
major. Lee Revell noticed that VIA DRM had existed in 2.6.9-mm1, but was now
gone. He asked why, and Andrew replied, "Actually I haven't been updating that
for a while, because of ghastly conflicts upstream. Then it disappeared
altogether due to administrative error. I'll see if I can resurrect it." Dave
Airlie also explained, "I asked Andrew to kill it, I wasn't happy with it
security wise still, resurrecting it could be messy as the tree isn't converted
over to the core/library split, I'll probably pick it back up once Linus merges
the current diffs after 2.6.10 is released... VIA DRM still only is useful for
2D HwMC stuff for non-root users, having to make a user run 3d apps as root is
probably worse than having an in-secure DRM, so I'm still waiting for the VIA/
unichrome people to see what they can do with it..." Lee replied, "FWIW almost
no one uses the DRM for 3D on this card. Many people do use the 2D HwMC stuff
though." And Dave said, "I might merge up a DRM with the 3D part disabled, so
the 2D stuff works after 2.6.10 comes out, Alan wanted me to merge up all the
outstanding drms that have security issues and disable them for non-root but
someone pointed out the issues with making people run untrusted things as root
to be able to use them at all..."

5. Linux 2.4.28 Released

16 Nov 2004 - 24 Nov 2004 (18 posts) Archive Link: "Linux 2.4.28-rc4"

Topics: Power Management: ACPI

People: Marcelo Tosatti, Chris Wright, Barry K. Nathan, Ozkan Sezer

Marcelo Tosatti announced Linux 2.4.28-rc4, saying:

Here goes the fourth release candidate of 2.4.28.

A few small problems showed up in time for another -rc.

Missing exported symbols in the networking area, an ACPI poweroff bugfix,
aic7xxx compile fix with -Werror, a binfmt_elf underflow enhancement, an SCTP
fix, and a couple TG3 fixes.

This will become v2.4.28 final if nothing _really_ bad shows up.

Thanks to everybody who has been contributing to make this happen.

Ozkan Sezer pointed out some security fixes that had been recently posted; but
Barry K. Nathan said he'd discussed them with Marcelo, and it was too late to
include these in 2.4.28; Marcelo confirmed this, saying the patches would make
it into 2.4.29-preX. Massimo Cetra asked why this decision had been made, if
the security holes could be exploited. It seemed to him the most important
thing was to close the holes before releasing 2.4.28 if possible. But Chris
Wright pointed out that 2.4.28 had already been published by that time (Marcelo
announced it as unchanged from -rc4); and Barry K. Nathan remarked that as far
as he'd been able to determine, at the worst, an exploit would crash the
program attempting to perpetrate the exploit - not such a terrible calamity.

6. Status Of OSS Deprecation

17 Nov 2004 - 18 Nov 2004 (9 posts) Archive Link: "[patch 2.6.10-rc2] oss: AC97
quirk facility"

Topics: Sound: ALSA, Sound: OSS, Sound: i810, Version Control

People: John W. Linville, Jeff Garzik, Jan Engelhardt, Lee Revell, Alan Cox, 
Andrew Morton

John W. Linville posted an OSS audio fix, "stolen shamelessly from ALSA" .
Andrew Morton asked why not just use ALSA instead of OSS, and Jeff Garzik
replied, "Until we actually remove the OSS drivers, it's sorta silly to leave
them broken." Jan Engelhardt replied, "It's just as silly to fix something
we're removing anyway." Alan Cox pointed out that a lot of folks still used
OSS, and Jeff added, "Until it's gone, the current users would prefer
not-broken to broken." Jan said it would be better to leave it broken, as an
incentive to switch to ALSA; but Jeff said, "i810 audio still locks up in ALSA
ATM..." At this point Lee Revell remarked, "Fixed in ALSA CVS on Tuesday. This
fix needs to go in 2.6.10."

7. Xen 2.0 Updates

17 Nov 2004 - 18 Nov 2004 (9 posts) Archive Link: "Xen 2.0 VMM patches"

Topics: BSD: FreeBSD, BSD: NetBSD

People: Ian Pratt, Andi Kleen

Ian Pratt said:

The Xen team would like to start submitting upstream the patches required to
enable Linux to run over the Xen 2.0 Virtual Machine Monitor. For more
information about Xen see: http://xen.sf.net

There are three main classes of patch required:

core :        small patches that provide extra hooks for arch-xen
arch-xen :    large patch to add arch/xen and include/asm-xen
xen-drivers : patch to add virtual block, network and console drivers

We're proposing to submit the 'core' patches first, as these probably require
closest inspection (the others are all new files in new directories, so can't
break existing architectures).

There is already a significant user base and lively developer community backing
the Xen project, so we're confident we will have the resources to maintain
arch-xen on Linux 2.6 going forward (as well as Linux 2.4/NetBSD/FreeBSD/etc).

Let us know what you think of the patches ;-)

Andi Kleen thought it didn't seem quite necessary to have a whole Xen port,
paralleling the i386 tree. But Ian said:

We've experimented with doing thing the other way round, having xen a sub
architecture of i386, but it was _really_ messy.

I firmly believe that having a separate arch/xen is the best approach for the
moment. In the future, it might make sense to merge arch xen into i386, but to
do this cleanly would require significant restructuring of i386. I think that's
something we could move toward after everyone's gotten comfortable with having
arch xen in the tree.

The fact that arch xen is self contained actually makes it easier for us to
maintain in some respects. We've been tracking 2.6 releases for some time
without too much difficulty.

Andi replied:

2.6 has been relatively easy for now (because it was supposed to be a "stable
kernel"), but I suspect it'll get worse again over time. e.g. in 2.5 it was
really bad for long times. Essentially you will need to commit significant man
power to this.

Also it's quite hard to always catch all the changes that get done to i386.

Overall I think it's a bad idea to have four different x86 like architectures
in the tree. Especially since there will be likely more hypervisors over time.
i386 and x86-64 make some sense because 64bit is a natural boundary, but
extending it elsewhere doesn't scale very well.

Ian said, "Over time, I hope we can merge the i386 xen port in with the native
architecture, but its going to require significant restructuring of the native
architecture to do it cleanly. In the meantime, I think we just have to bite
the bullet and maintain a separate architecture. I believe we have resources to
do this."

8. Linux 2.6.10-rc2-mm2 Released

18 Nov 2004 - 21 Nov 2004 (30 posts) Archive Link: "2.6.10-rc2-mm2"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux version 2.6.10-rc2-mm2, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/
2.6.10-rc2-mm2/

  * Lots of small bugfixes. Some against patches in -mm, some against Linus's
    tree.
  * There's a patch here which should address the oom-killings which a few
    people have reported.

9. Kprobes Wrapper To Define jprobe.entry

18 Nov 2004 - 19 Nov 2004 (6 posts) Archive Link: "[PATCH] Kprobes: wrapper to
define jprobe.entry"

Topics: Executable File Format

People: Ananth N. Mavinakayanahalli, Andrew Morton, David S. Miller

Ananth N. Mavinakayanahalli said:

Here is a patch that adds a wrapper for defining jprobe.entry to make it easy
to handle the three dword function descriptors defined by the PowerPC ELF ABI.

Current patch against 2.6.10-rc2-mm1 + kprobes patch for ppc64.

Changes for adding this wrapper for x86, ppc64 (tested) and x86_64 (untested)
below. The earlier method of defining jprobe.entry will continue to work.

He posted some pseudocode to use jprobes with this patch, adding, "I am not
aware of the semantics for sparc64 for making this change."

Andrew Morton said he hadn't seen the kprobes patch for ppc64 yet, and said,
"what should I do with this? I'm inclined to drop it until the x86_64 part has
been tested and Dave has had a go at the sparc64 version." David S. Miller
remarked, "Yes, now that we have kprobe support on 4 platforms, it is important
that anyone who changes public parts of this interface do the necessary
per-platform fixups necessary to coincide with such changes. I think the person
changing the data type should be the one fixing up sparc64 :-)" Ananth also
replied to Andrew, saying, "I have now tested the patch succesfully on x86_64
and updated it for sparc64 too (Dave says the change looks good)." Andrew asked
how much review and testing Ananth's kprobes-for-ppc64 patch had received so
far, and Ananth replied, "The patch was earlier posted on the PPC64 mailing
list for comments and Paul had reviewed it. I had to update the patch to take
care of the base kprobe changes that were made to accomodate the x86_64 port.
The patch is tested on POWER3 (uni) and POWER4 (lpar)."

10. LKST 2.2.0 For Linux 2.6.9 Released

18 Nov 2004 (1 post) Archive Link: "[ANNOUNCE/LKST] LKST 2.2.0 for linux-2.6.9
is released."

People: Masami Hiramatsu

Masami Hiramatsu said:

We are pleased to announce releasing new version of Linux Kernel State Tracer.

The Linux Kernel State Tracer(a.k.a. LKST) version 2.2.0 has been released.
This version can be applied to linux-2.6.9. And LKST 2.2.0 supports IA32, IA64
and x86-64 platforms.

LKST is a tool that supports to analyze of fault and evaluate for kernel.
Especially it is usuful for analyzing the unanticipated fault of kernal.

The latest version of the LKST newly supports the x86-64 architecture.

For more changes, see Changelog-2.2.0.txt
<http://prdownloads.sourceforge.net/lkst/Changelog-2.2.0.txt?download:gt;

Remarks:
For supporting IA64 and x86-64, we hacked KernelHooks.

LKST binaries, source code and documents are available in the following site,
https://sourceforge.net/projects/lkst/
http://sourceforge.jp/projects/lkst/

We prepared a mailing list written below in order to let users know update of
LKST.

lkst-users@lists.sourceforge.net
lkst-users@lists.sourceforge.jp

To subscribe, please refer following URL,

http://lists.sourceforge.net/lists/listinfo/lkst-users
http://lists.sourceforge.jp/mailman/listinfo/lkst-users

And if you have any comments, please send to the above list, or to another
mailing-list written below.

lkst-develop@lists.sourceforge.net
lkst-develop@lists.sourceforge.jp

11. Linux 2.6.9-ac10 Released

18 Nov 2004 - 19 Nov 2004 (4 posts) Archive Link: "Linux 2.6.9-ac10"

Topics: FS: smbfs, Forward Port

People: Alan Cox, Arjan van de Ven

Alan Cox, having resumed his fork of the kernel source, announced Linux
2.6.9-ac10, saying:

More merges and forward ports. These include the extra binfmt_elf checks and
the SMBfs overflow fixes that match those in 2.4.28. It also includes several
patches Dave Miller believes should be backported from the networking code.
Also fixed is a long standing problem where ide would claim some devices it
couldn't actually use and didn't install drivers for.

Arjan van de Ven is now building RPMS of the kernel and those can be found in
the RPM subdirectory and should be yum-able. Expect the RPMS to lag the diff a
little as the RPM builds and tests do take time.

The it8212 still doesn't default to DMA on - that is on the TODO list. The
HPT366 rework project is also not ready (its gone back to the drawing board for
a few days if you are a volunteer and wondered what is up).

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/linux-2.6/2.6.9/

12. Intel Thermal Monitor For x86_64 Updated

18 Nov 2004 - 19 Nov 2004 (6 posts) Archive Link: "[PATCH] Intel thermal
monitor for x86_64 (updated)"

Topics: Version Control

People: Zwane Mwaikambo, Andi Kleen

Zwane Mwaikambo said:

This updated patch adds support for notification of overheating conditions on
intel x86_64 processors and incorporates suggestions from Andi. Tested on EM64T
and test booted on AMD64.

Hardware courtesy of Intel Corporation

Andrew please backout the current patch and apply this one (verified it applies
against -bk), if you'd prefer an incremental let me know.

After some back-and-forth with Andi Kleen, Zwane posted a new patch, but with
no additional description of what had changed.

13. Possible GPL Violation By Silicon Laboratories

18 Nov 2004 (2 posts) Archive Link: "Linux support for SiLabs CP2102 devices"

Topics: USB

People: Greg KH

Greg KH said:

I've been getting a lot of requests lately to see if Linux supports the USB to
serial device from Silicon Laboratories called the CP2102 chip. It turns out
that the company is claiming Linux support, yet they are only shipping a binary
driver for Red Hat Linux 9.0.

In talking with the company, they insist that they will not release the source
code to this module, and they claim that they are not infringing on any rights
by not doing so. I claim that this is not true, as to write a usb to serial
driver for Linux you have to use the drivers/usb/serial/usb-serial.h header
file which is specifically licensed under the GPL v2. This file contains inline
functions and structures that all usb-serial drivers need to use in order to
work properly.

In short, there's no way you can write a Linux usb-serial driver, that uses the
usbserial interface, without it being a derived work of other, GPL only code.

So, they are in violation, so what. Well, I can't do much about this (due to my
employer's rules about suing companies). But I can do my best to spread the
word that the CP2102 device is not supported on Linux, and should be avoided at
all costs by anyone considering such a device in a future design. I encourage
everyone else to help spread this information too.

If people are looking for a good usb to serial chip that is supported on Linux,
Windows, and OS-X, there's the PL2303 device from Prolific, and the FTDI-SIO
chip, and the MCT-U232 chip. All of these work very well on Linux, and are
fully supported by all distros. I think they even might be cheaper than the
CP2102 device too :)

Oh, and just for fun, attached to this message is the Linux driver that SiLabs
is distributing, if anyone wants to poke around in it. The tarball contains 2
binary drivers, one of them a version of the usbserial.c file (which plainly is
licensed under the GPL) and a mcci_usb.o binary driver. Have fun with it, but
don't blame me for any badness that might happen to your box for running it, no
one has any way of knowing exactly what this driver is doing.

So, in conclusion, please stay away from Silicon Laboratories devices, if you
want to run Linux, as they are obviously not supporting Linux in any way.

There was no discussion of this, aside from Bill Marr thanking Greg for
pointing out the violation.

14. New Smaller /sbin/hotplug Tool

18 Nov 2004 - 19 Nov 2004 (5 posts) Archive Link: "[ANNOUNCE] a very tiny /sbin
/hotplug"

Topics: Hot-Plugging, Klibc, Small Systems

People: Greg KH, Eugene Surovegin, Robert Schwebel, Chris Larson

Greg KH said:

a number of people have complained over the past few years about the fact that
/sbin/hotplug was a shell script. Funny enough, it's the people on the huge
boxes, with huge number of devices that are complaining, not the embedded
people with limited resources (ironic, isn't it...)

Anyway, attached below is a replacement /sbin/hotplug written in c. Compiling
it with klibc gives you me the following size:

$ size hotplug
   text    data     bss     dec     hex filename
   4149      28      20    4197    1065 hotplug
$ ls -l hotplug
-rwxr-xr-x  1 greg users 4636 Nov 18 15:08 hotplug

Which is smaller than /bin/true on my boxes (and /bin/true is linked
dynamically, this is a static binary. Linked dynamically, it's still smaller
than /bin/true. gnu programs, go figure...)

I'll be putting this all togther in a "hotplug-ng" type tarball, as I slowly
replace the existing hotplug scripts with rewrites based on the fact that we've
learned things over the past 4 years, and dropping support for 2.4 and previous
kernels. But for now, have fun with this program.

Oh, and yeah, I know I need to fix up the fact that if /dev/null isn't present,
we should create it ourselves and go from there. That's next on the list after
putting it all in a project.

Remarking on why the complaints had come from big box users rather than
embedded systems folks, Eugene Surovegin said, "This is probably because
embedded people don't use hotplug at all :). On dozen different PPC and MIPS
boxes I worked on, we never needed this feature." Robert Schwebel disagreed,
saying, "PTXdist has hotplug support for some time." And Chris Larson also
pointed out, "I tend to focus on ARM, and find this very useful. I know of a
number of folks using erik andersen's "diethotplug" (which hasnt been touched
in some time). I look forward to your further hotplug improvements." Greg
replied:

Yes, diethotplug is based on my old package called, supprise, diethotplug, and
is located at

http://www.kernel.org/pub/linux/utils/kernel/hotplug/

But that only does module loading. The "full" replacement of today's /sbin/
hotplug functionality needs this hotplug multiplexer, and a diethotplug
replacement (which can get much smaller than the current diethotplug due to the
way modprobe works in 2.6.)

15. Documenting ioctls

18 Nov 2004 - 19 Nov 2004 (6 posts) Archive Link: "IDE ioctl documentation & a
new ioctl"

Topics: Disks: IDE, Ioctls

People: Edward Falk, Jim Nelson

Edward Falk said:

Hi all; let me introduce myself: I'm the guy that does IDE sustaining for
Google.

I'm getting ready to sit down and document the IDE ioctls. Probably
Documentation/hdio.txt or something like that. Before I start though, is
anybody already doing this?

Jim Nelson said he didn't think anyone else was working on ioctl documentation.
He said:

I had a thought in the back of my head of tackling ioctl documentation after I
went through the stuff that's already in Documentation, but I figured I had
enough to chew on for right now.

I'd probably make a subdirectory - i. e. Documentation/ioctl/hdio.txt - to
differentiate it from other documents, and make it easier to get maintainers to
put some stuff in there. ;) AFAICT, there is next to no documentation on
ioctl's anywhere in the kernel tarball.

Edward liked the idea of an ioctl directory, as it would encourage folks to add
to it.

16. Maintainership Of Orphaned Code

19 Nov 2004 - 20 Nov 2004 (5 posts) Archive Link: "[2.6 patch] remove obsolete
Computone MAINTAINERS entry (fwd)"

Topics: MAINTAINERS File

People: Adrian Bunk, Jim Nelson, Michael H. Warfield, Andrew Morton

Adrian Bunk said, "I'm not sure whether it makes sense to list the previous
maintainers for orphaned code, but if such entries contain buouncing mail
addresses it's IMHO time to simply remove them." He posted a patch to remove
Michael H. Warfield as the maintainer of the orphaned Computone Intelliport
Multiport card. Andrew Morton said that the address listed in that Maintainer
entry was still valid. Adrian replied that the mailing list was clearly
defunct. Jim Nelson said:

If someone is willing to step up to the plate and get the driver working again,
it would be better to have the contact information for the old maintainer
available in a centralized location. Plus, anyone who tries the driver and
finds it busted can look in the MAINTAINERS file and find out that it's not
being fixed, instead of it being one of those drivers that has no defined
maintainer (I've run across a few).

After all, we do have to be honest about unmaintained drivers - rather than
hiding broken code. Honestly, it's better to define who's responsible for an
area of code, even if it no longer works.

Adrian pointed out that the contact information was still available in the
driver documentation; and that:

MAINTAINERS does not cover all drivers. It's not about being honest or about
hiding broken code, but adding let's say fifty entries for no longer supported
drivers isn't of any practical value.

At least I'm checking MAINTAINERS for people who want to receive the patches I
send today, not for people who have worked on the driver at some time in the
past. Adding information about orphaned drivers to this file simply makes it
harder to find whether valid entries covering the driver in question exist.

If someone steps up and wants to generate and maintain a driver status document
that would be fine with me. But this would require a serious amount of work and
is more than just adding a few orphaned drivers to MAINTAINERS.

17. Some Discussion Of Compiler Extensions

20 Nov 2004 - 23 Nov 2004 (17 posts) Archive Link: "sparse segfaults"

People: Linus Torvalds, Jan Engelhardt, Mitchell Blank Jr, Russell King

In the course of discussion, Russell King pointed out that the "int tickadj =
500/HZ ? : 1" C construction was pretty strange in kernel/ptrace.c. As someone
else said, the 'true' part of the conditional was empty, and the C standard
didn't specify a default in that case. Therefore it didn't make sense that a C
compiler should be able to handle that construction. Linus Torvalds pointed
out:

Actually, this is documented gcc behaviour, where a missing true condition is
substituted with the condition value.

So what the above does is set "tickadj" to 500/HZ _except_ if that underflows
to zero, in which case tickadj gets the value 1.

IOW, it's the same as

    int tickadj = 500/HZ ? 500/HZ : 1;

except that the short syntax is not only shorter, but it's extremely convenient
in macros etc, because it only evaluates the value once, ie you can do

    int tickadj = *ptr++ ? : 1;

and it's well-behaved in that it increments the pointer only once.

Jan Engelhardt objected, "it's specific to GCC. This kinda ruins some tries to
get ICC working on the kernel tree :)" Linus replied:

Ahh, but Intel compiler developers are cunning, and can make (and afaik, _did_
make) icc compatible with the good gcc extensions.

And as we all know, the definition of "good gcc extension" really is "the
kernel uses it". (Some of the good ones turned up in C99 and are thus no longer
extensions - obviously gcc wasn't the only compiler that implemented them).

Good gcc extensions:

  * the inline asm syntax (which could be better, but hey, the gcc syntax is
    certainly not the worst around either)
  * statement expressions (but dammit, it should have used "return" to return
    the value)
  * short conditionals
  * symbol attributes (sections, "used", asm naming, etc)
  * local labels and computed goto
  * case ranges
  * typeof and alignof.
  * void * arithmetic

BAD gcc extensions:

  * nested functions (gaah)
  * extended lvalues (casts, conditionals and comma-operators as lvalues. They
    are just too confusing)
  * transparent unions (dammit, you could have done it with overloading
    instead).

Jan Engelhardt took umbrage at Linus' categorization of bad GCC extensions,
saying, "You don't have to use them..." But Linus replied:

We don't, generally. But they are bad even if you DON'T use them, because they
sometimes make obvious syntax errors etc much harder to debug.

For example, the "nested function" thing makes something as simple as a missing
end brace cause the error reporting to be totally off, when gcc decides that
"hey, that's ok, those other function declarations are just nested functions in
the middle of that other function". So you get something like

    file.c: lastline: parse error at end of input

even though the _real_ parse error could have been pinpointed exactly if gcc
did NOT do it's totally braindamaged nested functions. IOW, the extension
causes problems even when you don't use it.

Same goes for the "extended lvalues". They are not only insane, but they mean
that code like

    (0,i) = 1;

actually compiles. Why is that a problem? Because some people (ie me) have used
constructs like this in macros to make sure that the macro is "read-only", ie
you have a situation where you don't want people to mis-use the macro on some
architecture. So having

    int max_of_something;
    #define MAX_SOMETHING (0,max_of_something)

is actually a nice way to make sure nobody does anything like

    MAX_SOMETHING = new;

but the gcc extension means that this doesn't actually work.

(Yes, I've been bitten by this. And no, I don't see the _point_ of the
extension - does anybody actually admit to ever _using_ comma- expressions for
assignments?)

Mitchell Blank Jr. said that when he wanted to do something similar to Linus'
trick, he used "#define MAX_SOMETHING (max_of_something + 0)". He added, "When
gcc accepts an arbitrary algebraic expression as an lvalue I'll be impressed
:-)" Linus said:

Yes, I think I've done that too, and that works. My point is that the silly
comma-expression should _also_ work, and I don't see any _valid_ use of the
comma-expression as an lvalue.

I suspect (but don't have any real argument to back that up) is that the gcc
"extended lvalues" fell out as a side effect from how gcc ended up doing some
random semantic tree parsing, and it wasn't really "designed" per se, as much
as just a random implementation detail. Then somebody noticed it, and said
"cool" and documented it.

That's actually in my opinion a really good way to occasionally find a more
generic form of something - the act of noticing that an algorithm just happens
to give unintentional side effects that can actually be mis-used. So I don't
think that it's a bad way per se to add features, especially as they then are
often free (or even "negative cost", since _not_ adding the feature would
entail having to add a check against it).

And for all I know, many of the _good_ gcc features ended up being done that
way too.

But I think the (unintentional) downsides of these features are bigger than the
advantages.

On further reflection, he added:

Btw, the "+0" thing is something that actually might be dropped pretty early,
and as such a compiler _might_ get it wrong just because it ended up optimizing
the expression away. So you don't need to be all that impressed, certain
trivial expressions might just disappear under some circumstances.

Side note: the _biggest_ reason why "+0" is hard to optimize away early is
actually type handling, not the expression itself. The C type rules means that
"+0" isn't actually a no-op: it implies type expansion for small integer types
etc.

So I agree that it's unlikely to be a problem in practice, but I literally
think that the reason gcc ends up considering a comma-operator to be an lvalue,
but not a +-operator really _is_ the type-casting issues. A comma doesn't do
implicit type expansion.

What I find really strange is the ternary operator lvalue thing, though. A
ternary operator _does_ do type expansion, so that extended lvalue thing is
really quite complex for ternary ops. Try something like this:

        int test(int arg)
        {
                char c;
                int i;

                return (arg ? c : i) = 1023;
        }

and think about what a total disaster that is. Yes, gcc gets it right, but
dammit, what a total crock. The people who thought of this feature should just
be shot.

(Yes, it looks cool. Oh, well. The compiler can always simplify the expression
"(a ? b : c) = d" into "tmp = d ; a ? b = tmp : c = tmp", but hey, so can the
user, so what's the point? Looking at the output from gcc, it really looks like
gcc actually handles it as a special case, rather than as the generic
simplification. Scary. Scary. Scary.)

18. kernel.org Hardware Troubles

24 Nov 2004 (1 post) Archive Link: "kernel.org slowness"

People: H. Peter Anvin

H. Peter Anvin explained, "Just in case people have wondered about the recent
kernel.org slowness: we got unprecedented server load after Fedora Core 3 was
released, and it hasn't fully died down yet. Additionally, the server is
starting to show its age. We are actively working on getting new hardware;
hopefully we should have something new in place some time in December or
January."

 

 

 

 

 

 

                                Sharon And Joy
                                        

Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License version 2.0.