On 6/11/2021 0:09, Don Y wrote:
> On 6/10/2021 8:32 AM, Dimiter_Popoff wrote:
>> On 6/10/2021 16:55, Don Y wrote:
>>> On 6/10/2021 3:45 AM, Dimiter_Popoff wrote:
>>>
>>> [attrs elided]
>>  >
>> Don, this becomes way too lengthy and repeating itself.
>>
>> You keep on saying that a linear 64 bit address space means exposing
>> everything to everybody after I explained this is not true at all.
>
> Task A has built a structure -- a page worth of data residing
> at 0x123456.  It wants to pass this to TaskB so that TaskB can perform
> some operations on it.
>
> Can TaskB acccess the data at 0x123456 *before* TaskA has told it
> to do so >
> Can TaskB access the data at 0x123456 WHILE TaskA is manipulating it?
>
> Can TaskA alter the data at 0x123456 *after* it has "passed it along"
> to TaskB -- possibly while TaskB is still using it?

If task A does not want any of the above it just places them in a
page to which it only has access. Or it can allow read access only.
*Why* do you confuse this with linear address space? What does the
one have to do with the other?

>
>> You keep on claiming this or that about how I do things without
>> bothering to understand what I said - like your claim that I use the MMU
>> for "protection only".
>
> I didn't say that YOU did that.  I said that to be able to ignore
> the MMU after setting it up, you can ONLY use it to protect
> code from alteration, data from execution, etc.  The "permissions"
> that it applies have to be invariant over the execution time of
> ALL of the code.
>
> So, if you DON'T use it "for protection only", then you are admitting
> to having to dynamically tweek it.

Of course dps is dealing with it, all the time. The purpose of the
linear *logical* address space is just orthogonality and simplicity,
like not having to remap passed addresses (which can have a lot
of further implications, like inability to use addresses in another
tasks structure).

>
> *THIS* is the cost that the OS incurs -- and having a flat address
> space doesn't make it any easier!  If you aren't incurring that cost,
> then you're not protecting something.

Oh but it does - see my former paragraph.

