Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 05, 2010 at 08:30:38AM -0800, Linus Torvalds wrote: On Fri, 5 Mar 2010, Daniel Stone wrote: FWIW, Option ModulePath in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. The thing is, Xorg has - and I think for _very_ good reasons - deprecated using xorg.conf at all. So most people don't even have one (I certainly don't), and wouldn't know how to create one in the first place. Most people don't know how to bisect the kernel, either. :) xorg.conf hasn't at all been deprecated, beyond autoconf and xorg.conf.d. The goal was to ensure that no-one needed an xorg.conf _by default_, which I can quite safely say we've since achieved, but xorg.conf(.d) remains as the way to tell the server your non-default requirements. Anyway, badly OT here, so. Cheers, Daniel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
They want the benefits of lots of testers, without wanting to be courteous to those testers. Except for the small rather important detail that the Nouveau developers didn't ask for it to be merged in the first place. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 05 Mar 2010 18:04:34 +0200, Daniel Stone said: So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. Amen to that. I can remember the X10.4-X11 conversion in 1987. And a heck of a lot of source-level stability since then (even with the libX11 getting redone with libxcb under it. 23 years and still going strong is one hell of a good run for an ABI. pgpWWcYO5fyi6.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Sat, Mar 06, 2010 at 08:52:35PM +, Alan Cox wrote: They want the benefits of lots of testers, without wanting to be courteous to those testers. Except for the small rather important detail that the Nouveau developers didn't ask for it to be merged in the first place. *Someone* on the Red Hat/Fedora team made the decision to make it available on a very popular distribution to get more testing. And they did it without putting in the necessary versioning so that kernel testers could test upstream kernels. That, in my book, is an anti-social thing to do. Fedora isn't alone, of course; Ubuntu does this as well, and worse yet, with proprietary binary drivers. But just because Ubuntu does something worse, doesn't mean that Fedora should get a free pass for what they did. - Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Sat, Mar 06, 2010 at 11:28:16AM -0800, Linus Torvalds wrote: On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get stable . F*ck me, but people are being dense. Nah, they're just being lazy, selfish b*stards, that's all. :-( They want the benefits of lots of testers, without wanting to be courteous to those testers. - Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-03-05 22:51 schrieb ty...@mit.edu: On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: If distros want to run weird experiments on their users, let them! Sure, sometimes bad things happen, but sometimes good things happen too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut, Plymouth, the list goes on and on. So what distro would you recommend for people who want to do kernel development, do kernel testing, and do kernel bisects to help us find bugs? Are you basically saying, Kernel people shouldn't use Fedora? So what should we use instead? It's been Kernel people shouldn't use Nvidia ever since I started tinkering with device drivers for Linux. Of course there's hope that nouveau will one day change that, but we're obviously not quite there yet. Jm2c Tilman -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRmMIACgkQQ3+did9BuFvPcgCfesxRGK/XabLxAEY143aDYwdN Z7EAnjAbZKyUutNfzl9enda05vJLSRDV =e26J -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Hi, On Thu, 2010-03-04 at 10:43 -0800, Linus Torvalds wrote: it difficult to have some libdrm that can handle both versions. You shouldn't expect, by now, upgrade drm kernel without update libdrm or at least recompile libdrm. So when you saw a error message driver nouveau 0.0.n+1 and have 0.0.n is completely right. Is not a perfect world, but as talked on xorg mailing list, some time ago, we do not have resources to test it in all versions. Is better focus on just one combination. Best regards, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: You shouldn't expect, by now, upgrade drm kernel without update libdrm or at least recompile libdrm. Why? Why shouldn't I expect that? I already outlined exactly _how_ it could be done. Why are people saying that technology has to suck? So when you saw a error message driver nouveau 0.0.n+1 and have 0.0.n is completely right. No. It's _not_ right. The code knows what is wrong. Considering it a fatal error is _stupid_ and bad technology, when it could have just fixed it. Is not a perfect world, but as talked on xorg mailing list, some time ago, we do not have resources to test it in all versions. Is better focus on just one combination. This is not about testing all versions. It's fine to have just one combination. But why the hell doesn't it _load_ that one combination instead of just dying? IOW, there is a check for a version. It could - instead of dying - just dlopen() the right version instead. Why are people making excuses for bad programming and bad technology? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get stable . -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get stable . F*ck me, but people are being dense. With my suggestion, people could change the API _more_, because it wouldn't be as painful. This is not about change the ABI or not. This is about since you change the ABI, do it _well_, so that it doesn't hurt people as much. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 03:53:32PM -0800, Linus Torvalds wrote: Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded X and kernel must always change in lockstep. Frankly, I completely agree with you. This kind of shit makes it extremely difficult for users to run, say, 2.6.33 on F-12 without us doing a backport. Thankfully Ben takes care of that for me, usually, by keeping nouveau up to date with upstream in the various Fedora's, but it's still a set of shackles that I'm pretty sure none of us want. (Not only that, but it means if you update, you may need to do a full reboot before you can start X again, which is pretty disappointing.) For example, right now, Fedora 11's 2.6.30 kernel has nouveau 12, with nouveau 12 userspace. For Fedora 11's 2.6.32 kernel, instead of updating the userspace stuff, I forward ported the old DRM entirely, bringing with it whatever bugs it had, simply because DRM is such a nightmare. It's already impossible to run Fedora 13's 2.6.33 kernel on 12 since Ben put the nouveau git changes for the new ABI in there already. So we'll have to drop those from the F-13 2.6.33 for the F-12 2.6.33... This situation /sucks/ for users. Personally, I think we committed to a stable update ABI when nouveau got a MODULE_DEVICE_TABLE and started binding by default. But hey, I'm just the kernel maintainer, and I didn't pipe up then, which was my mistake. If we're going to ram something at users by default, we should at least try to guarantee that they'll be able to restart X and have things continue to work. That said, whether you think it's a lame excuse or not, staging was clearly labelled as buyer beware. I'm personally sorry that you got burned by nouveau on Fedora both these times, but we're really just trying to help, and not hinder things. (Maybe I should commit a patch to rip out the module aliases for nouveau, but I suspect I'd have more people screaming for blood that way. Sigh.) regards, Kyle -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 4:41 PM, Linus Torvalds torva...@linux-foundation.org wrote: And if we end up having people bisecting back and forth, I will hate that f*cking nouveau driver even more. Would it help to tag the flag day commit? At least that would make it trivial for bisecters to see whether each step in a bisection contains the commit or not. Generalizing that ... perhaps there could be a way to tell git that some set of tags represent flag days, so it could warn in any bisection if the set of included flag days changes. -Tony -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/04/2010 01:32 PM, Jeff Garzik wrote: On 03/04/2010 02:04 PM, Matthew Garrett wrote: Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. Shipping it as the default Fedora driver for NVIDIA hardware makes that text largely irrelevant. Indeed, that text isn't really reconcilable with the fact that the driver is being used by default in a stable distro release. (Why do people keep forgetting the whole upstream development thing?) Jesse said Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. but when it is the default driver, it is the default _production_ driver for Fedora users, in an official, stable Fedora release. And the alternative? You said F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? I attempted to use the non-default 'nv' driver just before nouveau was merged into upstream/staging, because I wanted a development kernel that actually worked on my Fedora-based devel boxes. It was a complete exercise in frustration, requiring at least one bugzilla bug report, and ultimately resulted in failure. Advising people to use nv is pretty much a joke IMHO, it's barely above VESA in some ways. People would be more likely to use the nvidia binary driver than that contraption.. Aside from the fact that running nouveau on this machine would drive me crazy (there's no fan speed control implemented so the GPU fan screams away at maximum speed), the other big reason I can't use it is that at least until quite recently it couldn't work with upstream kernels. Unfortunately, changes like this will being that problem back.. So at this point the nvidia binary driver is the most practical solution that actually meets my needs, sadly enough.. I gave up and waiting for Linus to merge nouveau, which instantly made my life a lot easier :) Kernel hacking on Fedora, my own dogfood, has become increasingly cumbersome because of all these graphics issues. Sometimes it's just easier to test a modern kernel on an ancient distro, sadly. Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thursday 04 March 2010 18:53:32 Linus Torvalds wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane mostly speaks for) seems to want at this stage. The problem with at this stage is that the stage has apparently been on-going for several years. Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded X and kernel must always change in lockstep. And the sad part is, it would be so nice if the X server would just dlopen the right thing automatically, so that the low-level driver wouldn't even need to care. It already does the whole discover which driver to load part, wouldn't it be nice if that code had automatic versioning too, and then a low-level driver really wouldn't have to care, everything would automatically do the right thing just when the version changes. Of course, the distro would still have to make all the different versions of libdrm available to users, but now updating one wouldn't screw over the others. So if you had a known-good setup with nouveau-0.0.15, you could install a nouveau-0.0.16 thing and _know_ that it won't affect that previous install at all. And yeah, I realize that those version numbers are wrong. Normal library versioning rules about patchlevel not changing semantics are obviously broken here. But maybe the rules could even try to first start with the exact version, ie do a driver-x.y.z.so load, then a driver-x.y.so load, then a driver-x.so load and finally a driver.so load. But I guess that nothing even does that drmGetVersion() until the nouveau driver has already been loaded. Which kind of forces the low-level drivers to do any such versioning on their own. But wouldn't it be nice if something like this was done at a higher level, so that the drivers really wouldn't even need to care? Why not support a _minimal_ ABI that will always let X start with nouveau? Having X working does not mean that all forms of acceleration have to work too. If X starts, even if is slow, users can easily check logs which should have a message saying 'ABI change - upgrade your ...'. Thoughts? Ed Tomlinson -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 23:44, Ingo Molnar mi...@elte.hu wrote: * Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful ?- limits the developer base ?- limits the tester base ?- wastes time and effort. (fewer developers/testers means that while _this_ ? feature was easier to add, all your _future_ features will be a bit harder ? to do. It compounds up.) ?- so it hurts even the very developer who is most convinced that this was the ? right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. - distros just try to get the latest and most capable but still stable version. Desperately so. Often they will create a version mix that was never tested by developers in that form. They'll expose users to ABI combinations that were never really intended. They have trouble bootstrapping and stabilizing those essentially random combinations and then have trouble applying stability and security fixes. The thing is, if development has such characteristics then it's pretty clearly not 3-4 separate projects but _one_ abstract project. [*] So the 'exploding test matrix' is simply the result of: creating ABIs between 3-4 _artificial components of the same project_ and then going through developer hell living with that mistake. [**] It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. Yes that is exactly the problem we are facing. And you know what? All graphic driver devs agree on that, but there is no obvious solution. Here are the interfaces which are part of this problem: - drm interface (drm wrappers as seen from the driver, drm ioctls from the user space) - X.Org acceleration interface (EXA and friends as seen from the driver, XRender and friends as seen from the apps) - Mesa interface (Gallium or mesa driver interface from the driver, OpenGL seen from the app) Any solution will involve merging two or more components together to remove interfaces, so lets observe pairwise what could be merged and the drawbacks: - Merge DRM and Mesa drivers. Technically we could do this, but then what happens when a new OpenGL version/feature comes around? Yes, we get a new mesa interface. So we're exchanging one interface for another here. No gain. - Merge DDX And DRM driver. Same problem as before, whenever 2D interfaces changes, we have to update the DDX anyway. Again, no gain in sight. - Merge Mesa and DDX drivers. This makes sense, and this is where gallium is going by providing 2D and GL acceleration on top of a single, common gallium driver. So yes, I have hopes that this one will happen eventually, at least on non-intel
Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri 5.Mar'10 at 8:44:07 +0100, Ingo Molnar wrote: Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: I agree 100% with this! I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install and I am ready to test the bleeding edge kernel. And everytime I complained about something breaking it got fixed. Really, testing the linux kernel is a hobby for me because it is easy. Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. True! Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? If this could be done for the kernel (which from my user POV seems much more complicated), I guess it could be done with Xorg. And Linux would have more Xorg testers and be better as a whole. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/04/2010 05:59 PM, Adam Jackson wrote: On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote: # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf Never tried this part. The bug I'm assuming you're referring to is https://bugzilla.redhat.com/show_bug.cgi?id=519298 in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X server does only try the one driver before falling back to vesa, which is a bug in the fallback logic I suppose. I've (blindly) fixed that for F13 now. Thanks. Can this be put into F12 too? However, the log in that bug only shows you using the built-in autoconfig logic, and not an xorg.conf file. So, given you were talking about a kernel without nouveau, I am left to assume one of: - you didn't try writing an xorg.conf fragment - you did, and it didn't work anyway The latter case is entirely plausible, as nv is not the sort of driver that gets a lot of love, but I'm not aware of any open bugs about gf9800 in particular in nv. The latter... would modeset in grub interfere, perhaps? Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI - its called not RTFM. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 05 Mar 2010 11:00:30 +0100, Carlos R. Mafra said: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? Feel free to do so. Note that you'll hit 2 problems: 1) In the kernel, the sysadmin can almost always get away with saying I have no XYZ devices or I only have ext4 filesystems or similar choices, and have the resulting kernel still support basically all the syscalls (unless you start going into CONFIG_EMBEDDED and doing some *major* surgury). Over on the X side of the fence, there aren't as many options that don't involve dropping major chunks of the functionality. You *sure* that nothing on your system depends on the XRandR extension? ;) 2) Lately, the X server is *already* highly modular and different components built from different source trees. Note that the base X server is only about half the size of the kernel RPM - there really isn't much left to trim out of the base server anymore. ncftp ...velopment/source/SRPMS dir kern* xorg* -rw-r--r--1 263 263 66965350 Feb 26 18:03 kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm -rw-r--r--1 263 26344300 Feb 27 01:39 xorg-sgml-doctools-1.1.1-4.fc12.src.rpm -rw-r--r--2 263 263 2229508 Feb 11 02:23 xorg-x11-apps-7.4-10.fc13.src.rpm -rw-r--r--1 263 263 8250097 Feb 27 00:06 xorg-x11-docs-1.3-6.fc12.src.rpm -rw-r--r--1 263 263 9718 Feb 27 03:27 xorg-x11-drivers-7.3-13.fc12.src.rpm -rw-r--r--2 263 263 263291 Feb 5 21:40 xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm -rw-r--r--2 263 263 271426 Feb 5 23:03 xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm -rw-r--r--1 263 263 293991 Feb 27 01:02 xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 247603 Feb 5 19:49 xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm -rw-r--r--1 263 263 273849 Feb 26 20:22 xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm -rw-r--r--1 263 263 475771 Feb 19 00:50 xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm -rw-r--r--1 263 263 354400 Feb 27 01:17 xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 296790 Feb 5 16:10 xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm -rw-r--r--2 263 263 257700 Feb 5 19:48 xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 260227 Feb 5 16:26 xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm -rw-r--r--2 263 263 537577 Feb 5 21:59 xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm -rw-r--r--2 263 263 254313 Feb 9 13:19 xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm -rw-r--r--1 263 263 252387 Feb 17 05:13 xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm -rw-r--r--2 263 263 608480 Feb 5 23:07 xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm -rw-r--r--2 263 263 361698 Feb 5 21:40 xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm -rw-r--r--2 263 263 244962 Feb 9 13:48 xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm -rw-r--r--2 263 263 289677 Feb 5 22:38 xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 281904 Feb 5 20:33 xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm -rw-r--r--1 263 263 978993 Feb 12 07:15 xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm -rw-r--r--2 263 263 305926 Feb 5 19:26 xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm -rw-r--r--2 263 263 296974 Feb 5 19:22 xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm -rw-r--r--2 263 263 492204 Feb 5 20:02 xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm -rw-r--r--2 263 263 427579 Feb 5 20:39 xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm -rw-r--r--2 263 263 318263 Feb 9 13:52 xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm -rw-r--r--2 263 263 254590 Feb 5 20:17 xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm -rw-r--r--2 263 263 290495 Feb 5 22:02 xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm -rw-r--r--2 263 26391334 Feb 18 16:59 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm -rw-r--r--2 263 263 449803 Feb 9 12:19 xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm -rw-r--r--2 263 263 475028 Feb 9 12:26 xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm -rw-r--r--2 263 263 248668 Feb 9 12:27 xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm -rw-r--r--2 263 263 280184 Feb 5 22:08 xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm -rw-r--r--2 263 263 424771 Feb 5 19:36 xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm -rw-r--r--2 263 263
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 08:44:07AM +0100, Ingo Molnar wrote: Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. - distros just try to get the latest and most capable but still stable version. Desperately so. Often they will create a version mix that was never tested by developers in that form. They'll expose users to ABI combinations that were never really intended. They have trouble bootstrapping and stabilizing those essentially random combinations and then have trouble applying stability and security fixes. The thing is, if development has such characteristics then it's pretty clearly not 3-4 separate projects but _one_ abstract project. [*] So the 'exploding test matrix' is simply the result of: creating ABIs between 3-4 _artificial components of the same project_ and then going through developer hell living with that mistake. [**] It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. Ingo [*] I realize that it's possibly hard for Xorg to merge with mesa and the kernel for license reasons, but my technical observation still stands. [**] I realize that modularization and many small packages were a clear advantage when we were still all downloading bits via 14.4k modems, but in this day and age of megabit connections that has become a non-issue. Rampant over-modularization and the resulting loss of focus on the end result (and the resulting explosion of a test matrix) is hurting us _far more_ than the disadvantages of any monolithic could ever hurt. We are seeing the proof of that all day with a 10+ MLOC kernel. Tying kernel, libdrm, X and mesa together 1-1 is not going to help anybody. When thinking along the same line of your reasoning, the answer is unifying graphics driver stacks, which requires increased modularization (in libdrm and mesa): one big abstract project. All of X.org, libdrm, drm, mesa/dri, mesa/gallium, all have relatively stable interfaces as they are supposed to support multiple (from 3 (libdrm) to ~50 (Xorg)) drivers. It's driver internal interfaces that are highly volatile, as it is easy to adjust all parts inside the same graphics driver stack, especially since the same developers know all these parts and it supports the same hw. On top, graphics driver are special, they are as complex and diverse as the hardware. So, graphics driver stacks can currently have up to 7-8 pieces spread everywhere: kernel drm driver, firmware, libdrm driver, Xorg driver, 2 mesa drivers, 1-2 media acceleration libraries. All spreading inherently unstable interfaces everywhere. Graphics drivers will always be complex, and buggy and unstable, but we should try to encapsulate some of that mess in a way that makes sense. I had a talk on FOSDEM about this which was very warmly received by some; the slides are here http://www.phoronix.com/scan.php?page=articleitem=fosdem_2010_unificationnum=1 Luc Verhaegen. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
So man up, guys. Face the problem, rather than say well, it's staging, or well, we can revert it. Neither of those really solve anything in the short run _or_ the long run. Linus stop and think for a minute instead. Maybe a timeline would help Nouveau development starts People ship highly experimental stuff for testers Code gets to the works but really needs a clean up point Linus demands it is merged Linus gets it merged as staging Developers start doing the cleanup Linus throws a tantrum because they did the cleanup after merge *YOU* forced the early merge (rightly or wrongly) *YOU* effectively created the API break problem So blaming other people is quite out of order. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 04 Mar 2010 14:32:02 -0500 Jeff Garzik j...@garzik.org wrote: On 03/04/2010 02:04 PM, Matthew Garrett wrote: Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. Shipping it as the default Fedora driver for NVIDIA hardware makes that text largely irrelevant. Why ? Fedora isn't special, Fedora is just a distribution that uses the Linux kernel. If Fedora turns on staging drivers then Fedora has to accept that stuff breaks and manage that expectation with its users. Staging is not and has not been API stable. If staging is going to be API stable then it it useless and may as well be deleted. In this case Linus is just a random Fedora user having a distro problem. I don't even see what it has to do with linux-kernel. The libdrm problem and difficulty using Fedora libdrm with current upstream kernel is a Fedora problem not a kernel problem. The kernel staging tree is unstable for API. Whether thats the Nouveau guys breaking Fedora, submissions to network drivers breaking/removing bogus APIs in stuff being cleaned up - whatever then thats how the cookie crumbles. DRM has just made it all horribly more visible because the libdrm/kernel stuff has such a complex and closely tied interface. Serious discussion point perhaps should be: is the libdrm so close to the kernel it ought to be in the same git tree ? Alternatively does it need to be easier to have multiple Nouveau libdrms autoselected according to the kernel side versioning. ELF library versioning is not rocket science and both the old and new libraries exist and can be installed so all the bits are present except for the wrapper to load the right sublibrary yes ? Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Why does the X community not understand simple library versioning? Why does Linus Torvalds not understand the Kconfig of his own staging directory ? Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 12:38:34 + The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI - its called not RTFM. All of this RTFM and what directory the noveau driver is sitting in is entirely irrelevant Alan. If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. It's about the tester base, and this breakage shrinks the tester base considerably. Or do you want the kernel tested by less people? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. It's about the tester base, and this breakage shrinks the tester base considerably. Or do you want the kernel tested by less people? I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful working machines. So - do you want Linux used by a lot less people, and to have no Nvidia driver ? See - its all about viewpoints. Do you think screaming at people who did no wrong increases the kernel developer and testing base ? No I thought not. To be honest the big thing I object to here is certain people who should know better behaving like small children. Not just in the sense of throwing their toys around because mummy didn't buy them the right sweetie but in not thinking about how other people see the problem and their actions. - Fedora merged the stuff to make it work and to improve life for lots of users. Good intent, rational logical behaviour - Linus asked for it to be merged and was warned about the ABI. He did that for good, sound reasons. - The developers accepted the merge to staging so they could fix the ABI later, they made that clear - again all good sound intentions - The ABI change and clean up was done - again good sound intentions, rational behaviour - Linus then threw a tantrum. He's right there are issues about how user migration should be handled but he didn't need to go screaming at the DRM people (not their fault), Fedora (who had good sensible goals in what they did) or the Nouveau people (who told him what was going on well in advance and did exactly what was asked of them before) Firstly he's being hypocritical (he keeps saying he doesn't want to control distributions, he even refused to allow ext2 to be merged *until* Red Hat shipped it), he was told clearly, and staging is for unfixed ABIs. Secondly he's shouting at people who all did a right thing, which only produces bad feelings. All that was needed was a Hey guys, I know its in staging but this is going to be a problem, can we either fix back compatibility or have some kind of migration policy and the tools so I can test it - otherwise I can't merge this No blaming, no tantrums, no judgemental comments from a single viewpoint. A collection of good intentions produced a problem. It happens all the time, screaming and blaming may be how politicians sometimes behave but we can surely do better ? Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 15:09:34 + I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful working machines. I think Fedora were right to merge it, and I think it was proper to merge it into the upstream kernel. But I also think the large size of that userbase should have been respected by doing the right thing here, and that means not making it so hard for Fedora users to use upstream kernels out of the box. Making the sandbox claim cuts both ways Alan. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, C. Bergström wrote: staging != stable This really is being repeated, over and over. But it's irrelevant. It's irrelevant because it's just a bad _excuse_. That driver is used in production environments. That's _reality_. The whole staging thing is nothing more than a meaningless word. And no, staging wasn't why it was merged. The reason it was merged was that very same reality. So every time somebody mentions staging as an argument, he's missing the whole effing point. It also misses the point that the issues I've tried to bring up (bisection, testability) are real _technical_ arguments. Again, waving that staging flag is just stupid. It has nothing to do with the technical arguments, or with the reality of the situation. In other words, it's not just an excuse, it's a _meaningless_ excuse. It's a red herring. It's irrelevant to the issue. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 2010-03-05 at 06:37 -0800, David Miller wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 12:38:34 + The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI - its called not RTFM. All of this RTFM and what directory the noveau driver is sitting in is entirely irrelevant Alan. If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. It's about the tester base, and this breakage shrinks the tester base considerably. Or do you want the kernel tested by less people? On the bright side, all this hubbub sends a very positive message to the noveau development crew. Folks, your work is important. I'd be proud as a peacock :) -Mike -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra crmaf...@gmail.com wrote: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? You must not follow X development at all. His name is Keith Packard. Matt Turner -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:17:54 +0200 On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. That's doesn't work, and it never will. First of all, if we didn't merge the driver Fedora users wouldn't be able to test the upstream kernel at all. And if you think things through, there is one and onle one set of actions that would have made things work properly. And that's merge the driver upstream and not break user visible APIs. In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. Consider if it didn't go upstream and I want to do upstream kernel development, ok so I patch the noveau-of-the-moment into my upstream tree. Six months and 10 DRM library updates later I go back and try to boot that kernel. And it's not going to work. So if the user visible APIs are changed in any set of situations (upstream merged, not upstream merged, etc.) things can end up breaking. Ergo, you simply can't sanely do it at all. You have to have a compatability story when you change these things. Personally I wouldn't have ever committed to that user visible APIs can break cause it's in -stable. Because that's complete garbage. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Personally I wouldn't have ever committed to that user visible APIs can break cause it's in -stable. Because that's complete garbage Staging has to have the no API rules. Read some of the stuff in there to understand why or apply about 30 seconds of thought to what it would mean to you. There are staging drivers using old wireless layers. If you say that no API can be broken from staging then you will have to put the old wireless compatibility into your network code forever. Does that fill you with joy, light and happiness ? Whether nouveau should ever have gone into staging is a different question. I don't personally think its all as clear cut as it might seem. Quite a few distributions ship whacky wireless drivers with old API's as the choice is that or nothing. They manage the user expectation and they deal with the drivers moving from one wireless stack to the other and mostly successfully hide it in userspace. The differences here appear to be - Having no video is more annoying than having no wireless - Userspace failed to hide it (so maybe its not a kernel ABI problem but a failure to anticipate the need for versioned libdrm and the importance in some eyes of supporting the kernel.org kernel - which like it or not is a corner case for distro *users*). - The box it broke happened to belong to Linus but that doesn't really require tantrums or fingerpointing to fix, particularly when its only the combination of a set of decisions and misunderstandings by Linus, Fedora and the Nouveau developers together that combined to create the mess. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Hi, On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. That's doesn't work, and it never will. First of all, if we didn't merge the driver Fedora users wouldn't be able to test the upstream kernel at all. And if you think things through, there is one and onle one set of actions that would have made things work properly. And that's merge the driver upstream and not break user visible APIs. Ah, argument by assertion. That's my most favourite thing to deal with on a Friday evening. Wait, did I say 'most'? I meant least. In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. That's a matter for the Fedora kernel team; for better or worse, they made the choices they did, which included going through all the relevant pain to support this. They didn't consider it suitable for upstream because they didn't think everyone else should be forced to endure that pain. Now it's upstream and everyone's being forced to deal with it. Great. Consider if it didn't go upstream and I want to do upstream kernel development, ok so I patch the noveau-of-the-moment into my upstream tree. Six months and 10 DRM library updates later I go back and try to boot that kernel. And it's not going to work. nouveau isn't going to work, no. vesa and nv remain unaffected; it's not like it's some kind of catastrophic failure whereby booting it eats your disk and gropes your sister-in-law. So if the user visible APIs are changed in any set of situations (upstream merged, not upstream merged, etc.) things can end up breaking. Correct! Ergo, you simply can't sanely do it at all. You have to have a compatability story when you change these things. You cannot sanely do it at all in an upstream kernel, no. Personally I wouldn't have ever committed to that user visible APIs can break cause it's in -stable. Because that's complete garbage. I guess you mean staging here; either way, that's a matter for you guys to deal with. I guess the upshot here is 'if you merge something against the developers' wishes by screaming at them until they comply, they repeatedly tell you that it's not API-stable, you merge it, and it changes API, then joke's on you'. If the result of this ridiculous mess is that anything merged to staging is never allowed to change userspace ABI ever, then great. As I said, it's really not my problem. Either way, fuck it, it's Friday. To the pub. Cheers, Daniel pgpl2HOShne3z.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote: On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra crmaf...@gmail.com wrote: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? You must not follow X development at all. His name is Keith Packard. Except that if you look at X lately, you'll realise that we do not have the resources to even come close to being able to do this properly. We struggle to support what we have already today, and we've still been hoping to create a real API, instead of the sad joke that is /usr/include/xorg/*.h, for the last few years. But we don't have enough people (or at least enough people who aren't busy with the other parts of their day jobs, or kids, or burnout, or whatever) to do it. I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. Cheers, Daniel pgpB62OHx1v5N.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. Cheers, Daniel pgp6wYP1dGLlT.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote: On 03/04/2010 05:59 PM, Adam Jackson wrote: in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X server does only try the one driver before falling back to vesa, which is a bug in the fallback logic I suppose. I've (blindly) fixed that for F13 now. Thanks. Can this be put into F12 too? Sure, why not. - you didn't try writing an xorg.conf fragment - you did, and it didn't work anyway The latter case is entirely plausible, as nv is not the sort of driver that gets a lot of love, but I'm not aware of any open bugs about gf9800 in particular in nv. The latter... would modeset in grub interfere, perhaps? It's not going to do anything if you didn't build a KMS driver. It's just a kcmdline option like any other; if there's no module to honor it, then it doesn't do anything. grub doesn't have any particular KMS awareness. I'm really going to have to see an X log and dmesg from the failure mode when actually using nv to diagnose this any further. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:40:09 +0200 On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. That's a matter for the Fedora kernel team; for better or worse, they made the choices they did, which included going through all the relevant pain to support this. They didn't consider it suitable for upstream because they didn't think everyone else should be forced to endure that pain. By not merging it upstream the pain is larger not smaller. It's enabled by default, so you therefore can't test upstream kernels by default. And as I showed already, even if you jump through the hoops to make it work (building noveau from out of tree in the upstream kernel) you'll end up getting screwed when the API changes anyways. Using VESA or whatever else you've suggested is just not a reasonable alternative. You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. We're better than that. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010, Carlos R. Mafra wrote: Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. Actually, take it from me: Xorg is _pleasant_ to test these days. Ok, so that's partly compared to the mess it _used_ to be, but it's really night and day. The whole build system was so incredibly baroque and heavy that you really had to understand it deeply if you wanted to do anything fancy. And the non-fancy alternative was to just build the whole thing, which took _hours_ even on fast machines because the build system overhead was near-infinite (I dunno, maybe parallel builds could be made to work, but it took more brain-power than I could ever put into it). These days, there's a few dependencies you need to know about (I do agree that from a user perspective the thing might have been made a bit _too_ modular) but they are generally fairly trivial, and there are scripts to download all the drivers and misc utilities needed. And the modularization often works: you can often (but by no means always; it does require that the other parts are close enough and that there haven't been any major changes) just have the source code to the one driver you care about, and recompile and install just that _single_ driver. I've done it. It's becautiful when it works. And it's a major pain when you notice it didn't work, and you needed to get the whole server and libdrm trees after all, and now you're not replacing single files any more and have little idea what it will stomp on in your distro. So it really is very convenient when it works. And X doesn't have thousands of drivers like the kernel (maybe 10-15 that people care about at all, and about three or four that actually really matter), and there are seldom huge changes that affect them all, so the modularization doesn't turn totally crazy. So I can see where the Xorg people really like their new modular world. It does work, it's _sooo_ much better than the mess it used to be, and the problems are fairly manageable when they do happen. The modular approach really works very well when there aren't lots of interactions between the modules, and when the modules are few enough that it isn't a total disaster (imagine doing a change that requires changes to all drivers in Xorg, vs doing a change that requires changes to all drivers in the kernel - the modular approach simply wouldn't work for the latter case, because you'd spend all your time just chasing down external users). That said, the _one_ thing I really wish could be done would be to make it easier to install things side-by-side - and with the modularization, you really do want to do it module-by-module. One of the things that makes it so easy to test the kernel is that when you install one kernel, that doesn't affect the others, and you can go back-and-forth in testing. That's really important, because it makes testing trivial and non-scary even in the presense of issues that makes the new version unusable. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
It seems to me that Linus' technical argument is indeed being mostly ignored. While breaking the ABI is unfortunate, the real problem that Linus complained about is that you can't install several userspace versions side-by-side. This means that if you install your new kernel and userspace, reboot, and find the new kernel doesn't work for some reason, you can't just go back to the old kernel and have working X, because you just replaced userspace with a version that no longer works with the kernel that worked correctly. This is even worse for distributions that want to upgrade the kernel, because each kernel package would need to have a Depends on the exact userspace package version. Thus, the package manager would remove the older kernel when the new one is installed (since they depend on different versions of the same userspace package). If the new kernel somehow doesn't work, the user is totally screwed and must reboot from a live CD. As pointed out, in this case, it is relatively easy to solve by adding a version number to libdrm-nouveau, the X driver and the DRI drivers. X will then have to load the correct driver and give Mesa the DRI driver name with the correct version appended. It may be a good idea to do this before the new nouveau ABI gets shipped in released distributions, and with a generic mechanisms that can be used by all X/drm drivers. Workarounds are possible, such as replacing /usr/bin/X with a script that loads the correct version, or using X over /dev/fb0 (which should work fine with any DRM KMS driver, and any non-DRI framebuffer), but they shouldn't be needed. BTW, the nVidia proprietary driver also ties the kernel and userspace version in this way, and is actually worse because it replaces the X libglx.so, breaking all other drivers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it. We're better than that. If you consider the problem is with the Fedora kernel team decision to merge it into Fedora in the first place, perhaps you should have an internal Red Hat discussion about it with the people who made that decision - who I suspect see it differently. Either way the Nouveau developers don't control Fedora packaging policy, in fact the GPL licence specially ensures the control is not theirs. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 07:48:35AM -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. That's a matter for the Fedora kernel team; for better or worse, they made the choices they did, which included going through all the relevant pain to support this. They didn't consider it suitable for upstream because they didn't think everyone else should be forced to endure that pain. By not merging it upstream the pain is larger not smaller. It's enabled by default, so you therefore can't test upstream kernels by default. 'That's a matter for the Fedora kernel team'. And as I showed already, even if you jump through the hoops to make it work (building noveau from out of tree in the upstream kernel) you'll end up getting screwed when the API changes anyways. So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. Using VESA or whatever else you've suggested is just not a reasonable alternative. You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. We're better than that. Your opinion on what constitutes reasonable support is not universal, absolute truth. pgpCl9WgXtapb.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 16:02:17 + You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it. And I'm arguing not merging it upstream would be like saying the same thing. We're better than that. If you consider the problem is with the Fedora kernel team decision to merge it into Fedora in the first place For the second time Alan, I don't. I think Fedora should have merged it. I think it should be upstream. And I think the API bustage needs to be avoided. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. read() still works the same way it did 30 years ago last time I checked. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. Now, I agree that that would have been the optimal setup from a testing an user standpoint, but I think it's a bit too strong. Things don't need to be frozen, but flag-days need to be avoided. The problem with flag-days is not so much that they need new support code: downloading a new version of something like X is not a huge issue. But flag-days work both ways: it's not just that you have to download a new version, it's that you can't go _back_ either - not even a little bit. For example, I can now test my new kernel, but if it turns out that there are problems with it, I'm now officially screwed. I can't go back and rely on even the stable distro kernel, like I'm used to (ok, that _really_ didn't work, but happily I didn't remove the distro kernel, so I'll just reboot with that). And I certainly can't bisect without major problems. And Fedora can't install the new libraries, because they won't work with their own old kernels either. So it effectively causes a version freeze: it looks like F12 will simply _never_ be able to support a 2.6.34 kernel, because if they do that, then everybody who gets the new packages (and has a nvidia graphics card) will now be stuck. So flag-days really are bad. They're bad for users, they're bad for distributions, and they're eventually bad for developers too because now they lose a lot of every-day testing. Some day, F13 will come out, and the _only_ testing all the new code ever got was the (relatively small) rawhide community, and the kernel crazies who did things manually. But even if you can't guarantee backwards compatibility, if you avoid the flag-day, and can have a new version of the environment that can handle both the old and the new model, you _could_ install that on F12 (before switching kernels), and not be in that effective version-freeze. Yeah, you'll still have a dependency chain, but it will be a one-way one, so you're not stuck. As long as you have the newest vesion of whatever libraries or support, you can go back-and-forth and test development systems. And we do that for the kernel in many other respects. We require that you have a recent enough compiler, for example. So there are already lots of those one-way dependencies where we're not infinitely backwards compatible with user space, but we've been pretty good at not having flag-days. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010 16:56:10 +0100 Luca Barbieri luca.barbi...@gmail.com wrote: It seems to me that Linus' technical argument is indeed being mostly ignored. While breaking the ABI is unfortunate, the real problem that Linus complained about is that you can't install several userspace versions side-by-side. I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. All the X builds are modular, all the modular builds support --prefix= with their autogen script. ld.so supports LD_LIBRARY_PATH and the shells support PATH variables. You can replace all or almost any part of X quite easily. There is also a mechanism for versioning within DRM for a lot of stuff, and drivers use flags to make it work nicely except for devel code (which is what Nouveau is) The fundamental problem you can't solve by versioning though is the exact one here. A new kernel that requires version X of a driver won't help if the newest version you have is X - 1. Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
Hi, On Fri, Mar 05, 2010 at 07:53:46AM -0800, Linus Torvalds wrote: These days, there's a few dependencies you need to know about (I do agree that from a user perspective the thing might have been made a bit _too_ modular) Indeed, no argument here. That said, the _one_ thing I really wish could be done would be to make it easier to install things side-by-side - and with the modularization, you really do want to do it module-by-module. One of the things that makes it so easy to test the kernel is that when you install one kernel, that doesn't affect the others, and you can go back-and-forth in testing. That's really important, because it makes testing trivial and non-scary even in the presense of issues that makes the new version unusable. FWIW, Option ModulePath in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. Cheers, Daniel pgpnHb05h5vaf.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Alan Cox wrote: You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it. Alan, you're ignoring reality. This problem existed *before* nouveau was merged. In fact, it was *worse* back then. How hard is that to understand? And yes, I do actually know. Because I used nouveau for a year before it was merged. You had to use a different version of drm too, so you couldn't even just compile the nouveau tree and install just the nouveau driver (and keep the other drivers from the main tree). So the watershed moment was _never_ the Linus merged it. The watershed moment was always Fedora started shipping it. That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: Two wrong choices don't make a right. So unmerge it. That's what I told people I can do (I'd just revert that commit). Read it more strongly: drop nouveau from your tree entirely. Don't give me any not a solution nonsense about that. The problem is entirely that your expectations for interface stability [1] in your tree do not match nouveau's development model and will not for the forseeable future. Yes, they should htfu and version interfaces like real men. But they're not going to, so either enforce your rule or don't. [1] - apparently ignorable when it's inconvenient, but let's not turn this into a sysfs argument. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010 08:44:07 +0100 Ingo Molnar mi...@elte.hu wrote: It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. This is a very good point, and something we've been wrestling with in the gfx community. Awhile back we separated the X drivers from the X core; I feel this was a mistake for the reasons you mention above. It's just plain harder to fix issues when you have to rev the ABI with every change, make sure both the old/new and new/old combinations work, and generally improve things like we do inside of Linux. [*] I realize that it's possibly hard for Xorg to merge with mesa and the kernel for license reasons, but my technical observation still stands. No we don't need to merge them fortunately. With GEM and KMS we've pushed two major bits of functionality into the kernel; bits that were badly split between all portions of the stack before. With EGL, we can push a lot of what X did into Mesa. There are even some projects to make a very thin X driver or separate display server sit directly on top of Mesa + EGL, unifying things further. So I really think things are getting better here, not worse (the nouveau issue here aside). -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Alan Cox wrote: Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Alan - it seems you're missing the whole point. The thing I objected to, in the VERY BEGINNING in this thread, i the fact that the thing was done in such a way that it's basically impossible to support the old/new ABI at all! Let me quote that second email: That commit seems to _on_purpose_ try to avoid at all cost being compatible. It not only removes some old entry-points, it literally re-numbers all the ioctl numbers as it does so, apparently entirely in order to just make it difficult to have some libdrm that can handle both versions. So it's not a before the patch went upstream issue. The same issue exists _after_ the patch went upstream. The way this was done, it's apparently basically impossible for the Fedora people to push out packaged that support both the old and the new kernel. Alan, if this had been done in a way that allowed that whole old/new ABI that you mention to work, I wouldn't have been complaining so much! In other words - I've not been complaining about updating the ABI. I've been complaining about doing it in such a way that it's near impossible to go back-and-forth, because the very thing you suggest was made way way harder than it should be. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
So the watershed moment was _never_ the Linus merged it. The watershed moment was always Fedora started shipping it. That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? So why are you screaming at the DRM and Nouveau people about the breakage ? That's the bit I really don't understand. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. Sure, but each user must manually find out how to setup that, and create and test the setup himself (or happen to use a distribution that somehow eases that, if any exist). I think that Linus has a good point in saying that this should be provided by default. And ideally not just by the distribution, but upstream, so that people wanting to test bleeding edge DRM drivers (not necessarily just nouveau) can do so more easily, and beable to go back to their working setup by rebooting should something go wrong. The fundamental problem you can't solve by versioning though is the exact one here. A new kernel that requires version X of a driver won't help if the newest version you have is X - 1. Yes, but the fact that you can't have both X - 1 and X at the same time makes it worse, since for instance bisecting won't just work. Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Well, yes, but it can still be implemented in time for the next distribution releases and the lesson can be learned for similar future situations. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010 07:53:46 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 5 Mar 2010, Carlos R. Mafra wrote: Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. Actually, take it from me: Xorg is _pleasant_ to test these days. Ok, so that's partly compared to the mess it _used_ to be, but it's really night and day. The whole build system was so incredibly baroque and heavy that you really had to understand it deeply if you wanted to do anything fancy. And the non-fancy alternative was to just build the whole thing, which took _hours_ even on fast machines because the build system overhead was near-infinite (I dunno, maybe parallel builds could be made to work, but it took more brain-power than I could ever put into it). These days, there's a few dependencies you need to know about (I do agree that from a user perspective the thing might have been made a bit _too_ modular) but they are generally fairly trivial, and there are scripts to download all the drivers and misc utilities needed. Just FYI for those following this thread; testing the server and 3D drivers really isn't too much trouble these days, you can even install everything into a separate path (I usually choose /opt-gfx-test); you just need to build libdrm, mesa, xserver and your video driver (along with an input driver or tw) in that order. Then just startx -- /opt/gfx-test/bin/Xorg and put something reasonable in .xinitrc. Full instructions at http://wiki.x.org/wiki/Development/BuildingX. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 05 Mar 2010 08:06:26 -0800 (PST) David Miller da...@davemloft.net wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. read() still works the same way it did 30 years ago last time I checked. Thats disingenous as read() is a method not an interface. It's also wrong because read() and write() behaviour has changed in various ways and old code broke because of it in subtle ways. Keeping the same method behaviour would have required things like new versions of read() for 64bit files, nonblocking, mandlocks, NFS, networking, etc all of which changed the core read() behaviour. I've yet to see anyone meaningfully argue it was the wrong thing to do. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
The thing I objected to, in the VERY BEGINNING in this thread, i the fact that the thing was done in such a way that it's basically impossible to support the old/new ABI at all! What did you expect them to do. They said when you first forced a merge that they would do this. They have no contract that I am aware of to deliver you compatibility, in fact quite the reverse they said they wouldn't be. Then you attribute to malice what was done as a cleanup by people who've pointedly never to commited to a constant API yet That commit seems to _on_purpose_ try to avoid at all cost being compatible. Great way to make friends. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010, Daniel Stone wrote: FWIW, Option ModulePath in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. The thing is, Xorg has - and I think for _very_ good reasons - deprecated using xorg.conf at all. So most people don't even have one (I certainly don't), and wouldn't know how to create one in the first place. And yeah, I used to happily edit timing lines and make up non-standard modes for my monitor, but I have to admit that I never _ever_ want to touch that file ever again. Last time I tried to, it was to set DPI to be something sane, but these days X gets even that right automatically, and no longer does the insane set DPY by size of the screen thing any more. And I think all of the reasons xorg.conf is basically being deprecated are valid for this case too. Switching between kernels is - in this case, due to the whole API change - effectively the same as switching the graphics card in the machine, but without even the ability to _name_ the cards and share a xorg.conf for the two cases (not that I think that you could do different ModulePath's per display anyway). So yeah, you could switch between kernels, start out in init 3, edit xorg.conf appropriately, switch to init 5, but once you start doing that, you might as well just switch a symlink around instead - it's easier. So I don't think xorg.conf is a help. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Alan Cox wrote: So the watershed moment was _never_ the Linus merged it. The watershed moment was always Fedora started shipping it. That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? So why are you screaming at the DRM and Nouveau people about the breakage ? That's the bit I really don't understand. Umm. You _really_ haven't been following, have you? Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last time that the nouveau guys don't seem to care. And I would like to say that yes, Dave really helped me. He got me a working setup again. I thank you, Dave. It means I don't have to revert the thing, and we can hopefully make progress. That said, I do think that the Fedora people _should_ have been the ones to catch this as a problem, and pushed back a bit on the Nouveau people even before it got to me. For all the reasons I've mentioned. Even if you need to change the interface, I've actually looked at the patch in question (have you, Alan?), and I got the very strong feeling that it _could_ have been done without breaking compatibility so completely and utterly, and making it so apparently intentionally hard to have a driver that can handle both the old and the new. IOW, maybe it would have required a new nouveau_drv etc, but with a slightly less hack-and-slash approach, maybe the new one could have supported the old interfaces enough to at least limp along. For example, breaking DRM so that 3D doesn't work, but you still get basic 2D acceleration - that's _way_ more acceptable, and is likely to need a much smaller subset of the whole DRI functionality. It looks like nobody even tried. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last time that the nouveau guys don't seem to care. Ok screamed about is perhaps better wording. Why should the Nouveau guys care ? You've forced their hand, you've demanded stuff they said they didn't want to do and then you've bitched about things they said they would do. Actually I think they've been quite restrained. I'd probably have proposed a licence change to make it only work on FreeBSD and Solaris given that treatment ;) Even if you need to change the interface, I've actually looked at the patch in question (have you, Alan?), Yes but I read it somewhat differently. Someone who never made a commitment to stability decided to do the logical thing. They deleted all the old broken interfaces, they cleaned up their ioctls numbering and they tided up afterwards. I read it as the action of someone who simply doesnt acknowledge that you have a right to control their development and is continuing to work in the way they intended. You can only see it as malicious if you assume they ever had some reason to keep compatibility or had promised it somewhere. Quite the reverse happened, and they never asked to be upstream in the first place. But the fact is, at least from my standpoint, I'd really hope that anything I had written would be used in ways I asked people to - Linus Torvalds, 2004 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Daniel Stone wrote: So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? I think that's what David ended up saying, but I think he is being _too_ strict. It's not how we've done other things either. We've changed ABI's over time many times. And we've even had complete breakage of old tools (although that is very much reserved for system tools, not regular applications: I think we've been almost religious about normal apps not breaking, unless there was some really overriding reason like security that forced us to really remove some interface). But most of the changes have been extending things, leaving the old interfaces around (often as wrappers around the new internal world order, sometimes by effectively having actual duplicated code). And then the old interface is maintained for quite a while (sometimes decades, often years, and generally at least for several kernel versions so that people have time to upgrade, and a distro can generally pick a newer kernel without having to change anything else). Sometimes we've done things that really end up requiring new tools. It's pretty rare, but it does happen. It happens a lot more for esoteric things that aren't every-day-in-your-face (I've seen at least _one_ mutter about sysfs in this thread ;) and might break something like a temperature sensor, for example. So the machine might _work_ and you could go for days without even noticing, but you might have some very specific functionality missing. Maybe your power meter doesn't work, or maybe you need to upgrade your kernel profiler to get good profiles again. Things like that. I suspect you as an X person know this very well, in fact. X itself has carried along a _lot_ of cruft exactly like this, that you guys have been removing only in the last few years - sometimes after decades of it being there. The whole switch to modern font handling is an obvious example of a _major_ fundamental feature change like that. So in general, what the kernel strives for is that very kind of the old model will still work - but it might be slow and emulated on top of a new way of dong things, and not get a lot of attention any more. And sometimes, there's really no good way of maintaining two interfaces at the kernel level, and then you have the downstream tools that have to learn to pick either the old or the new one, so that the tool still works regardless. And again, the old code _eventually_ bitrots or gets cleaned up, but what you really really want to avoid is to have a flag-day when you switch from one to the other, and you can't switch between adjacent versions of the kernel. In the 2.4.x/2.6.x split, for example, we did have system tools that needed to be upgraded if you came from a 2.4.x environment. You can still see signs of that in the kernel tree: we have that whole Documentation/Changes file that _still_ remains in our tree, even though it's purely historical. But if you look at that Documentation/Changes file, I don't think there is _any_ flag-day issue except for the removal of devfs. People _still_ talk about devfs in hushed tones. Everything else is about having to upgrade system tools _before_ upgrading the kernel (iow, they still worked on 2.4.x, but you needed recent enough versions of them to compile and run a 2.6.x kernel). In other words, it wasn't a flag day (apart from the already mentioned devfs users, and possibly something else I can't think of). It was an upgrade, yes, and it required some other things to be recent, but you could go back-and-forth between kernels if you had to. (Of course, it's now many years since that, so maybe my rose-colored glasses makes me forget the pain involved. And I obviously personally never made the whole 2.4.x - 2.6.x jump, since I'd been running the development kernels in between. So maybe I forgot some painful part). Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Alan Cox wrote: Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last time that the nouveau guys don't seem to care. Ok screamed about is perhaps better wording. Why should the Nouveau guys care ? You've forced their hand, you've demanded stuff they said they didn't want to do and then you've bitched about things they said they would do. Actually I think they've been quite restrained. I'd probably have proposed a licence change to make it only work on FreeBSD and Solaris given that treatment ;) Our OpenSolaris port isn't done yet.. ;) Oh.. and I hope you won't mind if we break the API in doing so.. *cough* /me hides -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 04:31:29PM +, Alan Cox wrote: On Fri, 05 Mar 2010 08:06:26 -0800 (PST) David Miller da...@davemloft.net wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. read() still works the same way it did 30 years ago last time I checked. Thats disingenous as read() is a method not an interface. It's also wrong because read() and write() behaviour has changed in various ways and old code broke because of it in subtle ways. Keeping the same method behaviour would have required things like new versions of read() for 64bit files, nonblocking, mandlocks, NFS, networking, etc all of which changed the core read() behaviour. I've yet to see anyone meaningfully argue it was the wrong thing to do. Alan Also GPU API is way more complex than any others kernel API (at least to my knowledge) and you can't know if the API you have is the good one until you have a fully working fast 3D driver ... and that takes either a lot of time with a lot of people. Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 11:05 AM, David Miller da...@davemloft.net wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 16:02:17 + You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it. And I'm arguing not merging it upstream would be like saying the same thing. No, it's not like saying the same thing. Not merging it upstream is saying we're not willing to support this in a reasonable way *at this time*. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
* Mike Galbraith efa...@gmx.de wrote: On the bright side, all this hubbub sends a very positive message to the noveau development crew. Folks, your work is important. I'd be proud as a peacock :) Heh, most definitely so! Noveau really is a game-changer i think, it's a big break-through for Xorg IMO. For the first time in Linux history we support 90%+ of graphics hardware in a more or less acceptable way. That is a big deal really and the xorg/drm folks should be proud of that accomplishment. It solves the nvidia.ko mess to a large degree and moves all these things into an actionable technical domain. I'm so much happier to argue with OSS folks who write this code than having to look at nvidia.ko tainted kernel crash logs. Ingo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/05/2010 10:17 AM, Daniel Stone wrote: On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. That particular horse left the barn when Fedora shipped nouveau in a stable release, not when Linus merged it into his tree. Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote: So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. No, that's not what people are saying. What people are saying is, avoid flag days. Deprecate things over a 6-12 month time period. We have lots of really good interfaces for doing that. You say you don't want to do that? Then keep it to your self and don't get it dropped into popular distributions like Fedora or Ubuntu. You want a larger pool of testers? Great! The price you need to pay for that is to be able to do some kind of of ABI versioning so that you don't have drop dead flag days. If you don't want to be a good citizen, then prepared to have people call you out for, well, not being a good OSS citizen. - Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 05:04:14PM +, Alan Cox wrote: You can only see it as malicious if you assume they ever had some reason to keep compatibility or had promised it somewhere. Quite the reverse happened, and they never asked to be upstream in the first place. The reason why this thread is inspiring so much traffic is because it's fundamentally about community norms. There are plenty of things that are not illegal, but which are at the same time anti-social. For example, there are all sorts of rules, if you are a researcher, about experimenting on human subjects. Many of those restrictions aren't codified in law, but if you violate them, other researches will say that you are a bad person, a bad researcher, and refuse to associate with you. And you might well lose your funding in the future --- but it's not illegal. If we are only talking about obligations under the GPL, sure, no one violated copyright licenses. But what *did* happen is someone basically said, I want to experiment on a whole bunch of users, but I don't want to spend the effort to do things in the right way. I want to take short cuts; I don't want to worry about the fact that it will be impossible to test kernels without pulling Frankenstein combinations of patches between Fedora 13 and Fedora 12. It's much like people who drill oil in the Artic Ocean, but use single-hulled tankers and then leave so much toxic spillage in their wake, but then say, hey, the regulations said what we did was O.K. Go away; don't bother us. Distro's that want to have a good reputation need to have a higher standard than, hey, it's allowed by the GPL. And maybe if we are sinking to the point where people are going to use stable means ABI breakages are allowed, we need to change the rules, since people want to quote rules as opposed to just being good community members. If you want lots of testers, then you need to be treat the testers, and the other developers in our development community with respect. I think the real problem was that Fedora and the Neauveu community are acting incredibly selfishly. They only care about their narrow point of view, and don't care about the pain they are inflicting on the kernel development process and other kernel developers. This is _legal_. It is, however, anti-social. - Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 8:46 AM, ty...@mit.edu wrote: On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote: So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. No, that's not what people are saying. What people are saying is, avoid flag days. Deprecate things over a 6-12 month time period. We have lots of really good interfaces for doing that. You say you don't want to do that? Then keep it to your self and don't get it dropped into popular distributions like Fedora or Ubuntu. You want a larger pool of testers? Great! The price you need to pay for that is to be able to do some kind of of ABI versioning so that you don't have drop dead flag days. If you don't want to be a good citizen, then prepared to have people call you out for, well, not being a good OSS citizen. I was trying my hardest to not say anything, but... Nouveau isn't an official Xorg project. It hasn't been added to the jhbuild list for auto-checkout, it doesn't get tinderbox time (admittedly a function of being part of the jhbuild) and I don't think it's on the katamari list, so it's never been shipped as part of an Xorg release. It is only in mainline under the staging rules; drivers come and go from staging under fairly lax rules. Fedora ships this stuff because they're actively developing it and enjoy deploying half-broken things to users in the vain hope that it magically won't break. I can't count the number of kittens eaten by Fedora systems I've used. (It is kind of sad that Fedora's still the best distro about not deploying broken stuff but still remaining up-to-date.) Tellingly, it doesn't look like this interface change has been deployed to stable Fedora, just Rawhide. The Ubuntu people don't talk to us as much as they should. Seeing how badly they biffed Radeon and Intel KMS deployment, it's hard for me to believe that deploying Nouveau went smoothly. I don't have much more personal experience; my work computer has an HD 3450 in it now instead of the old GeForce, and that's my only Ubuntu box. If distros want to run weird experiments on their users, let them! Sure, sometimes bad things happen, but sometimes good things happen too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut, Plymouth, the list goes on and on. If the problem here is actually that a distro is deploying a staging driver and picking up the pieces themselves, then just say it. This whole thing with flag days, deprecation, interface changes, etc. hinges on the idea that the code being deprecated was stable, usable, and widely deployed, but it wasn't and isn't. That said... Code probably is moving too fast inside nouveau. There is a bit of a wall to go through to get new patches upstream, which one would hope would inspire some developer restraint. intel and radeon both still have most (if not all) of the legacy code needed by ancient userspaces, and both DDX drivers are doing multiple-branch releases to keep old userspace interfaces alive for people unable to update their kernels. It might be useful for the nouveau guys to really seriously consider code before it leaves their trees and enters mainline; writing code that you won't commit to is quite lame for the obvious reasons, but also for some unobvious reasons, e.g. it makes you look like you don't actually know what you're doing and would rather just keep reinventing wheels without justifying and testing your design choices. (This is also why I was not exactly pleased with the suggestion of retooling all of the r600 userspace over a change to the CS system; we just spent the better part of a year moving everything over to CS!) ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010 12:21:29 +, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Serious discussion point perhaps should be: is the libdrm so close to the kernel it ought to be in the same git tree ? Alternatively does it need to be easier to have multiple Nouveau libdrms autoselected according to the kernel side versioning. ELF library versioning is not rocket science and both the old and new libraries exist and can be installed so all the bits are present except for the wrapper to load the right sublibrary yes ? That *would* make versioning impossible. To make the difficulty of improving ABI at the moment concrete, I just got done merging the patches for execbuf2 in userland and enabling i915 texture tiling. This was a 3% performance win in one test I was looking at, and 1% in another -- less than hoped, but important nonetheless (there are other cases that should see 30% or so wins hopefully). The patches got written back in July, and revved several times as they broke various combinations of compatibility. At the point that I merged eb2 to the kernel for 2.6.33, it wasn't *really* tested -- the userland side was broken all to hell it looked like, but at least it wasn't regressing execbuf1 any more, right? I spent this week getting userland working, including a new libdrm release (already obsolete because a bug in the libdrm violated what the ABI between libdrm - msea was supposed to be). So overall, I'd say that we spent about a month of developer time at least between jbarnes, ickle, and myself, on extending the execbuf interface to add a flag saying dear kernel, please don't do this bit of work on this buffer, because I don't need it and it makes things slow. This is not that bad for Intel folks. We're paid to hack on it, and can justify spending ridiculous amounts of time for small wins. I actually enjoy this. Right now all the userland -- whether it's Mesa, xf86-video-intel, libva, cairo-drm, stand-alone DRM testcases, etc., gets to move to the new libdrm API, declare its dependency in PKG_CHECK_MODULES, and hand that new flag to libdrm as if the kernel supported the new interface. Inside libdrm, it looks at the kernel version and uses the new interface or old as appropriate. The ugly versioning stuff stays in one easy-to-review 5kloc component, and the complicated 50kloc driver components get to pretend they have a fancy new kernel. But if libdrm's in the kernel, all those userland components no longer get to rely on the version of libdrm, because distros will ship whatever's with the kernel they're using and our userland does have to work on (relatively recent) distros. Each of those userland components would have to grow a compatibility layer to work with whatever kernel libdrm is available, passing the flag in the new API or using the old API. Userland would even buggier for having to replicate all that logic everywhere, and we probably wouldn't have execbuf2 landed yet. Well, OK. What I'd really do instead is make the kernel libdrm be a thin ioctl wrapper, and build a librealdrm that does what libdrm does today. But I don't think that's what you were suggesting. pgp21kB5PwxVU.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
So overall, I'd say that we spent about a month of developer time at least between jbarnes, ickle, and myself, on extending the execbuf interface to add a flag saying dear kernel, please don't do this bit of work on this buffer, because I don't need it and it makes things slow. Perhaps then, we should break ABI compatibility _more_ often to speed up development, but also have awesome mechanisms to make it painless for the user. Such as: 1. Automatic side by side userspace installation, as Linus proposed 2. Kernel make install refusing to proceed if it finds that userspace is not updated, and giving instructions on how to update userspace 3. Distributions packaging the new ABI X/Mesa drivers and libdrm even for stable distributions 4. Kernel make install offering to automatically install said distribution packages if it detects a supported distribution 5. Ability to drop new versions of drivers/gpu/drm in an older kernel tree and have it compile (within reasonable limits) In particular, for people with (slightly) old kernels, it should be much easier to make updated DRM trees still work with older kernels, than attempting to make updated userspace work with older kernel modules. This also actually gives them the benefits of the new code. And for people with really old kernels, it's not different from any other hardware device, which requires a kernel upgrade to have better support. Then, for instance, Linus would just have seen the following upon running make install: This kernel requires the Nouveau userspace version 0.0.16, which you don't have installed. Fedora 12 has been detected. Invoke yum to install the rpmnames RPMs required for it? [y/n] _or_ Ubuntu 9.10 has been detected Invoke apt-get to install the debnames packages required for it? [y/n] If the user says no, or the distribution is unknown, instructions on how to download and compile the source would be presented. Once you setup this system, you can freely break the ABI with no significant user discomfort by just raising the version number. This also potentially applies to stuff other than DRM (e.g. perf, kvm, iptables, udev, filesystem-specific tools/APIs, various device configuration systems, and so on). The really stable APIs/ABIs should not be the (undocumented) kernel ones, but Xlib and OpenGL, which actually have formal specifications. Perhaps eventually Gallium could join them as a stable API closer to the hardware, but that's a long way off. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 11:38 AM, Corbin Simpson mostawesomed...@gmail.com wrote: I was trying my hardest to not say anything, but... [blah blah Fedora blah Ubuntu blah staging blah blah] That said... Code probably is moving too fast inside nouveau. There is a bit of a wall to go through to get new patches upstream, which one would hope would inspire some developer restraint. intel and radeon both still have most (if not all) of the legacy code needed by ancient userspaces, and both DDX drivers are doing multiple-branch releases to keep old userspace interfaces alive for people unable to update their kernels. It might be useful for the nouveau guys to really seriously consider code before it leaves their trees and enters mainline; writing code that you won't commit to is quite lame for the obvious reasons, but also for some unobvious reasons, e.g. it makes you look like you don't actually know what you're doing and would rather just keep reinventing wheels without justifying and testing your design choices. (This is also why I was not exactly pleased with the suggestion of retooling all of the r600 userspace over a change to the CS system; we just spent the better part of a year moving everything over to CS!) Strike this paragraph. After talking with the nouveau guys again, I don't think they were doing anything out of the ordinary for staging drivers. Frustrating, sure, but not anything worth a 200-post flame war. Also, I am a tool, don't know what I'm talking about, not actually a nouveau dev, etc. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Strawman, mostly because all distros suck, the less patches you apply the less likely things are to work, LFS is the most fragile thing out there, etc. Hurp derp. If you need a feature not in the distro, and it is needed because you have installed something not in the distro or not new enough, you will have to go get it yourself. If you want a bleeding X, you should be prepared to build bleeding DDX and Mesa. If you want a new kernel FS, you probably need a newer e2fsprogs or xfsprogs. If you want new kernel DRM, you will need a new libdrm. That process is relatively distro-agnostic. Posting from a mobile, pardon my terseness. ~ C. On Mar 5, 2010 1:51 PM, ty...@mit.edu wrote: On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: If distros want to run weird exper... So what distro would you recommend for people who want to do kernel development, do kernel testing, and do kernel bisects to help us find bugs? Are you basically saying, Kernel people shouldn't use Fedora? So what should we use instead? - Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 2:41 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 5 Mar 2010, Ben Skeggs wrote: The F13 packages *will* work, so long as you're not bisecting back and forth. How do I install just the F13 libdrm thing, without changing everything else? I'm willing to try. We can make it part of the 2.6.34 release notes. And if we end up having people bisecting back and forth, I will hate that f*cking nouveau driver even more. I believe Dave has already explained this to you, but nobody has mentioned it here. What you are supposed to do is install the new nouveau driver, which requires a new libdrm. So, just compile both libdrm, and nouveau, to a sandbox, say /opt/new-nouveau, and then in /etc/X11/xorg.conf: Section Files ModulePath /opt/new-nouveau/lib/xorg/modules ModulePath /usr/lib/xorg/modules EndSection That should do it. No frankensteinian F13 packaging stuff, and no mess with the system's /usr/lib/. Cheers. -- Felipe Contreras -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/05/2010 09:42 AM, Jeff Garzik wrote: On 03/05/2010 10:17 AM, Daniel Stone wrote: On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. That particular horse left the barn when Fedora shipped nouveau in a stable release, not when Linus merged it into his tree. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ stopped me in my tracks i.g. in order to install using the livecd requires brain surgery. (for me that's fine, but for an average business person/s forget it). Justin P. Mattock -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: If distros want to run weird experiments on their users, let them! Sure, sometimes bad things happen, but sometimes good things happen too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut, Plymouth, the list goes on and on. So what distro would you recommend for people who want to do kernel development, do kernel testing, and do kernel bisects to help us find bugs? Are you basically saying, Kernel people shouldn't use Fedora? So what should we use instead? - Ted -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 6:19 PM, Linus Torvalds torva...@linux-foundation.org wrote: The thing I objected to, in the VERY BEGINNING in this thread, i the fact that the thing was done in such a way that it's basically impossible to support the old/new ABI at all! [...] The way this was done, it's apparently basically impossible for the Fedora people to push out packaged that support both the old and the new kernel. The reason why the nouveau people wanted to leave the driver in staging is because they wanted to leave open the option of reshuffling the API. The Fedora guys integrated this stuff on their own risk, and linux (because of your pressure), also did. At no point in time nouveau guys agreed to freeze the API. Now they have done precisely what was expected; there's no surprise there. The surprise seems to be that you thought (for some reason), that reshuffling the API wouldn't break the old (or current in F12) user-space code. Now, how exactly do you think that could have been achieved? Even if you have both nouveau_drv-0.0.15.so, and nouveau_drv-0.0.16.so... What piece of could would choose one rather than the other? There has never been such a piece of code. If there was no compatibility code for API re-shuffling, and API re-shuffling was expected, the resulting breakage was doomed to happen. Finally, at least it's possible to compile the radeon driver without support for DRM, so perhaps nouveau (and other drivers), should check the kernel drm version at run-time instead, and fall-back to non-drm mode when the version is not compatible. I think that's a sensible approach, although that might require a considerable amount of code. However, that's something to consider for the future, as your current libdrm/nouveau is not prepared to handle the DRM API re-shuffle that _must_ happen. Cheers. -- Felipe Contreras -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Distro's that want to have a good reputation need to have a higher standard than, hey, it's allowed by the GPL. And maybe if we are sinking to the point where people are going to use stable means ABI breakages are allowed, we need to change the rules, since people want to quote rules as opposed to just being good community members. If you want lots of testers, then you need to be treat the testers, and the other developers in our development community with respect. I think the real problem was that Fedora and the Neauveu community are acting incredibly selfishly. They only care about their narrow point of view, and don't care about the pain they are inflicting on the kernel development process and other kernel developers. This is _legal_. It is, however, anti-social. - Ted And people wonder why I stubbornly stick with Slackware Linux. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. Quite frankly, the more I look at that commit, the worse it looks. That commit seems to _on_purpose_ try to avoid at all cost being compatible. It not only removes some old entry-points, it literally re-numbers all the ioctl numbers as it does so, apparently entirely in order to just make it difficult to have some libdrm that can handle both versions. This all means that I literally cannot test the current -git tree. I suspect I have to revert it. Or is there a version of X that can handle _both_ the 0.0.15 and the 0.0.16 interfaces? That's absolutely required - so that it's not a flag-day any more to upgrade the kernel, and so that people (including very much me) can test and bisect other things without having to worry about basic functionality coming and going as you bisect things, Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Jesse Barnes wrote: Whoa, so breaking ABI in staging drivers isn't ok? Lots of other staging drivers are shipped by distros with compatible userspaces, but I thought the whole point of staging was to fix up ABIs before they became mainstream and had backwards compat guarantees, meaning that breakage was to be expected? If the staging driver isn't in common use, who cares? But this is a major driver, used by a major subsystem in a major distribution. It's not like Fedora-12 is some odd case. And it's not like nVidia graphics is unusual. Face it, nouveau is staging only in name. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Jesse Barnes wrote: On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. Yeah, it's in the first one. My bad. I didn't notice, because that one got cancelled for other reasons and never even tested. That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? Backwards compatibility is really important. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: When you asked that nouveau was merged, people explicitly told you that the reason it hadn't been was because the interface was unstable and userspace would break. You asked that it be merged anyway, and now you're unhappy because the interface has changed and userspace has broken? How hard is it to understand basic kernel development rules? Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People can hide behind all the staging and I asked for it things they like, but that doesn't change simple basic facts: distros should make sure drivers get merged up-stream, and people end up depending on them. Btw, I'm hoping some of this pain goes away for me, because I expect to get rid of the shitty nVidia card reasonably soon. The fact that my main box had a power supply that literally _required_ a power-sucking-piece- of-sh*t-graphics card has been painful to me. But none of that changes my basic objections. I didn't ask for nouveau to be merged as staging - I asked it to be merged because a major distro uses it. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:51:20 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Jesse Barnes wrote: On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. Yeah, it's in the first one. My bad. I didn't notice, because that one got cancelled for other reasons and never even tested. That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? Backwards compatibility is really important. Sure it is. But OTOH this is very clearly a use at your own risk driver. Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. The use at your own risk part is that you get to keep both pieces if you try to mix and match kernels and userspace until the STAGING moniker is removed. If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. Of course I'm implicitly trusting their motivation for breaking ABI in this case, but that was very much a part of the merge discussion so shouldn't come as a surprise to anyone. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: But none of that changes my basic objections. I didn't ask for nouveau to be merged as staging - I asked it to be merged because a major distro uses it. Put another way: the issue of whether _I_ happen to see this personally or not is kind of irrelevant. We need testers for development kernels. And any time we make that hard, we lose. That's really fundamental. The reason distributions should push their drivers upstream, and have a upstream first model in the first place is not because of _my_ hardware. It's because of the fundamental fact that if people can't test upstream kernels (because they don't work like the distro kernel does), we end up in a situations where people can't sanely test current git. And that model simply doesn't work from a development standpoint. If you make it basically impossible for people to upgrade kernels, and if you take away their ability to bisect bugs, you're going to cause the quality of development to go down. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:18:03 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Whoa, so breaking ABI in staging drivers isn't ok? Lots of other staging drivers are shipped by distros with compatible userspaces, but I thought the whole point of staging was to fix up ABIs before they became mainstream and had backwards compat guarantees, meaning that breakage was to be expected? Yes, it sucks, but what else should the nouveau developers have done? They didn't want to push nouveau into mainline because they weren't happy with the ABI yet, but it ended up getting pushed anyway as a staging driver at your request, and now they're stuck? Sorry this whole thing is a bit of a wtf... Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Jesse Barnes wrote: If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? All of these are always possible to do. We've been _very_ good at doing them in general. I'm complaining, because let's face it, what else can I do? And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. So practically speaking: what _do_ you suggest we do about all the regressions this will cause? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. Nobody has even answered me whether this is _forwards_compatible. It clearly isn't backwards-compatible. IOW, is there _any_ way to move back-and-forth over that commit, even if I can find a new libdrm? IOW, we know we have a problem here. But what's the solution? I know I can revert it (I tried, I'm running that kernel now, nouveau works). That's not a good solution, I know. But can you offer me a _better_ one? One that doesn't involve upgrade all the way to rawhide, and lose the ability to bisect anything, or run plain 2.6.33. So yes, I'm complaining. But I at least have mentioned one solution. You, in contast, are just making excuses with no solutions. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 10:43:30AM -0800, Linus Torvalds wrote: Or is there a version of X that can handle _both_ the 0.0.15 and the 0.0.16 interfaces? When you asked that nouveau was merged, people explicitly told you that the reason it hadn't been was because the interface was unstable and userspace would break. You asked that it be merged anyway, and now you're unhappy because the interface has changed and userspace has broken? -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 10:51:20AM -0800, Linus Torvalds wrote: That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 10:55:57AM -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: When you asked that nouveau was merged, people explicitly told you that the reason it hadn't been was because the interface was unstable and userspace would break. You asked that it be merged anyway, and now you're unhappy because the interface has changed and userspace has broken? How hard is it to understand basic kernel development rules? Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People can hide behind all the staging and I asked for it things they like, but that doesn't change simple basic facts: distros should make sure drivers get merged up-stream, and people end up depending on them. It takes a long time to work out exactly what kind of userspace interface you need when the hardware you're dealing with is entirely undocumented. The reason it's been shipped in Fedora is that it needs to be in front of actual users in order to get any testing at all, and we have the manpower to ensure that the dependencies are consistent. But most nouveau development isn't handled inside Red Hat, and we're in no position to dictate terms to the volunteers who are spending their spare time trying to write a useful driver. Btw, I'm hoping some of this pain goes away for me, because I expect to get rid of the shitty nVidia card reasonably soon. The fact that my main box had a power supply that literally _required_ a power-sucking-piece- of-sh*t-graphics card has been painful to me. You'd have hit similar issues if you'd been using Radeon KMS over the past couple of releases... But none of that changes my basic objections. I didn't ask for nouveau to be merged as staging - I asked it to be merged because a major distro uses it. It was merged as staging because the interface is unstable, which is consistent with staging's Kconfig: Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? All of these are always possible to do. We've been _very_ good at doing them in general. I'm complaining, because let's face it, what else can I do? And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. So practically speaking: what _do_ you suggest we do about all the regressions this will cause? At the moment in Fedora we deal with this for our users, we have dependencies between userspace and kernel space and we upgrade the bits when they upgrade the kernels, its a pain in the ass, but its what we accepted we needed to do to get nouveau in front of people. We are currently maintain 3 nouveau APIs across F11, F12 and F13. The main reason the API was gutted was because it supported lots of things that weren't supportable going forward. User modesetting support was completely removed and this meant lots of the API was pointless. Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface which justs ifdefs around this for now, and in another release or two we rip all that out. Of course I can't ask him either of these until normal people who live in Australia wake up in 2-3 hrs, as opposed to me who is sitting in the dark trying not to wake the baby. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 1:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. From Dave's initial pull request [git pull] drm merge from March 1, he does say *NOTE* in case you missed it: this will *break* your nvidia machine, its purely intentional. Rawhide should have the libdrm and driver updates necessary. Matt Turner -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: You're asking volunteers who didn't ask for their driver to be merged to perform more work in order to support users they didn't ask for. And _you_ are making excuses for BAD TECHNICAL DECISIONS! Come on! How hard is it to admit that that the change was done badly? How hard is it to admit that this isn't a political issue, it's about pure technology. There are good ways of doing things, and there are way sof doing things badly. I'm pointing to real _technical_ problems with how this was done. I'm talking about how this hurts testing, and how we've been able to handle things in other cases (with versioning, and forwards- or backwards- compatibility) without this kind of crap. If you can't handle backwards compatibility - fine. But I get the very strong feeling that people didn't even _think_ about trying to be at least forwards-compatible, and I'm getting the _very_ strong feeling that you are making excuses for bad technology. Is there some model of versioning inside X _except_ for the it won't work kind of thing? Can we fix this going forward, so that you can have _real_ versioning (ie multiple installed versions of a libdrm, the way you can have concurrently multiple installed versions of glibc?) IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 11:08:07 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? Sure, but both kinds of compat come at a cost, a potentially large one in this case, so why take it on before absolutely necessary? I know you can see both sides of this... And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. Right, but OTOH it's a development driver. If you're running Fedora, things will work as long as you stick to the distro packages. And if you're building your own kernels, you ought to be taking care with staging drivers, right? So practically speaking: what _do_ you suggest we do about all the regressions this will cause? Before this thread I thought the policy was let people muddle through with staging drivers until their staging status is cleared. If that's not the case, then really what's the point of staging? I'm sure there are other examples of this type of breakage in staging drivers, though admittedly nouveau is probably the biggest in terms of user interest. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: At the moment in Fedora we deal with this for our users, we have dependencies between userspace and kernel space and we upgrade the bits when they upgrade the kernels, its a pain in the ass, but its what we accepted we needed to do to get nouveau in front of people. We are currently maintain 3 nouveau APIs across F11, F12 and F13. Can we try to make it less of a pain in the ass at some other level? For example, I realize that it's a real pain - both for the kernel _and_ for the user space library - to dynamically have to support multiple versions of some interface. And doing it _statically_ (with a compile option) isn't much better, because you end up not only with source code from hell, you still end up with the problem of having to compile the libraries and the kernel for the same interface, and not being able to mix. So let's say that we live with an API that changes, where none of the binaries (and no single version of the source code either) really support anything but _their_ version of the interface. Why does it then have to be such an effing pain for the _user_? (And by being such an effing pain for the user, it also becomes indirectly a pain for the distribution too - now you have all those nasty dependencies where you really cannot mix things up at all, and you can't upgrade one piece without upgrading the other). Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. Quite frankly, I really don't think that's a wonderful option either. Havign dynamic conditionals in code not only makes things worse to maintain, they slow things down too, and make code bigger. So what I'd look for is a sane technical solution to the technical problem of that ABI screwed up. And it's not like this is a new issue. We've had this several times before. It's called versioning, and the solution tends to pretty much _always_ boil down to two cases: - don't _ever_ change the ABI in backwards-incompatible ways, and have feature flags to say what level of support ther is. This is quite common, but it really does require that backwards compatibility. You can add features, but every time you add a feature, you still maintain the old ones _and_ new users need to check the feature flag first (and fall back on the old way of doing things if the new feature isn't there) Clearly this one doesn't seem to work for DRM. And quite frankly, I suspect it's at least partly because some DRM people aren't even _trying_ - possibly because they aren't even thinking about these kinds of issues. - Install multiple versions concurrently, and know they are incompatible, but pick the right one automatically. I really don't understand why this wouldn't solve all your distro problems, _and_ solve my kind of user problems too. It's simply not acceptable to just say ok, X doesn't work. Why aren't the libdrm libraries simply _versioned_? IOW, why can't we just have /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so living happily side-by-side? Why can't we just switch between Fedora 11, 12 and 13 kernels, and automatically get the right library? The glibc people do it based on hardware features. It's just a dlopen() away. This isn't rocket science. I shouldn't need to complain. I think it would make the life of even the _developers_ much easier. Who was the less-than-rocket-scientist that decided that the right thing to do was to check the kernel DRM version support, and exit with an error if it doesn't match? See what I'm saying? What I care about is that right now, it's impossible to switch kernels on a particular setup. That makes it effectively impossible to test new kernels sanely. And that really is a _technical_ problem. Btw, I'm sure there are other approaches too. But I really suspect that it should be pretty trivial to change nouveau (and I suspect this has nothing nouveau-specific in it - it migth even be the X server itself that does the DRM version test) to instead of dying, just doing a dlopen() of the right version. Wouldn't the radeon and intel driver people love to be able to do something like that -too-? Seriously. The current situation is not just crap, it's _stupid_ crap. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev --
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? The thing is, I violently disagree with your basic premise. The way things are done now, that developer base actually just makes things _harder_ for themselves. They may not be aware that they do so, and they may _think_ that it's easier to just ignore versioning, but they are wrong. And I say that from personal experience. Doing incompatible changes in any code base makes everything harder. It results in users staying on old versions that you _know_ you don't want to support, but because of the incompatible change, they can't sanely upgrade. Seriously. So I bet we could do that wrapper nouveau.so that literally just does the get version, and dlopen the _real_ nouveau-version.so. Quite frankly, I don't know the XAA interfaces (or whatever they are in X these days), but somebody who does know them should be able to cook up such a wrapper in five minutes (and then spend a day testing it because of some silly bug, but whatever..) Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/04/2010 02:04 PM, Matthew Garrett wrote: Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. Shipping it as the default Fedora driver for NVIDIA hardware makes that text largely irrelevant. Jesse said Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. but when it is the default driver, it is the default _production_ driver for Fedora users, in an official, stable Fedora release. And the alternative? You said F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? I attempted to use the non-default 'nv' driver just before nouveau was merged into upstream/staging, because I wanted a development kernel that actually worked on my Fedora-based devel boxes. It was a complete exercise in frustration, requiring at least one bugzilla bug report, and ultimately resulted in failure. I gave up and waiting for Linus to merge nouveau, which instantly made my life a lot easier :) Kernel hacking on Fedora, my own dogfood, has become increasingly cumbersome because of all these graphics issues. Sometimes it's just easier to test a modern kernel on an ancient distro, sadly. Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 11:14:11AM -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. Nobody has even answered me whether this is _forwards_compatible. It clearly isn't backwards-compatible. IOW, is there _any_ way to move back-and-forth over that commit, even if I can find a new libdrm? Judging by http://cgit.freedesktop.org/mesa/drm/commit/?id=b496c63143e9a4ca02011582329bce2df99d9b7c , no. And if you're unhappy with that, don't use the driver. You enabled an option that's *documented* as potentially breaking between kernel releases, having been told that this was likely to happen, and now you're complaining? IOW, we know we have a problem here. But what's the solution? I know I can revert it (I tried, I'm running that kernel now, nouveau works). That's not a good solution, I know. But can you offer me a _better_ one? One that doesn't involve upgrade all the way to rawhide, and lose the ability to bisect anything, or run plain 2.6.33. Running -nv ought to be an option. So yes, I'm complaining. But I at least have mentioned one solution. You, in contast, are just making excuses with no solutions. You're asking volunteers who didn't ask for their driver to be merged to perform more work in order to support users they didn't ask for. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 11:41:22AM -0800, Linus Torvalds wrote: Is there some model of versioning inside X _except_ for the it won't work kind of thing? Can we fix this going forward, so that you can have _real_ versioning (ie multiple installed versions of a libdrm, the way you can have concurrently multiple installed versions of glibc?) There isn't. I don't think there's any intrinsic difficulty in doing so, other than the buildsystems and X's own unstable driver API. IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 12:07:19PM -0800, Linus Torvalds wrote: Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? Compared to dealing with Mesa's build system? I honestly wouldn't want to say. But you're right that pushing the job of supporting multiple interfaces out to userspace would be much more tractable here. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 12:07, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? The thing is, I violently disagree with your basic premise. The way things are done now, that developer base actually just makes things _harder_ for themselves. They may not be aware that they do so, and they may _think_ that it's easier to just ignore versioning, but they are wrong. And I say that from personal experience. Doing incompatible changes in any code base makes everything harder. It results in users staying on old versions that you _know_ you don't want to support, but because of the incompatible change, they can't sanely upgrade. Seriously. So I bet we could do that wrapper nouveau.so that literally just does the get version, and dlopen the _real_ nouveau-version.so. Quite frankly, I don't know the XAA interfaces (or whatever they are in X these days), but somebody who does know them should be able to cook up such a wrapper in five minutes (and then spend a day testing it because of some silly bug, but whatever..) Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? No. It makes our lives much more complicated. I've worked on the radeon driver before and about half my time was spent just checking compatibility with multiple kernel/user space combinations. You have to handle all possible combinations of DRM+DDX+Mesa drivers, and that gets hairy real quick. Then for nouveau I decided not to bother until interfaces were stable enough, and I think all developers agree on that. I suggest you think about the do not break user space interfaces principle from a graphics developer point of view and what that means for the user space code. For example, you could take a look at the radeon DDX or Mesa drivers, which do implement compatibility. In the long run this leads to little gems like this: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r200/r200_state.c#n2148 Obviously even though there is some form of compatibility, not all user space/kernel combinations are tested. In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually Stephane -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
