Date: Fri, 29 Jan 1999 11:51:22 -0700 From: Brandon Gillespie <brandon@roguetrader.com> To: Robert Withrow <witr@rwwa.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: more modular rc/init/uninit system... Message-ID: <19990129115122.A25989@cold.org> In-Reply-To: <199901291406.JAA27108@spooky.rwwa.com>; from Robert Withrow on Fri, Jan 29, 1999 at 09:06:19AM -0500 References: <36B1739E.1A22A983@urc.ac.ru> <199901291406.JAA27108@spooky.rwwa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Fri, Jan 29, 1999 at 09:06:19AM -0500, Robert Withrow wrote: >=20 > joy@urc.ac.ru said: > :- I prefer to see all variables WITH their values (read "system > :- configuration") in the one file. >=20 > BSD plusses: All configuration variables are in one place. >=20 > BSD minuses: Relationships between installed components is hard-coded > in the rc files by the placement of code. >=20 > SYSV plusses: It is much more modular. >=20 > SYSV minuses: Configuration variables are scattered across the many > confugration scripts. Which is the core of what my issues are. I agree with all of the above, and we are pretty much suggesting the same thing--with slight variances on specific implementations. What I suggest is /etc/rc.conf, exactly as it is now--but playing a role more akin to a defaults file, with local overriding files in /etc/rc.conf.d. In actuality nothing is stopping somebody from simply ignoring /etc/rc.conf.d, and just changing rc.conf. The main gist I was trying to convey, however, was that the functionality (actual code, instead of variable definitions) of rc and rc.* is split out by behaviour. This alone is *ALREADY HAPPENING*--like I suggested, look at /etc/rc.*. I belive this to be a natural evolution of what people want (otherwise why not just put _everything_ in /etc/rc?) Following the idea of just modularizing the executable part of /etc/rc*, there are two options: 1) make Yet Another Standard, or=20 2. follow an existing and widely accepted standard, at least loosely. I believe 2. to be the better option, and thus suggested putting the scripts in /sbin/init.d and /sbin/rc.d (symlinked to init.d). Furthermore, as I stated in the web page the scripts *should not be changed* The only role they play is _order_. Whether something runs or not is managed by the config script. Because of this the admin should really _never_ have to touch the symlinks (unless they are making something new). And to address the issue of configuration variables scattered across various files. Imho this is an ADVANTAGE. One problem with the unified script is variables become scattered about. When somebody adds a new functionality to the rc system, they often just tack the defining variables onto the end of rc.conf. So when you go to configure things you go to the area for what you are doing, and you don't notice the new functionality. By breaking out into files it forces proper grouping. As for new admins having a hard time--comeon, it isn't THAT hard :) The variables are still stored seperately from the code. And if it is that hard for them, they would likely be using sysinstall (or some other app) to configure things anyway. > 1) a packages boot-time configuration script is packaged in a seperate fi= le > and placed in an init.d directory, as in the SYSV system. These scripts, > however, define shell functions with conventional names, instead of being > a case statment as in SYSV. Each <package> file would contain: So instead of calling the script with an argument, it instead sources the script into the current execution environment and calls a function? Dunno... what advantages does it have over simply calling a sub script with arguments defining its behaviour? I do like the dependancy and register parts, however. -Brandon --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: AY3cXCnus8fmnaNJ/g5IZ17DyXPABdRL iQA/AwUBNrIDKkv5XoQiMgn6EQLcjQCgzq9KBt0/sGPunx4PxEYO75hDrn4AoOZB 1L9VpBkHa1jbcH975JGzuTxy =ntHG -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- 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?19990129115122.A25989>