Thread (6 messages) 6 messages, 3 authors, 2016-05-03

Re: How to properly extend uinput API

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2016-05-02 18:35:46

Hi Manuel,

On Sat, Apr 30, 2016 at 11:36:24AM +0200, Manuel Reimer wrote:
Hello,

I'm currently trying to somehow get uinput connected with ff-memless.
I am not sure that exposing ff-memless to userspace is a good idea.
Right now what we have is a supporting library for several kernel
modules and there were considerations to change it to work differently.

I'd rather userspace took care of handling dumb devices if t decided to
handle device communication instead of leaving it to the kernel.

Thanks.
My first try (which is some kind of hack which prevents API changes
and doesn't work at all) failed. Now my idea is to add some more
simple (and probably working) API for this. All, I need in the
"memless case", is some way to get two motor speeds sent to
usermode, which doesn't require all this callback stuff.

There is a new API which, as far as I understand, is meant to be
easier extendable:
https://github.com/torvalds/linux/commit/052876f8e5

What I need is some way to pass an additional boolean to tell the
kernel module that usermode wants to use ff-memless. Device setup is
done with an struct "uinput_setup". As far as I know it isn't easily
possible to extend this without breaking existing stuff.

It would be possible to write some hack which passes this
information via magic-value through ff_effects_max but I think there
has to be some nicer way.

So how to pass one more piece of information from usermode to kernel
module while setup without breaking existing (probably
closed-source) stuff? Keep a definition of the old struct version
and decide which one to use based on size?

Thank you very much in advance for any help.

Manuel
-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help