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
Details
Details
- Reviewers
imp delphij markj - Group Reviewers
releng - Commits
- rS353042: Remove host binary object drivers from GENERIC
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment 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)
hptnr is from 2013. It's not that popular and this won't affect many people. (16 - most say no controller detected)
hptrr is from 2007. It's old enough we can remove it, but still showing up (35 - ditto)
htp27xx is is from 2011. It's also not too popular. (30 - ditto)
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
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...
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.