From owner-svn-src-head@FreeBSD.ORG Tue Jul 12 19:46:10 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C804F1065677; Tue, 12 Jul 2011 19:46:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 85AF88FC18; Tue, 12 Jul 2011 19:46:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E25446B0A; Tue, 12 Jul 2011 15:46:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92D1A8A02F; Tue, 12 Jul 2011 15:46:09 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Tue, 12 Jul 2011 07:58:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107102347.p6ANl3qK066321__21248.7196004533$1310341655$gmane$org@svn.freebsd.org> <201107111114.33159.jhb@freebsd.org> <4E1B919F.7000800@FreeBSD.org> In-Reply-To: <4E1B919F.7000800@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107120758.30202.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Jul 2011 15:46:09 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pan Tsu Subject: Re: svn commit: r223917 - head/etc/rc.d X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:46:11 -0000 On Monday, July 11, 2011 8:13:19 pm Doug Barton wrote: > On 07/11/2011 08:14, John Baldwin wrote: > > On Sunday, July 10, 2011 8:53:31 pm Doug Barton wrote: > >> On 07/10/2011 17:42, Pan Tsu wrote: > >>> Doug Barton writes: > >>> > >>> Doesn't /boot/support.4th already populates kern.module_path with > >>> the path of successfully booted kernel? How is this different? > >> > >> When you test it, what happens? > > > > If you do 'boot foo' at the loader prompt you get > > /boot/foo;/boot/kernel;/boot/modules. > > No, I don't actually, which was my point to Pan: > > sysctl kern.bootfile > kern.bootfile: /boot/kernel.patched/kernel > > sysctl kern.module_path > kern.module_path: /boot/kernel;/boot/modules;/usr/local/modules > > That was after hitting "2. Escape to the loader prompt" at the beastie > menu, and typing 'boot kernel.patched'. The fact that it did not work as > one might expect was the reason I wrote the code that I did. Is this on HEAD? Perhaps the new boot loader menus recently imported broke this. > > It is arguably broken that the old /boot/kernel is still in the list, but that > > bug should be fixed in the loader, not here. > > I think that given the fact that we seem to have multiple broken > versions (as in, my version is broken one way, yours seems to be broken > a different way), it's hard for me to imagine removing the "belt and > suspenders" that I've already added. Not to mention the need to support > RELENG[78]. Well, I am basing off the behavior that the boot loader has had from 5.x up through 8.x. It may be that the new stuff aded to 9 last month by Julian broke this. > > However, I've never had a > > problem with kldload doing the wrong thing when using 'boot foo'. Do you have > > an actual use case that is broken? > > I was initially hoping to avoid the gymnastics, but given that > module_path wasn't doing TRT I thought it safe to err on the side of > caution. No, I think module_path should be fixed instead as if module_path is broken then 'kldload foo' at a prompt is also going to do the wrong thing. > > Oh, and if you use 'nextboot -k foo' or set 'kernel=foo' in loader.conf then > > it will DTRT. However, I would expect this script to be equivalent to a for > > loop of 'kldload foo', but now it isn't since you are using a divergent > > algorithm. That violates POLA IMO. > > It's not clear to me how what I'm doing is different than what _should_ > be happening. If you can spell that out to me I'd really appreciate it. If you do 'boot kernel.foo', then /boot/kernel.foo/ should be in the module_path which is what the kernel linker (when it autoloads a module on demand such as a firmware image or filesystem module) and kldload both use to locate klds. All of our various ways of loading a KLD should be following the same approach to avoid confusion, and using module_path does work fine on at least <= 8. It may be that there is a bug in the new boot loader stuff in 9 in which case that is what needs to be fixed as if module_path is broken, kldload and the kernel linker are also going to be broken. -- John Baldwin