On Wed, Oct 12, 2011 at 5:56 PM, Philippe Gerum <[email protected]> wrote: > On Wed, 2011-10-12 at 16:22 +0200, Gilles Chanteperdrix wrote: >> On 10/12/2011 04:03 PM, Thomas De Schampheleire wrote: >> > Hi, >> > >> > On Mon, Sep 26, 2011 at 11:46 PM, Gilles Chanteperdrix >> > <[email protected]> wrote: >> >> On 09/19/2011 10:45 AM, Thomas De Schampheleire wrote: >> >>> Hi, >> >>> >> >>> On Mon, Sep 19, 2011 at 9:42 AM, Ronny Meeus <[email protected]> >> >>> wrote: >> >>>> On Mon, Sep 19, 2011 at 9:25 AM, <[email protected]> >> >>>> wrote: >> >>>>>> From: [email protected] >> >>>>>> [mailto:[email protected]] >> >>>>>> On Behalf Of Philippe Gerum >> >>>>>> Sent: Sunday, September 18, 2011 5:37 PM >> >>>>>> ... >> >>>>>> Actually, we used to follow strictly the pSOS convention for this >> >>>>>> until >> >>>>>> 2.4.x, at which point we moved to name strings precisely because >> >>>>>> non-null terminated char[4] arrays would break the registry, the way >> >>>>>> you >> >>>>>> described. This is one of the rare situations where mimicking a >> >>>>>> useless >> >>>>>> limitation of the original API may be challenged by usability concerns >> >>>>>> in the new environment, and usability won in that case. The problem >> >>>>>> mostly comes from the fact that char[4] is automatically convertible >> >>>>>> to >> >>>>>> const char *, so we have no warning/error leading us to check the >> >>>>>> potentially problematic call sites. >> >>>>>> >> >>>>>> The concern about moving back to char[4] arrays - null-terminated if >> >>>>>> shorter - is for people who currently assign strings longer than 4 >> >>>>>> characters to name their objects. What could be done, is providing a >> >>>>>> build switch to select the accepted input, like >> >>>>>> --disable-psos-long-names to turn on char[4] interpretation. >> >>>>> >> >>>>> While I would prefer the switch --enable-psos-long-names, this sounds >> >>>>> okay to me, the more so as it is more than people who use the pSOS >> >>>>> skin without obeying pSOS rules deserve. >> >>>>> -- >> >>> [..] >> >>>>> >> >>>> >> >>>> Another option would be to introduce a run-time switch. >> >>>> The default behavior could be that long names are supported and if the >> >>>> "enable_short_names()" function is called, all names will the cut at 4 >> >>>> characters. >> >>>> The advantage of this dynamic switch is that different applications >> >>>> using the same library can use the mode they prefer. >> >>> >> >>> I would also be in favor of a runtime setting, rather than a >> >>> compile-time one. One cannot assume that all PSOS applications on a >> >>> system follow the same rules, or that there cannot be a mix of >> >>> 'legacy' PSOS applications and 'xenomai-style' ones. According to me, >> >>> a library should support all these uses. >> >> >> >> Hi, >> >> >> >> here is a patch which truncates identifiers to four characters and >> >> terminates them by a '\0' character, in order to avoid the issues at >> >> the origin of this thread. The patch also adds a variable >> >> "psos_long_names", 0 by default, which may be set to a non-zero value >> >> to enable the old behaviour (assume the identifier strings may be >> >> longer than 4 characters and are already null terminated). >> >> >> >> Could someone with the issue test it? >> > >> > It seems this slipped through the cracks, my apologies. We already >> > implemented this ourselves similarly, we didn't actually test your >> > patch so far. >> > >> > Now that we're trying out xenomai-forge, I ported this patch and tested it. >> > There are a few problems with it (also relevant to cobalt xenomai) >> > >> > * a bug in __psos_maybe_short_name so that only 3 characters are >> > retained (see below) >> > * the call to __psos_maybe_short_name also needs to be done in the >> > _ident functions >> > * although we don't use it, I think the pt_create and pt_ident >> > functions also need to be adapted >> > >> > Moreover, I wonder why you have made psos_long_names an exported >> > global variable. Sharing variables between two different pieces of >> > software is not very clean. I think it would be nicer with a get/set >> > function. >> >> Thanks for the review. The exported global variable is the simplest >> possible and sufficient implementation of this feature. You risk having >> a hard time convincing us otherwise. > > Ack. > >> >> -- >> Gilles. >> >> _______________________________________________ >> Xenomai-help mailing list >> [email protected] >> https://mail.gna.org/listinfo/xenomai-help > > -- > Philippe. > > > > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help >
Another simple solution would be to have a function available to set this mode. In that way the internal implementation can be changed without impact on the applications. I think it is always good to use a setter since this is more future safe. We also implemented the function tm_getm to get a timestamp in an efficient way. This function was available in the xenomai-2.5.6 (as a kind of extension on the psos interface) but in missing in the force version. I hope this code will also be in the patch that Thomas will send. Ronny _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
