[Buildroot] [PATCH 1/1] Updated systemd to version 197

[Buildroot] [PATCH 1/1] Updated systemd to version 197

[Olivier Schonken]

Made changes to config to allow for building systemd integrated udev
rather than building udev and systemd separately.

Created the versions of the existing patches for the new systemd version

The page-size issue for which there was a patch fixed in the new version,
thus deleted.

Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
---
 package/systemd/Config.in                    |    6 +--
 package/systemd/systemd-fix-getty-unit.patch |   46 ++++++++++--------
 package/systemd/systemd-fix-page-size.patch  |   43 -----------------
 package/systemd/systemd-uclibc-fix.patch     |   64 +++++++++++++++-----------
 package/systemd/systemd.mk                   |   20 ++++++--
 system/Config.in                             |   18 ++++++--
 6 files changed, 97 insertions(+), 100 deletions(-)
 delete mode 100644 package/systemd/systemd-fix-page-size.patch

diff --git a/package/systemd/Config.in b/package/systemd/Config.in
index 86ab2cf..2df4a3b 100644
--- a/package/systemd/Config.in
+++ b/package/systemd/Config.in
@@ -1,6 +1,6 @@
 config BR2_PACKAGE_SYSTEMD
 	bool "systemd"
-	depends on BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
+	depends on BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV
 	depends on BR2_INET_IPV6
 	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
 	depends on BR2_USE_MMU # dbus
@@ -18,6 +18,6 @@ config BR2_PACKAGE_SYSTEMD
 
 	  http://freedesktop.org/wiki/Software/systemd
 
-comment "systemd not available (depends on /dev management with udev and ipv6 support, and thread support in toolchain)"
-	depends on !BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV || !BR2_INET_IPV6 || \\
+comment "systemd not available (depends on ipv6 support, and thread support in toolchain)"
+	depends on !BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV || !BR2_INET_IPV6 || \\
 		!BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/systemd/systemd-fix-getty-unit.patch b/package/systemd/systemd-fix-getty-unit.patch
index 6df54b1..9b7f719 100644
--- a/package/systemd/systemd-fix-getty-unit.patch
+++ b/package/systemd/systemd-fix-getty-unit.patch
@@ -1,34 +1,40 @@
-Prefer getty to agetty in console setup systemd units
+From e3b4ecc1ad838fea5b9796e9bdc08dcfd9e9c03e Mon Sep 17 00:00:00 2001
+From: Olivier Schonken <olivier.schonken@gmail.com>
+Date: Sun, 3 Mar 2013 13:35:03 +0200
+Subject: Prefer getty to agetty in console setup systemd units
 
-Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
 ---
  units/getty at .service.m4        |    2 +-
  units/serial-getty at .service.m4 |    2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
-Index: systemd-37/units/getty at .service.m4
-===================================================================
---- systemd-37.orig/units/getty at .service.m4
-+++ systemd-37/units/getty at .service.m4
-@@ -32,7 +32,7 @@
+diff --git a/units/getty at .service.m4 b/units/getty at .service.m4
+index 083eb97..60d5808 100644
+--- a/units/getty at .service.m4
++++ b/units/getty at .service.m4
+@@ -27,7 +27,7 @@ ConditionPathExists=/dev/tty0
  
  [Service]
- Environment=TERM=linux
--ExecStart=-/sbin/agetty %I 38400
-+ExecStart=-/sbin/getty -L %I 115200 vt100
+ # the VT is cleared by TTYVTDisallocate
+-ExecStart=-/sbin/agetty --noclear %I 38400 linux
++ExecStart=-/sbin/agetty -L %I 115200 vt100
+ Type=idle
  Restart=always
  RestartSec=0
- UtmpIdentifier=%I
-Index: systemd-37/units/serial-getty at .service.m4
-===================================================================
---- systemd-37.orig/units/serial-getty at .service.m4
-+++ systemd-37/units/serial-getty at .service.m4
-@@ -32,7 +32,7 @@
+diff --git a/units/serial-getty at .service.m4 b/units/serial-getty at .service.m4
+index 60d7737..3c5bdda 100644
+--- a/units/serial-getty at .service.m4
++++ b/units/serial-getty at .service.m4
+@@ -22,7 +22,7 @@ Before=getty.target
+ IgnoreOnIsolate=yes
  
  [Service]
- Environment=TERM=vt100
--ExecStart=-/sbin/agetty -s %I 115200,38400,9600
-+ExecStart=-/sbin/getty -L %I 115200 vt100
+-ExecStart=-/sbin/agetty -s %I 115200,38400,9600 vt102
++ExecStart=-/sbin/agetty -L %I 115200 vt100
+ Type=idle
  Restart=always
  RestartSec=0
- UtmpIdentifier=%I
+-- 
+1.7.10.4
+
diff --git a/package/systemd/systemd-fix-page-size.patch b/package/systemd/systemd-fix-page-size.patch
deleted file mode 100644
index 241ceb8..0000000
--- a/package/systemd/systemd-fix-page-size.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-commit 7264278fbbdc1dc6c30fedc902d1337594aa6ff6
-Author: Lennart Poettering <lennart@poettering.net>
-Date:   Wed Mar 21 23:47:44 2012 +0100
-
-    journal: PAGE_SIZE is not known on ppc and other archs
-    
-    Let's use NAME_MAX, as suggested by Dan Walsh
-
-diff --git a/src/journal/journald.c b/src/journal/journald.c
-index d27cb60..87390bd 100644
---- a/src/journal/journald.c
-+++ b/src/journal/journald.c
-@@ -29,7 +29,6 @@
- #include <sys/ioctl.h>
- #include <linux/sockios.h>
- #include <sys/statvfs.h>
--#include <sys/user.h>
- 
- #include <systemd/sd-journal.h>
- #include <systemd/sd-login.h>
-@@ -2149,10 +2148,20 @@ static int process_event(Server *s, struct epoll_event *ev) {
-                         size_t label_len = 0;
-                         union {
-                                 struct cmsghdr cmsghdr;
-+
-+                                /* We use NAME_MAX space for the
-+                                 * SELinux label here. The kernel
-+                                 * currently enforces no limit, but
-+                                 * according to suggestions from the
-+                                 * SELinux people this will change and
-+                                 * it will probably be identical to
-+                                 * NAME_MAX. For now we use that, but
-+                                 * this should be updated one day when
-+                                 * the final limit is known.*/
-                                 uint8_t buf[CMSG_SPACE(sizeof(struct ucred)) +
-                                             CMSG_SPACE(sizeof(struct timeval)) +
--                                            CMSG_SPACE(sizeof(int)) +
--                                            CMSG_SPACE(PAGE_SIZE)]; /* selinux label */
-+                                            CMSG_SPACE(sizeof(int)) + /* fd */
-+                                            CMSG_SPACE(NAME_MAX)]; /* selinux label */
-                         } control;
-                         ssize_t n;
-                         int v;
diff --git a/package/systemd/systemd-uclibc-fix.patch b/package/systemd/systemd-uclibc-fix.patch
index 9a20845..2f689dc 100644
--- a/package/systemd/systemd-uclibc-fix.patch
+++ b/package/systemd/systemd-uclibc-fix.patch
@@ -1,6 +1,9 @@
-[PATCH] fix build with uClibc
-
-Based on OE patch from Khem Raj:
+From 19a0d4a9007c6505320a1f413e7fbb14c765ad1f Mon Sep 17 00:00:00 2001
+From: Olivier Schonken <olivier.schonken@gmail.com>
+Date: Sun, 3 Mar 2013 13:43:19 +0200
+Subject: Based on previous buildroot patch to systemd - including
+ previous commit message "Based on OE patch from Khem
+ Raj:
 
 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/systemd/systemd/paper-over-mkostemp.patch
 
@@ -8,16 +11,38 @@ But extended to also cover execvpe (OE carries a patch adding execvpe
 support to uClibc).
 
 Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
+"
+
+Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
 ---
  src/journal/journal-file.c |    2 ++
- src/macro.h                |   15 +++++++++++++++
+ src/shared/macro.h         |   15 +++++++++++++++
  2 files changed, 17 insertions(+)
 
