Re: [RFC] Small PCI core patch

Re: [RFC] Small PCI core patch

[Robert Hancock]

Jeff Garzik wrote:
> 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...]

I suspect the amount of data going through is large enough that this 
wouldn't really be practical. I think you'd have to deal with the code 
generating GPU instructions having to be trusted and have the device 
interface require root privileges..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [RFC] Small PCI core patch

[Jeff Garzik]

Robert Hancock wrote:
> Jeff Garzik wrote:
> 
>> 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...]
> 
> 
> I suspect the amount of data going through is large enough that this 
> wouldn't really be practical. I think you'd have to deal with the code 
> generating GPU instructions having to be trusted and have the device 
> interface require root privileges..

All I said was "ensuring userspace cannot cause invalid GPU microcode to 
be generated."

No matter what runs with root priveleges, other graphics processes do 
not, and one must ensure that app clients cannot generate sequences 
which cause the hardware to fail.  Which is a lot more difficult, when 
the unpriveleged app clients are submitting GLSL.

	Jeff

Re: [RFC] Small PCI core patch

[Alan Cox]

On Iau, 2005-11-24 at 22:06 -0600, Robert Hancock wrote:
> I suspect the amount of data going through is large enough that this 
> wouldn't really be practical. I think you'd have to deal with the code 
> generating GPU instructions having to be trusted and have the device 
> interface require root privileges..

You may wish to compare your suspicion with the DRI driver for via GPUs
which does exactly this without problem. The majority of video traffic
is not GPU instructions but textures which go via a different route.
Also the GPU streams are generally very clean to parse.

Alan

[RFC] Small PCI core patch

[Greg KH]

Any objections to this?

thanks,

greg k-h

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

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


Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

---
 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(-)

--- gregkh-2.6.orig/drivers/pci/access.c
+++ gregkh-2.6/drivers/pci/access.c
@@ -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)
 {
--- gregkh-2.6.orig/drivers/pci/bus.c
+++ gregkh-2.6/drivers/pci/bus.c
@@ -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);
--- gregkh-2.6.orig/drivers/pci/msi.c
+++ gregkh-2.6/drivers/pci/msi.c
@@ -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);
--- gregkh-2.6.orig/drivers/pci/pci-acpi.c
+++ gregkh-2.6/drivers/pci/pci-acpi.c
@@ -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
--- gregkh-2.6.orig/drivers/pci/pci-driver.c
+++ gregkh-2.6/drivers/pci/pci-driver.c
@@ -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);
--- gregkh-2.6.orig/drivers/pci/pci.c
+++ gregkh-2.6/drivers/pci/pci.c
@@ -425,7 +425,7 @@ pci_power_t pci_choose_state(struct pci_
 	return PCI_D0;
 }
 
-EXPORT_SYMBOL(pci_choose_state);
+EXPORT_SYMBOL_GPL(pci_choose_state);
 
 /**
  * pci_save_state - save the PCI configuration space of a device before suspending
@@ -910,36 +910,36 @@ __setup("pci=", pci_setup);
 #if defined(CONFIG_ISA) || defined(CONFIG_EISA)
 /* FIXME: Some boxes have multiple ISA bridges! */
 struct pci_dev *isa_bridge;
-EXPORT_SYMBOL(isa_bridge);
+EXPORT_SYMBOL_GPL(isa_bridge);
 #endif
 
 EXPORT_SYMBOL_GPL(pci_restore_bars);
