Page MenuHomeFreeBSD

avoid compiling in hpt* drivers containing binary blobs
ClosedPublic

Authored by emaste on Tue, Oct 1, 8:22 PM.

Details

Summary

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

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

emaste created this revision.Tue, Oct 1, 8:22 PM
emaste added a subscriber: markj.
markj accepted this revision.Tue, Oct 1, 8:33 PM

Fine with me.

This revision is now accepted and ready to land.Tue, Oct 1, 8:33 PM

+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...

imp added a comment.Wed, Oct 2, 2:41 PM

+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...

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...

imp added a comment.Wed, Oct 2, 2:42 PM

querying for hptFOO: no controller returns the same number of hits. Spot checking again shows no actual indicated use.

markj added a comment.Wed, Oct 2, 3:10 PM
In D21865#477783, @imp wrote:

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...

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.

imp added a comment.Wed, Oct 2, 3:44 PM
In D21865#477783, @imp wrote:

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...

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.

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.

markj added a comment.Wed, Oct 2, 4:08 PM
In D21865#477809, @imp wrote:
In D21865#477783, @imp wrote:

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...

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.

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.

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.

emaste added a comment.Wed, Oct 2, 6:30 PM

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.

This revision was automatically updated to reflect the committed changes.