tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: Disable autoload of compat_xyz modules



> Date: Wed, 02 Aug 2017 18:19:27 +1000
> from: matthew green <mrg%eterna.com.au@localhost>
> 
> > compat_linux
> > compat_linux32
> 
> all of these are used regularly by many netbsd users.  please don't
> include them in your list of targets.

Does anyone use compat_linux without also doing the additional system
configuration steps of setting up /emul?  Is it an onerous burden to
have to modload or add a line in /etc/modules.conf in those steps?

For users like me who don't care about running proprietary binary
blobs for Linux, compat_linux carries no benefit -- only the cost of
additional attack surface.

(This does not extend beyond compat_linux.  E.g., random hardware
devices for which we have drivers confer the benefit that I might run
into the hardware some day.  But I'm not going to run Linux binaries
without a clear conscious decision.)

For the users who do derive value from compat_linux, the cost of
requiring modload to enable it seems negligible to me.

> saying "modload is OK" is not how we treat the GENERIC kernel -- if
> it's OK, then it's OK for GENERIC is how we treat that.

That standard suggests we should remove the buggy unmaintained compat
modules altogether, which struck me as a more extreme proposal than I
care to push for now.  (I'm also not sure the set of modules we build
adheres to that standard as is, even outside the compat modules.)

If you want to propose deletion, that's fine.  What is not tenable is
leaving everything as is, as we've done in the past, just because
nobody has the energy either to maintain the code or to push for
deletion.


Home | Main Index | Thread Index | Old Index