Devel

devel@sel4.systems

20 participants
1384 discussions

verifying concurrency
by Gergely Buday 09 Dec '15

09 Dec '15

Hi there, what should I read if I want to understand the verification of concurrent programs related to the sel4 project? I have found https://ssrg.nicta.com.au/publications/papers/Daum-phd.pdf https://ssrg.nicta.com.au/publications/papers/Daum_DSW_08.pdf http://ssrg.nicta.com.au/projects/concurrency/ Are there others? Cheers - Gergely

3 2

Reminder: Microkernel-devroom CfP deadline is on this Sunday
by Jakub Jermar 07 Dec '15

07 Dec '15

Hi folks, the CfP deadline for the Microkernel devroom at FOSDEM 2016 is due this Sunday. See the original CfP [1] for information on what to do if you would like to give a talk about some microkernel-related topic. At the same time, I would like to encourage you to submit a talk proposal. It would be shame not to let the wider microkernel community know about the latest and greatest developments in your project. Lastly, please forward this reminder to whoever you think may want to give a talk in the devroom and is not among the recipients of this message. Thanks, Jakub [1] http://trac.helenos.org/wiki/Devroom2016

1 0

haskell on sel4
by Tim Newsham 05 Dec '15

05 Dec '15

I just noticed the web page says "we have Haskell sort-of running on seL4 (thanks or friends from Galois for their help), should be released in the near future" This is great news. Are you able to share any details such as when any of this will be public, what the porting strategy was (is this similar to HalVM?), what dependencies haskell compiled code requires, if there are sel4 bindings, etc? Tim

3 4

Initial Thread physical to Virtual Mapping
by Robert VanVossen 04 Dec '15

04 Dec '15

Hello, I am attempting to integrate the Xilinx drivers, provided through their SDK, with seL4 on the Zynq7000. In the root thread, I created a virtual mapping for the SD Card peripheral, and I pass that virtual address into the driver, so that it is reading and writing to it. The controller has a built-in DMA that gets used for data transfer. I created a buffer in the root thread's virtual space to pass to the DMA, but it needs a physical address. I calculated the virtual/physical offset from the physical and virtual addresses for the application that are given by the elfloader, but that didn't seem to be the correct mapping. Is there a good way to get that mapping, either from within the application itself or from the kernel before hand? Thanks, Robbie VanVossen DornerWorks

3 2

Assigning GPIO buffer to a new process
by Karl Apsite 02 Dec '15

02 Dec '15

Ahoy there! I'm working on a Zynq 7000 - ZC702 dev board. I've setup a capability associated with the GPIO buffer, and have successfully ran a small test in the root process that could read a button's state via GPIO. The next step is to send the capability to a second process so that it can read the button's state. I'm having some trouble understanding how I should go about using the IPC calls to achieve this transfer. I'll try to give a summary of my efforts, to clear up where I am, and what I've done so far. To start: I borrowed (heavily) from the 4th tutorial that established two separate processes Main: https://github.com/seL4-projects/sel4-tutorials/blob/master/solutions/hello… App: https://github.com/seL4-projects/sel4-tutorials/blob/master/solutions/hello… I felt inclined to inform the second process about the whereabouts of the new endpoint as opposed to making an assumption as to where it was allocated. I crammed the address into the argc/argv constructs as the process starts, and it seems to be able to continue just fine. 1. Is that an OK thing to do? I understand that I shouldn't be too willing to share vital information freely between both processes, and I'm not sure if abusing argc/argv to inform the second process is appropriate here. I left the main thread in seL4_Wait(). My idea is: other processes are expected to send a message representing a command that main can respond to. Main can check the message, badge(s), and privileges as necessary, and respond with the capability if it so desires. With the capability in hand, and a tag with extracaps set to one, I was NOT able to successfully send the cap. The second process would only receive a tag with extra caps set to zero, so it must be failing somewhere along the way. I loaded the cap into the first slot using seL4_SetCap(0, my_cap) and the cap was functioning previously, so I doubt it's erroring when I send. I expect an error on the receiving end somewhere. I have NOT been able to prepare a path for a capability in the second process, and notify seL4 of the location using seL4_GetCapReceivePath(root_node, new_cap, 32). 2. How should the second process obtain a reference to its root cnode? 3. How should the second process allocate a new cnode? I think the new_process_t structure in the main process has the addresses I'm after (to obtain the root cnode at least, and maybe allow me to a new cnode?), but I don't understand the implications of informing the second process about the information in the new_process_t structure. 4. Is the new process expected to know all of that information? 5. Is there an API to establish this sort of information (along with the IPC endpoint that I had to cram into argc/argv earlier?)

