Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Kernel page
| |||||||||||||
3.12 merge window, part 2
As of this writing, nearly 8,500 non-merge changesets have been pulled into
the mainline repository for the 3.12 development cycle; almost 5,000 of
those have been pulled since last week's
summary. The process was slowed
somewhat when Linus's primary disk drive failed, but not even hardware
failure can stop the kernel process for long.
This development cycle continues to feature a large range of internal improvements and relatively few exciting new features. Some of the user-visible changes that have been merged include:
Changes visible to kernel developers include:
The closing of the merge window still looks to happen on September 15, or, perhaps, one day later to allow Linus to get back up to speed after his planned weekend diving experience. (Log in to post comments)
3.12 merge window, part 2 Posted Sep 12, 2013 8:37 UTC (Thu) by jnareb (subscriber, #46500) [Link]
>* The direct rendering graphics layer has gained the concept of "render nodes," which separate the rendering of graphics from modesetting and other display control; the "big three" graphics drivers all support this concept. See this post from David Herrmann for more information on where this work is going.
In linked post there is said that render-nodes are not bound to a specific card and that driver-unspecific user-space (which can be relatively unprivileged) should not and can not ask "how do I find the render-node for a given card?”.
But I wonder, as there are hardware where there are graphics cards with different capabilities (e.g. Tesla for GPGPU, GeForce for display), would you be able to ask for said capabilities to select render node?
3.12 merge window, part 2 Posted Sep 12, 2013 14:13 UTC (Thu) by lambda (subscriber, #40735) [Link] I think that this comment from the blog post answers that question: With custom heuristics. There is currently no notion of “speed” in the DRM API, but afair Ian was implementing an OpenGL extension to give some useful information to the user. So you could just open all render-nodes, see what they provide and then use them. Basically, the answer is that you open up each render node, query it for its capabilities, and then use the appropriate one for your task.
3.12 merge window, part 2 Posted Sep 12, 2013 14:18 UTC (Thu) by mirabilos (subscriber, #84359) [Link]
Feeding the device tree is GOOD because it’s still usable to separate a class of machines from another class of machines, aids mixing with other entropy sources (is a source of more unruliness) and, to be frank and saying it with the words of the developer of RANDOM.SYS for MS-DOS: “Every bit counts.”
For that matter, MirBSD feeds the link-layer addresses of network interfaces into the pool in the code that attaches them to the global list of interfaces.
3.12 merge window, part 2 Posted Sep 13, 2013 18:09 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] For that matter, MirBSD feeds the link-layer addresses of network interfaces into the pool in the code that attaches them to the global list of interfaces. Linux does that too.
3.12 merge window, part 2 Posted Sep 13, 2013 18:36 UTC (Fri) by mirabilos (subscriber, #84359) [Link]
Ah good, then that’s a non-issue.
(I was responding to the lladdr being mentioned explicitly.)
3.12 merge window, part 2 Posted Sep 13, 2013 3:09 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> The netfilter subsystem supports a new "SYNPROXY" target that simulates connection establishment on one side of the firewall before actually establishing the connection on the other. It can be thought of as a way of implementing SYN cookies at the perimeter, preventing spurious connection attempts from traversing the firewall.
another place this could potentially be really useful is on a load balancer, if the load balancer can avoid establishing a connection to the real server for a short time, it can potentially gather more information about what is happening before making it's decision and connecting to the real server.
for example, if you can hold off until you see the packet containing the URL (or at least the beginning of it), you can direct the traffic to different servers based on what is being requested.
I haven't looked at this feature yet, so i don't know how long the system can hold off on making the connection, but this is an interesting possibility.
3.12 merge window, part 2 Posted Sep 19, 2013 4:43 UTC (Thu) by eternaleye (guest, #67051) [Link]
It's not any sort of general 'delay' - rather, it's a proxy implementation of syncookies.
|
|||||||||||||