-Index: systemd-44/src/macro.h
-===================================================================
---- systemd-44.orig/src/macro.h
-+++ systemd-44/src/macro.h
-@@ -28,6 +28,21 @@
+diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
+index 13fc8ed..84daf75 100644
+--- a/src/journal/journal-file.c
++++ b/src/journal/journal-file.c
+@@ -318,12 +318,14 @@ static int journal_file_allocate(JournalFile *f, uint64_t offset, uint64_t size)
+                 }
+         }
+ 
++#ifndef __UCLIBC__
+         /* Note that the glibc fallocate() fallback is very
+            inefficient, hence we try to minimize the allocation area
+            as we can. */
+         r = posix_fallocate(f->fd, old_size, new_size - old_size);
+         if (r != 0)
+                 return -r;
++#endif
+ 
+         if (fstat(f->fd, &f->last_stat) < 0)
+                 return -errno;
+diff --git a/src/shared/macro.h b/src/shared/macro.h
+index 29d9139..1919c61 100644
+--- a/src/shared/macro.h
++++ b/src/shared/macro.h
+@@ -27,6 +27,21 @@
  #include <sys/uio.h>
  #include <inttypes.h>
  
@@ -39,21 +64,6 @@ Index: systemd-44/src/macro.h
  #define _printf_attr_(a,b) __attribute__ ((format (printf, a, b)))
  #define _sentinel_ __attribute__ ((sentinel))
  #define _noreturn_ __attribute__((noreturn))
-Index: systemd-44/src/journal/journal-file.c
-===================================================================
---- systemd-44.orig/src/journal/journal-file.c
-+++ systemd-44/src/journal/journal-file.c
-@@ -229,11 +229,13 @@
-                 }
-         }
- 
-+#ifndef __UCLIBC__
-         /* Note that the glibc fallocate() fallback is very
-            inefficient, hence we try to minimize the allocation area
-            as we can. */
-         if (posix_fallocate(f->fd, old_size, new_size - old_size) < 0)
-                 return -errno;
-+#endif
- 
-         if (fstat(f->fd, &f->last_stat) < 0)
-                 return -errno;
+-- 
+1.7.10.4
+
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index e85355f..a04b15e 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -3,14 +3,13 @@
 # systemd
 #
 #############################################################
-SYSTEMD_VERSION = 44
+SYSTEMD_VERSION = 197
 SYSTEMD_SITE = http://www.freedesktop.org/software/systemd/
 SYSTEMD_SOURCE = systemd-$(SYSTEMD_VERSION).tar.xz
 SYSTEMD_INSTALL_STAGING = YES
 SYSTEMD_DEPENDENCIES = \
 	host-intltool \
 	libcap \
-	udev \
 	dbus
 
 # Make sure that systemd will always be built after busybox so that we have
@@ -34,7 +33,22 @@ SYSTEMD_CONF_OPT += \
 	--with-udevrulesdir=/etc/udev/rules.d \
 	--with-sysvinit-path=/etc/init.d/ \
 	--without-sysvrcd-path \
-	--enable-split-usr
+	--enable-split-usr 
+
+ifeq ($(BR2_PACKAGE_LIBGLIB2),y)
+	SYSTEMD_CONF_OPT += --enable-gudev
+	SYSTEMD_DEPENDENCIES += libglib2
+else
+	SYSTEMD_CONF_OPT += --disable-gudev 
+endif
+
+ifeq ($(BR2_PACKAGE_PYTHON),y)
+	SYSTEMD_CONF_OPT += --enable-acl
+	SYSTEMD_DEPENDENCIES += python
+else
+	SYSTEMD_CONF_OPT += --without-python
+endif
+        
 
 ifeq ($(BR2_PACKAGE_ACL),y)
 	SYSTEMD_CONF_OPT += --enable-acl
diff --git a/system/Config.in b/system/Config.in
index 1e4fff3..4834298 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -86,7 +86,17 @@ config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
 	depends on BR2_USE_WCHAR # udev
 	select BR2_PACKAGE_UDEV
 
-comment "udev requires a toolchain with LARGEFILE + WCHAR support"
+config BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV
+	bool "Dynamic using sytemd integrated udev"
+	depends on BR2_LARGEFILE # udev
+	depends on BR2_USE_WCHAR # udev
+	depends on BR2_INET_IPV6
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_USE_MMU
+	select BR2_PACKAGE_DBUS
+	select BR2_PACKAGE_SYSTEMD
+
+comment "systemd udev requires a toolchain with LARGEFILE + WCHAR support"
 	depends on !(BR2_LARGEFILE && BR2_USE_WCHAR)
 
 endchoice
@@ -108,16 +118,16 @@ config BR2_INIT_SYSTEMD
 	depends on BR2_LARGEFILE
 	depends on BR2_USE_WCHAR
 	depends on BR2_INET_IPV6
-	depends on BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
+	depends on BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on BR2_USE_MMU
 	select BR2_PACKAGE_DBUS
 	select BR2_PACKAGE_SYSTEMD
 
-comment 'systemd requires largefile, wchar, IPv6, threads and udev support'
+comment 'systemd requires largefile, wchar, IPv6 and threads support'
 	depends on !(BR2_LARGEFILE && BR2_USE_WCHAR && \
 		     BR2_INET_IPV6 && BR2_TOOLCHAIN_HAS_THREADS && \
-		     BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV)
+                     BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV)
 
 config BR2_INIT_NONE
 	bool "None"
-- 
1.7.10.4

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Hello,

On Sun,  3 Mar 2013 14:09:34 +0200, Olivier Schonken wrote:
> Made changes to config to allow for building systemd integrated udev
> rather than building udev and systemd separately.
> 
> Created the versions of the existing patches for the new systemd version
> 
> The page-size issue for which there was a patch fixed in the new version,
> thus deleted.
> 
> Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>

Thanks for this proposal. Indeed something needs to be done about
systemd/udev handling in Buildroot. We used to package udev and systemd
separately so that we could build a system that uses udev but not
systemd. With udev now being part of systemd, building a udev-based
system that uses some other init system than systemd has become a lot
more complicated.

Here is what is in the report of the last Buildroot Developers meeting
regarding this topic:

   """
   What to do with systemd/udev/eudev: we try to use the udev from
   systemd without systemd. Exactly how we don't know yet... There's a
   risk that udev becomes unusable without systemd, but Leonard
   Poettering promised this would not happen. After a quick look, it
   turns out that you always end up building systemd, which requires
   dbus, even if you need only udev. So it makes the systemd source
   tarball a bit unpractical to build a system that uses udev only, and
   doesn't need systemd. Probably an indication that we should have a
   look at eudev? How would this interact with the systemd selection?
   What about incompatibilities between udev and eudev? 
   """

Note that we said "There's a risk that udev becomes unusable without
systemd, but Leonard Poettering promised this would not happen." In
fact we were mis-informed, see the mail from Lennart at
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html.
He says:

   """
   (Yes, udev on non-systemd systems is in our eyes a dead end, in case
   you haven't noticed it yet. I am looking forward to the day when we
   can drop that support entirely.)
   """

So in fact building udev only without systemd doesn't seem like a good
idea moving forward. Therefore, I see two options:

 (1) Follow the upstream decision, and simply make udev available only
     if the init system is systemd. Unlike some other distributions, we
     never had the the desire of fighting against upstream. If someone
     is dissatisfied with decisions made by upstream projects, then
     that someone should go upstream and fix the problem here.

     This is the solution I would personally prefer. If some were using
     udev for some reason and mdev doesn't work for them, then we can
     probably help make mdev better where needed.

 (2) Package eudev and use it for non-systemd systems, and use the
     built-in udev for systemd systems. There is of course the problem
     that udev is not stand-alone: it provides a library, and there are
     some uncertainties on whether the libudev library will remain
     source-compatible between eudev and system's udev.

Thoughts?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Kevin Chadwick]

> So in fact building udev only without systemd doesn't seem like a good
> idea moving forward. Therefore, I see two options:
> 
>  (1) Follow the upstream decision, and simply make udev available only
>      if the init system is systemd. Unlike some other distributions, we
>      never had the the desire of fighting against upstream. If someone
>      is dissatisfied with decisions made by upstream projects, then
>      that someone should go upstream and fix the problem here.
> 
>      This is the solution I would personally prefer. If some were using
>      udev for some reason and mdev doesn't work for them, then we can
>      probably help make mdev better where needed.
> 
>  (2) Package eudev and use it for non-systemd systems, and use the
>      built-in udev for systemd systems. There is of course the problem
>      that udev is not stand-alone: it provides a library, and there are
>      some uncertainties on whether the libudev library will remain
>      source-compatible between eudev and system's udev.

Not saying this is the way to go at all as I haven't got stuck into mdev
yet but thought I may as well air another option which Gentoo was
following due to broken boot for seperate /usr without initramfs, which
is to stay at the udev version 17? (I think before the 192?
amalgamation or inheritance by an ignoramus) until the time that eudev
is said to be ready for production.

