Which branch?

[Florian Hars]

Hi,

if i wanted to play around with an MCU peripheral which is not yet
supported in Tock, would I be better advised to stay on master, or
should I start with the new syscall interface in 2.0?

And if the latter, the documentation files touched on tock-2.0-dev are
doc/reference/trd-syscalls.md and doc/Porting_Capsules_2.md, is
everything one needs to know in there?

Florian.

[Florian Hars]

On 16.12.20 12:36, Florian Hars wrote:
> And if the latter, the documentation files touched on tock-2.0-dev are
> doc/reference/trd-syscalls.md and doc/Porting_Capsules_2.md, is
> everything one needs to know in there?

Oh, and after reading "4.5 Read-Only Allow" in trd-syscalls several
times I still don't know what it says. Does it explain that you cannot
even share read-only references to flash memory with the kernel because
you can only ever pass references to the writeable address space to
Allow syscalls (and it is in every way except that both sides get
read-only access to the shared memory identical to the Read-Write Allow,
which requires that every byte of the memory is writeable by the app),
or does it explain that the main purpose of Read-Only Allow is to share
data stored in flash with the kernel, as you would otherwise waste RAM?

It looks a bit like a copy and paste accident from the proposal to add
that syscall.

Florian.

[Philip Levis]

On Dec 16, 2020, at 5:15 AM, Florian Hars <flo...@hars.de> wrote:

 does it explain that the main purpose of Read-Only Allow is to share data stored in flash with the kernel, as you would otherwise waste RAM?

This one. Read Write Allow (Allow in the 1.x API) requires that the buffer passed is both readable and writeable. The kernel checks the MPU/PMP configuration that this is true; if it’s only readable, Allow/Read Write Allow fails. So you can’t pass a reference to data in flash to Read Write Allow.

I’ll try to clarify the text.

Phil

———————
Philip Levis (he/him)
Associate Professor, Computer Science and Electrical Engineering

Faculty Director, lab64 Maker Space
Stanford University
http://csl.stanford.edu/~pal

[Brad Campbell]

I think either is fine. If you want to take advantage of the new syscall interface please do, but working on top of 1.x is fine as well. 

- Brad

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/cf25c054-d325-1725-7c46-054db6b441be%40hars.de.

[Philip Levis]

I think I’d disagree with Brad on this one — we’re going to transition to 2.0 pretty soon, and so you’ll have to rewrite it for 2.0 anyways, so might as well start there.

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/CADEbMG3SW2FjWAj5MErtkuqwV6qk1Duty7sp7y-jVvvOk%2BH9_A%40mail.gmail.com.

[Florian Hars]

On 17.12.20 19:05, Philip Levis wrote:
> I think I’d disagree with Brad on this one — we’re going to transition
> to 2.0 pretty soon, and so you’ll have to rewrite it for 2.0 anyways, so
> might as well start there.

OK, thanks, so I'll spend my copious free time™ on 2.0. It will probably
take some time to get stuff running at all before I start to think about
how to expose the functionality to applications anyway.

Florian.