Re: [patch 03/13] input: make input a multi-object module

[Anssi Hannula <anssi.hannula@gmail.com>]

Andrew Morton wrote:
> Anssi Hannula <anssi.hannula@gmail.com> wrote:
> 
>>
>>>>>It would be much nicer all round if we could avoid renaming this file.
>>>>
>>>>Indeed... There are these 4 options as far as I see:
>>>>
>>>>1. Do this rename
>>>>2. Put all the code in input-ff.c to input.c
>>>>3. Make the input-ff a separate bool "module" and add
>>>>EXPORT_SYMBOL_GPL() for input_ff_event() which is currently the only
>>>>function in input-ff.c that is called from input.c
>>>>4. Rename the input "module" to something else, it doesn't matter so
>>>>much as almost everybody builds it as built-in anyway.
>>>>
>>>>WDYT is the best one?
>>>
>>>
>>>I still don't know what problem you're trying to solve so I cannot say.
>>
>>Maybe you know now.
> 
> 
> yup, thanks.
> 
> I'd have thought that 3) is the path of least resistance.
> 
> But it does require that input.c "knows" that input-ff.c was included in
> the build, which is not a thing we like to do.

Well, it's going to be included as built-in and can't be built as a
module at all, so I think it's okay for us to do so?

> Why should things in input.c call into input-ff.c, btw?  The way we
> normally would handle that is to add a register_something() API to input.c
> and input-ff.c would insert its callback via that interface.

Yes, we could easily add a callback to e.g. struct input_dev, but is
that really preferred if the input-ff.c is built-in?

And it's built-in only because: If I were to implement
register_something() stuff for this, no module would require input-ff
and it would not be loaded, even if there are ff-capable device drivers
present.

-- 
Anssi Hannula