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

[Samuli Suominen]

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