Thread: [Etherboot-developers] Question on supporting nVidia .o driver
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Andy G. <an...@wa...> - 2002-08-21 15:44:42
|
Over at the xbox linux project there is some discussion today about supporting the nVidia inside the xbox (and used on nForce motherboards) Ethernet controller with an etherboot driver. The issue is that nVidia supply a .o file containing all the goodies; it is believed to be quite possible to fake up something using the kernel network API to use this and make it believe it was a kernel driver. The main question is, what's the prevailing opinion about using a .o in this way GPL-wise. It has been suggested that we'll be okay if we do not distribute the .o but make our GPL project consist of everything but. (Because we are running on the xbox only, portability is not a concern). In addition, has anyone made such a fake kernel API shell before? Has anyone looked at supporting nForce motherboards? -Andy |
|
From: Milosch M. <xbo...@me...> - 2002-08-21 15:55:26
|
Am Mittwoch, 21. August 2002 17:47 schrieb Andy Green: > In addition, has anyone made such a fake kernel API shell before? Has > anyone looked at supporting nForce motherboards? You don't need a kernel API - you can directly link to nvnetlib.o - nvnet= =2Ec is=20 a excellent reference document for this. -- Milosch |
|
From: Andy G. <an...@wa...> - 2002-08-21 16:02:52
|
Milosch Meriac wrote: > Am Mittwoch, 21. August 2002 17:47 schrieb Andy Green: > >>In addition, has anyone made such a fake kernel API shell before? Has >>anyone looked at supporting nForce motherboards? > > > You don't need a kernel API - you can directly link to nvnetlib.o - nvnet.c is > a excellent reference document for this. Milosch, that's a great point, nvnet.c is a perfect example of how to use the .o, we don't need to worry too much about faking up an environment that nvnetlib.o will find acceptable. -Andy |
|
From: Michael B. <mb...@fe...> - 2002-08-21 16:06:54
|
On Wed, 21 Aug 2002, Andy Green wrote: > Over at the xbox linux project there is some discussion today about > supporting the nVidia inside the xbox (and used on nForce motherboards) > Ethernet controller with an etherboot driver. > The issue is that nVidia supply a .o file containing all the goodies; it > is believed to be quite possible to fake up something using the kernel > network API to use this and make it believe it was a kernel driver. > The main question is, what's the prevailing opinion about using a .o in > this way GPL-wise. It has been suggested that we'll be okay if we do > not distribute the .o but make our GPL project consist of everything > but. (Because we are running on the xbox only, portability is not a > concern). > In addition, has anyone made such a fake kernel API shell before? Has > anyone looked at supporting nForce motherboards? Aside from the legal / copyright issues, a few technical points spring to mind: 1. The nVidia .o file is 20kB in size - around 4-5 times the size of most of the Etherboot drivers. This might be enough to prevent it working in 5.0.x (AFAICT, the memory-map changes in the 5.1.x branch will fix this anyway). 2. Is it possible to use the .o file to create a polling driver? Etherboot doesn't use interrupts. 3. As others have said, don't bother faking a kernel network API - just take the skeleton Etherboot driver in skel.c and fill out the gaps between that and the nVidia .o file. Michael Brown http://www.fensystems.co.uk |
|
From: Eric W B. <ebi...@ln...> - 2002-08-21 18:12:12
|
Michael Brown <mb...@fe...> writes: > On Wed, 21 Aug 2002, Andy Green wrote: > > Over at the xbox linux project there is some discussion today about > > supporting the nVidia inside the xbox (and used on nForce motherboards) > > Ethernet controller with an etherboot driver. > > The issue is that nVidia supply a .o file containing all the goodies; it > > is believed to be quite possible to fake up something using the kernel > > network API to use this and make it believe it was a kernel driver. > > The main question is, what's the prevailing opinion about using a .o in > > this way GPL-wise. It has been suggested that we'll be okay if we do > > not distribute the .o but make our GPL project consist of everything > > but. (Because we are running on the xbox only, portability is not a > > concern). > > In addition, has anyone made such a fake kernel API shell before? Has > > anyone looked at supporting nForce motherboards? > > Aside from the legal / copyright issues, a few technical points spring > to mind: > > 1. The nVidia .o file is 20kB in size - around 4-5 times the size of most > of the Etherboot drivers. This might be enough to prevent it working > in 5.0.x (AFAICT, the memory-map changes in the 5.1.x branch will fix > this anyway). This assumes the appropriate virt_to_bus, bus_to_virt and ioremap calls are being made. Otherwise it try reading and writing to the wrong registers. > > 2. Is it possible to use the .o file to create a polling driver? > Etherboot doesn't use interrupts. Plus having code you can change is much more maintainable. > 3. As others have said, don't bother faking a kernel network API - just > take the skeleton Etherboot driver in skel.c and fill out the gaps > between that and the nVidia .o file. Eric |
|
From: Stefan R. <st...@su...> - 2002-08-22 08:35:43
|
* Eric W Biederman <ebi...@ln...> [020821 20:12]: > > Aside from the legal / copyright issues, a few technical points spring > > to mind: > > > > 1. The nVidia .o file is 20kB in size - around 4-5 times the size of most > > of the Etherboot drivers. This might be enough to prevent it working > > in 5.0.x (AFAICT, the memory-map changes in the 5.1.x branch will fix > > this anyway). > > This assumes the appropriate virt_to_bus, bus_to_virt and ioremap calls > are being made. Otherwise it try reading and writing to the wrong > registers. Would a driver working in Linux not always require the virt_to_bus address shifting? > > 3. As others have said, don't bother faking a kernel network API - just > > take the skeleton Etherboot driver in skel.c and fill out the gaps > > between that and the nVidia .o file. Not faking the kernel api, but faking the api that nvidia uses in it's wrapper and on the other side, implementing a suitable etherboot api grip. Best regards, Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) |
|
From: Eric W B. <ebi...@ln...> - 2002-08-22 13:28:25
|
Stefan Reinauer <st...@su...> writes: > * Eric W Biederman <ebi...@ln...> [020821 20:12]: > > > Aside from the legal / copyright issues, a few technical points spring > > > to mind: > > > > > > 1. The nVidia .o file is 20kB in size - around 4-5 times the size of most > > > of the Etherboot drivers. This might be enough to prevent it working > > > in 5.0.x (AFAICT, the memory-map changes in the 5.1.x branch will fix > > > this anyway). > > > > This assumes the appropriate virt_to_bus, bus_to_virt and ioremap calls > > are being made. Otherwise it try reading and writing to the wrong > > registers. > > Would a driver working in Linux not always require the virt_to_bus > address shifting? There is a fairly big difference between virt_to_bus, and pci_alloc_consistent. A modern Linux driver will use pci_alloc_consistent. Plus if the abstraction is poor nvidia could be making assumptions about how Linux implements virt_to_bus which is totally different from the etherboot implementation. The reason etherboot can get away with virt_to_bus is that when it is ported I can essentially do pci_alloc_consistent on the entire etherboot image. At least that is the plan. Eric |
|
From: Richard A. B. <ric...@ho...> - 2002-08-23 09:36:18
|
----- Original Message ----- From: "Andy Green" <an...@wa...> To: <eth...@li...> Cc: <Xbo...@li...> Sent: Wednesday, August 21, 2002 4:47 PM Subject: [Xbox-linux] Question on supporting nVidia .o driver > The main question is, what's the prevailing opinion about using a .o in > this way GPL-wise. It has been suggested that we'll be okay if we do > not distribute the .o but make our GPL project consist of everything > but. (Because we are running on the xbox only, portability is not a > concern). From http://www.codelearn.com/cpp/gnutools/node56.html "Some people feel that linking to the library dynamically avoids making the executable derived work of the library. A dynamically linked executable does not embed a copy of the library. Instead, it contains code for loading the library from the disk during run-time. However, the executable is still derived work. The law makes no distinction between static linking and dynamic linking. So, when you compile an executable and you link it dynamically to a GPLed library, the executable must be distributed as free software with the library. This also means that you can not link dynamically both to a GPLed library and a proprietary library because the licenses of the two libraries conflict." If that is the case, it doesn't appear to matter if you distribute the library or not, the fact that you intend to link with it makes it a derived work. The suggested work around is to use something else, or get the maker of the library to release it under the GPL - great work arounds, why didn't we think of these! :-). "Note that there is no conflict when a GPLed utility is invoked by a proprietary program or vice versa via a system () call." Can we modprobe/insmod from a system call to load the module? That would bring us to this: "However, a free program that depends on a proprietary program for its operation can not be included in a free operating system, because the proprietary program would also have to be distributed with the system." Hence the not distributing the .o file idea. Has anyone actually spoken to a Legal expert on this? Or someone from GNU/FSF? They may be able to clear it up once and for all. If there is a licence conflict, hasn't it already been broken by the distribution of nvnet.o with the current version of xbox linux? And are we just looking at getting a replacement driver from the etherboot project? Or are we looking at remote booting the xbox? I'd be happier with a standalone box, not dependant on being served it's boot image. I hope that will still be an option. Richard. |
|
From: Stefan R. <st...@su...> - 2002-08-23 10:32:34
|
* Richard Antony Burton <ric...@ho...> [020823 11:35]: > >From http://www.codelearn.com/cpp/gnutools/node56.html > > "Some people feel that linking to the library dynamically avoids making the > executable derived work of the library. A dynamically linked executable does > not embed a copy of the library. Instead, it contains code for loading the > library from the disk during run-time. However, the executable is still > derived work. This would mean that a) You're not allowed to boot Windows using Lilo b) You're not allowed booting Windows CE using LinuxBIOS. The border is pretty philosophical I guess. But still. As long as the closed source blob would not call symbols from it's "loader", but just gets parsed and executed, this is not a library. The missing memcpy could be linked against the nv module (Thus creating a non-GPLed memcpy function before to avoid license problems) When the loader functionality is generic enough to only interact as a intermediate boot API layer, "using" the nv object as data. Otherwise I would not be allowed to write closed source commercial software when using vim. Or am I completely wrong? > "Note that there is no conflict when a GPLed utility is invoked by a > proprietary program or vice versa via a system () call." Can we > modprobe/insmod from a system call to load the module? That would bring us > to this: "However, a free program that depends on a proprietary program for > its operation can not be included in a free operating system, because the > proprietary program would also have to be distributed with the system." > Hence the not distributing the .o file idea. It would be enough though to show the functionality of the link layer by having one example where an open source driver uses this as well. Whether this example actually works should not even matter as long as it is there and shows the principles. There is no law telling that the software I give out for free is forced to be fully operational > If there is a licence conflict, hasn't it already been broken by the > distribution of nvnet.o with the current version of xbox linux? Probably, yes. SuSE does not deliver this with it's distribution, but rather contains a bunch of scripts downloading it for you. Same applies for some Truetype Fonts (here you even have to acknowledge the licenses to these) > And are we just looking at getting a replacement driver from the etherboot > project? Or are we looking at remote booting the xbox? I'd be happier with a > standalone box, not dependant on being served it's boot image. I hope that > will still be an option. remote booting is the way to go as long as you develop the basic system functionality. As soon as it's possible to install Linux natively you will very likely not need it. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) |
|
From: Andy G. <an...@wa...> - 2002-08-23 10:39:57
|
Stefan Reinauer wrote: >>If there is a licence conflict, hasn't it already been broken by the >>distribution of nvnet.o with the current version of xbox linux? > > > Probably, yes. SuSE does not deliver this with it's distribution, but > rather contains a bunch of scripts downloading it for you. Same applies > for some Truetype Fonts (here you even have to acknowledge the licenses > to these) :-( This discussion doesn't seem to be helping. nVidia put their object code driver out for use by the free software community, we're using it. They didn't want to share (for their own stupid reasons) information about the register-level detail of the chip. We are respecting that. And frankly if the GPL is trying to tell me that I CAN'T make a GPL project that interoperates with a .o file, yet does not include as part of the project, then something is busted with the GPL and we should release under a GPL.xboxlinux license which is exactly the same but allows this. Andy's brain says: ignore all this pointless nonproductive amateur lawyer crud and if someone feels we're doing them down they can say and we will react. In the meanwhile, do the needful. I can see why the GPL might want to encourage totally clean licenses and no funny dependences. But in our situation, with an externally mandated box and the one architechture to get going, its just burdensome. >>And are we just looking at getting a replacement driver from the etherboot >>project? Or are we looking at remote booting the xbox? I'd be happier with a >>standalone box, not dependant on being served it's boot image. I hope that >>will still be an option. > > remote booting is the way to go as long as you develop the basic system > functionality. As soon as it's possible to install Linux natively you > will very likely not need it. Etherboot will be another way to bring up the box under user control, that's all. Its not removing choices but adding them. It seems from the people using what it out there so far the CD boot route is currently preferred. In the future we will be installing a distro to HDD too. Personally I am an embedded trog and I am booting it from the flash (although I will probably move to Etherboot thus removing space problems). So whatever you like it will still be there. -Andy |
|
From: Richard A. B. <ric...@ho...> - 2002-08-23 10:51:19
|
----- Original Message ----- From: "Stefan Reinauer" <st...@su...> To: "Richard Antony Burton" <ric...@ho...> Cc: "Andy Green" <an...@wa...>; <eth...@li...>; <Xbo...@li...> Sent: Friday, August 23, 2002 11:27 AM Subject: Re: [Xbox-linux] Question on supporting nVidia .o driver > * Richard Antony Burton <ric...@ho...> [020823 11:35]: > > "Some people feel that linking to the library dynamically avoids making the > > executable derived work of the library. A dynamically linked executable does > > not embed a copy of the library. Instead, it contains code for loading the > > library from the disk during run-time. However, the executable is still > > derived work. > > This would mean that > a) You're not allowed to boot Windows using Lilo > b) You're not allowed booting Windows CE using LinuxBIOS. Surely here the boot loader isn't making use of the code that it links too. I think it would be stretch of the imagination to say a bootloader is a derived work of the operating system (which ever it happens to be booting). Also what the user chooses to boot, is up to the user, and not then distributed in some form based on it. I think I'm right in saying you can do what you like with GPL software on your own PC, so long as you aren't intending distributing it. I guess the quote given doesn't actually exclude your example, but perhaps it is slightly out of context. > The border is pretty philosophical I guess. But still. As long as > the closed source blob would not call symbols from it's "loader", but > just gets parsed and executed, this is not a library. But we make use of it's functions. We load it so we can use networking, so isn't it acting as a library for us? > The missing > memcpy could be linked against the nv module (Thus creating a non-GPLed > memcpy function before to avoid license problems) > When the loader functionality is generic enough to only interact as > a intermediate boot API layer, "using" the nv object as data. Doesn't your additional loader layer then become governed (forcefully) by the GPL, leaving you back at the same point again. You can't just create a layer for all the GPL software, make that layer non-GPL and then do what you like through the layer. If you try, the layer has become GPL too, gaining you nothing. > It would be enough though to show the functionality of the link layer > by having one example where an open source driver uses this as well. > Whether this example actually works should not even matter as long as > it is there and shows the principles. There is no law telling that the > software I give out for free is forced to be fully operational You mean make your own GPL verison of vmnet.o (for distribution with xbox linux) that has the same interface, but doesn't do anything. Then if users choose to replace that with the real version it's out of your hands? I guess that might work, but it's deceptive and not in the spirit of the GPL. (Which I might add I'm not a fan of, so yeah, I like your plan!) Richard. |
|
From: Donald J C. <dj...@ci...> - 2002-08-23 14:41:49
|
Richard Antony Burton wrote: > > ----- Original Message ----- > From: "Andy Green" <an...@wa...> > To: <eth...@li...> > Cc: <Xbo...@li...> > Sent: Wednesday, August 21, 2002 4:47 PM > Subject: [Xbox-linux] Question on supporting nVidia .o driver ... > So, when you compile an executable and you link it > dynamically to a GPLed library, the executable must be distributed as free > software with the library. This makes perfect sense, since the executable would not function without the GPLed library. > This also means that you can not link dynamically > both to a GPLed library and a proprietary library because the licenses of > the two libraries conflict." This, on the other hand, does not make any sense at all, and I bet that it would not stand up to a legal test (but IANAL). The GPLed library is not required to make the proprietary library function. The license of the proprietary library makes no restrictions on other libraries that might also be linked to the executable. I can't see how the GPL can extend from a library up into an executable and then down into another library. In a sense, the two libraries are not being linked together, they just happen to both be linked to a common executable. As someone else said, if the GPL does try to do this, then it is broken. I suspect there are no end of examples of GPLed code that links to the proprietary C libraries of various systems. IIRC, gcc linked with the system C library for a long time before the Gnu C library was an adequate replacement. -Don -- Don Christensen Senior Software Development Engineer dj...@ci... Cisco Systems, Santa Cruz, CA "It was a new day yesterday, but it's an old day now." |
|
From: Robert C. <lif...@bi...> - 2002-08-23 15:31:03
|
On Sat, 2002-08-24 at 00:41, Donald J Christensen wrote: > Richard Antony Burton wrote: > > This also means that you can not link dynamically > > both to a GPLed library and a proprietary library because the licenses of > > the two libraries conflict." > > This, on the other hand, does not make any sense at all, and I bet that > it would not stand up to a legal test (but IANAL). The GPLed library is > not required to make the proprietary library function. AFAIK you are correct. The GPL can not, and does not prevent the use of proprietary libraries by the author of a GPL program. In fact, the GPL itself does not mention libraries at all. (http://www.gnu.org/licences/gpl.html). > The license of the proprietary library makes no restrictions on other > libraries that might also be linked to the executable. Actually, a licence can do just about anything that the licensor can get the licencee to agree to. See for example MS's exluding the use of GPL'd *tools* with it's winCE SDK. No grepping in this source!. However, for the case *in discussion* I haven't read the NVidia licence, but assume that it is friendly enough to permit use with linux :}, and therefor this project. > I can't see how > the GPL can extend from a library up into an executable and then down into > another library. In a sense, the two libraries are not being linked > together, they just happen to both be linked to a common executable. The GPL doesn't try to extend intoo the other library. (assuming use of a GPL library, not a new author deciding what to do): The GPL only has power over code *you* create. It can't influence something a third party has created. What it can do is prevent you from violating the only-use-this-code-if-you-release-your-own rule that applies to the GPL library. Specifically, see section 3 of the GPL. (I won't quote here for brevity.) If you are unable to provide the full source for the executable excluding *normally distributed components of the OS*, then you can not use the GPL'd library XOR you cannot 'distribute' the product (because it is a derived work from the library - yuck). This means that if that proprietary library that you want to use, is not part of the OS... it's going to prevent you complying with section 3 UNLESS you get an excemption - see below. Note: under no circumstances does the GPL ask that the licence on the proprietart library be changed, only that the code author make a choice. > As someone else said, if the GPL does try to do this, then it is broken. > I suspect there are no end of examples of GPLed code that links to the > proprietary C libraries of various systems. These are covered by 'normally distributed components'. > IIRC, gcc linked with the > system C library for a long time before the Gnu C library was an > adequate replacement. There is an important thing to add here: The author of any given work can create an excemption in the GPL to allow linking with specific (or generic) proprietary libraries. There was some relicencing fuss with GPL projects that use libssl for just this reason recently IIRC. cygwin1.dll, which is a GPL C-and-a-bit library for win32, creates a specific excemption to the GPL for and 'open source compliant' licence (ie the X licence). For the code that will use the Nvidia blob, the author can create such an exclusion. If no one here will be that author, or it will be a derived work, or need pure GPL, non OS standard libraries available, then you need to write to the original author(s) and get an excemption. http://www.gnu.org/licenses/gpl-faq.html may be of interest to you folk. Or you could email RMS and get a specific answer for what you want to accomplish. Rob |
