Peter Memishian wrote:
> > > > > > ./lib/libast/common/features/*
> > > > > > ./lib/libcmd/common/features/*
> > > > > > ./lib/libdll/common/features/*
> > > > > > ./lib/libshell/common/features/*
> > > >
> > > > These are feature probes (e.g. for "iffe"&co.), they're used to
> > > > generate the matching platform-specific files. IMO they're usefull to
> > > > keep to have a reference how a matching setting was selected and how
> > > > they are intended to be used (and you can use the probes to
> > > > regenerate the files on demand for testing).
> > >
> > > OK.
> >
> > Ok == "keep them" ?
>
> OK as in "I can see how keeping these could be useful". So I don't have
> an objection (again, given that we will resync periodically).
Ok... thanks! :-)
> > > > > > ./lib/libast/common/misc/magic.tab
> > > > > > ./lib/libast/common/port/astmath.c
> > > > > > ./lib/libast/common/port/atmain.C
> > > > > > ./lib/libast/common/port/lc.tab
> > > > > > ./lib/libast/common/port/lcgen.c
> > > > > > ./lib/libast/common/regex/regdecomp.c
> > > > > > ./lib/libast/common/uwin/mini.sym
> > > >
> > > > Misc. sources (some of them unused - for now).
> > > >
> > > > > > ./lib/libpp/common/ppsym.c
> > > > > > ./lib/libshell/common/bltins/shopen.c
> > > > > > ./lib/libshell/common/sh/env.c
> > > >
> > > > Unused source (for now).
> > > >
> > > > > > ./lib/libshell/common/include/env.h
> > > >
> > > > Unused header.
> > > >
> > > > > > ./lib/libast/common/dir/dirstd.h
> > > >
> > > > Unused source file (not used on this platform).
> > >
> > > More information is needed on the above. Is "for now" unbounded, or is
> > > there follow-on work that will make use of this stuff? For the ones not
> > > listed as "for now", will they ever have relevance to Solaris?
> >
> > These files _may_ be used in future work. The problem is that I cannot
> > predict the future evolution of consumers and therefore don't know
> > whether they will be used or not (that's our little "Schroedingers
> > Cat"-problem right now with all the "currently maybe unused files").
>
> Taking dirstd.h as an example, it says:
>
> 23 /*
> 24 * AT&T Bell Laboratories
> 25 *
> 26 * <dirent.h> for systems with no opendir()
> 27 */
>
> It's impossible that opendir() will disappear from Solaris, so this file
> will never be useful. How can it be argued that this "may" be used in
> future work?
The the matching codepath is AFAIK used for FS3D support, too. From
"usr/src/lib/libast/common/dir/dirlib.h":
-- snip --
#ifdef _BLD_3d
#define DIR DIRDIR
#endif
#undef _DIRENT_H
#include "dirstd.h"
#ifndef _DIRENT_H
#define _DIRENT_H 1
#endif
#ifdef _BLD_3d
#undef DIR
#endif
-- snip --
(The FS3D thing may (or may not) be an interesting item for the ZFS
people to look at in the future (not now)).
> How many other files above are simply irrelevant to Solaris?
All of them which are currently listed as "unused files" are
_currently_" simply irrelevant to Solaris" in _today's_ configuration.
Turning features in libshell/libast on/off may change that quickly. The
same problem happens if a feature gets added which should be used on
more than one platform (like DTrace support) - we don't know exactly
which of these features/includes/sources are used on such target
platforms and removing them from the OS/Net codebase makes these files
and their codepaths "invisble" to the developers (and therefore may
cause wrong design decisions for an implementation (Ok... worst case
scenario... ;-/ )).
This is one of the problem we have with the "unused files" - we don't
know how our future will look like and what exactly we will need of the
features which are available. And that makes any predictions which files
are needed today, tomorrow and in the distant future as predictable as a
session of russian roulette (except that playing that specific game is
dangerous).
To answer your question above more detailed:
./lib/libast/common/misc/magic.tab
Magic number database (see file(1). Not used yet but may be usefull to
look later to get the /usr/bin/file tool+database updated).
./lib/libast/common/port/astmath.c
Test code for AST math functions.
./lib/libast/common/port/atmain.C
at stubs (not used on Solaris (unless someone writes something like
BrandZ/MVS ... =:-) ))
./lib/libast/common/port/lc.tab
l10n/i18n table (like "math.tab" ; the table+infrastructure is on my
list to be tweaked/enhanched for Solaris once we make some libast APIs
more open).
./lib/libast/common/port/lcgen.c
This is used to generate AST's <lc.h> tables from the table above.
./lib/libast/common/regex/regdecomp.c
Uhm... now I am confused. This piece should be compiled in...
... grumpf... wonderfull... we found a bug... ;-(
./lib/libast/common/uwin/mini.sym
AFAIK this one could be removed.
./lib/libpp/common/ppsym.c
Some kind of "iffe"-like probe to figure out the list of CPP predefined
symbols.
./lib/libshell/common/bltins/shopen.c
That's the "open" builtin command. Not used for now but may be later
usefull for some scripts which have to open files with non-standard
flags (e.g. |O_DSYNC|, |O_NOCTTY|, |O_NOFOLLOW| or XATTR files).
./lib/libshell/common/sh/env.c
Contains an API to modify environment variable pools. The matching
codepath (follow |_ENV_H| in the libshell sources) is currently not used
on Solaris (see problem above about "codepaths we do not use _now_").
> > > > > > ./lib/libast/common/astsa/align.h
> > > > > > ./lib/libast/common/astsa/ast.h
> > > > > > ./lib/libast/common/astsa/astwinsize.c
> > > > > > ./lib/libast/common/astsa/ccode.h
> > > > > > ./lib/libast/common/astsa/lclib.h
> > > > > > ./lib/libast/common/astsa/sig.h
> > > > > > ./lib/libast/common/astsa/strmatch.c
> > > > > > ./lib/libast/common/astsa/times.h
> > > >
> > > > Standalone AST subset glue
> > > > (see usr/src/lib/libast/common/astsa/README)
> > >
> > > I'm unclear why the standalone AST environment is relevant to ON (but I
> > > haven't had time to read the README, so maybe that explains it).
> >
> > AFAIK technicially these files could be removed.
>
> Is it correct to say that the entire `astsa' directory could simply be
> lopped off? Or are there some files in there Solaris uses?
AFAIK none of the files in usr/src/lib/libast/common/ are used by our
libast.so.1 build... however I am little bit scared to drain&&remove it
because it's in the global include searchpath of the libast build.
Another problem is that standalone tools like the tools which parse
tables and generate code may depend on these includes (to overlay
"normal" AST&&system includes in some cases) making this a little bit
tricky to sign a statement which says "... these are not used...". From
what I know today I think these could be removed (in theory... with some
uncertain feeling in my stomach...).
> > > > > > ./lib/libast/common/comp/conf.sh
> > > > > > ./lib/libast/common/comp/conf.tab
> > > >
> > > > Config tab generation.
> > >
> > > Need more information.
> >
> > This is like the "iffe" probed above - a static table with values and a
> > script to generate a couple of sources from this information, e.g.
> > usr/src/lib/libast/(${MACH}|${MACH64})/src/lib/libast/conftab.c,
> > usr/src/lib/libast/(${MACH}|${MACH64})/src/lib/libast/conftab.h and
> > usr/src/lib/libast/(${MACH}|${MACH64})/src/lib/libast/conflim.h are
> > created by this script based on the table information and local probing.
>
> OK, so it seems like these should be handled in the same was as the iffe
> probes.
Ok...
> > > > > > ./lib/libpp/common/gentab.sh
> > > > > > ./lib/libpp/common/pp.def
> > > > > > ./lib/libpp/common/pp.key
> > > > > > ./lib/libpp/common/pp.probe
> > > > > > ./lib/libpp/common/pp.tab
> > > >
> > > > Misc. feature probes and generation scripts
> > >
> > > Need more information.
> >
> > See above (the same as "math.tab" and "conf.tab") - a script
> > ("gentab.sh") is used to create sources from the matching table
> > information+local environment.
>
> Likewise, same as iffe probes.
Ok...
> > > > > > ./lib/libpp/sparc/gentab
> > > > > > ./lib/libpp/sparc/pp.req
> > > > > > ./lib/libpp/sparc/pp.yacc
> > > > > > ./lib/libpp/sparc/ppkey.yacc
> > > > > > ./lib/libpp/sparc/probe
> > > > > > ./lib/libpp/sparc/probe.sh
> > > >
> > > > Table/parser generation files etc. (not used in the OS/Net build since
> > > > we generated the destination files outside the tree and imported them
> > > > later).
> > >
> > > So what is the benefit of keeping them?
> >
> > The benefit would be that we only modify the original sources (e.g.
> > table data) and refresh the generated sources during development (same
> > procedure as "math.tab" etc.).
>
> So these are like the iffe probes? Or something else?
These are more like "math.tab" than the "iffe" probes but still fall
into the same general category (e.g. generated at build time).
[snip]
> > Even if "suid_exec.c" is not used in OS/Net (_maybe_ (currently the
> > exact status is not known - the old dtksh ships /usr/dt/bin/suid_exec
> > ... either this is a mistake, a problem with Solaris dtksh (which is
> > based on an ancient ksh93 version 'd' alpha) or something else) we do
> > not need it as Casper pointed out) ?
> > Note that there is (small) obstacle... if we remove this file and add
> > something like DTrace support which requires to patch this file for
> > non-Solaris platforms with DTrace support we have to resurrect this file
> > for development (this is another reason why I am not really happy with
> > doing a fine-grained stripping of the codebase - in the worst case we
> > run into lets "remove and resurrect files"-game (which can result in
> > really "funny" issues when the files are deleted before they are under
> > SCCS control since there is then no way to figure out that such a file
> > exists somewhere in the project's timeline)).
>
> Right, I don't want to purge anything we can make a reasonable case for
> needing to resurrect, which is why I think it makes sense to keep it (and
> include the appropriate findunref exceptions).
Ok...
> > > > > > ./lib/libshell/common/data/bash_pre_rc.sh
> > > > > > ./lib/libshell/common/data/math.tab
> > > >
> > > > Table of math functions and their attributes (e.g. number of
> arguments)
> > > > which are available by default (e.g. all the (C99) math functions are
> > > > controlled by this file).
> > >
> > > So at what point in the port was math.tab used?
> >
> > "math.tab" is used by usr/src/lib/libshell/common/features/math.sh to
> > create
> > usr/src/lib/libshell/(${MACH}|${MACH64})/src/cmd/ksh93/FEATURE/math
> > (this needs to be platform-specific). We just treat it like all the
> > other generate files (e.g. iffe probes etc.) and import it in one step
> > from a native AST/ksh build (saves time and headaches to specially treat
> > single files).
>
> OK, then it goes in the same bucket as the iffe probes.
Ok...
> > > > > > ./lib/libshell/common/mamstate.c
> > > > > > ./lib/libshell/common/sh/bash.c
> > > >
> > > > Used for "bash" compatibilty mode (unused).
> > >
> > > Seems odd that mamstate.c would have something to do with bash
> > > compatibility mode.
> >
> > Erm, no. My fault ("./lib/libshell/common/data/bash_pre_rc.sh" is a
> > mistake, too). ./lib/libshell/common/data/bash_pre_rc.sh and
> > ./lib/libshell/common/sh/bash.c are for the bash emulation mode,
> > ./lib/libshell/common/mamstate.c is the old mamfile tool ("make abstract
> > machine file state support").
>
> So it seems mamstate.c is unlikely to ever be useful on Solaris, right?
Right. AFAIK it can be removed.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
