DragonFly submit List (threaded) for 2008-03
DragonFly BSD
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


From: Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>
Date: Sat, 15 Mar 2008 19:43:06 +0200

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]