<div><br>
On Thu, Jun 25, 2020 at 6:08 PM Alex Qiu <<a href="mailto:xqiu@google.com" target="_blank">xqiu@google.com</a>> wrote:<br>
> Yes, there are some restrictions in my current demo, and I'm afraid<br>
> that I may not have the bandwidth to cover it further alone. My point<br>
> is that, sometimes hardwares is designed with some unexpected<br>
> complexity on topology (EEPROM behind MUX for example).<br></div><div>
To my understanding this case is already handled.  Assign the mux to the parent FRU config file, and the eeprom behind it will be detected correctly.  With that said, this type of hardware (optional mux with an eeprom behind it) is difficult to identify automatically with no other impact, hence needing to explicitly add it to the parent board.  Can you think of any other examples of unexpected topology that aren't covered?</div><div><br>
<br>
> Having the<br>
> ability to aid the topology discovery with code, and having the<br>
> topology info available to other functionalities can help a lot. JSON<br>
> config files are having a hard time bearing these logics, and any<br>
> extra logic implemented in JSON config files requires some kind of<br>
> script parser in daemons processing them.<br></div><div>
The majority of the config parsing is also able to be done at compile time, it just isn't implemented today.  With that said, the config file parsing in practice takes up very little CPU time in the last profile I did, so it hasn't been a priority.</div><div><br>
<br>
> Based on your replies, the<br>
> concept for functionally extensions that I was asking for should be<br>
> implemented as daemons either standalone or plugged onto dbus?<br>
<br></div><div>
I'm not understanding the distinction of standalone vs plugged into dbus, but I'll hazard a guess, and say yes, the dbus interfaces to the rest of the system is (one of) the project's intended extension points.  You can either manipulate them from an existing daemon, or create an all new daemon that has exactly the behavior you want.</div><div><br>
<br>
><br>
> On "reading sensors within the BMC console", I'm actually using a<br>
> script to directly read from hwmon right now, because we are having<br>
> sensor number limit on IPMI and performance issues with IPMI and dbus.<br>
> We are still actively investigating these performance issues now to<br>
> unblock the project, but based on the current findings, I think it's<br>
> better to have this tool before the protocol layers.<br></div><div>
Have you considered opening a review with this tool to make it available to others?  I'd recommend opening a review to put it in here:<br>
<a href="https://github.com/openbmc/openbmc-tools" rel="noreferrer" target="_blank">https://github.com/openbmc/openbmc-tools</a><br>
This repo is much less formal, but gives people a place for these "might be useful to others" type scripts.  Write up a commit message with something to the effect of "I wrote this tool, this is how you use it, I find it makes platform development easier because X." and get it checked in.</div><div><br>
<br>
><br>
> On issues like uint8_t, yes, we've noted them down, but they are still<br>
> tech debts on our backlog, and dealing with the performance issue<br>
> described above remains as our priority right now.<br>
<br></div><div>
It sounds like you're swamped for time, which I can respect.  With that said, If you start by making technical improvements on small things like the above, you're much more likely to have feedback (and help) when you propose more wide sweeping changes, like your python example.<br>
If you ever get free time, and want to continue moving your proposal more toward an actionable change we can make, I'm happy to help discuss options.  To be clear, I think if you can resolve some of the technical limitations of your proposal, and put together a patchset that implements it in a language that the project can use on a majority of platforms, I think it could be a better developer experience.  We just can't remove some of the user facing features that are implemented and/or planned already.<br>
</div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Ed</div></div>