The eudev list may be a good place to enquire about any potential
kernel incompatibilities of staying at an older udev version and
when eudev may be ready without getting loads of agro, lies or mis
understanding thrown at you.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

[Buildroot] What to do about systemd/udev/eudev?

[Lionel Orry]

Another note, Funtoo Linux (a gentoo derivative) team is experimenting
with usage of mdev as a complete udev replacement for the whole
distro. It seems to work and tries to prove the scalability of mdev
which sounds promising. Here are some files resulting from these
attempts:

- mdev from busybox configured for funtoo (1 tiny patch and simple
configuration in the ebuild):
https://github.com/slashbeast/foo-overlay/tree/master/sys-fs/mdev-bb
- repository for notes and mdev config/init scripts (may be worth a
look at mdev.conf and mdev.init):
https://github.com/slashbeast/mdev-like-a-boss

What I wanna say, is that it *may* sound reasonable to strongly
suggest people to stick with mdev as much as they can.

Cheers
Lionel

On Mon, Mar 4, 2013 at 11:16 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> So in fact building udev only without systemd doesn't seem like a good
>> idea moving forward. Therefore, I see two options:
>>
>>  (1) Follow the upstream decision, and simply make udev available only
>>      if the init system is systemd. Unlike some other distributions, we
>>      never had the the desire of fighting against upstream. If someone
>>      is dissatisfied with decisions made by upstream projects, then
>>      that someone should go upstream and fix the problem here.
>>
>>      This is the solution I would personally prefer. If some were using
>>      udev for some reason and mdev doesn't work for them, then we can
>>      probably help make mdev better where needed.
>>
>>  (2) Package eudev and use it for non-systemd systems, and use the
>>      built-in udev for systemd systems. There is of course the problem
>>      that udev is not stand-alone: it provides a library, and there are
>>      some uncertainties on whether the libudev library will remain
>>      source-compatible between eudev and system's udev.
>
> Not saying this is the way to go at all as I haven't got stuck into mdev
> yet but thought I may as well air another option which Gentoo was
> following due to broken boot for seperate /usr without initramfs, which
> is to stay at the udev version 17? (I think before the 192?
> amalgamation or inheritance by an ignoramus) until the time that eudev
> is said to be ready for production.
>
> The eudev list may be a good place to enquire about any potential
> kernel incompatibilities of staying at an older udev version and
> when eudev may be ready without getting loads of agro, lies or mis
> understanding thrown at you.
>
> --
> _______________________________________________________________________
>
> 'Write programs that do one thing and do it well. Write programs to work
> together. Write programs to handle text streams, because that is a
> universal interface'
>
> (Doug McIlroy)
> _______________________________________________________________________
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] What to do about systemd/udev/eudev?

[Stefan Fröberg]

4.3.2013 12:53, Lionel Orry kirjoitti:
> Another note, Funtoo Linux (a gentoo derivative) team is experimenting
> with usage of mdev as a complete udev replacement for the whole
> distro. It seems to work and tries to prove the scalability of mdev
> which sounds promising. Here are some files resulting from these
> attempts:
>
> - mdev from busybox configured for funtoo (1 tiny patch and simple
> configuration in the ebuild):
> https://github.com/slashbeast/foo-overlay/tree/master/sys-fs/mdev-bb
> - repository for notes and mdev config/init scripts (may be worth a
> look at mdev.conf and mdev.init):
> https://github.com/slashbeast/mdev-like-a-boss
>
> What I wanna say, is that it *may* sound reasonable to strongly
> suggest people to stick with mdev as much as they can.
>
> Cheers
> Lionel

Yes, I for one can confirm that if you don't need anything else than to
populate /dev with nodes and maybe few
symlinks then mdev is perfectly fine.

I have run buildroot xorg with mdev without any problems.

*But* ... (and this is a big but) I have not tested how it reacts to
kernel events after boot when you *plug/unplug* devices and if mdev
is capable of *running programs/scripts when some event happens*.

If Funtoo can make it work and make it also work seamlessly with all the
other crazy stuff (network-manager, and some other
gnome stuff) then I will kick out udev from my system in a nanosecond :-)

Regards
Stefan

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Stefan Fr?berg,

On Mon, 04 Mar 2013 20:12:29 +0200, Stefan Fr?berg wrote:

> *But* ... (and this is a big but) I have not tested how it reacts to
> kernel events after boot when you *plug/unplug* devices and if mdev
> is capable of *running programs/scripts when some event happens*.

mdev is capable of running programs/scripts when some event happens,
even after boot time. I've already used this capability to notify an
application when a USB input device is added/removed from the system,
or to trigger a system upgrade when a USB key is inserted.

However, if an application relies on libudev to get notifications of
devices appearing/disappearing, or other services, then of course, it
cannot work with mdev.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Stefan Fröberg]

4.3.2013 20:21, Thomas Petazzoni kirjoitti:
> Dear Stefan Fr?berg,
>
> On Mon, 04 Mar 2013 20:12:29 +0200, Stefan Fr?berg wrote:
>
>> *But* ... (and this is a big but) I have not tested how it reacts to
>> kernel events after boot when you *plug/unplug* devices and if mdev
>> is capable of *running programs/scripts when some event happens*.
> mdev is capable of running programs/scripts when some event happens,
> even after boot time. I've already used this capability to notify an
> application when a USB input device is added/removed from the system,
> or to trigger a system upgrade when a USB key is inserted.

It is? Oh good ! :-)

> However, if an application relies on libudev to get notifications of
> devices appearing/disappearing, or other services, then of course, it
> cannot work with mdev.

Damn... That would mean that network-manager and some other stuff would
need patchin then to
get completely rid of udev...
Real pity.

> Best regards,
>
> Thomas

Regards
Stefan

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Stefan Fr?berg,

On Mon, 04 Mar 2013 20:25:45 +0200, Stefan Fr?berg wrote:

> >> *But* ... (and this is a big but) I have not tested how it reacts to
> >> kernel events after boot when you *plug/unplug* devices and if mdev
> >> is capable of *running programs/scripts when some event happens*.
> > mdev is capable of running programs/scripts when some event happens,
> > even after boot time. I've already used this capability to notify an
> > application when a USB input device is added/removed from the system,
> > or to trigger a system upgrade when a USB key is inserted.
> 
> It is? Oh good ! :-)

See http://git.busybox.net/busybox/tree/examples/mdev.conf#n17.

> > However, if an application relies on libudev to get notifications of
> > devices appearing/disappearing, or other services, then of course, it
> > cannot work with mdev.
> 
> Damn... That would mean that network-manager and some other stuff would
> need patchin then to
> get completely rid of udev...
> Real pity.

Things like bluez, udisks, pulseaudio, X.org, etc. depend on libudev to
get notification when devices are added/removed.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Stefan Fröberg]

4.3.2013 20:30, Thomas Petazzoni kirjoitti:
> Dear Stefan Fr?berg,
>
> On Mon, 04 Mar 2013 20:25:45 +0200, Stefan Fr?berg wrote:
>
>>>> *But* ... (and this is a big but) I have not tested how it reacts to
>>>> kernel events after boot when you *plug/unplug* devices and if mdev
>>>> is capable of *running programs/scripts when some event happens*.
>>> mdev is capable of running programs/scripts when some event happens,
>>> even after boot time. I've already used this capability to notify an
>>> application when a USB input device is added/removed from the system,
>>> or to trigger a system upgrade when a USB key is inserted.
>> It is? Oh good ! :-)
> See http://git.busybox.net/busybox/tree/examples/mdev.conf#n17.
>
>>> However, if an application relies on libudev to get notifications of
>>> devices appearing/disappearing, or other services, then of course, it
>>> cannot work with mdev.
>> Damn... That would mean that network-manager and some other stuff would
>> need patchin then to
>> get completely rid of udev...
>> Real pity.
> Things like bluez, udisks, pulseaudio, X.org, etc. depend on libudev to
> get notification when devices are added/removed.
>
> Best regards,
>
> Thomas

Hmmm.....

Would it make sense to rip libudev out from latest systemd and make it
as a separate package ?
Just for satisfying dependency need for those packages ?

Could it even work without full systemd/udev stuff ???

Regards
Stefan

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Stefan Fr?berg,

On Tue, 05 Mar 2013 20:08:20 +0200, Stefan Fr?berg wrote:

> Would it make sense to rip libudev out from latest systemd and make it
> as a separate package ?
> Just for satisfying dependency need for those packages ?

libudev on its own doesn't make any sense, it needs to communicate with
udev somehow, I believe.

And anyway, in Buildroot, we don't want to derive from upstream, so we
clearly don't want to rip some part of an upstream package and make it
a new upstream package.

