Linux IIO development
 help / color / mirror / Atom feed
* Cut down on number of attribute macros?
@ 2010-03-26 16:11 Jonathan Cameron
  0 siblings, 0 replies; only message in thread
From: Jonathan Cameron @ 2010-03-26 16:11 UTC (permalink / raw)
  To: linux-iio@vger.kernel.org

Dear All,

As part of the abi changes, we would need a huge number of macros similar
to those currently provided in accel.h, adc.h and friends.

Often these actually lead to longer code that one would have if one called
the underlying IIO_DEVICE_ATTR and similar macros.  

Hence I'm after opinions from those working with the subsystem.  Are these
useful or would we be better served taking the approach of enforcing these
naming conventions via review of submitted drivers (similar to hwmon)?

Thus we rely on abi documentation rather than the current complex mess of
macros.

What do people think?

I'm certainly not inclined to enforce the use of these macros, particularly in
cases like the one I would have added as part of the new abi changes..

IIO_DEV_ATTR_ACCEL_Z_MAG_EITHER_RISING_VALUE(_mode, _show, _store, _reg)

vs just using IIO_DEVICE_ATTR directly in the instansiation

IIO_DEVICE_ATTR(accel_z_mag_either_rising_value,
	S_IRUGO | S_IWUSR,
	sca3000_show_thresh,
	sca3000_write_thresh,
	SCA3000_REG_CTRL_SEL_MD_Z_TH);

If anything the events, particularly the shared cases are even worse.

At some point I'm going to end up with an 80 character macro name using
the current approach.

Jonathan

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2010-03-26 16:09 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-26 16:11 Cut down on number of attribute macros? Jonathan Cameron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox