Small PCI core patch

Any objections to this?

thanks,

greg k-h

---------------------

Subject: PCI: fix up the exported symbols to be the proper license.

---
 drivers/pci/access.c     |   12 +++++-----
 drivers/pci/bus.c        |    6 ++---
 drivers/pci/msi.c        |    8 +++---
 drivers/pci/pci-acpi.c   |    4 +--
 drivers/pci/pci-driver.c |   16 ++++++-------
 drivers/pci/pci.c        |   54 +++++++++++++++++++++++------------------------
 drivers/pci/probe.c      |   14 ++++++------
 drivers/pci/proc.c       |    6 ++---
 drivers/pci/quirks.c     |    4 +--
 drivers/pci/remove.c     |    8 +++---
 drivers/pci/rom.c        |    8 +++---
 drivers/pci/search.c     |   20 ++++++++---------
 drivers/pci/setup-bus.c  |    6 ++---
 13 files changed, 83 insertions(+), 83 deletions(-)

@@ -56,12 +56,12 @@ PCI_OP_WRITE(byte, u8, 1)
 PCI_OP_WRITE(word, u16, 2)
 PCI_OP_WRITE(dword, u32, 4)
 
-EXPORT_SYMBOL(pci_bus_read_config_byte);
-EXPORT_SYMBOL(pci_bus_read_config_word);
-EXPORT_SYMBOL(pci_bus_read_config_dword);
-EXPORT_SYMBOL(pci_bus_write_config_byte);
-EXPORT_SYMBOL(pci_bus_write_config_word);
-EXPORT_SYMBOL(pci_bus_write_config_dword);
+EXPORT_SYMBOL_GPL(pci_bus_read_config_byte);
+EXPORT_SYMBOL_GPL(pci_bus_read_config_word);
+EXPORT_SYMBOL_GPL(pci_bus_read_config_dword);
+EXPORT_SYMBOL_GPL(pci_bus_write_config_byte);
+EXPORT_SYMBOL_GPL(pci_bus_write_config_word);
+EXPORT_SYMBOL_GPL(pci_bus_write_config_dword);
 
 static u32 pci_user_cached_config(struct pci_dev *dev, int pos)
 {

@@ -199,7 +199,7 @@ void pci_walk_bus(struct pci_bus *top, v
 }
 EXPORT_SYMBOL_GPL(pci_walk_bus);
 
-EXPORT_SYMBOL(pci_bus_alloc_resource);
+EXPORT_SYMBOL_GPL(pci_bus_alloc_resource);
 EXPORT_SYMBOL_GPL(pci_bus_add_device);
-EXPORT_SYMBOL(pci_bus_add_devices);
-EXPORT_SYMBOL(pci_enable_bridges);
+EXPORT_SYMBOL_GPL(pci_bus_add_devices);
+EXPORT_SYMBOL_GPL(pci_enable_bridges);

@@ -1119,7 +1119,7 @@ void msi_remove_pci_irq_vectors(struct p
 	}
 }
 
-EXPORT_SYMBOL(pci_enable_msi);
-EXPORT_SYMBOL(pci_disable_msi);
-EXPORT_SYMBOL(pci_enable_msix);
-EXPORT_SYMBOL(pci_disable_msix);
+EXPORT_SYMBOL_GPL(pci_enable_msi);
+EXPORT_SYMBOL_GPL(pci_disable_msi);
+EXPORT_SYMBOL_GPL(pci_enable_msix);
+EXPORT_SYMBOL_GPL(pci_disable_msix);

@@ -174,7 +174,7 @@ acpi_status pci_osc_support_set(u32 flag
 	ctrlset_buf[OSC_CONTROL_TYPE] = temp;
 	return AE_OK;
 }
-EXPORT_SYMBOL(pci_osc_support_set);
+EXPORT_SYMBOL_GPL(pci_osc_support_set);
 
 /**
  * pci_osc_control_set - commit requested control to Firmware

@@ -203,7 +203,7 @@ acpi_status pci_osc_control_set(acpi_han
 	
 	return status;
 }
-EXPORT_SYMBOL(pci_osc_control_set);
+EXPORT_SYMBOL_GPL(pci_osc_control_set);
 
 /*
  * _SxD returns the D-state with the highest power

@@ -525,11 +525,11 @@ static int __init pci_driver_init(void)
 
 postcore_initcall(pci_driver_init);
 
-EXPORT_SYMBOL(pci_match_id);
-EXPORT_SYMBOL(pci_match_device);
-EXPORT_SYMBOL(__pci_register_driver);
-EXPORT_SYMBOL(pci_unregister_driver);
-EXPORT_SYMBOL(pci_dev_driver);
-EXPORT_SYMBOL(pci_bus_type);
-EXPORT_SYMBOL(pci_dev_get);
-EXPORT_SYMBOL(pci_dev_put);
+EXPORT_SYMBOL_GPL(pci_match_id);
+EXPORT_SYMBOL_GPL(pci_match_device);
+EXPORT_SYMBOL_GPL(__pci_register_driver);
+EXPORT_SYMBOL_GPL(pci_unregister_driver);
+EXPORT_SYMBOL_GPL(pci_dev_driver);
+EXPORT_SYMBOL_GPL(pci_bus_type);
+EXPORT_SYMBOL_GPL(pci_dev_get);
+EXPORT_SYMBOL_GPL(pci_dev_put);

@@ -18,7 +18,7 @@
 
 /* Ugh.  Need to stop exporting this to modules. */
 LIST_HEAD(pci_root_buses);
-EXPORT_SYMBOL(pci_root_buses);
+EXPORT_SYMBOL_GPL(pci_root_buses);
 
 LIST_HEAD(pci_devices);
 

@@ -994,13 +994,13 @@ struct pci_bus * __devinit pci_scan_bus_
 		b->subordinate = pci_scan_child_bus(b);
 	return b;
 }
-EXPORT_SYMBOL(pci_scan_bus_parented);
+EXPORT_SYMBOL_GPL(pci_scan_bus_parented);
 
 #ifdef CONFIG_HOTPLUG
-EXPORT_SYMBOL(pci_add_new_bus);
-EXPORT_SYMBOL(pci_do_scan_bus);
-EXPORT_SYMBOL(pci_scan_slot);
-EXPORT_SYMBOL(pci_scan_bridge);
-EXPORT_SYMBOL(pci_scan_single_device);
+EXPORT_SYMBOL_GPL(pci_add_new_bus);
+EXPORT_SYMBOL_GPL(pci_do_scan_bus);
+EXPORT_SYMBOL_GPL(pci_scan_slot);
+EXPORT_SYMBOL_GPL(pci_scan_bridge);
+EXPORT_SYMBOL_GPL(pci_scan_single_device);
 EXPORT_SYMBOL_GPL(pci_scan_child_bus);
 #endif

@@ -611,8 +611,8 @@ static int __init pci_proc_init(void)
 __initcall(pci_proc_init);
 
 #ifdef CONFIG_HOTPLUG
-EXPORT_SYMBOL(pci_proc_attach_device);
-EXPORT_SYMBOL(pci_proc_attach_bus);
-EXPORT_SYMBOL(pci_proc_detach_bus);
+EXPORT_SYMBOL_GPL(pci_proc_attach_device);
+EXPORT_SYMBOL_GPL(pci_proc_attach_bus);
+EXPORT_SYMBOL_GPL(pci_proc_detach_bus);
 #endif
 

@@ -1312,7 +1312,7 @@ void pci_fixup_device(enum pci_fixup_pas
 	pci_do_fixups(dev, start, end);
 }
 
-EXPORT_SYMBOL(pcie_mch_quirk);
+EXPORT_SYMBOL_GPL(pcie_mch_quirk);
 #ifdef CONFIG_HOTPLUG
-EXPORT_SYMBOL(pci_fixup_device);
+EXPORT_SYMBOL_GPL(pci_fixup_device);
 #endif

@@ -55,7 +55,7 @@ int pci_remove_device_safe(struct pci_de
 	pci_destroy_dev(dev);
 	return 0;
 }
