public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Jonathan Cameron' <jic23@kernel.org>,
	William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: "kamel.bouhara@bootlin.com" <kamel.bouhara@bootlin.com>,
	"gwendal@chromium.org" <gwendal@chromium.org>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"david@lechnology.com" <david@lechnology.com>,
	"felipe.balbi@linux.intel.com" <felipe.balbi@linux.intel.com>,
	"fabien.lahoudere@collabora.com" <fabien.lahoudere@collabora.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-stm32@st-md-mailman.stormreply.com" 
	<linux-stm32@st-md-mailman.stormreply.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"syednwaris@gmail.com" <syednwaris@gmail.com>,
	"patrick.havelange@essensium.com"
	<patrick.havelange@essensium.com>,
	"fabrice.gasnier@st.com" <fabrice.gasnier@st.com>,
	"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
	"alexandre.torgue@st.com" <alexandre.torgue@st.com>
Subject: RE: [PATCH 0/4] Introduce the Counter character device interface
Date: Sun, 3 May 2020 14:21:11 +0000	[thread overview]
Message-ID: <b2d51e3f9dfb4dd78156b2e945607e8d@AcuMS.aculab.com> (raw)
In-Reply-To: <20200503151314.2ac1fc2e@archlinux>

From: Jonathan Cameron
> Sent: 03 May 2020 15:13
...
> > The following are some questions I have about this patchset:
> >
> > 1. Should enums be used to represent standard counter component states
> >    (e.g. COUNTER_SIGNAL_LOW), or would these be better defined as int?
> >
> >    These standard counter component states are defined in the
> >    counter-types.h file and serve as constants used by counter device
> >    drivers and Counter subsystem components in order to ensure a
> >    consistent interface.
> >
> >    My concern is whether enum constants will cause problems when passed
> >    to userspace via the Counter character device ioctl calls. Along the
> >    same lines is whether the C bool datatype is safe to pass as well,
> >    given that it is a more modern C datatype.
> 
> For enums, I'd pass them as integers.
> 
> Bool is probably fine either way.

Always use fixed size types in any API structures.
Ensure that fields are always on their natural boundaries.

So no enums and no bools.
It may even be worth using uint64_t for any userspace pointers.

At some point you'll live to regret anything else.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


      reply	other threads:[~2020-05-03 14:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 18:11 [PATCH 0/4] Introduce the Counter character device interface William Breathitt Gray
2020-04-29 18:11 ` [PATCH 2/4] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
2020-04-29 18:11 ` [PATCH 3/4] counter: Add character device interface William Breathitt Gray
2020-05-01  2:56   ` kbuild test robot
2020-04-29 18:11 ` [PATCH 4/4] docs: counter: Document " William Breathitt Gray
2020-04-29 20:21 ` [PATCH 0/4] Introduce the Counter " David Lechner
2020-05-03 14:52   ` Jonathan Cameron
2020-04-30 20:13 ` Alexandre Belloni
2020-05-01 15:46   ` William Breathitt Gray
2020-05-02 16:55     ` Jonathan Cameron
2020-05-03  9:23       ` Greg Kroah-Hartman
2020-05-03 12:54         ` Jonathan Cameron
2020-05-03 13:16           ` William Breathitt Gray
2020-05-03 15:05     ` Jonathan Cameron
2020-05-03 14:13 ` Jonathan Cameron
2020-05-03 14:21   ` David Laight [this message]

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=b2d51e3f9dfb4dd78156b2e945607e8d@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alexandre.torgue@st.com \
    --cc=david@lechnology.com \
    --cc=fabien.lahoudere@collabora.com \
    --cc=fabrice.gasnier@st.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gwendal@chromium.org \
    --cc=jic23@kernel.org \
    --cc=kamel.bouhara@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=patrick.havelange@essensium.com \
    --cc=syednwaris@gmail.com \
    --cc=vilhelm.gray@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox