Date: Thu, 28 Feb 2002 20:47:39 -0800 From: Mike Makonnen <mike_makonnen@yahoo.com> To: obrien@freebsd.org Cc: cjclark@alum.mit.edu, current@freebsd.org Subject: Re: NetBSD-style rc.d Project -- What I have so far... Message-ID: <1014958059.2899.189.camel@blackbox.pacbell.net> In-Reply-To: <20020228092311.A25539@dragon.nuxi.com> References: <20020226051811.K52727@blossom.cjclark.org> <1014914374.816.53.camel@blackbox.pacbell.net> <20020228092311.A25539@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2002-02-28 at 09:23, David O'Brien wrote: > On Thu, Feb 28, 2002 at 08:39:33AM -0800, Mike Makonnen wrote: > > I chose to go a slightly different route than Gordon, in that I have not > > tried to make the scripts compatible with NetBSD (His scripts include > > conditionals for NetBSD, mine don't). These are my reasons. > > The point you are missing is that we can work with the NetBSD guys to > maybe change the NetBSD framework such that it works better for *both* > systems. It is totally stupid to not share as much of the existing body > of work with NetBSD. If you have ever had to administrate or use more > than one Unix OS, you know how gratuitously different things are in > them. Typically for no good reason. I don't think I articulated myself very well in my email. I am not against sharing code with NetBSD and I don't like gratuitous diffs any more than the next guy, but the differences in our scripts are because of gratuitous diffs elsewhere in the system. I think it's better to eliminate the differences elsewhere in the system. Then the scripts will naturally converge, with less need for conditionals. The 'sysctl -w' issue is a trivial example, but let me use it again. My argument is that it is better to have NetBSD support writing to sysctls without a '-w' switch, so that the same invocation works for both OS, than to maintain a mechanism, in the startup scripts, by which to work around the issue. Let's take another example. The REQUIREMENT line in a script cannot be made conditional. It requires a modification of rcorder(8) to do so. So, if one of NetBSD's services has a requirement that we don't have, it automatically means we need two separate scripts with different REQUIREMENT lines regardless of whether the rest of the script is identical. BTW, from a quick glance at the rcorder(8) source, modifying it to eliminate this problem is not going to be a trivial task. > > > - Each project is going to have scripts that the other project > > won't use. This means someone has to invest the time and > > effort to maintain scripts the project won't be using > > I know we will not have 100% identical implementations. But people seem > to want to use the NetBSD bits as reference but change things to how the > "should have been done". Now, that I've had a bit more time to think about it, I appreciate better the point you're making. I still think it's better to make the rest of the OS more compatible, but I can understand your point. What bothered me about it initially is that it seemed you wanted 100% compatibility and _all_ of it directed at making our startup process conform to NetBSD's. The reason I eschewed making the scripts NetBSD compatible is because once I saw how Gordon did it and I actually started converting the scripts I gained a better appreciation for the amount of work it entailed. It's going to be a tedious and long process probably, but I can see the merits now if the NetBSD people are willing to work with us. For example, I prefer our method of mounting local and then remote file systems, rather than having the sysadmin specify critical_filesystems in rc.conf ( I can already imagine the flood of emails to freebsd-questions: "Help! My system won't boot..." :-). Can I make a few suggestions: - Aim for at least a six month "shake-down", with rc_ng="YES" by default, in -Current before 5.0-Release. - A. Leave the current scripts as they are, for the moment. As new scripts get converted make them NetBSD compatible. Then work on making the initial scripts converge. This option will probably take some time. or B. Leave the current scripts as they are, for the moment. Get the scripts converted as quickly as possible. If possible make them NetBSD compatible from the start, but the overriding factor is getting the new system up and running in -Current so that people can start using it while the larger and slower task of converging the scripts goes on in parallel. Getting the rest of the rc system converted should only take a couple of weeks. - It may be useful to fix _some_ compatibility problems in the base system, even if just to reduce the complexity of a script. However, I have a suspicion we would just get bogged down in flame-fests between the two projects over who's implementation is better :( - I think on some things, the two projects may "agree to disagree" on, which means the majority of the code base will probably be 'identical', but there will be differences in things like, boot order, requirements, etc. I am of the opinion that it would be better to just get the system up and running to start with, and then work toward making them as identical as possible as we move forward. Never the less, I am willing to put effort into converging the two systems (/me thinks I might live to regret this sentence :-). cheers, mike makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1014958059.2899.189.camel>