From owner-freebsd-embedded@freebsd.org Thu Jun 21 15:40:48 2018 Return-Path: Delivered-To: freebsd-embedded@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 5ABE910222D6; Thu, 21 Jun 2018 15:40:48 +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 0BA3B81D9C; Thu, 21 Jun 2018 15:40:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (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 9C59E2F9B5; Thu, 21 Jun 2018 15:40:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f46.google.com with SMTP id g21-v6so4987933lfb.4; Thu, 21 Jun 2018 08:40:47 -0700 (PDT) X-Gm-Message-State: APt69E3l5k0hIwR7JdNeqafTxkp2AS+ovVbN41rOGu9Nvh7rkvXkwyxH mmes/VEW3+Pg2BZn7Q33DMbnI6S9ahxml9HX+9M= X-Google-Smtp-Source: ADUXVKJ71KdHSGeK2egJTy28Wm/Ylelnl20f3mw7s88HThnV8pO22a+jD6U8KNAraeUvuu74oIl6KY8zXPqn2l8suOY= X-Received: by 2002:a19:d046:: with SMTP id h67-v6mr15635995lfg.52.1529595646097; Thu, 21 Jun 2018 08:40:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:40:25 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Thu, 21 Jun 2018 10:40:25 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Proposal: envmode/hintmode rototill To: freebsd-arch@freebsd.org Cc: freebsd-embedded@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:40:48 -0000 On Wed, Jun 20, 2018 at 11:38 PM, Kyle Evans wrote: > 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 I've created a phabricator review for my proposed patch here: https://reviews.freebsd.org/D15953 -- this contains the actual rototill as well as associated config(5)/config(8) changes. Thanks, Kyle Evans