On Thu, 09.10.14 07:21, Jan Synacek (jsyna...@redhat.com) wrote: > >> > > A related thing: there's a mapping bus-error <-> errno implemented, > >> > > but it only works for the errors defined in the library itself. It > >> > > would be nice to extend this mapping to the "user" defined errors, > >> > > e.g. in core/. Would you be amenable to adding a mechianism to > >> > > register additional mappings like bus-error-mapping.gperf so that they > >> > > are used by the library? > >> > > >> > Maybe have internal versions of the conversion calls that allow > >> > passing in an additional table? > >> That is not as convenient. E.g. sd_bus_error_set > >> internally calls bus_error_name_to_errno. Currently, this always > >> returns EIO for errors unknown to the library, and then the caller > >> does it own lookup (e.g. looking at > >> transaction_add_job_and_dependencies()). > > > > What precisely are you proposing instead? > > What about "extending" usage of errno with systemd specific errors? > Something like EUNITMASKED or E<anything systemd specific>? Plus, > implementing extended version of strerror(), which would use the > standard stderror() for the standard errno?
Well, using errno-style errors is certainly handy, but let's face it, it's not particularly descriptive. Before attempting to extending it we should probably look at other options, such as adopting sd_bus_error at more places, which allows more flexible identifiers as well as descriptive strings. Also, we return these errnos in many of our public APIs. We really should never return something there that cannot be made sense of externally, since people might (and should be able to) escalate the errors unmodified up the chain, where the immediate systemd context is lost or unknown. (Also, just think what would happen if multiple libraries would extend errno that way! how confusing would that get). So, my suggestion is to either accept the limited vocabulary of errno for this case (which I don't think is such a loss here), or to go for sd_bus_error, but some entirely new concept sounds less than ideal. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel