<whitequark>
^ someone wrote me asking whether it was 3-clause BSD or some other BSD, after which I decided not to bother with BSD
<sb0>
whitequark, what is your argument for MIT?
<whitequark>
sb0: the fact that I don't want anyone, starting with me, to care about what version of BSD it is
fengling has joined #m-labs
<larsc>
sb0: the problem with lm32 is, as you well know, that the toolchain breaks every so often
<sb0>
larsc, then use navre or stick to a known-good version
<larsc>
no openrisc?
<kristianpaul>
larsc: what about picorv32?
<whitequark>
oh dear
<kristianpaul>
what did i said? :p
<sb0>
openrisc also has toolchain issues
<sb0>
not as bad as lm32, but still
<kristianpaul>
well...
<sb0>
i think Tomasz Wlostowski made a small riscv implementation; not sure how good it is nor if the toolchain works
<sb0>
whitequark, can you clarify what "storage for static experiments" is?
<whitequark>
sb0: me?
<sb0>
it's part of core device storage. yes, post on the ML
<whitequark>
ah, in that sense. yes
<sb0>
i guess the rest should be simply a) upload kernels in several packets (so we meet the 10MB/item spec) b) some global key/value store accessible from kernels, possibly as simple as a linked list using the lwip malloc and managed by the comms-cpu
<whitequark>
we don't need a), it's enough to call a host RPC that returns the large string
<whitequark>
since there are no limits on that
<whitequark>
as for b) I think that will conflict with the rudimentary MPU proposal
<whitequark>
not sure what can be done about that
<sb0>
put the key/value malloc area into kernel-cpu-dedicated memory space
<sb0>
i think lwip supports defining several malloc areas...
<whitequark>
ah yes, that would work
<sb0>
no limits on host RPC data sizes? so packet-splitting is implemented for those?
<whitequark>
oh.
<whitequark>
oh right, same problem.
evilspirit has joined #m-labs
rohitksingh has quit [Ping timeout: 272 seconds]
rohitksingh has joined #m-labs
<GitHub186>
[artiq] whitequark pushed 3 new commits to master: http://git.io/vEyYt