Date: Sun, 21 Feb 1999 13:47:07 -0500 (EST) From: Larry Lile <lile@stdio.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, 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.9902211336080.9637-100000@heathers.stdio.com> In-Reply-To: <17260.919620937@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Feb 1999, Poul-Henning Kamp wrote: > In message <Pine.BSF.4.05.9902211129270.4606-100000@heathers.stdio.com>, Larry > Lile writes: > > > >> *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. > > That is simply not true. > > While it is true that we will not have support for Olicoms T/R > cards in the FreeBSD source tree. That precludes neither > support for other (more open) vendors T/R cards in the source tree. > nor > support for Olicoms T/R as a 3rd party (you!) maintained driver. It is currently the only working token-ring driver. It is not available by default in FreeBSD. It therefore presents a signifigant hurdle to new users. But this is my opinion and it seems we are going to have to agree to disagree on this point. > One of the problems in the FreeBSD project is that we are sometimes > way too centralist. This is one such instance. Code doesn't HAVE > to be in the freebsd source tree to be used. There are quite a > few pieces of software "floating around" for FreeBSD that is not > in the source tree. (There are also quite a number of bits in the > source tree that shouldn't be in there, but rather should be separate > packages). > > (This is btw. one of the few things that the -core team can agree > on: we need to handle and support "external" kernel components > better than we do now). So are my suggestions for making my driver and Olicom's objects more palatble to the source tree not acceptable? What are the points of contention? I would like to know so that I can see what else I could do to fix this. I do think it is important to make the distinction between my driver "if_oltr.c" and Olicom's "trlld.o". There is nothing about my driver, or Olicom's header file "trlld.h", that violate the spirit of the source tree. I think that the driver and header are fine where they live in dev/oltr as it is a combined ISA/PCI driver. 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.9902211336080.9637-100000>