Subject: Re: sys/lib/libsa: Cleanup and making stuff "smaller".
To: Simon Burge <simonb@telstra.com.au>
From: None <drochner@zel459.zel.kfa-juelich.de>
List: tech-kern
Date: 02/21/1999 12:31:14
simonb@telstra.com.au said:
> One of the big offenders is ufs.c.  To get this to work on the pmax,
> we need to disable symlink handling and we also don't have the
> ufs_close() routine or the ufs_write() stub.  I was looking too adding
> a NO_SYMLINK #ifdef for the symlink case, and a REALLY_SMALL #ifdef
> for the second case.  Any objections (or suggestions for better names
> :-)? 

I've added a similar option (NFS_NOSYMLINK) to nfs.c. So I'd call
your one UFS_NOSYMLINK. Instead of REALLY_SMALL I'd use more
descriptive names (eg UFS_NOCLOSE) and let the port specific
Makefile specify what it considers small or really small. The
requirements might be different for different ports, and it
is better imho to have fine-grained control over what goes into
the lib.

> On the subject of cleanup, there's still references to bcopy/bzero in
> sys/lib/libsa and not memcpy/memset.

Uses of memset(buf, val, len) with val!=0 are rare or not present
at all. The whole memset() API is crap imho because it is limited
to bytewise operation. This is not userland, so we don't have to
obey POSIX or whatever, so I'd vote to keep the more efficient bzero()
in libsa.

> Before anyone jumps up and down and says "go to 2 stage bootblocks!"
> (Jason included ;), we are moving toward this but are still aiming to
> have stage 1 live within the currently available bootblock space without
> resorting to some ugly nasty installboot-hack type scheme.

As someone (cgd?) said: This is a battle you can only lose.
You won't be able to implement nice features, and with every
libsa or compiler change the trouble begins again. Or perhaps
we'll get a working LFS one day, and want to boot from it...
I consider the bootblock installation by "disklabel" worse
than a port-specific "installboot". Dealing with the port specifics
within "disklabel" leads to an "#ifdef" mess, and cross-platform
support would be easier too if "disklabel" would only do what it
is called after: editing disklabels.

best regards
Matthias