I'm pushing what looks like the "final" version of sysenter/sysexit for now. There may be bugs left, but all the known issues are resolved:

• single-stepping over the system call now works. It doesn't actually see all of the user-mode instructions, since the fast system call interface does not lend itself well to restoring "TF" in eflags on return, but the trampoline code saves and restores the flags, so you will be able to step over the important bits.

  (ptrace also doesn't actually allow you to look at the instruction contents in high memory, so gdb won't see the instructions in the user-mode fast system call trampoline even when it can single-step them, and I don't think I'll bother to fix it up).

• NMI at the "wrong" time (just before first instruction in kernel space) should now be a non-issue. The per-CPU SEP stack looks like a real (nonpreemptable) process, and follows all the conventions needed for "current_thread_info()" and friends. This behaviour is also triggered by the single-step debug trap, so while I've obviously not tested NMI behaviour, I _have_ tested the very same concept at that exact point.
• The APM problem was confirmed by Andrew to apparently be just a GDT that was too small for the new layout.

This is in addition to the six-argument issues and the glibc address query issues that were resolved yesterday.

2.5.49 was usable for devel work, no kernel since has been. Its stopped IDE getting touched until January.

Linus. you are doing the slow slide into a second round of development work again, just like mid 2.3, just like 1.3.60, ...

it's a fair question.

I've been wondering how to formalize patch acceptance at code freeze, but it might be a good idea to start talking about some way to maybe put brakes on patches earlier, ie some kind of "required approval process".

I think the system call thing is very localized and thus not a big issue, but in general we do need to have something in place.

I just don't know what that "something" should be. Any ideas? I thought about the code freeze require buy-in from three of four people (me, Alan, Dave and Andrew come to mind) for a patch to go in, but that's probably too draconian for now. Or is it (maybe start with "needs approval by two" and switch it to three when going into code freeze)?

It does sound a little bureacratic for this point in development.

The first thing we need is a set of widely-understood guidelines. Such as:

Only

• bugfixes
• speedups
• previously-agreed-to or in-progress features
• totally new things (new drivers, new filesystems)

Once everyone understands this framework then it becomes easy to decide what to drop, what not.

So right now, sysenter is "in". Later, even "speedups" falls off the list and sysenter would at that stage be "out".

Can it be that simple?

You'd likely need an odd number of folks in this cabal^Winner circle though, or would you just do it and be damned if you got an equal number of 'aye's and 'nay's ? 8-)

