Rep:Re: [f-cpu] little feed-back from the libre softawre meeting

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

Interressing stuff !

-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 13/07/02
Objet: Re: [f-cpu] little feed-back from the libre softawre meeting

On Sat, Jul 13, 2002 at 01:30:45AM +0200, whygee@club-internet.fr wrote:
[...]
> >     read, write, exec bit + at least 3 rings (super user + user +
> >     something like for library,...)
> 
> RWX is ok, because this is how protection is enforced.
> i'd say that it is the minimum required TLB feature.

*nod*

What about different permission bits for different protection levels?
Like `supervisor may read and write, j. random luser may only read'.
That's probably better than a `user/supervisor' bit or an explicit
`page protection level'.

>>> During the travel to bordeaux, cedric and i think about using unix
file system style protection. With users, groups and others permition.
But after many discussions to kernel guys, they have nothing to do with
it.

>>> Maybe it could be used as user == a virtual address space, other
rings are like groups inside the address space. The problem come when
you want to change the ring : how do you come back to the good ring ?
(with a stack ?)
 
>>> Praticaly you access the tlb with virtual adress + the asn (address
space number manage by the sw, the name came from alpha world), it
return a miss or the physical address + the tags.
 The tags could be simply the rwx bit + rings number. If we want real
kind of groups (like unix file system), it must send back the rights for
every ring and we must compare the bit according to the status of the
current code. Could be interresting if there isn't too much ring.

> Concerning rings and groups, the issue is still open,
> as several proposal and ideas are floating and careless
> design will turn F-CPU implementations into a VAX-like,
> or worse... helping SW and OS is ok, as long as we don't
> do in HW all the work. It must be also "friendly" with
> many OS approaches, so i choose the "least common denominator"
> approach. A TLB with RWX rights and VMID is the most common
> feature and it's straight-forward to understand for SW and
> HW design. I'll try to continue to speak with the OS guyz
> (linux, Hurd and *BSD) to sort this.

Misquoting Bill Gates:

 `Two protection levels should be enough for every OS.'

[...]

>>>It's the guy who write the grsecurity patch that say that some people
try to use the third ring of x86 to increase protection.

> >>From my view,
> >     none polling thread barrer should be implemented (for tigh
> >     multithreaded application on multicpu)
> 
> please rephrase that and spellcheck it, i did not understand.

He probably meant: a non-polling thread barrier should be implemented
for
`tight' multithreading. I'm not sure what he means with `thread
barrier',
though - something like a hardware semaphore?

>>>kind of. But much more simple. More like a mutexes. It come to my
mind when i see here one of my professor from my university year ;p
In  some courses, i have seen different model to program massevily
parrallel machine. For the professor, the easier way and the most
effective way of programming is "big step" programm. Each processor run
it's own thread so this could be used at the thread level. 

>>>In fact, imagine a big loop split in 4 inside 4 thread. After the
loop, the program reused the data. Instead having a costly semaphore. A
easy way to do it is to put a "barrer", when a thread finish its work it
reach the barrer and must wait the other when the 4 threads have reach
the barrer the program continue.

>>> It could be a kind of mutexes, and could be uniq for a group of
thread. For the futur it could be nice to have more than a uniq
ressource. Imagine actual multireaded application but compile to use
more than a single cpu. So each " programmed thread" could have has many
threads as cpu.
nicO

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/