Release Candidates :: DSL v4.0 alpha1

After reading articles and posts from Linux kernel developers, I think I am about to go mad.

First we have Con Kolivas, who claims 2.6 Kernel development favors servers and/or huge machines not at all typical of real world desktop users. Then we have the announcement from Willy Tarreau on kernel 2.4.35, in which he states, no backports to support newer hardware, laptops, etc will be accepted. That kernel 2.4 is really for servers and firewalls. He suggests that desktop users go to kernel 2.6.

=> <=

Apparently, we are experiencing the lack of backports to the 2.4 kernel with both SATA and ipw2200.

And now with the 2.4 maintainer proclaimming no such backports will be accepted. Seems I have been toling away for very little forward progress in advancing hardware support with a newer kernel.

Someting to think about.

Con Kolivas on 2.6 Kernel

Willy Tarreua on the 2.4 Kernel

Quote

Apparently, we are experiencing the lack of backports to the 2.4 kernel with both SATA and ipw2200

Not to mention bcmxx, cpufreq, drm/i915 and uvc...

There maybe a chance for drm/i915 if I can figure out how to make git use mesa/drm from two months ago and recompile the kernel with CONFIG_X86_CMPXCHG set.

There's no confusion. I can empathize with Con Kolivas' feelings, but has he been able to substantiate that his patches are improvements in how 2.6 works on desktops? I hate to say it sounds like sour grapes, but it sounds like sour grapes.

As for 2.4 development, what I read and how I intepreted it's not quite so dire:

Quote

I'm open to merge the small updates required to maintain such systems running (eg: PCI IDs and such), but I will generally refuse all patches which add support for new desktop or notebook-specific hardware, unless the people present very convincing arguments.

IOW, older hardware will continue to be supported. If you make a convincing case, changes can be made for *NEW* HARDWARE AND *LAPTOP* SUPPORT. That's not unreasonable. You don't need to backport support for every piece of *new* hardware. Improvements can continue to be offered for older hardware.

I don't blame him. Look at all the dross being thrown into both kernel streams as it is. How the hell does supporting trivial stuff like "splash" improve interaction between kernel and hardware? All it does is mask it! That kind of crap belongs in userspace (and in operating systems that hide everything else like code from users), not built into a kernel or supported by it (compare LOC of Linux 2.6 and Linux 2.0 and then Minix 3). How long has DSL resisted updating kernels and even once reverting to an older kernel after updating? Isn't part of the reason size of newer kernels?

From my perspective, it's only logical that kernel development will move beyond supporting older architecture like i386 and i486 (as there are fewer and fewer of those machines) and that lines have to be drawn between what's supported in 2.4 and 2.6 just as there were when previous kernel lines were deprecated. There's a limit to how many new features should be backported because it's unlikely and impractical.

As far as Kolivas goes, the basic architecture support is the same on an i686 whether it's used in server or on a desktop, and the kernel can be custom configured to suit needs whether it's desktop, cluster, or in an embedded device. It's the job of a distro to make Linux suitable for specific uses (desktop, server, embedded, cluster), not of the kernel development team. Kernel developers can make the job easier of those configuring kernels for particular uses.

Who wins? Desktop distros? Linux doesn't have much marketshare in desktops as it is. It's also the view of the kernel development team that the desktop isn't the future; the desktop is rapidly becoming the past as it increasingly gives way to mobile devices. I'm sure there are mobile device vendors (like Palm!!) who wish more of their own submitted patches were included to make their jobs easier, too. The place where Linux actually prevails is in servers. That's where the biggest demand is and remains for kernel development. That's why there's a bias towards server performace. I disagree with Kolivas, though, that it's exclusively at the expense of desktop or mobile performance and that it's an either-or situation. All he's done by quitting is make it more difficult for his position to prevail.

I'll try to add some positive info to this post.

DSL 4.0alpha1 DOES boot with the "sata" code and detect my sata_nv controller and two SATA disk drives.

I added a IDE DVD-ROM drive to make it easier to test. I should have done this earlier so that there aren't too many variables at the same time.

When it boots, after the messages:

Checking for SATA....
Loading sata_nv.o...

Then, the word "Done." is written on top of the "Loading sata_nv.o..." line. It would be nice if the "Done." doesn't have a carriage return in front of it.

Then, it turns on dma, detects the ide cd on /dev/hdc, and boots up correctly.

Key, I think that your motherboard is also based on an Nvidia chipset, so you may be able to see the:

Loading sata_nv.o...

message before the "Done." message overwrites it, and dsl fails to find the KNOPPIX image on the CD.

If you see that sata_nv.o message, then you could use the knoppix cd to copy the dsl image to one of your SATA drives and it will be able to boot that way. It won't be as easy as using a live cd, but you could try out the other new features of dsl-4 that way.

Another thing that worked is the Nvidia gigabit ethernet with the forcedeth driver, so PXE booting might be another way to get it running.

I should have explained more about why I added the link about the 2.6 version of the drivers. It had an example of adding the atapi_enabled=1 option for the libata module to an initramfs, and I don't know how that is normally done under Debian. I thought that this might be an example of how to do that. Since that page is about 2.6 kernel versions and the Intel SATA driver, it wasn't a good choice to use it. My problem was that I couldn't get any hits on google for 2.4.34 kernels with SATA controlling an ATAPI device.

Oh, I forgot to mention that I tried all of those hdc=noprobe combinations, and none of them helped.

Con did make some good points about why it's at the expense of desktops.

For configuring your kernel for your needs, you cannot select the cpu scheduler (can in -mm..) like you can select the i/o scheduler. Thus the one sharing cpu power is always geared for servers. The -ck patchset added a fairer cpu scheduler, better for desktops..

-- probably out of topic, but I did change to kernel 2.6.20.14 when I turned DSL 3.4 into a customized webkiosk for nipun.. I had to, besides compiling and moving to right places, edit linuxrc and later init scripts mostly for module names, but also some other things. Generally it went quite painlessly..

Next Page...
original here.