[Nix-dev] Re: Re: Re: udev 151

[Tony White]

On 16 April 2010 19:18, Yury G. Kudryashov <urkud+nix at ya.ru> wrote:
> Tony White wrote:
>
>> On 15 April 2010 18:59, Yury G. Kudryashov <urkud+nix at ya.ru> wrote:
>>> Hi!
>>>
>>> First of all, I talked upstream, and they don't want to search in
>>> getenv(something). OTOH, they will accept a patch that will add
>>> configure- time option "--with-firmware-path".
>>>
>>> My proposal:
>>> 1. write this patch (will do).
>>> 2. set --with-firmware-path=/var/lib/udev/firmware
>>> 3. nix system expression creates /nix/store/hash-firmware with all needed
>>> firmware files.
>>> 4. udev job creates symlinks /nix/store/hash-firmware into
>>> /var/lib/udev/firmware.
>>>
>>>
>> Hi all,
>> Sigh.
>>> Do you want to write a patch and maintain it forever?
>> No. I would kindly like to request that you maintain the current
>> functionality if at all possible.
> This was possible only because it was simple to patch old firmware.sh to add
> this functionality. This was never supported upstream.
>>> If you need some impure path, we can add ONE standard impure path
>>> (/root/test-firmware or /lib/firmware) to --with-firmware-path argument.
>>> Note that adding another argument will require full rebuild of all
>>> packages that depend on udev (for example, xorgserver).
>> There you go. You've answered the question and my concern.
>> Also, so what if it issues a rebuild. It is a big change, it's
>> upstream's "fault" If anything and you have volunteered to do the work
>> that will smash the bug that they have created when they have chose to
>> ignore the good programming practice of using pure paths.
> They were never use "pure" paths. And now they're ready to use pure path.
> They just want to hardcode them at build time. We can use /roote/test-
> firmware:/var/lib/udev/firmware and symlink /var/lib/udev/firmware to
> /nix/store/hash-firmware at job start.
>
>> At least they are willing to take a patch, many wouldn't and the
>> "maintain it forever" Nonsense could still have happened (Maybe.) They
>> still have to accept your patch and you still have to write it but I
>> do have every confidence that you can make it work.
> It is already written. I will fix a few typos in the patch, and they'll
> accept it.
>
>> The low level stuff that is replacing hal is going to be need to be
>> added to NixOS by someone in the future if we would like to use
>> xserver 1.8 (Something called upower and udisk or something) And that
>> will definitely trigger a big rebuild.
> I have some ideas wrt xserver 1.8. Will write them later. It is not ready
> yet.
>> So why not two paths, if possible, it goes in stdenv updates and gets
>> merged when everyone is fully aware that a big rebuild will take
>> place, so then there isn't a problem with it causing a fuss.
> When udev-152 will be out with my patches, I'll add it as udev152.
>> Have I missed something or is stenv updates not being used for exactly
>> that purpose?
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>

Hi Yury,
>This was possible only because it was simple to patch old firmware.sh to add
>this functionality. This was never supported upstream.

>They were never use "pure" paths. And now they're ready to use pure path.
>They just want to hardcode them at build time. We can use /roote/test-
>firmware:/var/lib/udev/firmware and symlink /var/lib/udev/firmware to
>/nix/store/hash-firmware at job start.

Until kernel.org decided that /lib/firmware was to be the exact
location of search for all firmware blobs in 2.6.27 :
http://kernelnewbies.org/Linux_2_6_27#head-a1eaa0eeec567ae80d95dedf354e3663ae03f76b
firmware could be loaded from anywhere, as long as it's location was
made known to the driver which required the loading of said firmware.

So it was only about a year and a half ago they made that change.
Until then, you could use whatever path you liked. You just told each
driver where to load the firmware from.
Hard coding static paths into the kernel and or udev is new(ish) for
firmware and I'm just saying it's a rubbish idea without your patch to
be able to specify the location along with it.

Good luck sorting this, I'm sure you will.

Thanks,
Tony