linux-kernel - Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADbOyBQ0U_TiovwMJJO1zQpr5PcwmB1O155P4nC6CmwhZjA=UQ@mail.gmail.com>
Date:	Mon, 24 Feb 2014 22:17:25 +0100
From:	Elias Vanderstuyft <elias.vds@...il.com>
To:	Anssi Hannula <anssi.hannula@....fi>
Cc:	Michal Malý <madcatxster@...fuk.cz>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, Simon Wood <simon@...gewell.org>
Subject: Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it

On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý <madcatxster@...fuk.cz> wrote:
> On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote:
>>
>> I think we should extend the current ff-memless instead of duplicating
>> its functionality (even on a "for now" basis).
>>
>> Having looked at ff-memless-next briefly, it seems very similar to
>> ff-memless on its basic working principle, and therefore I don't really
>> see why extending ff-memless would be too cumbersome. Unless I'm missing
>> something - in that case, feel free to point it out to me :)
>
> Deciding whether to patch ff-memless or write a new driver from scratch was a
> perfect example of being caught between the rock and a hard place. I am not
> particularly fond of the fact that we would have two modules doing pretty much
> the same thing. My reasons for writing a separate module were:
> - Periodic effects. ff-memless doesn't do "real" periodic effects, it simply
> emulates them through rumble effect. Devices without rumble effect support
> require emulation through constant force effect. Just this was not something
> one could write in one afternoon:)
> - Conditional effects. These effects cannot be by nature combined into one
> overall force (at least not easily) so they have to be handled one by one -
> this is a concept ff-memless does not seem to consider. FFB devices have
> limits as to how many conditional (referred to as "uncombinable" in MLNX)
> effects can be active simultaneously, etc.
> All in all it seemed less error prone to write a new driver based on the ff-
> memless logic, test and deploy it on devices I have access to and once we are
> sure there are no nasty regressions port the rest of the drivers to the new
> API. Given the scope of the changes I am afraid that a "patch" to ff-memless
> would be pretty close to a rewrite anyway.

And add the fact that we already heavily tested the ff-memless-next driver.
Unless you do a diff between the original ff-memless.c and the current
ff-memless-next.c (which will result in a rather unintuitive patch),
it would be a huge waste of time to retest the modified (when doing
efforts to create an intuitive patch) ff-memless-next.c, considered my
total time spend on testing (and not to speak of the time that Michal
spent to fix the corresponding bugs.)
I know that might not be much of an argument, but on the other side,
my motivation to test again from scratch will be much lower (I can't
change much on that, I'm afraid), which would eventually lead to lower
reliability of the final product.

Elias
--
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/