Andrew Morton announced Linux 2.6.9-rc2-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm1/
- Added lots of Ingo's low-latency patches
- Lockmeter doesn't compile. Don't enable CONFIG_LOCKMETER.
- Several architecture updates
Norberto Bensa pointed out that one of the patches Andrew had accepted would break Nvidia's binary-only driver, and that Nvidia users would have to revert the patch in order to use the driver.
Jesse Barnes also noticed that some of the changes in -mm1 broke sn2; and some folks worked on that.
Miscellaneous other breakages and fixes were discussed, as usual.
James Bottomley said:
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
If you look at debian at the moment, it uses a huge mapping table on /proc/scsi/* to do this. If we implement the sysfs feature, we can simply go from /sys/block/<device> to the actual device to the driver and then to the module with no need of any fixed tables.
The code is a first cut and introduces two new module APIs: module_add_driver() and module_remove_driver(). We need this because the generic device model driver has no current knowledge of modules. We could enhance it to have a struct module * in struct device_driver, but once we have the sysfs links which this patch provides, there didn't seem to be a compelling reason to add it to struct device_driver.
Greg KH replied, I like it. But I do think that
this should be moved into the driver core, so I added a "struct module *"
to "struct device_driver". Here's the patch that I just applied to my
trees, based on yours. It is only the core changes (and yes, I did fix up
the location of the functions in the module.h file and fixed the bug when
modules were not configured in.) I'll post my usb core change after this,
to show you how USB can be hooked up to it. I'll let you figure out what
the best way to handle the scsi code would be.
He posted his patches,
but there was no discussion.
Elsewhere, Alexander Viro had his own objections. He said to James:
So what will your userland code do when you run it on a system with non-modular kernel currently running?
IOW, that's a fundamentally broken interface - you really want the same information regardless of modular vs. built-in.
Greg replied, I agree, and Rusty has some pending
patches that provide that information for all drivers built into the system.
When they are merged, this symlink will be created for those also (with a
bit of tweaking, but it will happen.)
Herbert Xu also agreed with
Alexander's objections, and was glad to see this being worked on in this
thread. James, however, disagreed with Alexander that the interface was
broken, though he agreed the module parameters might have some issues. But
there wasn't much discussion.
Rusty Russell put some comments in the code to warn folks that ipchains and ipfwadm were deprecated and would be removed soon. He said:
At the recent netfilter workshop in Erlangen, we was decided to remove the backwards compatibility code for ipchains and ipfwadm. This will allow significant cleanup of interfaces, since we had to have a mid-level interface for the backwards compatibility layer to use.
Start off with a warning for 2.6.9, so any remaining users have a chance to migrate. Their firewall scripts might not check return values, and they might get a nasty surprise when this goes away.
Bill Davidsen remarked:
I thought I understood the "new development model" but I guess I don't. Are working features now going to be removed from the "stable" chain instead of during a development cycle?
Not a complaint, I thought the new method was regarding new features...
There was no response here, but elsewhere Marc Ballarin pointed out that
Rusty's comments were compile-time only, and would thus probably be missed in
the long stream of compile-time warnings put out by standard kernels. Rusty
replied, Sure, but you have to start somewhere.
Next step will be #error. Then finally remove the whole thing (I don't want
to remove the whole thing to start with, since that would create a silent
failure).
Marc said he was thinking of a prominent message at module
load time; but the discussion skewed off.
Close by, Richard B. Johnson asked, What
replaces the firewall stuff? It can't just "go away"!
James
Courtier-Dutton and Marc replied that iptables had already been the standard
since 2001. Martin Josefsson also pointed this out, but Richard replied that
old code still depended on the old mechanisms. He said:
I guess I'll have to convert 1340 lines of ipchains commands to iptables -yech!
I had convert something to ipchains a couple of years ago. That's when I only had to kill-off only about 100 spam-hosts.
Now I gotta convert again. Soon they'll be replacing `ls` with `echo *` and nothing will work.
William Stearns replied:
I have a script that does a first pass of converting an ipchains firewall script to an iptables firewall script at
http://www.stearns.org/i2i/ipchains2iptables
http://www.stearns.org/i2i/ipchains2iptables.READMEBecause of architectural differences between the two firewall technologies it can't produce a perfect translation, but it does handle most of the grunt work.
Close by, Andi Kleen also pointed out that doesn't
have usable 32bit emulation on x86-64. 32bit userland on x86-64 kernel
cannot use iptables, they have to use ipchains. I would ask for to not
drop ipchains until this is fixed.
David Woodhouse agreed with this,
saying, The iptables compatibility with 32-bit
userspace is completely broken.
But Albert Cahalan objected, Who is doing a 32-bit userland on x86-64, and WTF for?
Why do they not also run a 32-bit kernel?
Matthew Garrett replied,
Debian will be shipping a 32-bit userland with a
64-bit kernel. The reasons are long, awkward, and mostly uninteresting. The
reason for shipping a 64-bit kernel is that it makes it easier for users
who require large quantities of VM to obtain it.
David S. Miller
said, But just like the sparc64 port, there
is a 64-bit userland compilation environment available, and debian has the
means to ship 64-bit specific packages on top of a mostly 32-bit userland.
So it is very easy for them to ship a 64-bit netfilter utility package if
they wanted to.
Con Kolivas said:
Updated the staircase cpu scheduler. This version is the first in the next development phase I've been leading it towards - removing dependency on scheduler_tick to make it suitable for a tickless kernel.
v8.6 removes all timeslice expiration from scheduler_tick and does this with an on-demand timer of it's own. Currently this does not offer any major advantage over the previous version, but once more of the code is removed from scheduler_tick and there is a mechanism for more accurate timers not dependant on jiffies it will offer better accuracy, lower overhead and low power advantages.
Rolled up and split patches for 2.6.9-rc2-mm2 available here:
Andrew Morton announced Linux kernel 2.6.9-rc2-mm3, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm3/
- This is a quick not-very-well-tested release - it can't be worse than 2.6.9-rc2-mm2, which had a few networking problems.
- Added Dmitry Torokhov's input system tree to the -mm bk tree lineup.
Mike Waychison said:
Some of you may remember my posting of a new way to do autofs in Linux a while back:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107341940326348&w=2
Anyhow, I've gotten to the point where I have code that people can play with. I've posted it all at http://autofsng.bkbits.net
There are two repos located there, one is the userspace bits (autofsng). ~ It has the 'utility' (automount) and the autofs usermode agent (autofs). This tree began as a automount 3.1.7 tree, but has drastically changed. Lots of good stuff has yet to be merged in from the automount 4 daemon.
The kernel bits are in the linux-2.6-autofsng repository. Broken out patches are forthcoming in the next (weeks?) [I know it is bad practice to pop-up out of nowhere with large changes, but I wasn't able to get anything out much earlier due to a variety of reasons. From now on, expect to see much traffic from me as I feed a broken-out patchsets to the list.]. It has the following major changes to it:
- - changes to the vfsmount tree structures so that you can detach and re-attach sub-trees of the vfsmount tree. The current implementation is admittedly a bit gross and will require work to make it pretty (and to get rid of having to grab a rwlock on every mntget/mntput!).
- - the addition of a mountpoint file descriptor api. I don't care for the interface at the moment, and I'll be posting interface descriptions later on along with broken out patches so that the interface itself can be thought through.
- - vfs native support for expiring mountpoints (and entire subtrees of them). There currently exists a syscall entry to specify this from userspace as a way to easily test it. As well, you can specify expiry information using the above mountpoint file descriptor api.
- - a new module implementing the 'autofs' filesystem called autofsng. This filesystem will support automounting of both direct and indirect maps. It also supports 'browsing'. Most of this magic happens using '->follow_link' walks on directory inodes. This is ugly, but it appears to be the best way to properly handle automounting from within the kernel.
There does remain a good amount of work to do, and I've tried to list things on the top of my head in the autofsng/autofs/TODO file. I'm sure I missed stuff :\
At this point, I can run and pass a ported autofs connectathon testsuite. I'm working on figuring out how to get the testsuite included in the package. For comparison, both autofs3 and autofs4 couldn't handle the majority (>%95) of the tests done. As well, we've uncovered a couple of nfs related issues that we'll be following up with on the nfs list.
So, if you have time to spare and you care about automounting, please have a try at using it. If you are curious enough to wade through it, feel free to give feedback/flames/comments on the code/design/weather.
Stew Smith said, autofsng userland tarball
and kernel patch can now be found here for non-bitkeeper users: ftp://ftp-eng.cobalt.com/pub/users/ssmith/autofsng/
Ed Schouten said that he'd Added
support for Microsoft Xbox gaming consoles by adding the config option
'CONFIG_X86_XBOX'. This patch is very minimalistic and should give the fellows
at xbox-linux.org a starting point.
Nick Piggin asked if anyone would
ever want to run a Linux kernel on an xbox; and Will Dyson and Ed said yes
indeed they wanted this. As Will put it, I would
appreciate having fewer out of tree patches to apply in order to run a new
kernel.
Nick replied:
I ask because there is probably quite a large number of embedded type devices devices that you could "just add a small patch for" to get it working. The added fact that you have to "hack" the hardware (I think?) to even get it to run Linux makes it probably a bit more questionable (it is great that we can run on xbox, but maybe not too harmful to keep it as an external patch). Anyway I've otherwise got no objections ;) if you can convince Andrew and/or Linus to merge it, then fine.
Ed replied:
you have multiple options to get Linux on it (flash the BIOS with cromwell, grub-based bootloader, alter some of its current software, etc).
The reason why the Xbox-Linux folks and I think it should belong in the main tree is adoption. Xbox Linux has been around since 2001 if I remember correctly and there are almost no distributions around that really support the Xbox. The people at Debian for example will only add Xbox support if it is available in the main tree.
David Weinehall also said to Nick, I really
hope that small patches for embedded type devices get accepted (given,
of course, that they follow the same quality standards as other patches),
just like we accept drivers for the x86...
Pavel Machek agreed with
this sentiment, saying that the Xbox port was really just another port like
ARM etc.
Nick said that the Xbox was a special case because running Linux on it required actually circumventing the hardware. But he reiterated that if Andrew Morton or Linus Torvalds accepted the patch, he'd have no objection. Rahul Karnik replied:
Linus rejected a similar (slightly larger patch) last year.
http://marc.theaimsgroup.com/?t=105819036500001&r=1&w=2
That said, he does change his mind. Is this still a "politically hot potato"?
Ed said:
From my point of view it isn't. Xbox-Linux already exists for three years and Microsoft still haven't done anything against it. It would be silly if they would file a lawsuit against us, after three years.
If they would, it would be useless anyway. Quote from xbox-linux.org: "Everything done on this project is for the sole purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA."
Sect. 1201 (f) can be read here: http://cyber.law.harvard.edu/openlaw/DVD/1201.html#f