Le mardi 07 décembre 2004 à 13:59 -1000, Dean Takemori a écrit : > On Dec 7, 2004, at 1:18 PM, Chris Howells wrote: > > > On Tuesday 07 December 2004 19:36, Jack Malmostoso wrote: > >> They supply a Linux driver that has to be compiled, so I think there > >> would > >> be no problem using it on PPC. that would be way too easy :) a fast glance at source shows some rare cases of asm usage (which could probably be avoided). grep "asm" on the content of source directory only shows one "do_div" macro which is a few lines of asm. shouldnt be too hard, and maybe the asm is gratuitous (at first sight) > > Unless it has been tested on PPC you can't assume this. Endianness may > > be an > > issue if the driver was developed on x86 or another little endian > > system > > unlike your Mac which is big endian. there is still the endianess issue. which is pretty big > Unfortunately it turns out that the driver will not compile > against the Yellowdog 4.0 (2.6.8-1.ydl.7) ppc kernel. I'm > no expert but in addition to probable endian problems, the > main issue appears to be x86 assumptions and asm usage. > > The driver _is_ under the GPL (v2), though. Hopefully that > means someone smarter and more experienced than I will be able > to put in the time to port the driver to PPC. yes it is under GPL which is the good thing, at least it shouldnt die. to blame the company who offered the driver some now ... FIRST, the "too bad for them" : the linux support is not to be seen on the website, not advertised anywhere. you have to KNOW that the adapter is linux supported and do a search in the support section.... googling for the model number or the chipset doesnot help at all to know that this adapter has GPL drivers which should be a hot selling point to me.... you only know it because you know it... and you are willing to experiment. on the technical point of view... ships in a zip file (i don't even have zip installed on my system) containing a readme(.dat!) and a tar.gz of the sources... gratuitous use of non linux file formats (not that you are required to name your text files .txt or without extension, but .dat... why?) ... the source feels pretty alien for linux code writing conventions... where "alien" is more specificaly : hungarian notation.... the few unhelpful comments in code are "constants here" with a nice ascii art... one big huge monolithic file.... custom Makefile to edit by hand.... tons of hardcoded stuff... tabsize=4 (they didnt read the "writing kernel code conventions howto"...)... the debug code is still there... with comments in front... and they ship with a monitor to hand test all the commands (ok this one is nice, but can do dangerous thing!) it feels like it has been slapped together with no input and not even reading how to write proper modules... i express doubt on it compiling on the next kernel versions, on non x86 kernels... to make it on the linux kernel a careful rewrite (and testing) is needed and the worst : google for it shows almost NO experience from anyone with the driver : http://www.google.fr/search?hl=fr&q=linux+planet +wl-u356&btnG=Rechercher&meta= 36 matches, none being user experiences http://www.google.fr/search?hl=fr&q=linux+zd1211&btnG=Rechercher&meta= = 52 matches, most being "does not compile" stuff. i'm worried about a driver written by one person, only tested on "red hat 9" as from the readme. with no user experience from outside. and no one knows about it so how will they buy it for the linux support.. too bad for them, a company that would sell a linux friendly 802.11g adapter would make a killing. -- Julien PERVILLE <julien.perville@free.fr>
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=