Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> 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.
>>>>
>>>>  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.
>>>>
>>>> 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.
>>> I just realized another issue. Where to put README and CREDITS file? The
>>> README should go into doc/txt/can-driver.txt. Should I add the credits
>>> to this file as well?
>>
>> I would maintain that file under drivers/can. Who knows if it doesn't
>> grow noticeably over the time... Some reference from the main CREDITS
>> would be good then. Something like "See drivers/<subsystem>/CREDITS for
>> further contributors".
> 
> Attached is a revised patch of RT-Socket-CAN for Xenomai ready for
> integration. I fixed most of the issues as discussed. Still a few on the
> TO-DO list, but they could be fixed later on, I think.
> 

Great! Will have a look later and start to merge it.

What's the status of the utils? Philippe and I agreed to put them into
src/utils/can.

Jan