Hi, in the past few months, Sebastian has extended the RTEMS libbsd infrastructure so it technically can import/export modules from/to the Linux kernel tree.
This extension is quite delicate, because in general, the Linux kernel sources are published under GPLv2, which is definitively incompatible with the RTEMS license. But there are some modules, which are dual licensed (GPLv2 or BSD style), and for those, this extension would be useful. In fact, this extension has been created to import (and stay in sync with) the DPAA infrastructure for the FSL/NXP QorIQ device family. Background (can be skipped): ---------------------------- in the past, Sebastian has created the libbsd infrastructure to import various SW modules from FreeBSD. This allows us to use FreeBSD code for networking, USB, WLAN and a broad range of drivers in RTEMS. The infrastructure allows the RTEMS project to stay in sync with FreeBSD. This means e.g. that we can harden the WLAN/WPA2 implementation against the "KRACK" attack as soon as a patch is available for FreeBSD. Now we have a delicate libbsd extension requirement: RTEMS contains support for the FSL/NXP "QorIQ" device family, which has 24(!) processors integrated and currently forms the upper end of RTEMS multicore BSPs. This chip family has a networking subsystem "DPAA" with complex communication/routing/switching capabilities, including multiple 10GBit ethernet interfaces. Writing a networking driver for this beast is virtually impossible due to its complexity. Using/integrating NXPs DPAA framework is the only feasible way to support these interfaces. The framework is published and maintained(!) inside the linux kernel code, and it is released under a dual (GPL or BSDish) license. ---------- Now I see four ways to deal with this linux importer: A.) We can simply integrate it into RTEMS as an extension to libbsd. - Technically, it adds a tool to extend the RTEMS code basis. - But Developers, who are not so familiar with licensing issues might easily use it to integrate pure GPLv2 code, which would be a big problem for RTEMS users. B.) We can reject any code (even dual licensed) that is part of the Linux kernel. - This would be inconsistent with other dual licensed modules which are now also part of RTEMS. - In the longer term it would also let the QorIQ support become obsolete (which currently has an important function to prove the superior SMP efficiency of RTEMS). - Maybe this decision would even indicate that the RTEMS project is not capable of keeping track with bleeding edge computing challenges. (I regard this argument a bit disproportionate, but think about it anyway...) C.) We can accept selected linux kernel code (which has a proper dual license) but reject the linux importer mechanism. - This would allow us to carefully integrate interesting modules and make licensing problems less probable. - But this would lead to potential bit rot in these imported modules, a situation we overcame with the libbsd framework. D.) We can accept the linux importer and selected linux kernel code, and provide some monitoring mechanism to avoid misuse of the importer. - This needs extra effort for the monitoring (manually of automatically) - OTOH this would give us more flexibility. ------------------- Any opinions on that? Any hints or ideas how we could solve the discrepancy between flexibility requirements and legal requirements of the project? I would be happy to have this discussed here! Thomas. -- -------------------------------------------- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
