From owner-cvs-all@FreeBSD.ORG Mon Sep 24 17:25:23 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C3D16A46C for ; Mon, 24 Sep 2007 17:25:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB5D13C45D for ; Mon, 24 Sep 2007 17:25:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1229658nfb for ; Mon, 24 Sep 2007 10:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=z0L0flR3hRJPakKWWtVDaxxGPCXpDTn+XQXqJB3Nr24=; b=p9jLrh6ENcQoPgyjWwst5mZmZBh1XHyeAh3Mdm6IOCNXqJS9fnsMrXFPOduHKkL5y53P99CnXn7Eo/wwMbi8FJDljQlvNxCPa7RF6ylsTUvENTCzyFibDmzlyZ1mIyt5dHDFfBWMdGWcZcqvc/lZXT3SJjqL4nkKkOtlwoSL4p4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VVUplNVwSV3ft2kSVvCF8DYSHSwxiOQAyr78xifPZjsdYBySok5zOMLAYTa+B2FJ07gcVZjXqvqto0eKGzdvL28A36rXB26uvbie1PzZxVVBZL8K1w/8yNKQrqgIgsTdt2Nqh3zhWybE98MZ2is4WFFnNIXgS/GZRG9vSnZxrF8= Received: by 10.78.149.13 with SMTP id w13mr2048313hud.1190654721060; Mon, 24 Sep 2007 10:25:21 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Mon, 24 Sep 2007 10:25:21 -0700 (PDT) Message-ID: <3bbf2fe10709241025r4e0d25c6x328ac21dc6bc99c@mail.gmail.com> Date: Mon, 24 Sep 2007 19:25:21 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200709241147.49288.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709112254.l8BMsB7P074637@repoman.freebsd.org> <200709211436.15444.jhb@freebsd.org> <3bbf2fe10709211338j6dbab59am1ad67c86c1a05baa@mail.gmail.com> <200709241147.49288.jhb@freebsd.org> X-Google-Sender-Auth: d9b615b9d28346e1 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 local_apic.c src/sys/i386/acpica madt.c src/sys/i386/i386 local_apic.c src/sys/kern subr_smp.c src/sys/sun4v/mdesc mdesc_init.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2007 17:25:24 -0000 2007/9/24, John Baldwin : > > It's a gratuitous change if you aren't actually _fixing_ anything. I think > there is a fundamental thing you are missing here though: it is ok to have > multiple SYSINIT's with the same subsystem and order if they are independent. > All device drivers register themselves with new-bus at the same subsystem and > order for example. There is no need to "dream up" a false ordering if it is > not needed. Now you have made B always come after A. What if a future code > change makes A depend on B? It is best to solve these problems when they > appear. I don't, personally, think this approach is fine and last efforts in order to fix topology basically showed what I'm saying. However this is just an opinion of mine, so this is nothing of highly definitive. > > Plain wrong? > > You mean maybe that it doesn't matter that (SI_ORDER_CPU -1) was > > shared with mptable_register()? And what about if someone adds > > dependency between the two? madt changes are perfectly working as they > > don't explicitly require to run before of mptable_register(). > > And to be precise, there is no madt_register() in amd64, so I have no > > idea what are you speaking about. :(. > > I guess you don't understand what these register routines do. Whee, please, I don't think one needs a big fantasy in order to understand them, and I think currently there are a lot of more difficult bits in the kernel than these functions :) My question is: what makes you so unconfortable with this patch? The ordering is fine, some things can be switched as they don't directly depends by each other but definitively they are in a good ordering. In the future you won't have problem of messy startup and if you really need to change the order you can do explicitly. So the problem is ...? > See above. Are you going to go throw and assign a static order to ever device > driver now just in case the one's registration routine might someday depend > on another? Yes, and it doesn't sound so unreasonable. > It hardcodes an ordering that isn't there and that might have to be reworked > in the future if a real dependency does show up that is not the order you > currently just randomly chose. randomly choose? Please be pragmatic. This ordering is not failing at all. I cannot think, for example, cpu_startup() to run after lapic bits... Attilio -- Peace can only be achieved by understanding - A. Einstein