Devel May 2024

devel@sel4.systems

10 participants
9 discussions

sel4bench grub iso
by Bengt.Lennicke＠mailbox.tu-dresden.de 20 May '24

20 May '24

Hello everyone, I am trying to create a grub iso image in order to run sel4bench on real hardware. The target architecture is x86_64 and I would prefer a grub iso because no changes to the hardware setup would be necessary then. What I did so far: I create the sel4bench images as follows mkdir sel4bench cd sel4bench repo init -u -u https://github.com/seL4/sel4bench-manifest.git repo sync mkdir build cd build ../init-build.sh -DPLATFORM=x86_64 ninja I get two elf images in the build/images directory as expected. Now in order to creat a bootable iso image i followed this guide https://www.gnu.org/software/grub/manual/grub/html_node/Making-a-GRUB-boota… Which means: mkdir -p iso/boot/grub grub-mkrescue -o grub.iso cp /path/to/kernel-x86_64-pc99 iso cp /path/to/sel4benchapp-image-x86_64-pc99 iso Then I add the grub.cfg under iso/boot/grub/grub.cfg menuentry "Load seL4 VM" --class os { multiboot /kernel-x86_64-pc99 module /sel4benchapp-image-x86_64-pc99 } There are a few lines missing from your offered grub stanza here https://docs.sel4.systems/Hardware/IA32 Mainly because I was having issues with getting it to run with them and without them I got further. Then I run grub-mkrescue -o grub.iso iso And try out the resulting iso as follows: qemu-system-x86_64 -cdrom grub.iso -nographic -enable-kvm -cpu Haswell,-vme,+pdpe1gb,+xsave,+xsaveopt,-xsavec,+fsgsbase,+invpcid,+syscall,+lm,enforce -m size=512M I get the following output: seL4 Benchmark ============== Switching to a safer, bigger stack... Setting up global fault handler... Failed to allocate object of size 140737488355328, error 1 Failed to allocate object of size 70368744177664, error 1 Failed to allocate object of size 35184372088832, error 1 Failed to allocate object of size 17592186044416, error 1 Failed to allocate object of size 8796093022208, error 1 Failed to allocate object of size 4398046511104, error 1 Failed to allocate object of size 2199023255552, error 1 Failed to allocate object of size 1099511627776, error 1 Failed to allocate object of size 549755813888, error 1 Failed to allocate object of size 274877906944, error 1 Failed to allocate object of size 137438953472, error 1 Failed to allocate object of size 68719476736, error 1 Failed to allocate object of size 34359738368, error 1 Failed to allocate object of size 17179869184, error 1 Failed to allocate object of size 8589934592, error 1 Failed to allocate object of size 4294967296, error 1 Failed to allocate object of size 2147483648, error 1 Failed to allocate object of size 1073741824, error 1 Failed to allocate object of size 536870912, error 1 Failed to allocate object of size 268435456, error 1 ipc Benchmarks ============== irquser Benchmarks ============== arch_simple_get_IOPort_cap not implemented Failed to get capability for IOPort range 0x43-0x43 PIT command failed! [Cond failed: error] Failed to init timer Benchmark failed, result 1 Register dump: rip: 0x4138a0 rsp: 0x10011640 rflags: 0x246 rax: 0x10000000 rbx: 0x10011660 rcx: 0x420c48 rdx: 0xffffffffffffffff rsi: 0x1 rdi: 0x2 rbp: 0x10011680 r8: 0x2b r9: 0x12008180c100f r10: 0x1 r11: 0x206 r12: 0x10011d88 r13: 0x10011d98 r14: 0x0 r15: 0x0 fs_base: 0x7494d0 gs_base: 0x0 [Cond failed: result == NULL] Failed to run benchmark irquser So ipc seems to run fine but irquser is not. Now I am only interested in the benchmark IPC for now. And maybe FAULT as well later. So I do not need to get irquser to run. Therefore I do the following setup again: mkdir sel4bench cd sel4bench repo init -u -u https://github.com/seL4/sel4bench-manifest.git repo sync mkdir build cd build ../init-build.sh -DPLATFORM=x86_64 and not i run ccmake . which opens a configuration screen where I can choose which benchmarks I want to include in the image. I disable everything except FASTPATH (this does not seem to be a benchmark) and IPC. I run ninja again and use the resulting images are build into an iso as stated above. Now running qemu results in this: Boot config: debug_port = 0x3f8 Boot config: disable_iommu = false Detected 1 boot module(s): module #0: start=0xa87000 end=0xd4e6a0 size=0x2c76a0 name='' Parsing GRUB physical memory map Physical Memory Region from 0 size 9fc00 type 1 Physical Memory Region from 9fc00 size 400 type 2 Physical Memory Region from f0000 size 10000 type 2 Physical Memory Region from 100000 size 1fee0000 type 1 Adding physical memory region 0x100000-0x1ffe0000 Physical Memory Region from 1ffe0000 size 20000 type 2 Physical Memory Region from feffc000 size 4000 type 2 Physical Memory Region from fffc0000 size 40000 type 2 Got VBE info in multiboot. Current video mode is 3 ACPI: RSDP paddr=0xf5b20 ACPI: RSDP vaddr=0xf5b20 ACPI: RSDT paddr=0x1ffe1550 ACPI: RSDT vaddr=0x1ffe1550 Kernel loaded to: start=0x100000 end=0xa14000 size=0x914000 entry=0x10040b ACPI: RSDT paddr=0x1ffe1550 ACPI: RSDT vaddr=0x1ffe1550 ACPI: FADT paddr=0x1ffe1404 ACPI: FADT vaddr=0x1ffe1404 ACPI: FADT flags=0x80a5 ACPI: 0 IOMMUs detected ACPI: MADT paddr=0x1ffe1478 ACPI: MADT vaddr=0x1ffe1478 ACPI: MADT apic_addr=0xfee00000 ACPI: MADT flags=0x1 ACPI: MADT_APIC apic_id=0x0 ACPI: MADT_IOAPIC ioapic_id=0 ioapic_addr=0xfec00000 gsib=0 ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0 ACPI: MADT_ISO bus=0 source=5 gsi=5 flags=0xd ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd ACPI: MADT_ISO bus=0 source=10 gsi=10 flags=0xd ACPI: MADT_ISO bus=0 source=11 gsi=11 flags=0xd ACPI: 1 CPU(s) detected ELF-loading userland images from boot modules: size=0x242000 v_entry=0x449631 v_start=0x400000 v_end=0x642000 p_start=0xd4f000 p_end=0xf91000 Moving loaded userland images to final location: from=0xd4f000 to=0xa14000 size=0x242000 Starting node #0 with APIC ID 0 Mapping kernel window is done available phys memory regions: 1 [100000..1ffe0000] reserved virt address space regions: 1 [ffffff8000100000..ffffff8000c56000] Booting all finished, dropped to user space seL4 Benchmark ============== Switching to a safer, bigger stack... Setting up global fault handler... vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 140737488355328, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 70368744177664, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 35184372088832, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 17592186044416, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 8796093022208, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 4398046511104, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 2199023255552, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 1099511627776, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 549755813888, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 274877906944, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 137438953472, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 68719476736, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 34359738368, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 17179869184, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 8589934592, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 4294967296, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 2147483648, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 1073741824, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 536870912, error 1 vka_alloc_object_at_maybe_dev@object.h:57 Failed to allocate object of size 268435456, error 1 ipc Benchmarks ============== libsel4muslcsys: Error attempting syscall 228 libsel4muslcsys: Error attempting syscall 96 JSON OUTPUT [{"Benchmark": "One way IPC microbenchmarks", "Results": [{"Function": "seL4_Call", "Direction": "client->server", "Client Prio": 254, "Server Prio": 254, "Same vspace?": true, "IPT .... All is well in the universe. Fin So the benchmark runs but now a libsel4muslcsys error is new. syscall 228 is sys_clock_gettime so I assume it is important for the benchmark and even so it is not terminating I am not sure whether the results are correct with that error. So somehow removing the other benchmarks resulted in an error in the ipc benchmark which was not there or at least not shown there when compiling with all benchmarks. When trying to find out which removal is causing the problem a variety of other problems is appearing. Do you think the musllib error is related to the missing lines in the grub.cfg? If so do you have an idea which one? Why do the different benchmarks influence each other, am I compiling it wrong? If there are information missing feel free to let me know and I will try to add them Kind regards, Bengt

