create a new topic branch based on the genodelabs/master branch. For example,
git checkout -b issue76
2 questions:
should we target master? or staging instead? I see some evolutions between these branches (as expected) and I am wondering what would be making the merge process easier for the maintainers?
the format for branch naming (implied) is the number of the issue, since in my case I am likely going to have multiple of those, would it be ok if I add a more human-readable description, something like fix/issueXX-what_this_topic_is_about ? this would help me keep track more easily.
side note:
I have signed the GCA, (and so did Karin, working with me), we attached this onto NYCU email but some of our accounts of github/codeberg may leak our @gmail address instead, will that be ok? (Iāll add a Authored-by trailer in hope you can match them, and will try to be cautious about it though).
Also, would you suggest me to create a first topic on this discouse forum first, before starting an issue on github or codeberg to discuss? or go straight for the issue and keep the convo there?
I am hoping asking questions about the process is ok based on the last piece:
Please do not take the steps described herein too seriously. They are not carved in stone. If you have suggestions for improving them, or if you feel staggered by all those rules, please let us know.
Developments should target the main branch. We will ask for a rebase to staging if required during the review process.
Feel free to name your branches according to your gusto.
As this is the Genode Users it exists mainly for discussing user related matters. Almost all technical discussions with strong relations to the implementation happen in the issue tracker (now on Codeberg).
If youāre eager to accept this challenge, I suggest to start with porting Linux usbbt.ko to virt_linux DDE (or any other BT device driver). The user stack itself is IMO the second, more complex task.
Is there a particular reason to prefer BlueZ over BTstack?
BTStack has the smaller code footprint and operates entirely in userspace already. Of course thereās the non-commercial licensing , but if youāre fine with that it would fit seemingly genode better.
As a more general question: Are Genode-programmed drivers completely equal w.r.t. security and other features no matter what micro kernel is used beneath ?
PS: Are there similar approaches for Genode as āseL4 Device Driver Framework (sDDF)ā linux-in-vm drivers ?
As one data point, I seem to recall not all Āµ-kernels fully support IOMMU (IO Memory Management Unit) ? That might be outdated knowledge though. But a while back the recommendation was to use a Āµkernel with full IOMMU support if one was worried about out-of-bounds DMA writes by drivers. I also recall reading that Genode was one of a very few systems that was able to use IOMMU protection, though that might have changed too.
Indeed, it seems like NOVA and the sel4 microkernels support IOMMU, while the others donāt. But would be really nice to get a confirmation / at-a-glance documentation by the Genode team on this.
As far as I know base-hw also supports IOMMU (or SMMU on ARM) in the core repos/os/src/driver/platform/ have io_mmu.cc for the core, and repos/base-hw/src/core/ contains io_mmu.h
NOVA, seL4 both supports it as you mentioned (dmar.cpp for NOVA, sel4 has arch/x86/kernel/vtd.c for intel, and drivers/smmu/smmuv2.c for the SMMU part - ARM).
Fiasco.OC I couldnāt find any iommu related code, but I may have missed it
