From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 15:03:33 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6EAB106566B; Sun, 20 Jul 2008 15:03:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 67E2C8FC0C; Sun, 20 Jul 2008 15:03:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KKaRd-0008h9-Hl; Sun, 20 Jul 2008 18:03:29 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Peter Ross In-reply-to: <20080720200229.T894@oldie.bigpond.com> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> <1216473536.1991.5.camel@wombat.2hip.net> <20080720003343.S23554@oldie.bigpond.com> <20080720200229.T894@oldie.bigpond.com> Comments: In-reply-to Peter Ross message dated "Sun, 20 Jul 2008 20:30:06 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 2008 18:03:29 +0300 From: Danny Braniss Message-ID: Cc: Doug Barton , Robert Noland , freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 20 Jul 2008 15:03:33 -0000 > On Sun, 20 Jul 2008, Danny Braniss wrote: > > > I went ahead with my idea - to reduce the list rcorder delivers, by > > eliminating those that don't have ${name}_enable, and I opened a pandora > > box :-) > > - dummy dependency like SERVERS/LOGIN don't have ${name}_enable > > nor should have. > > Two options: > - Just eliminate the scripts that have the variable, and set it to "no" > - A dummy entry in /etc/defaults/rc.conf with "# Don't overwrite this" > (So only one who really knows what he is doing will try it - hopefully) > as usual I forgot one word, don't have ${name}_enable should have been: don't have ${name}_enable="YES" (or true or 1) personaly, I prefer self-contained, like iscsi_enable=${iscsi_enable:-"NO"} instead of adding it to /etc/defaults/rc.conf, though I can see the benefit. what I'm trying to say, is keep the complexity to a minimum, less foot-shooting :-) > > - REQUIERE: xxx complains if xxx is not 'loaded' like in the case > > of NETWORKING requirement of ppp which I don't have enabled. > > Solved by point 1? > > > - some scripts rely on the existance of a ${file} which is better than > > the original /etc/rc which used to run mountd if /etc/exports existed, > > but does not 'conform' to the ${name}_enable paradigm. > > The same? > > > - some scripts like abi don't have abi_enable, but sysvipc_enable, > > linux_enable and svr4_enable. > > I looked at this. abi is in fact a container for three start scripts. > > Of course splitting them makes the situation worse.. > > If the ${name}_enable check becomes a function > some special cases could be treated in a case statement > > case ${name} of > mountd) > if [ -f /etc/exports ]; then result=1; fi > ;; > abi) > if [ checkyesno sysvipc -o checkyesno linux_enable .. ]; then > result=1; fi > ;; > *) > enable=eval \$${name}_enable > if [ "X${enable}" = "X" ]; then result=1 > else result=`checkyesno ${enable}`; fi > ;; > esac > > [That's untested demo code and may contain typos] > > Unfortunately the rc.d scripts are not self-contained anymore. That may > offend some. But there is shared *.subr code already. > the initial idea behind rcng (was it called like that?), was, and most of it is still good, it's nicer that the monolithick /etc/rc of old, and less messy than sys5's. lets try and keep it 'simple' - as usual the KISS principle has more than one interpretation :-) > > All these - and some more that I probably missed - can be fixed, or the > > warnings ignored, but is it worthwhile? > > That's a good question. It is up to the users of "slower" hardware > (e.g.embedded devices), I think. > yup, on the other hand, servers take so long to boot nowadays, that speeding up rc, IMHO, wont make a difference, or even if it's fast, a fsck that's running in the background will slow the host anyways :-). > Regards > Peter cheers, danny