drm
in [Kernel]
|
From: Alan Cox on 11 Dec 2009 07:50 On Fri, 11 Dec 2009 07:45:41 -0500 tytso(a)mit.edu wrote: > On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote: > > > > Well the main thing was I wasn't mean to discuss possible legal issues > > and still don't have permission, you know as well as I do once lawyers are > > involved you have to keep out of things until they deal with them. > > The thing which really surprises me is that if there are legally > dubious issues, why on *earth* did Red Hat allow Fedora to ship said > code? The thing which really surprises me is that if there are legal questions involved why on *earth* do people keep asking them on public mailing lists when they know the lawyers views/opinions/decisions will not be publishable there ? Ted, you of all people know that if you want to get an answer that isn't the way to get it. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: tytso on 11 Dec 2009 07:50 On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote: > > Well the main thing was I wasn't mean to discuss possible legal issues > and still don't have permission, you know as well as I do once lawyers are > involved you have to keep out of things until they deal with them. The thing which really surprises me is that if there are legally dubious issues, why on *earth* did Red Hat allow Fedora to ship said code? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 11 Dec 2009 10:40 On Fri, 11 Dec 2009, Jeff Garzik wrote: > > F11 uses nouveau here. It is actually a pain to get 'nv' going as an > alternate -- bugs have been filed. Makes kernel dev more difficult for me. I > was actually told, by Fedora people, that I should be hacking on the Fedora > (rpm-based) kernel, rather than a 100% upstream kernel like I have been > hacking/booting for the past decade, as a result of this setup (needing > nouveau kernel support, thus needing Fedora rather than upstream kernel). Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the wrong people - it's just that the actual driver authors aren't the ones that violated any rules), I do have to give kudos for the fact that the F12 situation seems to be much better. These days, what you can do is basically do all development (assuming it's not nouveau development) in the upstream kernel, and then you just have a separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff into. That tree/branch will be a mess of random merges-of-the-day, but you'll never push it out to anybody anyway, so nobody cares. And building that messy merge tree will get you a working setup without any extra steps - a simple "make modules_install ; make install" will JustWork(tm). So it's much more straightforward than it used to be (you had that separate tree that you could build modules in), you can basically build things exactly the same way you are supposed to do things _anyway_ if you have experimental branches etc and want to build in a temporary merged tree (even if you're not actually ready to merge it all and still want to keep the branches separate). Of course, it's a good thing that it's easier in F12, because in F11 if you forgot to build the nouveau stuff, it would just fall back on the VESA FB setup - you had a working system, it was just very slow X. You could then build the nouveau modules you forgot about, and re-start X. That "oops, I forgot" case seems to no longer work at all in F12 - if I build without Nouveau on my nvidia machine, the kernel will boot, but I will have neither working X _nor_ a working text login. So there's no way to even build the modules and fix it up - you have just to re-boot back into an old kernel. Very annoying for bisection. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Garzik on 11 Dec 2009 12:50 On 12/11/2009 10:28 AM, Linus Torvalds wrote: > > > On Fri, 11 Dec 2009, Jeff Garzik wrote: >> >> F11 uses nouveau here. It is actually a pain to get 'nv' going as an >> alternate -- bugs have been filed. Makes kernel dev more difficult for me. I >> was actually told, by Fedora people, that I should be hacking on the Fedora >> (rpm-based) kernel, rather than a 100% upstream kernel like I have been >> hacking/booting for the past decade, as a result of this setup (needing >> nouveau kernel support, thus needing Fedora rather than upstream kernel). > > Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the > wrong people - it's just that the actual driver authors aren't the ones > that violated any rules), I do have to give kudos for the fact that the > F12 situation seems to be much better. > > These days, what you can do is basically do all development (assuming it's > not nouveau development) in the upstream kernel, and then you just have a > separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff > into. > > That tree/branch will be a mess of random merges-of-the-day, but you'll > never push it out to anybody anyway, so nobody cares. And building that > messy merge tree will get you a working setup without any extra steps - a > simple "make modules_install ; make install" will JustWork(tm). At the outset, I was hoping for an even more straightforward solution: "if nouveau kernel mod not present, fall back to nv" That would work without any kernel modifications at all. But the answer came back as "if you run Fedora, run a Fedora kernel, otherwise don't expect anything to work" My experience directly contradicts claims of "upstream first" policy, both in code and attitude. I am looking into doing the git tree merge you suggest right now.... I didn't know that was an option, given ongoing API changes. That would make my life quite a bit easier. As you note, anything graphics is _glacially_ slow due to vesa fallback, when using a 100% upstream kernel. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Pages: 1 2 3 4 5 6 7 Prev: upstream regression: slob hang Next: WARNING: at fs/notify/inotify/inotify_fsnotify.c:129 |