Linux Kernel 2.5.1 is Out 306
xise writes: "The next installment in the 2.5 Linux Kernel beta series, 2.5.1 is avaliable at the usual place Linux Kernel Archives. Remember to use the mirrors. You can read the changelog here."
This discussion has been archived.
No new comments can be posted.
Linux Kernel 2.5.1 is Out
Related Links Top of the: day, week, month.
So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand
Changelog for when it get /.ed.... (Score:0, Informative)
final:
- Al Viro: floppy_eject cleanup, mount cleanups
- Jens Axboe: bio updates
- Ingo Molnar: mempool fixes
- GOTO Masanori: Fix O_DIRECT error handling
pre11:
- Jeff Garzik: no longer support old cards in tulip driver
(see separate driver for old tulip chips)
- Pat Mochel: driverfs/device model documentation
- Ballabio Dario: update eata driver to new IO locking
- Ingo Molnar: raid resync with new bio structures (much more efficient)
and mempool_resize()
- Jens Axboe: bio queue locking
pre10:
- Jens Axboe: more bio stuff
- Ingo Molnar: mempool for bio
- Niibe Yutaka: Super-H update
pre9:
- Jeff Garzik: separate out handling of older tulip chips
- Jens Axboe: more bio stuff
- Anton Altaparmakov: NTFS 1.1.21 update
pre8:
- Greg KH: USB updates
- Jens Axboe: more bio updates
- Christoph Rohland: fix up proper shmat semantics
pre7:
- Jens Axboe: more bio fixes/cleanups/breakage
- Al Viro: superblock cleanups, boot/root mounting.
pre6:
- Jens Axboe: more bio stuff
- Coda compile fixes
- Nathan Laredo: stradis driver update
pre5:
- Patrick Mochel: driver model infrastructure, part 1
- Jens Axboe: more bio fixes, cleanups
- Andrew Morton: release locking fixes
- Al Viro: superblock/mount handling
- Kai Germaschewski: AVM Fritz!Card ISDN driver
- Christoph Hellwig: make cramfs SMP-safe.
pre4:
- Jens Axboe: fix up bio highmem breakage, more cleanups
- Greg KH: USB update
pre3:
- Al Viro: more superblock cleanups
- Jens Axboe: more patches for new block IO layer
- Christoph Hellwig: get rid of the old, long- deprecated SCSI error
handling
pre2:
- Greg KH: USB update
- Richard Gooch: refcounting for devfs
- Jens Axboe: start of new block IO layer
pre1:
- me: README references to 2.4.x -> 2.5.x
- Alexander Viro: fix unmount inode breakage, show_vfsmnt cleanup
- Jeff Garzik: fix 8139too initialization
Re:didledididee...two kernels (Score:5, Informative)
Sure is. The kernel sources will untar to different directories based on version (how 'bout that?), so no problem with overwriting your stable ".config".
Anyhoo, after building your new kernel, copy it to the same location as your current kernel, but with a different name. (on Redhat this is
Add a new section that looks like:
image =
root =
label = Linux251 (or whatever)
read-only
Save lilo.conf and run lilo. This will re-install lilo with the new settings. Of course, if you're not using lilo, then cheerfully disregard the above.
On reboot, you should be able to pick from both the old kernel and the new kernel.
As for where the FM is, check out the LILO mini-HOWTO (in
Have fun.
The mirrors (Score:5, Informative)
The proper site for mirrors of the Linux Kernel is here [kernel.org].
Here's a quick link [kernel.org] to those of you looking for US-based mirrors.
-dan
into unix and punk? check out unixpunx.org
Re:2.4? (Score:3, Informative)
The core kernel will remain stable, new drivers will be added where they have no effect on the rest of the kernel - so its the users choice if they want the new drivers or not.
One of these days the ACs will get a clue ....
Re:What are the new things they are working on? (Score:5, Informative)
It seens every top-kernel developer or company has a different aproach, so its not clear which will be the one being picked (prolly a combination of patches)
IBM has a patch to do a per-cpu que of tasks, allowing better scaling of the scheduler. This causes a lot of the task scheduler to be re-written
Alan has a in-between solution with 8 que's (no matter the amount of CPU's), and a small part scheduler rewrite.
Some other ppl have different aproaches to it all, cant remember their perspective on it (check LKM archives if ur interested).
However the main point (as pointed out by alan and linus) seems to be: 99% of the linux boxes out there run only 3 concurent running tasks, so the scheduler has to remain optimized for this situation (!). The current scheduler handles this situation very well. So any updates and fixes are prolly likely to be non-intrusive to the current scheduler
Re:New in 2.5.x? (Score:3, Informative)
Re:Tulip cards - help! (Score:2, Informative)
but I mean... Would it kill you to run 2.4.xx when 2.6 is out? I mean, bugfixes are still being applied to the 2.2 kernel...
Re:2.4? (Score:4, Informative)
The vm change was made because the original 2.4 vm was not performing adequately, and as far as I know the new vm has caused very few problems, but has much better performance. Would you prefer that we all wait 1-2 years before we can use the improved vm in a stable kernel? I'd personally rather sacrifice a few versions of the "stable" branch and get this important change in now. It would have been nice if this was caught before the 2.4 release, but as I said, the number of people running the unstable branch is tiny compared to the number running the stable. Linus has to make a kernel release sometime, he can't just sit and let the same few people test forever, and he sure as hell can't pay huge teams to test each kernel before release. If this is what you want, use the kernel that comes with your favorite distro. These have been tested in this fashion.
As far as the other "HUGE" changes, I'm not sure what you are referring to. Perhaps the addition of reiserfs and ext3fs? They were tested extensively in 2.3, not just added as an afterthought in 2.4.x. They simply were not ready until slightly after the rest of the kernel, and Linus didn't want to wait for them. Once again, should we have to wait years for journaling file systems when they were already very close to being ready? I see no problem with adding them, and if they scare you, just don't use them.
Sure, there have been "server breaking kernel changes", most particularly the umount bug in 2.4.15, but this was due to a relatively small change. These thing happen and no changes to Linus's kernel release practices will prevent them. No one is perfect, and whining about it will not change that fact.
Re:-AC? (Score:4, Informative)
Worse than beta (Score:3, Informative)
Our company just started on the next release of our software, so I feel a bit "in tune" with where the kernel developers are at.
The beginning of a new release should be the place where you make all the hard choices and break things. Then you start putting the pieces together, and if you broke the right stuff for the right reasons, it will be better (but probably less stable) than before. Gradually, you add more and more features, but they don't tend to break things as badly. Finally, you stop adding features, and work on polish.
This is a development kernel, and things are broken because smart people decided to break them. Don't think it's beta. It's not.
Re:Whoa there, cowboy (michael)! (Score:2, Informative)
Maybe only the milestone ones...
Well, to be fair, a ton of the kernel will be re-written by 2.5.2. From what I've been reading at LKML, the block IO layer will have been re-done, and then the new kbuild will start to be integrated (Optional on supported platforms at that point). That's actually some pretty big stuff.
--Josh
Re:New in 2.5.x? (Score:1, Informative)
* a rewrite of the block i/o layer (i.e. how do you access your various disk drives, iirc) to remove some big single lock there that was holding back scalability.
* a rewrite of the driver model that would lead to better dealings with dynamic device configuration (ie. everything would be considered hot-plug), and to better keep track of all drivers used in a machine.
* the removal of old, deprecated code in I/O that is still hanging around.
* a better scheduler to better deal with more than 2/4 CPUs.
* the integration of ALSA (but I could be wrong, there).
The rest would be icing on the cake.
As for an official roadmap, I don't know. LWN did have a special report on the Linux Kermel Summit held earlier this year which could be considered the closest to a roadmap as can be. I think that Linus & Alan (and others, esp. IBM) basically want the Linux kernel to better scale upwards to deal more gracefully with, say, a big f**king Oracle database running on a gazillion processor mainframe.
I hope this helps.
Re:Don't overdo the caution (Score:1, Informative)
Re:This is development! DO NOT DEPLOY (Score:4, Informative)
Re:NTFS r/w (Score:5, Informative)
Re:Don't overdo the caution (Score:3, Informative)
Since it's only been one revision, it can't have destabilized that much.
2.5.1 introduces major changes to the block device layer, a rather crucial bit of code. Bugs in that code might well eat your data. In fact, it's a good idea to put the dangerous changes in early rather than in a late phase of development.
It takes as much work to destabilize a kernel as it did to stabilize it
Absolutely untrue, as any programmer knows. It takes a lot of hard work to make something stable, but it only takes a one-character change at the wrong place to destabilize the system for all users (cf. 2.4.15).
Re:FreeBSD probably has a more sensible policy her (Score:3, Informative)
BSD kernel development and Linux kernel development seem to be examples of two very different paradigms[1]
FreeBSD[2] kernel development, bug tracking and fixing appear to be very formal, resulting in a rather sedate evolution. Linux versions of the same thing, although every bit as centralised as BSD projects (or even more so, because Linus decides what goes into the release), appears to be much less formal--I can find no Linux equivalent of FreeBSD's bug tracking system. [freebsd.org]
The FreeBSD project does also appear to have more rigid project management. It's also much more of a single entity, too. Whereas the Linux kernel project is distinct from the distributions that use it, typically a BSD project includes management of everything from kernel development through package management to documentation, promotion and distribution of source media.
[1] Sorry for dumping the p-word on you without warning there, but I think it's merited in this case [G,D&R].
[2] Taking FreeBSD as an example of a BSD project.