> Hi Ed, > good to see you still around here! I'm always lurking. :)
> On Sun, 2008-05-04 at 11:20 -0500, ext [EMAIL PROTECTED] wrote: >> > Hi, >> > >> > On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch <[EMAIL PROTECTED]> wrote: >> >> Am Sat, 03 May 2008 20:53:53 +0300 >> >> schrieb Igor Stoppa <[EMAIL PROTECTED]>: >> >> >> >>> > I disagree. Any closed part in a Linux system forces developers to >> >>> > implement stupid wrappers and workarounds somewhere. If I'm forced >> >>> > to use a certain kernel or glibc version, it's not an open system. >> >>> >> >>> Probably i was not clear: i'm just saying that if a new kernel comes >> >>> out and the only impediment in using it is that the proprietary >> >>> module is not compliant, a new module compiuled against the new >> >>> kernel should be made available. >> >> >> >> Proprietary modules are a GPL violation (though this is sometimes >> >> tolerated) and taint the kernel. You loose the kernel community's >> >> support if you use them. That support is more important than Nokia's >> >> support. >> >> >> >> And I doubt you can supply modules for all the kernel flavors out >> >> there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' >> >> git tree (changes every few hours), or linux-next (changes daily). >> >> >> > >> > Thats pretty much the key point for me in this discussion. >> > >> > If you really want to be able to foster an independent linux distro >> > (or more than one), then you need/want to be able to control and >> > upgrade your kernel. >> > >> > Most of the kernel and system components are open or enough is known >> > to provide basic usage, but an 'internet tablet' with proprietary wifi >> > firmware that is not accessible in newer kernel version is a killer. >> > At the moment i am happy with usb networking for my experiments with >> > newer kernels, but the basic function of the device is crippled. >> > >> > Not complaining, and I do not know if it is feasible to supply builds >> > of umac.ko for later kernel versions, but I think this is a barrier to >> > really fostering a 'community distro'. >> >> A possible interim solution is to use one like nVidia has used for years >> for their closed video card drivers. Provide a binary object that >> implements all the core functionality of the chip, with a public API. >> Then have an open source kernel module wrapper that calls the funcions >> in >> the public API of the binary module. Then the open source part can be >> compiled for any kernel version and simply link in the closed object. >> Not >> an ideal model, but one that solves the problem of legacy hardware that >> vendors will not allow releasing info on. > > Indeed; I also think it would not be a big deal to setup daily/nightly > builds of this module, once the source trees have been identified - I > don't expect them to be too many. > > That's something much more practical and easier to achieve than "release > all the code, including what is not under your direct control". > > If the solution to ease the pain of development is one script away, i > guess it shouldn't be too hard to implement and too unreasonable to > demand that Nokia provides it as proof of goodwill. > > Of course those who are interested in wifi development would still have > reasons to complain, but the majority of developers would see the > obstacle removed. It should be possible to make the public API very close to the capabilities of the chip, so even wifi developers could focus on higher level things and not be too disappointed. But the key point is that it would make it trivial for the general users to upgrade their kernel without loosing functionality. When I wrote the drivers for the Quicknet telephony cards, they initially did not want to open source the drivers, so we did a similar wrapper scheme. Later when they decided to integrate their drivers into the kernel it was a simple task of merging the previously closed object with the open kernel module. Ed Okerson _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
