[elrepo] Problem with CUDA since 331.67.elrepo

Phil Perry phil at elrepo.org
Sat May 3 08:47:00 EDT 2014


On 03/05/14 00:38, Michael Lampe wrote:
> It's your decision, you are the maintainer. I'll confine myself therefore
> to technical aspects.
>
> 1) Packaging a piece of software also means to adapt it to how things work
> in a specific distribution. So one would expect that permissions for the
> nvidia devices reproduce the logic of the distribution for dri devices.
>   (Principle of least surprise.)
>

This FAQ (7.1):

http://uk.download.nvidia.com/XFree86/Linux-x86/331.67/README/faq.html

documents the default attributes nvidia-modprobe uses for creating 
device files and how to change those default values. Would you suggest 
changing these default values, and if so, to what?

> 2) Of course nvidia-modprobe works. It's suid root. It will create the
> device files and change permissions on the fly so that everyone gets
> through. No problems are to be expected, it's a real wheel.
>
> 3) Nnvidia-modprobe now loads everything on an "is needed" basis, not only
> nvidia-uvm. Given the size of this module and that it's not really new but
> something factored out, who cares? It was there before just not singled out.
>

Fair point, the module's memory footprint is small.

> As for other distributions: Of course, I've looked around what they do.
> Rpmfusion is heading in your direction
> (minimalistic working base with least effort), those I've looked at and
> that will include nvidia-uvm also piggy-back nvidia-uvm (because it cannot
> be automatically loaded, it's linux/udev agnostic), and Debian has actually
> a working solution for option #1 in my list (just found and tested).
>
> That said I don't have any problems with you taking another approach. This
> was just an attempt to contribute something back to a package I was using
> for a long time without hassle.
>
> -Michael
>

Thanks for that :-)

OK, here's what we will do. I will add nvidia-modprobe to the package so 
that works as a fallback, as NVIDIA intended.

Then if we can come up with a way to properly handle module loading and 
device creation we can add that down the line.

Phil



More information about the elrepo mailing list