> >>>I tried that change in linux-2.6/fs/lockd/mon.c
> >>>
> >>>static struct rpc_procinfo nsm_procedures[] = {
> >>>[SM_MON] = {
> >>> .p_proc = SM_MON,
> >>> .p_encode = (kxdrproc_t) xdr_encode_mon,
> >>> .p_decode = (kxdrproc_t) xdr_decode_stat_res,
> >>> .p_bufsiz = max(SM_mon_sz, SM_monres_sz) << 2,
>
> Will work since both SM_mon_sz and SM_monres_sz are compile-time
> constants, not true?
>
> [ ... snip ... ]
>
>
> So...
>
> The patch actually modifies the macro's last line in kernel.h
>
> - _x < _y ? _x : _y; })
> + __min(_x, _y); })
>
> But what I am unable to understand is why is the compiler unhappy with
> * _x < _y ? _x : _y; })*
>
> and happy with new macro been called internally *__min(_x,_y);*
Ok, _now_ I see. I used the
xdr4.c but mon.c seems happy with the new
max() (as you asked). Can only say: dunno. It should not make a difference.
Richard Knutsson
Richard,
I believe Vignesh had confirmed the patch.....
So now this is going to be crazy we have 3 pairs of min/max to deal with
min()/max()
min_t()/max_t()
__min()/__max()
Can the first one be considered *redundant*
I was wondering that from the very first. calling MACRO(MACRO()) somehow is dirty....Any suggestions !!