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

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

-----Message d'origine-----
De: whygee@club-internet.fr
A: f-cpu@seul.org
Date: 13/07/02
Objet: Re: [f-cpu] little feed-back from the libre softawre meeting

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

>>> For neal, the probleme came when a task ask for a very large amount
of memory you gie him a large page but then he will not use the all
memory so it could be good to catch all the unused memory. That's could
only be done with smaller page size.   

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

>>> i-64 give 4, 8,16,... kb page size (11 size !)

****************************
  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 ?

>>> That's the sw problem ! you need bigger number than the number of
line in the tlb (8 bits === maximum 255 line in the tlb)

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

>>>That's few !! It will be better to avoid so much different table but
maybe it's the only solution.
nicO (that go to see the RMS show ;p)

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

 
______________________________________________________________________________
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/