On Sat, Jul 07, 2018 at 10:46:24PM -0600, Warner Losh wrote: > On Sat, Jul 7, 2018 at 7:06 PM, Rodney W. Grimes < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein <eu...@grosbein.net> wrote: > > > > > > > 08.07.2018 4:38, Warner Losh wrote: > > > > > > > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein <eu...@grosbein.net > > > > <mailto:eu...@grosbein.net>> wrote: > > > > > > > > > > 07.07.2018 22:02, Andrew Gallatin wrote: > > > > > > > > > > > One thing that was tangentially brought up is that the ability > > > > > > to compile out-of-tree modules requires keeping the > > kernel-headers > > > > > > around. So we may need to identify all the headers that a > > module > > > > might > > > > > > need, and install them in /boot/$KERNEL/sys or some-such. This > > > > would > > > > > > be needed if, for example, we wanted to install a new Nvidia or > > > > Virtual > > > > > > Box module and have it work for older installed kernel > > versions too > > > > > > (eg, across ABI breaking changes in -current). > > > > > > > > > > We already have all headers in /usr/include, don't we? > > > > > > > > > > > > > > > Not really. We have a subset of the kernel headers that might not > > match > > > > the running kernel, nor be enough to build modules. > > > > > > > > They should match running kernel definitely as we do not support not > > > > syncronized kernel/world > > > > and installworld populates /usr/include. > > > > > > > > > > Nice theory. Lots and lots of people run this way. And it has worked > > well, > > > so long as the kernel is newer... so, no, they don't have to match. > > > > At some point I had an evolution of "make includes" that would work > > without the other parts of src being present (ie, only sys) so that > > you could update /usr/include with the kernel headers if you reved > > your kernel sources. > > > > Not sure how hard this would be to reimplement, but basically skip over > > missing parts of the src tree with a message (echo) that it could not > > find that particular set of sources was how it worked. > > > I really don't like this idea. It assumes The Kernel and The Includes. > However, that's not quite right. For people running releases, it's near > enough, but for developers it's not. I have, in the past, installed a > weekly kernel into /boot/kernel.$DATE and kept a constant userland. I did > this to catch performance regressions by being able to reboot quickly > between then. At any given time, we'd not have the right headers with this > scheme. Certainly not good enough to compile a module against the currently > booted kernel. > > I've started to like the idea of keeping module sources for 3rd party > modules /usr/local/<mumble> and using that to rebuild the module for a > specific kernel. If we were to install the kernel includes / opt*.h files > also into /boot/$KERNEL/include somehow, then 3rd party modules could be > rebuilt at any time and we'd always have access to the builddir files that > matter... Something to consider... I think I read that Linux did this to > help prevent module breakage when new kernels are used... It may be time > to ditch /boot/modules entirely in favor of a scheme like this. > > > /usr/include is never, ever used to build the kernel (except for things > > > like aicasm). > > > > Is not /usr/include really the kernel/userland interface, > > not the kernel/kernel interface? > > > > Yea, and more. It's a bit of hodge-podge, but on the whole, that's not an > inaccurate characterization. Especially the bit about it not being the > intra-kernel interface.
Building modules against /usr/include/sys mostly worked until recently, esp. if the proper default options were empirically collected into module' Makefile (like -DVIMAGE etc). Now with the ck use, and the fact that ck headers are not installed, this is impossible. You need the full kernel sources for module build. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
