Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Krzysztof Halasa <khc@pm.waw.pl>]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

>> There is only one thing which needs attention before/when merging LIRC:
>> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and,
>> actually, making a correct IR core design without the LIRC merged can be
>> only harder.
>
> This sounds like "merge first, think later"...

I'd say "merge the sane agreed and stable things first and think later
about improvements".

> The question is why we need to merge lirc interface right now, before we
> agreed on the sybsystem architecture?

Because we need the features and we can't improve something which is
outside the kernel. What "subsystem architecture" do you want to
discuss? Unrelated (input layer) interface?

Those are simple things. The only part which needs to be stable is the
(in this case LIRC) kernel-user interface.

> Noone _in kernel_ user lirc-dev
> yet and, looking at the way things are shaping, no drivers will be
> _directly_ using it after it is complete. So, even if we merge it right
> away, the code will have to be restructured and reworked.

Sure. We do this constantly to every part of the kernel.

> Unfortunately,
> just merging what Jarod posted, will introduce sysfs hierarchy which
> is userspace interface as well (although we not as good maintaining it
> at times) and will add more constraints on us.

Then perhaps it should be skipped, leaving only the things udev needs to
create /dev/ entries. They don't have to be particularly stable.
Perhaps it should go to the staging first. We can't work with the code
outside the kernel, staging has not such limitation.

> That is why I think we should go the other way around - introduce the
> core which receivers could plug into and decoder framework and once it
> is ready register lirc-dev as one of the available decoders.

That means all the work has to be kept and then merged "atomically",
it seems there is a lack of manpower for this.
-- 
Krzysztof Halasa