[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#7239: testbed

On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote:
> On Thu, 19 Apr 2012 14:58:32 GMT, masarati@aero.polimi.it wrote:
>>> I do have a patch+Perl script which wraps all operation(op, rs)
>>> calls, but it doesn't know which ops are "internal".
>> I don't think it's something that can be done automatically. Careful code
>> review and testing would be required.
>>> I want it for the SlapReply cleanup (ITS#6758). The only way to
>>> make a hunt for dirty SlapReplies feasible. I suggested it when
>>> I was doing the cleanup, but IIRC nobody replied - except there
>>> were related complaints that my cleanup was too invasive.
>>> http://www.openldap.org/lists/openldap-devel/201101/msg00039.html
>>> http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt
>>> Anyway, here's me trying agin again:-)
>> Sort of recall it. Well, it looks pretty invasive, indeed. The two
>> things should be kept separate. No preference about the order in which
>> the two changes should be applied. I'm in no hurry to work at internal
>> ops (mostly because I have scarce time for it and I'm worried about
>> possible unexpected showstoppers).
>> Maybe, if all calls for internal operations are wrapped by a macro, then
>> ITS#6758 SlapReply cleanup could be performed just from within that
>> macro;
>> calls that are not judged internal would need to be explicitly wrapped,
>> though.
> No, I meant the opposite: The macroization is done. It could mostly be
> scripted and makes no semantic change unless #ifdef(SlapReply debug),
> which is what the macros were for.


> Figuring out which ops to tag as internal does, as you say, require
> review and testing. And one extra arg to the macros.

How do you suggest to proceed?  I believe using different macros, e.g. 
slap_bi_op_internal, slap_be_op_internal and SLAP_OP_INTERNAL is clearer 
than having an additional 0/1 parameter.  OTOH, adding further 
parameters in the future would be probably easier if we extend your macros.

At this point, we need consensus on addressing ITS#6758 in the first place.


Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano