[Xenomai-core] RT-Socket-CAN versioning

[Xenomai-core] RT-Socket-CAN versioning

[Wolfgang Grandegger]

Hi Jan,

currently the RT-Socket-CAN drivers maintains it's own version or 
release number. As RT-Socket-CAN is part of Xenomai, I do not see the 
need for it (and so far I did not update it). What is the intended use 
of "driver_version" in "struct rtdm_device"? Furthermore, there is also
"profile_version" (which does not show up n the Doxygen docu for some 
strange reason). The latter one seems suitable to reflect CAN API changes.

Wolfgang.

[Xenomai-core] Re: RT-Socket-CAN versioning

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Wolfgang Grandegger wrote:
> Hi Jan,
> 
> currently the RT-Socket-CAN drivers maintains it's own version or
> release number. As RT-Socket-CAN is part of Xenomai, I do not see the
> need for it (and so far I did not update it). What is the intended use
> of "driver_version" in "struct rtdm_device"?

Actually, I was thinking about this too yesterday. The idea of the
separate versioning for RTDM drivers is to signal the users if something
in the driver really changed. It's fairly obvious what to do with it for
out-of-tree drivers, but for in-tree it might be worth considering the
policy.

The current model, maintained more or less properly for the existing
drivers, is to increment independently of Xenomai according to major or
minor changes. One may ease this burden for the driver developer by
simply filling in Xenomai's version here. That would just let the
revisions increase on every Xenomai release, even if the driver remained
untouched. The tag would still have a meaning for out-of-tree drivers,
but for in-tree it would be fairly meaningless.

Well, whatever is commonly preferred, it should then be applied
consistently on all RTDM drivers in Xenomai. What are the opinions on
this list (I will comment afterwards)?

> Furthermore, there is also
> "profile_version" (which does not show up n the Doxygen docu for some
> strange reason).

The automatic update from the latest SVN must be broken on
www.xenomai.org, there is more stuff missing.

> The latter one seems suitable to reflect CAN API changes.

Exactly. That's why I incremented that in SVN trunk's rtcan.h. A correct
profile version is definitely a must to let applications handle relevant
changes.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Re: RT-Socket-CAN versioning

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Wolfgang Grandegger wrote:
 > > Hi Jan,
 > > 
 > > currently the RT-Socket-CAN drivers maintains it's own version or
 > > release number. As RT-Socket-CAN is part of Xenomai, I do not see the
 > > need for it (and so far I did not update it). What is the intended use
 > > of "driver_version" in "struct rtdm_device"?
 > 
 > Actually, I was thinking about this too yesterday. The idea of the
 > separate versioning for RTDM drivers is to signal the users if something
 > in the driver really changed. It's fairly obvious what to do with it for
 > out-of-tree drivers, but for in-tree it might be worth considering the
 > policy.
 > 
 > The current model, maintained more or less properly for the existing
 > drivers, is to increment independently of Xenomai according to major or
 > minor changes. One may ease this burden for the driver developer by
 > simply filling in Xenomai's version here. That would just let the
 > revisions increase on every Xenomai release, even if the driver remained
 > untouched. The tag would still have a meaning for out-of-tree drivers,
 > but for in-tree it would be fairly meaningless.
 > 
 > Well, whatever is commonly preferred, it should then be applied
 > consistently on all RTDM drivers in Xenomai. What are the opinions on
 > this list (I will comment afterwards)?
 > 
 > > Furthermore, there is also
 > > "profile_version" (which does not show up n the Doxygen docu for some
 > > strange reason).
 > 
 > The automatic update from the latest SVN must be broken on
 > www.xenomai.org, there is more stuff missing.

