How do you find the number of people mapped to global section?

[Roger Tucker]

I've looked everywhere, but I'm sure I'm just missing it. I need to know the number of other processed mapped to a reserved memory global section. We need a system service SYS$GETGDI() or something to return information about global sections. I think the field I need is SEC$L_REFCNT. Is there an good way to get to this without writing some kernel code (and don't say use INSTALL/LIST to a file and search for it - that's lame.) What makes openVMS so cool, is there is a system service for almost everything - except for this?

[Hein van den Heuvel]

'What problem are you really trying to solve'

I know, htat may come over just about as lame as 'use INSTALL/LIST...' but seriously, there may be a better way to solve the problem?

Just to be able to report the number is neat and interesting and all, but how do you intend to use that in an application?

Maybe the part of the application which maps the section can also take out a lock, keeping count in the lock value block? A lock is often useful to find out whether the section is properly initialized already or not. It would be a fuzzy count due to processing leaving without clearing out, but getlki coudl be used for an accurate reading (grantcount+cvtcount) / reset.

Maybe trying to map is enough to know whether it is still there or whether the last use left and a delete was effected?

hth,
Hein.

[Robert_Boyd]

Roger,

I went looking for something like this a few months back -- and found out that this is currently still a non-trivial problem.

I had some email exchanges with a couple of people in HP support about this -- definitely a wishlist item unless someone has done some freeware work that is not generally available yet.

Robert

[Ian Miller.]

"some freeware work that is not generally available yet." - just in my head so far - I keep thinking there is a gap to fill especially with the more difficult question of which processes are mapped to a specific global section.

See
http://h71000.www7.hp.com/wizard/wiz_3365.html
http://h71000.www7.hp.com/wizard/wiz_3530.html
http://h71000.www7.hp.com/wizard/wiz_3635.html
http://h71000.www7.hp.com/wizard/wiz_3768.html

[Roger Tucker]

Since there was no system service routine on VMS to return global section information, and since I needed the reference count --- I decided to write one. It's not finished -- right now all it returns is the reference count and doesn't support an item list yet. I'm posting it here, because it works and for anyone to make comments about the code. This routine jumps to kernel mode, so if it crashes your system - you have been warned... If you see something wrong, or have a suggestion let me know. When I'm done with the item list changes, I'll try to post it again... VMS engineering can have this when I'm done, maybe it will be the first wave of open source programming for openVMS. We can all hope they will see the light someday... :-) Thanks, Roger

[Roger Tucker]

Didn't see my attachment - trying again.

[John Gillings]

Roger,

// if (ipl < IPL$_ASTDEL) __PAL_MTPR_IPL(ipl);
/* Don't understand this!!!! */

You should be restoring IPL to the level at the start of your routine, which is the intent of the above call.

I think in your case, it's being done for you by the return path through SYS$CMKRNL, but if this routine were entered through an exception change vector, you would probably crash soon after returning to the caller.

There's also a potential issue if the routine happened to be called from a higher IPL, as you can't just drop down to ASTDEL.

Although this is unlikely, when you're writing kernel mode code, you can't leave holes like that open. You're doing all the right things, probing your argument list, taking out appropriate spinlocks locks, mutexes and setting IPL. You need to make a decision about the environment you're prepared to execute from, in terms of IPL and spin locks that may already be held, and check your assumptions.

Like Hein, I'm really not sure WHY you need to know this. There may be a safer and cleaner way of doing what you're really trying to do.

[Ian Miller. · Accepted solution]

Note that the REFCNT is not the number of processes refering to the section but the number of PTEs refering to the section. If all the processes who use the section mapped the whole section then dividing REFCNT by SEC$L_UNIT_CNT would give you the number of processes referring to the section.

It would be best to package this as a system service. See SYS$EXAMPLES:UWSS.C for an example of how.

I would define the argument list as a structure whose members are the correct types for each parameter rather than an array of unit64.

[Roger Tucker]

Thanks for the note about REFCNT. For reserved memory global sections things get even more complex. There are two GSDs if you are using shared PTEs, and two GSTE's. The SEC$Q_MRES_REFCNT in the GSTE seems to be the number of pagelets referenced when mapped. GSD$L_RELATED_GSTX points to the related GSTE.

This has been fun and I'm learning a lot. For example, when I was playing around. I allocated the parameters on the kernel stack and I called my routine getgsi() from kernel mode just like a function call and it returns an ACCVIO from the $probew_1q(). The reason for this is that "callers_mode" is still USER(3). So, I'm starting to understand about what was meant by "the environment." Caller's mode doesn't mean a call frame like I first thought, but from from the last mode change.
even mmg_std$gsdscan() returns ACCVIO if the section name is in kernel mode. So, how does this work. If your in kernel mode, but want to call a system type service (and it is save), you have to do another mode change or go through the system service dispatcher, so that previous mode is kernel instead of still user?

I know, I know - we need a book on writing kernel mode code, but you just don't learn till you do it.

[Ian Miller.]

There is nothing like actually writing kernel mode code to demonstrate what you don't know :-) I find the Internals boot and 'Writing OpenVMS Alpha Device Drivers in C' books the most useful. I'm surprised that mmg_std$gsdscan() returns ACCVIO if the section name is in kernel mode. Ultimately you have to have the operating system listings if you are going to call internal routines so you can see what they expect and what checks they do.

All this is fun and educational but what is the problem you are trying to solve by getting this data?