-EXPORT_SYMBOL(pci_remove_device_safe);
+EXPORT_SYMBOL_GPL(pci_remove_device_safe);
 
 void pci_remove_bus(struct pci_bus *pci_bus)
 {

@@ -70,7 +70,7 @@ void pci_remove_bus(struct pci_bus *pci_
 	sysfs_remove_link(&pci_bus->class_dev.kobj, "bridge");
 	class_device_unregister(&pci_bus->class_dev);
 }
-EXPORT_SYMBOL(pci_remove_bus);
+EXPORT_SYMBOL_GPL(pci_remove_bus);
 
 /**
  * pci_remove_bus_device - remove a PCI device and any children

@@ -118,5 +118,5 @@ void pci_remove_behind_bridge(struct pci
 	}
 }
 
-EXPORT_SYMBOL(pci_remove_bus_device);
-EXPORT_SYMBOL(pci_remove_behind_bridge);
+EXPORT_SYMBOL_GPL(pci_remove_bus_device);
+EXPORT_SYMBOL_GPL(pci_remove_behind_bridge);

@@ -234,7 +234,7 @@ void pci_cleanup_rom(struct pci_dev *pde
 	}
 }
 
-EXPORT_SYMBOL(pci_map_rom);
-EXPORT_SYMBOL(pci_map_rom_copy);
-EXPORT_SYMBOL(pci_unmap_rom);
-EXPORT_SYMBOL(pci_remove_rom);
+EXPORT_SYMBOL_GPL(pci_map_rom);
+EXPORT_SYMBOL_GPL(pci_map_rom_copy);
+EXPORT_SYMBOL_GPL(pci_unmap_rom);
+EXPORT_SYMBOL_GPL(pci_remove_rom);

@@ -376,14 +376,14 @@ exit:				
 	spin_unlock(&pci_bus_lock);
 	return found;
 }
-EXPORT_SYMBOL(pci_dev_present);
+EXPORT_SYMBOL_GPL(pci_dev_present);
 
-EXPORT_SYMBOL(pci_find_bus);
-EXPORT_SYMBOL(pci_find_next_bus);
-EXPORT_SYMBOL(pci_find_device);
-EXPORT_SYMBOL(pci_find_device_reverse);
-EXPORT_SYMBOL(pci_find_slot);
-EXPORT_SYMBOL(pci_get_device);
-EXPORT_SYMBOL(pci_get_subsys);
-EXPORT_SYMBOL(pci_get_slot);
-EXPORT_SYMBOL(pci_get_class);
+EXPORT_SYMBOL_GPL(pci_find_bus);
+EXPORT_SYMBOL_GPL(pci_find_next_bus);
+EXPORT_SYMBOL_GPL(pci_find_device);
+EXPORT_SYMBOL_GPL(pci_find_device_reverse);
+EXPORT_SYMBOL_GPL(pci_find_slot);
+EXPORT_SYMBOL_GPL(pci_get_device);
+EXPORT_SYMBOL_GPL(pci_get_subsys);
+EXPORT_SYMBOL_GPL(pci_get_slot);
+EXPORT_SYMBOL_GPL(pci_get_class);

@@ -129,7 +129,7 @@ void pci_setup_cardbus(struct pci_bus *b
 					region.end);
 	}
 }
-EXPORT_SYMBOL(pci_setup_cardbus);
+EXPORT_SYMBOL_GPL(pci_setup_cardbus);
 
 /* Initialize bridges with base/limit values we have collected.
    PCI-to-PCI Bridge Architecture Specification rev. 1.1 (1998)

@@ -493,7 +493,7 @@ pci_bus_size_bridges(struct pci_bus *bus
 		break;
 	}
 }
-EXPORT_SYMBOL(pci_bus_size_bridges);
+EXPORT_SYMBOL_GPL(pci_bus_size_bridges);
 
 void __devinit
 pci_bus_assign_resources(struct pci_bus *bus)

@@ -526,7 +526,7 @@ pci_bus_assign_resources(struct pci_bus 
 		}
 	}
 }
-EXPORT_SYMBOL(pci_bus_assign_resources);
+EXPORT_SYMBOL_GPL(pci_bus_assign_resources);
 
 void __init
 pci_assign_unassigned_resources(void)

Ok, now that I have everyone's attention, no I'm not serious about submitting this patch, I'm not a fool. I know the rules about existing kernel symbols.

But, what if this patch really did go in? Who would be affected by this? Nothing that is currently in the kernel.org kernel tree, right, so what's the big deal?

Oh yeah, closed source drivers that are out side of the tree, but who cares about them?

Oh yeah, _very_ large companies rely on them right now, and are working on creating more and more closed source drivers. Why? Don't they know that their legal departments do not agree with this? Are they approaching Linux development in the same way they used to with the old Unix systems, i.e. fork and "add value"?

Well, consider this a warning shot for anyone who is relying on closed source modules. What you are doing is trying to take from Linux and not give anything back.. The GPL explicitly forbids this, and Linux would not be good enough today for you to be using it without that protection. There is a reason why you are wanting to use Linux for your internal use, and why your customers are asking for it.

If you, or your company is relying on closed source kernel modules, your days are numbered. And what are you going to do, and how are you going to explain things to your bosses and your customers, if possibly, something like this patch were to be accepted?

Something to think about...

thanks,

greg k-h

Please make the effort to ping major authors (copyright holders)...

Jeff

Well, if you're going to make PCI drivers GPL only, I don't see the point of keeping support for non-GPL modules in the first place :)

Ben.

I'm all about it, but good luck trying to convince ATI and/or nVidia ...

For those who haven't noticed, the latest generation of ATI cards have a new 2D engine that is completely different from the previous one and totally undocumented. So far, they haven't showed any plans to provide any kind of documentation for it, unlike what they did for previous chipsets, not even 2D and not even under NDA. That means absolutely _0_ support for it in linux or X.org except maybe with some future version of their binary blob, and _0_ support for it for any non-x86 architecture of course.

At least nVidia still sort-of maintains the obfuscated but working & opensource basic 2D driver ...

On the graphics front, things are actually getting _worse_ everyday.

Ben.

And funny enough unlike SCSI adapters and things for large server installations, nobody seems to really care enough about graphics cards, I've heard horror stories about how little Linux companies actually care about open source graphics, I suppose they have to follow the profit but still you'd like to think they effect of all this "open source drivers, get them in the kernel" work that is being done would at some point spill over ....

When someone gets up of their arse and sues nvidia or ATI and wins, then feel free to change these exports, otherwise your view on who is right has as much legal value as their view, whether we like it or not..

Dave.

Its easy to see why

The graphics market between Nvidia and ATI is extreme rivalry There have been some ugly patent lawsuits
Good software tricks can make the weaker hardware win Its very hard to write

So there are real secrets left in the market. Designing a SCSI controller isn't exactly a McJob but its commodity.

Nvidia are at least trying to do what they can within what for them is not a very easy set of market conditions for open sourcing. ATI were doing very nice things until they won the Xbox 360 contract. An observation that perhaps would not go amiss reaching the US legal watchdogs.

Alan

They are not the only ones doing closed source Linux drivers by far. They just seem to be the most "visible" these days. It's the other companies, the ones that know better (or at least have legal departments that know better) that are doing this for various different/odd hardware pieces that are the most upsetting to me.

And yes, I do understand the patent issue with the video players these days. But what about the hardware OEM companies like IBM and HP that bundle those graphic adapters in their system, and go off and support and maintain the systems, running Linux, for big-named customers. That's a timebomb waiting to go off, as there is some real money behind those contracts. They are the people in the position to change things today, yet they are not :(

We are the people to change things for tomorrow, and we are...

thanks,

greg k-h

if the wrapper is marked GPL then it will still work (whether it makes sense or is legal to do so i have no idea)

From what I know and have been told, it is explicitly not legal to do so.

But consult your lawyer for the final word on this, lkml is not a legal source :)

How is graphics going to be dealt with on Linux? Is the Linux desktop going to stay stuck in 1998 since that is the last year the graphics vendors released specs? If the choice is "open source or die" then that's the answer. Of course that answer is bad news desktop Linux distributions and they may die.

If the choice instead is to embrace current graphics hardware, then given the current state of the market, I don't see any other alternative than using the proprietary drivers and OpenGL stacks. The path in that direction is something like Xgl. We can wish for a non-proprietary choice on the current hardware, but the reality is that we are not going to get it.

--
Jon Smirl
[email protected]

On the other hand, there is little justification not to open source at least the kernel & basic mode setting part. It's all plumbing and mode setting stuff, monitor detection, etc... it's not part of any of the big added value or IP stuff that can be found in the 3D engine.

I've talked to them several times about that, trying to advocate really only putting the GL -> engine command stream generation in a binary blob (in userland where it belongs) and have everything else open sourced, but they aren't interested. In many cases, the replies I get are along the lines of "why would we do that ? nVidia doesn't" or "why could we care", or "give us a business justification" (the later translates to:
prove us that by doing so, we'll sell that many more million cards, which is obviously impossible) etc... They really doesn't give a shit about what we think, and will continue to do so until they get a bit fat lawsuite, that is my opinion at least.

Ben.

As long as they don't need to put binary junk in the kernel, they can keep the binary junk in userland, where it belongs. That is at least acceptable and legal, even if it's not a great situation.

The problem is they load these multi-megabytes blocs that want to hook into SMM BIOS interrupts, ACPI, VM, etc... all over the place and do all sort of junk in your kernel. Say goodbye to any kind of stability and maintainability of a kernel loaded with that crap.

And pretty much all of the crap in there doesn't have any good reason to be closed source. That's all just plumbing. A lot of that could even be shared between video drivers (they could use the DRI interface for example, and if it's not enough for them, extend it). That is not where the actual IP is.

But the real reasons are elsewhere anyway. They don't wnat to opensource because they don't want to open the gazillion security holes in their stuff (afaik, the binary drivers make absolutely no verification of the command streams passed from userland, you can make the card do whatever you want from any user context, including arbitrary DMA to/from system memory), the various comments & workarounds for HW bugs that aren't supposed to exist and might make some customers want to throw the cards back at them, the disgusting pile of smelly windows-originated library they link in and wrap all over the place to make linux look like NT, etc...

And we do _not_ want that in the kernel. There is no point in having linux on the desktop if it's at the cost of it being the same crap that windows is.

Ben.

Build some root exploits using their drivers and start sending them to LKML. The resulting bad PR should fix their security holes quick enough. Who knows, maybe the heat will be hot enough for them to go open source.

--
Jon Smirl
[email protected]

In the US you can't sue to force their hardware open until they are a proven monopoly. And as long as we have both Nvidia and ATI splitting the market we won't get a monopoly.

So the choices are:

1) Live in 1998. What happens in five years R200's are no longer available, fallback to VGA?

2) Temporarily accept the ugly drivers. Let desktop development continue. Work hard on getting the vendors to see the light and go open source.

3) Use Linux on the server and run Mac or Windows on your desktop.

The choice's aren't exclusive, you can do all three if you want. The catch is the part about advancing the Linux desktop, that can't happen without access to current and new video hardware.

--
Jon Smirl
[email protected]

No but you can sue for GPL breakage if their blob is considered as a derivative work or that sort of thing.

Won't happen without some incentive. Besides, I can't accept the ugly driver for the very simple reason that they only exist for x86 and I have no such thing ...

Your other points are totally irrelevant.

Ben.

I doubt they will see 'the light' for many years without dollar signs attached.

A question worth asking is: Who needs whom? Do we (FLOSS community) need them (Graphics hardware manufactures) or do they need us? Despite growth in Linux on Desktops, I think we need them a lot more than they need us.

There is no question that making drives for these card that work nicely with Linux and xorg will take some substantial effort. And it isn't work that can be easily spread around the community due to various trade secret issues. This suggests, to me at least, that the work needs to be done by a fairly small group of people who can sign NDAs with NVidia or ATI and work with their engineers and with the community to develop the right interfaces and to make drivers that have a minimal closed-source component that lives in user-space.

Who is going to pay these people to do this work? If you agree with the analysis of 'who needs whom', the logical answer is 'us'.

Maybe we need a small consortium of companies with vested interest in OSS each ponying up half a million, and use this to employ two teams of graphics experts, one of which works within NVidia, and one within ATI. I suspect the two companies could be convinced to take on some free engineering support, if it was presented the right way.

Anyone got a few dollars to spare?

NeilBrown

that doesn't mean they're allowed to not honor the GPL of course.

Also it's almost the same argument as the ndiswrapper discussion: as long as there is an alternative some of these companies (prolly not ati/nvidia although: see [1]) will stay closed, but once there's no alternative they'll just open up.

I can see the point of the argument that a change like this needs to be announced for say 6 months first in that feature-removal doc though.

[1] Both nvidia and ati have a way out: they can do the IP side (translating 3D stuff into card specific commands) in userspace and just pass the data to the hardware via a thin driver that just drives and controls the hardware. Sure it may be 5% slower, but it's a lot cleaner IP wise. X after all is MIT (bsd like without nasty clauses) licensed and allows binary components.

Yeah, you'd have to break it the patch up into _much_ smaller pieces... :)

Rob

What desktop Linux distributions?

My fiance's laptop recently got yet another spyware infection and she finally decided to give Linux a try on the thing. (She still has a windows desktop she spends most of her time at, so the laptop's optional.) And I've been looking for a decent desktop distro. None of the big boys like Red Hat or SuSE care about desktops anymore. Knoppix is great but it's only usable from the CD (which is too slow), I've never managed to install it to the hard drive and add packages afterwards.

I tried Ubuntu because it's at least _interested_ in desktop users, and my Fiance's reaction was "hate hate hate" (this is a quote. Mostly what she seemed to hate was Gnome, and I agree with her entirely on that one. I use KDE myself, but kbuntu is an afterthought that doesn't have any apps. Not even a gui tool to list available access points and select which one to bind to. Yeah, I can do iwlist/iwconfig from the command line every time I fire up my laptop at a coffee shop, but I'm not asking her to.)

I got a couple page writeup of what annoyed her, and I'm going to try to find something that she can hate less. But what's next, slackware? What distros are still _interested_ in linux on the desktop?

On the hardware front, there are some signs of hope. My dell laptop may actually have a usable open source driver for its video hardware, totally reverse engineered of course:
http://r300.sourceforge.net/

And someday I hope to actually build X from source, and opengl, and try testing this sucker. It probably won't be this week. Geeky as I am, building X, DRI, and openGL from source isn't something I do casually. But how can I try this out any other way?

The problem isn't the lack of technology. We've got forcedeth for network cards that never had a spec because when people did this work lots of end users showed up to try it out. But if you look at the status log for the radeon driver I mentioned above, it only seems to get touched every 2 months and the last time was in july. And this is something that, according to their web page, mostly works now for the hardware I've got...

The linux of 5 years ago was about as end-user ready as the Linux of today:
the progress we've made has been buried by new hardware requirements (wireless, 3d, suspend). We mostly have the technology, but we haven't gone after users who don't program. And without users, any problem solved becomes an isolated demo gathering dust. Who is integrating this stuff so we can see what the holes _are_?

Rob

[snip]

Historically hackers were not too good at raising funds.

Maybe we should use stuff which we are good at? Forcedeth is a nice precedent. 2d and especially 3d engines
may be significantly harder to reverse engineer,
but people can scale rather nicely, as kernel development shows. ;)

Then write specs from gained knowledge and put it on a web page.

IIRC reverese engineering for driver development is legal in most countries.

If ATI/NVidia will sue Linux on this, then server-oriented companies (RedHat, IBM, ...) probably could provide defence.
--
vda

The r300 driver is merged into the mainline projects so r300.sf.net is no longer the source for it. Mesa CVS now has support for it and as far as I know you can grab binary snapshots from
http://dri.freedesktop.org/snapshots/ saves a lot of compiling from source if they work..

Dave.

* Neil Brown:

And what do we actually need? 2D graphics, with some very, very basic acceleration? Basic 3D support? Playback of encrypted content?

Personally, I only need very basic 2D sypport, but this is probably the exception. The other extreme is the digital media desktop, which will very soon need to support encrypted video streams.

So what do we want? What sacrifices in terms of proprietary software and user restrictions are we willing to make?

I would concur. Although one of the problems as I understand it is the upcoming cards no longer have a 2D engine.

I assume they will rather completely drop development of the driver instead of developing an OSS driver. I cannot imagine that the 'few' people using Nvidia cards on some non-Windows systems are enough to proceed developing the closed-source driver. Or maybe they just stop developing the driver to hit us hard in the face! So we're left with nothing than just some old closed-source crap. I think it's getting even more realistic when a lawsuit is knocking on their doors. Don't you think?

I use my Nvidia card without the Nvidia drivers for long time now. For pure X without games and just GNOME and coding I have no need to run the proprietary driver at all. But maybe for others (mostly for people with laptops where you cannot simply change video cards due to a vendor-designed form-factor) it could get worst. What is left for them? Run non-X environments on the laptop? Even run Windows on it? Puh!

A damn stupid circumstance with Nvidia in the end...

Marc

Yep.

Current technology is completely programmable GPUs, with an ISA just like x86 or PPC processors have an ISA.

Programmable shaders -- aka JIT-compiled GLSL code -- are the order of the day. 2D and the static 3D pipeline are entirely implemented in terms of these instructions.

Allen Akin noted that graphics regularly goes through generic/specific hardware cycles. At the moment, we are in the 'generic' point in the cycle; thus, one can look at the older Rendition processors (docs available to XFree86 hackers) for a moderate example of how to deal with current ATI and NVIDIA cards.

So today's cards, it's all about transferring code (GPU microcode) and data (textures, vertexes, etc.) to and from the card. Remote execution one could call it. Or RPC :)

I've proposed to Intel, and would like to talk to ATI/NVIDIA, about seeing what can be done to standardize the REALLY DUMB components, like the DMA interface to transfer code and data.

Jeff

Yes, IMO this is the only realistic path, without cooperation from ATI/NVIDIA.

This is why I dislike the ATI r300 rev-eng effort: I cannot find any "Chinese wall": one team rev-engs the hardware and writes a doc. Another team writes the drivers from the docs.

Jeff

100% agreed... IMO this is the best way to get open source 3D stuff.

One sticking point is validation: ensuring userspace cannot cause invalid GPU microcode to be generated. [I can just hear Al Viro swearing, just thinking about creating secure compilers...]

Jeff

4) Write a translation layer (for xorg or the kernel) that can load Windows drivers. Use binary translation for non-x86. Hope the APIs are not patented.

Give up all hope of ever diagnosing or fixing a crash.

Welcome to Windows instability, circa 1995.

Jeff

You exaggerate. Windows drivers work well enough in Windows (or so I presume). One just has to implement the environment these drivers expect, very carefully.

For the untrusting, options do remain:

- run the driver in userspace (if it's a xorg driver, in a separate process) so that all outputs can be validated
- use binary translation even on x86 and validate all memory and I/O accesses (like valgrind, but hopefully faster)

It's still possible for the driver to dma stuff where it shouldn't. Maybe IOMMU games (where available) can help. But I seriously doubt it will be that bad.

I exaggerate nothing -- we have real world experience with ndiswrapper and similar software, which is exactly the same model you proposed, is exactly the same model that has created all sorts of technical, legal, and political problems.

Dumb with a capital 'D'.

Jeff

If you're going to use binary drivers it'd be much better to implement a linux "driver compatibility layer" so at least you don't have to use crap from other systems

And no, windows drivers don't work well enought in windows (try enabling the /3GB switch in your box and check how many drivers break...)

If they're reverse engineering the hardware, why would you need a chinese wall? Compaq was turning x86 assembly code into x86 assembly code and had to prove that the new x86 code didn't infringe the copyright on the old x86 code. They weren't turning port I/O and DMA logs into C code...

Rob

I don't have a Windows box, but I'm quite sure Windows (without the more esoteric switches) is quite stable, even in SMP. The '95 and NT 4.0 days are gone. Give the drivers the environment they like (mangle the addresses if necessary, single thread them, allow them larger stacks, whatever it takes) and they will work well. Put them in userspace if you're paranoid or isolate them using binary translation.

From this discussion, it looks like the choices of the future are Windows drivers or serial terminals. Excuse me now while I look for my null-modem cable.

Chinese wall is far more secure legally.

Linux doesn't need more headaches from open legal questions.

It worked for forcedeth, Broadcom wireless, and several other projects... it results in a better driver, too.

Jeff

I agree that the legal and political problems are real. I offered two solutions to the technical problems.

However the situation with video drivers is already bad, and deteriorating. I had to hunt on the Internet to get my recent (FC4) distro to support my low-end embedded video (via). In the future it looks like even that won't work.

I hope you have a better solution.

Are you sure it is a new 2D engine? ATI engineers have mentioned several times that they were looking at removing the 2D engine and going 3D only - using the 3D engine to draw the 2D data.

Removal of the 2D engines is a key vulnerability in the strategy of only using 2D on Linux.

--
Jon Smirl
[email protected]

And given real world experience with "solutions" like this, they cause more problems than they solve.

VIA is working with open source community. They are small enough (comparatively) that they need every advantage. VIA is one of the positive examples.

Almost all of the solutions listed in this thread are better:
Chinese wall rev-eng, funding, ...

Jeff

I'm aware of that. But look at the trouble we have even with the cooperative vendors. I'm sure they had a Windows driver from day zero.

As others pointed out, rev-eng of programmable 3D hardware will be difficult. There will be a perpetual (and long) lag between the introduction of hardware and Linux support. The effort has to repeat for new revisions of the hardware. And a rev-eng driver can still not be trusted: who knows whether the register you just wrote into doesn't have some subtle side-effect.

I want some too.

I don't think Windows drivers are the best, or even a good solution. But that may be the only realistic one. And I believe quite doable.

The biggest problem with VIA (and Intel) is that they are only available as integrated video on the motherboard. I can't just walk to the store and pick one up off the shelf. I have yet to see any AMD64 motherboards with these chipsets either.

--
Brian Gerst

Agreed.

VIA has Athlon64 chipsets, with their integrated graphics on it.

Jeff

And just to set the record straight, for those that want to read things into this proposal, this patch is the creation of my personal opinion, and I do not speak for, nor represent my employer, or anyone else.

This patch was to get people who are relying on binary drivers to think about the risk they are taking when they do so. It is not intended as legal advice, but a thought exercise only.

And if anyone thinks I would actually apply such a patch directly as-is, they are wrong. I would not deserve to be the PCI maintainer if I did so.

thanks,

greg k-h

via should work open source. It didn't in the initial FC4 X but that was an X.org/RH bug and is fixed in the updates.

You put it in the processor eventually.

Hi,

Le Mon, 21 Nov 2005 15:01:41 -0800, Greg KH a écrit :

Why not make a crappy GPL driver that just export again the symbols ?

MODULE_LICENSE("GPL");

pci_bus_read_config_byte_binary (....)
{
pci_bus_read_config_byte(...)
}
EXPORT_SYMBOL(pci_bus_read_config_byte_binary);

[...]

Also why as an embeded company I can't remove the licence check in the kernel I provide to my custommers.

No software tricks could force the company to use GPL because GPL allows you to remove or short-cut these tricks.

Only the law can do something about softwares that don't comply to GPL license...
It would be great if big companies that use Linux (OSDL, IBM, ...) proposes a poll of lawyers which could do something like gpl-violations (check if some softwares violate the GPL, if yes contact the copyright holders, and if the developpers accept represent them).

Matthieu

It will take forever for Intel and AMD to get their acts together :(

AMD did well by putting the memory controller on the CPU, but Intel didn't.

Intel added "IOA/T" (async DMA memory copies), but AMD doesn't have that.

And ATI/NVIDIA stuff will likely remain across the PCI-Express bus for quite a while.

My preference is to have ATI/NVIDIA use the same PCI-Express interface, and differentiate in the GPU.

Jeff

There might be a different way that could work if _many_ Linux-related companies participate:

Find a graphics card vendor who wants to offer a cheap graphics card while offering full specs and write an open source driver for this card.

Then start the PR campaign, e.g. press releases and free prominent notices at the SuSE main page "SuSE recommends ...".

Yes, this would require a significant joint effort.

But if successful, it might convince at least one of the two big graphics cards vendors that there's an (although relatively small) part of the market they are missing.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Because that's just so obviously illegal that anyone caught doing that would have no defense at all :)

thanks,

greg k-h

Actually I have a via/amd board:

00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 01:00.0 VGA compatible controller: VIA Technologies, Inc. S3 Unichrome Pro VGA Adapter (rev 01)

Works well on FC4 with an Ubuntu driver.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Because if you have to do tha your non GPL driver is a derivative work of your GPL driver and clearly GPL. More to the point any court of law is going to look at your behaviour and conclude that it was deliberate infringing behaviour, which is normally either criminal and/or scores triple damages. It may also count as circumvention, and that was one reason to add the module license/_GPL check - so that blatent abuse would fall under DMCA/EUCD. If the bad guys are going to have insane laws and penalties available to use against people, then it makes sense for the good guys to carry the same sized stick.

Note btw there is a very big difference between circumvention/blatant GPL violation and some of the other cases being discussed.

Nothing stops you. But see above as it applies likewise.

Alan

I must have missed something, there isn't such a strategy anywhere I know either in X or in the kernel. EXA in X is designed to make using the 3D engine to do the 2D rendering much easier.

It is not. It works with the vesa driver but you can count the scans at 60Hz. I believe it is in rawhide now but I don't have test machines,

Originally reported here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156681.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

You seem to miss my point: In a typical windows installation, some drivers are CRAPPY. It's not about the windows "core". It's the thousand of crappy drivers made by crappy companies to support cheap devices which makes it unstable.

The /3GB makes windows to switch to 1GB/3GB mode instead of the default 2GB/2GB. Passing "/PAE /3GB" options to the windows kernel is used by many people to measure the quality of the drivers - and _many_ times (specially with cheap hardware) it doesn't work. Some times the box won't even boot.

The same goes for SMP. Windows is SMP safe, but I bet my ass that the big majority of drivers made for cheap devices has not been tested in a smp box - I've seen it myself, my dual p3 box dies as soon as the dialup app tells the drivers of a cheap winmodem I have to do its job.

Which, by the way, is going to be _really_ fun in the windows world now that people is buying dual-core machines. Thousand of SMP-unsafe code paths will soon start being tested by millions of customers buying dual-core CPUs...(and is not that all linux drivers are or will be better but having the source allows fixing them...)

You seem to forget linux history: Linux started having _zero_ zupport for hardware except for a few devices and a single 32 bit architecture. Right now its the operative system with the biggest number of drivers on the world (most of windows drivers are not made by microsoft). Linux has beated companies like nvidia and ati in this field many times and can do it again.

None of the desktop Windows installations I'm aware of exhibit this. The recent versions of Windows are fairly stable.

Nobody uses this option (well my father does, but he's in technical computing. I was unable to convince him to move to Linux).

Most people have stable, easy to use Windows desktops. I don't like to admit it, but I had to fight to get my via video to work correctly.

(The Linux driver does not fail, though)

Many people have hyperthreaded CPUs today.

I sincerly doubt Linux ships with more drivers than Windows. And when you compare driver availability (shipped or vendor provided) the gap is very wide.

It works well on the server, where Linux has a large and rising market share. It doesn't work on the home desktop where Linux is nonexistent. There are also intellectual propery issues involved in video which prevent open drivers.

So, your Winmodem, most people's 3D cards, many wireless adapters, and all the esoteric devices are not supported (it is nice to see the situation improving with wireless, though). The lack of drivers is one of the blocks towards expansion on the home desktop, and vice versa.

Perhaps Windows drivers can allow enlarging the desktop market share, after which they will not be needed because the vendors will see the light and provide open, and presumably better drivers.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

It works perfectly here. This was a distro problem.

Lee

You don't seem to check frecuently windows help forums, where some people speaks of nvidia as the number 1 "bluescreener"...

Lots of windows drivers _are_ crappy. It's just a fact - some companies hire the wrong people. Some companies (like nvidia) get money from being fast, not from stability. This is a good example from a microsoft programmer about how some companies cheat the WHQL certification to get faster drivers...
http://blogs.msdn.com/oldnewthing/archive/2004/03/05/84469.aspx

This one about silent install of drivers by "smart" installers is fun
too: http://blogs.msdn.com/oldnewthing/archive/2005/08/16/452141.aspx

Hypertreaded CPUs can't run the two virtual cpus at the same time, real smps can so the probability should be smaller (this would be an interesting topic for another thread though ;)

Linux didn't always have a large market share on servers. Again, history has shown that the path taken by linux until now is succesful.

What he means is the process of begging the vendors for specs for just the 2D hardware engine won't work when a seperate 2D engine doesn't exist anymore.

--
Brian Gerst

Awsome. Certainly a very strong point against Windows drivers.

Actually they are parallel at the instruction level. For the purpose of SMP-safety they are the same as true SMP. They just have different performance characterestics.

I hope you're right. But desktops are more complex, more varied, and have much more, er, interesting, users.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Hi Greg,

I would suggest to apply this patch.

I don't know ATI, but NVidia is running huge Linux clusters for verification. IMHO its really time for them to contribute back to the community. In the end it would be the benefit for all.

Regards

Harri

My windows 2000 machine seems to bluescreen inside the intel graphics drivers now and then. It's slightly more stable than having two cards of the manufacturer Creative in the same machine at the same time, though.

One day I should put Linux on that machine to see if it crashes as often, I seem to recall there are open drivers for intel (except for init?). Would be interesting to compare average use.

Which may be an opportunity or a threat. Nvidia for example long ago provided enough info to do basic stuff with the TNT2 and RIVA cards.

Even if its the same engine its not the same question.

Yes, but at _least_ with nVidia you get this free "nv" driver that they maintain and that gives you basic mode setting & 2D accel... With the newest ATI cards, you don't even get that.

Ben.

By new 2D engine, I meant the mode setting core.

I use xorg's 'nv' driver. That one is _not_ from nVidia, it it?

They are, and getting better at it. One thing you really need to do before ascribing sinister goings on and malice to 'not doing what you want' is understand the view from the other side.

The "do things out way or we bomb you" approach isn't a constructive way to build bridges whether its performed by Linux developers or US presidents.

Alan

It is, though maybe not "officially". It's developped by an nVidia employee. That's also why it's totally obfuscated: there is not a single register name in there, only a vast list of magic numbers & magic values. Mark (the author) claims that he prefers that way and nobody else is supposed to work on the driver but him ... I find those arguments a bit bogus (people _do_ occasionally hack on this driver, and/or use it for the kernel nvidiafb etc...) but heh.. he's the author so he does what he wants.

Ben.

Yes but I don't necessarily need license from the GPL to distribute a derived work. What I need is permission from the copyright holders my proprietary driver is a derived work of, the GPL is merely one mechanism to get that permission. Permission from the GPLed driver, namely me, is easy enough for me to obtain. Permission from the authors of any other Linux code my propriety driver is a derivative work of is probably going to be impossible to obtain. So it seems to me that the relevant question is whether my (hypothetical) proprietary driver is a derivative work of any Linux code I did not write myself. I do not believe that "derivative work of" is transitive, so it does not necessarily follow that my propriety driver is a derivative work of any other code just because it is a derivative work of my GPL driver. However:

1) I am not a Lawyer.

2) If my driver was a derivative work of the kernel when it was using _GPL symbols, adding a shim between it and the kernel isn't going to change matters.

3) The _GPL annotation is a really strong hint that the authors of code would consider my proprietary driver a derivative work, and do not give any permission for me to use their code _except_ under the GPL. If my proprietary driver is a derivative work of someone else's code, I'm in trouble.

Andrew

I don't want to bomb them, either. I see that NVidia is in competition to ATI and others and that they don't want to release their sources to stay ahead. But breaking the GPL is not acceptable.

Recent news have shown that some very big companies (much larger than NVidia) don't give a dime for the rights of others, if it is not in their interest. If more and more companies break the GPL without any consequences, then the GPL will become meaningless.

Talking about the other side: Some months ago NVidia dropped support for some old (3 yrs, AFAIR) graphics cards in their proprietary driver. They could have considered to release the sources for this "old stuff" instead.

Regards

Harri

The age of the code/hardware is irrelevant. The big problem these folks have is the fear that they're infringing on the other guys patents.

They have relatively little to gain from such a goodwill gesture, and a hell of a lot to lose. iirc, 3dfx disappeared overnight due to legal battles that went..

"You lose, pay us lots of money, or let us buy you out and own your IP."

Even non-competitive vendors like Matrox have now gone binary-only, likely due to the same concerns (It for sure isn't to hide some super secret performance edge).

Dave

3Dfx were bought by Nvidia.

Ok, so, really who exactly is open-source friendly enough for me to recommend some hardware for some friends (these friends don't play games---they are more interested in proving theorems and getting their papers accepted by journals)?

VIA? SiS? What manufacturers are really getting along with Open Source drivers (even if their products are not for "3l33t" users/gamers)?

I'm often asked this and until some time ago, I used to give the answer that Matrox was collaborating, but it seems that Matrox is out of the game now... :-(

Regars, Rogério.

Rogério Brito : [email protected] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Possibly the best x86 one right now for docs, help and the like is AMD. Intel varies by which bit of Intel but publish a lot of stuff including errata which many vendors are reluctant to publish.

I've personally had good results with people at VIA although it can be quite variable and it is (as often the case) about the right groups of people trusting each other personally rather than public everything, ALi (likewise) although no experience with SiS.

With a lot of the vendors it really is about good direct relationships. They need to know who to talk to, that the person concerned on the open source end is trustworthy and relevant to the community. Most don't work on the kind of margins that let them interact with the entire world that way.

A lot of vendors do help and if you look over the kernel you will see many vendor written drivers and a fair number of 'written using vendor driver as a reference' drivers.

Or throw resources behind the OpenGraphics project (
http://www.opengraphics.org/ ). Help them out with the hardware specs, help out with the code. Then when the hardware finally arrives, help out by buying and using that hardware.
That'll give you a fully Open Source supported graphics card.

--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

Wow, this project has been making amazing progress. They may have a working device by the end of THIS year, and they seem to have buyers lining up to throw money at them when the card is ready. Even if gamer one does not buy it they appear to have a viable market in the academic and research communities. Plus high end content work, simulation, etc. This is shaping up to be a real open source success story.

Check out this progress report from 6 weeks ago:

http://kerneltrap.org/node/5743

Lee