ok, i figured out how to test this, and fixed the errors. it's working
on my machine by touching /firstboot. this may be ready for review now.

In D56365#1291416, @kib wrote:

In D56365#1291389, @markj wrote:

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

I cannot find much documentation for O_SYMLINK, it is not clear to me if open(<regular file>, O_SYMLINK) is permitted at all, and I have no good way to test. I would prefer O_PATH | O_NOFOLLOW too.

I read it in the following paragraph from MacOSX open(2) man page:

If O_SYMLINK is used in the mask and the target file passed to open() is a symbolic link then the open()
will be for the symbolic link itself, not what it links to.

For now I left the libc hack in the branch, but lets wait for des@ opinion.

I don't feel strongly about it, beyond wanting the gcc build to work. If @kib and @imp you guys don't agree on the direction here, my inclination is just to leave it as it is after 00dccc3164c6dff38350a1baeeea7238acf2efc3 and move on.

So I approve of this belatedly.

Bump.

The previous version (modulo the mistake) looked better. What's the point in the additional bool? All existing declarations rely on sparse initialization, so would have .cmd_securelevel = 0 always. If you add cmd_securelevel_set, it would be .cmd_securelevel_set = false. Thus, checking .cmd_securelevel_set for being true has no difference to checking .cmd_securelevel to be positive. I'd suggest to just do the securelevel_gt() check unconditionally.

So what's wrong with the #ifdef i386 that we're going to tear down in the near future?
This seems to be way over-engineering a solution to a bogus gcc warning.
I'd really rather have #ifdef _KERNEL around the two sat functions instead of this over-engineering.