Date: Mon, 22 Feb 1999 01:19:04 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Larry Lile <lile@stdio.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Julian Elischer <julian@whistle.com>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, cvs-all@FreeBSD.ORG Subject: Re: Current status of the olicom fracas. Message-ID: <36D031F8.F3D8ED7E@newsguy.com> References: <Pine.BSF.4.05.9902210846280.8995-100000@heathers.stdio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Larry Lile wrote: > > To dispense with all of the FUD flying about over the .o files: > > trlld.o: is Olicom's hardware interface library - it contains NO > copyrights ... > Someone has brought up the issue that this driver will not work for > Alpha systems. I do not know whether it will or not. Will an > Alpha link a little endian binary into the kernel? Is the object > code compatible, libc wise? I can fix the runtime endian problems > since the interface library does all i/o through routines in my > half of the driver. I do not want to exclude the Alpha users, I > just don't have an Alpha to work on. Also, if we had an installed > i386 user base Olicom might re-compile the objects specifically for > Alpha, but if the driver gets killed that will never happen. The above object file is the problem. It is i386 code, right? Thus, it will not run on alpha. ... > Stop advocating and pick up the phone. Call Olicom, if you can get > them to release the source I will be elated. I have heard the argument > before but no one else is willing to put in the work to get the source > from Olicom. I have spent hours on the phone and countless e-mails with > Olicom trying to get the source code, it it not going to happen any > time soon if at all. In the interim I think Olicom has done well to > provide an interface that open source projects can use, and should be > applauded for their efforts. Don't complain that someone else's efforts > don't measure up to your standards when you are unwilling to put forth > the effort to accomplish it yourself. Sorry Poul, very few people have > tried to add token-ring support to FreeBSD and no one has succeded thus > far. This "fracas" may kill it for good if we are not very carefull > about it. In this regard, I think you are wrong. What is in our tree, we "support". We can fix it and we provide source for, so people can fix any problems themselves. That's something our users expect, and even something we advertise as being one of our strengths. That the above code is i386 only is not really that much of a problem. If Olicom does not wish to support use of their cards in Alpha, that's up to them. The problem is that we surrender control over the source of something in the standard distribution. It is a very bad precedent. Where would we draw a line, now? How can we distinguish this piece of code from anything up to the whole driver? If cannot do it, we might see the day were almost all of our drivers for new hardware are (mostly) in object form, because the companies rather prefer doing it this way than making public the interface to their hardware. I my very personal opinion, this is contrary to what we wish to achieve. There are technical problems as well. For instance, is this code reentrant? If we go to fine-grained SMP, do we know it can have multiple concurrent instances of execution, or we'll have to "big lock" it? Also, what does that object do to our interrupts? Do we stand a chance of loosing interrupts inside it? The comparision to ROM codes has been made, and it seems to be quite valid. Also, token ring support truly is a very good thing. But the issue is not, by any means, clear cut. *Not* supporting those who will simply not open the interface to their products is a form of pressure. It goes both ways, though, and you seem to be more acutely aware of the other side (FreeBSD being pressured into accept closed objects if it wants to support the hardware). Truly, we don't care about the microcode. Even if we had the source, there is good chance we might not be able to compile it. But that single file up there... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!"Larry Lile wrote: > > To dispense with all of the FUD flying about over the .o files: > > trlld.o: is Olicom's hardware interface library - it contains NO > copyrights ... > Someone has brought up the issue that this driver will not work for > Alpha systems. I do not know whether it will or not. Will an > Alpha link a little endian binary into the kernel? Is the object > code compatible, libc wise? I can fix the runtime endian problems > since the interface library does all i/o through routines in my > half of the driver. I do not want to exclude the Alpha users, I > just don't have an Alpha to work on. Also, if we had an installed > i386 user base Olicom might re-compile the objects specifically for > Alpha, but if the driver gets killed that will never happen. The above object file is the problem. It is i386 code, right? Thus, it will not run on alpha. ... > Stop advocating and pick up the phone. Call Olicom, if you can get > them to release the source I will be elated. I have heard the argument > before but no one else is willing to put in the work to get the source > from Olicom. I have spent hours on the phone and countless e-mails with > Olicom trying to get the source code, it it not going to happen any > time soon if at all. In the interim I think Olicom has done well to > provide an interface that open source projects can use, and should be > applauded for their efforts. Don't complain that someone else's efforts > don't measure up to your standards when you are unwilling to put forth > the effort to accomplish it yourself. Sorry Poul, very few people have > tried to add token-ring support to FreeBSD and no one has succeded thus > far. This "fracas" may kill it for good if we are not very carefull > about it. In this regard, I think you are wrong. What is in our tree, we "support". We can fix it and we provide source for, so people can fix any problems themselves. That's something our users expect, and even something we advertise as being one of our strengths. That the above code is i386 only is not really that much of a problem. If Olicom does not wish to support use of their cards in Alpha, that's up to them. The problem is that we surrender control over the source of something in the standard distribution. It is a very bad precedent. Where would we draw a line, now? How can we distinguish this piece of code from anything up to the whole driver? If cannot do it, we might see the day were almost all of our drivers for new hardware are (mostly) in object form, because the companies rather prefer doing it this way than making public the interface to their hardware. I my very personal opinion, this is contrary to what we wish to achieve. There are technical problems as well. For instance, is this code reentrant? If we go to fine-grained SMP, do we know it can have multiple concurrent instances of execution, or we'll have to "big lock" it? Also, what does that object do to our interrupts? Do we stand a chance of loosing interrupts inside it? The comparision to ROM codes has been made, and it seems to be quite valid. Also, token ring support truly is a very good thing. But the issue is not, by any means, clear cut. *Not* supporting those who will simply not open the interface to their products is a form of pressure. It goes both ways, though, and you seem to be more acutely aware of the other side (FreeBSD being pressured into accept closed objects if it wants to support the hardware). Truly, we don't care about the microcode. Even if we had the source, there is good chance we might not be able to compile it. But that single file up there... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!"Larry Lile wrote: > > To dispense with all of the FUD flying about over the .o files: > > trlld.o: is Olicom's hardware interface library - it contains NO > copyrights ... > Someone has brought up the issue that this driver will not work for > Alpha systems. I do not know whether it will or not. Will an > Alpha link a little endian binary into the kernel? Is the object > code compatible, libc wise? I can fix the runtime endian problems > since the interface library does all i/o through routines in my > half of the driver. I do not want to exclude the Alpha users, I > just don't have an Alpha to work on. Also, if we had an installed > i386 user base Olicom might re-compile the objects specifically for > Alpha, but if the driver gets killed that will never happen. The above object file is the problem. It is i386 code, right? Thus, it will not run on alpha. ... > Stop advocating and pick up the phone. Call Olicom, if you can get > them to release the source I will be elated. I have heard the argument > before but no one else is willing to put in the work to get the source > from Olicom. I have spent hours on the phone and countless e-mails with > Olicom trying to get the source code, it it not going to happen any > time soon if at all. In the interim I think Olicom has done well to > provide an interface that open source projects can use, and should be > applauded for their efforts. Don't complain that someone else's efforts > don't measure up to your standards when you are unwilling to put forth > the effort to accomplish it yourself. Sorry Poul, very few people have > tried to add token-ring support to FreeBSD and no one has succeded thus > far. This "fracas" may kill it for good if we are not very carefull > about it. In this regard, I think you are wrong. What is in our tree, we "support". We can fix it and we provide source for, so people can fix any problems themselves. That's something our users expect, and even something we advertise as being one of our strengths. That the above code is i386 only is not really that much of a problem. If Olicom does not wish to support use of their cards in Alpha, that's up to them. The problem is that we surrender control over the source of something in the standard distribution. It is a very bad precedent. Where would we draw a line, now? How can we distinguish this piece of code from anything up to the whole driver? If cannot do it, we might see the day were almost all of our drivers for new hardware are (mostly) in object form, because the companies rather prefer doing it this way than making public the interface to their hardware. I my very personal opinion, this is contrary to what we wish to achieve. There are technical problems as well. For instance, is this code reentrant? If we go to fine-grained SMP, do we know it can have multiple concurrent instances of execution, or we'll have to "big lock" it? Also, what does that object do to our interrupts? Do we stand a chance of loosing interrupts inside it? The comparision to ROM codes has been made, and it seems to be quite valid. Also, token ring support truly is a very good thing. But the issue is not, by any means, clear cut. *Not* supporting those who will simply not open the interface to their products is a form of pressure. It goes both ways, though, and you seem to be more acutely aware of the other side (FreeBSD being pressured into accept closed objects if it wants to support the hardware). Truly, we don't care about the microcode. Even if we had the source, there is good chance we might not be able to compile it. But that single file up there... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!"Larry Lile wrote: > > To dispense with all of the FUD flying about over the .o files: > > trlld.o: is Olicom's hardware interface library - it contains NO > copyrights ... > Someone has brought up the issue that this driver will not work for > Alpha systems. I do not know whether it will or not. Will an > Alpha link a little endian binary into the kernel? Is the object > code compatible, libc wise? I can fix the runtime endian problems > since the interface library does all i/o through routines in my > half of the driver. I do not want to exclude the Alpha users, I > just don't have an Alpha to work on. Also, if we had an installed > i386 user base Olicom might re-compile the objects specifically for > Alpha, but if the driver gets killed that will never happen. The above object file is the problem. It is i386 code, right? Thus, it will not run on alpha. ... > Stop advocating and pick up the phone. Call Olicom, if you can get > them to release the source I will be elated. I have heard the argument > before but no one else is willing to put in the work to get the source > from Olicom. I have spent hours on the phone and countless e-mails with > Olicom trying to get the source code, it it not going to happen any > time soon if at all. In the interim I think Olicom has done well to > provide an interface that open source projects can use, and should be > applauded for their efforts. Don't complain that someone else's efforts > don't measure up to your standards when you are unwilling to put forth > the effort to accomplish it yourself. Sorry Poul, very few people have > tried to add token-ring support to FreeBSD and no one has succeded thus > far. This "fracas" may kill it for good if we are not very carefull > about it. In this regard, I think you are wrong. What is in our tree, we "support". We can fix it and we provide source for, so people can fix any problems themselves. That's something our users expect, and even something we advertise as being one of our strengths. That the above code is i386 only is not really that much of a problem. If Olicom does not wish to support use of their cards in Alpha, that's up to them. The problem is that we surrender control over the source of something in the standard distribution. It is a very bad precedent. Where would we draw a line, now? How can we distinguish this piece of code from anything up to the whole driver? If cannot do it, we might see the day were almost all of our drivers for new hardware are (mostly) in object form, because the companies rather prefer doing it this way than making public the interface to their hardware. I my very personal opinion, this is contrary to what we wish to achieve. There are technical problems as well. For instance, is this code reentrant? If we go to fine-grained SMP, do we know it can have multiple concurrent instances of execution, or we'll have to "big lock" it? Also, what does that object do to our interrupts? Do we stand a chance of loosing interrupts inside it? The comparision to ROM codes has been made, and it seems to be quite valid. Also, token ring support truly is a very good thing. But the issue is not, by any means, clear cut. *Not* supporting those who will simply not open the interface to their products is a form of pressure. It goes both ways, though, and you seem to be more acutely aware of the other side (FreeBSD being pressured into accept closed objects if it wants to support the hardware). Truly, we don't care about the microcode. Even if we had the source, there is good chance we might not be able to compile it. But that single file up there... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!"Larry Lile wrote: > > To dispense with all of the FUD flying about over the .o files: > > trlld.o: is Olicom's hardware interface library - it contains NO > copyrights ... > Someone has brought up the issue that this driver will not work for > Alpha systems. I do not know whether it will or not. Will an > Alpha link a little endian binary into the kernel? Is the object > code compatible, libc wise? I can fix the runtime endian problems > since the interface library does all i/o through routines in my > half of the driver. I do not want to exclude the Alpha users, I > just don't have an Alpha to work on. Also, if we had an installed > i386 user base Olicom might re-compile the objects specifically for > Alpha, but if the driver gets killed that will never happen. The above object file is the problem. It is i386 code, right? Thus, it will not run on alpha. ... > Stop advocating and pick up the phone. Call Olicom, if you can get > them to release the source I will be elated. I have heard the argument > before but no one else is willing to put in the work to get the source > from Olicom. I have spent hours on the phone and countless e-mails with > Olicom trying to get the source code, it it not going to happen any > time soon if at all. In the interim I think Olicom has done well to > provide an interface that open source projects can use, and should be > applauded for their efforts. Don't complain that someone else's efforts > don't measure up to your standards when you are unwilling to put forth > the effort to accomplish it yourself. Sorry Poul, very few people have > tried to add token-ring support to FreeBSD and no one has succeded thus > far. This "fracas" may kill it for good if we are not very carefull > about it. In this regard, I think you are wrong. What is in our tree, we "support". We can fix it and we provide source for, so people can fix any problems themselves. That's something our users expect, and even something we advertise as being one of our strengths. That the above code is i386 only is not really that much of a problem. If Olicom does not wish to support use of their cards in Alpha, that's up to them. The problem is that we surrender control over the source of something in the standard distribution. It is a very bad precedent. Where would we draw a line, now? How can we distinguish this piece of code from anything up to the whole driver? If cannot do it, we might see the day were almost all of our drivers for new hardware are (mostly) in object form, because the companies rather prefer doing it this way than making public the interface to their hardware. I my very personal opinion, this is contrary to what we wish to achieve. There are technical problems as well. For instance, is this code reentrant? If we go to fine-grained SMP, do we know it can have multiple concurrent instances of execution, or we'll have to "big lock" it? Also, what does that object do to our interrupts? Do we stand a chance of loosing interrupts inside it? The comparision to ROM codes has been made, and it seems to be quite valid. Also, token ring support truly is a very good thing. But the issue is not, by any means, clear cut. *Not* supporting those who will simply not open the interface to their products is a form of pressure. It goes both ways, though, and you seem to be more acutely aware of the other side (FreeBSD being pressured into accept closed objects if it wants to support the hardware). Truly, we don't care about the microcode. Even if we had the source, there is good chance we might not be able to compile it. But that single file up there... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!"Larry Lile wrote: > > To dispense with all of the FUD flying about over the .o files: > > trlld.o: is Olicom's hardware interface library - it contains NO > copyrights ... > Someone has brought up the issue that this driver will not work for > Alpha systems. I do not know whether it will or not. Will an > Alpha link a little endian binary into the kernel? Is the object > code compatible, libc wise? I can fix the runtime endian problems > since the interface library does all i/o through routines in my > half of the driver. I do not want to exclude the Alpha users, I > just don't have an Alpha to work on. Also, if we had an installed > i386 user base Olicom might re-compile the objects specifically for > Alpha, but if the driver gets killed that will never happen. The above object file is the problem. It is i386 code, right? Thus, it will not run on alpha. ... > Stop advocating and pick up the phone. Call Olicom, if you can get > them to release the source I will be elated. I have heard the argument > before but no one else is willing to put in the work to get the source > from Olicom. I have spent hours on the phone and countless e-mails with > Olicom trying to get the source code, it it not going to happen any > time soon if at all. In the interim I think Olicom has done well to > provide an interface that open source projects can use, and should be > applauded for their efforts. Don't complain that someone else's efforts > don't measure up to your standards when you are unwilling to put forth > the effort to accomplish it yourself. Sorry Poul, very few people have > tried to add token-ring support to FreeBSD and no one has succeded thus > far. This "fracas" may kill it for good if we are not very carefull > about it. In this regard, I think you are wrong. What is in our tree, we "support". We can fix it and we provide source for, so people can fix any problems themselves. That's something our users expect, and even something we advertise as being one of our strengths. That the above code is i386 only is not really that much of a problem. If Olicom does not wish to support use of their cards in Alpha, that's up to them. The problem is that we surrender control over the source of something in the standard distribution. It is a very bad precedent. Where would we draw a line, now? How can we distinguish this piece of code from anything up to the whole driver? If cannot do it, we might see the day were almost all of our drivers for new hardware are (mostly) in object form, because the companies rather prefer doing it this way than making public the interface to their hardware. I my very personal opinion, this is contrary to what we wish to achieve. There are technical problems as well. For instance, is this code reentrant? If we go to fine-grained SMP, do we know it can have multiple concurrent instances of execution, or we'll have to "big lock" it? Also, what does that object do to our interrupts? Do we stand a chance of loosing interrupts inside it? The comparision to ROM codes has been made, and it seems to be quite valid. Also, token ring support truly is a very good thing. But the issue is not, by any means, clear cut. *Not* supporting those who will simply not open the interface to their products is a form of pressure. It goes both ways, though, and you seem to be more acutely aware of the other side (FreeBSD being pressured into accept closed objects if it wants to support the hardware). Truly, we don't care about the microcode. Even if we had the source, there is good chance we might not be able to compile it. But that single file up there... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36D031F8.F3D8ED7E>