Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts)

From: [email-masked] (Noel Chiappa)
Date: Thu, 23 Nov 2006 16:44:25 -0500 (EST)

> From: Pekka Nikander <[email-masked]>

    > What I was missing, at minimum, in the above definition is that a name
    > being "virtual" seems to require another layer of indirection.

Yes, that (at least) is part of "virtual".

    > the *entities* referred to by that separate context are "virtual" in
    > the sense that they point to the "real" entities only _indirectly_,
    > either through the "virtual entities" being mapped directly to the
    > "real entities", or by the mapping taking place through first mapping
    > the "virtual entities" to "real names". I believe the latter case is
    > more usual.

The ones I can think of quickly, yes, but I would not claim that is a
complete survey!

    >  1. There is only one name space, S.

Well, it depends on what you mean by "name space". If you mean i) "one set of
syntactically possible names", yes. If you mean (as I usually do) ii) "a
naming context" - your next line - no. But I assume you mean the former, and
with that I kind of agree.

Not totally, mind, because I can think of examples (e.g. Multics virtual
memory, which was segmented and paged, but the machine's physical memory was
not segmented) where the syntax of the virtual objects name-space was
different from the syntax of the real objects name-space.

    >  2. There are two or more naming contexts, each mapping
    > the names in S into a different entity space E_i.

Well, they could all map to the same single physical entity space (for
example, processes in Unix, running on a single processor - each has a
virtual address space, but they all map to a single physical memory space).
Or there could be a set of physical entity spaces Ei (for example, processes
running on a multi-processor box, where each CPU has its own unshared memory).

  3. One entity space is considered "real", others "virtual".

I'd change this to "One or more is considered real" - see example above with
multiple CPU's.

  4. There is at least one extra layer of indirection from
     "virtual names" to "real entities", compared to mapping
     "real names" to "real entities".

Right. To go back to the CPU/memory example, mapping of physical addresses to
memory cells is performed in hardware (via bank recognition logic, cell
decoding logic, etc), and the mapping of virtual addresses to physical
addresses is done by page tables.

There are instances in which more than one layer of mapping is collapsed into
one. For example, consider a cache which takes in virtual addresses and
returns hits directly - the normal circuitry involved in turning physical
addresses into physical memory cells is never utilized. If the cache is
organized as a content-addressable-memory (i.e. each data cell is tagged with
the address of the data it holds), there's no mapping at all, really: the
virtual name turns directly into the data.

    > There are obvious benefits and drawbacks stemming from the (re)use of
    > the single name space.

Indeed!

    > The next interesting question is what is the exact difference between
    > virtualisation and delegation, both being examples of indirection, and
    > both typically taking place within a single name space.

Oh, that's easy. They involve different things entirely. Virtualisation
involves mapping between different name-spaces (in the sense of "naming
contexts"). Delegation typically involves handing authority for the assignment
of names within a chunk of a given name-space (real or virtual, it doesn't
matter) off to some other entity, away from the primary entity which has the
responsibility/control of that namespace.

    > (No, I don't have an answer to that right now here, but it's 10pm over
    > here.)

:-) I know that feeling! (And it's Thanksgiving on this side of the water!
So I must go, for now, too....)

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss