Date: Sun, 8 Jul 2018 09:25:29 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Eugene Grosbein <eugen@grosbein.net>, Andrew Gallatin <gallatin@cs.duke.edu>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r335916 - head/sys/conf Message-ID: <20180708062529.GV5562@kib.kiev.ua> In-Reply-To: <CANCZdfoFv=-umZx3%2BXvmjpOURp3YinafTK_jVT9gCEvZ3vA1rw@mail.gmail.com> References: <CANCZdfoOyMi=LpRYnv7=sF4OvOMd4TJ99dSpPEnerWSQCX1Wfg@mail.gmail.com> <201807080106.w6816V3r059288@pdx.rh.CN85.dnsmgr.net> <CANCZdfoFv=-umZx3%2BXvmjpOURp3YinafTK_jVT9gCEvZ3vA1rw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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 < > freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein <eugen@grosbein.net> wrote: > > > > > > > 08.07.2018 4:38, Warner Losh wrote: > > > > > > > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein <eugen@grosbein.net > > > > <mailto:eugen@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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180708062529.GV5562>