Hi Dmitry, Dmitry Adamushko wrote: > Hello Jan, > > well, take it with 2 huge grains of salt.. it's even not compile-tested :-)
Yeah, that might explain while already trying to parse it manually failed: What is xnintr_sync_stat_references? :) > > I don't think I've got it really nicer than your first patch.. the only > additional point is that > 'prev = xnstat_get_current()' reference is also tracked as reference > accounting becomes > a part of the xnstat interface (not sure we do need it though). Mind to elaborate on _why_ you think we need this, specifically if it adds new atomic counters? I'm too lazy looking for the probably valid reason on my own. Apropos atomic use counters: already considered all memory barrier issues for your locking scheme? > > Well (#2), I have to say that the whole intr subsystem looks not that nice > (maybe partly due > to being overloaded with xnstat details).. so I think, it'd require a closer > look. Let's get it right first, then think about aesthetic or even concrete optimisations again. > > Anyway, here is what I've got out of your patch so far.. the main issue is > whether we go this way > or it just makes things even more uglier. Again, correctness, race-avoidance worries me first right now. > > (a side effect : I transformed xnstat_* macroses into 'static inline' > function.. I guess, this way it's a bit nicer) Uhh, be careful, I burned my fingers with similar things recently as well. You have to make sure that all types are resolvable for _all_ includers of that header. Otherwise, I'm fine with cleanups like this. But I think there was once a reason for #define. Thanks, Jan PS: Please note my latest refactoring check-in to SVN, touching stat.h.
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core