[systemd-devel] [PATCH] Drop the udev firmware loader

[Greg KH]

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