On Sun, Jul 10, 2005 at 11:49:22AM -0700, Greg KH wrote: > On Sun, Jul 10, 2005 at 12:56:52AM +0200, Jakob Bohm wrote: > > > > Am I understanding you correctly when I read it as saying that kernel 2.6.12 > > (a point release in the "stable" branch) > > There is no more "stable" or "development" kernel branches anymore, > haven't been for quite some time. So this statement is false.
I was aware that a more aggressive change policy had been decreed for the 2.6.x series and that 2.7.x had not yet been started. I was not aware that the whole idea of starting a truly experimental branch (2.7.x or whatever) later had been abandoned. But thanks for the info, it only reinforces one of my points. > > > is making an incompatible change to the udev interface, > > No, udev had a bug that caused it to not work as well as it should in > 2.6.12, it was not a kernel problem. > > > requires an upstream udev version which will not work on relatively > > recent kernels (2.6.8 etc.) > > Not true again, the current udev will work just fine on older kernels. That was not the information published by Marco in his packaging changelog and in his blog. The bug is reported against the Debian package, I believed Marco on his word that this was an upstream change in udev, that udev 0.060 would not fully work on kernel 2.6.8, while previous udev versions would not work on kernel 2.6.12 . > > > and (from info elsewhere) simultaneously drops support for devfs (to > > which people just finished migrating their locally written scripts > > ...)? > > devfs has just been removed from the main kernel tree. If you all are > just starting to add support for it, you are all pointless behind the > times. Again confirming what I said. The decision to drop devfs as of 2.6.12 did not reach us users until about a year ago. Converting thousands of tools, scripts (upstream sources, distribution packages, local sysadmin scripts, even files such as /etc/fstab) on each and every system had then (a year ago) just been completed (not started). At that time, 2.6.x was relatively new, devfs was supported in both 2.4.x and 2.6.x and its naming scheme was no longer being changed at irregular intervals. Not so with udev. A year ago. Then the word came down: devfs is going to be removed! Move to udev! All your work is wasted! Debian does a very thorough and careful QA and integration on packages and has traditionally had a great focus on backward compatibility, however this natural creates a delay before major upstream events reach the user end of the pipeline. Full support for running Debian on kernel 2.6.x at all was not declared release ready until June 6th 2005, and just in case that release included kernel 2.4.27 as a fallback option. This was also the first release to not include a fallback kernel from the 2.2.x series. And the first release with an officially supported udev package. The Beta period for stuff like kernel and udev was a whole year *after* deciding on upstream versions numbers and making things apparently work. Put another way: kernel.org changes before mid 2001 became "Beta" in mid 2001 and was released in mid 2002. The batch of changes from mid 2001 to mid 2004 became "Beta" in mid 2004 and released in mid 2005. The batch changes from mid 2004 until some time in 2006 are now being prepared, expecting a "Beta" mid 2006 and release early 2007 (My apologies to the release team if this rough timeline is not accurate, I use words like Beta loosely here). It is like interstellar (local) e-mail: Ping round trip time measured in years, delay-bandwidth product (=TCP window) in Giga or Terra bytes. On systems not running Beta releases, this means that using udev rather than devfs in the system configuration and scripts was not even an option until a few weeks ago, less if people wait until they can get a DVD box via surface mail. Some people live on the bleeding edge, others wait for things to stabilize and the kinks to be shaken out of systems first. And for us, killing such a pervasive API needs a longer notice than a year or two. > > In the future, please get your facts straight before complaining. > I was complaining to Marco based on information from Marco. > > If this is correct, > > It is not. > Really?, that would be good news. > > then this is the third such self-incompatible kernel change in the > > last few months. The two others were a security patch that broke > > modules compiled from the same kernel source (due to careless touching > > of header files), and an ALSA user space library that could not > > simultaneously support kernel 2.6.8 and kernel 2.6.10. > > These were "incompatible" changes that happened to kernel.org kernels? According to very public messages on the Debian mailing lists at the time. The first was the fix for an issue in the tty or vt code which caused a large number of versioned kernel symbols to change, due to changing a structure related to the task structure. This had the unfortunate side effect that modules built from 2.6.8 sources before the patch would not load on a kernel built after the patch and the other way around. This broke installing Debian with a 2.6.8 kernel when the boot and root disks were not exactly the same age. This could have been avoided by making the patch slightly larger, or by warning distros so the new kernel could be protected with a different revision in uname, and thus the name of the subdir below /lib/modules/ . The second was a change in ALSA, somewhere 2.6.9 or 2.6.10, which caused the proper configuration values for a widely used sound card to be different depending on the kernel version. This in turn meant that when a 2.6.10 compatible set of user space ALSA tools got packaged, this widely used sound card stopped working for users running the 2.6.8 kernel. > Have you told the kernel developers about them? > Presumably the people closer to these issues did so through the usual channels. I merely noted the incidents and stuck to 2.4.x until the dust settled. -Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
