From owner-freebsd-hackers Sat Oct 4 13:47:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06018 for hackers-outgoing; Sat, 4 Oct 1997 13:47:05 -0700 (PDT) Received: from tok.qiv.com (uucp@[204.214.141.211]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06013 for ; Sat, 4 Oct 1997 13:47:00 -0700 (PDT) Received: (from uucp@localhost) by tok.qiv.com (8.8.6/8.8.5) with UUCP id PAA20466; Sat, 4 Oct 1997 15:45:23 -0500 (CDT) Received: from localhost (jdn@localhost) by acp.qiv.com (8.8.6/8.8.5) with ESMTP id PAA13843; Sat, 4 Oct 1997 15:40:53 -0500 (CDT) X-Authentication-Warning: acp.qiv.com: jdn owned process doing -bs Date: Sat, 4 Oct 1997 15:40:52 -0500 (CDT) From: "Jay D. Nelson" To: dk+@ua.net cc: Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: 2nd Notice: 4 days to code freeze in RELENG_2_2 branch. In-Reply-To: <19971004131600.29971@dog.farm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanks, Dmitry, your argument is much better stated than mine. What we are asking is _not_ a code change but a _comment_ change ;) If not now, how about after 2.2.5 is out the door? -- Jay On Sat, 4 Oct 1997, Dmitry Kohmanyuk [KOI8-R] Дмитрий Кохманюк wrote: > On Fri, Oct 03, 1997 at 07:41:57PM -0500, Jay D. Nelson wrote: > > Yes, Taylor is better in some respects. I'm not suggesting changing > > sample files or anything _except_ uncommenting the HDB capability in > > the build. When you are migrating from an older HDB system to FreeBSD, > > _and there is no compeling reason_ to use Taylor features, it is > > simpler, quicker and more reliable to simply move the config files to > > the FreeBSD system and go. > > Well, since we are now in beta period for 2.2, major changes in core > system are not allowed; but this change cannot hurt, and it would be > really nice to enable all kinds of config files for folks converting > from old uucp installations. > > Here is the patch (tested); I did diff -U15 so precedent comment is > visible. > As you can see, enabling all three features is backward-compatible: > first, tailor configs are looked up, then V2, then HDB. > > Patch: > > --- policy.h.ok Sat Oct 4 12:52:10 1997 > +++ policy.h Sat Oct 4 12:52:26 1997 > @@ -453,32 +453,32 @@ > /* To compile in use of the new style of configuration files described > in the documentation, set HAVE_TAYLOR_CONFIG to 1. */ > #define HAVE_TAYLOR_CONFIG 1 > > /* To compile in use of V2 style configuration files (L.sys, L-devices > and so on), set HAVE_V2_CONFIG to 1. To compile in use of HDB > style configuration files (Systems, Devices and so on) set > HAVE_HDB_CONFIG to 1. The files will be looked up in the > oldconfigdir directory as defined in the Makefile. > > You may set any or all of HAVE_TAYLOR_CONFIG, HAVE_V2_CONFIG and > HAVE_HDB_CONFIG to 1 (you must set at least one of the macros). > When looking something up (a system, a port, etc.) the new style > configuration files will be read first, followed by the V2 > configuration files, followed by the HDB configuration files. */ > -#define HAVE_V2_CONFIG 0 > -#define HAVE_HDB_CONFIG 0 > +#define HAVE_V2_CONFIG 1 > +#define HAVE_HDB_CONFIG 1 > > /* Exactly one of the following macros must be set to 1. The exact > format of the spool directories is explained in unix/spool.c. > > SPOOLDIR_V2 -- Use a Version 2 (original UUCP) style spool directory > SPOOLDIR_BSD42 -- Use a BSD 4.2 style spool directory > SPOOLDIR_BSD43 -- Use a BSD 4.3 style spool directory > SPOOLDIR_HDB -- Use a HDB (BNU) style spool directory > SPOOLDIR_ULTRIX -- Use an Ultrix style spool directory > SPOOLDIR_SVR4 -- Use a System V Release 4 spool directory > SPOOLDIR_TAYLOR -- Use a new style spool directory > > If you are not worried about compatibility with a currently running > UUCP, use SPOOLDIR_TAYLOR. */ > #define SPOOLDIR_V2 0 > > It is a 2-line change. > > > > > The down side is code size. It will grow a bit. The up side is that > > those of us who use it won't have to convert files and can convert > > older systems more quickly (and at less cost to a paying client.) > > Newbies won't see the change because they won't be using it. Old farts > > like me will be happier because we can deal with the same files we > > have been using for years. What can it hurt? > > Code size change is negligible: > > # size /usr/obj/usr/src/gnu/libexec/uucp/uuxqt/uuxqt /usr/libexec/uucp/uuxqt > text data bss dec hex > 98304 4096 692 103092 192b4 /usr/obj/usr/src/gnu/libexec/uucp/uuxqt/uuxqt > 86016 4096 692 90804 162b4 /usr/libexec/uucp/uuxqt > # size /usr/obj/usr/src/gnu/libexec/uucp/uucico/uucico /usr/libexec/uucp/uucico > text data bss dec hex > 208896 4096 20788 233780 39134 /usr/obj/usr/src/gnu/libexec/uucp/uucico/uucico > 192512 4096 20788 217396 35134 /usr/libexec/uucp/uucico > # > > So, how about changing 2 lines and making uucp configs compatible with all > of the outside world? >