re: kern/55103: /dev/wsmouse returns EINVAL

[Paul Goyette <paul%whooppee.com@localhost>]

On Fri, 3 Apr 2020, matthew green wrote:

> the problem is that in the past cat and hexdump were
> useful and usable as "clients".  that no longer works,
> because without the compat code available, there is no
> way, without setting the version, to access these nodes,
> which makes the cat/hexdump mehtods of debugging not work.
>
> any argument that says "fix your userland" misses the
> desired (and traditional) operation here and is not a
> helpful answer.
>
> i think the only real solution we have here is the sysctl
> that changes the default, and having the depend on whether
> there is a path for compat or not -- eg, if it is present,
> then use it, or if it's possibly available (MODULAR) then
> use it, but with no baked in compat or modules, the default
> should be the only working method.
>
> AFAICT, this avoids breaking old userland with new kernel,
> allows cat/hexdump to work, and keeps everything else
> working in at least the same feature set as before.

Let's see if I get this decision-process right...

Create the hw.wsmouse.default_version sysctl(8) to deal with
updating the default_version.  (And retain the existing ioctl
call to change the version used by an opened device.)

static int default_version =
#ifdef MODULAR
					old;
#else
					new;
#endif


In wsmouse_open()

	...
	/*
	 * The hook returns 0 (for "old version") if the hook is
	 * set;  otherwise we use the compile-time default version.
	 * Effectively, we have
	 *
	 * if (wsevent_50_available) {
	 *	version = old;
	 * } else {
	 *	version = default_version;
	 * }
	 */
	MODULE_HOOK_CALL(wsevent_50_version_hook(), (),
		default_version, version);
	...


If we do this, then MODULAR kernels will never default to the
new version, even if the compat_50 module is not present, and
it will be necessary for "new binaries" to explicitly set the
version using the ioctl() (or to update the version via the
sysctl).  "Old binaries" will continue to _fail_ if the compat_50
module is not present in a MODULAR kernel, but "old binaries"
_will_ work in non-MODULAR kernels (although the time-stamps in
the data will be wrong, since we'll set 64-bits).

Is this what we want?  If so, it should be relatively easy to
implement.

Unfortunately due to the introduction of a new compat_hook, it
would be inappropriate to pull this up to the -9 branch.  :(

I _think_ this is the decision/result matrix we end up with...

                     Old binary                New binary

non-MODULAR          Read succeeds, but data   Works fine
                     is wrong - 64-vs-32 bit
                     time-stamps

MODULAR, and         Read succeeds             Read succeeds, but data
module present,                                is wrong - 32-vs-64 bit
sysctl not updated                             time-stamps (can use the
                                               ioctl to make it work)

MODULAR, module      Read succeeds, but data   Read succeeds
present, and sysctl  is wrong
_is_ updated

MODULAR, module is   Read fails, as it does    Read fails as it does
not present, and     today                     today
sysctl not updated

MODULAR, module is   Read fails, as it does    Read succeeds
not present, and     today
sysctl is updated



+--------------------+--------------------------+-----------------------+
| Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
| (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |
+--------------------+--------------------------+-----------------------+