Re: [PATCH] macintosh/mac_hid.c: don't load by default

On Tue, Nov 15, 2022 at 04:07:53AM +0100, Thomas Weißschuh wrote:

On 2022-11-14 16:16-0800, Dmitry Torokhov wrote:

quoted

On Tue, Nov 15, 2022 at 12:54:41AM +0100, Thomas Weißschuh wrote:

quoted

Cc Franz who wrote the driver originally.
(I hope I got the correct one)

Hi Dmitry,

On 2022-11-14 10:33-0800, Dmitry Torokhov wrote:

quoted

On Sun, Nov 13, 2022 at 04:30:22AM +0100, Thomas Weißschuh wrote:

quoted

There should be no need to automatically load this driver on *all*
machines with a keyboard.

This driver is of very limited utility and has to be enabled by the user
explicitly anyway.
Furthermore its own header comment has deprecated it for 17 years.

I think if someone does not need a driver they can either not enable it
or blacklist it in /etc/modprobe.d/... There is no need to break
module loading in the kernel.

But nobody needs the driver as it is autoloaded in its current state.
Without manual configuration after loading the driver does not provide any
functionality.

Furthermore the autoloading should load the driver for a specific
hardware/resource that it can provide additional functionality for.
Right now the driver loads automatically for any system that has an input
device with a key and then just does nothing.

It only wastes memory and confuses users why it is loaded.

If somebody really needs this (fringe) driver it should be on them to load it
it instead of everybody else having to disable it.

The driver is not enabled by default, so somebody has to enable it in
the first place. How did you end up with it?

My distro kernel configured it to be enabled as module.

Maybe you should talk to them? Which one is this? Not all distributions
seem to enable it (Debian for example does not).

So people who want to use it can do so. It would be nice if the rest of us
wouldn't have to care about it.

quoted

quoted

Furthermore the file has the following comment since the beginning of the git
history in 2005:

    Copyright (C) 2000 Franz Sirl

    This file will soon be removed in favor of an uinput userspace tool.

OK, that is a separate topic, if there are no users we can remove the
driver. Do we know if this tool ever came into existence?

One interpretation of it is attached as "mac_hid_userspace.c".

quoted

What I do not want is to break the autoload for one single driver
because somebody enabled it without intending to use and now tries to
implement a one-off.

Is an autoloaded driver that then does not (ever) automatically provide any
functionality not broken by definition?

No because it does not result in any regression in behavior.

It was enabled by the distro. Which seems correct, because maybe somebody will
use it.

Taken to an illogical extreme: If it is fine for modules to load automatically
even if they are not useful, why not just always load all available modules?

Well, take for example a driver for a NIC. It is not really useful until
you configure it by assigning an address to the interface, etc. Should
we not automatically load drivers for NICs?

Maybe we can take the removal of the autoload as a first step of deprecation
and finally removal of the module.
To quote you:

    "I'd rather we did not promote from drivers/macintosh to other platforms,
     but rather removed it. The same functionality can be done from
     userspace." [0]

I think if you talk to your distro and see if they stop enabling it and
offer your userspace utility as a replacement if they indeed need the
functionality would be the best way of deprecating the driver.

Thanks.

-- 
Dmitry