Jan Kiszka wrote:
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
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
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
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

 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
   to do with the existing "rtcan" project.

 o Variable, type, and function names remain as they are.


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

Oops, I checked the previous mails and understood, that they should be kept external but anyway, I prefer this solution. Nevertheless, I think it requires integration with configure and friends. I have attached my revised external version of rtsocketcan-utils.



Attachment: rtsocketcan-utils-0.20.2.tar.bz2
Description: application/bzip

Xenomai-core mailing list

Reply via email to