@whitequark @raggi @david_chisnall David's approach is extremely appealing because it allows for support to be incrementally added to things rather than requiring an all-or-nothing shift to get the fancier behaviors.
It does have the friction of needing a kernel patch... so even if various kernel projects are willing to pick it up without a lot of deliberation and debate it'd take a while to percolate, but then again the magic of open source is you can actually have experimental kernel patches.
@whitequark @raggi @david_chisnall I think you could actually do a version of this as a driver rather than a subsystem change (so it'd be really easy to build just a single little module rather than having to do a whole kernel rebuild). Basically have the driver just have a couple ioctls where you use the driver fd to invoke the content negotiation actions on a pipe fd you pass in, just one level of indirection.
@swetland @raggi @david_chisnall oh yeah that would work!
@whitequark @raggi @david_chisnall On the userspace side code could try to open /dev/content-negotiation, try the direct ioctls (once they exist), and fall back to good 'ol plaintext if neither are available.
The down side of that approach is that it interacts poorly with sandboxing. Now every process that you might invoke interactively needs permission to access a new path.
