[systemd-devel] [HEADSUP] hostnamed

Lennart Poettering lennart at poettering.net
Mon Apr 18 10:38:54 PDT 2011


Heya,

just wanted to mention that systemd git now as a tiny daemon "hostnamed"
which is started on demand via dbus, and whose purpose is exactly three
things: provide a PK authenticated way for UI tools to change the
hostname, for sending out change signals when the hostname changes and
finally to maintain a "pretty" hostname (i.e. "Lennart's PC" instead of
"lennarts-pc") and an icon for the local machine. I expect this to be
used very soonishly in Avahi, NM, Bluetooth and in th GNOME3
configuration tools.

More information on this you find here:

http://www.freedesktop.org/wiki/Software/systemd/hostnamed

All of this are pretty desktopish features. That's why it is pretty easy
to rip it out: just don't install hostnamed and its service file, and
it is gone, as if it never was added in the first place. The
configuration files for hostnamed (/etc/machine-info) are carefully
separated from the essential hostname config file /etc/hostname to make
this easy.

At this point we have collected a few components of systemd that are of
little or no use on embedded systems. To mind come here hostnamed, the
binfmt handling, the console handling or even readahead. All of these
components can be easily ripped out as they are not handled in PID 1
itself. However, you currently have to do so manualy: remove the binary
from /lib/systemd and remove the matching unit files from
/lib/systemd/system. I'd be willing to merge a patch to make these
things configurable at compile time via ./configure switches. In general
I am not a big fan of conditional compilation, but here are the rules by
which I'd be willing to merge a patch:

* They don't litter the code with #ifdefs. Littering makefiles OTOH is OK.

* Everything defaults to on (i.e. the desktop build should be the
  default)

* We only make the parts optional that make sense to be optional,
instead of support a gazillion of different options just for the sake of
having options. i.e. a good start is to make only the four components
listed above optional, and maybe very few on top of that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list