Am 03.08.2016 um 02:54 schrieb Chris Johns: > On 02/08/2016 21:27, Christian Mauderer wrote: >> - A basic support for the FreeBSD cdev subsystem. This subsystem uses >> devfs which I implementation based on the RTEMS IMFS. > > Is this automatically included and what can we configure and control?
A lot of drivers in BSD use the cdev subsystem to create their /dev/xyz nodes. Till now we had only a very minimalistic implementation (enough to let everything link without errors) and a lot of workarounds to somehow avoid the usage of the /dev/xyz nodes or to create them inside the driver. One such example is freebsd/sys/net/bpf.c My implementation replaces the "let me just link" version. Therefore it is automatically included like the previous version. I don't think that it would be useful to switch it off. Making it optional means that we would have to offer a selection between the old "let me just link" version and the new one. That could lead to a lot of problems with dependencies. Some drivers might would rely on the one or the other implementation. > >> - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF >> and SYSINIT_NEED_FIREWALL_PFLOG configuration macros. > > Can you please add RTEMS_BSD_CONFIG_FIREWALL_PF and > RTEMS_BSD_CONFIG_FIREWALL_PFLOG to rtems-bsd-config.h. > > This is the user interface and what I intend to document and so what we > need to maintain and keep working into the future. > I'll look into this. >> - I ported the control tool for the firewall (pfctl) to libbsd. >> >> - I added a chapter on how to use PF to libbsd.txt. An example can be >> found in the pf01 test. > > Is there support for rc.conf(5) > (https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29) in the change? > > It would be nice to support ipfilter_enable, ipfilter_rules, > ipv6_ipfilter_rules, and ipfilter_flags. I think ipfilter_program can be > silently ignored. > > I would like LibBSD's user interface to be rc.conf(5) as standard and my > hope is the support work I have done for rc.conf makes it easy to add > support. I am happy for other ways to configure to be present and the > tests tend to need this however users who depend on those interface > maybe disappointed if those interfaces change or break. > I haven't added the support. But I'll try to create a patch in the next few days. >> - The method that I used for the pfctl port slightly improves the >> approach that is currently used for most other user space tools. A basic >> guide how to port a tool using the new method can be found in the >> libbsd.txt in the chapter "Porting of user space utilities". > > This is a nice change. > >> >> Basically I made two changes to the current approach: >> >> 1. I used a new method to handle the global variables. Basically they >> are put into a linker section that is saved before the program call and >> restored afterwards. >> >> 2. Beneath that I added some wrappers to calls like open / close or >> malloc / free. These wrappers create a list of opened files and >> allocated resources. After the program main function has finished, the >> resources are closed / freed. >> >> Please note: The method described in 1. makes it necessary to pull >> function static variables out of their functions. This works but is not >> really an optimal solution. The FreeBSD people are not really happy with >> this kind of patches. Currently I'm trying to evaluate an alternative >> solution (manipulating the object files to put the variables into a >> section) in this thread: >> >> https://lists.rtems.org/pipermail/devel/2016-August/015749.html >> > > I have wondered about using libdl as a way to wrap and limit scope and > while it is a nice idea ARM needs veneers to be fully supported. I have > also wondered if a GCC plugin could be used when building these specific > files to handle the linker attributes automatically. There is a nice > Python plugin framework for GCC which may help make this easier. > I think libdl is currently only available for some platforms? So my suggested solution currently targets a wider range of plattforms without the necessity to first port libdl. The plugin could be a solution to automate the process. But It would be highly gcc specific. I think that manipulating the section names inside the object file like suggested in the linked discussion would be a more portable solution. Kind Regards Christian -- -------------------------------------------- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