If someone is not happy with upstream, then start a new upstream
project, or fix the upstream project directly. It doesn't make sense to
fix upstream at Buildroot's level.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Rob Landley]

On 03/04/2013 12:21:56 PM, Thomas Petazzoni wrote:
> However, if an application relies on libudev to get notifications of
> devices appearing/disappearing, or other services, then of course, it
> cannot work with mdev.

Notifications are pretty straightforward. Should be possible for mdev  
to poke something simple and a shim library to provide the right  
interface...

Rob

[Buildroot] What to do about systemd/udev/eudev?

[Charles Krinke]

As a user working on an AM3517 project with buildroot, I am having
trouble seeing anything wrong with the existing implementation of
mdev. We have 802.11 and USB disks that are plugged in and removed and
the mdev subsystem seems to be working fine.

Having other alternatives is nice, but I hope we do not remove the
existing mdev which appears to work fine in embedded systems.

Charles

On 3/5/13, Rob Landley <rob@landley.net> wrote:
> On 03/04/2013 12:21:56 PM, Thomas Petazzoni wrote:
>> However, if an application relies on libudev to get notifications of
>> devices appearing/disappearing, or other services, then of course, it
>> cannot work with mdev.
>
> Notifications are pretty straightforward. Should be possible for mdev
> to poke something simple and a shim library to provide the right
> interface...
>
> Rob
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
Charles Krinke

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Charles Krinke,

On Tue, 5 Mar 2013 07:04:45 -0800, Charles Krinke wrote:
> As a user working on an AM3517 project with buildroot, I am having
> trouble seeing anything wrong with the existing implementation of
> mdev. We have 802.11 and USB disks that are plugged in and removed and
> the mdev subsystem seems to be working fine.
> 
> Having other alternatives is nice, but I hope we do not remove the
> existing mdev which appears to work fine in embedded systems.

There has never been any plan to remove mdev. We are talking about
possibility removing udev if systemd is not chosen as the init system.
That's all.

mdev will stay here, for sure.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Rob Landley]

On 03/05/2013 09:04:45 AM, Charles Krinke wrote:
> As a user working on an AM3517 project with buildroot, I am having
> trouble seeing anything wrong with the existing implementation of
> mdev. We have 802.11 and USB disks that are plugged in and removed and
> the mdev subsystem seems to be working fine.
> 
> Having other alternatives is nice, but I hope we do not remove the
> existing mdev which appears to work fine in embedded systems.
> 
> Charles

The existing mdev does work great. (solar at gentoo and myself designed  
it, Denys has extended it quite a bit since then.) This would be an  
extension for those other packages.

(It may be posible to just call some notify program and not modify mdev  
at all.)

Rob

> On 3/5/13, Rob Landley <rob@landley.net> wrote:
> > On 03/04/2013 12:21:56 PM, Thomas Petazzoni wrote:
> >> However, if an application relies on libudev to get notifications  
> of
> >> devices appearing/disappearing, or other services, then of course,  
> it
> >> cannot work with mdev.
> >
> > Notifications are pretty straightforward. Should be possible for  
> mdev
> > to poke something simple and a shim library to provide the right
> > interface...
> >
> > Rob
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
> 
> 
> --
> Charles Krinke
> 

[Buildroot] What to do about systemd/udev/eudev?

[Baruch Siach]

Hi Stefan,

On Mon, Mar 04, 2013 at 08:12:29PM +0200, Stefan Fr?berg wrote:
> 4.3.2013 12:53, Lionel Orry kirjoitti:
> > Another note, Funtoo Linux (a gentoo derivative) team is experimenting
> > with usage of mdev as a complete udev replacement for the whole
> > distro. It seems to work and tries to prove the scalability of mdev
> > which sounds promising. Here are some files resulting from these
> > attempts:
> >
> > - mdev from busybox configured for funtoo (1 tiny patch and simple
> > configuration in the ebuild):
> > https://github.com/slashbeast/foo-overlay/tree/master/sys-fs/mdev-bb
> > - repository for notes and mdev config/init scripts (may be worth a
> > look at mdev.conf and mdev.init):
> > https://github.com/slashbeast/mdev-like-a-boss
> >
> > What I wanna say, is that it *may* sound reasonable to strongly
> > suggest people to stick with mdev as much as they can.
> 
> Yes, I for one can confirm that if you don't need anything else than to
> populate /dev with nodes and maybe few
> symlinks then mdev is perfectly fine.
> 
> I have run buildroot xorg with mdev without any problems.
> 
> *But* ... (and this is a big but) I have not tested how it reacts to
> kernel events after boot when you *plug/unplug* devices and if mdev
> is capable of *running programs/scripts when some event happens*.
> 
> If Funtoo can make it work and make it also work seamlessly with all the
> other crazy stuff (network-manager, and some other
> gnome stuff) then I will kick out udev from my system in a nanosecond :-)

Of course it does. Quoting docs/mdev.txt from Busybox source:

Here's a typical code snippet from the init script:
[0] mount -t proc proc /proc
[1] mount -t sysfs sysfs /sys
[2] echo /sbin/mdev > /proc/sys/kernel/hotplug
[3] mdev -s

End of quote.

The only trouble is that the hotplug interface is racy. Events are not 
guaranteed to be processed at the same order they were generated. udev listens 
to events over netlink which guarantees sequential processing.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] What to do about systemd/udev/eudev?

[Stefan Fröberg]

Hi Baruch!

4.3.2013 20:37, Baruch Siach kirjoitti:
> Hi Stefan,
>
> On Mon, Mar 04, 2013 at 08:12:29PM +0200, Stefan Fr?berg wrote:
>> 4.3.2013 12:53, Lionel Orry kirjoitti:
>>> Another note, Funtoo Linux (a gentoo derivative) team is experimenting
>>> with usage of mdev as a complete udev replacement for the whole
>>> distro. It seems to work and tries to prove the scalability of mdev
>>> which sounds promising. Here are some files resulting from these
>>> attempts:
>>>
>>> - mdev from busybox configured for funtoo (1 tiny patch and simple
>>> configuration in the ebuild):
>>> https://github.com/slashbeast/foo-overlay/tree/master/sys-fs/mdev-bb
>>> - repository for notes and mdev config/init scripts (may be worth a
>>> look at mdev.conf and mdev.init):
>>> https://github.com/slashbeast/mdev-like-a-boss
>>>
>>> What I wanna say, is that it *may* sound reasonable to strongly
>>> suggest people to stick with mdev as much as they can.
>> Yes, I for one can confirm that if you don't need anything else than to
>> populate /dev with nodes and maybe few
>> symlinks then mdev is perfectly fine.
>>
>> I have run buildroot xorg with mdev without any problems.
>>
>> *But* ... (and this is a big but) I have not tested how it reacts to
>> kernel events after boot when you *plug/unplug* devices and if mdev
>> is capable of *running programs/scripts when some event happens*.
>>
>> If Funtoo can make it work and make it also work seamlessly with all the
>> other crazy stuff (network-manager, and some other
>> gnome stuff) then I will kick out udev from my system in a nanosecond :-)
> Of course it does. Quoting docs/mdev.txt from Busybox source:
>
> Here's a typical code snippet from the init script:
> [0] mount -t proc proc /proc
> [1] mount -t sysfs sysfs /sys
> [2] echo /sbin/mdev > /proc/sys/kernel/hotplug
> [3] mdev -s
>
> End of quote.

Yeah, I have something similar in my custom init.

> The only trouble is that the hotplug interface is racy. Events are not 
> guaranteed to be processed at the same order they were generated. udev listens 
> to events over netlink which guarantees sequential processing.
>
> baruch
>

Hmmm... that makes me little worried...

