breure%itihp2@pucc.princeton.edu (Frank Breure) (06/06/91)
I had some more problems upgrading St-minix to 1.5.10.4:
The file other/syslib.c is broken, it wil give a lot of compilation error's
I patched it by removing the include of <minix/type.h>, this is already done
in <lib.h> and the type sighandler_t is'nt defined anywhere so I uncommented
the old parameter declaration:
original:
*** syslib.c.org Sun Jun 2 16:18:59 1991
--- syslib.c Sun Jun 2 16:15:30 1991
***************
*** 1,6 ****
#include <lib.h>
#include <minix/com.h>
! #include <minix/type.h>
/*----------------------------------------------------------------------------
Messages to systask (special calls)
--- 1,6 ----
#include <lib.h>
#include <minix/com.h>
! /* #include <minix/type.h> is already included in <lib.h> */
/*----------------------------------------------------------------------------
Messages to systask (special calls)
***************
*** 40,47 ****
PUBLIC void sys_sig(proc, sig, sighandler)
int proc; /* which proc has exited */
int sig; /* signal number: 1 - 16 */
! /*void (*sighandler) ();*/ /* pointer to signal handler in user space */
! sighandler_t sighandler;
{
/* A proc has to be signaled. Tell the kernel. */
--- 40,47 ----
PUBLIC void sys_sig(proc, sig, sighandler)
int proc; /* which proc has exited */
int sig; /* signal number: 1 - 16 */
! void (*sighandler) (); /* pointer to signal handler in user spa
ce */
! /* sighandler_t sighandler;*/
{
/* A proc has to be signaled. Tell the kernel. */
So I turned back two changes that were done from 1.5.10.3 to 1.5.10.4.
There are also problems with stprint.c in the kernel directory!
Because there is no define of DEV_WRITE anywhere in the system, I simply
removed one line from stprint.c to make it work.
*** stprint.c.org Sun Jun 2 16:22:53 1991
--- stprint.c Sat Jun 1 17:25:07 1991
***************
*** 73,79 ****
while (TRUE) {
receive(ANY, &m);
switch(m.m_type) {
! case DEV_WRITE: do_write(&m); break;
case CANCEL : do_cancel(&m); break;
case HARD_INT : do_done(&m); break;
default: reply(TASK_REPLY, m.m_source, m.PROC_NR,
--- 73,79 ----
while (TRUE) {
receive(ANY, &m);
switch(m.m_type) {
! /* case DEV_WRITE: do_write(&m); break; */
case CANCEL : do_cancel(&m); break;
case HARD_INT : do_done(&m); break;
default: reply(TASK_REPLY, m.m_source, m.PROC_NR,
There is also a problem in fs/glo.h:
*** /users/src/fs/glo.h.org Thu Jun 6 00:29:53 1991
--- /users/src/fs/glo.h Wed Jun 5 19:21:13 1991
***************
*** 26,32 ****
EXTERN int rdwt_err; /* status of last disk i/o request */
/* Data which needs initialization. */
! typedef unsigned short u16_t; /* belongs in h/type.h */
extern u16_t data_org[INFO + 2];/* origin and sizes of init */
/* belongs in h/build.h */
extern int (*call_vector[])(); /* table of system calls handled by FS *
/
--- 26,32 ----
EXTERN int rdwt_err; /* status of last disk i/o request */
/* Data which needs initialization. */
! /* typedef unsigned short u16_t; /* belongs in h/type.h */
extern u16_t data_org[INFO + 2];/* origin and sizes of init */
/* belongs in h/build.h */
extern int (*call_vector[])(); /* table of system calls handled by FS *
/
the 'typedef unsigned short u16_t ; ' is already done in <sys/types.h>,
the typedef there is equivalent: ACK and C68 handle this different:
- ACK gives an error (and produces no output file);
- C68 gives no warnings or messages;
Is there a correct definition how a C compiler should handle this !
I was able to compile a running kernel using the ACK compiler! but
it is not completely tested yet.
I still have problems with the system I build with C68, after mounting
my two Minix partitions I get a kernel panic 'trap via vector 2'....
(this is still in the /etc/rc script, before you are asked to input
the date).
I do have a running 1.5.10.3 kernel compiled with C68 so wonder what
could have changed that makes this difference (should I look in one
of the assembly files, or is it because I'm currently using c68 patchevel 3
instead of patchlevel 2??.
My systems is: St1040, with root FS on hd3, no Ram-disk and 126k cache!
NOTE: the cdiffs I included are only to show where I've had problems, and
how they "could" be fixed, they aren't very sophisticated and
non-official of course.
--
Frank Breure (breure@itihp1.tno.nl)
TNO Institute of Applied Computer Science Delft, The Netherlands
----------------------------------------------------------------------
My opinions may be subject to change without notice.