On Tue, Apr 21, 2015 at 12:41 AM, Tom Gundersen <t...@jklm.no> wrote: > 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?
Improving logging is orthogonal, as it does allow the program to change the flow based the exit code. Adding a timeout exit code may break code using undocumented behavior, since the return code is not documented. Nir _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
