Re: [Freeipmi-devel] libipmiconsole questions

[Al Chu]

Hey Levi,

Thinking about this just a tad more, 

> Option #1) Create a function that returns some notification status to
> the user.
>    - Pro: Easy
>    - Con: No select/poll mechanism for anyone creating a lot of
> contexts.

I think this would be fine in the end after all.  The non-blocking case
that (I imagine) we're truly concerned about is that a user may try to
write data to the console before the SOL connection is finished
establishment.  A simple flag check prior to the write will allow us to
reject that write if we so choose.

Sound like a good way to fix this problem?

Al

On Tue, 2007-05-29 at 13:30 -0700, Al Chu wrote:
> Hi Levi,
> 
> > However, the ipmiconsole_engine_submit, which doesn't block, also 
> > doesn't set the flag to notify when the connection is established.  I
> > can't see any mechanism in /usr/local/include/ipmiconsole.h that would
> > allow me to determine when a non-blocking submit is ready to use.  Am I
> > missing something?
> 
> At the moment there isn't anything to let you know when the session has
> finished being setup using a non-blocking submission.  The belief was
> that a user would get the file descriptor immediately after submitting
> the context, and if the file descriptor was closed by the other end,
> that would inform the user that an error occurred, otherwise things were
> happy.  So I imagined something like this (which was what was done in
> ipmiconsole prior to 0.3.2):
> 
> ipmiconsole_engine_init();
> c = ipmiconsole_ctx_create();
> ipmiconsole_engine_submit(c);
> fd = ipmiconsole_ctx_fd(c);
> while (1)
> {
>   /* do select() on fd */
>   if (FD_ISSET(fd))
>   { 
>     n = read(fd);
>     if (n)
>       /* do something with the data */
>     else
>       printf("error: %s\n", ipmiconsole_ctx_strerror(...));
>   }
> }
> 
> In hindsight, you make a good point that some may want to be notified
> that a non-blocking context has finished making its connection vs.
> receiving an error.  I'm not sure of the best method though.
> 
> Option #1) Create a function that returns some notification status to
> the user.
>    - Pro: Easy
>    - Con: No select/poll mechanism for anyone creating a lot of
> contexts.
> 
> Option #2) Have a special flag/something on the file descriptor returned
> to the user indicating the connection is complete.
>    - Pro: Easy
>    - Con: Messes up semantics of what the prior file descriptor means
> 
> Option #3) Create another pipe that can return separate special status
> flags to the user
>    - Pro: Keeps semantics of all earlier code
>    - Con: more fds, ugh ..
> 
> Is having a non-blocking completion/notification mechanism something you
> think will be necessary?  I'll ping Chris Dunlap about Conman's needs
> too.  The original idea was based solely on Conman's needs, and this may
> have been a "hole" in the design we had forgotten to consider.
> 
> Al
> 
> On Tue, 2007-05-29 at 12:45 -0600, Levi Pearson wrote: 
> > I'm playing around with libipmiconsole to figure out how to use it to
> > access multiple consoles at once.  Looking at the exported API and the
> > implementation, I'm curious how non-blocking context submissions are
> > supposed to be handled.  
> > 
> > The ipmiconsole_engine_submit_block implementation adds a flag to the
> > ctx struct before submitting it telling the engine to write a piece of
> > data to the pipe as soon as it's established and then uses its own
> > select call to block until something is written to the pipe.
> > 
> > However, the ipmiconsole_engine_submit, which doesn't block, also
> > doesn't set the flag to notify when the connection is established.  I
> > can't see any mechanism in /usr/local/include/ipmiconsole.h that would
> > allow me to determine when a non-blocking submit is ready to use.  Am I
> > missing something?
> > 
> >             --Levi
> > 
> > 
> > 
> > _______________________________________________
> > Freeipmi-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/freeipmi-devel
> > 
-- 
Albert Chu
address@hidden
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory