Dmitry Torokhov <dmitry.torok...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
