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

Fri Nov 10 06:59:26 UTC 2017

Am 10.11.2017 um 02:04 schrieb Chris Johns:
> On 09/11/2017 19:17, Christian Mauderer wrote:
>> Am 09.11.2017 um 09:03 schrieb 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.
>>
>> Yes, I know. Not really a solution. But please keep in mind that WiFi on
>> RTEMS is a work in progress. It can't be expected that from "no WiFi" to
>> "WiFi completely integrated" is only one step.
>>
> 
> Understood. A ticket is a good to capture any details you have and to
> acknowledge this is outstanding.
> 
>>>
>>>> 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.
>>
>> I would have expected that too. Therefore: That one shouldn't be a big
>> problem.
>>
> 
> Agreed.
> 
>>>
>>>> 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?
>>>
>>
>> I'm no FreeBSD user and I only have a rough knowledge about how things
>> are done there. From my Linux-point-of-view I would expect that there is
>> something similar to udev that does some actions as soon as a new device
>> is discovered. I just somehow expected that in case of a network device
>> this action on FreeBSD would be to look in the rc.conf whether there is
>> something to do with this device. But I can be wrong too.
>>
> 
> I suggest an old PC with a USB port and a cheap USB Wifi adaptor FreeBSD
> supports. Install FreeBSD which is easy and then hack the init scripts adding
> `set -x` where you think it is needed. I have FreeBSD on a 8G USB stick for this
> type of testing.
> 
> I would have a look but I have misplaced my mini USB wifi adaptor.
> 

I took a quick glance to find out the behaviour on FreeBSD: It supports
hot-plugging. If I for example add a

  wlans_rtwn0="wlan7"
  ifconfig_wlan7="DHCP"

to rc.conf a RTL8188 USB WiFi dongle is created as wlan7. I'll add that
pice of information to the ticket. I think further investigation is
necessary which services are involved into that. But that will have to
wait till there is time for that part.

>>>> 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.
>>
>> Like said above, I would expect rc.conf to get re-parsed for new network
>> devices. But I'm not sure about that.
>>
>> We can't follow that model exactly. As far as I know, we can have at
>> least two sources for our rc.conf: Either a string or a file. In case of
>> the string, we would have to copy that string so we can parse it later
>> again. For big configs, that might wouldn't be the best idea.
> 
> I cannot say until I understand what FreeBSD does. This needs to investigated.
> 
>>
>> A better solution could be to prepare some lists with configurations for
>> devices. These lists could then be used on demand.
>>
> 
> I do not follow what this means.
> 

I meant that we could parse the rc.conf on the first pass and then put
the relevant information (rtwn0 as wlan7) into for example a linked
list. That list can then be used in the hot-plug-events. With that, it
wouldn't be necessary to do a lot of string parsing on every device
detection.

But that is something that would have to be discussed as soon as someone
want's to start an implementation.

>>>
>>>> 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.
>>
>> Agreed. I would prefer the configuration in rc.conf too. 
> 
> Excellent.
> 
>> But again: WiFi in RTEMS is (from my point of view) still a work in progress.
> 
> Understood.
> 
>>
>>>
>>> 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.
>>>
>>
>> Good point. I'll create a ticket.
>>
> 
> Thanks
> Chris
> 

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at 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.