Re: [OT] Re: Intel driver doc's Take 2.
On Tue, 3 Apr 2001, Dennis wrote: * Dennis ([EMAIL PROTECTED]) [010403 18:17]: [stuff] Just a reminder: estinc.com is NOT the same domain name as etinc.com and the opinions of employees and management at Enhanced Software Technologies Inc. (estinc.com) have nothing to do with etinc.com . Just clearing up possible confusion there (due to 1 character difference in domain name). -- Eric Lee Green [EMAIL PROTECTED] Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] Re: Intel driver doc's Take 2.
At 03:59 PM 04/04/2001, Eric Lee Green wrote: On Tue, 3 Apr 2001, Dennis wrote: * Dennis ([EMAIL PROTECTED]) [010403 18:17]: [stuff] Just a reminder: estinc.com is NOT the same domain name as etinc.com and the opinions of employees and management at Enhanced Software Technologies Inc. (estinc.com) have nothing to do with etinc.com . Just clearing up possible confusion there (due to 1 character difference in domain name). is this still going on? lol To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 06:17 PM 04/03/2001, T. William Wells wrote: Its not a "proprietary tree". I dont have time to clean it up and submit patches. But you do seem to have time to keep arguing with people??? I'm sure you'll have time to bitch again if 4.4 doesn't meet your needs because you didn't submit some patch you needed. Only because the same morons (like yourself) continue ad infinitum to post your useless comments publicly. I am opposed to supporting individuals or corporations whose principals cannot manage simple disagreements with civility. It makes it clear what the consequences will be _to me_ should I, in my capacity as consultant, ever have a dispute with such an individual or organization. I don't need that sort of stress nor would I be willing to expose my clients to such behavior. Nor do we, as a corporation, need the stress of dealing with customers with such attitudes. So it works out, doesnt it? When are you going to get it into your heads? You are not supporting me by buying what we sell. You are making a business decision, paying a price because you believe the product has at least the value of the price to you. This "consumer" attitude that you are doing a company a favor by buying something from them is completely misguided. Most companies are not some ISP or consultant struggling to pay its bills. WE are doing you a favor by making our technology available to you at a fair price. If you dont see it that way, then you have a serious problem. Because Cisco, and Intel, and 3Com and yes, Emerging Technologies will survive without your business and your attitude. We dont expect to make every sale. This is why, unless there is no reasonable alternative, your products will not be on my short-list of solutions. Ok, and unless we are totally desperate for cash (dont count on it) we wont sell anything to you. Deal? You've just made a world class business decision. Burning bridges with a vendor that you may someday need is absolutely brilliant. Now lets drop it and get back to work. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[OT] Re: Intel driver doc's Take 2.
* Dennis ([EMAIL PROTECTED]) [010403 18:17]: I am opposed to supporting individuals or corporations whose principals cannot manage simple disagreements with civility. It makes it clear what the consequences will be _to me_ should I, in my capacity as consultant, ever have a dispute with such an individual or organization. I don't need that sort of stress nor would I be willing to expose my clients to such behavior. [...] This "consumer" attitude that you are doing a company a favor by buying something from them is completely misguided. Most companies are not some ISP or consultant struggling to pay its bills. WE are doing you a favor by making our technology available to you at a fair price. If you dont see it that way, then you have a serious problem. Because Cisco, and Intel, and 3Com and yes, Emerging Technologies will survive without your business and your attitude. We dont expect to make every sale. [...] Ok, and unless we are totally desperate for cash (dont count on it) we wont sell anything to you. Deal? You've just made a world class business decision. Burning bridges with a vendor that you may someday need is absolutely brilliant. Can you go ahead and put me on that list of bridge burners too? Thanks. Rick -- Rick Bradley - http://xns.org/=roundeye To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
| Ok, and unless we are totally desperate for cash (dont count on it) we wont | sell anything to you. Deal? You've just made a world class business | decision. Burning bridges with a vendor that you may someday need is | absolutely brilliant. Cool, can I please go on the list of people you won't sell things to? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
The message referred to below was sent by me in *PRIVATE E-MAIL*. Dennis [EMAIL PROTECTED] posted that private e-mail to this public forum. He did not have my permission to do so. (But, yes, I stand by my sentiments -- I just didn't want them further cluttering this list.) From [EMAIL PROTECTED] Tue Apr 3 20:12:43 EDT 2001 Article: 12476 of local.freebsd.hackers: Path: twwells.com!newsgate!nowhere Newsgroups: local.freebsd.hackers From: Dennis [EMAIL PROTECTED] Subject: Re: Intel driver doc's Take 2. Date: Tue, 03 Apr 2001 19:33:27 -0400 References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Lines: 51 Xref: twwells.com local.freebsd.hackers:12476 At 06:17 PM 04/03/2001, T. William Wells wrote: ...but you've already seen that To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Folks- I've said it before. Just ignore Dennis and let the topic die. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 07:37 PM 04/03/2001, you wrote: | Ok, and unless we are totally desperate for cash (dont count on it) we wont | sell anything to you. Deal? You've just made a world class business | decision. Burning bridges with a vendor that you may someday need is | absolutely brilliant. Cool, can I please go on the list of people you won't sell things to? You're already on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 08:24 PM 04/03/2001, T. William Wells wrote: The message referred to below was sent by me in *PRIVATE E-MAIL*. Dennis [EMAIL PROTECTED] posted that private e-mail to this public forum. He did not have my permission to do so. (But, yes, I stand by my sentiments -- I just didn't want them further cluttering this list.) sorry, everything in my hackers mailbox gets copied to the list. You didnt have permission to send me private email, so dont do it again. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] Re: Intel driver doc's Take 2.
At 07:30 PM 04/03/2001, Rick Bradley wrote: * Dennis ([EMAIL PROTECTED]) [010403 18:17]: I am opposed to supporting individuals or corporations whose principals cannot manage simple disagreements with civility. It makes it clear what the consequences will be _to me_ should I, in my capacity as consultant, ever have a dispute with such an individual or organization. I don't need that sort of stress nor would I be willing to expose my clients to such behavior. [...] This "consumer" attitude that you are doing a company a favor by buying something from them is completely misguided. Most companies are not some ISP or consultant struggling to pay its bills. WE are doing you a favor by making our technology available to you at a fair price. If you dont see it that way, then you have a serious problem. Because Cisco, and Intel, and 3Com and yes, Emerging Technologies will survive without your business and your attitude. We dont expect to make every sale. [...] Ok, and unless we are totally desperate for cash (dont count on it) we wont sell anything to you. Deal? You've just made a world class business decision. Burning bridges with a vendor that you may someday need is absolutely brilliant. Can you go ahead and put me on that list of bridge burners too? You guys are so pathetic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Tue, 3 Apr 2001, Dennis wrote: This "consumer" attitude that you are doing a company a favor by buying something from them is completely misguided. Most companies are not some ISP or consultant struggling to pay its bills. WE are doing you a favor by making our technology available to you at a fair price. Yeah yeah, companies are there for the stockholders. Screw the customers. While this is a nice short-term business plan, I'm really curious how this social experiment will end up in the long run. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Fri, Mar 30, 2001 at 08:49:55PM +0100, Koster, K.J. wrote: Its not a "proprietary tree". I dont have time to clean it up and submit patches. But you do seem to have time to keep arguing with people??? I'm sure you'll have time to bitch again if 4.4 doesn't meet your needs because you didn't submit some patch you needed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 02:18 PM 03/31/2001, David O'Brien wrote: On Fri, Mar 30, 2001 at 08:49:55PM +0100, Koster, K.J. wrote: Its not a "proprietary tree". I dont have time to clean it up and submit patches. But you do seem to have time to keep arguing with people??? I'm sure you'll have time to bitch again if 4.4 doesn't meet your needs because you didn't submit some patch you needed. Only because the same morons (like yourself) continue ad infinitum to post your useless comments publicly. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
[trying to move this off -hackers] If memory serves me right, Dennis wrote: At 02:18 PM 03/31/2001, David O'Brien wrote: On Fri, Mar 30, 2001 at 08:49:55PM +0100, Koster, K.J. wrote: Its not a "proprietary tree". I dont have time to clean it up and submit patches. But you do seem to have time to keep arguing with people??? I'm sure you'll have time to bitch again if 4.4 doesn't meet your needs because you didn't submit some patch you needed. Only because the same morons (like yourself) continue ad infinitum to post your useless comments publicly. As they say, it takes two to tango. About ten messages ago you asked if someone could just let this thread die. Why don't you take the lead on this and be that person? I'm asking nicely and sincerely. That ought to count for something. Thanks, Bruce. PGP signature
Re: Intel driver doc's Take 2.
wrt- Dennis [EMAIL PROTECTED]- he doesn't think much of people here, and is abusive. Let's just move on and let him go find other folks to pick fights with. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Amen! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Intel driver doc's Take 2.
Its not a "proprietary tree". I dont have time to clean it up and submit patches. Please mail me your pci/if_fxp* just as they are and I wil clean up and submit patches in your name. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: old business (was Re: Intel driver doc's Take 2.)
At 12:50 PM 03/25/2001, Matthew Jacob wrote: On Sat, 24 Mar 2001, Dennis wrote: If the if_wx driver sucks, why not fix it rather than trying to coerce a mega-companies with a deep political structure to change is policies? But if youre not going to maintain it, dont do it at all. You cant stick it to users by deciding later that you dont want to support it anymore. I am going to fix it (but this has been low on my priority list- you got the bucks to pay for this, buddy, and make it more attractive then the other things I'm currently getting paid to work on? money talks...), and I *also* am trying to change Intel's policy. If I pay for it, I own it. Thats the caveat of "open-source" db To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 07:47 PM 03/24/2001, you wrote: On 24 Mar 2001, at 19:59, Dennis wrote: the only thing more annoying the 2 people having a discussion is a third person telling them to stop. Feel free not to read any more messages in this thread. Feel free to read the list charter. You two are in a pissing contest unreleated to this list. Please take it elsewhere. We are discussing the issue. TOO BAD if you dont like it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: old business (was Re: Intel driver doc's Take 2.)
At 12:50 PM 03/25/2001, Matthew Jacob wrote: On Sat, 24 Mar 2001, Dennis wrote: If the if_wx driver sucks, why not fix it rather than trying to coerce a mega-companies with a deep political structure to change is policies? But if youre not going to maintain it, dont do it at all. You cant stick it to users by deciding later that you dont want to support it anymore. I am going to fix it (but this has been low on my priority list- you got the bucks to pay for this, buddy, and make it more attractive then the other things I'm currently getting paid to work on? money talks...), and I *also* am trying to change Intel's policy. If I pay for it, I own it. Thats the caveat of "open-source" Not necessarily. You might pay to have it developed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
old business (was Re: Intel driver doc's Take 2.)
On Sat, 24 Mar 2001, Dennis wrote: If the if_wx driver sucks, why not fix it rather than trying to coerce a mega-companies with a deep political structure to change is policies? But if youre not going to maintain it, dont do it at all. You cant stick it to users by deciding later that you dont want to support it anymore. I am going to fix it (but this has been low on my priority list- you got the bucks to pay for this, buddy, and make it more attractive then the other things I'm currently getting paid to work on? money talks...), and I *also* am trying to change Intel's policy. I complained for days and then fixed the fxp driver in about 4 hours. Maybe its time to do work and complain less. Work is good. Complaints just are. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Mike Smith wrote: On Fri, 23 Mar 2001, Daniel C. Sobral wrote: Let me just pipe in a bit. Compromise seems just like the kind of thing marketing or legal would want to do. The problem is that _we_ cannot compromise because one cannot write a "half-way there" driver. It's a technical impossibility. I agree 100%. I don't think this will fly either. I am just making the effort to work with Intel to get what we need. It's not going to happen overnight. Period. They are not going to change their NDA policy. In the future maybe. Actually I will forward the email she sent me this last time after I got off the phone with her an hour ago. I mentioned the problems Jonathan had with the GigE card. That's why she refers to him. Anyway I will forward it in a sec to the list. [Speaking here from some experience with this set of issues.] The compromise that you want to strike, and really the *only* compromise that is going to work, is that the *documents* will remain undisclosed, but information from the documents that is necessary to produce a functional, high-performance driver may be disclosed, but *only* through the source code of the driver. Thus one or a small group of people sign the NDA, and keep the documentation. The driver is then developed and maintained by this team, who also have the opportunity to interact with Intel's engineering people. The source code resulting from this effort is then released publically. Intel should probably retain the right to veto code that you might want to put in the driver if they feel that it risks disclosure they don't want, but you don't have to suggest this to them unless you feel you need it as a bargaining chip. This would put them in the same situation as they are already in with their source-available Linux driver; it should not present any more intellectual property risks than they already face, and as a bonus, it gets us a better-supported driver. In case anyone is truly interested in doing this, I have a "limited liability company" setup to do exactly this sort of work. If someone is interested in approaching Intel about this, under "contract" to my LLC, let me know via private e-mail. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
1 - Give a select group of people the docs under NDA 2 - If there are any specific features Intel wants avoided, get them to identify them up front. 3 - Let them write a driver that uses whatever features that are useful, with header files that define the register bits etc that are reasonably related to the features used. 4 - Hand over the driver to intel for "final veto" with a pre-agreement in place so that if they do not respond in 30 days we can release it as-is. 5 - If they have specific features or register bit definitions that they want removed, then do so as long as it isn't going to hopelessly cripple the driver. If they want something removed that wasn't covered in the list at the start and is going to cause severe performance problems (say a 10% performance or efficiency drop), too bad. 6 - Repeat the loop for 'final veto' but with a week timeout instead of 30 days. Regarding step 5; if the information is already "out there" (other open source drivers, leaked onto the internet, etc) then it is fair game and we can use it. Step 4 is a lose. That will never fly because they don't have the interest or bandwidth to review. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, 24 Mar 2001, Luigi Rizzo wrote: I have read the thread for a while, and i wonder: why in the world someone should go through the effort and responsibility of SIGNING THE NDA _and_ negotiating with Intel for getting permissions to redistribute the code ? Because NDAs come as a blanket cover, and you can then negotiate exceptions to them. I do not see how this is doing any good to the project, given that 1) there are alternatives (for 100Mbit quite a few of them), and some cards are even better and cheaper than the "fxp"; 2) even if you have hardware with an "fxp" on board, adding a second supported card is cheap and easy -- nothing like having to put in a second video card; It's not about 100Mbit. Personally, I prefer the tulip chip. It's about Intel's 10/100/1000 Pro1000T. Of course if you need support for this card in your own business, you do what you need (including NDA's etc), but that is a totally different story (and it appears to be a relatively straightforward and quick thing to do if you do not need to redistribute the source code). I think we all have better ways to use our time for FreeBSD than dealing with the legal department of some company. Well- sure. some of us are required by various contractual obligations to our clients to attempt to support this stuff, against Intel's resistance I might add. Therefore, we're trying to encourage Intel to do the right thing. And this might also include encouraging the buyback into open source of the chipset because we happen to believe that this is in the mutual best interest of the FreeBSD project and the vendor. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, 24 Mar 2001, Luigi Rizzo wrote: I have read the thread for a while, and i wonder: why in the world someone should go through the effort and responsibility of SIGNING THE NDA _and_ negotiating with Intel for getting permissions to redistribute the code ? I do not see how this is doing any good to the project, given that 1) there are alternatives (for 100Mbit quite a few of them), and some cards are even better and cheaper than the "fxp"; Cheaper is of little importance to me (although I would grumble if the price went much over $100). But "better"? Please continue! I am very interested in your insights on alternatives. 2) even if you have hardware with an "fxp" on board, adding a second supported card is cheap and easy -- nothing like having to put in a second video card; For many (most?) people that may be practical. But what about those of us with a 1RU system using fxp on the motherboard and NEED the single PCI slot for something else? I suspect that there are more of us than you might think. All the best, -Richard --- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, 24 Mar 2001, Luigi Rizzo wrote: I have read the thread for a while, and i wonder: why in the world someone should go through the effort and responsibility of SIGNING THE NDA _and_ negotiating with Intel for getting permissions to redistribute the code ? sleep deprived venting I made the effort to try and work things out for users like dennis. Who constantly have problems with Intel changing their PHY's, and our driver not getting updated. Because Intel wont give doc's out without an NDA. Now that should tell people like dennis, that our developers are *not interested* in writing binary only drivers, and/or signing NDA's. And I agree if a company needs the support let them sign the NDA and have the thing done in-house. I made the effort as im usre many others here have to beat Intel with a clue bat. They simply are not interested in playing nice. And AFAIC we can drop Intel support right now and whack the driver from the tree. I could care less about Intel CPU's or NIC HW. I have choices. And there are far better choices then Intel. Not that dropping the driver will happen. But my guess is the driver will eventually just suffer from so much bit rot that it will get yanked. I can be just as fascist as Intel. I could say we should just make a statement and rip the driver now. Make a nice article on daemon news and/or slashdot co-authored by the Linux Intel nic maintainer and just publicaly say both OS's are dropping support for Intel until such time as Intel does away with NDA's on their HW. The people who develop for FreeBSD, and I'm sure Linux as well, as you noted do not have the time to screw around with legal dept's in companies. They have work to do, and code to write. I, among many im sure, made the effort to get Intel to get a friggin clue. And as others have said before it's a practice in futility. So I made the effort. Intel is aware of what crack heads their being. End of story. Sorry dennis but if I were you I would start using other brands of NIC's. /sleep deprived venting = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 01:33 PM 03/24/2001, [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2001, Luigi Rizzo wrote: I have read the thread for a while, and i wonder: why in the world someone should go through the effort and responsibility of SIGNING THE NDA _and_ negotiating with Intel for getting permissions to redistribute the code ? sleep deprived venting I made the effort to try and work things out for users like dennis. Who constantly have problems with Intel changing their PHY's, and our driver not getting updated. Because Intel wont give doc's out without an NDA. Now that should tell people like dennis, that our developers are *not interested* in writing binary only drivers, and/or signing NDA's. You use the term "our developers" as if you are some sort of closed cult. I have NEVER complained about Intel not releasing full information on their boards.That whining has come exclusively from hackers that didnt feel like doing the work. I complained about FreeBSD having a "maintainer" for a very important driver who didnt do any maintaining. I fixed the persistent PHY problem in an afternoon with info from the available linux driver supplied by intel. You dont need to get intel to change its policy to support the board. Its just an excuse to not do it. There are plenty of resources available. If the if_wx driver sucks, why not fix it rather than trying to coerce a mega-companies with a deep political structure to change is policies? But if youre not going to maintain it, dont do it at all. You cant stick it to users by deciding later that you dont want to support it anymore. I complained for days and then fixed the fxp driver in about 4 hours. Maybe its time to do work and complain less. dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2001, Richard Hodges wrote: For many (most?) people that may be practical. But what about those of us with a 1RU system using fxp on the motherboard and NEED the single PCI slot for something else? I suspect that there are more of us than you might think. Richard, Well then I suggest you ALL start writing Intel every single day to RELEASE DOCS WITH NO NDA. Then this problem will go away. That is probably the "right" thing to do, but like you, I'm not going to hold my breath. AFAIK the XL driver for 3com card's performs just as well if not better then the intel cards. And gee funny enough the new dual AMD Athlon board from Tyan will sport onboard 3Com 10/100 FE. Thanks for the tip on the XL driver. Over the years, I have seen many questions about which driver/card was the best, and all the answers were pretty vague, or suggested that Intel had the edge. That's good news on the Tyan motherboard. The bad news is the price... About $950 :-( All the best, -Richard --- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 02:49:14PM -0500, Dennis wrote: You use the term "our developers" as if you are some sort of closed cult. They have something in common, and it's not a cult. It's called being an "open source developer". I have NEVER complained about Intel not releasing full information on their boards.That whining has come exclusively from hackers that didnt feel like doing the work. I complained about FreeBSD having a "maintainer" for a very important driver who didnt do any maintaining. I fixed the persistent PHY problem in an afternoon with info from the available linux driver supplied by intel. You dont need to get intel to change its policy to support the board. Its just an excuse to not do it. There are plenty of resources available. Not in terms of time. BSD developers prefer to spend their time on opensource code that's done the right way. Hence the quality of FreeBSD. I'm sure you knew that already, since you're supporting this in ETInc's products. If the if_wx driver sucks, why not fix it rather than trying to coerce a mega-companies with a deep political structure to change is policies? But if youre not going to maintain it, dont do it at all. You cant stick it to users by deciding later that you dont want to support it anymore. You can't "fix" a device driver "correctly" when you don't have the right docs. I complained for days and then fixed the fxp driver in about 4 hours. Maybe its time to do work and complain less. Uh bro, if you have patches, submit them! That's what opensource is all about... of course you knew that too. :) -- wca PGP signature
Re: Intel driver doc's Take 2.
On Sat, 24 Mar 2001, Richard Hodges wrote: Thanks for the tip on the XL driver. Over the years, I have seen many questions about which driver/card was the best, and all the answers were pretty vague, or suggested that Intel had the edge. Yes. It's currently my understanding that the xl driver is indeed as reliable and as fast as the fxp. I know what your saying though. The fxp has been touted as the fastest. Years ago it was the de driver for DEC cards that was the screamer, then it became the fxp, but the xl driver is just as fast. That's good news on the Tyan motherboard. The bad news is the price... About $950 :-( Yeah when I saw that price I about had a stroke! My guess is it's going to be half that when it finally rolls out in april. AMD CPU's and AMD boards have *always* been cheaper then Intel parts. I really doubt Tyan is going to start breaking that now. Granted this is their first high end server board for K7's but Tyan always has faily decent prices on their MB's. I think that 950 is just an initial marketing price. But in relaity when it rolls out you will see it on pricewatch for half that. That's my guess. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
If the if_wx driver sucks, why not fix it rather than trying to coerce a mega-companies with a deep political structure to change is policies? But if youre not going to maintain it, dont do it at all. You cant stick it to users by deciding later that you dont want to support it anymore. You can't "fix" a device driver "correctly" when you don't have the right docs. Most drivers are written without full docs. Intel supplied drivers for linux are available for both eepro100 and gigabit cards. The info is out there. Cobbling together the info to produce a driver...THATS what open source is all about. I complained for days and then fixed the fxp driver in about 4 hours. Maybe its time to do work and complain less. Uh bro, if you have patches, submit them! That's what opensource is all about... of course you knew that too. Im not an "open-source" developer. but then again, you knew that. Plus I offered to help and J. Lemon bit off my head. Plus Im sure you wouldnt want Intels copyright in "your" driver. db To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 02:45 PM 03/24/2001, [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2001, Richard Hodges wrote: Thanks for the tip on the XL driver. Over the years, I have seen many questions about which driver/card was the best, and all the answers were pretty vague, or suggested that Intel had the edge. Yes. It's currently my understanding that the xl driver is indeed as reliable and as fast as the fxp. I know what your saying though. The fxp has been touted as the fastest. Years ago it was the de driver for DEC cards that was the screamer, then it became the fxp, but the xl driver is just as fast. thats not true at all. We have traced many of our heavily loaded customers problems to the XL driver. Replacing them with intels solved the problems. But for general use you are probably correct. Db To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 03:11:54PM -0500, Dennis wrote: Most drivers are written without full docs. Intel supplied drivers for linux are available for both eepro100 and gigabit cards. The info is out there. Cobbling together the info to produce a driver...THATS what open source is all about. [...] Im not an "open-source" developer. but then again, you knew that. Plus I If you're not an opensource developer, then you don't know what yer talking about. Why do you even bother subscribing to any freebsd lists if you aren't going to adopt any sort of opensource behavior? -- wca PGP signature
Re: Intel driver doc's Take 2.
At 03:12 PM 03/24/2001, Will Andrews wrote: On Sat, Mar 24, 2001 at 03:11:54PM -0500, Dennis wrote: Most drivers are written without full docs. Intel supplied drivers for linux are available for both eepro100 and gigabit cards. The info is out there. Cobbling together the info to produce a driver...THATS what open source is all about. [...] Im not an "open-source" developer. but then again, you knew that. Plus I If you're not an opensource developer, then you don't know what yer talking about. Why do you even bother subscribing to any freebsd lists if you aren't going to adopt any sort of opensource behavior? Is being an "open-source" developer now a necessary condition for being a "hacker" or "developer"? You academics crack me up. You have it completely backwards. Most open-source people dont know what they are talking about. This conversation about intel is like a bunch of women discussing what its like to be hit in the balls. its downright comical. They are in the business of making money. If you think they dont know the exact impact of releasing the information then you need to get out of your cubical a hell of a lot more. For your info, Bub, what makes the BSD license attractive is its usability by commercial vendors, so maybe you should go play in Linuxland because you are the one in the wrong camp, not me. the ability to take code, fix it and incorporate it into a product WITHOUT giving back source is the ENTIRE CONCEPT of the BSD license. And why does all of your email have that stupid attachment? Whats the matter, cant figure out how to use an open-source mailer? :-) DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On 24 Mar 2001, at 16:12, Dennis wrote: And why does all of your email have that stupid attachment? Whats the matter, cant figure out how to use an open-source mailer? :-) It's called a PGP signature. Could you two kids please take this pissing contest off -hackers? Thanks. -- Dan Langille pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php got any work? I'm looking for some. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 04:12:34PM -0500, Dennis wrote: For your info, Bub, what makes the BSD license attractive is its usability by commercial vendors, so maybe you should go play in Linuxland because you are the one in the wrong camp, not me. the ability to take code, fix it and incorporate it into a product WITHOUT giving back source is the ENTIRE CONCEPT of the BSD license. Obviously so, but it serves no point to complain about an opensource driver's problem on an opensource list if you're going to fix it in your proprietary tree, say you did so, and not pass it on. Since nobody else gets to see your "fix", it won't solve a thing, for you or FreeBSD. And why does all of your email have that stupid attachment? Whats the matter, cant figure out how to use an open-source mailer? :-) What's the matter, don't know how to use pgp? -- wca PGP signature
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 06:31:44PM +0100, Luigi Rizzo wrote: 2) even if you have hardware with an "fxp" on board, adding a second supported card is cheap and easy -- nothing like having to put in a second video card; Many, many U1-form-factor systems have two fxp on-board NICs. No room to add third (and fourth) supported NIC. K THNX. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Matthew Jacob wrote: 1 - Give a select group of people the docs under NDA 2 - If there are any specific features Intel wants avoided, get them to identify them up front. 3 - Let them write a driver that uses whatever features that are useful, wi th header files that define the register bits etc that are reasonably rela ted to the features used. 4 - Hand over the driver to intel for "final veto" with a pre-agreement in place so that if they do not respond in 30 days we can release it as-is . 5 - If they have specific features or register bit definitions that they wa nt removed, then do so as long as it isn't going to hopelessly cripple the driver. If they want something removed that wasn't covered in the list at the start and is going to cause severe performance problems (say a 10% performance or efficiency drop), too bad. 6 - Repeat the loop for 'final veto' but with a week timeout instead of 30 days. Regarding step 5; if the information is already "out there" (other open source drivers, leaked onto the internet, etc) then it is fair game and we can use it. Step 4 is a lose. That will never fly because they don't have the interest or bandwidth to review. I know. That is why I stressed that it is critical that there is a timeout. If there is no timeout, then you get stuck in the situation that Jonathan Lemon is in with his driver. *getting* the timeout clause is the trick. If somebody can manage that, then we are set. Finding somebody with the right marketing/legal connections who can get this in writing and who is naive enough to think that their internal departments will spend the time is what requires luck and/or persistance. There is no point beginning this process unless you can get the procedure *in writing*. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 04:19 PM 03/24/2001, Will Andrews wrote: On Sat, Mar 24, 2001 at 04:12:34PM -0500, Dennis wrote: For your info, Bub, what makes the BSD license attractive is its usability by commercial vendors, so maybe you should go play in Linuxland because you are the one in the wrong camp, not me. the ability to take code, fix it and incorporate it into a product WITHOUT giving back source is the ENTIRE CONCEPT of the BSD license. Obviously so, but it serves no point to complain about an opensource driver's problem on an opensource list if you're going to fix it in your proprietary tree, say you did so, and not pass it on. Since nobody else gets to see your "fix", it won't solve a thing, for you or FreeBSD. Its not a "proprietary tree". I dont have time to clean it up and submit patches. "hackers" doesnt imply "open-souce". This is a "general technical discussion" list, according to freebsd.org. db To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
At 04:07 PM 03/24/2001, Dan Langille wrote: On 24 Mar 2001, at 16:12, Dennis wrote: And why does all of your email have that stupid attachment? Whats the matter, cant figure out how to use an open-source mailer? :-) It's called a PGP signature. Could you two kids please take this pissing contest off -hackers? Thanks. the only thing more annoying the 2 people having a discussion is a third person telling them to stop. Feel free not to read any more messages in this thread. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Yes, I agree. We should delete the rest of this thread. On Sat, 24 Mar 2001, Dennis wrote: At 04:07 PM 03/24/2001, Dan Langille wrote: On 24 Mar 2001, at 16:12, Dennis wrote: And why does all of your email have that stupid attachment? Whats the matter, cant figure out how to use an open-source mailer? :-) It's called a PGP signature. Could you two kids please take this pissing contest off -hackers? Thanks. the only thing more annoying the 2 people having a discussion is a third person telling them to stop. Feel free not to read any more messages in this thread. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On 24 Mar 2001, at 19:59, Dennis wrote: the only thing more annoying the 2 people having a discussion is a third person telling them to stop. Feel free not to read any more messages in this thread. Feel free to read the list charter. You two are in a pissing contest unreleated to this list. Please take it elsewhere. -- Dan Langille pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php got any work? I'm looking for some. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 03:11:54PM -0500, Dennis wrote: Most drivers are written without full docs. Feh. *EVERY* wpaul written Ethernet driver was written _with_ having the full docs. wpaul will not write a driver otherwise. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
:: Hah, me neither. In fact, if you want to try out a binary of my :: Intel GigE driver, it is at http://www.flugsvamp.com/~jlemon/fbsd/drivers :: Jonathan Wow, what I coincidence. I just did a search a couple days ago for any recent developments, and earlier today spent a bit of time with this very driver, with absolutely no idea this conversation had just taken place... A quick background -- some months ago I asked about a Gig ethernet driver when the wx driver didn't seem to work, and I had no e-mail address and was planning to be somewhere else. Well, I still have no e-mail address and I haven't escaped yet, but again, the reply address will reach the people who are in charge of the machinery, and I peek in on the lists now and then. Like now. If I may ask, this binary driver, which cards does it support and which cards does it *not* support? Or if releasing that info is restricted by the NDA, does your driver support the newer Intel Pro/1000 F cards, which had been mentioned here a couple months back (Livengood, if I remember, and which decidedly did not work with the driver by Matthew Jacob)? I did experiment with the driver and the card ealier today for an hour or so without complete success, like no network functionality at all, but I'm not going to rule out pilot error, though it seemed to exhibit similar lack of functionality to the wx driver. If it should work, I'll think about giving it another shot, but if it only works with the 1000 cards (not the F or T) then I won't try the impossible. Or consider this a possible problem report on the driver with the Pro 1000 F... Thanks! barry bouwsma, still stuck at cold snowy TDC internet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Fri, Mar 23, 2001 at 04:08:39PM +0100, Olibert Obdachlos wrote: If I may ask, this binary driver, which cards does it support and which cards does it *not* support? Or if releasing that info is restricted by the NDA, does your driver support the newer Intel Pro/1000 F cards, which had been mentioned here a couple months back (Livengood, if I remember, and which decidedly did not work with the driver by Matthew Jacob)? I'm admittedly not familiar with Intels marketing nomenclature. But if by "1000 F", you mean the 82543/Livingood chip, then yes, this driver should work on that board. In fact, the driver was designed around the 82543, and then backported to 82542 (wiseman). It won't work with the 1000 T (twisted pair) just yet, since I haven't written the PHY support for that card. (I only have the fiber versions of the card here). But it should work with all the fiber mode cards. I did experiment with the driver and the card ealier today for an hour or so without complete success, like no network functionality at all, but I'm not going to rule out pilot error, though it seemed to exhibit similar lack of functionality to the wx driver. If it should work, I'll think about giving it another shot, but if it only works with the 1000 cards (not the F or T) then I won't try the impossible. Or consider this a possible problem report on the driver with the Pro 1000 F... Hmm. Send me details, the more information, the better. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
restricted by the NDA, does your driver support the newer Intel Pro/1000 F cards, which had been mentioned here a couple months I'm admittedly not familiar with Intels marketing nomenclature. But if by "1000 F", you mean the 82543/Livingood chip, then yes, this driver should work on that board. Thanks! That's exactly what I was hoping to know before getting too deep over my head. Consider yourself lucky -- I spent a while navigating the Intel website to see if much had changed. I did dig up the old message I had sent which isn't worth reposting, but may contain pointers to marketroid data and the like. It's from 19.Jan in -hardware, Message-ID: [EMAIL PROTECTED] or news:[EMAIL PROTECTED] but it's probably not worth digging out of the archive now. In fact, the driver was designed around the 82543, and then backported to 82542 (wiseman). I haven't had my sweaty hands over one of these cards, but I'll assume the 82543GC discussed in these messages is equivalent. I'll also try to get a close look at a card to know what is in use. the impossible. Or consider this a possible problem report on the driver with the Pro 1000 F... Hmm. Send me details, the more information, the better. I'll wait a second before passing on details I don't have at hand, because I can't say I trust the test machine it was placed in, which spontaneously rebooted on me at reboot time, and then wedged up at a following reboot. I think it needs a high-speed lesson through the machine room to meet Mister Floor. Also, I don't trust the configuration that dmesg reveals at boot -- I got stellar performance from a similar machine when it assigned IRQs like 20 and 21 to the fxp ethernet card, while on a different HP machine, I had hell trying to get both an ethernet card and a pile of sound cards to work, when IRQs were given similar to what this test machine wants to give, and I needed to do some juggling of cards to get anything to happen. Everything worked great when I got the high IRQs though. So it's quite possible that this machine needs to have the gigabit ethernet card swapped around -- it came up at irq5. This card is also installed in another machine currently doing production service and was given irq21 or something, so there is definitely some weird BIOS difference between the two machines. chorusI hate PC hardware./chorus This will probably wait til monday, and I'll also ask our techie who posted some details last time if he's seeing exactly the same thing now. I made some tests I didn't try last time, but before I make any claims, I want to eliminate the possibility of flaky hardware at this end and gather relevant details. Thanks, I'll get back to you about this... barry bouwsma, resident TDC internet netmangler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Mike Smith wrote: On Fri, 23 Mar 2001, Daniel C. Sobral wrote: Let me just pipe in a bit. Compromise seems just like the kind of thing marketing or legal would want to do. The problem is that _we_ cannot compromise because one cannot write a "half-way there" driver. It's a technical impossibility. I agree 100%. I don't think this will fly either. I am just making the effort to work with Intel to get what we need. It's not going to happen overnight. Period. They are not going to change their NDA policy. In the future maybe. Actually I will forward the email she sent me this last time after I got off the phone with her an hour ago. I mentioned the problems Jonathan had with the GigE card. That's why she refers to him. Anyway I will forward it in a sec to the list. [Speaking here from some experience with this set of issues.] The compromise that you want to strike, and really the *only* compromise that is going to work, is that the *documents* will remain undisclosed, but information from the documents that is necessary to produce a functional, high-performance driver may be disclosed, but *only* through the source code of the driver. Thus one or a small group of people sign the NDA, and keep the documentation. The driver is then developed and maintained by this team, who also have the opportunity to interact with Intel's engineering people. The source code resulting from this effort is then released publically. Intel should probably retain the right to veto code that you might want to put in the driver if they feel that it risks disclosure they don't want, but you don't have to suggest this to them unless you feel you need it as a bargaining chip. This would put them in the same situation as they are already in with their source-available Linux driver; it should not present any more intellectual property risks than they already face, and as a bonus, it gets us a better-supported driver. Yes, but for goodness's sake, make sure there are time limits on it! Try this: 1 - Give a select group of people the docs under NDA 2 - If there are any specific features Intel wants avoided, get them to identify them up front. 3 - Let them write a driver that uses whatever features that are useful, with header files that define the register bits etc that are reasonably related to the features used. 4 - Hand over the driver to intel for "final veto" with a pre-agreement in place so that if they do not respond in 30 days we can release it as-is. 5 - If they have specific features or register bit definitions that they want removed, then do so as long as it isn't going to hopelessly cripple the driver. If they want something removed that wasn't covered in the list at the start and is going to cause severe performance problems (say a 10% performance or efficiency drop), too bad. 6 - Repeat the loop for 'final veto' but with a week timeout instead of 30 days. Regarding step 5; if the information is already "out there" (other open source drivers, leaked onto the internet, etc) then it is fair game and we can use it. With somebody like Intel, it is pretty important to get this in some form of writing. They have a horrible habbit of "forgetting" things that are "too hard" (eg: sweeping your driver for unused information). The reason Intel keep a tight lid on this stuff is that they are very afraid of losing their "competitive advantage" of having functional fxp drivers in the Windows installation, while most of the other ethernet cards do not. If somebody can clone the 8255x series such that it is "close enough" from publically available documentation that it will work with the windoze CD drivers, then Intel loses the upper hand. *That* is what they are afraid of. If some taiwanese manufacturer makes a clone and intel goes after them, and they can point to the freebsd fxpreg.h file that thoughtfully defines every single bit and register in the NDA manuals, you can bet that Intel wont be happy. On the other hand, if it meant that they would have had to pull the drivers apart (illegal under DMCA in the US), Intel would be able to sue them to death if they ever tried to sell it in the US. And then there's always the 'trade secrets' lawsuits of death. (remember Intel vs VIA over the "Apollo" BX chipset workalike). The 'yellow manual' describes the chips, steppings, quirks, workarounds, etc in painful detail... In enough detail that one could do a legal 'clean room' implementation if the manual were freely available. However, there are lots of things that would never go into a FreeBSD driver. Things like the microcode interfaces for the wake-on-lan sequencer/filter, etc. There are a bunch of stuff that is totally irrelevant to us. There are a bunch of things on the chips that are so badly broken that they are not useful to us at all (eg: the checksum assistance on the 82559). I'm sure that we could arrange to
Intel driver doc's Take 2.
I just got off the phone with Linda Sanchez at our favorite company Intel. She is a Sr. "Marketing Engineer" (What is a marketing engineer?) for their LAN products. She is itnerested in helping us get the information we need to write drivers for their cards. But she also knows NDA's are not going away. She wants to meet us halfway in the short term. Somewhere between a datasheet and a programming manual, that we can get with no NDA. I know alot of you are totally fed up with Intel and at this point couldnt give two hoots about Intel or their cards. But she is willing to work with us to get us what we need. I told her it sounds like an all or nothing proposition that we NEED the programming manuals. Not datasheets, not fluffy reference drivers. But for the short term that is not going to happen. Sigh. She does want to try and help us like I said. She need's specific information that we need that we cant get unless we sign NDA's for the doc's so she can try and get them merged into a reference product somewhere between the datasheet (worthless) and the programming manual (NDA). I know this is not ideal or what bill, jonathon, or others want. They would rather Intel just get a friggin clue and stop being anal. And while in the long term this may change it isn't going to be soon. She is willing to compromise and try and get us doc's on the bits we need. Is anyone willing to try and work on a middle of the road to keep support current for Intel nic's? Or has everyone decided to just not waste the effort or time on Intel idiocy anymore? Either way is fine. It's not like we only support one brand of NIC's. I'm just making an offer, the only offer from Intel, to help work with OS developers. I completely understand everyone's attitude towards Intel and I think it's totally justified. And I am usually an all or nothing person. I don't do middle of the road. But thats the offer on the table. Try and get us what we need in manual in between the datasheet and the programming doc's. But it will be available without an NDA. This is the option we currently have. Any takers? If there are she want's me to collect specific item's that are needed. Like the recent PHY debacle. What item's do we need programming doc's on? Specific parts? Etc. In the long term maybe Intel will get a clue but I am not holding my breath. But this is a chance to try and get what we need under a non-NDA arrangement. So if anyone has any care whatsoever to make one last effort to support Intel hardware and wants to work on getting the information we need. Let me know. I *think* we can get her to piecemeal the info we need into a non NDA doc for us, piece by piece that is as good or better as the programming doc's. Anyway if there are any takers that want to work with me on getting the doc's required let me know. Otherwise i'm just like everyone else I dont have a 50 megaton nuclear device to beat Intel with to get them to do the right thing. And Intel support can be dropped. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Random idea from the peanut gallery... Find someone who is NDA'd and knows both the programming manual and the needs of the device driver. Have that person compose a list of those bits of the manual most necessary for getting a working driver. This would be an explicit list of figures, diagrams, tables and text sections. I would assume that Intel legal would then go through the list and give a yea/nay for each item requested. For the contested items, perhaps a redacted/simplified version could be proposed instead, but hopefully the bulk of the request would accepted. Just my $0.02 -JohnG (neither NDA'd or working on the driver) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
[EMAIL PROTECTED] wrote: She need's specific information that we need that we cant get unless we sign NDA's for the doc's so she can try and get them merged into a reference product somewhere between the datasheet (worthless) and the programming manual (NDA). I know this is not ideal or what bill, jonathon, or others want. They would rather Intel just get a friggin clue and stop being anal. And while in the long term this may change it isn't going to be soon. She is willing to compromise and try and get us doc's on the bits we need. Let me just pipe in a bit. Compromise seems just like the kind of thing marketing or legal would want to do. The problem is that _we_ cannot compromise because one cannot write a "half-way there" driver. It's a technical impossibility. Now, if Bill Paul, Jonathan Lemon or whoever can come up with a "compromise" that would work, fine. But otherwise, and I think otherwise is likely, please explain the above to this person. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It's a rewarding life, but hey, somebody has to have all the fun, right? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: She need's specific information that we need that we cant get unless we sign NDA's for the doc's so she can try and get them merged into a reference product somewhere between the datasheet (worthless) and the programming manual (NDA). Well, I applaud your effort, but I can't really think of how this would work. The information in the programming manual is required to program the chip. It is already a fairly concise manual, and if you axe anything out of it, it would mean that feature wouldn't be supported. A programming manual generally looks something like the following (completely made up) example: control register:offset 0, length 2 words bit 31:MWI enable bit 29-30: duplex settings 00 = full duplex 01 = half duplex 1x = auto negotiate In order for duplex settings to take effect, the chip must first be be reset to idle state, then the link settings changed bit 28:receiver enable 0 = disable 1 = enable before enabling the receiver, the receive control register must be set up appropriately, as well as the receive ring base and length registers. Exactly what in the above (fictional) example is it possible to axe out and still come up with a functional driver? Descriptions of each bit and their position in the register? The rules/caveats associated with each bit? I hate to say it, but anything that gets axed out of the manual basically means that those features of the chip will not be used. I honestly don't think that the marketer you talked to really understands this; I can't for the life of me see how anything less than the programming manual will be sufficient. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Fri, 23 Mar 2001, Daniel C. Sobral wrote: Let me just pipe in a bit. Compromise seems just like the kind of thing marketing or legal would want to do. The problem is that _we_ cannot compromise because one cannot write a "half-way there" driver. It's a technical impossibility. I agree 100%. I don't think this will fly either. I am just making the effort to work with Intel to get what we need. It's not going to happen overnight. Period. They are not going to change their NDA policy. In the future maybe. Actually I will forward the email she sent me this last time after I got off the phone with her an hour ago. I mentioned the problems Jonathan had with the GigE card. That's why she refers to him. Anyway I will forward it in a sec to the list. Now, if Bill Paul, Jonathan Lemon or whoever can come up with a "compromise" that would work, fine. But otherwise, and I think otherwise is likely, please explain the above to this person. Well I have a feeling if bill even reads this, which he will probably see Intel in the subject and delete it, or has a procmail filter for 'Intel' :-) he will probably just get more frustrated then he is. Jonathan, I dont know. He is probably as fed up as everyone else. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
For what it's worth, I believe I'm still committed to work on the GigE driver. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
btw- *I* have no problem with an NDA as long as it includes a rider that says what we could release as open source. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: btw- *I* have no problem with an NDA as long as it includes a rider that says what we could release as open source. Hah, me neither. In fact, if you want to try out a binary of my Intel GigE driver, it is at http://www.flugsvamp.com/~jlemon/fbsd/drivers -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
I hate to say it, but anything that gets axed out of the manual basically means that those features of the chip will not be used. I honestly don't think that the marketer you talked to really understands this; I can't for the life of me see how anything less than the programming manual will be sufficient. You should be allowed the whole manual, but some list of what can be made visible should not be all that hard to do- certainly after you've looked over the manual and you work with Intel to figure what is and isn't releasable. I have a personal contact with a manager in the LAN group at Intel who I'm visiting this weekend. We'll see if he has some influence in this matter. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Thu, Mar 22, 2001 at 10:39:58AM -0800, Matthew Jacob wrote: I hate to say it, but anything that gets axed out of the manual basically means that those features of the chip will not be used. I honestly don't think that the marketer you talked to really understands this; I can't for the life of me see how anything less than the programming manual will be sufficient. You should be allowed the whole manual, but some list of what can be made visible should not be all that hard to do- certainly after you've looked over the manual and you work with Intel to figure what is and isn't releasable. Sure. If intel would simply say: " we don't want the driver to support cisco ISL, checksum offloading, VLAN, or Wake On Lan features " I suppose I could work with that. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Fri, 23 Mar 2001, Daniel C. Sobral wrote: Let me just pipe in a bit. Compromise seems just like the kind of thing marketing or legal would want to do. The problem is that _we_ cannot compromise because one cannot write a "half-way there" driver. It's a technical impossibility. I agree 100%. I don't think this will fly either. I am just making the effort to work with Intel to get what we need. It's not going to happen overnight. Period. They are not going to change their NDA policy. In the future maybe. Actually I will forward the email she sent me this last time after I got off the phone with her an hour ago. I mentioned the problems Jonathan had with the GigE card. That's why she refers to him. Anyway I will forward it in a sec to the list. [Speaking here from some experience with this set of issues.] The compromise that you want to strike, and really the *only* compromise that is going to work, is that the *documents* will remain undisclosed, but information from the documents that is necessary to produce a functional, high-performance driver may be disclosed, but *only* through the source code of the driver. Thus one or a small group of people sign the NDA, and keep the documentation. The driver is then developed and maintained by this team, who also have the opportunity to interact with Intel's engineering people. The source code resulting from this effort is then released publically. Intel should probably retain the right to veto code that you might want to put in the driver if they feel that it risks disclosure they don't want, but you don't have to suggest this to them unless you feel you need it as a bargaining chip. This would put them in the same situation as they are already in with their source-available Linux driver; it should not present any more intellectual property risks than they already face, and as a bonus, it gets us a better-supported driver. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Jonathan Lemon wrote: In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: She need's specific information that we need that we cant get unless we sign NDA's for the doc's so she can try and get them merged into a reference product somewhere between the datasheet (worthless) and the programming manual (NDA). Well, I applaud your effort, but I can't really think of how this would work. The information in the programming manual is required to program the chip. It is already a fairly concise manual, and if you axe anything out of it, it would mean that feature wouldn't be supported. How about meeting half-way in a different way ? Suppose they provide the manual with NDA but in the NDA agreement they state that the source code of the driver developed using this manual may be published. To reiterate, the manual itself would still be their trade secret but the results of development done based on this manual would be free. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
