From owner-freebsd-rc@FreeBSD.ORG Sun Dec 4 07:23:29 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF5B916A420; Sun, 4 Dec 2005 07:23:29 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CC4243D5C; Sun, 4 Dec 2005 07:23:26 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jB47NM4A076469; Sun, 4 Dec 2005 10:23:22 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jB47NGXH076466; Sun, 4 Dec 2005 10:23:16 +0300 (MSK) (envelope-from yar) Date: Sun, 4 Dec 2005 10:23:15 +0300 From: Yar Tikhiy To: Brooks Davis Message-ID: <20051204072315.GA75603@comp.chem.msu.su> References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> <438E4FCB.8060806@FreeBSD.org> <20051202080604.GA12291@comp.chem.msu.su> <20051202163539.GA22464@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051202163539.GA22464@odin.ac.hmc.edu> User-Agent: Mutt/1.5.9i Cc: freebsd-rc@freebsd.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2005 07:23:29 -0000 On Fri, Dec 02, 2005 at 08:35:39AM -0800, Brooks Davis wrote: > > > > > > A few comments: > > > > > > > > - I have this vague feeling that we should replace most dependencies on > > > > mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. > > > > This isn't important. :) > > > > > > Right, this can be revisited later if needed. The more I thought about this > > > the more I liked the concept of what JR suggested, although obviously I > > > implemented it in a slightly different manner. I'm hesitant to add more > > > pseudo-targets, as I think using mountcritremote is a good "clear bright > > > line" for this purpose. I also have a fantasy down the road (not sure how to > > > implement it yet) of making the point to split early/late configurable. For > > > example, I can imagine a scenario where someone might want to put the split > > > at mountcritlocal. However, this is a good safe place to start. > > > > With a pseudo-target for filesystems, will we still need the split > > hardcoded in /etc/rc? Using a single run of rcorder should be > > sufficient if all our rc.d scripts specify correct interdependencies > > between each other. Using the pseudo-target would be a natural way > > of doing so while keeping the possibility to move the split up and > > down the boot sequence. > > You have to run rccorder twice because until mountcritremote (or an > equivalent pseudo target) you aren't garenteed to have access to all the > files rcorder needs to parse. Now I see. I obviously missed this point. Thanks for clarifying it. However, are there plans to allow for ports inserting theirselves in the early stage? E.g., a 3rd-party routing daemon can be needed to fully start the network prior to doing mountcritremote. And if the routing daemon were built against older libraries in addition, it would need the compat libraries in /usr/local/lib/compat added to the ldconfig search path in advance. This is the case I myself ran into once. Making the split between the stages movable to mountcritlocal, as you proposed, would be a solution. This can be generalized to an rc.conf variable indicating the name of the rc.d script to put the split after. -- Yar