LWN: Comments on "3.12 merge window, part 2"

3.12 merge window, part 2

eternaleye — 2013-09-19T04:43:03+00:00

It's not any sort of general 'delay' - rather, it's a proxy implementation of syncookies.

3.12 merge window, part 2

mirabilos — 2013-09-13T18:36:49+00:00

Ah good, then that’s a non-issue.

(I was responding to the lladdr being mentioned explicitly.)

3.12 merge window, part 2

BenHutchings — 2013-09-13T18:09:25+00:00

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

dlang — 2013-09-13T03:09:15+00:00

> 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

mirabilos — 2013-09-12T14:18:27+00:00

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

lambda — 2013-09-12T14:13:06+00:00

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

jnareb — 2013-09-12T08:37:59+00:00

>* 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?