| Message ID | 1362312574-17701-1-git-send-email-olivier.schonken@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
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
> 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.
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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
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
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
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
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
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
>>>>> "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.
>>>>> "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.
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
> 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.
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
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
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
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
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
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
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
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
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
[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
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
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
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@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@busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > > > > -- > Charles Krinke >
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
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
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
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@.service.m4 | 2 +- > units/serial-getty@.service.m4 | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > -Index: systemd-37/units/getty@.service.m4 > -=================================================================== > ---- systemd-37.orig/units/getty@.service.m4 > -+++ systemd-37/units/getty@.service.m4 > -@@ -32,7 +32,7 @@ > +diff --git a/units/getty@.service.m4 b/units/getty@.service.m4 > +index 083eb97..60d5808 100644 > +--- a/units/getty@.service.m4 > ++++ b/units/getty@.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@.service.m4 > -=================================================================== > ---- systemd-37.orig/units/serial-getty@.service.m4 > -+++ systemd-37/units/serial-getty@.service.m4 > -@@ -32,7 +32,7 @@ > +diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4 > +index 60d7737..3c5bdda 100644 > +--- a/units/serial-getty@.service.m4 > ++++ b/units/serial-getty@.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
[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
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@.service.m4 | 2 +- units/serial-getty@.service.m4 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -Index: systemd-37/units/getty@.service.m4 -=================================================================== ---- systemd-37.orig/units/getty@.service.m4 -+++ systemd-37/units/getty@.service.m4 -@@ -32,7 +32,7 @@ +diff --git a/units/getty@.service.m4 b/units/getty@.service.m4 +index 083eb97..60d5808 100644 +--- a/units/getty@.service.m4 ++++ b/units/getty@.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@.service.m4 -=================================================================== ---- systemd-37.orig/units/serial-getty@.service.m4 -+++ systemd-37/units/serial-getty@.service.m4 -@@ -32,7 +32,7 @@ +diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4 +index 60d7737..3c5bdda 100644 +--- a/units/serial-getty@.service.m4 ++++ b/units/serial-getty@.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"
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