[systemd-devel] [PATCH] core: don't allow enabling if unit is masked

[Lennart Poettering]

On Thu, 09.10.14 07:21, Jan Synacek (jsynacek at 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