[PATCH 09/10] libbsd.txt: Describe current state of WLAN.

[Chris Johns]

On 09/11/2017 17:41, Christian Mauderer wrote:
> 
> currently there is still no rc.conf support. I took a look at it and
> found out that I can't do it in the scope of the project. Therefore I
> only added a note regarding this in the "known restrictions".

Hmmm.

> In FreeBSD, the creation of such devices would be handled by rc.conf
> lines like
>     wlans_rtwn0="wlan0"
>     ifconfig_wlan0="DHCP"
> 
> It wouldn't be a great problem to parse such lines in rc.conf and call a
> matching ifconfig command. 

The rc.conf API we have should be able to handle something like that or it
should be close.

> But there is a problem due to the nature of
> the rtwn0 device: It's an USB device. Due to that, it isn't there right
> from the start. Depending on quite a number of conditions it will appear
> sooner or later during the startup or - in the worst case - a user could
> plug it after a few minutes of run time.

Understood, enumeration takes time.

> 
> Please correct me if I'm wrong but as far as I know, the rc.conf support
> in RTEMS currently is only executed once during start without
> remembering any configuration for later use. The source can be either a
> file or a string.

Is rc.conf run more than once in FreeBSD? I know the `service` command uses it
to know if a service is enabled, ie onestart etc. Is there something else?

> With that in mind, I would expect that roughly the following would be
> necessary for that implementation:
> 
> - To handle dynamically added WiFi and network devices through rc.conf,
> either the complete rc.conf string or at least the information from the
> wlans_xxx and ifconfig_xxx lines has to be kept somewhere for later use.
> 
> - Some kind of handler or daemon for detecting new USB devices would be
> necessary. As far as I know, there is currently no such thing. The only
> other application with dynamic device detection that I know of is the
> media listener. But I think that is on block device level and not on the
> USB level.

I am confused about the way FreeBSD does this. I did not think rc.conf is rerun
at all. As I said it is parsed by lots of things. We should follow the same
model if that is feasible. If you could determine what FreeBSD does it would go
a long way to knowing which path is the best path to follow.

> I would have liked to add that integration to have a clean solution.

I agree on needing a clean solution but it is not clear yet what that is.

> But
> like I said, there isn't enough free budget left in that project to do
> it. I really hope that we can find some time and budget for it in the
> future.

I respect and thank you for being open about this. I view getting a suitable
solution for rc.conf is important for the project because this stuff is
complicated to get working. I have raised rc.conf before and I had hoped it was
understood we need to support it. It is crazy to require users to have some
parts in rc.conf and other parts in complex fragile custom code to make this
stack work. This has been a valid criticism of RTEMS for years and I would like
to see us address it.

Could you please determine what rc.conf work is needed and document it in a
ticket? I feel you are best to do this since you are across the code in detail.

Chris