The automatic update only updates the web site from the contents of the
"generated" directory. In order to update this directory, go to the
"doc" subdirectory of the build tree and type "make generate-doc", then
run svn commit in the "generated" directory. I will install the proper
version of doxygen and regenerate the documentation.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Re: RT-Socket-CAN versioning

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Wolfgang Grandegger wrote:
>  > > Hi Jan,
>  > > 
>  > > currently the RT-Socket-CAN drivers maintains it's own version or
>  > > release number. As RT-Socket-CAN is part of Xenomai, I do not see the
>  > > need for it (and so far I did not update it). What is the intended use
>  > > of "driver_version" in "struct rtdm_device"?
>  > 
>  > Actually, I was thinking about this too yesterday. The idea of the
>  > separate versioning for RTDM drivers is to signal the users if something
>  > in the driver really changed. It's fairly obvious what to do with it for
>  > out-of-tree drivers, but for in-tree it might be worth considering the
>  > policy.
>  > 
>  > The current model, maintained more or less properly for the existing
>  > drivers, is to increment independently of Xenomai according to major or
>  > minor changes. One may ease this burden for the driver developer by
>  > simply filling in Xenomai's version here. That would just let the
>  > revisions increase on every Xenomai release, even if the driver remained
>  > untouched. The tag would still have a meaning for out-of-tree drivers,
>  > but for in-tree it would be fairly meaningless.
>  > 
>  > Well, whatever is commonly preferred, it should then be applied
>  > consistently on all RTDM drivers in Xenomai. What are the opinions on
>  > this list (I will comment afterwards)?
>  > 
>  > > Furthermore, there is also
>  > > "profile_version" (which does not show up n the Doxygen docu for some
>  > > strange reason).
>  > 
>  > The automatic update from the latest SVN must be broken on
>  > www.xenomai.org, there is more stuff missing.
> 
> The automatic update only updates the web site from the contents of the
> "generated" directory. In order to update this directory, go to the
> "doc" subdirectory of the build tree and type "make generate-doc", then
> run svn commit in the "generated" directory. I will install the proper
> version of doxygen and regenerate the documentation.
> 

Ah, thanks.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-core] Re: RT-Socket-CAN versioning

[Wolfgang Grandegger]

Hi Jan,

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Hi Jan,
>>
>> currently the RT-Socket-CAN drivers maintains it's own version or
>> release number. As RT-Socket-CAN is part of Xenomai, I do not see the
>> need for it (and so far I did not update it). What is the intended use
>> of "driver_version" in "struct rtdm_device"?
> 
> Actually, I was thinking about this too yesterday. The idea of the
> separate versioning for RTDM drivers is to signal the users if something
> in the driver really changed. It's fairly obvious what to do with it for
> out-of-tree drivers, but for in-tree it might be worth considering the
> policy.
> 
> The current model, maintained more or less properly for the existing
> drivers, is to increment independently of Xenomai according to major or
> minor changes. One may ease this burden for the driver developer by
> simply filling in Xenomai's version here. That would just let the
> revisions increase on every Xenomai release, even if the driver remained
> untouched. The tag would still have a meaning for out-of-tree drivers,
> but for in-tree it would be fairly meaningless.
> 
> Well, whatever is commonly preferred, it should then be applied
> consistently on all RTDM drivers in Xenomai. What are the opinions on
> this list (I will comment afterwards)?

OK, no other opinions so far. Then let's keep the current versioning 
scheme. I'm going to boost the RT-Socket-CAN version number to 0.90.0 
with the next commit and to 1.0.0 for the next official release (2.4.x?).

Wolfgang.

[Xenomai-core] Re: RT-Socket-CAN versioning

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Wolfgang Grandegger wrote:
> Hi Jan,
> 
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Jan,
>>>
>>> currently the RT-Socket-CAN drivers maintains it's own version or
>>> release number. As RT-Socket-CAN is part of Xenomai, I do not see the
>>> need for it (and so far I did not update it). What is the intended use
>>> of "driver_version" in "struct rtdm_device"?
>>
>> Actually, I was thinking about this too yesterday. The idea of the
>> separate versioning for RTDM drivers is to signal the users if something
>> in the driver really changed. It's fairly obvious what to do with it for
>> out-of-tree drivers, but for in-tree it might be worth considering the
>> policy.
>>
>> The current model, maintained more or less properly for the existing
>> drivers, is to increment independently of Xenomai according to major or
>> minor changes. One may ease this burden for the driver developer by
>> simply filling in Xenomai's version here. That would just let the
>> revisions increase on every Xenomai release, even if the driver remained
>> untouched. The tag would still have a meaning for out-of-tree drivers,
>> but for in-tree it would be fairly meaningless.
>>
>> Well, whatever is commonly preferred, it should then be applied
>> consistently on all RTDM drivers in Xenomai. What are the opinions on
>> this list (I will comment afterwards)?
> 
> OK, no other opinions so far. Then let's keep the current versioning

I guess everyone's busy with more serious issues.

> scheme. I'm going to boost the RT-Socket-CAN version number to 0.90.0
> with the next commit and to 1.0.0 for the next official release (2.4.x?).

Ack. That's preferred from my side as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]