|
From: Peter L. <P.L...@sy...> - 2002-08-21 18:07:31
|
Sorry, everyone, I sort of started this. :) > > 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. Misunderstanding on Mr Green's part. My suggestion was that the nvnetlib.o contains enough NIC API on to which we could glue an EB driver API (as suggested already). It seems to me that the *driver* is essentially open source, but that the minutiae of tweaking the NIC is enclosed in nvnetlib.o - I've never done an Etherboot polling driver before, but I've looked at enough NIC specs to guess that this is true, and my original post to suggest to the xbox-linux guys that, if possible, a This would seem reasonable, as well - after all hardware vendors tend to be obsessed only be hiding their hw interfaces; making life hard for the world is usually just a side-effect. And if we *do* hit any problems, we could just ask nVidia, no? At least lets give them opportunity to be helpful before assuming that they aren't. The LinuxBIOS experience is somethimes that asking hw vendors for specs means that the *spec* may be NDA'd even though the resulting source can be open. > > 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). The GPL is only "enforced" at the point of *distribution* (from reading http://emoglen.law.columbia.edu/publications/lu-12.html), but we are not claiming nvnetlib.o is GPL'd. It's nVidia's copyright, which they license as being OK for distribution in Linux related circumstances. The question is more does *Etherboot* tolerate being linked with such code? Actually, since EB can boot FreeDOS and maybe other things, I suppose it's not exclusively Linux related. :) > > In addition, has anyone made such a fake kernel API shell before? Has > > anyone looked at supporting nForce motherboards? I repeat that this was NOT my suggestion, but I believe OSkit does this. > 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). I can image that much of the nvnet.o might be bloat from Etherboot's POV, but as you say EB can hopefully cope. > 2. Is it possible to use the .o file to create a polling driver? > Etherboot doesn't use interrupts. Based on fairly cursory inspection, I'd guess yes. It may not be elegant, though, and I suspect the only authoritative answer is likely to be suck it and see. Several dozen people will now prove me wrong... > 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. :) |
|
From: Peter L. <P.L...@sy...> - 2002-08-21 18:51:39
|
> It seems I did misunderstand you here, however, I was imagining that > nvnetlib.o is full of APIs that take kernel-defined structs as > parameters, etc, and at least to this extent it will need to be kept > satisfied. I didn't make it too clear, but my cursory inspection did establish that the only linux related stuff seems to be the "driver" part, (nvnet.c nvnet.h os.h), and NOT the "NIC API" parts (basetype.h phy.h adapter.h). I'm basing my guesses to a significant degree on the "looks like they did the right thing, so they probably did" principle. We want to use the Linux driver as guide and then write an EB driver to the NIC's API. > Yes, this work should be equally applicable to the nForce motherboards, > in case the xbox is a bit contentious for them. Sure. I think Etherboot and LTSP are "respectable" enough. Also, if anyone out there has a non-Xbox mobo, it might make EB development a bit easier. > The .o can be kept at arms length from whatever shim is needed to > interface it to the etherboot stuff, I can imagine it can be distributed > in a way that nobody will be unhappy. And again, we can at least ask. They probably just don't know about EB. |
|
From: Andy G. <an...@wa...> - 2002-08-21 18:19:15
|
Peter Lister wrote: > Misunderstanding on Mr Green's part. My suggestion was that the > nvnetlib.o contains enough NIC API on to which we could glue an EB > driver API (as suggested already). It seems to me that the *driver* is > essentially open source, but that the minutiae of tweaking the NIC is > enclosed in nvnetlib.o - I've never done an Etherboot polling driver > before, but I've looked at enough NIC specs to guess that this is true, > and my original post to suggest to the xbox-linux guys that, if > possible, a It seems I did misunderstand you here, however, I was imagining that nvnetlib.o is full of APIs that take kernel-defined structs as parameters, etc, and at least to this extent it will need to be kept satisfied. > And if we *do* hit any problems, we could just ask nVidia, no? At least > lets give them opportunity to be helpful before assuming that they > aren't. The LinuxBIOS experience is somethimes that asking hw vendors > for specs means that the *spec* may be NDA'd even though the resulting > source can be open. Yes, this work should be equally applicable to the nForce motherboards, in case the xbox is a bit contentious for them. > The GPL is only "enforced" at the point of *distribution* (from reading > http://emoglen.law.columbia.edu/publications/lu-12.html), but we are not > claiming nvnetlib.o is GPL'd. It's nVidia's copyright, which they > license as being OK for distribution in Linux related circumstances. The > question is more does *Etherboot* tolerate being linked with such code? > > Actually, since EB can boot FreeDOS and maybe other things, I suppose > it's not exclusively Linux related. :) The .o can be kept at arms length from whatever shim is needed to interface it to the etherboot stuff, I can imagine it can be distributed in a way that nobody will be unhappy. -Andy |
|
From: Michael B. <mb...@fe...> - 2002-08-21 22:14:45
|
On Wed, 21 Aug 2002, Peter Lister wrote: > > 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). > I can image that much of the nvnet.o might be bloat from Etherboot's > POV, but as you say EB can hopefully cope. For the sake of the sanity of anyone who tries to develop this driver: >=20kB of driver code is almost certainly enough to make Etherboot 5.0.x simply die without warning at seemingly random points. I say this on the basis that 17kB of driver code (prism2_pci, prism2_plx and rtl8139 in the same build) produces these effects. This is due to the memory model in Etherboot 5.0.x. I would strongly recommend that anyone attempting to write this driver ignores the 5.0.x tree and works only on 5.1.x with the new memory architecture. *** DO NOT TRY TO GET THIS DRIVER TO WORK WITH ETHERBOOT 5.0.x *** Hopefully that might save someone a few days of pointless head-banging. :-) Michael Brown |
