Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!mcsun!hp4nl!star.cs.vu.nl!sreiz
From: sreiz@cs.vu.nl (Steven Reiz)
Newsgroups: comp.os.minix
Subject: Re: AmigaMINIX 1.5.10.1 Problems - already!!
Message-ID: <10308@star.cs.vu.nl>
Date: 26 Jun 91 09:25:20 GMT
Article-I.D.: star.10308
References: <1991Jun25.213421.25788@dircon.co.uk>
Sender: news@cs.vu.nl
Lines: 83

uad1146@dircon.co.uk (Stuart Millington) writes:

>   I have just upgraded AmigaMINIX to 1.5.10.1, it is running 
>on with an A2091 HDC. I have a few question/problems:

>1)  'ps' does not find the proccess names. 
>    'ps -U /kernel /fs /mm' gives
>           can't read kernel namelist : no such file or directory

I have never tried it myself (ahum), but I guess that ps needs either
the .out files (kernel.out etc) or the .mix files to read the namelists,
have you tried both? I just looked at kernel.mix with strings, and it seems
to contain a symbol table. Second, are you sure that you actually created
a file /kernel (kernel.mix) etc? It seems to me that ps couldn't open
those files. Have you looked at ps.c?

>2)  I am using minix.img from the new boot disk in my hard drive 
>draw, so I do not need a floppy to boot. I did re-compile from 
>the new sources as a test. It worked perfectly - I did this 
>before the 'ps -U' above.
>    However since I tried compiling clam1.4, every time I try
>to compile anything I get :
>   exception 8 caused signal 4 to pid XX (procnr 6) at pc0x400, 
>sr0x0008

You can see which pass crashed with cc -v, I'll bet that it's cem.
If so, you might want to try the original cem on your ack disk,
maybe the copy on your hd has been corrupted?
The crc for cem, after chmem =120000 cem, should be 59962.
If it isn't, let me know (by email).

>3)  Why has WBminix been changed from a script to an executable, 
>which does the same thing the script used to do, but with 4 
>times as much disk space.[I do realise that disk space on the 
>boot disk is hardly scarce.]

I think that it might even save disk space, because the script needed
IconX, which some people might not have, it was not yet included in the
Workbench 1.2 release. Even more important, the new setup makes
'installing' minix unnecessary, because Minix no longer depends on
Workbench binaries (setmap, iconx, etc), just on setclock, which is
not vital.

> I consider it slightly bad practice 
>such a non-unique pathname as 'BOOT:' into an executable. I 

I agree. On the other hand I included the source, so you can change
it yourself, or write a script that uses IconX.

>realise it is _very_ easy to change this back into a script 
>myself, BUT are the people responsible for the official updates 
>going to depend on it being an executable in the future?

I guess not, in fact I don't even see how/why we could depend on that.

>BTW - how does MINIX handle file locking - to prevent multiple 
>simultaneous accesses, when it is not desirable? The UNIX books 
>I have looked in all say consult the local documentation because 
>all systems handle it differently. I can't find any references 
>in the 1.5 manual.

Minix does not (as far as I know) provide explicit locking primitives.
One way would be to create a dummy file, existance of the lockfile
meaning that nobody has the lock, nonexistance that someone does have the
lock:
lock()
{
	while (unlink("dummy.lock")== -1)
		sleep(1);
}

unlock()
{
	close(creat("dummy.lock", 0600));
}

>PS - last never found the correct logout time on 1.5.10.0, or 
>any subsequent patch - including 1.5.10.1 Is this a bug, or 
>just a problem on my system?

I'm not sure. Did it find the correct login time?

	Steven