Date: Thu, 5 Oct 2000 13:19:05 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Doug Barton <DougB@gorean.org> Cc: FreeBSD Hackers <hackers@FreeBSD.org>, Sheldon Hearn <sheldonh@uunet.co.za> Subject: Re: Making /etc/defaults/rc.conf a configuration file. Message-ID: <20001005131905.A89144@mithrandr.moria.org> In-Reply-To: <39DC0003.713CF2B7@gorean.org>; from DougB@gorean.org on Wed, Oct 04, 2000 at 09:13:55PM -0700 References: <20001003033245.A63319@mithrandr.moria.org> <39DC0003.713CF2B7@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed 2000-10-04 (21:13), Doug Barton wrote: > Can you give more details about this process? I'm not sure how it would > work to change the list of conf files other than in the default location > if you're going to source the defaults anyway. defaults/rc.conf has ``rc_conf_files=/etc/rc.conf /etc/rc.conf.local'' rc.conf doesn't change rc_conf_files rc.conf.local sets rc_conf_files=/etc/rc.conf.script-generated rc.conf.script-generated doesn't change rc_conf_files So, we start with defaults/rc.conf, and read that in, and see listvar (rc_conf_files) says to look in rc.conf, so we read that in, and it doesn't set rc_conf_files, so we go to rc.conf.local, and read that in. It sets rc_conf_files to a file we haven't seen before, so we read it in. This may not be obvious, but it'll be obvious once it's documented. > > This only shows how to replace things using rc.conf - changing scripts > > to use periodic.conf is as simple as replacing > > > > if [ -r /etc/defaults/periodic.conf ] > > then > > . /etc/defaults/periodic.conf > > source_periodic_confs > > fi > > > > with > > > > rcfile=/etc/defaults/periodic.conf listvar=periodic_conf_files . /etc/sourceconf > > But you're basically doing exactly the same thing(s), just in a > different order. With all due respect to Neil, I stated previously that > I feel like this is a solution in search of a problem. I'm not arguing > for the status quo necessarily, I'm just concerned that when something > comes along down the road that *does* need to do something differently, > we will end up redoing all of this stuff again. I can't see how anything _can_ come down the road. It's an interface. If we want to read in configuration variables, we run the command. We don't care _how_ it does it, just that it does. If we need to change something, it'll be within that /etc/sourceconf file. > For what it's worth, I do not oppose the change, however I would like > to see some comments in the sourceconf file as to what is going on where > and why. I can't help feeling that sourceconf_start and sourceconf_dosrc > could just as easily be in the same function, but in my current state > I'm probably missing something. Also, in the sc.patch the entry for > /etc/rc has ". /etc/sourceconfs" instead of ". /etc/sourceconf". Oops, you're write, the patch won't work. That's what I get for generating the patch on another machine by hand, I suppose. The patch I've generated now (with just the one change) is the one I've actually been using to boot for the past few days. I don't mind adding mini-documentation to the scripts, I suppose, if that's required. > In any case, if the patch has been thoroughly tested under a variety of > different configurations, it's probably worth putting in -current. It > would probably be worth comparing what you're doing here to the work > that's happening on the rc files in netbsd that some here have discussed > bringing over, in whole or in part. We're not conflicting with anything that's happened in NetBSD. NetBSD's stuff is quite reasonable, but Daniel Sobral has pointed me at some things that he feels are missing, and I tend to agree after discussion with him. It is my plan (you probably heard me mentioning it) to investigate the NetBSD stuff properly, and compare it with slightly more featureful USM ( http://www.roguetrader.com/~brandon/sas/ ), which unfortunately may do too many things behind your back than what we're used to. However, I have a few things before that in my queue, and one of them is making it possible to develop a simple C API for reading our sh-style configuration, which somewhat requires that non-configuration code to disappear. (I should've continued when my suggestion was totally rebuffed last time, but I didn't have the time) Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001005131905.A89144>