Date: Thu, 26 Oct 2017 07:41:21 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: Colin Percival <cperciva@tarsnap.com>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: RFC: Removing hpt* drivers from GENERIC Message-ID: <20171026054121.jovsq5d7j4wqzci2@ivaldir.net> In-Reply-To: <15E3ADE8-A648-4408-AFCC-EA904CBEA4F5@fubar.geek.nz> References: <0100015f557d9cd2-098d2e99-d4c4-45ce-90bf-47b76455a6de-000000@email.amazonses.com> <15E3ADE8-A648-4408-AFCC-EA904CBEA4F5@fubar.geek.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
--mgh5dhiqlnm445op Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 26, 2017 at 03:12:57AM +0100, Andrew Turner wrote: >=20 > > On 25 Oct 2017, at 22:43, Colin Percival <cperciva@tarsnap.com> wrote: > >=20 > > Hi developers, > >=20 > > I'd like to remove the hpt* drivers from GENERIC. These are the drivers > > for the HighPoint storage hardware -- SATA (hptnr) and RAID (hpt27xx, h= ptiop, > > hptmv, hptrr). > >=20 > > My reason for wanting to remove them is that the hpt27xx and hptnr driv= ers > > spend ~150 ms in their DEVICE_PROBE routines every time the system boot= s. > > Since they are roughly 1000x slower than the median driver, this is cle= arly > > excessive; unfortunately the time is being spent inside a binary blob, = so > > there is no apparent way to fix the drivers. (The other three drives f= rom > > the same vendor -- hptiop, hptmv, and hptrr -- don't exhibit this parti= cular > > bug, but I don't see any strong argument in favour of not removing them= along > > with the two problem drivers.) > >=20 > > All of these are available via kernel modules, so the impact upon users > > should be minimal. Obviously I would not plan on MFCing this change. > >=20 > > Any objections? GOGOGO >=20 > Why are we building these binary blobs into the kernel? We don=E2=80=99t = have the source for these so it=E2=80=99s more difficult to audit them for = security issues. If the user wishes to load them as modules they are fine t= o do that, however I don=E2=80=99t think we shouldn=E2=80=99t be linking an= y of these blobs in a GENERIC kernel. I totally agree here! Bapt --mgh5dhiqlnm445op Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlnxdX4ACgkQY4mL3PG3 Plr7kQ/+PnMcYUKZ//6VOnm9Rom5ZsAj+zWcYQG8Ph4vvRFJNS4G9cggbVPqL8PY XFLFOAdPBOfkrU9ZKKxLGVO4TCVT4Vgno/tNqJrwTKrc+AHFsEB0cfkG0W+/oiyw qU5svflkyH0vhqQi2GtDB7V/EAqqvGVoUSiulXFi5dVBF+sPbA2py7Ix7Ql7Xnv9 dWdRVIduIoxfSZ/YNQbzTfEO43HbI+JSssIn+JQ0nThu6nicrUelpdpiv6YzGN2D 4BV38v58KLOCYJaOF6Vq6j9fKIkNwe5QuZV35oui0RbcmxjyqKW4Dwd9sun4v3vp F6M/Bb4HoQiBxpwSuEQnCph284RZyoweqJuUDU33FwpoEcR7I4i2NXghLSA1CGq0 zJKknD8SF2jOSf5faVH7nMG0ZJH6xS3iISMn0sXaFS4LkCOwHWlq/DvbFVW6RCro jPnDhsD6Lgc/yyPRXkkDZjYltjAdLpwuEti7T+z5Axw29BE4fxfgl5rqFYHnv4qJ NqvG4hFWBlXt2DADWU35ZsYvln+PSBwCj9dWv8lCRgNQWvy92JAd4e/5E6R8/492 NFVC+58nmoow2hskOeoe0vwQ+6VUjV8SxE7VY8wYsGhCIWJe11uBjTt6GEhQJytj CnsKPwTNHOn39Xip8dWmUc4Ch/xhl3pXLo2eQG6WJ7anpvlL0CQ= =dnWO -----END PGP SIGNATURE----- --mgh5dhiqlnm445op--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171026054121.jovsq5d7j4wqzci2>