-EXPORT_SYMBOL(pci_enable_device_bars);
-EXPORT_SYMBOL(pci_enable_device);
-EXPORT_SYMBOL(pci_disable_device);
-EXPORT_SYMBOL(pci_max_busnr);
-EXPORT_SYMBOL(pci_bus_max_busnr);
-EXPORT_SYMBOL(pci_find_capability);
-EXPORT_SYMBOL(pci_bus_find_capability);
-EXPORT_SYMBOL(pci_release_regions);
-EXPORT_SYMBOL(pci_request_regions);
-EXPORT_SYMBOL(pci_release_region);
-EXPORT_SYMBOL(pci_request_region);
-EXPORT_SYMBOL(pci_set_master);
-EXPORT_SYMBOL(pci_set_mwi);
-EXPORT_SYMBOL(pci_clear_mwi);
+EXPORT_SYMBOL_GPL(pci_enable_device_bars);
+EXPORT_SYMBOL_GPL(pci_enable_device);
+EXPORT_SYMBOL_GPL(pci_disable_device);
+EXPORT_SYMBOL_GPL(pci_max_busnr);
+EXPORT_SYMBOL_GPL(pci_bus_max_busnr);
+EXPORT_SYMBOL_GPL(pci_find_capability);
+EXPORT_SYMBOL_GPL(pci_bus_find_capability);
+EXPORT_SYMBOL_GPL(pci_release_regions);
+EXPORT_SYMBOL_GPL(pci_request_regions);
+EXPORT_SYMBOL_GPL(pci_release_region);
+EXPORT_SYMBOL_GPL(pci_request_region);
+EXPORT_SYMBOL_GPL(pci_set_master);
+EXPORT_SYMBOL_GPL(pci_set_mwi);
+EXPORT_SYMBOL_GPL(pci_clear_mwi);
 EXPORT_SYMBOL_GPL(pci_intx);
-EXPORT_SYMBOL(pci_set_dma_mask);
-EXPORT_SYMBOL(pci_set_consistent_dma_mask);
-EXPORT_SYMBOL(pci_assign_resource);
-EXPORT_SYMBOL(pci_find_parent_resource);
-
-EXPORT_SYMBOL(pci_set_power_state);
-EXPORT_SYMBOL(pci_save_state);
-EXPORT_SYMBOL(pci_restore_state);
-EXPORT_SYMBOL(pci_enable_wake);
+EXPORT_SYMBOL_GPL(pci_set_dma_mask);
+EXPORT_SYMBOL_GPL(pci_set_consistent_dma_mask);
+EXPORT_SYMBOL_GPL(pci_assign_resource);
+EXPORT_SYMBOL_GPL(pci_find_parent_resource);
+
+EXPORT_SYMBOL_GPL(pci_set_power_state);
+EXPORT_SYMBOL_GPL(pci_save_state);
+EXPORT_SYMBOL_GPL(pci_restore_state);
+EXPORT_SYMBOL_GPL(pci_enable_wake);
 
 /* Quirk info */
 
-EXPORT_SYMBOL(isa_dma_bridge_buggy);
-EXPORT_SYMBOL(pci_pci_problems);
+EXPORT_SYMBOL_GPL(isa_dma_bridge_buggy);
+EXPORT_SYMBOL_GPL(pci_pci_problems);
--- gregkh-2.6.orig/drivers/pci/probe.c
+++ gregkh-2.6/drivers/pci/probe.c
@@ -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
--- gregkh-2.6.orig/drivers/pci/proc.c
+++ gregkh-2.6/drivers/pci/proc.c
@@ -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
 
--- gregkh-2.6.orig/drivers/pci/quirks.c
+++ gregkh-2.6/drivers/pci/quirks.c
@@ -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
--- gregkh-2.6.orig/drivers/pci/remove.c
+++ gregkh-2.6/drivers/pci/remove.c
@@ -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);
--- gregkh-2.6.orig/drivers/pci/rom.c
+++ gregkh-2.6/drivers/pci/rom.c
@@ -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);
--- gregkh-2.6.orig/drivers/pci/search.c
+++ gregkh-2.6/drivers/pci/search.c
@@ -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);
--- gregkh-2.6.orig/drivers/pci/setup-bus.c
+++ gregkh-2.6/drivers/pci/setup-bus.c
@@ -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)

Re: [RFC] Small PCI core patch

[Greg KH]

On Mon, Nov 21, 2005 at 02:53:03PM -0800, Greg KH wrote:
> Subject: PCI: fix up the exported symbols to be the proper license.

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

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

On Mon, 2005-11-21 at 15:01 -0800, Greg KH wrote:

> 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?

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.

Re: [RFC] Small PCI core patch

[Dave Airlie]

> 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.
>

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.

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 11:47 +1100, Dave Airlie wrote:
> 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

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

Re: [RFC] Small PCI core patch

[Jon Smirl]

On 11/21/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-11-22 at 11:47 +1100, Dave Airlie wrote:
> 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.

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
jonsmirl@gmail.com

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

> 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.

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.

Re: [RFC] Small PCI core patch

