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.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
