Date: Wed, 23 Apr 1997 23:06:33 -0500 From: Chris Csanady <ccsanady@nyx.pr.mcs.net> To: hackers@FreeBSD.ORG Subject: Discussion of boot mechanism (Was Re: /etc/netstart bogons.. ) Message-ID: <199704240406.XAA02513@nyx.pr.mcs.net> In-Reply-To: Your message of Thu, 24 Apr 1997 09:27:59 %2B1000. <Pine.BSF.3.91.970424092151.10264R-100000@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >On Wed, 23 Apr 1997, Brian Somers wrote: > >> I like the idea of a "summary" at the top of /etc/rc (oh, and >> netstart should be rc.net as someone mentioned a while ago): > >That was me. I was just about ready to say "I'm changing netstart to >rc.net unless someone stops me", but I guess the change might come with >this sweep, unless rc.d takes over. I really would like to see an init.d stlye init mechanism, but I think we should think long and hard on how to implement it before any major changes. Regardless of religeous preference, this style of startup mechanism doesn't have to be evil. I'll try to go over a few issues that I see, and hopefully we can have a sane discussion about this. :) 1. run levels, and lame shell script links like S01*, S10*, etc. There is basically no need for this--it is essentially a hack to get around the lack of a real dependancy handling system. How best to implement it though? Even some people have proposed using make. I dont know if this could support the kind of dynamic dependancies we want though. I was thinking more along the lines of having something like "#require NETWORK" at the beginning of the scripts, and using a generic sh script to parse / order / record dependancy information. Also, the scripts echo's and such may be ordered by the dependancy graph somehow and grouped so that we'd have something nicer to look at than "The system is coming up." or some unorganized mess. :) 2. What about location, ie. do we want to keep all local changes in /usr/local/etc or some such place not on the root. Regardless, I think that the dependancy system should work across the directories. 3. Also, if we are to have a true dependancy system, some state will have to be kept somewhere in order to keep track of whats running and how to undo it upon system (or individual package) shutdown. Where do we put this? /var may not be mounted, and it would be nice to keep / ro. As well as recording what is started and stopped, we'd also need a default list of packages to start--perhaps in /etc/config. 4. Configuration information, how should this be defined and where should it go? I really think that SGI did a fairly nice job of this with /etc/config/. I really dislike having one huge file to house all of our configuration. Having it split up means that parts of the system that rarely change can persist even across OS revisions. These files are very simple, containing just options, or simple things to be sourced of which the interfaces remain constant. (like portmap.options or netif.options or such) This is really handy when you have dozens of machines and makes it easier to rdist, etc. Having common static things embedded in sysconfig makes it necessary to regenerate (somehow) lots of new files every time you upgrade and is annoying when you have lots of machines. Whatever we come up with, it would also be nice to have standard across the BSD's if possible. I know that this issue keeps popping up, but I think thats only because it needs to be adressed someday. I hope I am not deeply upsetting anyone. :) --Chris Csanady
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704240406.XAA02513>