[Jon Smirl]

On 11/21/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 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...

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
jonsmirl@gmail.com

Re: [RFC] Small PCI core patch

[Rob Landley]

On Monday 21 November 2005 20:20, Jon Smirl wrote:
> On 11/21/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Maw, 2005-11-22 at 11:47 +1100, Dave Airlie wrote:
> > 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.
>
> 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.

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

Re: [RFC] Small PCI core patch

[Dave Airlie]

>
> 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 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.

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

On Tue, 2005-11-22 at 01:34 +0000, Alan Cox wrote:
> On Maw, 2005-11-22 at 11:47 +1100, Dave Airlie wrote:
> > 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
> 
> 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

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.

Re: [RFC] Small PCI core patch

[Jon Smirl]

On 11/21/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 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
> lawsuit, that is my opinion at least.

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
jonsmirl@gmail.com

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

On Mon, 2005-11-21 at 22:23 -0500, Jon Smirl wrote:
> On 11/21/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 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
> > lawsuit, that is my opinion at least.
> 
> 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.

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

> 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.

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.

Re: [RFC] Small PCI core patch

[Neil Brown]

On Monday November 21, jonsmirl@gmail.com wrote:
> 
> 2) Temporarily accept the ugly drivers. Let desktop development
> continue. Work hard on getting the vendors to see the light and go
> open source.

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

Re: [RFC] Small PCI core patch

[Denis Vlasenko]

On Tuesday 22 November 2005 06:11, Neil Brown wrote:
> 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.
[snip] 
> 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?

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

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 10:07:12AM +0200, Denis Vlasenko wrote:
> 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.

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

Re: [RFC] Small PCI core patch

[Rob Landley]

On Tuesday 22 November 2005 08:30, Jeff Garzik wrote:
> On Tue, Nov 22, 2005 at 10:07:12AM +0200, Denis Vlasenko wrote:
> > 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.
>
> 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.

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

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 10:33:48AM -0600, Rob Landley wrote:
> On Tuesday 22 November 2005 08:30, Jeff Garzik wrote:
> > On Tue, Nov 22, 2005 at 10:07:12AM +0200, Denis Vlasenko wrote:
> > > 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.
> >
> > 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.
> 
> 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...

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

Re: [RFC] Small PCI core patch

[Florian Weimer]

* Neil Brown:

> A question worth asking is: Who needs whom?  Do we (FLOSS community)
> need them (Graphics hardware manufactures) or do they need us?

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?

Re: [RFC] Small PCI core patch

[Adrian Bunk]

On Tue, Nov 22, 2005 at 03:11:52PM +1100, Neil Brown wrote:
> On Monday November 21, jonsmirl@gmail.com wrote:
> > 
> > 2) Temporarily accept the ugly drivers. Let desktop development
> > continue. Work hard on getting the vendors to see the light and go
> > open source.
> 
> 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.
>...
> 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.
>...

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.

> NeilBrown

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

Re: [RFC] Small PCI core patch

[Jesper Juhl]

On 11/22/05, Adrian Bunk <bunk@stusta.de> wrote:
> On Tue, Nov 22, 2005 at 03:11:52PM +1100, Neil Brown wrote:
> > On Monday November 21, jonsmirl@gmail.com wrote:
> > >
> > > 2) Temporarily accept the ugly drivers. Let desktop development
> > > continue. Work hard on getting the vendors to see the light and go
> > > open source.
> >
> > 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.
> >...
> > 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.
> >...
>
> 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.
>

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.


> 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.
>

--
Jesper Juhl <jesper.juhl@gmail.com>
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

Re: [RFC] Small PCI core patch

[Lee Revell]

On Wed, 2005-11-23 at 16:46 +0100, Jesper Juhl wrote:
> 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. 

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

Re: [RFC] Small PCI core patch

[Avi Kivity]

Jon Smirl wrote:

>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.
>
>  
>
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.

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 05:46:41PM +0200, Avi Kivity wrote:
> 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

Re: [RFC] Small PCI core patch

[Avi Kivity]

Jeff Garzik wrote:

>On Tue, Nov 22, 2005 at 05:46:41PM +0200, Avi Kivity wrote:
>  
>
>>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.
>
>  
>
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.

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 06:14:56PM +0200, Avi Kivity wrote:
> 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.

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

Re: [RFC] Small PCI core patch

[Avi Kivity]

Jeff Garzik wrote:

>On Tue, Nov 22, 2005 at 06:14:56PM +0200, Avi Kivity wrote:
>  
>
>>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.
>>    
>>
>
>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.
>  
>
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.

>Dumb with a capital 'D'.
>  
>
I hope you have a better solution.

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 06:40:20PM +0200, Avi Kivity wrote:
> Jeff Garzik wrote:
> 
> >On Tue, Nov 22, 2005 at 06:14:56PM +0200, Avi Kivity wrote:
> > 
> >
> >>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.
> >>   
> >>
> >
> >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.
> > 
> >
> I agree that the legal and political problems are real. I offered two 
> solutions to the technical problems.

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


> 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.

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


> >Dumb with a capital 'D'.
> > 
> >
> I hope you have a better solution.

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

	Jeff

Re: [RFC] Small PCI core patch

[Avi Kivity]

Jeff Garzik wrote:

>  
>
>>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.
>>    
>>
>
>VIA is working with open source community.  They are small enough
>(comparatively) that they need every advantage.  VIA is one of the
>positive examples.
>
>  
>
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.

>  
>
>>>Dumb with a capital 'D'.
>>>
>>>
>>>      
>>>
>>I hope you have a better solution.
>>    
>>
>
>Almost all of the solutions listed in this thread are better:
>Chinese wall rev-eng,
>
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.

> funding, ...
>  
>
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.

Re: [RFC] Small PCI core patch

[Brian Gerst]

Jeff Garzik wrote:
> On Tue, Nov 22, 2005 at 06:40:20PM +0200, Avi Kivity wrote:
>> Jeff Garzik wrote:
>>
>>> On Tue, Nov 22, 2005 at 06:14:56PM +0200, Avi Kivity wrote:
>>>
>>>
>>>> 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.
>>>>   
>>>>
>>> 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.
>>>
>>>
>> I agree that the legal and political problems are real. I offered two 
>> solutions to the technical problems.
> 
> And given real world experience with "solutions" like this, they cause
> more problems than they solve.
> 
> 
>> 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.
> 
> VIA is working with open source community.  They are small enough
> (comparatively) that they need every advantage.  VIA is one of the
> positive examples.
> 

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

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 12:37:54PM -0500, Brian Gerst wrote:
> 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.

Agreed.


> I have yet to see any AMD64 motherboards 
> with these chipsets either.

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

	Jeff

Re: [RFC] Small PCI core patch

[Avi Kivity]

Brian Gerst wrote:

> 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.

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.

Re: [RFC] Small PCI core patch

[Rogério Brito]

On Nov 22 2005, Jeff Garzik wrote:
> VIA is working with open source community.  They are small enough
> (comparatively) that they need every advantage.  VIA is one of the
> positive examples.

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 : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: [RFC] Small PCI core patch

[Alan Cox]

On Mer, 2005-11-23 at 08:51 -0200, Rogério Brito wrote:
> VIA? SiS? What manufacturers are really getting along with Open Source
> drivers (even if their products are not for "3l33t" users/gamers)?

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.

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 18:40 +0200, Avi Kivity wrote:
> 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.

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.

Re: [RFC] Small PCI core patch

[Avi Kivity]

Alan Cox wrote:

>On Maw, 2005-11-22 at 18:40 +0200, Avi Kivity wrote:
>  
>
>>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.
>>    
>>
>
>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.
>
>  
>
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.

Re: [RFC] Small PCI core patch

[Diego Calleja]

El Tue, 22 Nov 2005 18:14:56 +0200,
Avi Kivity <avi@argo.co.il> escribió:

> 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.

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...)

Re: [RFC] Small PCI core patch

[Avi Kivity]

Diego Calleja wrote:

>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...)
>  
>
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.

Re: [RFC] Small PCI core patch

[Diego Calleja]

El Tue, 22 Nov 2005 18:35:07 +0200,
Avi Kivity <avi@argo.co.il> escribió:


> 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.

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...)

>  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.

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.

Re: [RFC] Small PCI core patch

[Avi Kivity]

Diego Calleja wrote:

>El Tue, 22 Nov 2005 18:35:07 +0200,
>Avi Kivity <avi@argo.co.il> escribió:
>  
>
>>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.
>>    
>>
>
>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.
>
>  
>
None of the desktop Windows installations I'm aware of exhibit this. The 
recent versions of Windows are fairly stable.

>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.
>  
>
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 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.
>  
>
(The Linux driver does not fail, though)

>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...)
>
>  
>
Many people have hyperthreaded CPUs today.

>> 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.
>>    
>>
>
>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). 
>
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.

>Linux
>has beated companies like nvidia and ati in this field many times and
>can do it again.
>  
>
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.

Re: [RFC] Small PCI core patch

[Lee Revell]

On Tue, 2005-11-22 at 22:08 +0200, Avi Kivity wrote:
> I don't like to 
> admit it, but I had to fight to get my via video to work correctly. 

It works perfectly here.  This was a distro problem.

Lee

Re: [RFC] Small PCI core patch

[Diego Calleja]

El Tue, 22 Nov 2005 22:08:49 +0200,
Avi Kivity <avi@argo.co.il> escribió:


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

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


> Many people have hyperthreaded CPUs today.

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 ;)


> It works well on the server, where Linux has a large and rising market 

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.

Re: [RFC] Small PCI core patch

[Avi Kivity]

Diego Calleja wrote:

>El Tue, 22 Nov 2005 22:08:49 +0200,
>Avi Kivity <avi@argo.co.il> escribió:
>
>  
>
>>None of the desktop Windows installations I'm aware of exhibit this. The 
>>recent versions of Windows are fairly stable.
>>    
>>
>
>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
>
>  
>
Awsome. Certainly a very strong point against Windows drivers.

>  
>
>>Many people have hyperthreaded CPUs today.
>>    
>>
>
>Hypertreaded CPUs can't run the two virtual cpus at the same time,
>  
>
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.

>>It works well on the server, where Linux has a large and rising market 
>>    
>>
>
>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.
>  
>
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.

Re: [RFC] Small PCI core patch

[Jan Knutar]

On Tuesday 22 November 2005 18:35, you wrote:

> 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. 

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.

Re: [RFC] Small PCI core patch

[Marc Koschewski]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2005-11-22 13:27:57 +1100]:

> On Tue, 2005-11-22 at 01:34 +0000, Alan Cox wrote:
> > On Maw, 2005-11-22 at 11:47 +1100, Dave Airlie wrote:
> > > 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
> > 
> > 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
> 
> 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.

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

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

On Tue, 2005-11-22 at 15:07 +0100, Marc Koschewski wrote:

> 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... 

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.

Re: [RFC] Small PCI core patch

[Marc Koschewski]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2005-11-23 09:53:30 +1100]:

> On Tue, 2005-11-22 at 15:07 +0100, Marc Koschewski wrote:
> 
> > 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... 
> 
> 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.

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

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

> > 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.
> 
> I use xorg's 'nv' driver. That one is _not_ from nVidia, it it?

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.

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 13:27 +1100, Benjamin Herrenschmidt wrote:
> 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 would concur. Although one of the problems as I understand it is the
upcoming cards no longer have a 2D engine.

Re: [RFC] Small PCI core patch

[Greg KH]

On Tue, Nov 22, 2005 at 10:35:32AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-21 at 15:01 -0800, Greg KH wrote:
> 
> > 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?
> 
> I'm all about it, but good luck trying to convince ATI and/or nVidia ...

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

Re: [RFC] Small PCI core patch

[Chris Wedgwood]

On Tue, Nov 22, 2005 at 10:35:32AM +1100, Benjamin Herrenschmidt wrote:

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

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)

Re: [RFC] Small PCI core patch

[Greg KH]

On Mon, Nov 21, 2005 at 05:28:27PM -0800, Chris Wedgwood wrote:
> On Tue, Nov 22, 2005 at 10:35:32AM +1100, Benjamin Herrenschmidt wrote:
> 
> > I'm all about it, but good luck trying to convince ATI and/or
> > nVidia...
> 
> 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 :)

Re: [RFC] Small PCI core patch

[Arjan van de Ven]

