> > >Yah, but there are a couple of programs which don't quite work properly 
> > >between the two - disklabel, for one (mac has a different MAXPARTITIONS), 
> > >eeprom(8) and screenblank(1) (Sun-specific),
> > > [...]
> 	disklabel should be using sysctl to get kern.maxpartitions & 
> 	kern.rawpartition.... (tsk - I guess I should send-pr a fix
> 	for this given I've just opened my mouth about it :)...

This isn't enough.

in particular, programs which use 'struct disklabel' also have to
grapple with the fact that the disklabel struct includes:

        struct  partition {             /* the partition table */
                u_int32_t p_size;       /* number of sectors in partition */
                u_int32_t p_offset;     /* starting sector */
                u_int32_t p_fsize;      /* filesystem basic fragment size */
                u_int8_t p_fstype;      /* filesystem type, see below */
                u_int8_t p_frag;        /* filesystem fragments per block */
                union {
                        u_int16_t cpg;  /* UFS: FS cylinders per group */
                        u_int16_t sgs;  /* LFS: FS segment shift */
                } __partition_u1;
#define p_cpg   __partition_u1.cpg
#define p_sgs   __partition_u1.sgs
        } d_partitions[MAXPARTITIONS];  /* actually may be more */

and that various things:

#define DIOCGDINFO      _IOR('d', 101, struct disklabel)/* get */
#define DIOCSDINFO      _IOW('d', 102, struct disklabel)/* set */
#define DIOCWDINFO      _IOW('d', 103, struct disklabel)/* set, update disk */

hard-code the size of 'struct disklabel'.


> 	The only problem binaries should be those using libkvm... &
> 	I guess if the sun3 kvm is merged into the m86k one that should
> 	be ok as well...

or, one could have libkvm switch on the machine type, i.e. at run-time.
This would make libkvm larger, but you have to pay for some things... 8-)




chris