From owner-svn-src-head@freebsd.org Sun Jul 8 04:46:26 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 CC38DFE9090 for ; Sun, 8 Jul 2018 04:46:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 610F080480 for ; Sun, 8 Jul 2018 04:46:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id 188-v6so22294680ita.5 for ; Sat, 07 Jul 2018 21:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DpDlHy6iBUOdwRKK3HEVxcmo5Qc4BoCmco8v1ed6ahg=; b=B02J7BdY83frG61dW9H/F+utZG11s9UGTGGr/3uPDdvonSnUnzLliYoCIzECkOibLL VvbpelterWYYp/VUNbmCxfeFcjCoJsuujgChgfFNAGznI3qHDnZi40jjqYYXpw3AyYSm m5khN2+e4smo1CEvG4z5fXa8HCbFBpCAsSgzsYjyEuQYuTAO6q3GZSPaL1VFXNWzNtgj r5J6wM4KaeBHepoUtxeiFhUxly/qR8E8JiJOc6cHB0vJZfSD1PdwzUJnsPJvqODj2Hwm 39VxuadP6LcOFTFrMqqkY3aZ5vemelW1YYCcv5oOYmKSNVoPJL4p4xnVgIbfhN3qIvim SrQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DpDlHy6iBUOdwRKK3HEVxcmo5Qc4BoCmco8v1ed6ahg=; b=Fo9bmRgVfaHFE5E3xXLcifag9YjwiluIIN6HWJ70YRiliFmbTKQBiwrKQxuNcUZ2iH //r9Z6ihVCDid5bCO1zNSl3GXsx59gmFUPvJhc2Ya5+8DyY7rwZXCqCGFxEsUJyC7yMK UxFYQUAnedTiiyAs4Yo77IG+/fq/9ospXSGkx72JVvNre5PMg/+CZ69WQEbOeRT1PnZT 8iojNLSrQmDbrRE2xfiK7T1i/MgrgfSsjmoaQOgylYNAPt3kh2M7X259kOAA54O3nrbV q/ANcKxURIo9/enmMCPqAQoPMzLtMCEGNz4jEvQZdtwUKwepHrpWSZ1sBvHg5+CjAq6E ufRA== X-Gm-Message-State: APt69E1ekO272wtn7BOatjZt5X3sbTFlafXzD7GSoRNA31b7fsjtxi6C DWnVNWlWNE4njQ+BSu5BA8S6YWBek4c/RqESKGJDhA== X-Google-Smtp-Source: AAOMgpfZr2406kw5nNfD0+y4zXU5isrrzV8Kv3fbSt2GFNgm4L4h289OIO7xb8uv7oX+vI4DuTLLCZmJBQ4AiJ2JwEw= X-Received: by 2002:a24:d0d7:: with SMTP id m206-v6mr12062724itg.1.1531025185561; Sat, 07 Jul 2018 21:46:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:1183:0:0:0:0:0 with HTTP; Sat, 7 Jul 2018 21:46:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201807080106.w6816V3r059288@pdx.rh.CN85.dnsmgr.net> References: <201807080106.w6816V3r059288@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sat, 7 Jul 2018 22:46:24 -0600 X-Google-Sender-Auth: 54AfneZcvnFQEQ9b4uqPWw9wrNg Message-ID: Subject: Re: svn commit: r335916 - head/sys/conf To: "Rodney W. Grimes" Cc: Eugene Grosbein , Andrew Gallatin , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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 04:46:27 -0000 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. Warner