Well, I know I said I would have this a week ago, but as I dug I ended up with more and more issues. What I was hoping would be one small patch ended up with 20 patches, some sizeable.
One big thing that was wrong in the previous patch set is that you can have a single BMC behind multiple interfaces. Yes, there are systems that do this. So you may multiple interfaces pointing to a single BMC. The BMC was also named by product id and dev id. Because of this, allowing dynamic BMC information opened a whole can of worms. The BMCs is matched by either guid or product id/dev id. If you allow this information to change, then the name or matchups to interfaces may be wrong. So now that that information is dynamic, why not make guid and channel information dynamic, too? It could theoretically change, even though guid is not supposed to, it could be added in a new firmware version. I fixed the locking problem you found by using memory barriers and temporary holding places instead of locks. So as I kept finding things, I kept fixing things and it went on and on until I got to 20 patches. And getting all the locking right was a big pain. Some of these are not strictly necessary for you, they are fixes for other things I found on the way. And the conversion to guid_t probably doesn't matter to you, unless you want a correct guid reported in the BMC. -corey ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer