michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) (11/19/88)
Hi there,
We were getting used to a reasonable way of generating
boot images in System V.3.0 on 386 boxes using mkunix etc.
We have based all our drivers to be installable this way.
In our environment, where we have lots of networked machines,
we use one machine to generate kernels for all other machines
and transfer the image across ethernet. We have also build
a nice user interface to generate the config and system files
used by the mkunix scheme.
To my surprise, the V.3.2 tape we got for 386 systems has
a totally different, incompatible, scheme to do the same thing.
Even the syntax of the configuration files is different, and
less readable I might add.
It is less flexible and assumes that boot images are generated
on the system they will run on.
I was even more surprised when I found out that the V.3.2 for the
3B2 still has mkunix! Appearantly, AT&T considers this change
to large to justify making their add-on driver packages installable
under the new scheme. I agree with AT&T on this point. They allowed
the change for 386 machines though.
We basically have two ways of coping with this:
1) Change our user interface and packages and buy new
versions of all "as-is" purchased packages that need
the kernel to be relinked.
2) Keep mkunix, which of course is work too.
I wonder what the community thinks. Are software suppliers changing
to follow the new scheme? I know of a few that already did, but some
others didn't. I am particularly interested in the course of
action of independent (driver) software suppliers that are hit
by this change.
--
# Michiel Fierst van Wijnandsbergen Internet fierst@idca.tds.philips.nl #
# Philips Telecomm. and Data Systems UUCP ...!mcvax!philapd!fierst #