1 0

17 May '24

The seL4 summit 2024 [0] will be held in Sydney, Australia, 15-17 October 2024. The seL4 summit will cover the complete seL4 ecosystem, consisting of the verified microkernel, as well as all seL4-related technology, tools, infrastructure, products, projects, and people. Tickets include: * Participation in the 3-day conference, including talks, keynotes, seL4 updates & discussions * Networking with other seL4 experts and enthusiasts * Reception and dinner Register here [1] The early bird cut-off date is 15 September 2024. Local seL4 Sydney-siders will look into organising some informal activities for Monday 14 October 2024, before the summit kicks off, for anyone who wants to join. Gernot may also organise a bush walk for the weekend before the summit. Stayed tuned for more info! [0] https://sel4.systems/Foundation/Summit/2024 [1] https://events.linuxfoundation.org/sel4-summit/ Birgit Brecknell seL4 Foundation Project Coordinator birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

Loading a large sel4test image on Odroid-C4 Fails
by Linh Pham 16 May '24

16 May '24

Hello, I am running into an issue with booting up an sel4test image on the Odroid-C4. When the calculated memory bound for the sel4test-driver's ELF is around 100MB or larger, I get an asychronous data abort like so: ELF-loader started on CPU: ARM Ltd. Cortex-A55 r1p0 paddr=[c3d2000..e068117] No DTB passed in from boot loader. Looking for DTB in CPIO archive...found at c502760. Loaded DTB from c502760. paddr=[256000..261fff] ELF-loading image 'kernel' to 0 paddr=[0..255fff] vaddr=[8000000000..8000255fff] virt_entry=8000000000 ELF-loading image 'sel4test-driver' to 262000 paddr=[262000..6cd7fff] vaddr=[400000..6e75fff] virt_entry=443090 "Error" handler, esr 0xbe000011 elr: ffffffff1a4996e4 lr : ffffffff1a497654 (reloc) elr: 000000000c3d96e4 lr : 000000000c3d7654 x0 : 0000000001ad7340 x1 : 0000000000000000 x2 : 0000000006a75348 x3 : 000000000c3dfdc0 x4 : 0000000001b494c8 x5 : 000000000c3dca50 x6 : 0000000000262000 x7 : 0000000000000001 x8 : 0000000000000008 x9 : ffffffffffffffff x10: 0000000000000000 x11: 0000000000000002 x12: 00000000f4fef9e0 x13: 0000000000000001 x14: 00000000f4fef9e0 x15: 0000000000000000 x16: 0000000020000000 x17: 0000000000c0c0c0 x18: 00000000f0f3dda0 x19: 000000000c3dfff0 x20: 0000000020000000 x21: 0000000000000002 x22: 00000000f0f769c0 x23: 0000000000000002 x24: 00000000f2ff556c x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000f0f6d380 x29: 000000000c3dfda0 Code: f94017e0 91002000 f90017e0 f94007e0 (f1001c1f) Resetting CPU ... Our sel4test image is large because we're using a static heap. Note that the relevant region from the log output is [262000..6cd7fff], the exception occurs when trying to write into memory in this range. After some investigation, writing to physical address 0x5100000 is what causes the problem. I haven't been able to find any documentation on why this physical address range can't be written to. Is this some sort of device memory region? I was able to eventually boot by changing the ELF loader to load into a much higher memory address (e.g. somewhere around 0x80000000), but I would like to have a clearer idea of the Odroid's memory layout so that I could choose an address range that is definitely safe to load the image into. Thank you, Linh

