From owner-freebsd-arch@FreeBSD.ORG Sun Apr 20 16:53:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB4CB37B401 for ; Sun, 20 Apr 2003 16:53:08 -0700 (PDT) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF27E43FAF for ; Sun, 20 Apr 2003 16:53:05 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 0EC824304D; Sun, 20 Apr 2003 16:53:04 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Scott Long , Bruce Evans Date: Sun, 20 Apr 2003 16:52:37 -0700 User-Agent: KMail/1.5 References: <200304182047.h3IKlhIZ000817@number6.magda.ca> <20030419165033.V15269@gamplex.bde.org> <3EA10351.3010001@btc.adaptec.com> In-Reply-To: <3EA10351.3010001@btc.adaptec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304201652.37912.wes@softweyr.com> cc: arch@freebsd.org Subject: Re: config(8) should check if a scheduler is selected X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 23:53:08 -0000 On Saturday 19 April 2003 01:05, Scott Long wrote: > Bruce Evans wrote: > > > > It is the only mandatory option (sic). Kernels with no options > > (although they might not be useful) can be built except for this bug. > > Example of a minimal config file (before misconfiguration of the > > configuration of scheduling). > > > > %%% > > machine i386 > > cpu I686_CPU > > ident MIN > > %%% > > The scheduler is (one of) the first core subsystems to be made > modular. If by chance the VM system became modular (VM_MACH, VM_UVM > =-) you'd have a similar situation there also. Doesn't this argue for a keyword rather than an option? If you have to have one or the other for the kernel to function, wouldn't a 'scheduler' keyword (and likewise a 'vm' or 'vm_model' keyword) save us from the lunacy of non-optional options? > I'm afraid that the lack of seatbelts in config(8) for SCHED_xxx will > generate a lot of user complaints when 5.1 is released. Since code to > implement it has not magically appeared yet, we might have to make due > with adding extra eye-catching comments to things like NOTES and > GENERIC. Or maybe we could fix it? > > BTW, a minimal kernel is now almost 3 times as large as in FreeBSD-2 > > due to general bloat and misconfiguration of configuration in the > > opposite way (subsystems much larger than scheduling are standard; > > you can still leave out FFS and INET but many less useful subsystems > > are standard). > > Some of us remember when 250k FreeBSD kernels were not hard to > configure =-) And 330K kernels were the norm, as long as you eschewed NFS. Sigh. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-arch@FreeBSD.ORG Sun Apr 20 17:02:14 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB1F037B405 for ; Sun, 20 Apr 2003 17:02:14 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F4C43FB1 for ; Sun, 20 Apr 2003 17:02:14 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3KNxjZ13064; Sun, 20 Apr 2003 16:59:45 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id RAA25960; Sun, 20 Apr 2003 17:02:03 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA08850; Sun, 20 Apr 2003 18:01:57 -0600 (MDT) Message-ID: <3EA334F2.60409@btc.adaptec.com> Date: Sun, 20 Apr 2003 18:01:54 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Peters References: <200304182047.h3IKlhIZ000817@number6.magda.ca> <20030419165033.V15269@gamplex.bde.org> <3EA10351.3010001@btc.adaptec.com> <200304201652.37912.wes@softweyr.com> In-Reply-To: <200304201652.37912.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: config(8) should check if a scheduler is selected X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 00:02:15 -0000 Wes Peters wrote: > On Saturday 19 April 2003 01:05, Scott Long wrote: > >>Bruce Evans wrote: >> >>>It is the only mandatory option (sic). Kernels with no options >>>(although they might not be useful) can be built except for this bug. >>> Example of a minimal config file (before misconfiguration of the >>>configuration of scheduling). >>> >>>%%% >>>machine i386 >>>cpu I686_CPU >>>ident MIN >>>%%% >> >>The scheduler is (one of) the first core subsystems to be made >>modular. If by chance the VM system became modular (VM_MACH, VM_UVM >>=-) you'd have a similar situation there also. > > > Doesn't this argue for a keyword rather than an option? If you have to > have one or the other for the kernel to function, wouldn't a 'scheduler' > keyword (and likewise a 'vm' or 'vm_model' keyword) save us from the > lunacy of non-optional options? > > >>I'm afraid that the lack of seatbelts in config(8) for SCHED_xxx will >>generate a lot of user complaints when 5.1 is released. Since code to >>implement it has not magically appeared yet, we might have to make due >>with adding extra eye-catching comments to things like NOTES and >>GENERIC. > > > Or maybe we could fix it? > I'll repeat again: >> Since code to implement it has not magically appeared yet... =-) I'd be happy if someone took this up. If Terry can do it with magical linker sets and virtual tables or whatever, that would be great too. Until patches appear, I'm not too concerned on how it's done. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Apr 20 18:02:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 054FD37B401 for ; Sun, 20 Apr 2003 18:02:49 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4564443FFD for ; Sun, 20 Apr 2003 18:01:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0075.cvx21-bradley.dialup.earthlink.net ([209.179.192.75] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197PgS-0001I6-00; Sun, 20 Apr 2003 18:01:25 -0700 Message-ID: <3EA34218.54596AA@mindspring.com> Date: Sun, 20 Apr 2003 17:58:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Long References: <200304182047.h3IKlhIZ000817@number6.magda.ca> <3EA10351.3010001@btc.adaptec.com><3EA334F2.60409@btc.adaptec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ced197f76609200dba576725b7604e18350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: arch@freebsd.org Subject: Re: config(8) should check if a scheduler is selected X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 01:02:49 -0000 Scott Long wrote: > >> Since code to implement it has not magically appeared yet... > > =-) > > I'd be happy if someone took this up. If Terry can do it with > magical linker sets and virtual tables or whatever, that would be > great too. Until patches appear, I'm not too concerned on how > it's done. Is it going to sit still? Last I looked, new scheduler interfaces were being defined. The cost is going to be an extra function call and a pointer indirect for each scheduler function. Hope that's OK... -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue Apr 22 03:09:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F4837B401 for ; Tue, 22 Apr 2003 03:09:58 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 067A243FE5 for ; Tue, 22 Apr 2003 03:09:57 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h3MA9tE11538 for ; Tue, 22 Apr 2003 12:09:55 +0200 (MEST) Date: Tue, 22 Apr 2003 12:09:55 +0200 (CEST) From: Harti Brandt To: freebsd-arch@freebsd.org Message-ID: <20030422115708.J39097@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: media definitions for ATM X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 10:09:58 -0000 Hi all, in preparation for a SUNI module that allows uniform access to the ATM layer stuff for most ATM cards I want to introduce if_media definitions for ATM. Neither OpenBSD nor NetBSD seems to have them, I don't know about BSD/OS (is there a place on can look at their header files?). While you normally can't switch media on an ATM card, it makes sense to be able to toggle media options via ifconfig (SDH and Sonet, for example) and see the carrier state.c So driven by the lack of prior art I came up with the following definitions that use the next available media code (5): /* * ATM */ #define IFM_ATM 0x000000a0 #define IFM_ATM_UNKNOWN 3 #define IFM_ATM_TAXI_100 4 #define IFM_ATM_TAXI_140 5 #define IFM_ATM_MM_155 6 #define IFM_ATM_SM_155 7 #define IFM_ATM_UTP_155 8 #define IFM_ATM_MM_622 9 #define IFM_ATM_SM_622 10 #define IFM_ATM_SDH 0x00000100 /* SDH instead of SONET */ #define IFM_ATM_NOSCRAMB 0x00000200 /* no scrambling */ #define IFM_ATM_UNASSIGNED 0x00000400 /* unassigned cells */ Would these be ok? Does anybody know of any conflicts with other *BSD*? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue Apr 22 03:44:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E6C37B401 for ; Tue, 22 Apr 2003 03:44:00 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 1041543FDF for ; Tue, 22 Apr 2003 03:43:59 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 590 invoked from network); 22 Apr 2003 10:38:27 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 22 Apr 2003 10:38:26 -0000 Received: (qmail 44402 invoked by uid 1000); 22 Apr 2003 10:41:46 -0000 Date: Tue, 22 Apr 2003 13:41:46 +0300 From: Peter Pentchev To: Harti Brandt Message-ID: <20030422104146.GE542@straylight.oblivion.bg> Mail-Followup-To: Harti Brandt , freebsd-arch@freebsd.org References: <20030422115708.J39097@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsxXAMtlQ5JHofzM" Content-Disposition: inline In-Reply-To: <20030422115708.J39097@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: media definitions for ATM X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 10:44:01 -0000 --AsxXAMtlQ5JHofzM Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2003 at 12:09:55PM +0200, Harti Brandt wrote: >=20 > Hi all, >=20 > in preparation for a SUNI module that allows uniform access to the ATM > layer stuff for most ATM cards I want to introduce if_media definitions f= or ATM. > Neither OpenBSD nor NetBSD seems to have them, I don't know about BSD/OS > (is there a place on can look at their header files?). This used to be in the motd of builder.FreeBSD.org; it seems to have been removed from there, but take a look at the /local0/BSDOS/ directory on builder. From a quick glance, neither the 4.1 nor the 5.0-smp-devel trees seem to have IFM_ATM definitions. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. --AsxXAMtlQ5JHofzM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+pRxq7Ri2jRYZRVMRAvohAKCuj1je+RmrCf57sLbUXNUwTmjJPgCdEXx1 j6f+Voy1iTQgevn41WKMYWA= =2BmJ -----END PGP SIGNATURE----- --AsxXAMtlQ5JHofzM-- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 22 03:52:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39E3937B401 for ; Tue, 22 Apr 2003 03:52:38 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A03343F75 for ; Tue, 22 Apr 2003 03:52:37 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h3MAqVoT004258; Tue, 22 Apr 2003 12:52:32 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Harti Brandt From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Apr 2003 12:09:55 +0200." <20030422115708.J39097@beagle.fokus.fraunhofer.de> Date: Tue, 22 Apr 2003 12:52:31 +0200 Message-ID: <4257.1051008751@critter.freebsd.dk> cc: freebsd-arch@freebsd.org Subject: Re: media definitions for ATM X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 10:52:38 -0000 In message <20030422115708.J39097@beagle.fokus.fraunhofer.de>, Harti Brandt wri tes: >/* > * ATM > */ >#define IFM_ATM 0x000000a0 >#define IFM_ATM_UNKNOWN 3 >#define IFM_ATM_TAXI_100 4 >#define IFM_ATM_TAXI_140 5 >#define IFM_ATM_MM_155 6 >#define IFM_ATM_SM_155 7 >#define IFM_ATM_UTP_155 8 >#define IFM_ATM_MM_622 9 >#define IFM_ATM_SM_622 10 >#define IFM_ATM_SDH 0x00000100 /* SDH instead of SONET */ >#define IFM_ATM_NOSCRAMB 0x00000200 /* no scrambling */ >#define IFM_ATM_UNASSIGNED 0x00000400 /* unassigned cells */ > >Would these be ok? Does anybody know of any conflicts with other *BSD*? Add the 25.6Mbit/sec twisted pair which is used for ADSL while you're at it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 22 18:46:23 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31BD437B401 for ; Tue, 22 Apr 2003 18:46:23 -0700 (PDT) Received: from ivoti.terra.com.br (ivoti.terra.com.br [200.176.3.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C8343FAF for ; Tue, 22 Apr 2003 18:46:22 -0700 (PDT) (envelope-from fass@terra.com.br) Received: from barra.terra.com.br (barra.terra.com.br [200.176.3.52]) by ivoti.terra.com.br (Postfix) with ESMTP id D7CAF408D25 for ; Tue, 22 Apr 2003 22:46:20 -0300 (BRT) Received: from fass (unknown [200.148.192.247]) (authenticated user fass) by barra.terra.com.br (Postfix) with ESMTP id 5F497234056 for ; Tue, 22 Apr 2003 22:46:20 -0300 (BRT) Message-ID: <007701c3093a$259f83f0$6788b1c8@fass> From: "Felipe Afonso" To: Date: Tue, 22 Apr 2003 22:46:23 -0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Wed, 23 Apr 2003 05:03:24 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: AMD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 01:46:23 -0000 Hi All, The FreeBSD will support AMD64 (Opteron) Processor? When? Thanks, Felipe Afonso fass@terra.com.br From owner-freebsd-arch@FreeBSD.ORG Wed Apr 23 06:50:20 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 108C537B401 for ; Wed, 23 Apr 2003 06:50:20 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABF243F75 for ; Wed, 23 Apr 2003 06:50:19 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h3NDoHTk019147; Wed, 23 Apr 2003 06:50:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h3NDoHuB019144; Wed, 23 Apr 2003 06:50:17 -0700 Date: Wed, 23 Apr 2003 06:50:17 -0700 From: Brooks Davis To: Felipe Afonso Message-ID: <20030423135017.GA12304@Odin.AC.HMC.Edu> References: <007701c3093a$259f83f0$6788b1c8@fass> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <007701c3093a$259f83f0$6788b1c8@fass> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-arch@freebsd.org Subject: Re: AMD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 13:50:20 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2003 at 10:46:23PM -0300, Felipe Afonso wrote: > Hi All, > The FreeBSD will support AMD64 (Opteron) Processor? When? Yes. Probably soon. It's been booting for a week or so. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ppn3XY6L6fI4GtQRAkTFAJ9+XtqNdcP0g2WWtpES8u9JT66TNgCeOhD+ eKS0TxapGL7dnFEaIjxKit4= =iDVi -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-arch@FreeBSD.ORG Wed Apr 23 09:29:32 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D6B37B401 for ; Wed, 23 Apr 2003 09:29:32 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639F543F75 for ; Wed, 23 Apr 2003 09:29:31 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h3NGTKZW011089; Wed, 23 Apr 2003 09:29:24 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h3NGTJ7W011088; Wed, 23 Apr 2003 09:29:19 -0700 (PDT) Date: Wed, 23 Apr 2003 09:29:18 -0700 From: "David O'Brien" To: Brooks Davis Message-ID: <20030423162918.GA11029@dragon.nuxi.com> References: <007701c3093a$259f83f0$6788b1c8@fass> <20030423135017.GA12304@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030423135017.GA12304@Odin.AC.HMC.Edu> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Felipe Afonso cc: freebsd-arch@freebsd.org Subject: Re: AMD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 16:29:32 -0000 On Wed, Apr 23, 2003 at 06:50:17AM -0700, Brooks Davis wrote: > On Tue, Apr 22, 2003 at 10:46:23PM -0300, Felipe Afonso wrote: > > Hi All, > > The FreeBSD will support AMD64 (Opteron) Processor? When? > > Yes. Probably soon. It's been booting for a week or so. It is just now starting into single user mode. It will come in time. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Fri Apr 25 18:45:39 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C39C237B401 for ; Fri, 25 Apr 2003 18:45:39 -0700 (PDT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A0443FD7 for ; Fri, 25 Apr 2003 18:45:39 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h3Q1jbPx012319 for ; Fri, 25 Apr 2003 21:45:37 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302251255.48219.wes@softweyr.com> Date: Fri, 25 Apr 2003 21:45:36 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 Subject: Re: NEWSYSLOG changes, -Create option for rc.diskless X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 01:45:40 -0000 Back on March 9th, Garance A Drosihn wrote: > >I have an update in: >http://people.freebsd.org/~gad/newsyslog/create-opt.diff > >which implements a '-C' option for newyslog. Once this is >committed, /etc/rc.diskless2 should be changed to use it. The >update also adds a a 'C' flag for the config file entries, to >match an option that NetBSD has. > >Please pay close attention to the new createlog() routine, >as a later update will switch to using that for all logfile >creations. My goal was to eliminate all windows in the creation >of a new log file. This later update (once I do it) should >complete the job started in revision 1.41 (from april 2002). Based on the feedback in March, I've made some changes to my earlier change. The way it works now is that *if* the -C option is specified once, then newsyslog will create any log files which do not exist, *and* which have the 'C' flag specified in their config file entry. If the -C option is specified multiple times, then all missing log files are created, without carrying if they have a 'C' flag specified. With this change in, I would then change rc.diskless2 so it runs 'newsyslog -CC' (instead of what it does now, which is very icky...) If any files are also given on the command line, then the -C or -CC will only apply to the specified log files. Does this seem reasonable? I'd like to commit this to current on Sunday (the .diff even includes the change for the man page!). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 15:46:12 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 665C937B401; Sat, 26 Apr 2003 15:46:12 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E3D743F93; Sat, 26 Apr 2003 15:46:11 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003042622460900100e25s3e>; Sat, 26 Apr 2003 22:46:10 +0000 Date: Sat, 26 Apr 2003 15:46:08 -0700 (PDT) From: Doug Barton To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org Message-ID: <20030426154030.M13476@znfgre.qbhto.arg> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-rc@yahoogroups.com Subject: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 22:46:12 -0000 [ Please respect followups to -arch, and avoid cross-posting responses, thanks. ] Summary: I'm proposing the removal of the old rc system from HEAD, and all subsequent 5.x releases. Background: During the discussion of importing the next generation rc system (rcNG) the request was made to follow a "typical" deprecation schedule, with rcNG as the default in 5-Release, and the old system (rcOG) still existent but deprecated, not to be removed till 6.x. At the time, I agreed to that plan as a sort of "wait and see" measure, since it seemed reasonable at the time. However, I think it's time to revisit that decision. Current situation: If you'll pardon a bit of horn blowing, the rcNG team, especially Mike Makonnen, has done a great job of bringing over a lot of code from NetBSD, making some improvements, and quite a few compatibility patches. The existing rcNG system, to the best of our knowledge, is totally bug-compatible with rcOG. We've hit all of the project timelines that we established for ourselves, and we continue to improve the system, while staying responsive to bug reports. That's the good news. The bad news is that the status quo leaves us with essentially 3 "rc branches" to support. The rcNG code is where most new development is occurring. There is also rcOG in HEAD, and the old rc system in RELENG_4. This is becoming more and more difficult to support as time goes by. We're already seeing features that are added in rcNG that there are no plans to migrate to rcOG, mostly because they are 5.x only features. Dropping rcOG in HEAD will free up cycles that could then be better spent on developing new features, and back-porting useful things to RELENG_4 (whether on OG or NG format). We're also starting to see some confusion on the part of users about having both systems on disk. I haven't seen a _lot_ of posts about this yet, but I think that the rate of adoption for -current is still pretty slow, so it's hard to judge. In fact, I think that since rcNG has been the default for over 7 months now, with practically zero reported problems, speaks volumes toward the suitability of rcNG as the stand alone code base in 5.x. Proposal for the future: We'd like to take the following actions: 1. Remove the old rc framework prior to the 5.1-Release. 2. Backport /etc/rc.subr to RELENG_4 prior to 4.9-Release. The purpose here is to allow ports authors to make use of the rcNG system for their startup scripts, and to possibly allow us to backport major features that just work better in the NG framework. 3. Start generating error messages about the compatibility variables we are currently supporting. portmap_*, xntpd_*, and single_mountd_enable. Your friendly neighborhood rc team is ready and willing to entertain discussion on this topic. Particularly, if you're not using rcNG now because it lacks some feature that the old system had, we'd really like to hear from you. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 16:08:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D413337B401; Sat, 26 Apr 2003 16:08:03 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D5B43F3F; Sat, 26 Apr 2003 16:08:03 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id DCF1C5308; Sun, 27 Apr 2003 01:08:00 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: freebsd-arch@freebsd.org From: Dag-Erling Smorgrav Date: Sun, 27 Apr 2003 01:08:00 +0200 In-Reply-To: <20030426154030.M13476@znfgre.qbhto.arg> (Doug Barton's message of "Sat, 26 Apr 2003 15:46:08 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 References: <20030426154030.M13476@znfgre.qbhto.arg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-current@freebsd.org cc: freebsd-rc@yahoogroups.com Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 23:08:04 -0000 Doug Barton writes: > I'm proposing the removal of the old rc system from HEAD, and all > subsequent 5.x releases. I'm all for it, rcNG rocks! DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 16:10:34 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD0E037B401; Sat, 26 Apr 2003 16:10:34 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AC4143FAF; Sat, 26 Apr 2003 16:10:34 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id 61628225F1; Sat, 26 Apr 2003 16:10:33 -0700 (PDT) Date: Sat, 26 Apr 2003 16:10:33 -0700 From: Will Andrews To: Dag-Erling Smorgrav Message-ID: <20030426231033.GX1836@procyon.firepipe.net> Mail-Followup-To: Dag-Erling Smorgrav , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-rc@yahoogroups.com References: <20030426154030.M13476@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-current@freebsd.org cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 23:10:35 -0000 On Sun, Apr 27, 2003 at 01:08:00AM +0200, Dag-Erling Smorgrav wrote: > I'm all for it, rcNG rocks! Amen. Regards, -- wca From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 16:14:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 556A437B401; Sat, 26 Apr 2003 16:14:08 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3F3943F75; Sat, 26 Apr 2003 16:14:07 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3QNBLZ05425; Sat, 26 Apr 2003 16:11:21 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA13614; Sat, 26 Apr 2003 16:14:00 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA00773; Sat, 26 Apr 2003 17:13:56 -0600 (MDT) Message-ID: <3EAB12AC.8050707@btc.adaptec.com> Date: Sat, 26 Apr 2003 17:13:48 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20030426154030.M13476@znfgre.qbhto.arg> In-Reply-To: <20030426154030.M13476@znfgre.qbhto.arg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-rc@yahoogroups.com Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 23:14:08 -0000 Doug, I totally understand and support the issues with maintenance. I do, however, have a couple of questions: 1. Have all ports been preened of dependence on rcOG? 2. What about 3rd party software that is not in ports? Would it be possible and acceptable to officially deprecate rcOG in 5.1 and then remove it sometime in June or July? I understand that this extends the maintenance of rcOG a tiny bit, but it will also help users and vendors transition. Also, will any seatbelts be in place to catch software that tries to do things the rcOG way? Thanks! Scott Doug Barton wrote: > [ Please respect followups to -arch, and avoid cross-posting responses, > thanks. ] > > Summary: > > I'm proposing the removal of the old rc system from HEAD, and all > subsequent 5.x releases. > > Background: > > During the discussion of importing the next generation rc system (rcNG) > the request was made to follow a "typical" deprecation schedule, with rcNG > as the default in 5-Release, and the old system (rcOG) still existent but > deprecated, not to be removed till 6.x. At the time, I agreed to that plan > as a sort of "wait and see" measure, since it seemed reasonable at the > time. However, I think it's time to revisit that decision. > > Current situation: > > If you'll pardon a bit of horn blowing, the rcNG team, especially Mike > Makonnen, has done a great job of bringing over a lot of code from NetBSD, > making some improvements, and quite a few compatibility patches. The > existing rcNG system, to the best of our knowledge, is totally > bug-compatible with rcOG. We've hit all of the project timelines that we > established for ourselves, and we continue to improve the system, while > staying responsive to bug reports. That's the good news. > > The bad news is that the status quo leaves us with essentially 3 "rc > branches" to support. The rcNG code is where most new development is > occurring. There is also rcOG in HEAD, and the old rc system in RELENG_4. > This is becoming more and more difficult to support as time goes by. We're > already seeing features that are added in rcNG that there are no plans to > migrate to rcOG, mostly because they are 5.x only features. Dropping rcOG > in HEAD will free up cycles that could then be better spent on developing > new features, and back-porting useful things to RELENG_4 (whether on OG or > NG format). > > We're also starting to see some confusion on the part of users about > having both systems on disk. I haven't seen a _lot_ of posts about this > yet, but I think that the rate of adoption for -current is still pretty > slow, so it's hard to judge. > > In fact, I think that since rcNG has been the default for over 7 months > now, with practically zero reported problems, speaks volumes toward the > suitability of rcNG as the stand alone code base in 5.x. > > Proposal for the future: > > We'd like to take the following actions: > > 1. Remove the old rc framework prior to the 5.1-Release. > > 2. Backport /etc/rc.subr to RELENG_4 prior to 4.9-Release. The purpose > here is to allow ports authors to make use of the rcNG system for their > startup scripts, and to possibly allow us to backport major features that > just work better in the NG framework. > > 3. Start generating error messages about the compatibility variables we > are currently supporting. portmap_*, xntpd_*, and single_mountd_enable. > > > Your friendly neighborhood rc team is ready and willing to entertain > discussion on this topic. Particularly, if you're not using rcNG now > because it lacks some feature that the old system had, we'd really like to > hear from you. > > Doug > From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 18:00:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8750E37B401 for ; Sat, 26 Apr 2003 18:00:33 -0700 (PDT) Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7637D43F85 for ; Sat, 26 Apr 2003 18:00:32 -0700 (PDT) (envelope-from jwd@bsdwins.com) Received: from bsdone.bsdwins.com (localhost [127.0.0.1]) by bsdone.bsdwins.com (8.12.9/8.12.9) with ESMTP id h3R0thC1096964; Sat, 26 Apr 2003 20:55:43 -0400 (EDT) (envelope-from jwd@www.bsdwins.com) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.12.9/8.12.9/Submit) id h3R0thR9096963; Sat, 26 Apr 2003 20:55:43 -0400 (EDT) Date: Sat, 26 Apr 2003 20:55:43 -0400 From: John De Boskey To: freebsd-arch@freebsd.org Message-ID: <20030427005543.GA96834@BSDWins.Com> References: <20030426154030.M13476@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030426154030.M13476@znfgre.qbhto.arg> User-Agent: Mutt/1.4.1i cc: freebsd-rc@yahoogroups.com Subject: Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 01:00:33 -0000 ----- Doug Barton's Original Message ----- > [ Please respect followups to -arch, and avoid cross-posting responses, > thanks. ] > > Summary: > > I'm proposing the removal of the old rc system from HEAD, and all > subsequent 5.x releases. I am all for rcNG, with many thanks to those involved. I did notice something the other day, though, that I have a question about. What is the status of /etc/netstart? Are there plans to upgrade it to be aware of rcNG? Comments? Thanks! John From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 20:49:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AEB237B401 for ; Sat, 26 Apr 2003 20:49:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1036843F85 for ; Sat, 26 Apr 2003 20:49:00 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3R3mw100618; Sat, 26 Apr 2003 20:48:59 -0700 (PDT) Message-ID: <3EAB532A.3090107@isi.edu> Date: Sat, 26 Apr 2003 20:48:58 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-rc@yahoogroups.com References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427005543.GA96834@BSDWins.Com> In-Reply-To: <20030427005543.GA96834@BSDWins.Com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080003010304040800060402" cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 03:49:01 -0000 This is a cryptographically signed message in MIME format. --------------ms080003010304040800060402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 4/26/2003 5:55 PM, John De Boskey wrote: > > I did notice something the other day, though, that I have a > question about. What is the status of /etc/netstart? Are there > plans to upgrade it to be aware of rcNG? I have a "nettoggle" script at http://www.isi.edu/larse/etc.html that tries to reimplement netstart under rc_ng, and also tries to provide the corresponding inverse netstop functionality. The general idea is that "nettogle stop" should get you to a state where the location.sh location-detection stuff (on the same page) can reconfig things, and a "nettoggle start" then brings the services back up. The nettoggle stuff is very lightly tested, the loction stuff is quite stable. The nettoggle stuff is kinda hackish right now and needs to be better aligned with the rest of rc_ng. (Feedback very welcome.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms080003010304040800060402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQyNzAzNDg1OFowIwYJKoZIhvcNAQkEMRYEFJJ6lNqgvkhv7/ysBfI0 764wqx3rMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEA0QcIya2h86oz1NJY0/4l8JCR2SilDITN+T0v zFFMKI85Z6lXQV4ArGCEgUZ0O27uPg1k/kUj/nGLaN/QlHkPqHuLhgpKEyEMX07cmiX7EMW/ rVx5ar2BHKgpWtfD3B/CFmrXJg6MQ8PD25wvHnlfSNRr1awYCyErWDMKiOtwo9sucZz0is7T gVP2RhD1l2cw4u00m/f6TUchI3qi1zjFksj1S+QTXhT7WArZBXqjy0vLY+eLcNszQizde0M1 0f8i6B8GzW2l4y66U7QPMgHq+aBCLacx51kPVkAjA6/lHqnHNLykMSKtgOfejNG+rkhHAeRR wBTPCggZPGj7DCZFegAAAAAAAA== --------------ms080003010304040800060402-- From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 22:47:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E307437B401; Sat, 26 Apr 2003 22:47:51 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33B2243F75; Sat, 26 Apr 2003 22:47:51 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003042705474900100e27ege>; Sun, 27 Apr 2003 05:47:50 +0000 Date: Sat, 26 Apr 2003 22:47:48 -0700 (PDT) From: Doug Barton To: FreeBSD-rc@yahoogroups.com, scottl@freebsd.org In-Reply-To: <3EAB12AC.8050707@btc.adaptec.com> Message-ID: <20030426223810.Y657@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 05:47:52 -0000 On Sat, 26 Apr 2003, Scott Long wrote: > Doug, > > I totally understand and support the issues with maintenance. I do, > however, have a couple of questions: > > 1. Have all ports been preened of dependence on rcOG? To my knowledge, there are no such dependencies. There's nothing in OG for the port scripts to utilize, like there is with rc.subr in NG. The only thing that the ports (should) depend on is the fact that the scripts in /usr/local/etc/rc.d/*.sh will get started, and that works in NG. > 2. What about 3rd party software that is not in ports? Once again, to my knowledge there are no such dependencies, but if someone has examples I'll be glad to take a look. > Would it be possible and acceptable to officially deprecate rcOG in 5.1 > and then remove it sometime in June or July? I understand that this > extends the maintenance of rcOG a tiny bit, but it will also help users > and vendors transition. My concern is that since we'll have a LOT more adopters of 5.1 than there were of 5.0, waiting would only increase the confusion. Also, they've had 7 months of rcNG being the default to catch any problems that might have cropped up. Unless someone comes up with a concrete case of "X is/will be broken," I'd like to move forward with this plan. > Also, will any seatbelts be in place to catch > software that tries to do things the rcOG way? I'm not sure what we'd test against, but if you have an idea, I'm all ears. :) Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 23:01:44 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB90037B401 for ; Sat, 26 Apr 2003 23:01:43 -0700 (PDT) Received: from out004.verizon.net (out004pub.verizon.net [206.46.170.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BC7C43FA3 for ; Sat, 26 Apr 2003 23:01:43 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.7.75]) by out004.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net>; Sun, 27 Apr 2003 01:01:42 -0500 Date: Sun, 27 Apr 2003 02:01:41 -0400 From: Mike Makonnen To: FreeBSD-rc@yahoogroups.com In-Reply-To: <20030427005543.GA96834@BSDWins.Com> References: <20030426154030.M13476@znfgre.qbhto.arg> <20030427005543.GA96834@BSDWins.Com> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [138.88.7.75] at Sun, 27 Apr 2003 01:01:41 -0500 Message-Id: <20030427060142.JOJH28930.out004.verizon.net@kokeb.ambesa.net> cc: freebsd-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 06:01:44 -0000 On Sat, 26 Apr 2003 20:55:43 -0400 John De Boskey wrote: > > I am all for rcNG, with many thanks to those involved. > > I did notice something the other day, though, that I have a > question about. What is the status of /etc/netstart? Are there > plans to upgrade it to be aware of rcNG? > > Comments? We should have functionality equivalent to it by 5.2. I don't think that it should be a requirement to meet before removing rcOG, though. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 23:11:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5E2C37B401; Sat, 26 Apr 2003 23:11:37 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 206DC43F3F; Sat, 26 Apr 2003 23:11:37 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h3R68nZ11079; Sat, 26 Apr 2003 23:08:49 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id XAA29838; Sat, 26 Apr 2003 23:11:29 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id AAA00957; Sun, 27 Apr 2003 00:11:26 -0600 (MDT) Message-ID: <3EAB7486.2060107@btc.adaptec.com> Date: Sun, 27 Apr 2003 00:11:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Barton References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com> <20030426223810.Y657@znfgre.qbhto.arg> In-Reply-To: <20030426223810.Y657@znfgre.qbhto.arg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 06:11:38 -0000 Doug Barton wrote: > On Sat, 26 Apr 2003, Scott Long wrote: > > >>Doug, >> >>I totally understand and support the issues with maintenance. I do, >>however, have a couple of questions: >> >>1. Have all ports been preened of dependence on rcOG? > > > To my knowledge, there are no such dependencies. There's nothing in OG for > the port scripts to utilize, like there is with rc.subr in NG. The only > thing that the ports (should) depend on is the fact that the scripts in > /usr/local/etc/rc.d/*.sh will get started, and that works in NG. > Great! > >>2. What about 3rd party software that is not in ports? > > > Once again, to my knowledge there are no such dependencies, but if someone > has examples I'll be glad to take a look. > Fair enough > >>Would it be possible and acceptable to officially deprecate rcOG in 5.1 >>and then remove it sometime in June or July? I understand that this >>extends the maintenance of rcOG a tiny bit, but it will also help users >>and vendors transition. > > > My concern is that since we'll have a LOT more adopters of 5.1 than there > were of 5.0, waiting would only increase the confusion. Also, they've had > 7 months of rcNG being the default to catch any problems that might have > cropped up. > > Unless someone comes up with a concrete case of "X is/will be broken," I'd > like to move forward with this plan. > There's a big difference between, "dougb and friends no longer support nor commit to rcOG, it's going away so don't use it" and, "dougb and friends just whacked rcOG". =-) Invariably there are going to be people/vendors out there that are abusing rcOG, have been lazy for the last 7 months and haven't adapted their systems to rcNG, and will be highly cranky over rcOG disappearing. Having a formal deprecation period gives these people some warning and diminishes their ability to whine. =-) Adding a big "if [ "${rc_ng}" = "NO" ]; then echo "rc_ng=NO is deprecated, unsupported, and will go away in the next release"; fi" to the scripts allows us to cover our rears, makes everyone happy, and lets you all off the hook for providing rcOG support. If you want to remove the bits from CVS the moment that HEAD opens up after the 5.1-BETA freeze, that's fine by me. Scott From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 23:58:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D662937B401; Sat, 26 Apr 2003 23:58:08 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1959243F3F; Sat, 26 Apr 2003 23:58:08 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <20030427065806003006c622e>; Sun, 27 Apr 2003 06:58:07 +0000 Date: Sat, 26 Apr 2003 23:58:04 -0700 (PDT) From: Doug Barton To: Scott Long In-Reply-To: <3EAB7486.2060107@btc.adaptec.com> Message-ID: <20030426231507.K657@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com><3EAB7486.2060107@btc.adaptec.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 06:58:09 -0000 On Sun, 27 Apr 2003, Scott Long wrote: > There's a big difference between, "dougb and friends no longer support > nor commit to rcOG, it's going away so don't use it" We've been saying this, although perhaps not as stridently as we could have, since we made NG the default 7 months ago. If they haven't caught the clue by now, I don't see how giving them more notice is going to help. > Invariably there are going to be people/vendors out there that are > abusing rcOG, have been lazy for the last 7 months and haven't adapted > their systems to rcNG, and will be highly cranky over rcOG disappearing. > Having a formal deprecation period gives these people some warning and > diminishes their ability to whine. =-) Once again, I have to ask you for a concrete example. If any 3rd party has scripts that run out of /usr/local/etc/rc.d, then they will continue to work just like they always have. If they have been abusing rcOG by actually editing the scripts that exist in /etc, their stuff is badly broken already, and the presence or absence of rcOG in the base isn't going to matter, since they are already depending on customized versions. If we were talking about a kernel API, I think that your request would be justified. But we're not. We're talking about an "interface" that has always provided well defined 3rd party support that will not be removed or changed, merely enhanced. The other thing to keep in mind is that unlike a kernel, or other interface, we have no power to actually take functioning rcOG scripts away from users. Even mergemaster doesn't delete files. People with wacky, broken stuff can keep running it that way forever for all I care. Also the stuff will still be there in CVS, just as unsupported and un-committed-to as it would be if we didn't cvs rm it. What I'm talking about is removing it from the default installation to avoid confusing new users, and to further reinforce the fact that it's gone away to anyone who still hasn't caught the clue. This will not cause any problems to those with existing rcOG installations that they depend on, or people who've converted to rcNG. > Adding a big "if [ "${rc_ng}" = "NO" ]; then echo "rc_ng=NO is > deprecated, unsupported, and will go away in the next release"; fi" to > the scripts allows us to cover our rears, makes everyone happy, and lets > you all off the hook for providing rcOG support. That's a good idea, I'm testing something like that right now, thanks. However, it will only be useful for people who upgrade /etc/rc*, which doesn't include the people you're most concerned about. Before you have another knee-jerk REaction to my proposal, please stop and think about how much different this scenario is than something like a kernel interface or binary. Then please try to come up with a concrete example of how things will break if the code is cvs rm'ed. I'm betting that you can't. :) Doug -- This .signature sanitized for your protection