DragonFly submit List (threaded) for 2008-03
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: [patch] clear direction flag for signal handlers
On Wednesday 12 March 2008, Aggelos Economopoulos wrote:
> On Wednesday 12 March 2008, Matthew Dillon wrote:
> > :only differs in some code block and that block can be cleanly turned into a
> > :function, do just that. Or, for example in sendsig() define a macro
> > :is_vm86(regs) (or whatever), only define it as 0 in the appropriate vkernel
> > :include and you're done. The compiler will just throw away the dead code, no
> > :#ifdefs involved. Etc.
> >
> > Heh. No way. A macro used for conditional compilation is really
> > no different from an #ifdef. We're definitely not going to do
> > that.
>
> But it is different.
>
> compare
>
> if (has_vm(regs)) {
> code;
> }
>
> with
>
> #ifndef _KERNEL_VIRTUAL
> if (regs->tf_eflags & PSL_VM) {
> code;
> }
> #endif
>
> In the first case you have to parse one conditional, the same conditional that
> was there before vkernel was added to the tree. The macro just serves as an
> optimal __predict_false(regs->tf_eflags & PSL_VM) that effectively does
> __assume_false() and allows the compiler to remove the code at compile time.
> There is no extra logic.
>
> The second case adds an extra conditional that is evaluated at a different time
> and uses different syntax than the rest of the code. Repeat a couple of times
> (with #else too), intersperse some C conditionals and you end up with the kind
> of mess that rightly gave #ifdef its bad name.
If it's not too much trouble, could you clarify exactly what you don't like
with this concrete example? I think my explanation of why this is not
equivalent with an #ifdef is reasonable.
Thanks,
Aggelos
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]