On Tue, Dec 10, 2002 at 10:33:48PM -0800, Gordon Tetlow wrote: > > That sounds like a good idea. According to current NETWORKING requirements it > > just means the network interfaces are brought up, but routing seems to be a > > reasonable requirement as well. I can't think of a good reason why it would > > not be a good idea. Maybe we could move the other routing daemons > > there as well (from /usr/sbin)? > > Well, there in lies the chicken and the egg problem (and why I've been > cursing rcng recently). /usr is mounted after networking so all the things > that implictly require /usr must be run after networking is setup (but what > about things like route6d that is in /usr/sbin?)
You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin. I think if we have routed there we might as well have the others there. Actually we only need to move route6d to /sbin. I can't think of a reason you would need multicast routing before the whole system was up. I think we can live with and additional 42k on /. > > IMO rc.d should have the following major catagories: > > DISKS > FILESYSTEMS > NETWORKING > DAEMON > LOGIN I don't see the need for FILESYSTEMS. As it is we only have two scripts mountcritlocal and mountcritremote. And since network mounted filesystems are quite common any script that needs FILESYSTEM is simply going to have to wait until NETWORKING is up. There's no way we can get around that. > NETWORKING, DAEMON, and LOGIN exist in the NetBSD framework. NetBSD also > describes a SERVERS catagory that I don't really understand the need for. Basicaly it's for daemons that you need running as early as possible, like syslogd. Other services are going to need them, but you can't really fit them in the other categories. > > I'd like to think about really sitting down and overhauling the rc.d > system after 5.0 is branched. I think that it's reasonable to say we > should not try to be compatible with NetBSD except for keeping a common > rc.subr and major initialization catagories (basically anything that is > in all caps). Does anyone have a problem with dyking out the NetBSD > specific portions after 5.0? I was quite a ways through porting our scripts when David insisted that they be compatible with NetBSD in order to make it into the tree. It took quite a bit more work to restart almost from the beginning and redo them. And I would hate to see that work go to waste. So, I'm not an impartial party here and won't say anymore about it except to say that I think being in sync with NetBSD is a worthwhile and doable goal if we (both projects) make a firm commitment to do it. This means that we wouldn't be "slavishly" accepting NetBSD code, but that the projects would work the differences out so that the only differences left would be because of architectural differences between the two OSes. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48516/pgp00000.pgp
Description: PGP signature
