From owner-cvs-all Sun Feb 21 11:57:45 1999 Delivered-To: cvs-all@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8120811555 for ; Sun, 21 Feb 1999 11:57:42 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id EAA25967; Mon, 22 Feb 1999 04:52:38 +0900 (JST) Message-ID: <36D0621D.12BF872D@newsguy.com> Date: Mon, 22 Feb 1999 04:44:29 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Larry Lile Cc: Poul-Henning Kamp , Julian Elischer , "Jordan K. Hubbard" , cvs-all@FreeBSD.ORG Subject: Re: Current status of the olicom fracas. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Larry Lile wrote: > > Without accepting the closed object, at this time, we are taking away > token-ring support for FreeBSD. And that is unfortunate. The alternative, compromising on a very basic principle, is also unfortunate. So, it is between two unfortunate options. > 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. We have at least two options in this regard: 1) Give the driver back to them, so they can distribute it themselves. 2) Provide the driver separate from the distribution. We also have one other option I mention below. Someone already suggested a port. Can we make a kld out of it, building it as a port? KLD's can be loaded at boot time, so that's about as good as having it compiled in the kernel. Except for installation over (token ring) network. > 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. IMHO, it is a *big* compromise for us. Even if it is just a small file, playing a small part in a single driver, it is a fundamental change to our philosophy (as I perceive it to be, granted). Now, we have a "license" exception with regards to softupdates. It resides in src/contrib, and requires explicit activation by the user, in the form of the symbolic link. The same thing could be done in this case. Place this specific file under src/contrib, with a README file explaining it is a black box (and the licensing terms -- do not reverse engineer, I suspect), and the linking instructions, and mention it in the LINT. To me, the license exception is a far bigger issue. Granted, it is said that softupdates may eventually get a standard BSD-style license, but that is not the case at the present. I never heard the arguments for it's inclusion (I would expect the core to have arguments over this, at the very least :), but it's usefulness to a great number of users must sure have been taken into account. Same could be said of token ring support. > 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... The problem is not much what trlld.o does. The technical problems weight in far less than the "philosophical" ones. Or, at least, I think so. -- 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