[oi-dev] More on USB failure to automount

Gary Mills gary_mills at fastmail.fm
Sun Oct 10 19:43:04 UTC 2021


On Sun, Oct 10, 2021 at 10:33:07AM +0200, Andreas Wacknitz wrote:
>
> Hi, are there any news about this bug and its fix?

That patch didn't work.  Neither did the next dozen or so.  However, I
did learn a great deal about glib.  I know what the cause is.  I just
don't have the solution yet.

One of the causes is the nature of the EAGAIN error.  In the context
of hald and glib on OI, the read() system call within glib produces
this error when the pipe is empty, but the other end of the pipe is
still open for write.  Every subsequent read() will produce the same
error until the process at the other end actually writes something to
the pipe.  This error is converted to G_IO_STATUS_AGAIN by glib.  hald
only processes lines when the status returned by
g_io_channel_read_line() is G_IO_STATUS_NORMAL .  It ignores any
others, including G_IO_STATUS_AGAIN .

The other cause is that lines written by hald (with the write() system
call) to the pipe all end with "\n\0".  Yes, the trailing null is
written to and read back from the pipe.  However, hald does not set
the line terminator as glib expects, instead relying on glib's
automatic line ending determination.  In this case, that appears not
to work.  Instead, glib does a second read, which always sets the
status to G_IO_STATUS_AGAIN .  Once set, this status replaces any
previous status.

As you can see, hald writes lines to the pipe with write() but reads
them back with g_io_channel_read_line().  That design may be a third
cause.

I'm going to do a bit more testing with hald and glib, and then return
to what I was doing with OI.



-- 
-Gary Mills-		-refurb-		-Winnipeg, Manitoba, Canada-



More information about the oi-dev mailing list