Messages in this thread | | | Date | Sat, 27 May 2006 01:22:16 +0300 | From | Anssi Hannula <> | Subject | Re: [patch 03/13] input: make input a multi-object module |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |