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

[whygee@club-internet.fr]

hello, new and not-so-new readers,

i am at LSM until monday and internet access is not
easy for my poorly configured computers, but most
mails recipients are physically here :-)

----Message d'origine----
>De: "Nicolas Boulay"
>
>Cedric, Whygee and i have travel to Bordeaux to assist to the libre
>software meeting ( lsm.abul.org ). Lots of people from very differents
>open/libre source word are comming.
>
>It end tomorow. The following is a little feed-back from our discussion
>with different people. (we don't know where is whygee so i send you
>without his rereading)

sorry, i woke up late and had to gather some food for the week-end, i explained the F-CPU development to a Hurd guy
all night long...


>Security point of view
>
<snip>
>  They propose :
>     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.

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.

>>From Cedric thinks :
>     we need 3 sr : to set or unset the tbl 
i presume that we will need much more, as the interface
must remain clean and orthogonal throughout different
core types... let's make something simple, logical
and easy to understand from the beginning, even though if we
don't use all the features now...

>      something to change the ring
>      for vm writter we must enable or not the read
>       access to sr(trap on read AND write)

SRs will contain a place which says what the current user
can read and/or write => not a problem (it's slow anyway, so...)
it's not yet defined in the VHDL sources but will become
a reality whenever the corresponding piece of code is written.

>>From discussion with a Hurd guy (Neal Wafield)
hmmm... speaking about God and its saints .. ;-)
we started speaking about IPC yesterday...

>     16 kb for a page is a little bit to much
why ? if you have huge datasets (megabytes, gigabytes...)
you will spend your time in the trap handler...
i count on the OS to "gather" contiguous small pages into
larger ones, possibly based on usage statistics (that the
CPU could gather).

>     8 kb could be enough
>     all new processor have between 5 to 11 page size !
cool.
however too many sizes might make the LSU more complex :-(
i guess that 4 is the best tradeoff.

****************************
  Don't let children look
****************************

i just found a REALLY naughty  (cough)#hack# ....

it doesn't soleve the page size problems
but removes some "kernel addressing " problems,
which make the LSU a bit more complex...

>     alpha handle an 8 bits fields for virtual area number (for tlb and
>       caches) -> sw must avoid collusion.
you mean "collision" ? :o)

>     we should try to implement L4 (hurd main kernel) to verify the
>       process management of the f-cpu
whatever you want as long you #do# it ...
you know the song....

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

>Conclusion :
>     implemented L4
>     change specification of the tlb (no more the kind of caches use
>     but an 8 bits fields)

8-bit field if you want but will this solve virtual
aliases problems ?

>     Looking for technics to handle different page size on the same
>       memory for (tlb) to avoid the use of many independant memories

my current method is to have N parallel TLBs with 
one size each. Say, 8 entries for 4KB, 8 entries for 32KB,
8 entries for 256 etc...

>Hope this help. Comments ?

let's have a talk :-)

>nicO and Cedric

YG

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