lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEnQRZBUi=m55dP5=B8ahHFgb6o2JA2cWTh0aZf8RNtWid1yEw@mail.gmail.com>
Date:	Tue, 28 Oct 2014 12:22:16 +0200
From:	Daniel Baluta <daniel.baluta@...el.com>
To:	Jonathan Cameron <jic23@...nel.org>
Cc:	Hartmut Knaack <knaack.h@....de>,
	Daniel Baluta <daniel.baluta@...el.com>,
	irina.tirdea@...el.com, linux-iio@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald <pmeerw@...erw.net>
Subject: Re: [RFC PATCH v2 4/7] iio: core: Introduce STEPS channel type,
 ENABLE mask and INSTANCE event

On Sat, Oct 25, 2014 at 10:18 PM, Jonathan Cameron <jic23@...nel.org> wrote:
> On 24/10/14 23:31, Hartmut Knaack wrote:
>> Daniel Baluta schrieb am 09.10.2014 14:39:
>>> From: Irina Tirdea <irina.tirdea@...el.com>
>>>
>>> These changes are needed to support the functionality of a pedometer.
>>> A pedometer has two basic functionalities: step counter and step detector.
>>>
>>> The step counter needs to be enabled and then it will count the steps
>>> in its hardware register. Whenever the application needs to check
>>> the step count, it will read the step counter register. To support the
>>> step counter a new channel type STEPS is added. Since the pedometer needs
>>> to be enabled first so that the hardware can count and store the steps,
>>> we need a specific ENABLE channel info mask.
>>>
>>> The step detector will generate an interrupt each time a step is detected.
>>> To support this functionality we add a new event type INSTANCE.
>>>
>> Hi,
>> I was wondering, if it would be better to name this channel somehow more generic. What you are actually counting are some pulses, and only the implementation of the hardware leads to the interpretation of these pulses as for example steps.
>> Other devices for this category would be pulse counters - either stand alone, or as part of SoCs. Some use cases I could think of are: liquid/gas flow measurements, engine rotation/RPM counts, object counts, ...
>> Any opinions?
>
> I agree there might be potential here for a broader interface...    RPM however
> would be a rotational speed measurement and hence in radians / second or
> radians if just a count of pulses off an encoder.
>
> We have just recently had a human pulse counter as well which is another count.
>
> The question to my mind is do we gain anything by making it more generic?
> Does it help userspace?  Chances of having many applications that don't care
> about the difference between steps and other pulse counts is probably low
> so right now I'm (slightly) falling on the side of have these more specific
> counts.
>
> So what does everyone else think?

I think making this more generic might confuse the users. Having this
more specific makes the interface very clear about who should use it.

Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