[Ksummit-2012-discuss] [ATTEND] NVIDIA education, and embedded architectures

Ted Ts'o tytso at mit.edu
Wed Jun 20 02:39:22 UTC 2012


On Tue, Jun 19, 2012 at 08:09:58PM -0600, Stephen Warren wrote:
> 
> * Within the constraints I have, what should I and perhaps other NVIDIA
> employees be contributing to in the kernel? In a Google+ comment, Linus
> noted that we have mainly been contributing patches for Tegra SoC
> infra-structure details. I'm curious what other areas people might
> expect me/NVIDIA to contribute to. I assume the issue is mainly the lack
> of open support for the graphics-related parts of our HW, but perhaps
> there's some expectation that we'd also start helping out some core area
> of the kernel too? Would that kind of thing help our image even if we
> didn't open up our HW?

Speaking very selfishly as a kernel developer if I want to run the
nvidia closed source driver on a bleeding edge kernel, it's simply
painful.   There are a number of reasons for this:

1) The packaging scheme for the nivida driver presupposes that you are
going to be using the distro packaging system, and that you want to
install the kernel, and the headers in a magic place, and then try to
get dkms working.  This is rather slow and painful, and hard to debug
when you discover random things such as the fact that the nvidia
driver build system blows up mysteriously if you have ccache enabled
(so you better disable when you're building the closed source module).

2) If there is an incompatibility between the Nvidia driver and the
latest bleeding edge kernel, it can be potentially quite a while
before I will be able to get a working driver --- and if want to test
an -rc kernel, lots of luck!

Now, maybe the answer is that kernel developers should just avoid
Nvidia laptops like the plague, and get a laptop with the Intel video
chipset.  That's going to be my personal solution with my personal
laptop, and I will likely give up trying to do kernel development and
running bleeding edge kernels on my corporate laptop which is mandated
(unfortunately) to using the Nvidia graphics card.  (And *fortunately*
my corp laptop old enough so I don't have to dick around with Optimus
support...)

But if Nvidia wants to make life easier for the kernel developers, it
would be nice if there was a git tree that was advertised as being
"potentially broken --- use at your own risk" which dropped Nvidia's
proprietary drivers into a kernel tree, and allowed a kernel developer
to build a development kernel with a binary Nvidia driver directly
into a single kernel tree.  In the perfect world, I could type "make
deb-pkg" in my kernel tree, and get a single debian binary .deb file
which contained my binary kernel as well as the nvidia.ko module.  And
it would be really nice, if by -rc3 or -rc4 it would be possible to
get an un-QA'ed version of the driver delivered as an integration into
the kernel tree, and very shortly after a 3.x kernel is released,
there is a new nvidia module released (instead of potentially waited
for the next turn or two of the release crank).

I do realize, though, that the kernel developer market is a very, very
tiny one --- even smaller than the general Linux laptop/desktop
market, and it may simply not make business sense.  But in terms of
making me feel cranky, the fact that I have to use an Nvidia graphics
board with my corporate laptop simply doesn't make me happy, because
it adds all sorts of pain to my wanting to dogfood bleeding-edge
kernels.  And so it might be cheaper, easier, and more realistic for
me to just carry two laptops around, at least until I can convince the
corp laptop selection committee to make a laptop with Intel graphics
available, or perhaps as the only choice, since most of us don't need
fancy-shamcy 3D graphics.  I'd be perfectly happy with a 2D driver
that worked with development kernels, but that also seems very
unlikely, at least today, unless we go with a non-Nvidia option.

						- Ted


More information about the Ksummit-2012-discuss mailing list