From owner-freebsd-current Wed Dec 11 0:46:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25BDB37B401 for ; Wed, 11 Dec 2002 00:46:28 -0800 (PST) Received: from mail.identd.net (matrix.identd.net [64.172.21.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 7C7A743E4A for ; Wed, 11 Dec 2002 00:46:27 -0800 (PST) (envelope-from mtm@identd.net) Received: (qmail 24822 invoked by uid 1007); 11 Dec 2002 08:46:03 -0000 Date: Wed, 11 Dec 2002 00:46:03 -0800 From: Mike Makonnen To: Gordon Tetlow Cc: "Daniel C. Sobral" , current@freebsd.org, obrien@freebsd.org, Doug Barton Subject: Re: RC NG, ntp and routed Message-ID: <20021211084603.GA24584@matrix.identd.net> References: <3DF4996E.1040706@tcoip.com.br> <20021210024350.GC16008@matrix.identd.net> <20021210162208.GJ45512@roark.gnf.org> <3DF61DE4.9070205@tcoip.com.br> <20021210225014.GA22267@matrix.identd.net> <20021211002318.GT45512@roark.gnf.org> <20021211054754.GA23972@matrix.identd.net> <20021211063348.GU45512@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20021211063348.GU45512@roark.gnf.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD/4.7-STABLE (i386) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 10, 2002 at 10:33:48PM -0800, Gordon Tetlow wrote: > > That sounds like a good idea. According to current NETWORKING requireme= nts 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 w= ould > > not be a good idea. Maybe we could move the other routing daemons > > there as well (from /usr/sbin)?=20 >=20 > 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 wh= at > 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. Act= ually 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 /. >=20 > IMO rc.d should have the following major catagories: >=20 > DISKS > FILESYSTEMS > NETWORKING > DAEMON > LOGIN =20 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 th= em in the other categories. >=20 > 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" accept= ing NetBSD code, but that the projects would work the differences out so that t= he only differences left would be because of architectural differences between the two OSes. Cheers. --=20 Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC= 68B9 --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE99vtL2uHir9vMaLkRAtdwAJwIYHsXBIsEHmlomFZar2Uvs9LRfwCgr3ze nG7lC34yZ1l3+QLLW89OPBU= =5YXo -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message