>
>> NO, this is not true either. On 32 bit machines - as mine in
>> production are - mapping 4G logical space into say 128M of physical
>> memory goes all the way through page translation, block translation
>> for regions where page translation would be impractical etc.
>> You sound the way I would have sounded before I had written and
>> built on for years what is now dps. The devil is in the detail :-).
>>
>> You pass "objects", pages etc. Well guess what, it *always* boils
>> down to an *address* for the CPU. The rest is generic talk.
>
> Yes, the question is "who manages the protocol for sharing".
> Since forever, you could pass pointers around and let anyone
> access anything they wanted.  You could impose -- but not
> ENFORCE -- schemes that ensured data was shared properly
> (e.g., so YOU wouldn't be altering data that *I* was using).
>
> [Monitors can provide some structure to that sharing but
> are costly when you consider the number of things that may
> potentially need to be shared.  And, you can still poke
> directly at the data being shared, bypassing the monitor,
> if you want to (or have a bug)]
>
> But, you had to rely on programming discipline to ensure this
> worked.  Just like you have to rely on discipline to ensure
> code is "bugfree" (how's that worked for the industry?)
>
>> And if you choose to have overlapping address spaces when you
>> pass a pointer from one task to another the OS has to deal with this
>> at a significant cost.
>
> How does your system handle the above example?  How do you "pass" the
> pointer from TaskA to TaskB -- if not via the OS?  Do you expose a
> shared memory region that both tasks can use to exchange data
> and hope they follow some rules?  Always use synchronization
> primitives for each data exchange?  RELY on the developer to
> get it right?  ALWAYS?

I already explained that. If task A wants to leave a message
into task B memory it goes through a call (signd7$ or whatever,
there are variations) and the message is left there.
If task A did not want to receive messages it won't even be
attempted by the OS, will return a straight error (task does not
support... whatever). If the message is illegal the result is
similar. And if it happens that task A tries to access directly
memory of task B which it is not supposed to it will just go to
the "task A memory access violation. Press CR to kill it".

You have to rely on the developer to get it right if they
write supervisor code. Otherwise you need not.
The signalling system works in user mode though you can
write supervisor level code which uses it, but if you
are allowed to write at that level you can mess up pretty
much everything, I hope you are not trying to wrestle
*that* one.

>
> Once you've passed the pointer, how does TaskB access that data
> WITHOUT having to update the MMU?  Or, has TaskB had access to
> the data all along?

By just writing to the address task A has listed for the
purpose. It is not in a protected area so the only thing
the MMU may have to do is a tablewalk.

*THIS* demonstrates the advantage of the linear logical
address space very well.

>
> What happens when B wants to pass the modified data to C?
> Does the MMU have to be updated (C's tables) to grant that
> access?  Or, like B, has C had access all along?  And, has
> C had to remain disciplined enough not to go mucking around
> with that region of memory until A *and* B have done modifying
> it?

Either of these has its area which allows messaging. I don't
see what you want to achieve by making it only more cumbersome
(but not less possible) to do.

> I don't allow anyone to see anything -- until the owner of that thing
> explicitly grants access.  If you try to access something before it's
> been made available for your access, the OS traps and aborts your
> process -- you've violated the discipline and the OS is going to
> enforce it!  In an orderly manner that doesn't penalize other
> tasks that have behaved properly.

So well, how is the linear address space in your way of doing that?
It certainly is not in my way when I do it.

>
>> In a linear address space, you pass the pointer *as is* so the OS does
>> not have to deal with anything except access restrictions.
>> In dps, you can send a message to another task - the message being
>> data the OS will copy into that tasks memory, the data being
>> perfectly able to be an address of something in another task's
>
> So, you don't use the MMU to protect TaskA's resources from TaskB
> (or TaskC!) access.  You expect LESS from your OS.

Why on Earth do you think that? And what does the linear address space
have to do with *any* of it?
Pages can be as small as 4k why do you not just have them properly
setup upon task start or at some time by having the page which
can receive messages open to accesses and the rest closed?
And again, how on Earth do you see any relevance between a linear
logical address space and all this.

>
>> memory. If a task accesses an address it is not supposed to
>> the user is notified and allowed to press CR to kill that task.
>
> What are the addresses "it's not supposed to?"  Some *subset* of
> the addresses that "belong" to other tasks?  Perhaps I can
> access a buffer that belongs to TaskB but not TaskB's code > Or, some OTHER buffer that TaskB doesn't want me to see?  Do
> you explicitly have to locate ("org") each buffer so that you
> can place SOME in protected portions of the address space and
> others in shared areas?  How do you change these distinctions
> dynamically -- or, do you do a lot of data copying from
> "protected" space to "shared" space?

This is up to the tasks, they can make system calls to mark
pages non-swappable, write protected etc., you name it.
And again, ***this has nothing to do with orthogonality
of the logical address space***.

>
>> Then there are common data sections for groups of tasks etc.,
>> it is pretty huge really.
>
> Again, you expose things by default -- even if only a subset
> of things.  You create shared memory regions where there are
> no protections and then rely on your application to behave and
> not access data (that has been exposed for its access) until
> it *should*.

Why would you want to protect regions you don't want protected?
The common data sections are quite useful when you write a largish
piece of software which runs as multiple tasks in multiple
windows - e.g. nuvi, the spectrometry software - it has
multiple "display" windows, a command window into which
one can also run dps scripts etc., why would you want to
deprive them of that common section? They are all part of the
same software package.
But I suppose you are not that far yet since you still wrestle
scheduling and memory protection.

>
> Everybody does this.  And everyone has bugs as a result.  You
> are relying on the developer to *repeatedly* implement the sharing
> protocol -- instead of relying on the OS to enforce that for you.

Not at all. And for I don't know which time, this has 0% to do
with the linearity of the logical address space which is what
you objected.

Please let us just get back to it and just agree with the obvious,
which is that linear logical address space has *nothing* to do
with security.

Leave DPS alone. DPS is a large thing and even I could not
tell you everything about it even if I had the weeks it would
take simply because there are things I have to look at to
remember. Please don't try to tell the world how the OS you want
to write is better than what you simply do not know.
Tell me about the filesystem you have
implemented for it (I'd say you have none by the way you
sound), how you implemented your tcp/ip stack, how your
distributed file system works (in dps, I have dfs - a device
driver which allows access to remote files just as if they
are local provided the dfs server has allowed access to that
user/path etc.). Then tell me how you implemented windowing,
how do you deal with offscreen buffering, how do you refresh
which part and how do you manipulate which gets pulled where
etc. etc., it is a long way to go but once you have some
screenshots it will be interesting to compare this or that.
Mine are there to see and well, I have not stopped working
either.

Dimiter

======================================================
Dimiter Popoff, TGI http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/