From owner-freebsd-arch@freebsd.org Thu Jun 21 04:39:21 2018 Return-Path: Delivered-To: freebsd-arch@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 DA6231002A6D; Thu, 21 Jun 2018 04:39:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69DE9884F0; Thu, 21 Jun 2018 04:39:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (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)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 06C492B6E4; Thu, 21 Jun 2018 04:39:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f49.google.com with SMTP id m4-v6so1148995lfj.13; Wed, 20 Jun 2018 21:39:19 -0700 (PDT) X-Gm-Message-State: APt69E0xA39M2t4xcmpUxQPTmIrvRSD6+zjEYd9fsA3MIR+Jmdc3e1iN sNLpQ2jgAS9IzWHpi/9/5t2hIGb9PAWg+2VU7E4= X-Google-Smtp-Source: ADUXVKLZ4xqdn6UQAf6HxCynnF7/UvUU9omYVB8ssClncgbglAKmdEiTFSWOHH3OwDxp08v35aG8BzXp4ClOgC+Afmw= X-Received: by 2002:a2e:6506:: with SMTP id z6-v6mr6650919ljb.76.1529555958444; Wed, 20 Jun 2018 21:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 21:38:57 -0700 (PDT) From: Kyle Evans Date: Wed, 20 Jun 2018 23:38:57 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Proposal: envmode/hintmode rototill To: freebsd-arch@freebsd.org Cc: freebsd-embedded@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 04:39:21 -0000 Hello! The current situation with envmode/hintmode (see: config(5), `env` and `hints` respectively) is less than ideal, and conflicts with some future needs that I have. There will be a decent summary after the next couple paragraphs of background. The problem is that config(5) supplied env/hints are mutually exclusive with loader.conf(5)-driven kenv. The hints situation is slightly better as it can be altered with a sysctl that switches to the dynamic environment and thus pulls in any static hints supplied through config(5) along with whatever hints might have appeared in the chosen static kenv and those mixed in after the switch to dynamic environment. The way I need it to work is that config(5) supplied env is effectively a seed for the static environment. This would then get augmented with whatever MD environment (generally from loader(8)) has been specified. A poor example goal is to be able to have a kernconf with `options VERBOSE_SYSINIT` and debug.verbose_sysinit=0 set to quiet it by default, then have the ability to add in debug.verbose_sysinit=1 through loader(8) to make the VERBOSE_SYSINIT behavior verbose again. This is a bad example because this could be accomplished with `options VERBOSE_SYSINIT=0`, but I think it gets the point across- the kernconf environment is a set of reasonable defaults that may be overwritten by the loader. I had initially thought that maybe there were security considerations to be had here, but loader(8) static env can be switched to by including static_env.disabled=1 in said env- so it wasn't always ignored in the current world order. SUMMARY: I would like to: 1.) Eradicate envmode/hintmode 2.) Augment kernconf env with loader(8) supplied env 3.) Prior to the dynamic environment being setup, hint searches will be conducted across the two dfferent kinds of static environments (if applicable) as well as any static hints that were supplied, in order: loader(8) env, config(5) env, config(5) hints 4.) After the dynamic environment is provisioned (from loader(8) and config(5) environments), add in config(5) hints 5.) Once all of these environments have been merged into the dynamic environment, all hint searches should then just search the dynamic environment. This seems to be the common case for searches at the moment; the dynamic environment is completely merged by the end of SI_SUB_KMEM In the New World Order, there is no such thing as ignoring any of these environments. Each one is either provided or not, and the kernel will use them if they're provided. I have a pretty-close-to-finished patch implementing all of the above. Thoughts? Is there a reason this is a really bad idea? Thanks, Kyle Evans