Other than that, it reminds me of the way the gcc folks work, with a number of people reviewing patches before acceptance [not that this doesn't happen on l-k already], and at least 1 approval from someone prepared to approve submissions.

The approval process does seem to be quite a lot of work though. I think it was rth last year at OLS who told me that at that time he'd been doing more approving of other peoples stuff than coding himself.

Quite frankly, I wouldn't expect a lot of dissent.

I suspect a group approach has very little inherent disagreement, and to me the main result of having an "approval process" is to really just slow things down and make people think about the submitting. The actual approval itself is secondary (it _looks_ like a primary objective, but in real life it's just the _existence_ of rules that make more of a difference).

I heartily disagree with the approval process for development, just because it gets so much in the way and just annoys people. But for stabilization, that's exactly what you want. So I think gcc is using the approval process much too much, but apparently it works for them.

And I think it could work for the kernel too, especially the stable releases and for the process of getting there. I just don't really know how to set it up well.

A start might be

1. Ack large patches you don't want with "Not for 2.6" instead of ignoring them. I'm bored of seeing the 18th resend of this and that wildly bogus patch.

   Then people know the status

2. Apply patches only after they have been approved by the maintainer of that code area.

   Where it is core code run it past Andrew, Al and other people with extremely good taste.

3. Anything which changes core stuff and needs new tools, setup etc please just say NO to for now. Modules was a mistake (hindsight I grant is a great thing), but its done. We don't want any more
4. Violate 1-3 when appropriate as always, but preferably not to often and after consulting the good taste department 8)

Make it async. So anyone can review stuff and record their feelings in a centralized place. We have a spare machine set up, kernel.bkbits.net, that could be used as a dumping grounds for patches and reviews if master.kernel.org is too locked down.

If you force the review process into a "push" model where patches are sent to someone, then you are stuck waiting for them to review it and it may or may not happen. Do the reviews in a centralized place where everyone can see them and add their own comments.

Huh? That's like saying "we don't need a bug database, we have a mailing list". That's patently wrong and so is your statement. If you want reviews you need some place to store them. A mailing list isn't storage.

You'll do it however you want of course, but you are being stupid about it. Why is that?

Oh dear me. Larry McVoy has flipped

I'm now being added to his spam list for *not* mentioning bitkeeper

Poor Larry, I hope has a nice christmas break, he clearly needs it

A happy christmas to you all, and in case I'm too busy putting batteries in the kids presents the rest of the year, here's a 2.5.53 for you.

It's got stuff all over - SCSI updates, ACPI, ia64, sparc, USB, net, device mapper, AGP, ALSA, you name it. Meanwhile I worked mostly on the sysenter support, we'll have to wait for glibc releases to test that out more.

Oh, and merges with Andrew and Dave.

This patch updates UML to 2.5.53. As far as UML itself is concerned, this is identical to all recent 2.5 UML releases, except that I tossed in a small fix for a race involving multiple xterms popping up at once.

I'm in the process of merging my recent 2.4 changes into my 2.5 tree, but I figured I'd get this patch out first.

The 2.5.53 UML patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.53-1.bz2

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

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

Please pull either http://uml.bkbits.net/skas-2.5 or http://jdike.stearns.org:5000/skas-2.5

This allows the UML kernel to run in a different address space from its processes. The benefits include better security and much improved performance. This is a large patch, but

it's all under arch/um and include/asm-um
a lot of it is code movement

This is described fairly completely in

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=fa.ia69pmv.e4qnq1%40ifi.uio.no

Pulled, but that /proc/mm crap has to go (it wasn't in this patch, or I would have rejected it).

What are the semantics the host code wants/needs, and how can we implement a sane generic mechanism that doesn't involve opening magic files?

Having co-processes isn't wrong in itself, I just want the support to be clean and generic, instead of a huge hack.

1. Multiple address spaces per process
2. Ability to make a child switch between address spaces
3. Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect on an address space which is not current->mm)

Yes, valgrind already has a pseudo-scheduler, a psuedo-threads library, it delivers signals by hand, and it wants to run its client in a separate thread so it can get out of the business of being an LD_PRELOAD shared library.

This is all stuff that UML has, that UML does right (/me crosses fingers), and that is usable by Valgrind (and anything else that's interested) with some repackaging of UML as a library.

Replacing Valgrind's signal delivery with UML's is a no-brainer. Replacing its scheduler and threads library would involve it creating UML processes by calling UML's do_fork(). Valgrind would need to provide the low-level switch_to, I think. There are probably other things that Valgrind would need to provide, but I see no reason this wouldn't work.

I do believe that fd's are a natural way to handle it, since it needs _some_ kind of handle, and the only generic handles the kernel has is a file descriptor. We could create a new kind of handle, but it would be likely to be just more complexity.

HOWEVER, the part I worry about is creating tons of new system calls that just duplicate existing ones by adding a "fd" argument. That part I really don't much like. Because if this were to really be a generic feature, it really wants pretty much _all_ system calls supported, ie things like

        fd = open(<mm,ptr>ags, ...);

        retval = read(<tr>

to allow the user to not just mmap but generally "take the guise of" any other mm for the duration of the system call.

Which really means that I _think_ the right approach would be to literally have a "indirect-system-call-using-this-mm" system call, which does something like

        asmlinkage sys_mm_indirect(int fd, struct syscall_descriptor_block *user_args)
        {
                struct mm_struct *old_mm;
                struct syscall_descriptor_block args;

                if (memcpy_from_user(&args, user_args, sizeof(args)))
                        return -EFAULT;

                mm = get_fd_mm(fd);
                old_mm = current->mm;
                current->mm = mm;
                switch_mm(mm);

                arch_do_syscall(&args);

                current->mm = old_mm;
                switch_mm(old_mm);
                put_mm(mm);
        }

which allows _any_ system call to be made for that mm.

If their module is a derivative of GPL code, then yes.

If the total work consisting of GPL code and their proprietary module is a derivative of GPL code, then probably.

Richard Henderson is working with tgafb on alpha. I'm looking into the architecture specific Makefiles in cooperation with Richard.

I recall alpha patches from others as well, but do not recall anything about module support.

After quite some fiddling we finally have some glibc binaries with sysenter support. The problems were not in the sysenter code but in coordinating everything in ld.so so that it works on old kernels (without TLS support).

Anyway, the result can be downloaded from

ftp://people.redhat.com/drepper/glibc/2.3.1-25/

These RPMs are drop-in replacements for the ones in the last Red Hat beta, released about a week ago. They haven't been tested in any other environment. They also use NPTL as the default libpthread. As is the case with every beta release code, do *not* install them on production machines. We see no problems with the new code but your mileage may vary. If you see problems ideally file them in Red Hat's bugzilla (remember these are RH-specific binaries). Alternatively send reports to libc-alpha@redhat.com. If you suspect the problem is related to the kernel side you know where to post.

Thanks.

Having a full system like this showed a few special cases in sysenter handling, where some system calls really depend on the old "iret" return path.

Notably, "sys_iopl()" requires the iret path because that's the only way to restore the full eflags, and "execve()" requires the iret return path because it needs to start up the new process with fixed values in %edx/%ebx, and the stack has a new layout and no longer contains the required sysexit fixup code.

I've pushed the fix for both of these issues to the kernel -bk trees.

Without the fix, a system with sysenter support would not boot up cleanly with these libraries due to the execve() issues, and X wouldn't start because of the iopl() problem.

With this in place, I've not seen any strange behaviour.

A couple of weeks ago, I started a thread about writing a bug database dedicated to Linux kernel development.

My theory is that by making it Linux kernel development specific, it can save more time, and make bug tracking easier than a generic bug database.

Anyway, version 1.0 is now on-line:

http://grabjohn.com/kernelbugdatabase/

For the time being, you'll have to E-Mail me a request for a user account, (which you need to do anything with it), but I've also put some screenshots on-line here:

http://grabjohn.com/kernelbugdatabase/screenshots/

Basically, it's designed around two main principles:

• As much as possible is done automatically - you shouldn't need to search using keywords, or categorise things manually, (although you can). Instead, try searching for bugs by uploading a .config file, and having it automatically parsed, by selecting config options from a list, or by browsing the database for the state of bugs in a particular kernel tree.

• Bugs are colour-coded:

  Grey - untested in this kernel version
  Blue - untestable in this kernel version due to other bugs
  Red - this bug is present in this kernel
  Green - this bug is not present in this kernel

There is also a command line interface, which will eventually be accessible via E-Mail, but for the time being it is only accessible via the web. The command line interface currently allows you to list the bugs, get details about them, and add comments.

Any comments on this new bug database would be very much appreciated!

OK, I've fixed some bugs and added a guest account to my new bug database:

http://grabjohn.com/kernelbugdatabase/

Username: guest
Password: guest

You can't submit bug reports or add comments using the guest account, (it will appear to let you, but then just not add the data), but you can search, and try out the command line interface.

If you want a real account, drop me an E-Mail.

After consulting with Rusty, I'm happy to present an initial cut at manpages for Futexes in Linux 2.5.40 and onwards.

Please find DocBook, HTML and troff on http://ds9a.nl/futex-manpages and on http://ds9a.nl/futex-manpages.tar.gz

Andries, please consider these for adoption.

I'd like to present 2nd version of fastps.

Changes at kernel side:

• common codebase for 2.4 and 2.5
• filters incorporated (ability to select processes to be retreived)
• possible deadlock removed
• usage of for_each_task() reduced
• O(1)-compatibility

Changes in userspace tool fps:

• ability to select processes to be shown (see fps -h)
• cleanups in output format
• fps looks for System.map in several dirs

Patches against 2.4.20/2.5.53 and userspace tool may be found at http://tmi.comex.ru/fps/

This is to announce my availability for President of the United States of America. I am a 46 year old US citizen. My platform is extreme openness. As President, I will install high-quality motion-picture cameras everywhere I sleep, with some distribution mechanism for the interested adult public to audit the produce of such cameras. Rest assured, there is currently no reason to suspect that such cameras would detect anything notable. As President, I will make every effort to release most government-held secrets. Under me, the Executive Branch will convert all personal IBM PC-type computers to unix-like or other open-source operating systems. Et cetera. Extreme openness. I will accept the nomination of either major US political party. If I don't get a major nomination or huge independant support, I support the Democratic Party candidate. Until subsumed by a major established party, consider me the leader of the "Responsible Party".

Send contributions to

Rick Hohensee
3234 Powder Mill Rd.
Adelphi, Maryland
USA
20783-1037

Please identify yourself accurately with any contributions. Anonymous or inadequately accounted contributions will be noted on the Internet and donated to a D.C. service for the homeless, or will be distributed to the homeless by me personally. Contributions and contributors, if any, will be listed on the Internet. If you are contributing for or as an organization, detail the contributors to the organization to at least a 1% resolution. As far as I know, I may have already hereby violated some campaign finance law. If so, please advise. Looking at a campaign one step at a time, if you contribute by check, please note that I don't currently have a checking account and it requires about $100-- to start one.

Class is accountable. Party responsibly.

Oh by the way, I need hackers for my cabinet. I have the US Code on my FTP site,

ftp://ftp.gwdg.de/pub/linux/install/clienux/packages

It took a week to pull it out of the retarded privatized interface the GPO has it behind. Talk about bloat. It makes Common Lisp look like Chuck Moore's latest Forth chip. I also need somebody to liberate the CFR, the Code of Federal Regulations.

I need some people that haven't forgotten how to use a computer to do basic cleanups like convert "intelligence" in the CIA sense to "strinfo", shut down the war on herbs, eliminate using the tax laws as a form of subsidy, et cetera. The better hackers will get cabinet positions. Otherwise I'll promote from the existing staff.