[PATCH] klogd: Handle facility too when reading from /proc/kmsg

Denys Vlasenko vda.linux at googlemail.com
Sun Jan 22 00:56:39 UTC 2012


On Saturday 21 January 2012 17:40, Laurent Bercot wrote:
> >> I have no problem with anyone building something. I have a problem
> >> when someone forces this "something" on me.
> > Pitty you feel that way.  A NAK (and ignoring further requests) should be
> > sufficient.  Any "lobbying" going on in the background?
> 
>  FWIW, Denys is not the only one disliking systemd. I also fully support
> the eradication of systemd from the surface of the planet, and we are a
> small group of users feeling the same way.
> 
>  There are good, technical reasons for this. From an engineering
> standpoint, the design of systemd makes an unacceptable amount of
> newbie mistakes; it looks like it has been designed by an average
> undergraduate student. The fact that the systemd people spend so
> much time lobbying for it, and managed to get it integrated into
> mainstream GNU/Linux distributions is just scary, and reminds me
> of Microsoft practices.
>
>  Instead of spending so much energy promoting systemd, they should
> spend more energy studying software engineering and researching the
> state of the art in init systems, and produce better software.


I found a startling example by Lennart himself at
http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html:


---------------------------------------------------------------
> Le mercredi 18 mai 2011 à 16:18 +0200, Lennart Poettering a écrit : 
> > On Wed, 18.05.11 15:49, Josselin Mouette (joss debian org) wrote:
> > > I don’t have anything against requiring systemd, since it is definitely
> > > the best init system out there currently, but the Linux dependency is an
> > > absolute no-no for us. Having optional Linux-only functionalities is OK;
> > > requiring Linux is not.
> > 
> > Quite frankly, I'd like to question this. In the light of GNOME OS I
> > think we need to ask ourselves the question if we do ourselves any good
> > if we continue to support all kinds of kernels that simply cannot keep
> > up with Linux anymore.
> 
> By definition, another kernel cannot « keep up with Linux » if you
> introduce the features you need in Linux and then expect others to have
> them instantly available. In contrast, they also have features that
> Linux does not.
> 
> Frankly, BSD is doing quite well. They have ported upower and I expect
> to have a udisks port eventually. So far nothing has prevented GNOME
> from fully working on BSD, and adding an arbitrary dependency just
> because you don’t want to maintain some #ifdef’s in systemd would be a
> real loss.

It's not just some #ifdefs. It's a ton. Lemme list a couple of Linux
specific interfaces that are used in systemd, you'd have to find
replacements for:

- cgroups
- timerfd
- signalfd
- epoll
- autofs4
- inotify
- fanotify
- /proc/*/stat
- /proc/*/comm
- /proc/*/cmdline
- libudev
- POSIX mqueue as fd
- AF_UNIX/SOCK_SEQPACKET
- abstract namespace AF_UNIX
- get_current_dir_name()
- canonicalize_file_name()
- O_CLOEXEC/SOCK_CLOEXEC
- /proc/*/fd
- numerous prctl() controls, like PR_SET_NAME, PR_CAPBSET_DROP, PR_SET_PDEATHSIG, ...
- capabilities
- numerous console ioctls, like TIOCLINUX, VT_ACTIVATE, TIOCSTTY/TIOCNOTTY ...
- /sys
- /dev/urandom
- /dev/char/*, /dev/disk/by-label/*, /dev/disk/by-uuid/*
- openat() and friends
- O_DIRECTORY
- waitid()
- /sys/class/tty/console/active
- /sys/class/dmi/id
- ioprio
- various rlimits, like RTPRIO/RTTIME
- F_SETPIPE_SZ
- IP_FREEBIND
- oom score
- binfmt_misc

And this is just what I found while going through two files in
systemd.
--------------------------------------------------------------

Hilarious. He does not understand why mostly using portable
Unix idioms and interfaces is a good idea.

-- 
vda


More information about the busybox mailing list