About three weeks ago I asked this question on this list:
> In order to simplify the generation of 4.1.1 kernels for servers and
> workstations, I would like to be able to make them on a single
> machine. I am only interested in sun4 and sun4c kernel architectures
> (no sun3 or 3x). I know I can copy the /sys/<kernel-arch> hierarchy
> and merge other /sys files as necessary, but before I do this I would
> like to know if it will work, and, if so, what to look out for. I can
> already see that /sys/sun/conf.c will need some work. Anything else?
After receiving one "no" and several "yes" replies, I decided to try it.
I did not respond until now because I was unable to test the results
until this week. The answer is yes, it can be done, and it isn't very
difficult, but there are some things to watch out for if you have
already installed mods or fixes for special devices or software
All that is really required is to have a /sys/sun4 and /sys/sun4c, each
with their respective conf and OBJ directories. Some suggested using a
mount of the other kernel arch, but I copied it to make things easier
to do as root. It takes an extra 4 MB (more when you make vmunix),
which I did not consider to be very much space for the convenience of
having everthing in one place. In my case I used an SS1 to make
kernels for Sparcs (SS1, SS1+, SS2, SLC and IPC) and 4/490s. The
vmunix that is created on a Sparcstation will work just fine on a
4/490. I don't see any reason why it shouldn't work the other way
around, but I have not tried it.
The only possible problems arise from modifications that have been made
to files in other directories besides /sys/sun4 and /sys/sun4c. In
particular, /sys/sun/conf.c may need work because of the correspondence
of the bdevsw and cdevsw structures defined in it to major numbers in
/dev devices. All of the standard Sun devices have assigned numbers,
and do not present problems. Optional devices, however, usually take
the next number in sequence. So, if, as in my case, you have already
installed different devices in different systems (e.g., an OMNI board in
a server and a serial I/O Sbus card in a Sparcstation) then these
numbers may have overlapped. Since most third-party vendors consider
any file in /sys to be fair game, you have to check all files for
differences and merge the changes together. Prior to setting this up I
checked the entire /sys hierarchies for differences using a remote mount
and diff -r. Some files, like /sys/conf.common/files.cmn, just needed a
/sys/sun/conf.c, however, was another matter. Since I had a confict of
device numbers, I decided that the easiest fix was to take the server
conf.c as a starting point (it had more devices installed) and
re-install the serial Sbus card software. This worked out okay, but
had to be tweaked by hand anyway. Since the last device in the server
conf.c was 105, I had expected the serial Sbus card to come in at 106.
Silly me! Of course it was 137! Call me crazy, but somehow it just
didn't seem right. After poking around the install script for a while,
I discoverd the awk program that determines the next device number to
use. It looks for the string "cdevsw" and then counts "}"s to
determine how many elements of the structure there are, which seems a
reasonable thing to do. The writer of this script, however, had
apperently never met the writer of the Presto board installation
script, who added an ifdef'd section somewhere in the middle of the
declaration of cdevsw, thereby adding a bunch of "}"s that would compile
fine but would fool a simple awk script.
So did I change the serial card install script to send conf.c through
cpp first, test it and send the changes back to the vendor telling them
that this would handle the case where there were ifdefs in conf.c?
Naaaaahhhhhh. I just edited conf.c and changed 137 to 106! After all,
one good kludge deserves another, right? Anyway, it provided some mild
amusement for the day.
Remember that after doing something like this you may have to change some
device numbers. In my case it was only a half dozen machines. Also
don't forget to install patches in all architectures to which they
apply. I put mine in /sys/patches so they are right where I need them.
In all, I like this setup and just wonder why I didn't do it sooner.
Dan Lorenzini Greenwich Capital Markets firstname.lastname@example.org
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:19 CDT