From owner-freebsd-hackers@FreeBSD.ORG  Thu Jun 21 18:01:45 2012
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id ED27E106564A
	for <freebsd-hackers@freebsd.org>; Thu, 21 Jun 2012 18:01:45 +0000 (UTC)
	(envelope-from wojtek@wojtek.tensor.gdynia.pl)
Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99])
	by mx1.freebsd.org (Postfix) with ESMTP id 2636A8FC12
	for <freebsd-hackers@freebsd.org>; Thu, 21 Jun 2012 18:01:44 +0000 (UTC)
Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1])
	by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5LI1gvm009409;
	Thu, 21 Jun 2012 20:01:42 +0200 (CEST)
	(envelope-from wojtek@wojtek.tensor.gdynia.pl)
Received: from localhost (wojtek@localhost)
	by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id
	q5LI1fNd009406; Thu, 21 Jun 2012 20:01:42 +0200 (CEST)
	(envelope-from wojtek@wojtek.tensor.gdynia.pl)
Date: Thu, 21 Jun 2012 20:01:41 +0200 (CEST)
From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>
To: Mike Meyer <mwm@mired.org>
In-Reply-To: <20120621134545.5e42b50e@bhuda.mired.org>
Message-ID: <alpine.BSF.2.00.1206211957500.9337@wojtek.tensor.gdynia.pl>
References: <4FDFB44D.9090308@gentoo.org> <4FE0ADCD.9010109@FreeBSD.org>
	<4FE0C123.8030301@gentoo.org>
	<CAGH67wRidMZrzjzTSdwud+Z5V--wOTN8CHXOWcOr+E5XHYo2rA@mail.gmail.com>
	<4FE0F773.1080403@gentoo.org>
	<CAGH67wQdb-c0Kf=60rkaJSH8Hd0OjwCi=rQQMzGq8xfp2q7b=Q@mail.gmail.com>
	<4FE100F9.2050009@funtoo.org> <20120620073920.GA5300@lonesome.com>
	<alpine.BSF.2.00.1206201618560.75278@wojtek.tensor.gdynia.pl>
	<CAPDOV49kkOdeV+6LVW5j5PO6VYrrNVqWZEksc_GzvWHjbufoAQ@mail.gmail.com>
	<20120620214006.GA1651@aspire.rulingia.com>
	<alpine.BSF.2.00.1206211159280.1662@wojtek.tensor.gdynia.pl>
	<20120621134545.5e42b50e@bhuda.mired.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7
	(wojtek.tensor.gdynia.pl [127.0.0.1]);
	Thu, 21 Jun 2012 20:01:42 +0200 (CEST)
Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject: Re: Replacing rc(8) (Was: FreeBSD Boot Times)
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2012 18:01:46 -0000

>> 1) "runlevels" with arbitrary names. runlevel change would start and stop
>> right services.
>
> With a couple of additions:
>     - it should be easy to see which services are on at a given runlevel.

already proposed in rc.conf

>     - it should be easy to see which runlevels a service is on at.

same.

>> service2_enable="NO"
>> service3_enable="foolevel maintenance"
>> service4_enable="YES -foolevel" (or ALL -funkyrunlevel)
>
> Using two symbols to indicate negation - one to start, and then one on
> each runlevel - is overkill. There's not a use case where you have a

better method already proposed by
jhellenthal@dataix.net

> But each line has become more complicated, going from a simple on/off
> setting to a small language that can even have errors (like "foolevel
> -barlevel"). This violates the second thing on your list of things we

see above.

> The downside is that it adding a service now becomes harder - you have
> to edit each runlevel script instead of just one.

i unable to understand this sentence. rc.d scripts would be exactly as 
they currently are.

extra data in rc.conf would define "runlevels" at which they are active.

doing this as currently (_enable=YES) would mean every "runlevel".

my point is that if you put new startup system in place of old, nothing 
will change with your existing rc.conf!