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
Another possibility would be to use rtscan as short form for rtsocketcan
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