Posted
by
michael
on Friday July 04, 2003 @03:07PM
from the release-early-release-often-ha-ha-ha-ha dept.

gomoX writes "As seen on C|Net , Linus has announced that the pre-2.6 series will be starting in early July. Despite not having been able to meet the release goal for 2.6 in June 2003, the next stable version is not as far away as you may think. You can take your guess based on the fact there was a 9 month period between first test version of 2.4 and the official release of 2.4.0 on January 2001."

I truly believe the time for linux has come. It has always been stable and powerful (as all you slashdotters already know), but now it is really as easy to use as Windows....I tried Mandrake 7.2 but gave up after 1 month for various reasons. Now I have Mandrake 9.1, and I was very pleasantly surprised how polished it was... and easy to use! It is now my primary OS at home. MS, eat your heart out!

There was some hesitancy, upon the official release of kernel 2.4, based upon some bugs etc...

I'm wondering, does the kernel - generally speaking - get more and more stable. For example, will the first release of 2.6 be more stable than the first release of 2.4. I realise that there are new additions to the kernel, and with that new problems will probably emerge. However, comparatively speaking, does it make sense that the kernel's evolution will lean towards stability with each release in the cycle, or will it generally be unnoticable?

I have absolutly nothing to add of a technical nature to this story, so I will delude you with a rambling trip down memory lane (comprised completly of anecdotes from 2.2).

My first taste of linux was phatLinux on my brand new p2-400 (128MB of pc 100 ram I liked). 3 months later I had built a sub 400 dollar computer to play around with and bought (yes paid money for) Linux Mandrake 6.5 from Wal-Mart. From there I began learning about this kernel thing (and my joys when I found make menuconfig and make xconfig, have you ever tried make config? ewww...) Well that went fine and fun, I added options, made modules all the fun stuff you do, but it was still in the same 2.2 vein that came with mandrake. Then 2.4.0 final was relased and I compiled and installed my first new kernel. Everything was new and faster. DevFS was a godsend, the ppp and bsd compression routines made my modem fast (or somthing I went from 2.5 kb/s downloads to 5-6 kb/s after recompiling). Since then I have also come to love dri, premptive and low latency patches, and all these other backported goodies. I am waiting on 2.6 final before I play with any of the new features (I didn't play with 2.3 or 2.5). Ok I am done. And I didn't even mention Gentoo... oh wait... damn.;)

Nah thats not true, there is a freeze at the end of development kernels.

However you no matter the less right.Why? Because only a few people use uneven series. So they are tested not really well. You can ask people millions of times to test the final 2.5.x releases, they will stay with 2.4.x.

However as soon 2.6.0 is released all will jump of it, and test in broad enviroenment, so it takes some even releases until most issues are done.

It's our social behaviour that defines this reality. Not a way the linux kernel development could improve.

"What about that? Will we be finaly able to switch kernels without a reboot?"

I did that back in the 2.2 days with monte. Later with 2.4 kernels I did a few changes, added a feature I was missing, fixed a bug and such stuff. In case you want to see it. But it was never completely stable and lacked SMP support.

kexec might be a better alternative. AFAIK it is being maintained and might even have made it into the 2.5 kernel.

It was only a couple of years ago that knowledgeable people were calling this idea ridiculous, and giving good reasons, however progress has marched on, and we're actually coming within sight of it. The basic challenges are much the same as for hotplug cpus, hotplug memory, process migration in a cluster, and yes, kexec, all of which are being worked on or already working. So I'll go out on a limb and predict that hot-kernel swapping will be demonstrated during the 2.7 timeframe. It won't be perfect, but such things never are in the first cut.

The thing that makes hot kernel swapping practical is the stable api between userland and the kernel. Big changes there are few and far between, and they can be special-cased.

I think it is safe to say nobody knows if Reiser4 will go into the stock 2.6 kernel, but I think the principals would like it to happen, and depending on how well the Reiser4 beta performs this summer, it should be possible, as long as it does not appear that adding the Reiser4 code would disrupt existing code.

What happened to devfsd and lvm? I know they were talking about replacing lvm, and I was wondering if the new code is in place?Also, I read somewhere that the developers were unhappy about devfsd, since 'nobody was using it'. I'm using it, so I'm hoping they don't remove it.

I've been hearing though other channels that the IDE layer rewrite improves the IDE subsystem to the point where SCSI emulation won't be needed to drive an IDE CD burner. Can anyone confirm or deny this? If so, this will probably become my main reason to switch to 2.6 (although there are quite a few secondary ones too). Thanks linux team (and IDE rewrite folks)!

You are correct in assuming you don't need ide-scsi to emulate a SCSI host for burning cdroms in 2.6, but it has nothing at all to do with the IDE rewrite.

2.6 has support for queueing "generic scsi" commands through the block layer, using the same mechanism and transport as the regular read/write file system requests. So we can overload the sg (scsi generic) SG_IO and provide the same functionality for non-scsi attached devices (such as atapi burners). With a recent cdrecord, you can give the device with -dev=/dev/hdc for instance.

Additionally, cd burning is now zero copy. The user space data buffer is mapped directly into the kernel for the dma operations. DMA is supported on a 4-byte boundary, where 2.4 and previous has required sector alignment (512 bytes) for any atapi dma operations.