Four drivers (hptmv, hptnr, hptrr, hpt27xx) include precompiled binary objects, and we ought not include such in the GENERIC kernel. They are available as modules if users need them.
Relnotes: Yes
Differential D21865
avoid compiling in hpt* drivers containing binary blobs emaste on Oct 1 2019, 8:22 PM. Authored by Tags None Referenced Files
Subscribers
Details
Four drivers (hptmv, hptnr, hptrr, hpt27xx) include precompiled binary objects, and we ought not include such in the GENERIC kernel. They are available as modules if users need them. Relnotes: Yes
Diff Detail
Event TimelineComment Actions +re@ I'm mostly in favor of the change (smaller kernel size, etc.), but since we are removing driver from GENERIC, it's better if we can provide a mechanism to load the driver on demand, or a binary update can easily brick the system... Comment Actions devmatch can provide that. However, the data from nycbug dmesg server strongly suggests that nobody will notice. hptmv is from 2004. It can be removed from the system. (0) On the whole, I'd say we can remove these from the system because they are basically abdonware binary drivers that are quite hard to debug if there's problems because of it. They are also not very popular at all (despite the false positives, none of the ones I checked actually indicated use of these controllers. I'd propose we kick them out of the tree, put them in ports and let people that care about them be listed as maintainer, or they get deleted from the ports tree... Comment Actions querying for hptFOO: no controller returns the same number of hits. Spot checking again shows no actual indicated use. Comment Actions IMO having drivers in the ports tree doesn't really help. The fact that they're still in ports implies some level of support, so they're still a maintenance burden, and patching out-of-tree code is more work. I would much sooner just build them as modules and keep them in the tree for some time. The out-of-tree legacy DRM drivers are a case in point here. Comment Actions I'm cool with kicking all but maybe hptnr out of the tree entirely. They are so old, fringe and undebuggable that we should just cut our losses. There's likely 0 current uses of them given their age, and I've found no evidence in any of the incomplete sets of data we have. The DRM drivers are a special case: they touch APIs that change frequently. These drivers do none of that. It's a problem we need to solve, but not really relevant to the argument here. Comment Actions With the hpt* drivers I agree it'd be less of a problem, but it's still a problem for e.g., CAM KPIs. To be clear, I have no feelings on whether these drivers should stay or go; I have never encountered any of them in my use of FreeBSD. My feeling, based on experiences with both the current and legacy DRM drivers, is just that we do not gain anything from moving drivers into the ports tree. Comment Actions
OK then, for -CURRENT I think a relnotes and UPDATING entry is sufficient, regardless of whether we do the devmatch magic or not, and will commit shortly. |