User Details
- User Since
- Jun 2 2014, 4:20 PM (469 w, 4 d)
Today
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...
Yesterday
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.
Thu, Jun 1
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.
Wed, May 31
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.
Tue, May 30
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.
Mon, May 29
Fri, May 26
Thu, May 25
I believe all of these are good to remove given the shakiness of their crypto underpinnings
Wed, May 24
Tue, May 23
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...
Nice.. there was a freebsd-version phabricator or pull request that can use these REs instead of the badly broken ones there now.
.if defined(KERNBUILDDIR) .PATH: ${KERNBUILDDIR} CFLAGS+= -I${KERNBUILDDIR} .for _src in ${SRCS:Mopt_*.h} CLEANFILES+= ${_src} .if !target(${_src}) ${_src}: ln -sf ${KERNBUILDDIR}/${_src} ${.TARGET} .endif .endfor .else .for _src in ${SRCS:Mopt_*.h} CLEANFILES+= ${_src} .if !target(${_src}) ${_src}: :> ${.TARGET} .endif .endfor .endif
Ok. A comment about why is good for me.. I should have looked more deeply. Thanks @sjg...
Mon, May 22
Sun, May 21
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
Sat, May 20
I'm not sure I like this... I'm not a fan of disabling warnings since it could hide other issues that creep in...