Newsgroups: comp.os.minix
Subject: Re: More problems changing click size
References: <F6dS2.106$VM.13269@news.uswest.net>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <3719900a.0@isc-newsserver.isc.rit.edu>
Date: 18 Apr 1999 03:55:54 -0500
X-Trace: 18 Apr 1999 03:55:54 -0500, grace.isc.rit.edu
Lines: 73
XPident: voidptr
X-Original-NNTP-Posting-Host: 129.21.3.100
XPident: Unknown
Path: star.cs.vu.nl!newsfeed.amsterdam.nl.net!sun4nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-peer1.sprintlink.net!news-in-west1.sprintlink.net!news.sprintlink.net!isc-newsserver.isc.rit.edu!aje9383
Xref: star.cs.vu.nl comp.os.minix:35299

In article <F6dS2.106$VM.13269@news.uswest.net>,
Johnathon McAlister <maccer@uswest.net> wrote:

>Now - the bad news:
>The @#$%^& program still has 32-bit dependencies!  I converted "copy68k.s"
>to "copy68k.c" - ALL of it, using trivial byte copies to keep the complexity
>down.  Also altered the Makefile to recognize that "copy68k.o" was dependent
>on "<minix/const.h>".  Remade the system with no problems, but it still dies
>in 32-bit mode.
>
>Using the faster system to track things down, I've deduced the following:
>
>1) MacMinix gets way into the startup process before dying.  The initial
>dialog showing the kernel load is gone, kernel/main.c has completely
>executed and exited via "restart()", the console task is up and running (I
>get the TTY 0 window w/ text), the other tasks are running (serial port
>messages appear, printer message appears), IDLE is up and running (I get the
>"BOOTING MINIX" message), MM is up and running (the memory amounts are
>printed, and diagnostic printf statements I inserted indicate various pieces
>are executed), and FS is up and running (diagnostic printf again shows it
>looping through, getting and replying to messages).

Hmmm...that would seem to be pretty much all of the kernel!

>2) As I understand it, the next process that is started is INIT.  I assume
>somewhere in INIT is the part that mounts the filesystem - but MacMinix dies
>before the mount is done.  Thus, the crash seems to be somewhere between the
>start of INIT and the mount.  However, when I try to put simple printf
>messages in "tools/init.c" and do a "make", I get errors.  The compile works
>fine, but the "ld" complains about "_exit" being multiply defined,
>preventing me from tracing the flow through INIT.

init starts by attempting to start a shell running /etc/rc, which mounts
filesystems, etc; it then attempts to open up logins/gettys on the specified
ports.  Is anything from /etc/rc  being executed?  Try adding an echo or
something as the first line in this file.

Printing stuff from within init is typically done using explicit system
calls, something like:

	fd = open( CONSOLE, 1 );
	write( fd, "Frodo Lives!\n", 12 ); /* 12 chars in string */
	close( fd );

One of the definitions of _exit is found in /usr/lib/head.o, which is
specifically linked into init (but not most normal programs).  Another exit
apparently gets linked in from somewhere, too, but I can't track down
precisely which library routine does it.  (Okay, I'm just too lazy to at the
momment).  Printf does force the inclusion of a fair number of library
files.

>3) I thus have the following questions:
>
>Anyone know of click size dependencies in INIT?

I don't think there are any explicitly.

>Any other suggestions?

Try tracing, via debugging printfs or whatever, the system calls into mm;
I'd guess that perhaps either fork or exec is failing somewhere, due to some
dependence on click size which isn't perfectly obvious.  It sounds as though
perhaps init is dying when it attempts to fork/exec the shell for /etc/rc.

>4) [personal note] Hacking the system has been great fun (a lot more fun
>than the COBOL and DB2 I use every day), esp. now that I have a system that
>can keep up with my typing.  :-)

Beware--it's also highly addictive.

--Andrew Erickson, aje9383@grace.isc.rit.edu
May your init never be able to fork and exec if you send me unsolicited
commercial Email.
