CSS/Harvard 2.9BSD bug report #10

[Keith Bostic]

Subject: directory reading in 2.9BSD

This is intended to be an explanation/discussion of the problems that people
are having with various programs attempting to read directories in the CSS/
Harvard 2.9BSD.  People have complained that the previous messages and the
comments delivered with the source were unduly cryptic, so bear with me if I
go into too much detail.

As mentioned in the "gotcha" file delivered with the source, the "new"
directory reading routines have been installed in the C library.  This was
intended to conform to the way 4.X does things and we had hoped that it would
make porting various programs easier.  Unfortunately, there are a few programs
that really do need to know about the underlying directory structure, fsck
and dump, for example.  To get around this, we split the include file dir.h
into two parts, one which had the defines for the old directory structure
and one that had the defines for the new directory structure.  Which part
of it was actually included was dependent on whether or not the define "KERNEL"
was set.  Then, in programs that needed the old stuff, we surrounded the
include statement for dir.h in the following fashion.

#define KERNEL
#include <sys/dir.h>
#undef KERNEL

As has been pointed out to me in *great* detail, this was Evil because it
assumed that a program would never need to use *both* sets of directory reading
includes.  It starts to get nasty when you realize that user.h (the user
structure) has a directory structure in it, u_dent.  This causes all sorts
of things to break because programs that include user.h have to include dir.h
to satisfy the directory structure requirement.  Since they don't define
KERNEL before they include it, they get the wrong size directory structure
and  therefore think that the user structure is the wrong size.  This was the
problem with ps.

There are numerous fixes to the this particular problem.  Fix one, the easy
one.  For the debonair person-about-town who doesn't particularly care to
muck about the kernel and various applications.  Whenever you come across a
program that includes user.h and attempts to read the user structure, make
sure that it defines KERNEL before it includes dir.h.  If it later also uses
the directory reading routines, split that module into a separate file and
include dir.h again, this time without defining KERNEL.  Any programs that
are reading the actual device, not the directory file, should define KERNEL
before including dir.h.  Other programs should be converted to use the
new directory reading routines.  If you choose not to convert them, defining
KERNEL before including dir.h will probably make them work.  This approach
should fix any problems you run into with the programs on the CSS/Harvard
2.9BSD tape.  Obviously, it won't fix all possible problems.

Fix two, the "interesting" one.  For the home-handyperson type.  Move the
kernel directory structure into user.h and change its name.  Below is what
I've put in my user.h.

/*
 * The V7 directory structure, to be used by the kernel and programs that
 * need to read the file system directly.
 */
struct kerdir {
	ino_t	kd_ino;
	char	kd_name[MAXNAMLEN];
};

...

	struct	kerdir u_dent;		/* current directory entry */

Then, remove the includes for dir.h from the entire kernel.  (There are about
20 incidences.)  Then, in fsck.c, mkfs.c, ncheck.c, dcheck.c, dump/*.[ch],
dumpdir.c, ps.c, adb/*.[ch], w.c, restor.c and the kernel, change all
occurrences of "d_ino" to "kd_ino", "d_name" to "kd_name", and "struct direct"
to "struct kerdir".  Be careful when you make these changes, I don't remember
any nasty things like variables called "xd_ino", but I may have forgotten them.
Remake the dependency lists in all the makefiles.  Remake the programs and the
kernel.

Obviously, I prefer the second fix; it's cleaner and allows most programs
to ignore the differences between the two directory structures.  It won't
impact on our effort to be 4.X compatible, these programs are never going
to be 4.X compatible anyway.  On the other hand, the first fix is certainly
easier; you'll get the second fix when you get our next tape.

--keith