From owner-svn-src-head@freebsd.org Sun Jul 8 06:25:47 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 118A7FF1E94 for ; Sun, 8 Jul 2018 06:25:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CAC283799 for ; Sun, 8 Jul 2018 06:25:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w686PUtA033421 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Jul 2018 09:25:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w686PUtA033421 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w686PTnY033417; Sun, 8 Jul 2018 09:25:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2018 09:25:29 +0300 From: Konstantin Belousov To: Warner Losh Cc: "Rodney W. Grimes" , Eugene Grosbein , Andrew Gallatin , src-committers , 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> References: <201807080106.w6816V3r059288@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 06:25:47 -0000 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 wrote: > > > > > > > 08.07.2018 4:38, Warner Losh wrote: > > > > > > > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein > > > > 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/ 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.