On Mon, Apr 13, 2015 at 3:04 PM, Nir Soffer <nir...@gmail.com> wrote: > On Sat, Apr 11, 2015 at 6:58 PM, David Herrmann <dh.herrm...@gmail.com> wrote: >>> A program running this tool can detect a timeout (expected) or an error >>> (unexpected), and can change the program flow based on this result. >>> >>> Without this, the only way to detect a timeout is to implement the timeout >>> in the program calling udevadm. >> >> I cannot really see a use-case here. I mean, yeah, the commit-message >> says it warns about timeouts but fails loudly on real errors. But >> again, what's the use-case? Why is a timeout not a real error? Why do >> you need to handle it differently? > > Timeout means that the value I chose may be too small, or the machine > is overloaded. The administrator may need to configure the system > differently. > > Other errors are not expected, and typically unexpected errors in an > underlying tool means getting the developer of the underlying tool > involved. > >> Anyway, if it's only about diagnostics this patch seems fine to me. > > Yes, it is mainly about diagnostics, and making it easier to debug and > support.
Wouldn't a better solution be to improve the udevadm logging? If we change the exit codes this is basically ABI. Do we really want to make such promises only for diagnostics? Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
