Date: Sat, 10 Mar 2001 15:05:30 -0500 From: Dennis <dennis@etinc.com> To: wpaul@FreeBSD.ORG (Bill Paul) Cc: hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: if_fxp - the real point Message-ID: <5.0.0.25.0.20010310145045.023a41c0@mail.etinc.com> In-Reply-To: <20010310061124.E7AF437B718@hub.freebsd.org> References: <5.0.0.25.0.20010309204335.01fc2b00@mail.etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:11 AM 03/10/2001, Bill Paul wrote: > > > > I think its been mentioned several times in this and other threads that > > intel has a driver for LINUX that is effective documentation on the board, > > and the code is public (although you may have to stick an intel copyright > > in the code also). > >Whoever mentioned this was not thinking clearly. A manual is effective >documentation for a NIC. Sample driver code alone is not. It's handy, but >it's not enough. When you write a driver, you make certain design decisions >based on the information in the manual and the OS you're developing for. >By forcing someone to rely soley on your driver to see how the board >works, you're limiting their ability to make their own design decisions. >What works well for Windows or Linux may be mediocre for BSD. Besides, >Intel engineers have a knack for choosing really confusing register names. confusing or not, the logic to fix the driver is available. You can whine about there being "no full documentation", but guess what? FreeBSD doesnt have "full documentation" either. Do any of your drivers have "full documentation" for anyone that want to modify them? Fixing Greenman's driver is no party either as he hasnt documented any of the phy-related stuff he uses. >And again, saying "but there's a Linux driver" just gives vendors an >excuse to perpetuate their stupidity. I'm not keen to give them this >opportunity. You "guys" regularly say to me "you have the source, fix it". Source that works IS documentation. As someone whose read a few controller specs in my time, I can tell you that "full documentation" is sometimes a lot less useful than code that works, because the docs dont always make it clear what needs to be done to achieve a certain goal. > > > You guys continue not to understand why companies dont disclose board info > > freely. You end up competing with your own customers. They dont want > people > > buying gray market parts and selling $9. boards. Its very easy to clone a > > board with 2 chips on it these days. > >I'm sorry, that doesn't wash. *I* am not trying to compete with anyone. >Lord knows I can't afford to fabricate my own controller chips on my >salary. its not about you, man, its about the clone manufacturers that can make cards that use your or intel's drivers without any engineering. You dont have to "fabricate chips", you buy them from Intel. Thats what I mean by "competing with your own customers". Intel sells chips for $8. and boards for $32. they odnt want to have to compete with boards that sell for $12. with their $8. chips. Your lame argument might be that "they sell the chips anyway" , but that doesnt work, becuase they make money on the boards at 32 and dont at 12. Notice that there arent really any Intel eepro100 clones? Because intel makes sure that the spec isnt public, so they can go after anyone that clones them. Western Digital in the 80s learned the hard way. You do all the marketing, get software written for your cards, and then the taiwanese cash in on it and you have to lower your prices to where you cant make enough money to get back your marketing outlay. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.0.25.0.20010310145045.023a41c0>