2 1

seL4 2.0.0 Release Notes
by Anna Lyons 01 Dec '15

01 Dec '15

Introducing seL4 2.0.0 ====================== Version 2.0.0 introduces more consistent terminology to manual and code, as well as API and performance improvements, including to seL4's formally verified ARMv6 version. We clarified the notion of signals and notifications vs IPC, and added a new feature to the seL4 API that allows user programs to receive notifications while waiting for IPC messages. You can now also poll notification objects. Both of these changes are aimed at simplifying user-level interaction with interrupts. In addition to the new features, seL4 has become even faster than it was before, esp. in scheduling threads. The new features and performance improvements are available on all supported platforms, and are formally verified to full sel4 standards. We have also switched our release process to semantic versioning, so it's easy to tell which seL4 releases are binary-compatible, source-compatible, or will require updates to user-level code. Terminology Changes =================== IPC vs Notifications -------------------- The old terminology of "synchronous IPC" vs "asynchronous IPC" was confusing and misleading. We changed this to reflect the fact that IPC in seL4 is always synchronous and is simply referred to as "IPC", which is enabled by "endpoint" objects. The receive operation is now more appropriately called "receive". What used to be called incorrectly "asynchronous IPC" is now called Notifications, enabled by "notification" objects. Notifications are not a form of message passing, but arrays of binary semaphores, and the new terminology describes this better. The operations on them are consequently called "signal" and "wait" New Features ============ Notification binding -------------------- A notification can be bound to a thread and is referred to as the thread's bound notification object. This is a 1:1 relationship. Whenever a thread waits for an IPC on an endpoint, it will receive any signals sent to its bound notification object, with the signal flags converted into a single-word message. Threads can also explicitly wait for signals by waiting on the notification object itself. For more details, see the 2.0.0 manual Implementation improvements =========================== * introduces the bitfield scheduler: faster scheduler (Was linear in the number of runnable threads, now log n) * improved benchmarking macros: can now specify multiple benchmarking tracepoints at once added CONFIG_RELEASE_PRINTF in addition to CONFIG_DEBUG and CONFIG_RELEASE, which enables printf in a release build API Changes =========== * seL4_Recv replaces seL4_Wait on endpoints * seL4_Wait is now only used on notification objects * Async endpoint -> notification object * sync endpoint -> endpoint * seL4_Recv on an endpoint may now return signals sent to a thread's bound notification object. API Additions ============= * seL4_NotificationObject replaces deprecated seL4_AsyncEndpointObject * seL4_NotificationBits size in bits of a notification object * seL4_IRQHandler_SetNotification replaces deprecated seL4_IRQHandler_SetEndpoint * seL4_Recv replaces seL4_Wait for endpoints * seL4_Wait used on notifications * seL4_NBRecv non-blocking (polling) receive on an endpoint, which fails if there is no message waiting. Opposite of NBSend (which silently fails if there is no receiver waiting) * seL4_Poll collects any signals from a notification objects, returns zero if there are none * seL4_Signal replaces deprecated seL4_Notify * seL4_TCB_BindNotification bind a notification to a tcb * seL4_TCB_UnbindNotification unbind a notification from a tcb Deprecations ============ * seL4_AsyncEndpointObject * seL4_Notify * seL4_IRQHandler_SetEndpoint Note on Syscall names ==================== Logically there are only two operations on capabilities, send and receive, which can take opcodes specifying sup-operations. For example, the Notification operations Signal and Wait are mapped to Send and Receive, respectively. For efficiency reasons, many kernel objects use separate kernel entry points for their operations. You must not rely on either, as this can change at any time. Instead, always use the object-specific wrapper functions. User-level repositories ======================= To simply repository management we have merged many of our user level library repositories. To see the changes please compare 1.0.4.xml and 2.0.x.xml in https://github.com/seL4/seL4test-manifest Upgrade notes ============= Calls to seL4_Wait no longer return a seL4_MessageInfo_t as seL4_Wait is intended to be used on notification objects. Calls to the prior version of seL4_Wait need to be replaced with seL4_Recv. If you don't want to upgrade yet - don't worry. Both the sel4test-manifest and verification manifest repositories have manifests titled 1.0.4.xml which point to the tips of the previously released repositories before today. All library repositories have a branch called '1.0.x-compatible' which are compatible with the 1.0.4 kernel. Note that to use the new merged repositories, you must upgrade to 2.0.0. Full changelog ============== Use git log 1.0.4..2.0.0 in https://github.com/seL4/seL4 More details ============ See the 2.0.0 manual included in the release for detailed descriptions of the new features. Or ask on this mailing list! Enjoy! ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

