Help! modifying os to support >14 char filenames (sys V.3)

[Piercarlo Grandi]

On 19 Sep 90 06:18:17 GMT, machina at uts.amdahl.com (Miguel A. Ramirez) said:

	[ ... on how many user programs have an hard coded 14 for the
	max length of file name in a System V environment, and thus
	would not respond to a change in a #define ... ]

machina> There's no such thing as an easy hack.

Indeed, being able to change a #define'd symbol from 14 to 30 is not an
easy hack, and I have been only been trying to sound funny; much more
seriously, it is the reason why the #define'd symbol has been there
since at least 10 years ago, to allow for *easy* parametrization.

Some user programs have been silly enough to avoid it? They would break
under *any* scheme to change the filename length, so changing the
#define is the _easiest_ way out, because at least it impacts the kernel
and kernel-level utilities less than the other choices. Once you have
decided you want to change the maximum file name length, what is 'easy'
is relative to that decision.

Maybe I should have written 'an easy (relative to the other
alternatives) way to satisfy your requirement in a strict sense and with
the easiest and smallest (relatively, but also, to me, in absolute
terms) changes to kernel and command sources is ...' instead of 'an easy
hack is ...'.

My postings are already too long -- I don't really want to write out
everything in extenso, just to avoid people like you getting confused.

News is not Congress (yet :->), and articles are not Bills.

machina> BTW, Piercarlo did you test not only the kernel but also all
machina> the commands that were effected by the long file name support?

Actually, I think I have listed most of those in the standard System V
distribution (I think I forgot SCCS, and no doubt some others) in some
past article.  Let me repeat, very few programs actually scan
directories. Most work on collections of file pathnames, and of these
only a few break a file pathname in file names (most are happy with
mucking with suffixes at the end of pathnames).

One may want to have a look at the BSD sources (freely available to
those that have a System V source license) and scan them for usage of
MAXNAMLEN; one would easily find the list of programs (modulo some BSD
vs. System V differences) where one has to become suspicious, because
the BSD crew put in all those MAXNAMLENs when they had to convert from
the V7/V32/4.1BSD/System III/System V to the FFS directory organization.

machina> No?  But I thought it was an easy hack?  --

You seem so sure, you must have done so. So please, for our information,
post a list of commands and libraries in the standard System V
distribution that have an hard coded 14, the relative percentage of
source files, and in how many places for each.

Also, what is easy depends on many factors; what is easy for me may be a
big problem to you, for example, or (improbably :->) viceversa. For me
using find(1), xargs(1) and egrep(1) is easy, for example, and not even
too time consuming :-) :-) :-).

The difficult problems are others even if somebody may seem daunted by
the consequences of changing a fairly old and well understood symbolic
constant.

As to the real problems, another example; from evidence easily available
using any AT&T, Sun or Dec (just to mention three big names) UNIX
kernel, doing trivial tuning or even just avoiding gross misdesigns of
page (and working set) replacement kernel modules and of the programs
that run under them seems to be impossibly difficult (for those
manufacturers, at least) or to require an inordinate number of releases.

	(spoiler: actually paging or swapping module design is not an
	easy task for anybody, especially if compared with merely
	changing the file name length leaving the directory structure
	the same. It is a bit easier though than what would be apparent
	from the problems that AT&T, Sun and Dec (and many others) seem
	to have with it).
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk