Submitted by Linus has announced the release of the 2.6.22 kernel. Much has happened in this development cycle, including the addition of the mac80211 (formerly ‘Devicescape’) wireless networking stack, the eventfd system calls, some new TCP congestion control algorithms, a rewritten CFQ I/O scheduler, a new IEEE1934 (Firewire) stack, support for the Blackfin architecture, the long-awaited IVTV TV tuner driver, and much more. See the KernelNewbies 2.6.22 page for vast amounts of detail, the long-format changelog for even more detail, or the short-form changelog for a (relatively) concise listing of patches in this release.
Running this kernel from torvalds dev tree for a while. They must have cleaned up a bit, i get less gcc warning messages then with earlier versions.
Interesting…
Tons of updates and improvements here. Looks like fan control and sysfs structure is much updated… and that I might leave office with my trusty Z61m a little early today 😉
Kudos Linus & Co!
Best regards,
Shameless freeloader who have yet to file his first kernel bug
Nice, a lot of improvements, some urgently awaited. ACPI got a lot of love and I’m crossing my fingers that hot-docking laptops is now working better.
OTOH, now we have to wait another round for the companies insisting on proprietary drivers for their hardware. Yes, I’m looking at you, ATI and NVidia. The kernel devs around Kroah-Hartmann made you an honest and generous offer ( http://www.kroah.com/log/linux/free_drivers.html ) a few month ago and yet, nothing happened.
What do you mean, nothing happened? Lots of developers and companies signed up. Some drivers are already in the tree (if I’m not mistaken… I think Greg said this himself some time ago… too lazy to look for a reference but I bet you can find it easily yourself) as a result of “Greg’s offer”.
If you mean nothing came out of this from ATI and NVidia… honestly… did you really expect that it would?
Edited 2007-07-09 21:59
It seems like i heard about a dozen companies signed up, many with several devices to support, but that it was still early and only 1 or 2 drivers had been added so far. I didn’t think it was a particularly impressive response, but the devs seemed quite happy with it.
I don’t remember where or when I saw that, though, so take it with a grain of salt.
Edited 2007-07-09 22:01
Why be so negative? I would say it’s early, and ALREADY a couple of drivers are in the tree. That’s a couple more than if the offer hadn’t been made at all. And probably, more are being baked right as we speak.
Edited 2007-07-09 22:14
There has been an awful lot of uptake, especially given that by GKH’s own admission the offer was made essentially as a ‘joke’…
With the new wireless stack I wonder if I will need to reconfigure the way I have been doing wireless on my laptop. I’m one of the lucky people that was able to get the broadcom bcm43xx working without using an ndis wrapper. I have it set up and wrote directions on how to do it, I really hope that doesn’t change or if it did change let it be much easier to do.
“With the new wireless stack I wonder if I will need to reconfigure the way I have been doing wireless on my laptop.”
Wonder if my Ralink 2570 USB device is ever going to be “properly” supported in Linux.
It should eventually make it robust. Fedora 7 has the new wireless networking stack backported to the 2.6.21 based kernel it shipped with and it has been working reasonably well along with the new firewire stack which has also been in Fedora as it originated from there.
I’m not a kernel hacker, nor do I write drivers, but from what I’ve gathered, the new wireless stack provides a universal implementation of a lot of things like MAC, WPA, WEP, and 801.22g. That being said, you don’t have to use the new stack, since the drivers previously written for Linux implement most of this from scratch. Intuitively, I don’t see why the old drivers couldn’t work with the new network stack with a minimal amount of porting. I could be completely wrong on that, though.
I’m already loving the new wireless stack. Of course I’m not reaping any benefits from it yet, but it’s certainly bound to make wireless drivers in the Linux world a lot more sane. It’ll probably also speed up the development of new drivers since there’s a universal implementation of nearly everything now.
Edit: Fixed typos. Need caffeine…
Edited 2007-07-09 15:40
From a coding side, it wouldn’t be too hard. Just change most of the internal functions of the drivers into wrappers that call the new functions built into the new wireless stack.
You have the option of using the bcm43xx driver with either wifi stack; in fact, for now, you’re probably better off using the existing softmac stack. Not all of the chipsets are currently supported to the same extent, under the new stack (in my particular case, the 4311 chipset works beautifully under softmac but they’re having performance and stability issues with mac80211).
I agree with elsewhere. I can’t get my adapter to work with the mac80211 version of bcm43xx. It’s great with softmac.
Note that if you do try it on the new stack, you’ll need a version 4.x firmware; the old stack version only works with version 3.x firmware. So if you want to switch you have to keep switching your firmware out too. Bit of a pain.
the long-awaited IVTV TV tuner driver
Why is there a driver for a TV tuner in an OS kernel?
Do you mean (1) OS = operating system or do you mean (2) OS = open source? Since (2) is not making much sense, I assume (1) and point out the monolithic nature of the Linux kernel.
OS means Operating System; if I meant OSS, I’d say OSS (unless it was a typo and I caught it too late to fix — the miniscule window to catch and fix errors here on OSNews is aggravating).
Also, being a ‘monolithic’ kernel doesn’t mean that drivers have to be put where they don’t belong; that’s just sloppy design. But if Linux has gone so long handling drivers that way, then that flaw will probably continue to cripple driver support — at least not until 3.0, at least.
I’ve seen OS used for both and I admit my inability to read your mind. Sorry.
So you already knew that Linux is monolithic? Why did you ask then? Or was it a “clever” ploy to stage a stab at the Linux kernel? Well, feel free, stab away, but please don’t waste time by staging it.
So you already knew that Linux is monolithic? Why did you ask then?
Just because Linux is a monolithic kernel design does not mean that it has to include every possible thing in the kernel. Things that are bugprone and not essential to the operation of the actual kernel, like most drivers, are the types of things that shouldn’t be included — which is why seeing a TV tuner make it into the kernel surprised me so much.
You have a misunderstanding. Drivers are included in the kernel source, not necessarily compiled in the binary image. Most distros ship with many drivers compiled as modules that load at boot (or not, depending on your modules.autoload config file).
If you opt to compile your own kernel, you can choose to compile-in the drivers or make them modules. In this case, yes it would be silly to compile-in peripheral drivers.
What do you mean? Just because the IVTV TV Tuner card drivers just barely entered the mainstream kernel, does not mean that the Linux kernel did not already contain a lot of different TV tuner card drivers. For example, the bttv drivers that a huge majority of older TV tuner cards use, have been in the kernel since as long as I can remember (could be wrong, but I think it was even in the 2.2 kernels.)
The TV Tuner I have in my HTPC uses the saa7134 driver and it’s built as a module for most any distribution, and is included in the kernel tree as well.
I understand where you’re getting at; I’m sure that these drivers could work in user space, but at the same time, there is a performance penalty for decision.
Now, with that being said, there is nothing stopping some inventive person from creating a userland API/ABI if they feel that ‘large numbers of drivers in the kernel’ could be a risk not worth taking.
Personally, I’d sooner see less drivers in kernelspace – load the very basic in kernel space, load the rest in userl. With that being said, however, if were such a problem it would have been looked at already by someone.
If you find it necessary to fix it up, there is nothing stopping you from doing so.
‘large numbers of drivers in the kernel’
The drivers are most of the times compiled as module and thus only loaded if the corresponding hardware is present. So how could this be a risk?
I am not talking about that.
What I am talking about is that moving non-critical modules into userspace, it should mean a higher level of stability for the system overall.
Does a TV card driver need to be loaded into kernel space? no, it can be loaded into userspace; and if they driver is buggy – worse case scenario, if loaded in userspace, it’ll crash, and its just a matter of restarting it again. Nothing lost.
What I am talking about is that moving non-critical modules into userspace, it should mean a higher level of stability for the system overall.
Does a TV card driver need to be loaded into kernel space? no, it can be loaded into userspace; and if they driver is buggy – worse case scenario, if loaded in userspace, it’ll crash, and its just a matter of restarting it again. Nothing lost
Much unlike windows XP a buggy linux driver seldomly takes the whole system with it.
Which has nothing to do with the task at hand; the issue is userspace drivers – debate as to why userspace drivers are not needed in Linux – given how Windows and numerous other platforms readily support them.
Linux can support them just as easily, in fact there are some active projects like FUSE. If there aren’t a lot of userspace drivers, the only reasonable explanation is that no one sees much of a reason to create them. Probably because kernel drivers aren’t much of a problem in linux, and tend to be fixed almost immediately when they are. If you want to start coding them, I’d certainly support trying to get them into the kernel, but I don’t think it’s really fair to stand by and complain without doing anything. At least not until you can show me a real problem, like a driver that keeps crashing for you that no one will fix. Hypothetical problems aren’t welcome.
In other words, the question isn’t “why doesn’t linux have userspace drivers” it is “why does linux need userspace drivers” and remember that hypothetical problems don’t count much when it would take a lot of effort to fix. Better to focus on real problems, there are certainly enough of them.
Edited 2007-07-11 02:45
“Much unlike windows XP a buggy linux driver seldomly takes the whole system with it.”
I have refrained from modding your post down only because I cant blast it into oblivion. Are you really that clueless or are you trying to be funny? I have been bitten by buggy drivers in the past on Linux, and I know for damned sure that I’m not some edge case here.
The stability of Linux is no less affected by crappy drivers than any other monolithic operating system.
I am very sorry for being so rude, but blatantly idiotic statements irritate the hell out of me.
So in other words, you think that Linux, Windows, and practically every other mainstream OS does things wrong, and you are trying to make a point. Badly…
Things would have gone better if you had just been honest and said “I think Linux should be redesigned as a microkernel, it’s better not to have complex drivers built in.”
“Why is there a driver for a TV tuner in an OS kernel?”
For the same reason there are drivers for printers, scanners, cameras, sound cards, video cards, etc. Linux is a monolithic kernel.
You don’t have to compile it in, you can create a module for loading at any time. It’s very convenient to have so many drivers already in kernel, freshly installed Linux system doesn’t need any additional drivers, as opposed to Windows where you have to download them or look for driver CDs.
I think what he means is: “Why the hell does a kernel have even a tv tuner driver in it?” A just question..
The answer being Linux is a monolithic kernel.
It supports many many many drivers, either as modules or otherwise.
If you don’t like it, don’t compile it in. That’s open source. That’s freedom. That’s the advantage. That’s why people turn into zealots or refuse to run anything NON-OSS – they are used to what is an unprecedented level of freedom and control over their system that most don’t want or don’t understand.
Why is this hard for people to grasp?
People troll that which they do not understand
And a very easy question to answer. It’s for the same reason that in Mac OS X (for instance) you can plug in most common cameras/printers/scanners and they just work. Likewise, in WinXP when I plug in my Canon Powershot digital camera, a wizard pops up and walks me through the extraction of photos.
The idea is to have plenty of hardware support out of the box. The vanilla Linux kernel has all these drivers in the source code distribution. Each individual distro can use them however they want. If you’re building a liveCD you can hand pick your drivers. Oh! A PVR liveCD could use that TV tuner driver!
The idea is to have plenty of hardware support out of the box.
But isn’t packing in drivers and other such software part of a specific distribution, not a kernel used by multiple distros and firmwares?
… I don’t even now why I’m arguing for improving Linux’s architecture anyways. o_o;
Every single distro is going to want to support all the hardware they can, and they’re all going to use the same drivers, so why shouldn’t they all be packed together in one package? It seems like forcing the distros to gather all these drivers together would be a huge waste of resources.
They still can (and do) make occasional changes to drivers by applying patches to the kernel.
Edited 2007-07-09 19:22
@Almafeta:
My last attempt to explain this, hopefully it’ll put your mind at rest.
In order to compile ANY drivers/modules you’d need the kernel headers. That’s why it makes sense to distribute these drivers with the kernel source code, you’re going to need the headers/libs anyways. Not everything under the sun is included, mostly popular hardware such as RealTek network adapters or Adaptec SCSI/RAID controllers because those are things you need at the time of installation or rolling your own kernel.
More specifically about the IVTV tuner driver (since it’s what you initially picked out): http://ivtv.sourceforge.net/FAQ.html
I wouldn’t say that it’s a generic driver, it follows a spec that is supported by at least a few different cards. This reaffirms the idea of wider hardware support instead of saturating the kernel source package with drivers for every make/model.
Lastly, you’re not arguing Linux’s architecture. You’re nit picking about source code distribution.
I think what he means is: “Why the hell does a kernel have even a tv tuner driver in it?” A just question..
Where do you think it belongs, the manufacturer’s website? Then it wouldn’t work out of the box.
It is a driver for a piece of hardware. The kernel uses the drivers for the hardware it detects. Therefore, why wouldn’t all the drivers logically be included in the kernel?
Will wait for Fedora 8. That and the next Gnome + KDE should prove promising
You don’t have to wait for Fedora 8 to get a new kernel. In Fedora, new versions of the kernel are released as updates regularly. 2.6.22 will likely be available as an update within a week or two (after spending some time in updates-testing) for Fedora 7 and maybe even Fedora Core 6.
What would you like to see or what features should Linux 3.0.0 have?
Let me quote Linus <http://lkml.org/lkml/2005/3/2/247> 🙂
“- 2.6.<odd>: still a stable kernel, but accept bigger changes leading up
to it (timeframe: a month or two).
– 2.<odd>.x: aim for big changes that may destabilize the kernel for
several releases (timeframe: a year or two)
– <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
the kernel to be a microkernel using a special message-passing version
of Visual Basic. (timeframe: “we expect that he will be released from
the mental institution in a decade or two”).”
so if he decides to do a 3.0 he will re write the entire kernel and he will use a newer/innovative design for it?
like micro-kernel or hybrid i mean
It’s already a hybrid kernel, or at least close enough that a 2.8 series could be one. But yes, the idea is that a 3.0 kernel would be completely redesigned and built from the ground up, to the point where it would really be a completely different kernel – not really Linux at all. Linus has already said he doesn’t think this will ever happen. At least not within his lifetime.
theres no such thing as a hybrid kernel, its just marketing invented by MS.
Linux can already be considered a hybrid kernel and Linus has some very strong opinions on microkernels (“microkernels are just stupid” is a mild one) 😉
As far as I know, there are no plans for 3.0 whatsoever. Probably we’ll only see 2.6.X for a long time.
Linux needs a new cluster-friendly storage subsystem that manages storage across the cluster in terms of physical “chunks” of contiguous storage. While pages and frames are indexed within each node, logical and physical chunks would be indexed uniquely and consistently across the cluster.
Each logical chunk would be associated with one or more physical chunks, which would consist of mirrored (persistent) and cached (temporary) copies. Storage I/O would operate on logical chunks, and the storage layer would handle the synchronization of physical chunks.
The LVM would offer to abstract a set of logical chunks as a flat logical volume. However, filesystem designers would be interested in operating on the set of logical chunks. They would pack related blocks in the same logical chunk to get high performance on distributed storage. The user may want to set different replication policies for chunks of metadata blocks and chunks of a large file.
Paging would be implemented such that each logical chunk of paging space is owned by a single process. Storage caching would normally be done in terms of logical chunks, creating new physical chunks in memory. Writing to individually cached pages of a logical chunk would temporarily invalidate all of its physical chunks.
This isn’t really a 3.0 kind of change, though. Although it’s arguably far more pervasive than the process-management overhaul that was central to 2.6, a new storage layer would be within the bounds of a 2.8 milestone. Linux has a much more resourceful development community today than it did when the 2.5.x branch was in development, so I think that tackling the storage architecture is a workable goal.
This is a case of the traditional microkernel vs monolithic kernel debate. Both have advantages and disadvantages. While a microkernel seems more elegant and can increase system reliability, it has additional overhead (makes the system slower) – and it harder to develop and debug (Linux being a monolithic kernel helped it shoot passed Hurd – a microkernel, it terms of development progress according to the Hurd developers.)
However, because Linux is OSS, it is inherently modular – with the build script you change almost everything about how the kernel operates, even without actually changing the code. That’s why the same kernel can run on a tiny cellphone and a super computer just fine. Having the source code on hand actually improves the flexibility and quality of the OS that’s why many “pragmatic” people like Linus are also OSS advocates.
Edited 2007-07-11 23:09