From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751552AbdIWKug (ORCPT ); Sat, 23 Sep 2017 06:50:36 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:33300 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750814AbdIWKuf (ORCPT ); Sat, 23 Sep 2017 06:50:35 -0400 X-Google-Smtp-Source: AOwi7QCcJ66udUt7zNq4VMa97RM+/HA21V4XeNEMYHLjmpl2VBkQOx5H0d0vJPcZgxpW9ekBTB6mmQ== Date: Sat, 23 Sep 2017 12:50:31 +0200 From: Ingo Molnar To: Jean Delvare Cc: LKML Subject: Re: [PATCH] firmware: dmi_scan: Drop dmi_initialized Message-ID: <20170923105031.xd6qslfn3sgingn6@gmail.com> References: <20170918100551.4c3feea6@endymion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170918100551.4c3feea6@endymion> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jean Delvare wrote: > I don't think it makes sense to check for a possible bad > initialization order at run time on every system when it is all > decided at build time. > > A more efficient way to make sure developers do not introduce new > calls to dmi_check_system() too early in the initialization sequence > is to simply document the expected call order. That way, developers > have a chance to get it right immediately, without having to > test-boot their kernel, wonder why it does not work, and parse the > kernel logs for a warning message. And we get rid of the run-time > performance penalty as a nice side effect. Huh? Initialization ordering requirements are very opaque, and by removing the debug check any such bugs are actively hidden. How is documentation supposed to uncover such bugs once they happen? So NAK. Thanks, Ingo