Subject: Re: some diffs to 1.0-current / 1.0 (probably as well)
To: None <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
From: Niklas Hallqvist <firstname.lastname@example.org>
Date: 01/12/1995 14:11:47
>>>>> "Chris D" == Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU> writes:
Niklas> But... the root partition still fails to mount :-)
>> It was config.new that was busted! In my config.new/sem.c there
>> are uses of the constant "8" instead of MAXPARTITIONS. When I
>> found this and changed it everything worked OK! I wonder if this
>> is fixed in -current? I'm still at 941225 sources.
Chris D> A similar fix was made to the NetBSD 1.0 config.new.
Chris D> (actually it was substantially different, but it worked just
Chris D> fine... 8-)
To sem.c? I can still spot the magic '8' in there. Has my sup got
out of sync?
Chris D> Unfortunately, it is _not_ appropriate to just change 8 to
Chris D> MAXPARTITONS -- because that hard-codes a machine-dependent
Chris D> constant into an otherwise machine-independent binary.
Chris D> A m68k config.new binary built on, say, an amiga should be
Chris D> able to run correctly on an amiga, on a mac, on a da30, and a
Chris D> sun3, and should be able to correctly generate configuration
Chris D> files for _any_ machine which uses config.new.
Chris D> hardcoding '8' breaks this.
Chris D> I've looked at the problem (twice in fact), and did not find
Chris D> an 'easy' or 'nice' solution either time...
How about generating makedev(x, y * MAXPARTITIONS + z) in swapnetbsd.c
instead of precalculating the 2nd arg? I mean MAXPARTITIONS literally
here, not the value of the system config.new is built upon. Then when
compiling the kernel, the target machine MAXPARTITIONS will be used,
just like it should be.
PS. I haven't rebuilt config.new from -current, maybe things work
now, but as I've said: in sem.c there's still an occurrence of
the magic '8' which bothers me.