OSNews

Interesting...

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."

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.

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.

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.

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?

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.

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.