On Tue, 2005-11-22 at 10:35 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-21 at 15:01 -0800, Greg KH wrote:
> 
> > 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?
> 
> I'm all about it, but good luck trying to convince ATI and/or nVidia ...

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.

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Tue, Nov 22, 2005 at 06:50:52AM +0100, Arjan van de Ven wrote:
> [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.

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

Re: [RFC] Small PCI core patch

[Jon Smirl]

On 11/21/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 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.

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
jonsmirl@gmail.com

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 11:54 -0500, Jon Smirl wrote:
> Removal of the 2D engines is a key vulnerability in the strategy of
> only using 2D on Linux.

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.

Re: [RFC] Small PCI core patch

[Brian Gerst]

Alan Cox wrote:
> On Maw, 2005-11-22 at 11:54 -0500, Jon Smirl wrote:
>> Removal of the 2D engines is a key vulnerability in the strategy of
>> only using 2D on Linux.
> 
> 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.

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

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 16:13 -0500, Brian Gerst wrote:
> 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.

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.

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

On Tue, 2005-11-22 at 11:54 -0500, Jon Smirl wrote:
> On 11/21/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 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.
> 
> 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.

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

> Removal of the 2D engines is a key vulnerability in the strategy of
> only using 2D on Linux.
> 
> --
> Jon Smirl
> jonsmirl@gmail.com

Re: [RFC] Small PCI core patch

[Rob Landley]

On Monday 21 November 2005 17:01, Greg KH wrote:
> On Mon, Nov 21, 2005 at 02:53:03PM -0800, Greg KH wrote:
> > Subject: PCI: fix up the exported symbols to be the proper license.
>
> 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.

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

Rob

Re: [RFC] Small PCI core patch

[Matthieu CASTET]

Hi,

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

> 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?
> 
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

Re: [RFC] Small PCI core patch

[Greg KH]

On Tue, Nov 22, 2005 at 07:26:55PM +0100, Matthieu CASTET wrote:
> Hi,
> 
> Le Mon, 21 Nov 2005 15:01:41 -0800, Greg KH a ?crit?:
> 
> > 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?
> > 
> Why not make a crappy GPL driver that just export again
> the symbols ?
> 
> MODULE_LICENSE("GPL");

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

thanks,

greg k-h

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 19:26 +0100, Matthieu CASTET wrote:
> Why not make a crappy GPL driver that just export again
> the symbols ?

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.

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

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

Alan

Re: [RFC] Small PCI core patch

[Andrew James Wade]

On Tuesday 22 November 2005 15:15, Alan Cox wrote:
> On Maw, 2005-11-22 at 19:26 +0100, Matthieu CASTET wrote:
> > Why not make a crappy GPL driver that just export again
> > the symbols ?
> 
> Because if you have to do tha your non GPL driver is a derivative work
> of your GPL driver ...

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

Re: [RFC] Small PCI core patch

[Jeff Garzik]

On Mon, Nov 21, 2005 at 02:53:03PM -0800, Greg KH wrote:
> Any objections to this?

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

	Jeff

Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt]

On Mon, 2005-11-21 at 14:53 -0800, Greg KH wrote:
> Any objections to this?

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.

Re: [RFC] Small PCI core patch

[Greg KH]

On Mon, Nov 21, 2005 at 02:53:03PM -0800, Greg KH wrote:
> Any objections to this?
> 
> thanks,
> 
> greg k-h
> 
> ---------------------
> 
> Subject: PCI: fix up the exported symbols to be the proper license.
> 
> 
> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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

Re: [RFC] Small PCI core patch

[Harald Dunkel]

Hi Greg,

Greg KH wrote:
> 
> 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.
> 

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

Re: [RFC] Small PCI core patch

[Alan Cox]

On Maw, 2005-11-22 at 23:31 +0100, Harald Dunkel wrote:
> 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.

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

Re: [RFC] Small PCI core patch

[Harald Dunkel]

Alan Cox wrote:
> 
> 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.
> 

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

Re: [RFC] Small PCI core patch

[Dave Jones]

On Wed, Nov 23, 2005 at 07:06:34AM +0100, Harald Dunkel wrote:
 
 > 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.

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

Re: [RFC] Small PCI core patch

[Alan Cox]

On Mer, 2005-11-23 at 01:26 -0500, Dave Jones wrote:
> 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."


3Dfx were bought by Nvidia.