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

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

The following reply was made to PR kern/55103; it has been noted by GNATS.

From: Paul Goyette <paul%whooppee.com@localhost>
To: Michael van Elst <mlelstv%serpens.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/55103: /dev/wsmouse returns EINVAL
Date: Wed, 1 Apr 2020 19:38:52 -0700 (PDT)

 On Thu, 2 Apr 2020, Michael van Elst wrote:
 
 > On Wed, Apr 01, 2020 at 09:15:02PM +0000, Paul Goyette wrote:
 >>
 >> > Reading from /dev/wsmouse was possible to get mouse events from any program.
 >>  The original code (before merging the [pgoyette-compat] branch) was
 >>  conditional on
 >>   	#if defined(COMPAT_50) || defined(MODULAR)
 >>  (and directly returned EINVAL if those options were not present).
 >
 > Before COMPAT_50:  reading mouse was possible, no EINVAL failure existed.
 > After COMPAT_50: reading mouse was possible because COMPAT_50 was default.
 > Now: reading mouse is no longer possible because COMPAT_50 is removed and
 > module isn't autoloaded.
 >
 > What would you suggest to make "reading mouse is possible" true again?
 >
 > - Move compat code back into main code, no option, no optional module.
 >
 > - Weaken compatibility and make events with 64bit time_t the default
 > unless the module is loaded.
 >
 > There is a single user of that interface and the difference between
 > "doen't work because no compat code installed" (status quo) and
 > "doesn't work because interface isn't compatible" (second choice)
 > is small. In either case you only get compatibility (with ancient
 > userland!) by loading the module.
 >
 > The first choice is also a possibility. Just implementing the old protocol
 > version probably needs less code than the module and compat glue.
 
 Looking at the original code, it seems pretty clear that the intent was
 to restrict use of version-0 to compat code, and that without compat
 code one should use WSEVENT_VERSION.  And that is what the current code
 implements, as far as I can tell.
 
 I'm not familiar with evbarm systems, so I don't know anything about
 the removal of compat_50 from default kernel(s).  But it seems to me
 that that removal should have updated any "standard" users/callers of
 this interface to use the updated version.
 
 My only suggestion to resolve this would be to attempt to autoload the
 compat_50 module before calling the compat hook.  If autoload succeeds
 then everything should be fine;  if autoload fails, you get the same
 behaviour as what you get today.  Please start a discussion thread on
 tech-kern if you want me to pursue this approach.
 
 I do not believe that either "move compat code back ..." or "weaken
 compat ..." are appropriate choices.  But I will attempt to follow
 whatever consensus is reached on tech-kern@ discussion.
 
 
 
 +--------------------+--------------------------+-----------------------+
 | 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   |
 +--------------------+--------------------------+-----------------------+