On Thu, 2007-06-28 at 08:42 -0700, Al Chu wrote:
> Hey Levi,
> Thanks for noticing this. I'm guessing that the implementation changed
> awhile back and I forgot to change the comments.
> I need to look at the code again the refresh my memory on how best to
> implement this. Looking at ipmiconsole (the tool, not the lib) it seems
> neither ipmiconsole_ctx_destroy() or ipmiconsole_engine_teardown()
> block. I actually spin waiting for ipmiconsole_ctx_destroy() to return
> a non-zero value back to me.
> I'll modify the comments for now, and add blocking equivalents into my
> Is this something that's needed soon on your end?
Well, I've got libipmiconsole hooked into the current release of conman
now, and I'm working on clean up and debugging issues now. It's worked
great in my small-scale testing so far, so we'd like to push the
FreeIPMI tools out into our system image that's being released next
Chris sounded like he wanted to do some refactoring of conman before he
tackled integrating libipmiconsole, but we wanted to see it happen ASAP.
I'll submit a patch once I'm finished cleaning up, and then Chris can
use it or not. I won't be offended if it doesn't fit his vision of where
conman is going, but it ought to at least be a relatively clean solution
to fitting libipmiconsole into the current conman structure that will be
useful until he's finished with his refactoring.
Anyway, part of the cleanup is getting the libipmiconsole stuff cleanly
torn down when conman closes down via a signal, and the way it's set up
now, all of the connection objects get destroyed sequentially via a
list_destroy, and it might be painful to sequentially spin-wait.
Though, now that I think about it, calling ipmiconsole_engine_teardown()
before the list_destroy() should ensure that all of them start
disconnecting at once, so it shouldn't be that bad.
I'll see how that works out, so maybe it won't be a time-critical
enhancement at all.
Freeipmi-devel mailing list