This on the other hand bothers me. Maybe my intuition as to what's sensible design is off, but creating an object from lookup_name() feels wrong, especially given that we have to defer creating the fd.
I generally concur. There is precedent too, though: in `console_lookup_name` and `console_server_lookup_name`.
I guess the right solution here is to combine lookup_name() and open_file(),
How do you see it implemented? Shall I combine them in `struct object_ops`, and adjust implementors appropriately?
presumably using OBJ_OPENIF to distinguish the two.
I'm not sure about that.
1. Interposing different semantics to `attr` is in-band signaling. - Note that native ignores `OBJ_OPENIF` entirely IIRC (you can't create a file normally there). If we want to use it for internal purposes, we would want to *special case* NPFS and then filter that flag out. - Also, `open_file` doesn't accept `attr`. Or perhaps, did you mean for me to extend it? 2. If `OBJ_OPENIF` were simply instead a magic value for a new internal parameter, then it would be unnecessary indirection.