2 2

seL4 docker support for Apple Silicon
by Gerwin Klein 15 May '24

15 May '24

The seL4 development docker containers at https://github.com/seL4/seL4-CAmkES-L4v-dockerfiles now provide multi-architecture images for x86 and arm64. That means development on Apple Silicon (M1/2/3) with docker for seL4 should now work properly (including qemu) and should also be much faster than before. Intel machines should work as before. You should not need to do anything special or different to before, Docker should be pulling the correct kind of container for your architecture. This is brand new (as of today), so please check it out and report any issues you find. If you haven’t used the containers before, have a look at the README in the repository above. If you have been using them and want to make sure that the new versions are picked up: cd seL4-CAmkES-L4v-dockerfiles/ git checkout master git pull make pull_camkes_image user Enjoy! Gerwin

1 0

Re: Announcing release v0.2 of Neptune OS: a Windows NT personality for the seL4 microkernel
by Hugo V.C. 14 May '24

14 May '24

Are we talking about the same ReactOS ... ? As far I can see here: https://reactos.org/forum/ they have an active community. Try to post there. You also have this LinkedIn resource: https://www.linkedin.com/company/reactos-foundation/ Let me know if you have any problem contacting them and I'll try to help you. seL4 + ReactOS looks like a killer combination for the industry, they need to know about your work. Best, El lun, 13 may 2024 a las 15:07, Dr. Chang Liu, PhD. (<cl91tp(a)gmail.com>) escribió: > Dear Hugo, > > Thank you very much for your interest. I did try to find the ReactOS > mailing list to post this announcement in but it seems that their mailing > list has long been dead since late 2022, so I'm not sure where the main > communication channel of ReactOS development is. Perhaps you could point me > to the right place. > > Best regards, > > On Mon, May 13, 2024, 12:50 AM Hugo V.C. <skydivebcn(a)gmail.com> wrote: > >> Hats off. >> I'll test it and give my feedback. I'm very interested in your project, >> IMHO is one of the most interesting ones I have seen in years. >> >> BTW: are you in contact with ReactOS guys? Maybe would make sense to join >> efforts with them...? >> >> El dom, 12 may 2024 a las 17:40, Dr. Chang Liu, PhD. (<cl91tp(a)gmail.com>) >> escribió: >> >>> Dear seL4 community, >>> >>> I'm announcing the release of v0.2 of Neptune OS, an operating system >>> that >>> I have been developing that aims to create a Windows NT personality on >>> top >>> of the seL4 microkernel, by implementing the upper layer of the Windows >>> kernel called the NT Executive, as well as Windows kernel drivers, as >>> userspace processes under seL4. For those that remember the release of >>> v0.1 >>> two years ago and have been wondering, yes, the project is still alive. I >>> have been a bit busy with postdoc work (academia is hard!!) last year but >>> finally got a bit of free time lately to get enough work done that I >>> think >>> is interesting enough to warrant a v0.2 release. The project can be found >>> on github (https://github.com/cl91/NeptuneOS). >>> >>> The biggest feature of the v0.2 release is a (I hope) reasonably complete >>> file system stack supporting read-ahead and write-back caching, that >>> includes a FAT12/16/32 file system driver and a floppy controller driver, >>> both of which are ported over from ReactOS (but running in userspace >>> instead of kernel space). I'll explain the technical points below but you >>> can watch a short video (https://www.youtube.com/watch?v=o3FLRnkh0ic) >>> that >>> demonstrates the basic file system commands, including cd, dir, copy, >>> move, >>> del, md, and mount/umount. >>> >>> Arguably the biggest challenge for a userspace file system stack is >>> minimizing the performance penalties of the additional context switches. >>> There are radical solutions to this problem along the lines of Unikernels >>> that require linking the FS code with the applications. These solutions >>> are >>> not very practical for everyday desktop or server OSes. On traditional >>> OSes >>> there is FUSE on Linux/Unix which is often regarded as having inferior >>> performance compared to equivalent kernel-mode drivers. To some extent >>> this >>> problem is inevitable, as context switches are always more expensive than >>> function calls, no matter how much you optimize the former. However, that >>> doesn't mean we can't optimize our OS design so that the performance >>> penalties of running file systems in userspace are small enough that the >>> benefit of userspace file systems outweighs their performance cons. >>> >>> The key to this performance goal I believe is an efficient cache design. >>> Indeed, for FUSE it is possible to tune the cache parameters to >>> drastically >>> increase its performance (see [1] and the citation therein). On Neptune >>> OS >>> we cache aggressively: not only do we cache the underlying block device >>> pages, we also maintain the relationship between file regions and their >>> underlying disk regions. In other words, the primary role of the file >>> system driver is to translate an offset of a file object into an offset >>> of >>> the underlying storage device, and this relationship is cached since they >>> are not expected to change, at least for currently open files. >>> Furthermore, >>> we cache file attributes as well as the file hierarchy itself, so that >>> if a >>> process opened a file and the file system driver returned a valid handle, >>> we do not need to query the FS driver again (at least not before the >>> first >>> process closes the handle) when another process opens the same file with >>> the same attributes (because we know it exists and know about its >>> attributes). Of course, we need to be careful when things get >>> closed/deleted/moved, etc, so we need a mechanism to synchronize >>> information with the file system driver process. This is done by sending >>> messages using the seL4 IPC. >>> >>> What is amazing is the fact that despite these changes to the inner >>> workings of the NT cache manager, not to mention the fact that all >>> drivers >>> are now running in userspace, the Windows kernel driver API remains >>> largely >>> unchanged, so that it is indeed possible to port the relevant ReactOS >>> drivers to our architecture without doing too much work (I believe I >>> spent >>> three to four man-weeks worth of work porting the FAT file system >>> itself). >>> The vast majority of work is in fact removing code rather than writing >>> new >>> code, because of the simplifications of locking and other synchronization >>> issues that simply disappear when drivers run in userspace. For those who >>> are interested in knowing more about our architecture and are perhaps >>> interested in porting drivers from ReactOS, I am in the process of >>> writing >>> a book (found under the docs of the github repo) called "Neptune OS >>> Developer Guide" that explains all these things. Note this is very much a >>> work-in-progress. >>> >>> In addition to the cache manager work, in order for the file system stack >>> to function, several other system components must be implemented, most >>> notably DMA and Win32 SEH (structured exception handling). Our DMA >>> architecture supports both PCI bus mastering and the weird ISA DMA that >>> must go through the ISA DMA controller. The latter requires managing the >>> so-called "map registers" that must be shared across different ISA >>> devices. >>> Again we find that the Windows kernel API can be adapted to a seL4-based >>> userspace driver model almost straightforwardly. This is perhaps not so >>> surprising, because NT was allegedly originally designed as a microkernel >>> OS (this is inevitably an urban legend, but early NT design documents >>> refer >>> to the code beneath the NT Executive as the "microkernel", so there is >>> reason to believe). >>> >>> To summarize, what I hope is that with the design outlined above, we can >>> in >>> fact have a practical, reasonably performant userspace file system stack >>> without resorting to radical departures from traditional desktop/server >>> computing paradigms. Of course, it's ridiculous to talk about performance >>> for floppy disk controllers, so the primary goal of the next release is >>> to >>> port the ATA/AHCI hard disk drivers from ReactOS to Neptune OS, in order >>> to >>> produce a valid benchmark against equivalent kernel mode designs. Anyway, >>> if you read so far, I hope you find the work interesting (I personally >>> do!). If you have any comments, or even better if you ran the code and >>> found bugs/issues, please do open an issue in the github repo. Thank you! >>> >>> [1] >>> >>> https://medium.com/@xiaolongjiang/linux-fuse-file-system-performance-learni… >>> >>> --- >>> Dr. Chang Liu, PhD. >>> github.com/cl91/NeptuneOS >>> _______________________________________________ >>> Devel mailing list -- devel(a)sel4.systems >>> To unsubscribe send an email to devel-leave(a)sel4.systems >>> >>

