> > > > > ./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).
> > > > > ./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? How many other files above are simply irrelevant to Solaris?
> > > > > ./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?
> > > > > ./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.
> > > > > ./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.
> > > > > ./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?
> > > > > ./lib/libshell/common/sh/suid_exec.c
> > >
> > > "suid_exec" helper for "setid" binaries (unsed - see set[ug]id script
> > > discssion here and in shell-discuss at opensolaris.org).
> >
> > Likewise.
>
> 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).
> > > > > ./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.
> > > > > ./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?
--
meem
