Patrik, thanks, I do understand the plug-ins are loaded at startup, this is what makes the code a bit confusing. It loads the plug-in, then adds the newly loaded policy to all *existing* session. As I see it, there is no way to have a session at that point in time, unless for some reason the plug-in is reloaded at runtime--which it is now. Therefore this code appears to be a NOP.
The other point was that on one hand it seems like the code supports loading more than one plug-in because, for example, the code keeps a sorted list of policies based on priority. But on the other hand, the assignment of the policy to a newly created session just grabs the highest priority policy--no probing or other logic. It was difficult to see the intent in the code: single or multiple plug-in support. The intent here was part of what I was looking for and I think Daniel answered that; only one plug-in is really supported. Also to clarify, the intent was not to swap an existing assigned plug-in during runtime, I agree this would be difficult to manage. The point I was trying to make was that more than one plug-in gives greater flexibility over the sessions. Currently if I want to add more policy logic to a session, and keep the session-policy-local policy plug-in functionality I have one option; modify the session-policy-local to add more filtering--or whatever the case may be. If more than one plug-in were supported you could create a new plug-in that support other features and possibly add features/functionality easier. It seems like the policy plug-ins should operate differently than the other plug-ins in that you want a "chain" of policies for a session, not just a single plug-in. One policy plug-in may not cover all that is needed for the system, unlike a technology where WiFi HW uses the WiFi plug-in. What seem likely is that the create/destroy calls all policy plug-ins each time. This allows the plug-in to decide whether it should do something or not. Tysen On Thu, Nov 7, 2013 at 5:20 AM, Daniel Wagner <[email protected]> wrote: > On 11/07/2013 08:44 AM, Patrik Flykt wrote: > >> >> Hi, >> >> On Wed, 2013-11-06 at 14:47 -0500, Tysen Moore wrote: >> >> The code seems to load the plug-in and during the session policy plug-in >>> init it registers by calling connman_session_policy_register. The >>> routine >>> then stores the policy in a list based on the priority, then calls >>> probe_policy. probe_policy then cycles through all sessions and assigns >>> this session policy to any session without a policy reference. I have a >>> couple concerns: >>> 1. This occurs only at startup--unless these session policies can >>> register >>> themselves outside of startup. Therefore, there will never be any >>> sessions. Therefore the code is a NOP, and is not called anywhere else. >>> 2. If registration could happen later the second plug-in would never get >>> assigned. >>> >> >> Policy - and other - plugins are all loaded at startup, not during run >> time. Was this the answer you were looking for? >> >> The other issue is that there never seems to be a probe-like callback >>> even >>> when a session is created. The session is assigned the highest priority >>> session policy no matter what. Typically systems I've used would probe >>> all >>> plug-ins in priority order and stop if the plug-in returns that it >>> handled >>> the probe. This would allow the plug-in to be specialized for more >>> targeted use and allow for more than one supported plug-in. Currently >>> the >>> highest priority wins. >>> >> >> In that case there seems to be a probe() session policy module function >> missing. Please add one, other APIs like network and device have probe() >> functionality. >> > > The probing is shortcuted because I didn't see any real reason to support > more than one policy plugin at runtime. > > It gets really fast tricky if something changes when a session already is > in use. What should happen if policy plugin A decides it is not applicable? > Should policy plugin B now be asked for a configuration? My assumption was > that one plugin is enough when the system is running. If you need to have > your own plugin, it should handle all sessions, not part of them, that > was my thinking. > > cheers, > daniel > > > > _______________________________________________ > connman mailing list > [email protected] > https://lists.connman.net/mailman/listinfo/connman > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
