Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!star.cs.vu.nl!philip
From: philip@cs.vu.nl (Philip Homburg)
Newsgroups: comp.os.minix
Subject: Re: Bug in ST-kernel 1.5.10.4
Message-ID: <10205@star.cs.vu.nl>
Date: 16 Jun 91 19:46:42 GMT
References: <56110@nigel.ee.udel.edu> <3252@krafla.rhi.hi.is>
Sender: news@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Lines: 33

In article <3252@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
%>proto.h:
%>_PROTOTYPE( void set_name, (int source_nr, int proc_nr, char *ptr));
%                                 ^^^^^^^^^
%Can anyone tell us what this extra parameter is for. The change is not very
%well documented as to what its purpose is.
%
%>system.c:
%>set_name(m_ptr->PROC1, (char *)sp);     /* save command string for F1 display */
%>set_name(proc_nr, (char *) 0);  /* disable command printing for F1 */
%
%Obviously a suitable value for source_nr needs to be added to the left of the
%parameter list in these function calls. It seems to me that simply duplicating
%the first parameter here will fix this kernel bug quite adequately and display
%the names correctly. I haven't had a chance to check it yet though.
%
%set_name is called elsewhere with different values for source_nr and proc_nr
%so it is not an acceptable solution to remove source_nr from the function
%definition.

The the semantics of set_name are changed. It used to record a pointer to
the program name in the address space of the process. This caused problems
with forks and it might not be the true name of the executable. In the
new version of set_name, the name of the executable is copied and stored
in the kernel. But that name comes from the address space of MM so
set_name(source, proc, ptr) means that the name for process proc is stored
at location ptr in process source.





						Philip