Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was: sendpath()]]

[Mitchell Blank Jr]

Ingo Molnar wrote:
> - probably the most radical solution is what i suggested, to completely
> avoid the unique-mapping of file structures to an integer range, and use
> the address of the file structure (and some cookies) as an identification.

IMO... gross.  We do pretty much this exact thing in the ATM code (for
the signalling daemon and the kernel exchainging status on VCCs) and it's
pretty disgusting.  I want to make it go away.

> - a less radical solution would be to still map file structures to an
> integer range (file descriptors) and usage-maintain files per processes,
> but relax the 'allocate first non-allocated integer in the range' rule.
[...]
> 	fd = open(...,O_ANY);

Yeah, this gets talked about, but I don't think a new flag for open is a
good way to do this, because open() isn't the only thing that returns
a new fd.  What about socket()?  pipe()?

Maybe we could have a new prctl() control that turns this behavior
on and off.  Then you'd just have to be careful to turn it back off
before calling any library functions that require ordering (like popen).

Other than that, I think it'd be a good idea, especially if it could
be implemented clean enough to make it CONFIG_'urable.  That can't
really be fairly judged until someone produces the code.

-Mitch