Make Linux and Posix eventfd functions configurable

[patricoferris]

This is a very niche request, but I need to be able to control how the Linux and Posix backends for Eio create their "event FDs". In particular, I need to be able to ensure that they are safely moved to higher FD numbers in msh, a shell I am writing. This is a fairly common thing to do in shells (e.g. dash savefd).

[talex5]

I suspect this isn't needed (and you'll have the same problem with anything else that allocates FDs).

It might be better to treat the user-facing numbers as labels that can map to any FD internally. e.g. when the user says date >&3 it means that date's stdout should be connected to the FD that the shell script calls 3, but the shell might refer to that as FD 5 when talking to the kernel.

[patricoferris]

Thanks @talex5!

I suspect this isn't needed (and you'll have the same problem with anything else that allocates FDs).

True, but I think this is for shells to worry about and in practice not too many things need to do that (right now, I have a mostly working POSIX shell and only Eio is doing this).

It might be better to treat the user-facing numbers as labels that can map to any FD internally. e.g. when the user says date >&3 it means that date's stdout should be connected to the FD that the shell script calls 3, but the shell might refer to that as FD 5 when talking to the kernel.

My concern here is that this might break the semantics in some subtle ways. For example, consider this script:

#!/bin/sh

exec 4>log
ls -la /proc/self/fd

Whilst there might be noise in /proc/self/fd I think most would expect 4 to be mapped to log? Maybe this doesn't matter so much, I haven't quite thought through it all yet.

[talex5]

In your example, ls is listing its own FDs and will have the expected numbering, but yes /proc/$SHELL/fd would be different.

One other approach, that doesn't involve changing Eio's API, would be to open /dev/null and dup it a few times to reserve some FDs, then initialise Eio, then close them again.