On Thu, Jun 24, 2021 at 10:13:49AM +0100, Sean Young wrote:

On Wed, Jun 23, 2021 at 03:10:20PM +0200, Johan Hovold wrote:

quoted

Sorry about the late reply on this one too.

On Tue, May 25, 2021 at 02:25:49PM +0200, Oliver Neukum wrote:

quoted

Am Donnerstag, den 20.05.2021, 15:31 +0200 schrieb Johan Hovold:

quoted

quoted

Isn't that already handled by lircd using uinput?

The problem with that reasoning, though it is true, is

1) We would need to remove a lot of subsystems if we took that
to the logical conclusion. 

Removing code is always nice. ;)

So rather than adding hotplug to serdev, we should remove line-discipline,
serdev, and serio and all its drivers from the kernel? This is taking
your own argument and applying it your code.

Not at all. Not everything can be done in user space, but some things
can.

quoted

quoted

3) We end up with two classes of LIRC devices

We already do, right? That's kind of my point since we have lircd
supporting uinput.

This is not an either-or situation, lircd is the "old" solution which is
slowing being supplanted with rc-core. All the new keymaps are rc-core and
do not work with lircd. The new rc-core tooling (in the v4l-utils package) 
does not work with lircd. lircd hasn't had any real patches merged for years
now.

There is whole new tooling in the works for rc-core which is not compatible
with lircd.

Sure, you already explained that. I was just asking (earlier) why you
didn't use the infrastructure that's already in place. If there are good
reasons for not doing so then fine. 

quoted

quoted

quoted

I hear you, but we still need to have those discussions from time to
time to make sure our architecture is sane. One of the problems today
with the kernel development process appears to be that too few
questions
are asked. If it builds, ship it...

Indeed, so, could we force a line discipline on a device on the kernel
level? Code duplication is bad.

Not sure I understand what you have mind here. serdev is sort of a
line-discipline which we'd "force" on a device if there's a matching
description in devicetree, while line disciplines always need to be
instantiated by user space. Or are you referring to ldisc/serdev code
reuse?

I am pretty sure Oliver is suggesting that all ldisc/serdev code in
the kernel is duplication of code which can be done in userspace, by your
own argument.

See above.

quoted

quoted

quoted

But I think I've got that point across by now.

Yes and and we need to think about the conclusion we draw from
that point. It seems to me that an architecture that pushes data
through the whole tty layer into a demon, then through uinput
is definitely not elegant.

The elegant answer is serdev, but it does not yet support the features
needed in this case (i.e. hotplugging).

Since we already support user-space drivers for these devices, I see
nothing wrong with implementing support for another one in user space
unless there are strong reasons against doing so (e.g. performance,
pm or usability). But if uinput works then great, we're done.

As discussed lircd has terrible latency, and lircd is out of date and
unmaintained and does not work with modern tooling and keymaps.

Also essentially your saying that any input device that connects to a
serial port should be done in user space. There are a ton of kernel
drivers doing exactly that, and that is why serio exists in the first
place.

I'm not, again see above. I'm saying that we should not make one-off
copies of serial drivers if we can avoid it.

In this case the limitations of lircd and the lack of hotplugging in
serdev may be a sufficient reason for making an exception. As we've
already discussed.

Johan