On 03/08/2016 15:56, Christian Mauderer wrote:
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.
I agree. This is a nice change to have.
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.
I was only asking to see if there was something we need to manage.
- 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.
Thanks.
- 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.
Great. If there is something you need in the rc.conf support please let
me know.
- 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.
Yes and it complicates the build because of symbols and this extends the
reach of what is needed into the user's build systems.
The plugin could be a solution to automate the process. But It would be
highly gcc specific.
Yes.
I think that manipulating the section names inside
the object file like suggested in the linked discussion would be a more
portable solution.
I did not pick this up when I read the thread. What is being suggested?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
