Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 7:37 PM, Tom Gundersen t...@jklm.no wrote: On 30 May 2014 18:25, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 30/05/14 13:08, Greg KH escribió: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. Maybe I am not understanding something well. but the driver appears to require the *kernel* side of this functionality. https://www.kernel.org/doc/Documentation/dell_rbu.txt Because I am pretty sure udev is not in the business of BIOS updates.. True, but until that is fixed on the kernel side the support is still required on the udev side for things to work in all cases (sorry for not pointing this out earlier BTW). I think what some distros have done is to just rip out the Dell bios thing, but I guess that won't fly in the upstream kernel. Refactoring this on the kernel side so the dell stuff is not tied to the regular firmware loader should not be hard from what I can tell... (to be honest the whole thing looks like a pretty bad abuse of the interface). Any takers? In case anyone is interested in testing this out with the affected hardware, that would be awesome: http://www.spinics.net/lists/kernel/msg1755247.html. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 01/06/14 08:45, Lennart Poettering wrote: On Fri, 30.05.14 04:32, Michael Biebl (mbi...@gmail.com) wrote: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. To make this clear, we expect that systemd and kernels are updated in lockstep. We explicitly do not support really old kernels with really new systemd. So far we had the focus to support up to 2y old kernels (which means 3.4 right now), but even that should be taken with a grain of salt, as we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side. I am tempted to say that we should merge the firmware loader removal patch at the same time as the kdbus requirement is made. As that would be a clean cut anyway... Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. I've already set minimum kernel required to 2.6.39 in = 213, and I'd be fine setting it even higher. Talking only of the udev bit here. I don't like dropping support for old versions, but if that's what has to be done, I'll go with that. Please, don't use this as an excuse to drop support for MinimalBuilds as described in wiki in some manner. As in, if it's still possible to use some kernel, like kernel with kdbus, and even if it requires an userspace library like 'libsystemd-something' to go with it, and still get a udev one way or another, that can run standalone, we are all good. I'd really hate to be forced to fork (or carry huge patchset) unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what is provided to me by *you*, udev upstream) - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Sun, 01.06.14 09:10, Samuli Suominen (ssuomi...@gentoo.org) wrote: Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. I've already set minimum kernel required to 2.6.39 in = 213, and I'd be fine setting it even higher. Talking only of the udev bit here. I don't like dropping support for old versions, but if that's what has to be done, I'll go with that. Please, don't use this as an excuse to drop support for MinimalBuilds as described in wiki in some manner. As in, if it's still possible to use some kernel, like kernel with kdbus, and even if it requires an userspace library like 'libsystemd-something' to go with it, and still get a udev one way or another, that can run standalone, we are all good. You need the userspace code to set up the bus and its policy and handle activation. That's not a trivial task. For us, that's what sytemd does in PID 1. You'd need to come up with an alternative for that. I'd really hate to be forced to fork (or carry huge patchset) unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what is provided to me by *you*, udev upstream) Oh god. You know, if you come me like this as blame me that I would force you to do something, then you just piss me off and make me ignore you. Anyway, as soon as kdbus is merged this i how we will maintain udev, you have ample time to figure out some solution that works for you, but we will not support the udev-on-netlink case anymore. I see three options: a) fork things, b) live with systemd, c) if hate systemd that much, but love udev so much, then implement an alternative userspace for kdbus to do initialiuzation/policy/activation. Also note that this will not be a change that is just internal between udev and libudev. We expect that clients will soonishly just start doing normal bus calls to the new udev, like they'd do them to any other system service instead of using libudev. Good luck, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, 30.05.14 04:32, Michael Biebl (mbi...@gmail.com) wrote: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. To make this clear, we expect that systemd and kernels are updated in lockstep. We explicitly do not support really old kernels with really new systemd. So far we had the focus to support up to 2y old kernels (which means 3.4 right now), but even that should be taken with a grain of salt, as we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side. I am tempted to say that we should merge the firmware loader removal patch at the same time as the kdbus requirement is made. As that would be a clean cut anyway... Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30 May 2014 03:10, Michael Biebl mbi...@gmail.com wrote: 2014-05-30 3:55 GMT+02:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? Debian Wheezy does ship with 3.2 and we do provide backports of newer systemd versions of it. It also simplifies dist-upgrades if one can still boot with the old kernel in case the new one fails to boot for whatever reason. So +1 for keeping it. As Zbiginiew said, the maintenance cost is basically zero. While it is not very important that this patch gets applied now, as a general rule it seems extremely unlikely that we will keep being able to boot on such old kernels going forward. Maybe it would be best to find some alternative way to achieve your features sooner rather than later? You could for instance use the double reboot mechanism to upgrade from really old kernels and some sort of double buffering or snapshots to support rollback. Running new user space on ancient kernels seems like it would just cause more work at little to no gain... Just my two cents, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 05/30/2014 02:51 AM, Greg KH wrote: On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Bieblmbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KHgre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? Agreed. Upstream should always be the driving force forwards thus carrying the most modern code as well as being the decisive factor when it's time to obsolete things from their code base and the burden be put on downstream to carry and maintaining the legacy code being removed if for whatever reason they still require the functionality it provided, be it the udev firmware loader or legacy compatibility mode or generators etc. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote: On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related Then stick with those old systemd/udev versions for those kernels, nothings wrong with that. But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated Why would 6 months make any difference for removing it then vs. now? greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30/05/14 17:13, Greg KH wrote: On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote: On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related Then stick with those old systemd/udev versions for those kernels, nothings wrong with that. Yes there is, it means an extra step for the users to mask newer versions, and burden for maintainers to backtrack patches for bugfixes for old version But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated Why would 6 months make any difference for removing it then vs. now? Because new kernel patchsets are being written, some are semi-ready in various version controls, some are not, giving time for upstreams to migrate is usually good idea, expecting everyone is ready when you say jump is not realistic If it's really not a big problem to maintain the firmware loader for some time longer, please just do that :/ - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 06:05:19PM +0300, Samuli Suominen wrote: On 30/05/14 17:13, Greg KH wrote: On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote: On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related Then stick with those old systemd/udev versions for those kernels, nothings wrong with that. Yes there is, it means an extra step for the users to mask newer versions, and burden for maintainers to backtrack patches for bugfixes for old version That burden is on you in the first place for agreeing to keep supporting such old and obsolete kernels. Not on others who made no such agreement or decision. But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated Why would 6 months make any difference for removing it then vs. now? Because new kernel patchsets are being written, some are semi-ready in various version controls, some are not, giving time for upstreams to migrate is usually good idea, expecting everyone is ready when you say jump is not realistic The kernel said jump a long time ago, why didn't you change then? If it's really not a big problem to maintain the firmware loader for some time longer, please just do that :/ Again, why should we care about older distros who rely on older kernels? The burden of keeping code running on those older kernels is up to the developers who made the decision to keep running them, not to upstream projects who know better. As you say, the patch is simple for you to keep in your tree, if you want to keep the feature around. That way you can keep running old kernels for a decade if you decide to. But honestly, it makes no sense anymore to keep this in the repo at all. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. bah, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
El 30/05/14 13:08, Greg KH escribió: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. Maybe I am not understanding something well. but the driver appears to require the *kernel* side of this functionality. https://www.kernel.org/doc/Documentation/dell_rbu.txt Because I am pretty sure udev is not in the business of BIOS updates.. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30 May 2014 18:25, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 30/05/14 13:08, Greg KH escribió: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. Maybe I am not understanding something well. but the driver appears to require the *kernel* side of this functionality. https://www.kernel.org/doc/Documentation/dell_rbu.txt Because I am pretty sure udev is not in the business of BIOS updates.. True, but until that is fixed on the kernel side the support is still required on the udev side for things to work in all cases (sorry for not pointing this out earlier BTW). I think what some distros have done is to just rip out the Dell bios thing, but I guess that won't fly in the upstream kernel. Refactoring this on the kernel side so the dell stuff is not tied to the regular firmware loader should not be hard from what I can tell... (to be honest the whole thing looks like a pretty bad abuse of the interface). Any takers? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote:
As discussed ad-nauseum previously, it is the kernel's task
to load firmware, not udev's.
I think this patch is a bad idea - it makes things harder for people
who, for whatever reason, good or bad, run older kernels. At the same
time, our maintenance burden is pretty much zero.
Zbyszek
---
Makefile.am | 8
configure.ac| 20
src/udev/udev-builtin.c | 3 ---
src/udev/udev.h | 6 --
src/udev/udevd.c| 13 -
5 files changed, 50 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 50e7560..2965966 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2788,14 +2788,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 be57e82..6c84c66 100644
--- a/configure.ac
+++ b/configure.ac
@@ -975,25 +975,6 @@ fi
AM_CONDITIONAL(HAVE_MYHOSTNAME, [test $have_myhostname = yes])
#
--
-AC_ARG_WITH(firmware-path,
- AS_HELP_STRING([--with-firmware-path=DIR[[[:DIR[...],
- [Firmware search path (default=)]),
- [], [with_firmware_path=])
-OLD_IFS=$IFS
-IFS=:
-for i in $with_firmware_path; do
- if test x${FIRMWARE_PATH} = x; then
- FIRMWARE_PATH=\\\${i}/\\\
- else
- FIRMWARE_PATH=${FIRMWARE_PATH}, \\\${i}/\\\
- fi
-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],
AS_HELP_STRING([--disable-gudev], [disable Gobject libudev support
@:@default=enabled@:@]),
[], [enable_gudev=yes])
@@ -1215,7 +1196,6 @@ AC_MSG_RESULT([
Build Python:${PYTHON}
Installation Python: ${PYTHON_BINARY}
sphinx binary: ${SPHINX_BUILD}
-firmware path: ${FIRMWARE_PATH}
PAM modules dir: ${with_pamlibdir}
PAM configuration dir: ${with_pamconfdir}
D-Bus policy dir:${with_dbuspolicydir}
diff --git a/src/udev/udev-builtin.c b/src/udev/udev-builtin.c
index fd373d0..dd44b2d 100644
--- a/src/udev/udev-builtin.c
+++ b/src/udev/udev-builtin.c
@@ -34,9 +34,6 @@ static const struct udev_builtin *builtins[] = {
[UDEV_BUILTIN_BLKID] = udev_builtin_blkid,
#endif
[UDEV_BUILTIN_BTRFS] = udev_builtin_btrfs,
-#ifdef HAVE_FIRMWARE
-[UDEV_BUILTIN_FIRMWARE] = udev_builtin_firmware,
-#endif
[UDEV_BUILTIN_HWDB] = udev_builtin_hwdb,
[UDEV_BUILTIN_INPUT_ID] = udev_builtin_input_id,
[UDEV_BUILTIN_KEYBOARD] = udev_builtin_keyboard,
diff --git a/src/udev/udev.h b/src/udev/udev.h
index 62538bc..6f0a7bd 100644
--- a/src/udev/udev.h
+++ b/src/udev/udev.h
@@ -141,9 +141,6 @@ enum udev_builtin_cmd {
UDEV_BUILTIN_BLKID,
#endif
UDEV_BUILTIN_BTRFS,
-#ifdef HAVE_FIRMWARE
-UDEV_BUILTIN_FIRMWARE,
-#endif
UDEV_BUILTIN_HWDB,
UDEV_BUILTIN_INPUT_ID,
UDEV_BUILTIN_KEYBOARD,
@@ -172,9 +169,6 @@ struct udev_builtin {
extern const struct udev_builtin udev_builtin_blkid;
#endif
extern const struct udev_builtin udev_builtin_btrfs;
-#ifdef HAVE_FIRMWARE
-extern const struct udev_builtin udev_builtin_firmware;
-#endif
extern const struct udev_builtin udev_builtin_hwdb;
extern const struct udev_builtin udev_builtin_input_id;
extern const struct udev_builtin udev_builtin_keyboard;
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 1c9488e..7d7b17a 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -98,9 +98,6 @@ struct event {
dev_t devnum;
int ifindex;
bool is_block;
-#ifdef HAVE_FIRMWARE
-bool nodelay;
-#endif
};
static inline struct event *node_to_event(struct udev_list_node *node)
@@ -465,10 +462,6 @@ static int event_queue_insert(struct udev_device *dev)
event-devnum = udev_device_get_devnum(dev);
event-is_block = streq(block, udev_device_get_subsystem(dev));
event-ifindex = udev_device_get_ifindex(dev);
-#ifdef HAVE_FIRMWARE
-if (streq(udev_device_get_subsystem(dev), firmware))
-event-nodelay = true;
-#endif
log_debug(seq %llu queued, '%s' '%s', udev_device_get_seqnum(dev),
udev_device_get_action(dev),
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. --- Makefile.am | 8 configure.ac| 20 src/udev/udev-builtin.c | 3 --- src/udev/udev.h | 6 -- src/udev/udevd.c| 13 - 5 files changed, 50 deletions(-) diff --git a/Makefile.am b/Makefile.am index 50e7560..2965966 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2788,14 +2788,6 @@ libudev_core_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ -DFIRMWARE_PATH=$(FIRMWARE_PATH) -if ENABLE_FIRMWARE -libudev_core_la_SOURCES += \ - src/udev/udev-builtin-firmware.c You forgot to delete this file as well, any reason why? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
El 29/05/14 21:54, Greg KH escribió: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. --- Makefile.am | 8 configure.ac| 20 src/udev/udev-builtin.c | 3 --- src/udev/udev.h | 6 -- src/udev/udevd.c| 13 - 5 files changed, 50 deletions(-) diff --git a/Makefile.am b/Makefile.am index 50e7560..2965966 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2788,14 +2788,6 @@ libudev_core_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ -DFIRMWARE_PATH=$(FIRMWARE_PATH) -if ENABLE_FIRMWARE -libudev_core_la_SOURCES += \ -src/udev/udev-builtin-firmware.c You forgot to delete this file as well, any reason why? Oh, right. I could submit a second patch that does just that though (plus removing the item from the TODO list) -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 06:55:10PM -0700, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? My chromebook with kernel 3.4. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
2014-05-30 3:55 GMT+02:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? Debian Wheezy does ship with 3.2 and we do provide backports of newer systemd versions of it. It also simplifies dist-upgrades if one can still boot with the old kernel in case the new one fails to boot for whatever reason. So +1 for keeping it. As Zbiginiew said, the maintenance cost is basically zero. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 03:59:39AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 06:55:10PM -0700, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? My chromebook with kernel 3.4. Why can't you update your kernel to a modern release? And why would you want to run a new systemd on such an obsolete kernel? greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 04:10:48AM +0200, Michael Biebl wrote: 2014-05-30 3:55 GMT+02:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? Debian Wheezy does ship with 3.2 and we do provide backports of newer systemd versions of it. You update systemd but you don't update the kernel? How does that make any sense? greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 07:26:47PM -0700, Greg KH wrote: On Fri, May 30, 2014 at 04:10:48AM +0200, Michael Biebl wrote: 2014-05-30 3:55 GMT+02:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? Debian Wheezy does ship with 3.2 and we do provide backports of newer systemd versions of it. You update systemd but you don't update the kernel? How does that make any sense? You install the new kernel, but you have to reboot before it is useful for anything. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
2014-05-30 4:32 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. Keeping the userspace firmware loader for a little longer costs us nothing and simplifies things for downstreams. So let's be nice to them. I don't see a good reason to rush the removal of the userspace firmware loader. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? Keeping the userspace firmware loader for a little longer costs us nothing and simplifies things for downstreams. So let's be nice to them. I don't see a good reason to rush the removal of the userspace firmware loader. Why not just port the in-kernel firmware loader to those kernel versions? That solves more problems than sticking with this code does... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 07:51:29PM -0700, Greg KH wrote: On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? It should. I'd hardly call Debian a random distro. They are bound to have lots of issues with the conversion to systemd as the default on their wide range of supported systems. Keep such compatibility stuff around just makes things easier for everyone. Even for us, the cost of maintaining some ifdef-ed code is lower than handling the additional bug reports from people who compile their own systemd. Keeping the userspace firmware loader for a little longer costs us nothing and simplifies things for downstreams. So let's be nice to them. I don't see a good reason to rush the removal of the userspace firmware loader. Why not just port the in-kernel firmware loader to those kernel versions? That solves more problems than sticking with this code does... This doesn't readily solve the problem with requiring lock-step upgrades. You first have to deploy the updated kernel, then install newer systemd. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 05:00:34AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 07:51:29PM -0700, Greg KH wrote: On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? It should. I'd hardly call Debian a random distro. It's a slow moving distro. If it takes 5 years for their next stable release, why should we be forced to maintain code that no one else uses? They are bound to have lots of issues with the conversion to systemd as the default on their wide range of supported systems. Keep such compatibility stuff around just makes things easier for everyone. Even for us, the cost of maintaining some ifdef-ed code is lower than handling the additional bug reports from people who compile their own systemd. Then it could be made into a simple patch for those distros that require obsolete kernels :) Keeping the userspace firmware loader for a little longer costs us nothing and simplifies things for downstreams. So let's be nice to them. I don't see a good reason to rush the removal of the userspace firmware loader. Why not just port the in-kernel firmware loader to those kernel versions? That solves more problems than sticking with this code does... This doesn't readily solve the problem with requiring lock-step upgrades. You first have to deploy the updated kernel, then install newer systemd. You can install a new systemd then say that no more firmware loading will happen until you reboot with your new kernel that you install afterwards. As firmware loading is usually a boot-only event, or a add a new device event, I don't see that as a major restriction, do you? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
2014-05-30 6:02 GMT+02:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 05:00:34AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 07:51:29PM -0700, Greg KH wrote: On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? It should. I'd hardly call Debian a random distro. It's a slow moving distro. If it takes 5 years for their next stable release, why should we be forced to maintain code that no one else uses? As a responsible and serious upstream project I expect us to not gratiously break our downstream users, especially if it can be easily avoided. And as already said, the maintenance cost is basically zero. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
El 30/05/14 00:17, Michael Biebl escribió: As a responsible and serious upstream project I expect us to not gratiously break our downstream users, especially if it can be easily avoided. And as already said, the maintenance cost is basically zero. So your argument is that we should keep code that nobody should use, because a particular distribution might need to run on ancient unsupported kernels ? well, This is not a Systemd/udev problem but Debian's one and they should carry full burden for doing insane things. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
