sverre@fesk.UUCP (Sverre Froyen) (12/04/88)
I have tried to get Brandon's sysV version of w to work on my National Semiconductor ICM3216 running SysV.2.2. This is a demand paged system and, as Brandon points out in the documentation, w is unable to locate the user structure. I have looked through the system documentation and various include files but I am unable to find the solution (I have no source). I suspect I must start with the value of p_addr in the proc table, which is a short integer, (this entry is replaced by page tables for the user block in SysV.3) and then go through some of the macros for the page tables. Unfortunately, guesswork won't cut it and I was hoping somebody on the net possesses some hard information. Thanks, Sverre -- Sverre Froyen UUCP: boulder!fesk!sverre, sunpeaks!seri!fesk!sverre ARPA: froyen@nmfecc.arpa BITNET: froyen@csugold.bitnet
allbery@ncoast.UUCP (Brandon S. Allbery) (12/11/88)
As quoted from <214@fesk.UUCP> by sverre@fesk.UUCP (Sverre Froyen): +--------------- | I have tried to get Brandon's sysV version of w to work on my | National Semiconductor ICM3216 running SysV.2.2. This is a | demand paged system and, as Brandon points out in the documentation, | w is unable to locate the user structure. I have looked through | the system documentation and various include files but I am unable | to find the solution (I have no source). I suspect I must start +--------------- I've been trying to find it myself, via trial-and-error; I want to use it on a few demand-paged System V-based machines myself. Anyone know what V.2.2 and V.3.1 do with the ublock? Thanks in advance, all. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
root@rpp386.Dallas.TX.US (The Beach Bum) (12/11/88)
In article <13232@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <214@fesk.UUCP> by sverre@fesk.UUCP (Sverre Froyen): >+--------------- >| I have tried to get Brandon's sysV version of w to work on my >| National Semiconductor ICM3216 running SysV.2.2. This is a >| demand paged system and, as Brandon points out in the documentation, >| w is unable to locate the user structure. I have looked through >| the system documentation and various include files but I am unable >| to find the solution (I have no source). I suspect I must start >+--------------- > >I've been trying to find it myself, via trial-and-error; I want to use it on >a few demand-paged System V-based machines myself. Anyone know what V.2.2 >and V.3.1 do with the ublock? /dev/mem is a very fast device. Searches on it are so simple as to be obsurd. Start with a finding SOME collection of information which will allow you to identify the ublock as being your own. The address of your own process table entry is a real unique sort of number. That item is no sweat to find. Next, stare at the proc structure to see what sort of information it gives you. p_daddr and p_caddr are two good guesses. proc.h _usually_ has enough info for you to figure out which one it is. Then, using the macros in param.h or sysmacros.h or some other collection of headers, make a really good guess about WHERE you expect the ublock to be. Put the two of them together. Start by finding your process table entry. Save the address in the table where you found it, because you may need it later. Now, SEQUENTIALLY read all of the memory in /dev/mem trying to find YOUR ublock. When you do [ and you should sooner or later ... ], you know you have found at least ONE block in the case of a demand paged system. If you aren't on a system which pages the ublock [ the ublock is contiguous starting at some address ], you should be able to, with some experimentation, deduce the formula used to locate the ublock. If you ARE on a system where the ublock is not contiguous, you at least should be able to determine the method used to store that one page. Look at the page table entries [ god willing ... ], and once you have figured out how you got that one page, you should be able to figure out how to get the rest of them.
root@yclept.UUCP (Root) (12/12/88)
In article <13232@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <214@fesk.UUCP> by sverre@fesk.UUCP (Sverre Froyen): >+--------------- >| I have tried to get Brandon's sysV version of w to work on my >| National Semiconductor ICM3216 running SysV.2.2. This is a >| demand paged system .... >+--------------- >I've been trying to find it myself, via trial-and-error; I want to use it on >a few demand-paged System V-based machines myself. Anyone know what V.2.2 >and V.3.1 do with the ublock? I have seen several methods used to address the user block. One method is to use a pointer in a fixed location, possibly an area that is particulary easy to address for the particular processor the system is running on. If memory copying is relatively cheap on the particular processor, the user area can be swapped to a fixed real memory address. If the kernel itself runs with the memory mapping unit active, another method is possible -- the active user area is remapped to a fixed virtual area. The most likely places to look for the code that handles to user switch is in the interrupt handlers and in the sleep() routine which dispatches a waiting process onto the processor. That is determined by the implementation and not by any description of the interface between the kernel and the application programs. Randy Herber, @ home: {att|amdahl|mcdchg|obdient|wheaton}!yclept!rjh, rjh@yclept.chi.il.us, Disclaimer: These are my personal views. Nothing may be construed about my employer's or customers' views or plans from this information.
dwc@homxc.UUCP (Malaclypse the Elder) (12/13/88)
In article <13232@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > As quoted from <214@fesk.UUCP> by sverre@fesk.UUCP (Sverre Froyen): > +--------------- > | I have tried to get Brandon's sysV version of w to work on my > | National Semiconductor ICM3216 running SysV.2.2. This is a > | demand paged system and, as Brandon points out in the documentation, > | w is unable to locate the user structure. I have looked through > | the system documentation and various include files but I am unable > | to find the solution (I have no source). I suspect I must start > +--------------- > > I've been trying to find it myself, via trial-and-error; I want to use it on > a few demand-paged System V-based machines myself. Anyone know what V.2.2 > and V.3.1 do with the ublock? > > Thanks in advance, all. > it will all depend on the architecture of the machine that it is running on. but in the proc structure for each process (look in /usr/include/sys/proc.h), there should be entries for copies of the page table entries for the u_area. look in the comments for any hints. once you get the entry, just look for the physical page frame that the pages of the u_area is in (they are not necessarily contiguous). you can take it from there. another alternative, if the system also uses segments, is to look at the segment table for the page table of the u_area. this too, should be kept in the proc structure. danny chen att!homxc!dwc
hutch@lzaz.ATT.COM (R.HUTCHISON) (12/13/88)
From article <13232@ncoast.UUCP>, by allbery@ncoast.UUCP (Brandon S. Allbery): ~ As quoted from <214@fesk.UUCP> by sverre@fesk.UUCP (Sverre Froyen): ~ +--------------- ~ | I have tried to get Brandon's sysV version of w to work on my ~ | National Semiconductor ICM3216 running SysV.2.2. This is a ~ | demand paged system and, as Brandon points out in the documentation, ~ | w is unable to locate the user structure. I have looked through ~ | the system documentation and various include files but I am unable ~ | to find the solution (I have no source). I suspect I must start ~ +--------------- ~ ~ I've been trying to find it myself, via trial-and-error; I want to use it on ~ a few demand-paged System V-based machines myself. Anyone know what V.2.2 ~ and V.3.1 do with the ublock? ~ ~ Thanks in advance, all. ~ ~ ++Brandon ~ -- ~ Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X In the systems I have looked at, the user area is either indirectly pointed to by an entry in the process table (something like p_ubptbl) or is stuck somewhere in a process-page table. If you have a pointer to the page table, you will have to look at a system reference manual to see how the ptbl maps vitrual to physical pages and then use this information to trot off and find them. If the user area is stuck in a process page table, I believe that you would need more detailed information on your implementation of the OS to find its virtual address and, hence, its relative location in the page table. If the process has been swapped (5.3.1 and after), you may have to go to the correct swap device to find it (real pain for applications). In any case, you will always run the risk of not finding it where you througt it was supposed to be, especially if there is a lot of paging going on on your system (applications are always pre-emptable at any time (well amost any):) I wonder if anyone has thought about making the handling of the user area portable in SVR4? It seems to be quite different in every version I've looked at. I assume that the reduction of machine-specific code is an objective for new releases, especially in the memory management area. Bob Hutchison att!lzaz!hutch
arnold@emory.uucp (Arnold D. Robbins {EUCC}) (12/14/88)
In article <309@lzaz.ATT.COM> hutch@lzaz.ATT.COM (R.HUTCHISON) writes: >I wonder if anyone has thought about making the handling of the user >area portable in SVR4? It seems to be quite different in every >version I've looked at. I assume that the reduction of >machine-specific code is an objective for new releases, especially in >the memory management area. Won't /proc in SVR4 finally handle this right? The kernel knows where the u block is, let the kernel get it for you. inews fodder inews fodder inews fodder inews fodder inews fodder -- Arnold Robbins -- Emory University Computing Center DOMAIN: arnold@unix.cc.emory.edu UUCP: { decvax, gatech, skeeve }!emory!arnold BITNET: arnold@emoryu1 PHONE: +1 404 727-7636 FAX: +1 404 727-2599
logan@vsedev.VSE.COM (James Logan III) (12/14/88)
In article <9338@rpp386.Dallas.TX.US> root@rpp386.Dallas.TX.US (The Beach Bum) writes: # If you ARE on a system where the ublock is not contiguous, you at least ... Like mine... # should be able to determine the method used to store that one page. Yeah, sure. I spent two weeks doing this once. I finally got ahold of the sources for the "ps" command and I still can't determine the method. (Talk about spaghetti code... Yuck!) I didn't look at the sources for very long, but it wasn't immediately apparent. I'll look at the source again this weekend maybe and explain the method that my version of System V uses. # Look at the page table entries [ god willing ... ], and once you have # figured out how you got that one page, you should be able to figure out # how to get the rest of them. -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
guy@auspex.UUCP (Guy Harris) (12/14/88)
>I wonder if anyone has thought about making the handling of the user >area portable in SVR4? It seems to be quite different in every >version I've looked at. I assume that the reduction of >machine-specific code is an objective for new releases, especially in >the memory management area. Yes, the machine-dependencies in the VM code should be more centralized and circumscribed in S5R4.0, since it's picking up SunOS 4.0-style VM code. I don't know how portable the U area stuff will be; some of that may still end up being part of the machine-dependent code. Then again, S5R4 should also have "/proc", which will provide what should be a machine-independent way to get a lot of information about processes, obviating the need to rummage around in the kernel's address space and know how it implements the U area.