diff options
Diffstat (limited to 'open_issues/systemd.mdwn')
| -rw-r--r-- | open_issues/systemd.mdwn | 126 |
1 files changed, 125 insertions, 1 deletions
diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn index bf8ae70a..1d774307 100644 --- a/open_issues/systemd.mdwn +++ b/open_issues/systemd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -24,3 +24,127 @@ Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)* Daniel Gollub, Stefan Seyfried, 2010-10-14. Likely there's also some other porting needed. + + +# IRC, OFTC, #debian-hurd, 2011-05-19 + + <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the + "systemd as dependency" and all the messages in it don't give me a bright + future for gnome on hurd... + <pochu> yeah, I've read the thread + <pochu> it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + <pochu> we'll see + <pinotree> you can always help me with kde on hurd, would be nice ;) + <pochu> hehe + <pinotree> pochu: well, even if the depenency is rejected, the whole «don't + give a damn about non-linux and only bless linux for the "gnome os"» is a + bit... worrying attitude + <pochu> yeah... it doesn't come from all the community though + <pochu> I'm sure some people have always thought that way + <tschwinge> Or we could get systemd going? :-) + <pochu> good luck with that :p + <guillem> tschwinge: haha!? :) + <tschwinge> That bad? + <guillem> tschwinge: if you mean by that forking indefinitely then maybe + <guillem> tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + <guillem> or even older Linux versions! + <guillem> to the point of rejecting patches, because they "clutter" the + source code... + <tschwinge> Well, then let's ``just'' implement the Linux interfaces. :-) + <guillem> tschwinge: then you'll be always playing catch up + <guillem> tschwinge: for example several of the Linux-only things upstream + makes heavy use of, are pretty recent Linux-only additions to the kernel, + but equivalents have been present on FreeBSD for years + <tschwinge> Yeah. I'm half-serious, half-joking. + <tschwinge> I haven't looked at the systemd code at all. + <guillem> + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + <guillem> some are just glibc extensions though + <guillem> and some are IMO optional and should be conditionalized, but... + <guillem> pochu: I don't think that attitude is that old, there was a time + when Linux was not used widely, or even that functional, I think it has + been taking strength since the Linux Plumbers Cartel started :) + <guillem> as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + <guillem> tschwinge: in any case, these "recent" events are "pissing me + off" to the point of having considered several times implementing + portable replacements for some of those Utopia projects, the problem as + always is time though :) + <guillem> tschwinge: and the issue is not only with systemd, upstart's + upstream has the same approach to portability, if you want to port it, + you'll have to maintain a fork + <pochu> let's create our own init system, make it better than anyone else, + and when people start switching to it, let's start using hurd-only APIs + :) + <tschwinge> We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. <http://directory.fsf.org/project/DMD/> + <guillem> the real problem with that attitude is not the lack of care for + portabilty, the real problem is that these people are pushing for their + stuff all over the stack, and most of the time deprecating their own + stuff after a while when they have rewritten it from scratch, leaving the + burden of maintaining the old stuff to the other ports + <guillem> witness HAL, ConsoleKit, etc etc + <guillem> (anyway enough ranting I guess :) + <tschwinge> Yeah, it's true, though. + <pochu> agreed + + +# Requires Interfaces + +In the thread starting +[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a +[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been +posted that contains the following list (no claim for completeness) of +interfaces that are used in (two source code files of) systemd: + + * cgroups + * namespaces + * selinux + * autofs4 + * capabilities + * udev + * oom score adjust + * RLIMIT_RTTIME + * RLIMIT_RTPRIO + * ionice + * SCHED_RESET_ON_FORK + * /proc/$PID/stat + * fanotify + * inotify + * TIOCVHANGUP + * IP_TRANSPORT + * audit + * F_SETPIPE_SZ + * CLONE_xxx + * BTRFS_IOC_DEFRAG + * PR_SET_NAME + * PR_CAPBSET_DROP + * PR_SET_PDEATHSIG + * PR_GET_SECUREBITS + * /proc/$PID/comm + * /proc/$PID/cmdline + * /proc/cmdline + * numerous GNU APIs like asprintf + * SOCK_CLOEXEC, O_CLOEXEC + * /proc/$PID/fd + * /dev/tty0 + * TIOCLINUX + * VT_ACTIVATE + * TIOCNXCL + * KDSKBMODE + * /dev/random + * /dev/char/ + * openat() and friends + * /proc/$PID/root + * waitid() + * /dev/disk/by-label/ + * /dev/disk/by-uuid/ + * /sys/class/tty/console/active + * /sys/class/dmi/id + * /proc/$PID/cgroup + * \033[3J + * /dev/rtc + * settimeofday() and its semantics |