3 3

Does seL4 support periodic thread
by ぷ风过无痕?? 27 Nov '15

27 Nov '15

Hi everyone,I have some questions about seL4's timer. I know seL4 is controlling the timer device. In the current release version, scheduling is tick-based, there's a periodic interrupt that feeds into the scheduler. I wanna know if seL4 support periodic thread. I want to implement a periodic process in Refos which is above seL4 kernel.And, if seL4 does not support periodic thread, could I modify the kernel scheduler? Does it influences formal verification? I find that Refos modifies _thread_state_t enumeration-type variables (kernel\include\object\structures.h ). Does it influences formal verification? Thank you so much!!

3 2

CAmkES-vm Configuration
by Bryan Ching 24 Nov '15

24 Nov '15

Hi, I was trying to configure the CAmkES-vm to run the vmware configuration. However, I get the following error. [apps/vm] building... /home/bryan/camkes-vm/tools/camkes/camkes.mk:125: /home/bryan/camkes-vm/build/x86/pc99/vm/camkes-gen.mk: No such file or directory [GEN] camkes-gen.mk While transforming AST: /home/bryan/camkes-vm/apps/vm/vm.camkes:4: unresolved reference to VM make[1]: *** [/home/bryan/camkes-vm/build/x86/pc99/vm/camkes-gen.mk] Error 255 make[1]: *** Deleting file `/home/bryan/camkes-vm/build/x86/pc99/vm/ camkes-gen.mk' make: *** [vm] Error 2 I have seen this error before. This time, I used the "make menuconfig" command. I go to Applications --> VMM Main Application --> Configuration. I type in "vmware" to try and configure it. When I am back on the command line, I type "make vmware_defconfig" and then "make silentoldconfig" and finally "make". Where is the camkes-gen.mk file supposed to be located? Thanks, Bryan

2 4

Destroying the Root Thread
by Robert VanVossen 20 Nov '15

20 Nov '15

Hello, I was wondering if I can safely destroy my application root thread after I have setup the capabilities and memory mappings for all of my other threads in the system? Thanks, Robbie VanVossen DornerWorks

5 8

CAmkES-vm Build Question
by Bryan Ching 17 Nov '15

17 Nov '15

Hi, I was just wondering for the CAmkES-vm, where is the Makefile to build it? Also, to clone the github repository, do I use "repo" or can I use "git clone"? Thanks, Bryan

4 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Devel