Pavel Machek posted a patch to let init know that the power button had been pressed, so it could shut down gracefully. Andrew Grover objected, This is not correct, because we want the power button to be configurable. The user should be able to redefine the power button's action, perhaps to only sleep the system. We currently surface button events to acpid, which then can do the right thing, including a shutdown -h now (which I assume notifies init). Pavel replied, There's no problem with configurability -- you can configure init as well. I saw it pretty much analogic to situation with Ctrl-Alt-Del: it also sends signal to init. Init then decides what to do. [I believe requiring acpid for such easy stuff is not neccessary...] But John Fremlin pointed out, Using a signal to hit init with is a bit dubious because most signals are hooked up for something else already. For example, SIGTERM sent to my init (http://john.snoop.dk/programs/linux/jinit) would shutdown and start sulogin, which is probably not what you want when you press the off button. Elsewhere, Miquel van Smoorenburg added, SIGTERM is a bad choise. Right now, init ignores SIGTERM. For good reason; on some (many?) systems, the shutdown scripts include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means "all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.

Mike Castle suggested that perhaps there should be a special mechanism to allow user-space to communicate with the kernel, in order to handle all these situations. Pavel replied, init _is_ the tool which is right for defining policy on such issues. Take a look how UPS managment is handled.

There followed a long, meandering discussion on the ins and outs of various policies and configurations; but no conclusive decision came out of it.

Peter Osterlund reported that under fork load, 2.4.4 seemed less responsive than 2.4.3. He said, For example, when running the gcc configure script, the X mouse pointer is very jerky. The configure script itself runs approximately as fast as in 2.4.3. Another thing is that the bash loop "while true ; do /bin/true ; done" is not possible to interrupt with ctrl-c. A third thing I noticed is that starting a gnome session in redhat 7.0 takes longer. (It takes more time for the gnome splash screen to appear.) He attributed this behavior to the recent patch, to cause children to run first before parents after a fork; and posted a patch to revert that feature. J.A. Magallon could not confirm the problem, but Mohammad A. Haque said he'd seen the identical behavior as well. Rene Puls also reported identical behavior, and found that Peter's patch fixed it.

At one point, Linus Torvalds said, The new "run the child first" approach has advantages, but it is entirely possible that the advantages unfairly prioritize things that do a lot of forking. He and several others pointed out that Peter's while loop was just a bash bug. But he agreed there was definitely a problem. He said, Reverting it outright may be an acceptable approach. I'll think about it: the arguments _for_ the patch are true and real, and it shows up as real improvements on some things.. An alternative approach might be to not give the child the _whole_ timeslice, but give it more than half. Partition it out 66% - 33% or something.

H. Peter Anvin posted a patch, and explained, I was looking over the iso9660 code, and noticed that it was doing endianness conversion via ad hoc *functions*, not even inlines; nor did it take any advantage of the fact that iso9660 is bi-endian (has "all" data in both bigendian and littleendian format.) The attached patch fixes both. It is against 2.4.4, but from the looks of it it should patch against -ac as well. Martin Dalecki sounded a word of warning, Please beware: There is a can of worms you are openning up here, since there are many broken CD producer programms out there, which only provide the little endian data and incorrect big endian entries. I had some CD's of this form myself. So the endian neutrality of the iso9660 is only in the theory present... Pavel Machek remarked with a smirk, It might be funny to *deliberately* create different filesystems; one on little endian side and one on big endian side. That way windows users would see "macs suck" and mac users "PCs suck", and that with just one cd ;-).

Andreas Rogge wanted to create 100,000 mailboxes in a directory, only to find that after 32768, the directory refused to create any new sub-directories. H. Peter Anvin replied that he believed 2^15 directories in a single directory was an ext2 limitation. Andreas Dilger replied:

Chris Mason confirmed Andreas D.'s observations on reiserfs, The link count isn't used at all when deciding if the directory is empty (we use the size instead), so we can just lie to VFS if someone tries to make tons of subdirs. Andreas D. replied, For that matter, ext2 doesn't use the link count on directories to determine if they are empty either, so it shouldn't be too hard to do the same with the ext2 indexed-directory code.

Ingo Oeser suggested that any application trying to create so many directories was completely broken, but H. Peter said, The application is using the VFS the way it is advertised to work. If you think doing ls on an extrememly large directory is painful, you have never seen the droppings of an application which tries to do load-balancing between directories by doing real hashing. THAT is painful! At least in the first case you can use grep.

Geert Uytterhoeven suggested:

Jonathan Lundell replied:

There was some discussion of various possibilities, and at one point David S. Miller remarked, I suppose the point is that there is a fine line wrt. using APIs to influence people to "do the right thing", and this has been exemplified in several threads I've been involved in wrt. PCI dma and other topics. :-)

Nico Schottelius posted a patch to create a compile-time option to disable the speaker on the PC. Simon Richter said it would be nice if this were configurable at runtime via something like sysctl. Keith Owens said the entire problem was user-space, since setterm and xset could both disable the speaker. But Oystein Viggen replied, Well, some buggy programs don't care about you turning off beeping in X. I think gnome-terminal or such has its own checkbox for turning beeps on or off. Nico said that he'd also first thought the problem was user-space only. But he also agreed with Simon, that a runtime option would be best of all. He asked where to find sysctl documentation, but no one gave any links.

Anton Blanchard announced:

Dwayne C. Litzenberger started salivating onto the floor, and asked, How far away is the capability to "teleport" processes from one machine to another over the network? Think of the uptime! A couple people pointed him to MOSIX, but Jakob Ostergaard replied that MOSIX actually wouldn't give long uptimes due to process migration. He pointed out that processes on MOSIX clusters were always tied to their home node, and would die no matter how far they had migrated, if the home node died. Bruce Harada gave a pointer to Heterogeneous Process Migration: The Tui System.

There was no reply to that, but elsewhere, Peter Rival asked when hot-swap or hot-add RAM would be supported, and Chris Wedgwood replied, Adding memory probably isn't going to be too hard... but taking existing memory off line is tricky. You have to find some way of finding all the pages that are in use and then dealing with them appropriately, and when some are locked or contain kernel data this would be extremely difficult I should think. Later he added, It's hard with current memory allocation and management paradigms, if we wanted to abstract things more and make (break) certain rules, I'm sure it can me made to work -- the only thing is, we would loose _MUCH_ speed and efficiency (and waste much more space), so much so I doubt anyone would serious want to know about it. We would also have to violate certain assumptions of RT applications.

At one point, Rik van Riel said that hot-remove RAM wouldn't really be so difficult, because:

Chris asked how Rik would handle relocating pages which were mlocked, without violating RT contraints. Rik replied, Fuck RT constraints. Linux doesn't have infinitely small scheduling latencies, it's easy to copy a page without increasing the scheduling latencies much. David Woodhouse gave his take:

Keith Owens requested:

Vamsi Krishna S. volunteered to work on item 4. Tigran Aivazian suggested adding to the wishlist:

There was no reply to this, but Manfred Spraul also suggested, 'ss' and especially 'ssb' could print the new value of the overwritten register/memory address in each line, perhaps both the old and new value. Keith exhorted people to actually code up the existing wishes before adding new ones.

There was no reply to this, but elsewhere, George Anzinger replied to item 1 of Keith's original list. He pointed out, ^X^X swaps point and mark in emacs. One (well, I) often will do ^X^X^X^X to examine where mark is and then return to point. Someone suggested using the break condition instead, and Juan J. Quintela replied, kdb uses BREAK in the serial port (that minicom uses C-a for sending a break is an anecdote :) But the problem at hang is the console. I vote for the ^X^X^X as I a think that it is not a difficult shortcut. (and yes, I also use emacs and ^X^X all the time, but I think that this combination is not specially bad, and I suppose that the pet aplication of other people will have problems with something like: ^A^A^A that I never use).