I don't think I ever really affirmatively agreed to anything. I do recall various things being discussed at various times and various things being changed, but from where I sit it's all spread out and foggy.

I certainly remember that good-sounding recommendations which addressed the things which Christoph doesn't like were convincingly shot down by yourself and by Robert, but I don't recall why.

Look, this stuff is hard. This is why I've asked you and Robert again and again and again to generate some sort of design doc or FAQ which addresses each of these frequently-asked-questions. So the poor rest of us can look through it and say "oh yeah". Because inotify _is_ a tricky thing, and standard kernel interface designs _don't_ fit it well.

So. It's not too late. Please spend an hour and write up the Inofity Implementation FAQ? You probably remember and fully understand what all of our objections are and I know that you have explanations and rebuttals at hand.

Please? Something like:

q: Why does it use an ioctl multiplexer

a: Because ...

etc...

I haven't done a detailed review of the patch in months and I intend to do another soon. That FAQ will help! When I ask more silly questions we can update it, so those questions will never again be asked.

I know it's unusual process-wise, but inotify is an unusual feature.

As some people may have noticed already, 2.6.12 is out there now.

The full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory. The file that says "ChangeLog-2.6.12" only contains the stuff from -rc2 onward.

Included here in the email are the changes since -rc6, and as you can see from the appended diffstat, most of the things are pretty small (ie it looks like a long list, and then you look at the diffstat and realize that most of the changes end up being just a line or two).

One of the least important changes is still worth pointing out: it was discussed earlier on the kernel mailing list in another thread, but maybe people didn't notice it: the sign-off procedure was clarified to make it clear that the person signing off understands that the project - and thus the patch and the sign-off itself, of course - is public and will be archived.

This may sound silly and obvious - and it is - but it makes people more comfortable about the fact that we obviously save identifying information in the sign-off (that's the whole point), and in general people also submit things like their own email addresses in CREDITS files etc, and so nobody should be expecting any of that to be kept confidential.

I don't think anybody did, of course, but hey, this way it's explicit. So part of the new stuff is this patch:

        diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
        --- a/Documentation/SubmittingPatches
        +++ b/Documentation/SubmittingPatches
        @@ -271,7 +271,7 @@ patch, which certifies that you wrote it
         pass it on as a open-source patch.  The rules are pretty simple: if you
         can certify the below:

        -        Developer's Certificate of Origin 1.0
        +        Developer's Certificate of Origin 1.1

                 By making a contribution to this project, I certify that:

        @@ -291,6 +291,12 @@ can certify the below:
                     person who certified (a), (b) or (c) and I have not modified
                     it.

        +       (d) I understand and agree that this project and the contribution
        +           are public and that a record of the contribution (including all
        +           personal information I submit with it, including my sign-off) is
        +           maintained indefinitely and may be redistributed consistent with
        +           this project or the open source license(s) involved.
        +
         then you just add a line saying

                Signed-off-by: Random J Developer <random@developer.org>

just so that people are aware of this.

Btw, in case anybody ends up wondering about what the actual patches are, if you're a git user (or, more likely, not quite a user yet, but rather wondering what you can do with git), you can start off with doing

git-whatchanged -p v2.6.12-rc6..v2.6.12

and it will do exactly what you think it migth do - it shows every commit between -rc6 and the final 2.6.12 release as a patch ("-p") with the associated commit message.

Yes, git creates tar-archives that use the extended pax headers, and I think you need tar-1.14 to fully understand them. They should not hurt (apart from the warning) on older versions of tar.

The extended header just contains a hidden comment record that tells the git commit ID that was used to generate the tar-tree.

Because it's extracted as a regular file (instead of tar knowing that it's a comment header), you will now have a file called "pax_global_header" that has the contents

52 comment=9ee1c939d1cb936b1f98e8d81aeffab57bae46ab

in it (where "9ee1c939d1cb936b1f98e8d81aeffab57bae46ab" is the git SHA1 name of the Linux-2.6.12 commit).

So it's not entirely "harmless" in that it causes a bogus file to be created, but it's not like it's a huge problem either, and that bogus file actually does contain real information (although it's not useful unless you're a git user).

In an attempt to make VOIP technology usable by other members of the household, I have created a device driver for the Yealink usb-p1k phone also known as a so called Skype phone.

Basically the device consists of an usb sound-card with keyboard, LCD, speaker and will set you back for about 30 euro's.

The "sound card" is supported by the generic usb-audio driver. This driver adds support for keyboard, LED, dialtone and LCD functions.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm1/

• Someone broke /proc/device-tree on ppc64. It's being looked into.
• Nothing particularly special here - various fixes and updates.

As promised, we are finally releasing the Linux RealTime Benchmarking Framework (LRTBF). We hope others will find it useful and even want to add their own testsets. Generally we'll be more than pleased to add contributions to future releases.

As was explained earlier, the Linux RT Benchmarking Framework (LRTBF) is a set of drivers and scripts for evaluating the performance of various real-time additions for the Linux kernel. Specifically, the LRTBF allows measuring the overall load imposed by the RT enhancement and its ability to deterministically respond to incoming interrupts. Initially, the LRTBF was used for evaluating Ingo Molnar's PREEMPT_RT patches and Philippe Gerum's I-pipe, but by releasing it under the GPL we hope its usefullness will extend beyond those initial tests.

The LRTBF and all related information is found here: http://www.opersys.com/lrtbf/

We (the -stable team) are announcing the release of the 2.6.12.1 kernel which has two security fixes.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.12 and 2.6.12.1, as it is small enough to do so.

The updated 2.6.12.y git tree can be found at: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.12.y.git

and can be browsed at the normal kernel.org git web browser: www.kernel.org/git/

 Makefile                  |    2 +-
 arch/ia64/kernel/ptrace.c |   15 ++++++++++-----
 arch/ia64/kernel/signal.c |    5 +++--
 fs/exec.c                 |    1 +
 4 files changed, 15 insertions(+), 8 deletions(-)

Summary of changes from v2.6.12 to v2.6.12.1

Chris Wright:
Linux 2.6.12.1

Linus Torvalds:
Clean up subthread exec (CAN-2005-1913)

Matthew Chapman:
ia64 ptrace + sigrestore_context (CAN-2005-1761)