Move FSDISKTYPE uses from disklabel(8) invocations to vnconfig(8)
invocations, making the geometry information written to the
disklabel a bit more logically related to the disktab information
from wh

Move FSDISKTYPE uses from disklabel(8) invocations to vnconfig(8)
invocations, making the geometry information written to the
disklabel a bit more logically related to the disktab information
from whence it came. Also makes FSDISKTYPE usage consistent.

Flip the disklabel(8) invocations to the "echo '/ *'"
idiom to make it obvious that the desire is to create a single
'a' partition containing all free space.

No intentional functional change. MBRs, disklabels and newfs
outputs appear identical.

reads good to kn@

show more ...

Retire -E's "expert" mode. Introduced 23 years ago to avoid
confusing users with FFS attributes that only experts should
fiddle with. Actual use has withered away with functionality
rendered moot or

Retire -E's "expert" mode. Introduced 23 years ago to avoid
confusing users with FFS attributes that only experts should
fiddle with. Actual use has withered away with functionality
rendered moot or moved elsewhere.

'-e' remains for the truly obscure corner cases.

Simply excise the code for now to see if hidden users/uses are
exposed. Further simplifications are possible if no such
users/uses surface.

ok with sthen@ millert@ kn@ otto@

show more ...

Don't rely on the disklabel defaults or a disktab entry's ba#/fa#
values for the block/fragment sizes that some install media need.
Hoist the desired values into the newfs(8) invocations to make it
o

Don't rely on the disklabel defaults or a disktab entry's ba#/fa#
values for the block/fragment sizes that some install media need.
Hoist the desired values into the newfs(8) invocations to make it
obvious non-default values are required and what the values are.

No functional change.

ok kn@

show more ...

Pass make flags to kernel and lib builds

Running `make -j4' in /usr/src/distrib/amd64/ramdisk_cd/ et al. executes
make(1) to both build the RAMDISK kernel and build libraries.

Doing so does not pro

Pass make flags to kernel and lib builds

Running `make -j4' in /usr/src/distrib/amd64/ramdisk_cd/ et al. executes
make(1) to both build the RAMDISK kernel and build libraries.

Doing so does not propagate the flags specified to the ramdisk_cd
invocation, which in turn means `-j4' for example is ignored and both kernel
and libraries will not be built in parallel.

Pass make(1)'s MFLAGS along to retain relevant flags; make is clever enough
to separate flags, variable assignments and targets from each other and only
pass along things to `MFLAGS' that'd make sense, i.e. `make -C. -j4 foo=bar'
does *not* pass `-C.' to change directories.
(can be easily tested with `make -p ... | grep MFLAGS'.)

This makes hacking on ramdisks/the installer much faster, espescially since
the `bsd' target does `make clean' and therefore builds a new kernel every
time.

OK deraadt

show more ...

distribute the gzip'd version of bsd.rd on platforms where we all boot
methods support it. if anyone finds a method which does not work, please
speak up.

Make ffs2 the default for newfs; change all calls to create e.g. floppy
filesystems or ramdisks to use explicit -O 1; installer already does that.
ok sthen@

Change install images called *.fs to *.img. These are UFS filesystem images,
but additionally have a bootblock in the first 8K (since UFS does not use that
space). There are some UEFI direct-from-i

Change install images called *.fs to *.img. These are UFS filesystem images,
but additionally have a bootblock in the first 8K (since UFS does not use that
space). There are some UEFI direct-from-internet bootloaders that require
the name *.img. So this makes things more convenient for those, while keeping
it consistant in all architectures.
ok kettenis beck kn

show more ...

Further removal of differences (using install instead of cp, sorting
chunks in a specified order, using a few variables, performing bsd.rd
to bsd.gz conversion as similar as possible)

Do not need reacharound back to our own obj directory, pretty silly

repair more trivial differences

rm is in /bin, no need to specify

Every Makefile on every architecture had deviated in unique ways.
Eliminate many more differences. When it makes sense, build bsd.rd
and miniroot/ramdisk.fs and cd.iso in the same directory. More s

Every Makefile on every architecture had deviated in unique ways.
Eliminate many more differences. When it makes sense, build bsd.rd
and miniroot/ramdisk.fs and cd.iso in the same directory. More steps
coming after this..

show more ...

TOPDIR and TOP are not neccessary.

remove the abstraction REV on top of abstraction OSrev which is always
the sme.

CBIN variable is also pointless, it is always "instbin". Rather than
having two mysterious names, let's settle on one.

the BSD_RD variable is pointless

Use new rdsetroot.

Use makefs to build bsd.rd. ok deraadt

Use new kernel compile method for ramdisks, de-escalating to $BUILDUSER
as required.
much help from natano and tb.

We do not produce "core" files, so they do not need to be deleted. they
have been *.core files for a very long time. That's a lot of unlink()
calls saved.

Turn on the distrib lib bits in crunchgen by setting SRCLIBDIR.
Add the new files to the clean target's rm list.

"why not get it tested?" deraadt@

Unbreak most archs for the last commit. cut and paste changed rdsetroot
to elfrdsetroot. Does not yet fix sparc

Allow the elf rdsetroot operation to function on 32 bit and 64 bit binaries.
Enables developers to build arm ramdisk kernels on amd64 archs
OK deraadt@ 'looked fine' miod@

Deprecate vnds in favour of svnds.

In effect, this removes the "old" vndX nodes, and renames
the svndX nodes to vndX.

Old svndX nodes will still continue to work though, for now.

Cleanup according

Deprecate vnds in favour of svnds.

In effect, this removes the "old" vndX nodes, and renames
the svndX nodes to vndX.

Old svndX nodes will still continue to work though, for now.

Cleanup accordingly.

ok deraadt@, todd@
comments and ok on the man page bits from jmc@

show more ...

No need to make depend kernels; ok guenther