here's the first pre-release of 2.4.34. Nothing really serious, I onlymerged the previously queued patches. Pete Zaitcev has issued a bunchof USB fixes in usbserial and also more general locking to fix a bugwith some usb-storage devices such as the TEAC CD-210PU. We only knowthat it fixed the problem for the reporter, but this should definitelyget more testing. There's also an interesting NFS fix from Jeff Layton.

Some people have asked me what the hotfix tree will become. It willstill exist in its current form to provide fixes for older versions.But I will create a 4 digit version for latest release because peoplegot used to this since the 2.6-stable branch. The version suffix inthe hotfix will still reflect the equivalent head level (eg: hf33.1will equal 2.4.33.1). I will prepare one soon with the most importantof the few bugs below.

Also, I've been asked by several people to consider merging MikaelPettersson's gcc4 patches :

I've been reluctant at first for the usual reasons : "who has a 2.4distro with gcc4 ?", and after recalling all the trouble Marcelohad to deal with during the gcc3 update. But after discussion withsome people, I realized that the problem is not here, it's for thekernels those people have to maintain for other systems (eg: servers,firewalls, etc...) and which they suddenly cannot build anymore afterthey have updated the distro on their desktop PC.

With Mikael's help, I've carefully split ant reviewed ALL the fixes,and carefully logged the error they each fixed. Also, warnings anderrors have been split. I must say that those fixes mostly consist in :

Since most of them were sleeping bugs waiting for someone to wakethem up, I considered it was worth merging them provided that weobserve no regression. So I have created a separate tree for itthat I will merge into mainline in a few pre-releases if we don'tencounter any problem.

What has been tested right now : - make allmodconfig on x86 with gcc-2.95.3, 3.3.6 and 4.1.1 => builds OK

- make "reasonable" config on x86-smp with all 3 compileres => builds and boots

- make "reasonable" config on x86_64 and PPC with gcc 4.1 => builds and boots

- make "reasonable" config on sparc64-smp with 3.3.5 and 4.1.1 => builds and boots

- build debian's sparc32 kernel with 4.1.1 => builds

I have no problem not supporting some rare architectures, andpeople who use them are welcome to port them. It's quite easy,it took me less than two hours to fix both sparc32 and sparc64.

Also, I have checked that the patches were really not intrusive.I could apply the following cumulative external patches on topof a gcc4-patched kernel without even one reject :

Therefore, I consider the drawbacks almost inexistent (mostlysome work on our side) compared to the advantages of gettingcleaner code and making the job easier for the users tomaintain existing setups.

Feedback welcome, particularly on sparc/sparc64 where it isdifficult to build a full-featured kernel, and therefore I'msure there might still be a few corner cases.Thanks for your patience during this long mail :-)