- It's even more complex than just fixing `open_file()` so that it receives a file name. In other words, your fusing proposal touches two methods instead of just one.
- If we still want to do global refactoring, we can do it in a separate PR. Also see the point below about server/console.c
- There are objects (e.g., `registry`) that have a complex `lookup_name` implementation with *several* early returns. Fusing them will require either duplicating "open_file" code at each return point or factoring out so that we still have separate lookup and open-file.
Yes, you'd have to do some nontrivial refactoring. That doesn't mean it's the wrong thing to do (although it'd be nice to have confirmation that it's the right thing to do).
- It's worth mentioning that, on native, object lookup and file opening is externally completely distinct stage (see `IRP_MJ_CREATE`).
N...ot really, though? IRP_MJ_CREATE only applies to devices, whereas we use this infrastructure for several different object types. Also, IRP_MJ_CREATE does get passed the whole path, and FILE_OPEN vs FILE_CREATE, so I'd say that they're not distinct stages.
After all, the kludgy "create the file object in midst of lookup" thing already has precedent in server/console.c. Introducing one more instance doesn't seem like regression of style, although I could be wrong.
If it has precedent then perhaps this patch is fine, although perhaps we should also not bother delaying the create_pseudo_fd() call like the console does.
It's not what I would do, but that's not saying much.