Date: Sun, 21 Feb 1999 12:30:53 -0500 (EST) From: Larry Lile <lile@stdio.com> To: "Daniel C. Sobral" <dcs@newsguy.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: <Pine.BSF.4.05.9902211129270.4606-100000@heathers.stdio.com> In-Reply-To: <36D031F8.F3D8ED7E@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I hope the fact that your message was duplicated 5 times over was
some problem with your mailer. 8/
On Mon, 22 Feb 1999, Daniel C. Sobral wrote:
> 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.
The gnashing of teeth was over the copyrights in the microcode, from
PHK's commit log:
I urge that nobody use this driver until we have these issues resolved.
cd /sys/dev/oltr
for i in *.uu
do
uudecode < $i
done
strings *.o | grep -i copyright
161298 Copyright (c) 1998 Olicom. All rights reserved ,!,!n7
161298 Copyright (c) 1997, 1998 Olicom. All rights reserved
(C) COPYRIGHT IBM 1983,4,5,6(C) COPYRIGHT TI 1983-89,90-94
EO V228.10.18 (C) Copyright Olicom 1998.
SMAC.00.38 (C) Copyright Olicom 1998.
I was ony trying to make clear where the copyrights were and PHK said
that microcode could be "grudgingly accepted". I assume that is after any
licensing/copyright issues are resolved.
That does not mean that the interface object issue has been resolved, and
I am sure the same licensing/copyright issues apply.
> > 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.
The FreeBSD half of the driver is available in source. Olicom provides
support for the object. The FreeBSD half of the driver is the majority of
the logic in the driver. I do understand your position though.
> 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.
As I have said before, I would like to have the source for the interface
but it is not feasible currently. It should be easy however to determine
that, in this case, that the object is only a hardware interface and not
a driver. It uses the FreeBSD half of the driver for all i/o amd I have
to allocate memory for it to use (and pass it to the object). It does
not effectively even touch the PC except that the code is executed in
the PC's processor.
In my experience companies either provide all of the interface
specs or none. In the latter case they usually won't help at all.
> 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?
It is the drivers responsibility to handle these problems with whatever
OS specific code that is neccesary. In other words, I have to do the
proper spl/mutex protection in my driver code. Take a look at if_oltr.c.
All of these technical problems must be resolved in the FreeBSD half of
the driver.
> 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.
I beleive the comparison to ROM is also valid. I think token-ring support
is a good thing, otherwise I wouldn't have written it. I appreciate your
support. I am trying to help resolve the issues at hand.
> *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).
Without accepting the closed object, at this time, we are taking away
token-ring support for FreeBSD.
Olicom may be more willing to release the source if they see a "customer
base". Right now that "customer base" is me, and that is not very
exciting to them. But I am glad they have provided PMW kit as a
compromise, it is better than no chance at all.
I do not like having to use their object, I would much rather have source.
I would settle for interface specs. This is a compromise.
>
> 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...
I think people are assigning much more power to trlld.o than it really
has. It is just dumb hardware interface code, it knows where to get
info out of the card (using my i/o routines), how to twiddle card settings
(...), I give it buffers to store packets in, I give it buffers I want
transmitted, etc. It is simply a way for Olicom to "hide" its asic
interface, again I personally dont like it but...
Larry Lile
lile@stdio.com
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.9902211129270.4606-100000>