From owner-freebsd-current@freebsd.org Sat Feb 16 19:34:55 2019 Return-Path: Delivered-To: freebsd-current@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 C9F2214F268B for ; Sat, 16 Feb 2019 19:34:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1686A9794E for ; Sat, 16 Feb 2019 19:34:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id C0FD014F268A; Sat, 16 Feb 2019 19:34:54 +0000 (UTC) Delivered-To: current@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 80F3914F2689 for ; Sat, 16 Feb 2019 19:34:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 038B49794D for ; Sat, 16 Feb 2019 19:34:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id f196so7742383qke.10 for ; Sat, 16 Feb 2019 11:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P3WOm8C0hTHZnVeGoHogY6yNmfXHU7vSP2KZRF/7fmM=; b=SGbRjbOdKpDAYhXkJC9KS4zBV1NtngD9/oM5K1iKkGnQe9wXHn3ZovQQT1MSSoA0iy fEgDwMpeOpgR+qbYinFQLmsxvH5IajMN1Pua1KwcSqDWJZDHPgPtISx6j0bJmghfzYkk ayPTUyOt7+1FtPIgLC8wRHAiFP77S0IhlCxlT0a4ii9bttkllhIZbAVIdMRE6Vo8KAVV 2grX0sMIZlZ7TyKRZ9qjQVX4o0pFtL6W3clD5wTX9Vqfn/WcG6+Cu6+b0E1jkZ3AwVIS bUOlizskxXpsJB9Or8RfAbC6rHoUOapZug67cjM+VJUu0ZUQJL51OW5qIVABdpsXAtN7 HYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P3WOm8C0hTHZnVeGoHogY6yNmfXHU7vSP2KZRF/7fmM=; b=FlNDwbX3hrpZqIkrdxq6fdkzYV0Wx2IC69uMq8WHxw5MEE3T8zwBerN0M1f5ApoKba KuxvqmRXfoHc6Fx5CU7myLTmGwkC/s6C+qGAIY/KhtjI8q1bHT+O/DjT++Zdba1sbWbk 0UgKdeyTmZ5Uyg5tUL3KHP+EMJDc4Bbmv5OeG3bhw+X/udJ7ayolUC981LMD4zorQFrt O7BjrvSzEg3fxNT0mFxj/LniquEjkCz5VRqCFfd6DP0wl16uddM+C7UBrxquGKsRDloq eo9aNtG5SpsOC1eJRwBRRRybf81ap0z/q0divRZ/GtTXcsy7lTvn3ku5prH2FXYSonAT bx/w== X-Gm-Message-State: AHQUAuZSTl8+n2PhB6Evv2+/l4GLDxriaooVd7EFxU7M+9fxd4E1DXCE u9nMwnieTaRRmbRIhpeGMXAA96KYhvTNcbBOtth5mA== X-Google-Smtp-Source: AHgI3IY1g4nw0W9bo0gGd5vCWqdowaV8vfzhHWay36xmP9YKITFqtj7Jt4+jtGrxZwAlWNBMg3llz1O5B2+8eFDTUBM= X-Received: by 2002:a37:6fc2:: with SMTP id k185mr1123972qkc.175.1550345693150; Sat, 16 Feb 2019 11:34:53 -0800 (PST) MIME-Version: 1.0 References: <77EDD0AB-BAAC-460F-B2E1-46ABA5045178@gmail.com> <201902161531.x1GFVC2b096692@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902161531.x1GFVC2b096692@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sat, 16 Feb 2019 12:34:42 -0700 Message-ID: Subject: Re: problem building dev/e1000 To: "Rodney W. Grimes" Cc: Enji Cooper , Robert Huff , FreeBSD Current X-Rspamd-Queue-Id: 038B49794D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 19:34:56 -0000 On Sat, Feb 16, 2019 at 9:16 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > On Feb 15, 2019, at 11:47, Robert Huff wrote: > > > > > > Lev Serebryakov writes: > > > > > >>> My question would be: why? If some drivers have a new > > >>> dependency on iflib, why isn't that expressed in sys/conf/files > > >>> and handled automatically? > As expressed elsewhere that gets a bit messy when it is more than > just a few things that depend on this module, and historically > has been done by adding comments to GENERIC that describe the > dependency in the form of "requires iflib". > > Though there are some ideas floating around that might better > address this, for the time being that is how it is being handled. > > > >> My question exactly. > > > > > > I am so glad people who know what they're talking about have the > > > same response I did. :-) > > > > I totally missed the part where Robert said he was compiling it > > into the kernel. Also, I remember the days when drivers didn?t > > automatically compile in dependent options (example: ?device re? > > requires ?device miibus?). I guess things have changed a bit in > > the past year [while I was away] with some drivers? > > Thanks, > > -Enji > > > Respectcfully, > > > Robert Huff > > Nothing has changed, other than we now have another miibus > type thing called iflib and there are a half dozen drivers > that need to have iflib compiled in if you use them. What > is new is that these drivers already existed in the past, > but have been re-written to use iflib, so if your carrying > an old kernel config file around and update accross the > iflib'ification of that driver you have to pick up the > change that went into GENERIC that pulls in iflib. > That's always been true. We've never really had good support for invariant kernel config files on the branch that weren't derived from GENERIC in some way. Some recent branches have been better about this, but there's plenty of precedent in the past where changes like this have become required for this driver or that. > These are probably the types of changes that we should > consider not merging to something called stable/. > Generally, I tend to agree. However, apart from making the iflib standard, and impossible to remove, there's little that can be done in this case. We've made minor changes like this to kernel config files in the past, and merging this work would fall under that precedent. Not something to be done willy-nilly, but also not something to not do if the consequences of not doing it are worse than doing it. For our low end, already starting to feel the squeeze, being able to compile this out is a needful thing. config(8) sucks. Plain and simple. It's difficult to work on, doesn't express what it needs to, and is hard to transition away from. We are stuck with it for the life of the 12 branch (and like 13 and 14 too). It's easy to solve 80% of the problems with it, but hard to do so without introducing more problems that are much harder to paper-over. It needs to be taken out behind the woodshed and shot, but it does it job adequately enough that any replacement will have hard shoes to fill, especially since the number of weird, idiosyncratic edge cases config leans one way or the other have become expected and are actually the right thing to do. We also have enough velocity in the files, options and other files that trying to write a replacement and keep up is hard. tl;dr: config(8)'s unique quirks may force us to do things we'd rather not. Warner