Date: Sun, 21 Feb 1999 10:30:00 -0500 (EST) From: Larry Lile <lile@stdio.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: 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: <Pine.BSF.4.05.9902210846280.8995-100000@heathers.stdio.com> In-Reply-To: <15806.919595472@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Okay, I had forgotten that cvs-committers was a closed list. My last
e-mail therefore probably only went to Jordan. Would everyone please
keep me CC'd on whatever goes across committers, reading committers
over the mail archive is just not effective.
First of all the .o files are my responsibility, Julian shouldn't be
getting raked over the coals for my sin.
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
trlldmac.o: is the TMS-380 Microcode - it is the one WITH copyrights
trlldhm.o: is the "hawkeye" microcde - it contains NO copyrights
trlldbm.o: is the "bullseye" microcde - it contatins NO copyrights
I was given tacit aproval from Olicom to redistribute these files and
any others from the PowerMACH Works kit. The whole kit can be downloaded
from Olicom's ftp server freely and without registration, and is made
for the explicit purpose of building drivers and boot proms for their
adapters. I have commmited to getting written permission from Olicom
as soon as they open monday.
I wish I had been able to get the source for trlld.o ( the interface
library) but they WILL NOT release it, even under NON-DISCLOSURE. I
have tried BOTH ways. I have also tried to get them to re-compile the
object in a.out format for 2.2.x but they will not unless there is a
business case, ie customers with cards who want the library. They
already provide the library in 4 object formats. They are trying to
balance their need to protect their asic's and the need for open-source
drivers. Compromise, imagine that. I do not think the driver should be
excluded from the source tree simply because it relies on an object
library from Olicom that must be a part of the kernel. This would be
a dis-service to FreeBSD and the token-ring users that are being excluded.
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.
I do not think that the inclusion of the interface library is going to
lead to the degredation of the source tree into ".o-files only". I also
think adapter microcode being "grudginly accepted" is a bit over zealous.
Why do we care what is in the microcode for an embeded processor on an
adapter?
> I personally advocate the position that any instruction executed
> on the CPU must be available in source form, and therefore this
> driver should not live in the FreeBSD source tree unless we can
> get the source from OliCom.
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.
Now can we all put aside the hostility and discuss this calmly and
sanely like adults as Jordan suggested earlier. The object files
are MY responsibility, I do not want to see Julian getting roasted
over this. If you want to roast someone, aim my way. When it is
all said and done, it was my doing - I wrote the driver.
Now how do we save the oltr driver and token-ring support for FreeBSD?
Larry Lile
lile@stdio.com
PS: I think I may take up windmill jousting as a hobby :P
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?Pine.BSF.4.05.9902210846280.8995-100000>