https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211528
Matthew Macy <mm...@nextbsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mm...@nextbsd.org
--- Comment #4 from Matthew Macy <mm...@nextbsd.org> ---
(In reply to Ben RUBSON from comment #3)
There are two problems with this:
The one that gives me say:
1) The linuxkpi that drm-next uses is very different from the linuxkpi in HEAD.
Adding COMPAT_LINUXKPI to HEAD would essentially preclude ever supporting
anything newer than Haswell on FreeBSD with a GENERIC kernel config. It's safe
to say that there are a lot more users of X11 on Intel hardware built within
the last 3 years than there are IB users.
The one that really bother me:
2) Once a driver is in GENERIC there is no established mechanism for removing
it. The kernel is reaching upwards of 30 MB. Unlike Linux and everything else,
FreeBSD has no namespacing for modules statically linked in to the kernel. I've
hit namespace conflicts between the linuxkpi and 20 year old raid drivers. The
driver has no reason to be there now and should have its own namespace even if
it does.
FreeBSD is already several times slower booting than linux. A large part of
this is due to the fact that it runs the probe routine for every PCI driver at
every PCI node in the device tree.
Thus with any driver being added to GENERIC, the question should be: "is this
device needed to work out of the box?" For drivers like em or igb the answer is
yes. For most things the answer is no.
I assume that you're not really asking to further slow down boot times, bloat
the kernel, and create a perpetual burden on developers. What you probably
really want is for device support to automatically load the modules as needed.
If that's the case, take a look at Warner's initial work and see if you're able
to apply that to mlx:
http://bsdimp.blogspot.com/2016/01/details-on-coming-automatic-module.html
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
