Hello Abhishek,
On 16 April 2014 15:33, Abhishek Sharma <[email protected]> wrote: > <Abhishek> It's a typo. Please ignore the same. We had to remove those to > reduce the file size for posting on the mailing list. > I think it would be good if you could share those use cases even in text format [...] > <Abhishek> From the modularity and ownership prespective it is better to > have this functionality seperate from systemd. Besides as Systemd is an > independent upstream project used by many distros, it may be difficult to > push tizen IVI specific changes there.. > Well, most likely those aspects which are really IVI specific will not fit systemd. Otoh features like logging stats of the process lifecycle and adjusting policy are definitely not IVI specific. These are the parts I was referring to and I think it would be worth at least trying to send an RFC to the systemd mailing list. It's a small effort, but you might be surprised by a good reception. Especially if you explain why you need this feature. Typically one would develop the needed feature as patchset on top of the mainstream project and gradually have the code merged. This would enable you to have the functionality right away and over time reduce the burden of maintenance, by merging it into the upstream project. > Comment 3: > most of the higher level logic could be implemented using Murphy, > which is already present on IVI platform, afaik. > But there is no mention of Murphy and why it would not be suitable > for the job. > > <Abhishek> For Audio, video and network specific scenarios Murphy could > address these functionalities. We could also envision that HM for those > specific aspects interacts with Murphy. However, there are many other > system aspects which are outside the purview of Murphy and those could be > manged from the proposed HM when it is fully realized.. > Murphy is currently used for AV but basically what it does is to take a bunch of rules, inputs and trigger corresponding outputs. What is missing is the plugin to manage processes, but I would think that it's easier to write just this part and leverage the existing Murphy than essentially re-write what Murphy already provides. > <Abhishek> We have essentially proposed to leverage capabilities of > systemd, data logging and recovery procedures in an unified way. So > basically, it is a reuse of existing components but packaged differently > for automotive specific requirements. > >From what I understood, you are doing more than packaging. Again: I'm not saying that _everything_ should be integrated into systemd/Murphy, but some major functionality you described seem to be quite generic for CE products. <Abhishek> You might have seen our replies to other queries where we have tried to differentiate our proposal from other existing solutions. We plan to incorporate all review comments and prepare a detailed presentation and share with the team. ok, thanks If you can fit them, even as plain text, I think describing few key use cases would really help your progress, by providing real-life examples that can be used to validate ideas. --- cheers, igor
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
