Weekly Edition
Return to the Kernel pageRecent Features
| |||||||||||||
Quotes of the week
mb() is the new lock_kernel(). Sigh.
-- Andrew Morton
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.
-- Andrew Morton
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.
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(Log in to post comments)
Quotes of the week Posted Oct 25, 2007 9:15 UTC (Thu) by alonz (subscriber, #815) [Link] 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] Yes, I saw that and was quite amused myself.
Quotes of the week Posted Oct 26, 2007 9:10 UTC (Fri) by dberkholz (subscriber, #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] 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] 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] 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] 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 (subscriber, #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/
|
|||||||||||||