1 0

seL4 developer hangout reminder
by Birgit Brecknell 13 May '24

13 May '24

Hi all A friendly reminder that the seL4 developer hangout is on again this week. Tue 14 May, 22:00 UTC. For your local date and time please see https://sel4.systems/contact/. Zoom link: https://unsw.zoom.us/j/82640784431 Birgit Brecknell seL4 Foundation Project Coordinator birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

Announcing release v0.2 of Neptune OS: a Windows NT personality for the seL4 microkernel
by Dr. Chang Liu, PhD. 13 May '24

13 May '24

Dear seL4 community, I'm announcing the release of v0.2 of Neptune OS, an operating system that I have been developing that aims to create a Windows NT personality on top of the seL4 microkernel, by implementing the upper layer of the Windows kernel called the NT Executive, as well as Windows kernel drivers, as userspace processes under seL4. For those that remember the release of v0.1 two years ago and have been wondering, yes, the project is still alive. I have been a bit busy with postdoc work (academia is hard!!) last year but finally got a bit of free time lately to get enough work done that I think is interesting enough to warrant a v0.2 release. The project can be found on github (https://github.com/cl91/NeptuneOS). The biggest feature of the v0.2 release is a (I hope) reasonably complete file system stack supporting read-ahead and write-back caching, that includes a FAT12/16/32 file system driver and a floppy controller driver, both of which are ported over from ReactOS (but running in userspace instead of kernel space). I'll explain the technical points below but you can watch a short video (https://www.youtube.com/watch?v=o3FLRnkh0ic) that demonstrates the basic file system commands, including cd, dir, copy, move, del, md, and mount/umount. Arguably the biggest challenge for a userspace file system stack is minimizing the performance penalties of the additional context switches. There are radical solutions to this problem along the lines of Unikernels that require linking the FS code with the applications. These solutions are not very practical for everyday desktop or server OSes. On traditional OSes there is FUSE on Linux/Unix which is often regarded as having inferior performance compared to equivalent kernel-mode drivers. To some extent this problem is inevitable, as context switches are always more expensive than function calls, no matter how much you optimize the former. However, that doesn't mean we can't optimize our OS design so that the performance penalties of running file systems in userspace are small enough that the benefit of userspace file systems outweighs their performance cons. The key to this performance goal I believe is an efficient cache design. Indeed, for FUSE it is possible to tune the cache parameters to drastically increase its performance (see [1] and the citation therein). On Neptune OS we cache aggressively: not only do we cache the underlying block device pages, we also maintain the relationship between file regions and their underlying disk regions. In other words, the primary role of the file system driver is to translate an offset of a file object into an offset of the underlying storage device, and this relationship is cached since they are not expected to change, at least for currently open files. Furthermore, we cache file attributes as well as the file hierarchy itself, so that if a process opened a file and the file system driver returned a valid handle, we do not need to query the FS driver again (at least not before the first process closes the handle) when another process opens the same file with the same attributes (because we know it exists and know about its attributes). Of course, we need to be careful when things get closed/deleted/moved, etc, so we need a mechanism to synchronize information with the file system driver process. This is done by sending messages using the seL4 IPC. What is amazing is the fact that despite these changes to the inner workings of the NT cache manager, not to mention the fact that all drivers are now running in userspace, the Windows kernel driver API remains largely unchanged, so that it is indeed possible to port the relevant ReactOS drivers to our architecture without doing too much work (I believe I spent three to four man-weeks worth of work porting the FAT file system itself). The vast majority of work is in fact removing code rather than writing new code, because of the simplifications of locking and other synchronization issues that simply disappear when drivers run in userspace. For those who are interested in knowing more about our architecture and are perhaps interested in porting drivers from ReactOS, I am in the process of writing a book (found under the docs of the github repo) called "Neptune OS Developer Guide" that explains all these things. Note this is very much a work-in-progress. In addition to the cache manager work, in order for the file system stack to function, several other system components must be implemented, most notably DMA and Win32 SEH (structured exception handling). Our DMA architecture supports both PCI bus mastering and the weird ISA DMA that must go through the ISA DMA controller. The latter requires managing the so-called "map registers" that must be shared across different ISA devices. Again we find that the Windows kernel API can be adapted to a seL4-based userspace driver model almost straightforwardly. This is perhaps not so surprising, because NT was allegedly originally designed as a microkernel OS (this is inevitably an urban legend, but early NT design documents refer to the code beneath the NT Executive as the "microkernel", so there is reason to believe). To summarize, what I hope is that with the design outlined above, we can in fact have a practical, reasonably performant userspace file system stack without resorting to radical departures from traditional desktop/server computing paradigms. Of course, it's ridiculous to talk about performance for floppy disk controllers, so the primary goal of the next release is to port the ATA/AHCI hard disk drivers from ReactOS to Neptune OS, in order to produce a valid benchmark against equivalent kernel mode designs. Anyway, if you read so far, I hope you find the work interesting (I personally do!). If you have any comments, or even better if you ran the code and found bugs/issues, please do open an issue in the github repo. Thank you! [1] https://medium.com/@xiaolongjiang/linux-fuse-file-system-performance-learni… --- Dr. Chang Liu, PhD. github.com/cl91/NeptuneOS

2 1

seL4 multicore boot failed on arm64
by Leonid Meyerovich 10 May '24

10 May '24

Hello, I run my seL4 application on 4 core ARMv8. Recently I have developed some more application code (I mention it because file system size is increased an I believe it may change boot time) and from time to time I observed that boot process failed (stuck after the following print) calling schedule calling activate thread kernel boot done.. CPU=1 calling schedule calling activate thread kernel boot done.. CPU=2 calling schedule calling activate thread kernel boot done.. CPU=3 Booting all finished, dropped to user space calling schedule calling activate thread kernel boot done.. CPU=0 Some time I see that only 2 CPU have been booted (like CPU1 and CPU3, or CPU2 and CPU3) Last print is the last one in init_kernel() function Thanks you, Leonid

2 3

Building seL4test 12.1.0 fails on Ubuntu 22.04 (WSL2)
by Ben McCart 09 May '24

09 May '24

I have run into the following build error when running ninja to build seL4test (following instructions at: https://docs.sel4.systems/GettingStarted#setting-up-your-machine) Here is what I get for output. Any suggestions on a work-around? (Do I have the wrong version of a python tool or library?) -- [65/263] Generating circular_includes_valid FAILED: kernel/circular_includes_valid /home/dev/seL4test/build-x86/kernel/circular_includes_valid cd /home/dev/seL4test/build-x86/kernel && /home/dev/seL4test/kernel/tools/circular_includes.py --ignore kernel_all_copy.c < kernel_all.i && touch circular_includes_valid Traceback (most recent call last): File "/home/dev/seL4test/kernel/tools/circular_includes.py", line 74, in <module> sys.exit(main(args)) File "/home/dev/seL4test/kernel/tools/circular_includes.py", line 61, in main while file_stack[-1] != header: IndexError: list index out of range [66/263] Invoking muslc build system /home/dev/seL4test/projects/musllibc/src/prng/seed48.c:6:40: warning: argument 1 of type ‘short unsigned int *’ declared as a pointer [-Warray-parameter=] 6 | unsigned short *seed48(unsigned short *s) | ~~~~~~~~~~~~~~~~^ In file included from /home/dev/seL4test/projects/musllibc/src/prng/seed48.c:1: /home/dev/seL4test/projects/musllibc/include/stdlib.h:133:25: note: previously declared as an array ‘short unsigned int[3]’ 133 | unsigned short *seed48 (unsigned short [3]); | ^~~~~~~~~~~~~~~~~~ /home/dev/seL4test/projects/musllibc/src/unistd/getcwd.c: In function ‘getcwd’: cc1: warning: function may return address of local variable [-Wreturn-local-addr] /home/dev/seL4test/projects/musllibc/src/unistd/getcwd.c:9:14: note: declared here 9 | char tmp[PATH_MAX]; | ^~~ ninja: build stopped: subcommand failed.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Devel May 2024