Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> I would not use ENOTTY for F_BELOW on !DIR, maybe ENOTDIR is
> better.

From errno(2) manpage:

     20 ENOTDIR Not a directory. A component of the specified pathname
             existed, but it was not a directory, when a directory was
             expected.

F_BELOW is fcntl(2).

     int
     fcntl(int fd, int cmd, ...);

But there is no pathname.  Yes it is partly vague, but then grep the whole
tree for ENOTDIR and always anticipates a pathname at a higher level.

At least check what the errno means, don't go by memory.

I may use the generic EINVAL and add an additional reason in the
manual page.  ENOTTY falls into the generic catagory, but I'm willing
to go even more generic.


Anyways, this is a such tiny component of the proposal.

I honestly think it is embarassing that the outside development
community expresses such disinterest in the future of Unix, and this is
the most significant discussion.  It is pretty obvious when Linux adds
openat2(2) with a featurechest of wishless items noone can combine
constructively.  Each addition probably has one piece of software using
it, and thereby placing pressure on the kernel to be bug-free for each
of those specific features.  Subtle, reuseable components are supposed
to be the norm.

This feels like a repeat of the Unix wars when "thoughtless additions
without design" were added due to overly competitive practices.

It is a community failing.  It's back to short-term business practices.


If noone wants to experimentaly use this, I'll throw it into the trashcan.