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:


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

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.


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.


Xenomai-core mailing list

Reply via email to