Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
孙冰 writes: > I use this: > > [Unit] > Description=Wicd sleep hook > Before=sleep.target > StopWhenUnneeded=yes > > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStart=-/usr/share/wicd/daemon/suspend.py > ExecStop=-/usr/share/wicd/daemon/autoconnect.py > > [Install] > WantedBy=sleep.target > - Clever :) It turns out I always misinterpreted the documentation for StopWhenUnneeded. I never read past the first sentence and assumed this option was only going to stop services "when it felt like it". But this is a very nice solution, still stateful (remainafterexit) but by focusing on the sleep-state instead of the before-sleep and after-sleep it nicely works around cyclic/conflicting dependencies. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
I use this: [Unit] Description=Wicd sleep hook Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=-/usr/share/wicd/daemon/suspend.py ExecStop=-/usr/share/wicd/daemon/autoconnect.py [Install] WantedBy=sleep.target - ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.
Hi Tony, best to my experiences, I doubt that suppressing the loading of device units will speed up systemd that much. There are other major parts that far more significantly delay the startup (cgroups in some cases, loading the unit set at startup, executing the generators, and finally loading the binary of systemd and the shared libraries ...). You'll probably gain more benefit when starting to optimize at these ends ... Best regards Marko Hoyer Software Group II (ADITG/SW2) Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 > -Original Message- > From: systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org > [mailto:systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org] On > Behalf Of Tony Seo > Sent: Thursday, August 08, 2013 3:12 AM > To: Mantas Mikulėnas > Cc: systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] How to delete device units presented in systemd- > analyze plot. > > > I understand what you mean, but I think that I will cut the time for loading > device unit if I keep those from appearing on my plot. > > I want to do a try to temporarily disappear some kinds of device units and > then I'm supposed to measure boot speed depending a board of mine.(Actually, I > believe that loading time for device unit affects to boot speed) > > What do think that loading time for device units doesn't affect to boot speed > at machine? > > Thanks. > > > > 2013/8/8 Mantas Mikulėnas > > > On Wed, Aug 7, 2013 at 8:03 PM, Tony Seo wrote: > > > > Hello. > > > > Now, I have studied systemd for optimizing systemd on my board. > > > > After edited several units, I would like to delete some device > configuration > > units existing on my picture from systemd-analyze(best-dream- > boy.blogspot) > > > > I read the manual pages about systemd.device, I tried to delete > device units > > through editing /etc/fstab and systemctl mask. > > > > But I couldn't delete those device units, at least existing units on > the > > picture. > > > You cannot delete these units because they do not exist anywhere > except in memory – they're only a way to represent device status in > the format of systemd units. In other words, they do not cause the > problems you're having; they only make the problems visible in your > bootchart. > > -- > Mantas Mikulėnas > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fstab-generator: why nofail=true removes "Before=$post" in .mount
Hi, all I have a question after looking fstab-generator.c. I hope someone can help me. In add_mount(), if nofail=true, "Before=$post" won't be added to xxx.mount: [..] if (post && !noauto && !nofail && !automount) fprintf(f, "Before=%s\n", post); why doing this? If nofail=true, that means $post "Wants" this xxx.mount. And no matter xxx.mount fails or not, $post will be reached (if post is a target unit). I think it's more reasonable to try do xxx.mount before $post. So I'd like to keep "Before=$post" in the nofail=true case. I coud post a patch, but I think it's best to consult to you guys first in case I'm missing something. Thanks WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dbus: use _cleanup_free_ instead of freeing ourself
On Thu, Jul 25, 2013 at 05:36:01PM +0200, Ronny Chevalier wrote: > --- > src/core/dbus-execute.c | 3 +-- > src/core/dbus-job.c | 11 ++- > src/core/dbus-manager.c | 14 +++--- > src/core/unit.c | 48 ++-- > 4 files changed, 28 insertions(+), 48 deletions(-) Applied... > @@ -1225,12 +1224,10 @@ static DBusHandlerResult > bus_manager_message_handler(DBusConnection *connection, > p = bus_path_escape(k); > if (!p) { > fclose(f); > -free(introspection); > goto oom; > } ... but you could think about also applying _cleanup_fclose_ here. This would completely kill the cleanup in error handling blocks, making things simpler. > int unit_write_drop_in(Unit *u, UnitSetPropertiesMode mode, const char > *name, const char *data) { > -_cleanup_free_ char *p = NULL, *q = NULL; > +_cleanup_free_ char *p = NULL; > +_cleanup_free_ char *q = NULL; ... and I removed those parts which split variable declarations into separate lines. They were fine as they were. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.
I understand what you mean, but I think that I will cut the time for loading device unit if I keep those from appearing on my plot. I want to do a try to temporarily disappear some kinds of device units and then I'm supposed to measure boot speed depending a board of mine.(Actually, I believe that loading time for device unit affects to boot speed) What do think that loading time for device units doesn't affect to boot speed at machine? Thanks. 2013/8/8 Mantas Mikulėnas > On Wed, Aug 7, 2013 at 8:03 PM, Tony Seo wrote: > > > > Hello. > > > > Now, I have studied systemd for optimizing systemd on my board. > > > > After edited several units, I would like to delete some device > configuration > > units existing on my picture from > systemd-analyze(best-dream-boy.blogspot) > > > > I read the manual pages about systemd.device, I tried to delete device > units > > through editing /etc/fstab and systemctl mask. > > > > But I couldn't delete those device units, at least existing units on the > > picture. > > You cannot delete these units because they do not exist anywhere > except in memory – they're only a way to represent device status in > the format of systemd units. In other words, they do not cause the > problems you're having; they only make the problems visible in your > bootchart. > > -- > Mantas Mikulėnas > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Re] I wanna construct server-client model with systemd option
Thank you for your friendly answer. After I recevied your mail, I have aimed to complete to make server-client model. In my view, I didn't still know how to use a service option in service configuration file. The seceario I want to make is like this: *A..service is a server program and it should be remained continuously.* *And B.service as a client program can access to A.service which has been living in systemd.* In this case, What should I use options each service which I said. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: fail firmware loading immediately if no search path is defined
On Wed, Aug 7, 2013 at 12:52 AM, Maarten Lankhorst wrote: > Op 07-08-13 02:26, Andy Lutomirski schreef: >> On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen wrote: >>> On 6 Aug 2013 18:32, "Bryan Kadzban" wrote: On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote: > On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen wrote: >> On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst >> wrote: >>> Op 05-08-13 18:29, Andy Lutomirski schreef: The systemd commit below can delay firmware loading by multiple minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one noticed that the systemd-udev change would break new kernels as well as old kernels. Since the kernel apparently can't count on reasonable userspace support, turn this thing off by default. commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a Author: Tom Gundersen Date: Mon Mar 18 15:12:18 2013 +0100 udev: make firmware loading optional and disable by default Distros that whish to support old kernels should set --with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware" to retain the old behaviour. >>> methinks this patch should be reverted then, >> Well, all the code is still there, so it can be enabled if anyone >> wants it. >> >>> or a stub should be added to udev to always fail firmware loading so >>> timeouts don't occur. >> I think the only use (if any) of a userspace firmware loader would be >> for anyone who wants a custom one (i.e., not udev), so we shouldn't >> just fail the loading from udev unconditionally. >> >> How about we just improve the udev documentation a bit, similar to >> Andy's kernel patch? > Sorry, I should first have checked. We already document this in the > README: > >>Userspace firmware loading is deprecated, will go away, and >>sometimes causes problems: >> CONFIG_FW_LOADER_USER_HELPER=n ...And this patch is making the kernel default to the correct behavior, instead of the now-broken-by-udev behavior. I'm not sure I see the issue with it? :-) >>> Oh yeah this patch is totally the right thing to do, I was just arguing that >>> there is nothing to be done on the udev side. >>> (Add me to the list of people that think udev is broken too, fwiw. But let's at least not leave *both* sides in a broken-by-default state.) >>> Well I don't think it is too much to ask that the kernel and udev should be >>> configured in a consistent way. Especially as thing still work even if you >>> get it wrong, albeit with a delay. >> Except that the current defaults are inconsistent and there is no >> explanation anywhere in the logs when this is screwed up. >> > So what is wrong with my 'fail in udev immediately if not configured' idea? > In that case it > doesn't matter whether CONFIG_FW_LOADER_USER_HELPER is set or not. > > You could even print a useful message for the user in udev to the log, so > they have an idea of what > happened. Breaking udev on older still supported kernels by default without > printing any debug info > is silly, and the only cost is a small increase in disk space when unused. I > did so in below patch. Seems reasonable to me. It might be worth adding something to the message to suggest turning off CONFIG_FW_LOADER_USER_HELPER. > > ~Maarten > > I converted < ELEMENTSOF to != ELEMENTSOF in the loop to work correctly when > the array is empty. > Most code in udev-builtin-firmware is eliminated at -O2 optimization level > when FIRMWARE_PATH > is not explicitly set. > > 8< > diff --git a/Makefile.am b/Makefile.am > index b8b8d06..2097629 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -2235,6 +2235,7 @@ libudev_core_la_SOURCES = \ > src/udev/udev-ctrl.c \ > src/udev/udev-builtin.c \ > src/udev/udev-builtin-btrfs.c \ > + src/udev/udev-builtin-firmware.c \ > src/udev/udev-builtin-hwdb.c \ > src/udev/udev-builtin-input_id.c \ > src/udev/udev-builtin-keyboard.c \ > @@ -2271,14 +2272,6 @@ libudev_core_la_CPPFLAGS = \ > $(AM_CPPFLAGS) \ > -DFIRMWARE_PATH="$(FIRMWARE_PATH)" > > -if ENABLE_FIRMWARE > -libudev_core_la_SOURCES += \ > - src/udev/udev-builtin-firmware.c > - > -dist_udevrules_DATA += \ > - rules/50-firmware.rules > -endif > - > if HAVE_KMOD > libudev_core_la_SOURCES += \ > src/udev/udev-builtin-kmod.c > diff --git a/configure.ac b/configure.ac > index 0ecc716..dc7a3e3 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -823,8 +823,6 @@ for i in $with_firmware_path; do > done > IFS=$OLD_IFS > AC_SUBST(FIRMWARE_PATH) > -AS_IF([test "x${FIRMWARE_PATH}" != "x"], [ AC_DEFINE(HAVE_FIRMWARE, 1, > [Define if FIRMWARE is available]) ]) > -AM_CONDITIONAL(ENABLE_FIRMWARE, [test
Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.
On Wed, Aug 7, 2013 at 8:03 PM, Tony Seo wrote: > > Hello. > > Now, I have studied systemd for optimizing systemd on my board. > > After edited several units, I would like to delete some device configuration > units existing on my picture from systemd-analyze(best-dream-boy.blogspot) > > I read the manual pages about systemd.device, I tried to delete device units > through editing /etc/fstab and systemctl mask. > > But I couldn't delete those device units, at least existing units on the > picture. You cannot delete these units because they do not exist anywhere except in memory – they're only a way to represent device status in the format of systemd units. In other words, they do not cause the problems you're having; they only make the problems visible in your bootchart. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to delete device units presented in systemd-analyze plot.
Hello. Now, I have studied systemd for optimizing systemd on my board. After edited several units, I would like to delete some device configuration units existing on my picture from systemd-analyze(best-dream-boy.blogspot) I read the manual pages about systemd.device, I tried to delete device units through editing /etc/fstab and systemctl mask. But I couldn't delete those device units, at least existing units on the picture. So I would ask you a question about it. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2, ping?] tmpfiles, man: Add xattr support to tmpfiles
It was <2013-07-15 pon 15:22>, when Maciej Wereski wrote: > diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml > index 519f9bc..92157b5 100644 > --- a/man/tmpfiles.d.xml > +++ b/man/tmpfiles.d.xml > @@ -229,6 +229,21 @@ L/tmp/foobar ---- > /dev/null > place of normal path > names. > > + > + > +t > +Set extended > +attributes on item. It should be > +used with conjunction with other "in conjunction with" -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impact when not loading ipv6 and autofs kernel module ...
On Wed, Aug 7, 2013 at 1:24 PM, Hoyer, Marko (ADITG/SW2) wrote: > 2. What impact do I have to expect in case the kernel does not provide > ipv6 functionality? I think the main problem is in case you were to somehow insmod the ipv6 module after boot, in which case it probably won't be set up correctly. Maybe someone else know of other problems? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
Indeed, that sounds like a solution. It's a bit of a philosophical thing though, remainafterexit+oneshot works nicely for things that represent a certain state (powersaving on) which can be inspected and turned off. oneshot "scripts" don't feel natural to me somehow without such a state (which RemainAfterExit provides). But maybe I need to alter my view on services a bit. For now I will try your solution. Thanks On Wed, Aug 7, 2013 at 1:02 PM, Tom Gundersen wrote: > On Wed, Aug 7, 2013 at 10:12 AM, Mathijs Kwik > wrote: >> I have a few things that need to get run after waking up my laptop >> (things like hdparm to set device power options/spindown time). >> I created oneshot, remainafterexit services for those and made them >> wanted by multi-user.target.This works fine for the first boot. > > Are you sure you want RemainAfterExit? Without it you should be able > to set WantedBy=sleep.target and After=sleep.target. > >> As I consider these services "dead" after a suspend/hibernate, I added >> Conflicts=sleep.target, so now systemd is aware that these services >> are no longer active after a wakeup. >> >> Now I would like to somehow have these services restart on wakeup. >> I can add these services to some new target(wakeup.target), but I >> don't know how to proceed from there. I thought of making >> wakeup.target WantedBy suspend.target, After suspend.target, but since >> suspend.target pulls in sleep.target (which conflicts with these >> services) that will fail. More so, after wakeup.target is started the >> first time, it will never go down itself, so the second wakeup won't >> do anything. The same is true for multi-user.target, once that is >> reached/activated on first boot, it never deactivates until shutdown. >> >> How should a situation like this be handled? >> Ideally, I don't want to use: >> - /usr/lib/systemd/system-sleep (considered hacky) >> - a service/script that runs "systemctl start ..." (secret >> dependency, hidden from systemd) >> >> Thanks, >> Mathijs >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Impact when not loading ipv6 and autofs kernel module ...
Hello systemd developers, I found that systemd automatically tries to load ipv6 and autofs kernel modules, when they are not compiled in. Could you give me a hint what is not working, when they are neither provided as kernel modules nor compiled in? In case of autofs I found that automount units are not working any more (I would have expected this). Without ipv6 I can't find any problems by now. So: 1. Is there any other impact but the described one when the autofs kernel feature is missing? 2. What impact do I have to expect in case the kernel does not provide ipv6 functionality? Thx for any input. Best regards Marko Hoyer Advanced Driver Information Technology GmbH Software Group II (ADITG/SW2) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6948 Fax +49 5121 49 6999 mho...@de.adit-jv.com ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschäftsführung: Wilhelm Grabow, Katsuyoshi Maeda ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
On Wed, Aug 7, 2013 at 10:12 AM, Mathijs Kwik wrote: > I have a few things that need to get run after waking up my laptop > (things like hdparm to set device power options/spindown time). > I created oneshot, remainafterexit services for those and made them > wanted by multi-user.target.This works fine for the first boot. Are you sure you want RemainAfterExit? Without it you should be able to set WantedBy=sleep.target and After=sleep.target. > As I consider these services "dead" after a suspend/hibernate, I added > Conflicts=sleep.target, so now systemd is aware that these services > are no longer active after a wakeup. > > Now I would like to somehow have these services restart on wakeup. > I can add these services to some new target(wakeup.target), but I > don't know how to proceed from there. I thought of making > wakeup.target WantedBy suspend.target, After suspend.target, but since > suspend.target pulls in sleep.target (which conflicts with these > services) that will fail. More so, after wakeup.target is started the > first time, it will never go down itself, so the second wakeup won't > do anything. The same is true for multi-user.target, once that is > reached/activated on first boot, it never deactivates until shutdown. > > How should a situation like this be handled? > Ideally, I don't want to use: > - /usr/lib/systemd/system-sleep (considered hacky) > - a service/script that runs "systemctl start ..." (secret > dependency, hidden from systemd) > > Thanks, > Mathijs > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
Hi all, I have a few things that need to get run after waking up my laptop (things like hdparm to set device power options/spindown time). I created oneshot, remainafterexit services for those and made them wanted by multi-user.target.This works fine for the first boot. As I consider these services "dead" after a suspend/hibernate, I added Conflicts=sleep.target, so now systemd is aware that these services are no longer active after a wakeup. Now I would like to somehow have these services restart on wakeup. I can add these services to some new target(wakeup.target), but I don't know how to proceed from there. I thought of making wakeup.target WantedBy suspend.target, After suspend.target, but since suspend.target pulls in sleep.target (which conflicts with these services) that will fail. More so, after wakeup.target is started the first time, it will never go down itself, so the second wakeup won't do anything. The same is true for multi-user.target, once that is reached/activated on first boot, it never deactivates until shutdown. How should a situation like this be handled? Ideally, I don't want to use: - /usr/lib/systemd/system-sleep (considered hacky) - a service/script that runs "systemctl start ..." (secret dependency, hidden from systemd) Thanks, Mathijs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: fail firmware loading immediately if no search path is defined
Op 07-08-13 02:26, Andy Lutomirski schreef: > On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen wrote: >> On 6 Aug 2013 18:32, "Bryan Kadzban" wrote: >>> On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote: On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen wrote: > On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst > wrote: >> Op 05-08-13 18:29, Andy Lutomirski schreef: >>> The systemd commit below can delay firmware loading by multiple >>> minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one >>> noticed that the systemd-udev change would break new kernels as well >>> as old kernels. >>> >>> Since the kernel apparently can't count on reasonable userspace >>> support, turn this thing off by default. >>> >>> commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a >>> Author: Tom Gundersen >>> Date: Mon Mar 18 15:12:18 2013 +0100 >>> >>> udev: make firmware loading optional and disable by default >>> >>> Distros that whish to support old kernels should set >>> >>> --with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware" >>> to retain the old behaviour. >>> >> methinks this patch should be reverted then, > Well, all the code is still there, so it can be enabled if anyone > wants it. > >> or a stub should be added to udev to always fail firmware loading so >> timeouts don't occur. > I think the only use (if any) of a userspace firmware loader would be > for anyone who wants a custom one (i.e., not udev), so we shouldn't > just fail the loading from udev unconditionally. > > How about we just improve the udev documentation a bit, similar to > Andy's kernel patch? Sorry, I should first have checked. We already document this in the README: >Userspace firmware loading is deprecated, will go away, and >sometimes causes problems: > CONFIG_FW_LOADER_USER_HELPER=n >>> ...And this patch is making the kernel default to the correct behavior, >>> instead of the now-broken-by-udev behavior. >>> >>> I'm not sure I see the issue with it? :-) >> Oh yeah this patch is totally the right thing to do, I was just arguing that >> there is nothing to be done on the udev side. >> >>> (Add me to the list of people that think udev is broken too, fwiw. But >>> let's at least not leave *both* sides in a broken-by-default state.) >> Well I don't think it is too much to ask that the kernel and udev should be >> configured in a consistent way. Especially as thing still work even if you >> get it wrong, albeit with a delay. > Except that the current defaults are inconsistent and there is no > explanation anywhere in the logs when this is screwed up. > So what is wrong with my 'fail in udev immediately if not configured' idea? In that case it doesn't matter whether CONFIG_FW_LOADER_USER_HELPER is set or not. You could even print a useful message for the user in udev to the log, so they have an idea of what happened. Breaking udev on older still supported kernels by default without printing any debug info is silly, and the only cost is a small increase in disk space when unused. I did so in below patch. ~Maarten I converted < ELEMENTSOF to != ELEMENTSOF in the loop to work correctly when the array is empty. Most code in udev-builtin-firmware is eliminated at -O2 optimization level when FIRMWARE_PATH is not explicitly set. 8< diff --git a/Makefile.am b/Makefile.am index b8b8d06..2097629 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2235,6 +2235,7 @@ libudev_core_la_SOURCES = \ src/udev/udev-ctrl.c \ src/udev/udev-builtin.c \ src/udev/udev-builtin-btrfs.c \ + src/udev/udev-builtin-firmware.c \ src/udev/udev-builtin-hwdb.c \ src/udev/udev-builtin-input_id.c \ src/udev/udev-builtin-keyboard.c \ @@ -2271,14 +2272,6 @@ libudev_core_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ -DFIRMWARE_PATH="$(FIRMWARE_PATH)" -if ENABLE_FIRMWARE -libudev_core_la_SOURCES += \ - src/udev/udev-builtin-firmware.c - -dist_udevrules_DATA += \ - rules/50-firmware.rules -endif - if HAVE_KMOD libudev_core_la_SOURCES += \ src/udev/udev-builtin-kmod.c diff --git a/configure.ac b/configure.ac index 0ecc716..dc7a3e3 100644 --- a/configure.ac +++ b/configure.ac @@ -823,8 +823,6 @@ for i in $with_firmware_path; do done IFS=$OLD_IFS AC_SUBST(FIRMWARE_PATH) -AS_IF([test "x${FIRMWARE_PATH}" != "x"], [ AC_DEFINE(HAVE_FIRMWARE, 1, [Define if FIRMWARE is available]) ]) -AM_CONDITIONAL(ENABLE_FIRMWARE, [test "x${FIRMWARE_PATH}" != "x"]) # -- AC_ARG_ENABLE([gudev], diff --git a/rules/50-firmware.rules b/rules/50-firmware.rules deleted file mode 100644 index f0ae684..000 --- a/rules/50-firmware.rules +++ /dev/null @@ -1,3 +0,0 @@ -# do not edit this file, it will be overwritten on