All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Nicolodi <daniele@domain.hid>
To: xenomai-core <xenomai@xenomai.org>,
	Alexis Berlemont <alexis.berlemont@domain.hid>
Subject: [Xenomai-core] Analogy: A4L_CHAN_AREF_* and AREF_* and other macros
Date: Mon, 29 Mar 2010 22:46:56 +0200	[thread overview]
Message-ID: <4BB111C0.9050502@domain.hid> (raw)

Hello Alexis,

I have noticed that in Analogy headers there are two sets of macros to
define channels references, one with prefix A4L_CHAN_AREF_ and the other
with prefix AREF_. I think keeping both is confusing and dangerous,
because similar symbols are defined with different numerical values!

The later form is the one used in comedi API and drivers, but i think it
is better to prefix all exported symbols and constants with a namespace
like string. I would be for keeping only the former form.

If you agree, I can provide a patch for you to review.

Similarly, I would rename TRIG_ constants to something like A4L_TRIG_,
and while at it I think TRIG_WAKE_EOS should become A4L_CMD_WAKE_EOS, as
it is a command flag and not a trigger source.

Similarly, it would be nice also to rename other macros defined in
command.h, adding at least a common A4L_ prefix. While at it I think
that, maybe after a rename to make their purpose more clear, CR_* macros
should be exposed to user space too.

If you think API breakage should be avoided, even in a so early stage of
development and diffusion, we can keep the old definitions for a while,
issuing deprecation warning (in this case those symbols would have to be
exposed as constant variables where to apply the __deprecated__ gcc
attribute).

Let me know what you think about this proposal.

Cheers,
-- 
Daniele



             reply	other threads:[~2010-03-29 20:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 20:46 Daniele Nicolodi [this message]
2010-04-04 13:43 ` [Xenomai-core] Analogy: A4L_CHAN_AREF_* and AREF_* and other macros Alexis Berlemont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BB111C0.9050502@domain.hid \
    --to=daniele@domain.hid \
    --cc=alexis.berlemont@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.