Anyway, how I feel this situation is that official udev is going to do
even more some crazy stuff in the future.
(read also some angry post from Linus about how they handle their
development but that's irrelevant now)

Currently udev:
- requires /usr to be mounted before it starts
- systemd init system to rule them all (altought Arnout said that  it is
still optional???)
- dbus (why the heck would I want/need dbus if im just making
rescue/repair initramfs to boot system straight to shell ?)
- other ?

So IMHO, buildroot should definetely have plan B that will have some
other alternative device handling than udev.
Be it eudev, mdev with steroids(Funtoo) or whatever....

Just my 2 cents

Regards
Stefan

[Buildroot] What to do about systemd/udev/eudev?

[Peter Korsgaard]

>>>>> "Stefan" == Stefan Fr?berg <stefan.froberg@petroprogram.com> writes:

Hi,

 Stefan> Currently udev:
 Stefan> - requires /usr to be mounted before it starts
 Stefan> - systemd init system to rule them all (altought Arnout said that  it is
 Stefan> still optional???)
 Stefan> - dbus (why the heck would I want/need dbus if im just making
 Stefan> rescue/repair initramfs to boot system straight to shell ?)
 Stefan> - other ?

 Stefan> So IMHO, buildroot should definetely have plan B that will have some
 Stefan> other alternative device handling than udev.
 Stefan> Be it eudev, mdev with steroids(Funtoo) or whatever....

Well, we do: static /dev, devtmpfs and mdev. For a rescue initramfs
devtmpfs is probably the best option.

-- 
Bye, Peter Korsgaard

[Buildroot] What to do about systemd/udev/eudev?

[Rob Landley]

On 03/04/2013 12:37:29 PM, Baruch Siach wrote:
> Hi Stefan,
> 
> On Mon, Mar 04, 2013 at 08:12:29PM +0200, Stefan Fr?berg wrote:
> > 4.3.2013 12:53, Lionel Orry kirjoitti:
> > > Another note, Funtoo Linux (a gentoo derivative) team is  
> experimenting
> > > with usage of mdev as a complete udev replacement for the whole
> > > distro. It seems to work and tries to prove the scalability of  
> mdev
> > > which sounds promising. Here are some files resulting from these
> > > attempts:
> > >
> > > - mdev from busybox configured for funtoo (1 tiny patch and simple
> > > configuration in the ebuild):
> > >  
> https://github.com/slashbeast/foo-overlay/tree/master/sys-fs/mdev-bb
> > > - repository for notes and mdev config/init scripts (may be worth  
> a
> > > look at mdev.conf and mdev.init):
> > > https://github.com/slashbeast/mdev-like-a-boss
> > >
> > > What I wanna say, is that it *may* sound reasonable to strongly
> > > suggest people to stick with mdev as much as they can.
> >
> > Yes, I for one can confirm that if you don't need anything else  
> than to
> > populate /dev with nodes and maybe few
> > symlinks then mdev is perfectly fine.
> >
> > I have run buildroot xorg with mdev without any problems.
> >
> > *But* ... (and this is a big but) I have not tested how it reacts to
> > kernel events after boot when you *plug/unplug* devices and if mdev
> > is capable of *running programs/scripts when some event happens*.
> >
> > If Funtoo can make it work and make it also work seamlessly with  
> all the
> > other crazy stuff (network-manager, and some other
> > gnome stuff) then I will kick out udev from my system in a  
> nanosecond :-)
> 
> Of course it does. Quoting docs/mdev.txt from Busybox source:
> 
> Here's a typical code snippet from the init script:
> [0] mount -t proc proc /proc
> [1] mount -t sysfs sysfs /sys
> [2] echo /sbin/mdev > /proc/sys/kernel/hotplug
> [3] mdev -s
> 
> End of quote.
> 
> The only trouble is that the hotplug interface is racy. Events are not
> guaranteed to be processed at the same order they were generated.  
> udev listens
> to events over netlink which guarantees sequential processing.

Which is why mdev added /dev/mdev.seq which is described in the same  
mdev.txt file you just quoted from in the "SEQUENCING" section.

