Date: Sun, 21 Feb 1999 15:27:57 -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.9902211458000.11748-100000@heathers.stdio.com> In-Reply-To: <36D0621D.12BF872D@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My preference is the last option but I am not going to cross my arms and arbitrarily discard all other options though. On Mon, 22 Feb 1999, Daniel C. Sobral wrote: > We have at least two options in this regard: > > 1) Give the driver back to them, so they can distribute it > themselves. The source for the driver then is no longer under FreeBSD's control and may suffer from bit rot. Also they may make un-acceptable copyright changes. > 2) Provide the driver separate from the distribution. This gets back to the difficulties of installing without proper support and newbies may not understand. Do you really want to answer all of those "but you say token-ring is supported, how come I can't install" and etc questions. > 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 don't know. I have never made a port, package or kld. I would also worry about things like version forks occuring between the driver and the kit files. Also things like this tend to evaporate from commercial websites or get moved, in reference to the PMW kit. So I would like to find somewhere "safe" to get it stored. Safe places being one of the FreeBSD CD's and ftp.freebsd.org. :) > > > 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. I mentioned that in one of my previous messages. * For the interface library, where. It is related to both the i386 and * the oltr cards. Could we have it placed in /usr/src/contrib/Olicom? * It could have i386 and Alpha directories if neccesary. We could * also place a disclaimer in with it. * * Olicom's header could live in either sys/dev/oltr or contrib/Olicom it * is only a matter of changing files.i386. That seems to me like a reasonable and fair compromise. Just force the users to link the object (or actually .o.uu) files into dev/oltr by hand and I would leave files.i386 looking in dev/oltr. If you didn't go make the links your kernel compile would die, maybe I could find a way to warn users during config or something. Definately noted in LINT and never active in GENERIC by default. Some kind soul might want to build a boot floppy though. 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.9902211458000.11748-100000>