Quotes of the week

[Posted October 24, 2007 by corbet]

mb() is the new lock_kernel(). Sigh.

So I *really* don't want to throw any stones in a glass house here. Quite the reverse. I'd like to get rid of some of the glass, and replace it with padding. Because you all know we'd all fit better in a padded room than a glass house..

-- Linus Torvalds

I was in bugfix-only mode from a week prior to 2.6.24 release and during the merge window. Partly caused by the already-idiotic amount of stuff we had queued for 2.6.24, partly because we needed to concentrate on stabilising the 2.6.25 patchpile rather than writing new stuff.

And partly to send the signal that rather than beavering away on new features all the time, we should also be spending some (more) time testing, reviewing and bugfixing the current and soon-to-be-current code.

-- Andrew Morton

I don't currently know of any common piece of hardware in use today that is not supported on Linux. And since these vendors do not know, and I don't, I'm asking the world to help out.

-- Greg Kroah-Hartman looks for driver projects

Quotes of the week

Posted Oct 25, 2007 9:15 UTC (Thu) by alonz (subscriber, #815) [Link] (2 responses)

My own favorite for this week was:

--- Thomas Fricaccia >thomas_fricacci >at< yahoo.com< wrote:

> ...
> 
> Since I know that the people behind these security frameworks are serious and
> worthy folk of general good repute,

I make no claims to worthyness, strongly deny being serious,
and challenge you to demonstrate my good repute.

-- Casey Schaufler

Quotes of the week

Posted Oct 25, 2007 17:07 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (1 responses)

Yes, I saw that and was quite amused myself.

Quotes of the week

Posted Oct 26, 2007 9:10 UTC (Fri) by dberkholz (guest, #23346) [Link]

Clearly an attempt to get onto this page. =)

Quotes of the week

Posted Oct 25, 2007 10:56 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (7 responses)

common piece of hardware is a stretch but the resulting Wiki seems to have quickly filled up
with the sort of wacky stuff Alan Cox used to collect.

There are a few items in there which are or were genuinely somewhat popular though, and
hopefully those attract some attention and make their way into a future 2.6.x release.

Quotes of the week

Posted Oct 25, 2007 14:22 UTC (Thu) by iabervon (subscriber, #722) [Link] (5 responses)

The wiki is also pointing out a number of reasonably important devices that can be driven from
userspace but there aren't drivers anywhere. Probably the biggest class is the "phone line
sound cards", which are supposed to be modems but lack an entirely open source daemon to play
modem sounds over them. (slmodem is a mostly-open-source solution, but the codec is
closed-source and doesn't seem to be entirely universal wrt pcm format, and is only i386)

Quotes of the week

Posted Oct 25, 2007 21:51 UTC (Thu) by xav (guest, #18536) [Link] (4 responses)

How about the current generation of graphic cards ?
None of them work, except as glorified framebuffers. You can't drive their 3D engine.

3D engine does not belong to kernel!

Posted Oct 25, 2007 21:55 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

He talked about Linux, not GNU/Linux. 3D engine support should be entirely outside of kernel - it's too big, too fragile and too high-level to stuff it in kernel...

3D engine does not belong to kernel!

Posted Oct 25, 2007 22:24 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, mode-setting *is* going into the kernel, and it's not beyond the 
bounds of possibility that this might involve some GPU bashing.

3D engine does not belong to kernel!

Posted Nov 2, 2007 14:40 UTC (Fri) by siki_miki (guest, #48840) [Link]

Having 3D engine support completely in userspace isn't feasible. At least a small part of it
must be in kernel: buffer memory de/allocation, and command buffer validation and submission
(to prevent deadlocking from userspace etc), probably few other things.

Most of code can be placed in userspace libraries (stuff running on CPU in same thread as GL
program). They do parsing of high level calls (OpenGL), converting it in low level GPU
commands, shader instructions etc. Last step is putting them in a buffer and sending to a
graphic card in one pack (command buffers). This is how DRI works, but also how new Vista
stack works. DRI also takes care of some 3D initialization and does automatic memory
allocation but this all goes over kernel ioctls. (note: DRI2 changes quite a lot here)

Modesetting is currently done from userspace in a very hackish way, but this is not really a
3D engine stuff. Kernel modesetting is hopefully beginning of a solution for long standing
annoyances(e.g. mondesetting flickering) and conflicts between VGA/framebuffer/X/VT
modesetting. It should allow for other-than-Xserver programs to fully use graphic card (in
embedded space for example). It should also allow userspace consoles finally bring end to
horrible VT switch as finally one piece of code will control all modesetting. Also it brings
alternative to linux framebuffer for major graphic cards (advantage is that it'll work with
new memory management), while it will still wrap backwards compatible fbdev API on top of it.

Quotes of the week

Posted Oct 25, 2007 22:01 UTC (Thu) by iabervon (subscriber, #722) [Link]

They're specifically listed as known issues that can't be dealt with in the kernel community,
and outside of the scope of this question.

Quotes of the week

Posted Oct 25, 2007 22:47 UTC (Thu) by fjf33 (guest, #5768) [Link]

My biggest problem is with SD cards. It is really frustrating. But I use my camera to read SD
cards through USB. :(

Quotes of the week

Posted Oct 28, 2007 19:33 UTC (Sun) by oak (guest, #2786) [Link]

When I year ago investigated digi-TV card (DVB-C) support to see which I 
should buy, the actual info was very hard to find (which products are 
supported and whether the support is actually in mainstream distros), so I 
didn't buy any.  I'm not sure whether the situation is much better today:
http://www.linuxtv.org/wiki/index.php/DVB-C_PCI_Cards
http://www.linuxtv.org/wiki/index.php/DVB-C_USB_Devices

Btw. I wondered a bit about the request for "TI OMAP / Nokia N800+N810"  
drivers[1].  AFAIK Nokia has released the sources a long time ago and 
actively pushes them to upstream[2].  Only WiFi is a binary blob, but 
there's some project to write open source replacement and anyway the WiFi 
is separate chip from OMAP according to comments here:
http://www.hanno.de/blog/2007/nokia-n800-my-review-2nd-look/

[1] 
http://linuxdriverproject.org/twiki/bin/view/Main/Drivers...
[2] Check the email addresses on the mailing list since 2004:
http://linux.omap.com/pipermail/linux-omap-open-source/