(It turns out most embedded systems don't actually need it, but it's  
there if you just can't sleep otherwise...)

Rob

[Buildroot] What to do about systemd/udev/eudev?

[Arnout Vandecappelle]

On 04/03/13 11:16, Kevin Chadwick wrote:
> Not saying this is the way to go at all as I haven't got stuck into mdev
> yet but thought I may as well air another option which Gentoo was
> following due to broken boot for seperate /usr without initramfs, which
> is to stay at the udev version 17? (I think before the 192?
> amalgamation or inheritance by an ignoramus) until the time that eudev
> is said to be ready for production.

  And this is exactly what Olivier Schonken's patch does, right? For 
systemd init systems, systemd's udev is used; for other init systems, the 
old udev 17 is used.

  As to compatibility of the udev library users: we can make them depend 
on BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV if they really require 
the new udev. It's of course a pity that some simple package like 
libatasmart requires a specific init system to be installed, but that's 
what you get when you enter Leonard Poettering's cathedral...

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 05 Mar 2013 07:40:56 +0100, Arnout Vandecappelle wrote:

>   And this is exactly what Olivier Schonken's patch does, right? For 
> systemd init systems, systemd's udev is used; for other init systems, the 
> old udev 17 is used.

udev 17 ? I guess you mean 182, right?

Sure that's what Olivier Schonken's patch does. But how compatible are
the libudev from the modern udev bundled with systemd, and the old udev?

Also, Olivier's patch doesn't update all the packages that depend on
udev so that they can either depend on the old udev, or systemd.

That's why I started this thread, to decide where we want to go, and
then implement the relevant patches. Without knowing this direction, it
was impossible to review Olivier's patch properly.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Arnout Vandecappelle]

On 03/05/13 19:55, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Tue, 05 Mar 2013 07:40:56 +0100, Arnout Vandecappelle wrote:
>
>>    And this is exactly what Olivier Schonken's patch does, right? For
>> systemd init systems, systemd's udev is used; for other init systems, the
>> old udev 17 is used.
>
> udev 17 ? I guess you mean 182, right?
>
> Sure that's what Olivier Schonken's patch does. But how compatible are
> the libudev from the modern udev bundled with systemd, and the old udev?
>
> Also, Olivier's patch doesn't update all the packages that depend on
> udev so that they can either depend on the old udev, or systemd.

  Yes, that's what Olivier's patch does: packages that depend on udev 
will use the old udev, not the systemd udev.

  Hm, just now I realized that that means that you get two udevs when 
using systemd... OK, so this is not really the way to go :-(

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 06 Mar 2013 08:52:36 +0100, Arnout Vandecappelle wrote:
> > Also, Olivier's patch doesn't update all the packages that depend on
> > udev so that they can either depend on the old udev, or systemd.
> 
>   Yes, that's what Olivier's patch does: packages that depend on udev 
> will use the old udev, not the systemd udev.
> 
>   Hm, just now I realized that that means that you get two udevs when 
> using systemd...

Yeah, yes this is what I meant by "Olivier's patch doesn't update all
the packages that depend on udev so that they can either depend on the
old udev, or systemd."

> OK, so this is not really the way to go :-(

Well, it might be the way to go, but it needs a bit more work.

We can make a udev-virtual package, or whatever the name, that will
depend on the old udev or systemd.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Arnout Vandecappelle]

On 03/06/13 09:24, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Wed, 06 Mar 2013 08:52:36 +0100, Arnout Vandecappelle wrote:
>>> Also, Olivier's patch doesn't update all the packages that depend on
>>> udev so that they can either depend on the old udev, or systemd.
>>
>>    Yes, that's what Olivier's patch does: packages that depend on udev
>> will use the old udev, not the systemd udev.
>>
>>    Hm, just now I realized that that means that you get two udevs when
>> using systemd...
>
> Yeah, yes this is what I meant by "Olivier's patch doesn't update all
> the packages that depend on udev so that they can either depend on the
> old udev, or systemd."
>
>> OK, so this is not really the way to go :-(
>
> Well, it might be the way to go, but it needs a bit more work.
>
> We can make a udev-virtual package, or whatever the name, that will
> depend on the old udev or systemd.

  But I'm a bit afraid to assume that a package can work with either... 
When someone introduces a package or does a version bump, they'll 
typically test it with one udev, either the legacy one or the new one. If 
the two start to diverge, it would have to be tested with both scenarios.

  With other virtual packages (jpeg, lua, ...), the projects make sure 
that there is compatibility. In the case of udev, it is the intention not 
to stay compatible... And the incompatibility will often be run-time 
(dbus bindings, for instance).

  So I guess the only real way forward is to replace udev with eudev. 
Then the virtual package concept is feasible.


  For the time being, however, I would say that all the current users of 
udev should depend on !BR2_PACKAGE_SYSTEMD.


  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] What to do about systemd/udev/eudev?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> So in fact building udev only without systemd doesn't seem like
 Thomas> a good idea moving forward. Therefore, I see two options:

 Thomas>  (1) Follow the upstream decision, and simply make udev available only
 Thomas>      if the init system is systemd. Unlike some other distributions, we
 Thomas>      never had the the desire of fighting against upstream. If someone
 Thomas>      is dissatisfied with decisions made by upstream projects, then
 Thomas>      that someone should go upstream and fix the problem here.

 Thomas>      This is the solution I would personally prefer. If some were using
 Thomas>      udev for some reason and mdev doesn't work for them, then we can
 Thomas>      probably help make mdev better where needed.

 Thomas>  (2) Package eudev and use it for non-systemd systems, and use the
 Thomas>      built-in udev for systemd systems. There is of course the problem
 Thomas>      that udev is not stand-alone: it provides a library, and there are
 Thomas>      some uncertainties on whether the libudev library will remain
 Thomas>      source-compatible between eudev and system's udev.

 Thomas> Thoughts?

I think option (1) is the best as well.

-- 
Bye, Peter Korsgaard

[Buildroot] What to do about systemd/udev/eudev?

[Kevin Chadwick]

> Hi,
> 
>  Thomas> So in fact building udev only without systemd doesn't seem like
>  Thomas> a good idea moving forward. Therefore, I see two options:  
> 
>  Thomas>  (1) Follow the upstream decision, and simply make udev available only
>  Thomas>      if the init system is systemd. Unlike some other distributions, we
>  Thomas>      never had the the desire of fighting against upstream. If someone
>  Thomas>      is dissatisfied with decisions made by upstream projects, then
>  Thomas>      that someone should go upstream and fix the problem here.  
> 
>  Thomas>      This is the solution I would personally prefer. If some were using
>  Thomas>      udev for some reason and mdev doesn't work for them, then we can
>  Thomas>      probably help make mdev better where needed.  
> 
>  Thomas>  (2) Package eudev and use it for non-systemd systems, and use the
>  Thomas>      built-in udev for systemd systems. There is of course the problem
>  Thomas>      that udev is not stand-alone: it provides a library, and there are
>  Thomas>      some uncertainties on whether the libudev library will remain
>  Thomas>      source-compatible between eudev and system's udev.  
> 
>  Thomas> Thoughts?  
> 
> I think option (1) is the best as well.

It's worth bearing in mind however that in the long run and if eudev is
still around then I would expect (2) to be by far the best option for
their reduced dependencies, older kernel support and just general
all round sane and considerate decision making.

It's been a few weeks since I checked, is eudev considered stable yet.
When it is I'd say (2) definately.

Why not both. I don't believe there is too much difference? and eudev
is tracking udev but less so the other way around I believe.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Kevin Chadwick,

On Mon, 4 Mar 2013 19:52:09 +0000, Kevin Chadwick wrote:

> It's worth bearing in mind however that in the long run and if eudev is
> still around then I would expect (2) to be by far the best option for
> their reduced dependencies, older kernel support and just general
> all round sane and considerate decision making.

We already have support for static /dev, devtmpfs or mdev, and none of
those options require *any* dependency beyond some basic kernel options
and Busybox. So for anyone looking for a lightweight solution, we
already have plenty of choices.

> It's been a few weeks since I checked, is eudev considered stable yet.
> When it is I'd say (2) definately.
> 
> Why not both. I don't believe there is too much difference? and eudev
> is tracking udev but less so the other way around I believe.

If someone contributes sane patches that implement both systemd-udev
and eudev, then we will of course review them and consider them.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Attila Kinali]

On Sun, 3 Mar 2013 19:54:36 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> So in fact building udev only without systemd doesn't seem like a good
> idea moving forward. Therefore, I see two options:
> 
>  (1) Follow the upstream decision, and simply make udev available only
>      if the init system is systemd. Unlike some other distributions, we
>      never had the the desire of fighting against upstream. If someone
>      is dissatisfied with decisions made by upstream projects, then
>      that someone should go upstream and fix the problem here.
> 
>  (2) Package eudev and use it for non-systemd systems, and use the
>      built-in udev for systemd systems. There is of course the problem
>      that udev is not stand-alone: it provides a library, and there are
>      some uncertainties on whether the libudev library will remain
>      source-compatible between eudev and system's udev.

How about
  (3) Wait a couple of months to see where this whole udev mess goes to.

eudev is still pretty young and got started on the wrong foot (see the
the very poor presentation at FOSDEM). How Lennart and Kai are treating
non-systemd users is pretty much nazi like, IMHO and shows a great lack
of understanding how diverse the linux ecosystem is. Not only do we have
a lot of people who want a slim system that is easy to debug, there are
also enough people who need to squeeze out every kB they can get. And
these are left out by the current systemd development, because it doesn't
fit into the vision of Lennart and Kai. 

As you know, this lead to a great unhappiness among many people who care
about a clean OS environment. And many people were talking about taking
udev out of systemds death grip before eudev happend. And i imagine that
a few other people will try too in the next months.

So, to come back to the original issue, i would say just freeze the current
version and wait a couple of months until it either becomes clear what will
happen or incompatibilites force you to upgrade.


			Attila Kinali


-- 
The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
		-- unknown

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Attila Kinali,

On Mon, 4 Mar 2013 20:47:31 +0100, Attila Kinali wrote:

> How about
>   (3) Wait a couple of months to see where this whole udev mess goes to.
> 
> eudev is still pretty young and got started on the wrong foot (see the
> the very poor presentation at FOSDEM). How Lennart and Kai are treating
> non-systemd users is pretty much nazi like, IMHO and shows a great lack
> of understanding how diverse the linux ecosystem is. Not only do we have
> a lot of people who want a slim system that is easy to debug, there are
> also enough people who need to squeeze out every kB they can get. And
> these are left out by the current systemd development, because it doesn't
> fit into the vision of Lennart and Kai. 

Why the heck would people caring about every KB use udev in the first
place? Once again, we already have static /dev, devtmpfs and mdev
support, and those are *way* more lightweight than udev.

> So, to come back to the original issue, i would say just freeze the current
> version and wait a couple of months until it either becomes clear what will
> happen or incompatibilites force you to upgrade.

Our udev version is 182, released March 2012, almost a year ago.
Our systemd version is 44, released March 2012, almost a year ago.

I think we've already waited 12 months. Isn't that enough?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Attila Kinali]

On Mon, 4 Mar 2013 21:17:43 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Why the heck would people caring about every KB use udev in the first
> place? Once again, we already have static /dev, devtmpfs and mdev
> support, and those are *way* more lightweight than udev.

Ok, i might have exagerated. But still, systemd is a lot more heavyweight
than standard sysV init. Not to talk about the added complexity that
has very little benefit, especialy for embedded systems.
 
> > So, to come back to the original issue, i would say just freeze the current
> > version and wait a couple of months until it either becomes clear what will
> > happen or incompatibilites force you to upgrade.
> 
> Our udev version is 182, released March 2012, almost a year ago.
> Our systemd version is 44, released March 2012, almost a year ago.
> 
> I think we've already waited 12 months. Isn't that enough?

Uhmm.. oh..kay... 

I don't know, 1 year is a damn long time in opensource. And yes,
I agree that there should be an update soonish. But forcing people
to either use an old Buildroot release or to swallow systemd isn't
a very nice prospect either. 

All of that being said, I'm not a developer, so please regard this
as only my opinion as a mere user. I'm not trying to push the decision
in any way or other.

			Attila Kinali

-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
		-- Tirin, The Dispossessed, U. Le Guin

[Buildroot] What to do about systemd/udev/eudev?

[Thomas Petazzoni]

Dear Attila Kinali,

On Tue, 5 Mar 2013 10:53:15 +0100, Attila Kinali wrote:

> > Why the heck would people caring about every KB use udev in the first
> > place? Once again, we already have static /dev, devtmpfs and mdev
> > support, and those are *way* more lightweight than udev.
> 
> Ok, i might have exagerated. But still, systemd is a lot more heavyweight
> than standard sysV init. Not to talk about the added complexity that
> has very little benefit, especialy for embedded systems.

Indeed, but where have you read that we will force people to use
systemd?

Busybox init will remain the default init system, like it has always
been in Buildroot. SysV init will remain an option (so I don't really
understand what it really provides in terms of useful features of
Busybox init, but that's a different question).

Only people who *really* want to use udev and nothing else would have
to use systemd.

> > > So, to come back to the original issue, i would say just freeze the current
> > > version and wait a couple of months until it either becomes clear what will
> > > happen or incompatibilites force you to upgrade.
> > 
> > Our udev version is 182, released March 2012, almost a year ago.
> > Our systemd version is 44, released March 2012, almost a year ago.
> > 
> > I think we've already waited 12 months. Isn't that enough?
> 
> Uhmm.. oh..kay... 
> 
> I don't know, 1 year is a damn long time in opensource. And yes,
> I agree that there should be an update soonish. But forcing people
> to either use an old Buildroot release or to swallow systemd isn't
> a very nice prospect either. 

Where the heck have you read that we will force people to use systemd.

We currently support three init systems:

 * Busybox init
 * SysV init
 * systemd

And four /dev management methods:

 * static
 * devtmpfs only
 * devtmpfs + mdev
 * devtmpfs + udev

The *ONLY* change we're talking about here is to change the four /dev
management methods to:

 * static
 * devtmpfs only
 * devtmpfs + mdev
 * devtmpfs + udev, depends on init system == systemd

So besides the people who would want to use udev, all the other
options/combinations would still be available. You will still be able
to do Busybox init + static, or SysV init + devtmpfs, or whatever
combination, *EXCEPT* udev without systemd.

Why is it that as soon as systemd starts being discussed, people have
the feeling that the entire world is blowing up?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] What to do about systemd/udev/eudev?

