On Thu, 2007-06-28 at 10:06 -0600, Levi Pearson wrote:
> 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
> > TODO.
> > 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
That's awesome! How many engine threads do you have running? How many
> 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.
That seem's like a good plan. Running engine_teardown() then a
list_destroy() on all the contexts. But, as you state the previous e-
mail, if that's not working, there must be a bug. I'll take a look.
> I'll see how that works out, so maybe it won't be a time-critical
> enhancement at all.
High Performance Systems Division
Lawrence Livermore National Laboratory
Freeipmi-devel mailing list