[Xenomai-core] Re: [Xenomai-help] [ANNOUNCE] RTDM driver for CAN devices

[Wolfgang Grandegger <wg@domain.hid>]

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>>>>> - Well known issue: the RTCAN name. This should definitely get resolved
>>>>> before we merge. Any feedback already?
>>>> I contacted the author. If I will not get an answer soon, I tend
>>>> changing the global name to RT-Socket-CAN (rtsocketcan).
>>> I would really hate to have a drivers/rtsocketcan or a
>>> rtdm/rtsocketcan.h. The short name is so much nicer.
>> He did not say, that we cannot use the name RTCAN but he prefers that we
>> use a different name to avoid confusion. Therefore I suggest to use the
>> offical name "RT-Socket-CAN" for the project, but leave almost all
>> internal rtcan prefixes as they are apart from:
>>
>>   drivers/rtsocketcan
>>   rtdm/rtsocketcan.h
>>
>> Note that the API does use the Linux naming in most cases (with the
>> prefix can).
>>
>> Another possibility would be to use rtscan as short form for rtsocketcan
>> as prefix.
>>
>> What do you think? Well, it's just a name.
> 
> Never underestimate naming. Ok, I have this proposal now:
> 
>  o drivers/can/ - That's consistent with the existing subdir naming
>    anyway.

I was also thinking about that.

>  o rtdm/rtcan.h - The "rtdm/" prefix clearly defines the context: It's
>    THE standard real-time CAN profile for RTDM.
> 
>  o All references to "RTCAN" in comments, READMEs, headers, etc. must be
>    changed to RT-Socket-CAN. So it should be clear that this has nothing
>    to do with the existing "rtcan" project.
> 
>  o Variable, type, and function names remain as they are.

OK, thats fine for me. The important thing is, that the official project 
name is different from RTCAN.

> Jan
> 
> 
> PS: Another point for the long-term to-do list :-> : The nested locking
> and the global scope of certain locks. It's safe, it's harmless for
> current primary target platforms (UP), but it's not really beautiful
> when considering SMP setups. A bit tricky, for sure.

Yes, it's also not nice, that it is in the HW specific driver. I did not 
  touch it because I have no SMP system for testing.

Wolfgang.