[Stefan Fröberg]

[snip]
>
> Why is it that as soon as systemd starts being discussed, people have
> the feeling that the entire world is blowing up?
>
> Best regards,
>
> Thomas

Eh, maybe it's because some of us have invested time to make "perfect"
custom init for their systems and now
systemd developers are saying: "no, you can't use our latest udev with
your perfectly working init system anymore.
so use systemd or screw you"

Of course people will get upset when forced to change their working
systems at the upstreams whims.

But anyway, personally Im more than happy with mdev and happy that
buildroot continues to offers so many *choices*, unlike others....

Regards
Stefan

[Buildroot] [PATCH 1/1] Updated systemd to version 197

[Stefan Fröberg]

3.3.2013 14:09, Olivier Schonken kirjoitti:
> Made changes to config to allow for building systemd integrated udev
> rather than building udev and systemd separately.
>
> Created the versions of the existing patches for the new systemd version
>
> The page-size issue for which there was a patch fixed in the new version,
> thus deleted.
>
> Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
> ---
>  package/systemd/Config.in                    |    6 +--
>  package/systemd/systemd-fix-getty-unit.patch |   46 ++++++++++--------
>  package/systemd/systemd-fix-page-size.patch  |   43 -----------------
>  package/systemd/systemd-uclibc-fix.patch     |   64 +++++++++++++++-----------
>  package/systemd/systemd.mk                   |   20 ++++++--
>  system/Config.in                             |   18 ++++++--
>  6 files changed, 97 insertions(+), 100 deletions(-)
>  delete mode 100644 package/systemd/systemd-fix-page-size.patch
>
> diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> index 86ab2cf..2df4a3b 100644
> --- a/package/systemd/Config.in
> +++ b/package/systemd/Config.in
> @@ -1,6 +1,6 @@
>  config BR2_PACKAGE_SYSTEMD
>  	bool "systemd"
> -	depends on BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
> +	depends on BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV
>  	depends on BR2_INET_IPV6
>  	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus
>  	depends on BR2_USE_MMU # dbus
> @@ -18,6 +18,6 @@ config BR2_PACKAGE_SYSTEMD
>  
>  	  http://freedesktop.org/wiki/Software/systemd
>  
> -comment "systemd not available (depends on /dev management with udev and ipv6 support, and thread support in toolchain)"
> -	depends on !BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV || !BR2_INET_IPV6 || \\
> +comment "systemd not available (depends on ipv6 support, and thread support in toolchain)"
> +	depends on !BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV || !BR2_INET_IPV6 || \\
>  		!BR2_TOOLCHAIN_HAS_THREADS
> diff --git a/package/systemd/systemd-fix-getty-unit.patch b/package/systemd/systemd-fix-getty-unit.patch
> index 6df54b1..9b7f719 100644
> --- a/package/systemd/systemd-fix-getty-unit.patch
> +++ b/package/systemd/systemd-fix-getty-unit.patch
> @@ -1,34 +1,40 @@
> -Prefer getty to agetty in console setup systemd units
> +From e3b4ecc1ad838fea5b9796e9bdc08dcfd9e9c03e Mon Sep 17 00:00:00 2001
> +From: Olivier Schonken <olivier.schonken@gmail.com>
> +Date: Sun, 3 Mar 2013 13:35:03 +0200
> +Subject: Prefer getty to agetty in console setup systemd units
>  
> -Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> +Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
>  ---
>   units/getty at .service.m4        |    2 +-
>   units/serial-getty at .service.m4 |    2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>  
> -Index: systemd-37/units/getty at .service.m4
> -===================================================================
> ---- systemd-37.orig/units/getty at .service.m4
> -+++ systemd-37/units/getty at .service.m4
> -@@ -32,7 +32,7 @@
> +diff --git a/units/getty at .service.m4 b/units/getty at .service.m4
> +index 083eb97..60d5808 100644
> +--- a/units/getty at .service.m4
> ++++ b/units/getty at .service.m4
> +@@ -27,7 +27,7 @@ ConditionPathExists=/dev/tty0
>   
>   [Service]
> - Environment=TERM=linux
> --ExecStart=-/sbin/agetty %I 38400
> -+ExecStart=-/sbin/getty -L %I 115200 vt100
> + # the VT is cleared by TTYVTDisallocate
> +-ExecStart=-/sbin/agetty --noclear %I 38400 linux
> ++ExecStart=-/sbin/agetty -L %I 115200 vt100
> + Type=idle
>   Restart=always
>   RestartSec=0
> - UtmpIdentifier=%I
> -Index: systemd-37/units/serial-getty at .service.m4
> -===================================================================
> ---- systemd-37.orig/units/serial-getty at .service.m4
> -+++ systemd-37/units/serial-getty at .service.m4
> -@@ -32,7 +32,7 @@
> +diff --git a/units/serial-getty at .service.m4 b/units/serial-getty at .service.m4
> +index 60d7737..3c5bdda 100644
> +--- a/units/serial-getty at .service.m4
> ++++ b/units/serial-getty at .service.m4
> +@@ -22,7 +22,7 @@ Before=getty.target
> + IgnoreOnIsolate=yes
>   
>   [Service]
> - Environment=TERM=vt100
> --ExecStart=-/sbin/agetty -s %I 115200,38400,9600
> -+ExecStart=-/sbin/getty -L %I 115200 vt100
> +-ExecStart=-/sbin/agetty -s %I 115200,38400,9600 vt102
> ++ExecStart=-/sbin/agetty -L %I 115200 vt100
> + Type=idle
>   Restart=always
>   RestartSec=0
> - UtmpIdentifier=%I
> +-- 
> +1.7.10.4
> +
> diff --git a/package/systemd/systemd-fix-page-size.patch b/package/systemd/systemd-fix-page-size.patch
> deleted file mode 100644
> index 241ceb8..0000000
> --- a/package/systemd/systemd-fix-page-size.patch
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -commit 7264278fbbdc1dc6c30fedc902d1337594aa6ff6
> -Author: Lennart Poettering <lennart@poettering.net>
> -Date:   Wed Mar 21 23:47:44 2012 +0100
> -
> -    journal: PAGE_SIZE is not known on ppc and other archs
> -    
> -    Let's use NAME_MAX, as suggested by Dan Walsh
> -
> -diff --git a/src/journal/journald.c b/src/journal/journald.c
> -index d27cb60..87390bd 100644
> ---- a/src/journal/journald.c
> -+++ b/src/journal/journald.c
> -@@ -29,7 +29,6 @@
> - #include <sys/ioctl.h>
> - #include <linux/sockios.h>
> - #include <sys/statvfs.h>
> --#include <sys/user.h>
> - 
> - #include <systemd/sd-journal.h>
> - #include <systemd/sd-login.h>
> -@@ -2149,10 +2148,20 @@ static int process_event(Server *s, struct epoll_event *ev) {
> -                         size_t label_len = 0;
> -                         union {
> -                                 struct cmsghdr cmsghdr;
> -+
> -+                                /* We use NAME_MAX space for the
> -+                                 * SELinux label here. The kernel
> -+                                 * currently enforces no limit, but
> -+                                 * according to suggestions from the
> -+                                 * SELinux people this will change and
> -+                                 * it will probably be identical to
> -+                                 * NAME_MAX. For now we use that, but
> -+                                 * this should be updated one day when
> -+                                 * the final limit is known.*/
> -                                 uint8_t buf[CMSG_SPACE(sizeof(struct ucred)) +
> -                                             CMSG_SPACE(sizeof(struct timeval)) +
> --                                            CMSG_SPACE(sizeof(int)) +
> --                                            CMSG_SPACE(PAGE_SIZE)]; /* selinux label */
> -+                                            CMSG_SPACE(sizeof(int)) + /* fd */
> -+                                            CMSG_SPACE(NAME_MAX)]; /* selinux label */
> -                         } control;
> -                         ssize_t n;
> -                         int v;
> diff --git a/package/systemd/systemd-uclibc-fix.patch b/package/systemd/systemd-uclibc-fix.patch
> index 9a20845..2f689dc 100644
> --- a/package/systemd/systemd-uclibc-fix.patch
> +++ b/package/systemd/systemd-uclibc-fix.patch
> @@ -1,6 +1,9 @@
> -[PATCH] fix build with uClibc
> -
> -Based on OE patch from Khem Raj:
> +From 19a0d4a9007c6505320a1f413e7fbb14c765ad1f Mon Sep 17 00:00:00 2001
> +From: Olivier Schonken <olivier.schonken@gmail.com>
> +Date: Sun, 3 Mar 2013 13:43:19 +0200
> +Subject: Based on previous buildroot patch to systemd - including
> + previous commit message "Based on OE patch from Khem
> + Raj:
>  
>  http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/systemd/systemd/paper-over-mkostemp.patch
>  
> @@ -8,16 +11,38 @@ But extended to also cover execvpe (OE carries a patch adding execvpe
>  support to uClibc).
>  
>  Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> +"
> +
> +Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
>  ---
>   src/journal/journal-file.c |    2 ++
> - src/macro.h                |   15 +++++++++++++++
> + src/shared/macro.h         |   15 +++++++++++++++
>   2 files changed, 17 insertions(+)
>  
> -Index: systemd-44/src/macro.h
> -===================================================================
> ---- systemd-44.orig/src/macro.h
> -+++ systemd-44/src/macro.h
> -@@ -28,6 +28,21 @@
> +diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
> +index 13fc8ed..84daf75 100644
> +--- a/src/journal/journal-file.c
> ++++ b/src/journal/journal-file.c
> +@@ -318,12 +318,14 @@ static int journal_file_allocate(JournalFile *f, uint64_t offset, uint64_t size)
> +                 }
> +         }
> + 
> ++#ifndef __UCLIBC__
> +         /* Note that the glibc fallocate() fallback is very
> +            inefficient, hence we try to minimize the allocation area
> +            as we can. */
> +         r = posix_fallocate(f->fd, old_size, new_size - old_size);
> +         if (r != 0)
> +                 return -r;
> ++#endif
> + 
> +         if (fstat(f->fd, &f->last_stat) < 0)
> +                 return -errno;
> +diff --git a/src/shared/macro.h b/src/shared/macro.h
> +index 29d9139..1919c61 100644
> +--- a/src/shared/macro.h
> ++++ b/src/shared/macro.h
> +@@ -27,6 +27,21 @@
>   #include <sys/uio.h>
>   #include <inttypes.h>
>   
> @@ -39,21 +64,6 @@ Index: systemd-44/src/macro.h
>   #define _printf_attr_(a,b) __attribute__ ((format (printf, a, b)))
>   #define _sentinel_ __attribute__ ((sentinel))
>   #define _noreturn_ __attribute__((noreturn))
> -Index: systemd-44/src/journal/journal-file.c
> -===================================================================
> ---- systemd-44.orig/src/journal/journal-file.c
> -+++ systemd-44/src/journal/journal-file.c
> -@@ -229,11 +229,13 @@
> -                 }
> -         }
> - 
> -+#ifndef __UCLIBC__
> -         /* Note that the glibc fallocate() fallback is very
> -            inefficient, hence we try to minimize the allocation area
> -            as we can. */
> -         if (posix_fallocate(f->fd, old_size, new_size - old_size) < 0)
> -                 return -errno;
> -+#endif
> - 
> -         if (fstat(f->fd, &f->last_stat) < 0)
> -                 return -errno;
> +-- 
> +1.7.10.4
> +
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index e85355f..a04b15e 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -3,14 +3,13 @@
>  # systemd
>  #
>  #############################################################
> -SYSTEMD_VERSION = 44
> +SYSTEMD_VERSION = 197
>  SYSTEMD_SITE = http://www.freedesktop.org/software/systemd/
>  SYSTEMD_SOURCE = systemd-$(SYSTEMD_VERSION).tar.xz
>  SYSTEMD_INSTALL_STAGING = YES
>  SYSTEMD_DEPENDENCIES = \
>  	host-intltool \
>  	libcap \
> -	udev \
>  	dbus
>  
>  # Make sure that systemd will always be built after busybox so that we have
> @@ -34,7 +33,22 @@ SYSTEMD_CONF_OPT += \
>  	--with-udevrulesdir=/etc/udev/rules.d \
>  	--with-sysvinit-path=/etc/init.d/ \
>  	--without-sysvrcd-path \
> -	--enable-split-usr
> +	--enable-split-usr 
> +
> +ifeq ($(BR2_PACKAGE_LIBGLIB2),y)
> +	SYSTEMD_CONF_OPT += --enable-gudev
> +	SYSTEMD_DEPENDENCIES += libglib2
> +else
> +	SYSTEMD_CONF_OPT += --disable-gudev 
> +endif
> +
> +ifeq ($(BR2_PACKAGE_PYTHON),y)
> +	SYSTEMD_CONF_OPT += --enable-acl
> +	SYSTEMD_DEPENDENCIES += python
> +else
> +	SYSTEMD_CONF_OPT += --without-python
> +endif
> +        
>  
>  ifeq ($(BR2_PACKAGE_ACL),y)
>  	SYSTEMD_CONF_OPT += --enable-acl
> diff --git a/system/Config.in b/system/Config.in
> index 1e4fff3..4834298 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -86,7 +86,17 @@ config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
>  	depends on BR2_USE_WCHAR # udev
>  	select BR2_PACKAGE_UDEV
>  
> -comment "udev requires a toolchain with LARGEFILE + WCHAR support"
> +config BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV
> +	bool "Dynamic using sytemd integrated udev"
> +	depends on BR2_LARGEFILE # udev
> +	depends on BR2_USE_WCHAR # udev
> +	depends on BR2_INET_IPV6
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	depends on BR2_USE_MMU
> +	select BR2_PACKAGE_DBUS
> +	select BR2_PACKAGE_SYSTEMD
> +
> +comment "systemd udev requires a toolchain with LARGEFILE + WCHAR support"
>  	depends on !(BR2_LARGEFILE && BR2_USE_WCHAR)
>  
>  endchoice
> @@ -108,16 +118,16 @@ config BR2_INIT_SYSTEMD
>  	depends on BR2_LARGEFILE
>  	depends on BR2_USE_WCHAR
>  	depends on BR2_INET_IPV6
> -	depends on BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
> +	depends on BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV
>  	depends on BR2_TOOLCHAIN_HAS_THREADS
>  	depends on BR2_USE_MMU
>  	select BR2_PACKAGE_DBUS
>  	select BR2_PACKAGE_SYSTEMD
>  
> -comment 'systemd requires largefile, wchar, IPv6, threads and udev support'
> +comment 'systemd requires largefile, wchar, IPv6 and threads support'
>  	depends on !(BR2_LARGEFILE && BR2_USE_WCHAR && \
>  		     BR2_INET_IPV6 && BR2_TOOLCHAIN_HAS_THREADS && \
> -		     BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV)
> +                     BR2_ROOTFS_DEVICE_CREATION_SYSTEMD_DYNAMIC_UDEV)
>  
>  config BR2_INIT_NONE
>  	bool "None"

