So.. looks good to me...
It would be awesome if we could automatically detect this quirk... maybe if the probe works turn the rest off? If you are up for trying that...
If not, this can go in as is...

Though thinking about it, one could likely make the same argument as '88 and say this is existing behavior.
If you'd agree with that, then this is fine and we'll look at making things better.

I think we have a bug with this, which I think we can fix as I suggested. I don't think that spa_name is ever change once it's cerated, so I think at least the error message is OK, though it doesn't specify which dataset failed.

Since it has ioctl definitions, this is correct since you aren't supposed to include ioccom.h in user code.

I have a bunch of silly style things that my automated script catches. Please consider fixing them.

I like it. 1 down, 9 to go to make Robert happy :)

I think this approach is an innovative way to cope with things.

So I think this is a great next step.
I'd love gfx to be 100% optional, but there's still some interdependencies with lua and 4th that make that much harder than it needs to be.
It might also be better to move the framebuffer stuff more into vbe.c since that might allow fewer ifdefs, but I've not delved enough to know if that's really a good idea.

In D38459#918469, @kib wrote:

In D38459#918467, @imp wrote:

I have code that automatically translates new system calls between host/target for bsd-user (though I'm not quite ready to commit it).
ioctl is possible, but has a lot more exceptional cases so is harder to do automatically. There's no automated annotation like there is for system calls.
The 'generic interfaces' require that I go and create annotations for each of the 'op codes' in that, because that doesn't exist in our current annotation.

So having a few extra system calls means they will be annotated and my job of getting it to work in bsd-user and others wanting to do automatic translation is easier.

For system calls you do need annotations, you cannot properly understand the purpose of any pointer passed to syscall otherwise. Is it in, out, in/out, or even just an abstract address like mmap/munmap/madvise arguments?

I'd think that doing a vendor branch with OpenBSD as the upstream might be ideal.
This code seems mostly fine, though, and I'm generally on board with the idea.

Sorry I missed this, but we should just remove this entirely from here. It duplicates info elsewhere. I'll take care of doing that.

I have code that automatically translates new system calls between host/target for bsd-user (though I'm not quite ready to commit it).
ioctl is possible, but has a lot more exceptional cases so is harder to do automatically. There's no automated annotation like there is for system calls.
The 'generic interfaces' require that I go and create annotations for each of the 'op codes' in that, because that doesn't exist in our current annotation.

I believe all of these are good to remove given the shakiness of their crypto underpinnings

I like it. But let's get Andy and kib to sign off on it too...

Your conclusion is valid only for meta mode. For non-meta mode, beforedepend is always buiilt before beforebuild, even if you aren't generating the .depend files. So your logic doesn't match the code, and having an expliict comment about why both isbetter. And that disccitnction should be exxplicitly called out because otherwises it looks redundant to people that know the code and they might remove it if the justistifcaion isn't there with specificity (and not thte logical conclusion, but the actual implementation). It tripped me up and I've been looking at this stuf for 20 years...

In D40219#915745, @tsoome wrote:

hm, do we actually need this preprocessor #if statement?

Nice.. there was a freebsd-version phabricator or pull request that can use these REs instead of the badly broken ones there now.

Ok. A comment about why is good for me.. I should have looked more deeply. Thanks @sjg...

In D40191#915026, @hselasky wrote:

@imp : Get me right: Maybe I need to += them to a new variable?

When you have "beforedepend:" inside a .if conditional, is that respected?

What I meant to code is:

When these files are needed, assym.inc and offset.inc, they need to happen beforedepend and beforebuild.

There is no problem when using -j1 . I only saw this occasionally when using -jXX .

In D40191#915079, @kib wrote:

Which modules need .inc files? For amd64, I cannot think about any except efirt.ko and might be linux.ko. You incur the overhead to generate the files to all modules, from my reading.

I'll have to study this in detail... it's a bigger change than I thought it would be...

It would be better if we depended on the header files directly... but if these really are files otherwise not mentioned in the build system and are purely a side effect of the o creation then this is goid.

Do you really need both? Before depend is how we do all the other ones like this... unless something has changed that I missed

In D40177#914817, @jfree wrote:

In D40177#914781, @imp wrote:

There's a general preference to include sys/_types.h instead of sys/types.h

It looks like including sys/_types.h does not define types like uint32_t and uint64_t. I still get compilation errors for every file in this review when replacing sys/types.h with sys/_types.h.

I'm not sure I like this... I'm not a fan of disabling warnings since it could hide other issues that creep in...