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

[Lee Salzman <lee.salzman@lvdi.net>]

On Sat, Jul 13, 2002 at 01:57:03AM +0200, Michael Riepe wrote:
> 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'.
> 
    
    I have to agree with Michael here. In all the time I've been making
kernels, I've never EVER found protection levels to be of any use.
Separate masks for supervisor and user level for the page are the way 
to go, i.e. user RWX and supervisor RWX.

> > 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.'
> 

    One protection level is one too many. Capability masks
allow features to be more smoothly virtualized and privileges to
be more easily delegated. Protection levels just totally munge this
idea.

> [...]
> > >>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?
> 
    
    Aside from a test-and-set instruction, you can implement just about
any type of worthwhile thread synchronization in software. Even better
is to just have your threads running asynchronously whenever possible.

> -- 
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>

    Lee

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