Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Oct 1997 15:40:52 -0500 (CDT)
From:      "Jay D. Nelson" <jdn@qiv.com>
To:        dk+@ua.net
Cc:        Greg Lehey <grog@lemis.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: 2nd Notice:  4 days to code freeze in RELENG_2_2 branch.
Message-ID:  <Pine.BSF.3.96.971004153121.13824A-100000@acp.qiv.com>
In-Reply-To: <19971004131600.29971@dog.farm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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?
    > 





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971004153121.13824A-100000>