This will need at least the following additional patch to be able to
build with uClibc:

http://eric-weiss.de/oe/oe-core/meta/recipes-core/systemd/systemd/optional_secure_getenv.patch

Regards
Stefan

[Buildroot] [PATCH 1/1] Updated systemd to version 197

[Stefan Fröberg]

[snip..] 

> This will need at least the following additional patch to be able to
> build with uClibc:
>
> http://eric-weiss.de/oe/oe-core/meta/recipes-core/systemd/systemd/optional_secure_getenv.patch
>
> Regards
> Stefan
>


Also, package/systemd/systemd-uclibc-fix.patch needs updating.
src/journal/journald-kmsg.c needs also posix_fallocate workaround.

However, there is a patch for uClibc 0.9.33  that add's
posix_fallocate() function
http://git.uclibc.org/uClibc/patch/?id=5643900913f64c00f1c2958914586708efa5a473

And maybe latest git of uClibc (or at least coming 0.9.34) will contain
that function.
'
So patching 0.9.33 with posix_fallocate and/or requiring at least 0.9.34
for systemd would be good.

Please also add the following:

ifeq
($(BR2_TOOLCHAIN_BUILDROOT)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC)$(BR2_TOOLCHAIN_CTNG_uClibc),y)
    SYSTEMD_CONF_OPT += --disable-myhostname
endif

Regards
Stefan