From owner-freebsd-hackers Thu Oct 18 20: 8: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A07A337B403; Thu, 18 Oct 2001 20:07:55 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9J3Jfo06174; Thu, 18 Oct 2001 20:19:41 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110190319.f9J3Jfo06174@mass.dis.org> To: babkin@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, msmith@mass.dis.org Subject: Re: FYI In-Reply-To: Message from Sergey Babkin of "Thu, 18 Oct 2001 22:50:35 EDT." <3BCF94FB.50F5D295@bellatlantic.net> Date: Thu, 18 Oct 2001 20:19:41 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Well, honestly, FreeBSD makes the life of the developers of third-party > binary-only drivers fairly difficult. It does? On the whole, actually, I'd say we do a pretty good job of making it easy. > The reason is that there > are a lot of API changes happening between the releases (take > Julian Elisher's recent problem for example). It's a poor example. Drivers don't involve themselves in the sysinit chain. > So the driver writers > are forced to at least recompile their drivers for each release. This isn't typically the case, actually. 4.x has in fact been very good in this regard. > Plus people are very active at ripping away the old APIs even > when there is no immediate need for that nor benefit from it (think > of phk's removal of the LIST-something macros). The removal of the LIST* macros doesn't affect the kernel interface (they're macros, not functions). > So often not > a simple recompilation but a noticeable rewrite may be required > for a driver between different versions of FreeBSD. I've been maintaining drivers for a while now, and frankly, I just don't see this. > That actually is true not only for the drivers but for the usual > binaries too. For example, there seems to be no way to combine > COFF and ELF libraries into one executable. Of course there isn't, and there'd be no point in it. > That made porting > of Lyx to 4.0 unfeasible, as the binary-only Xforms library it > used was at the time available in the COFF form only. And I haven't > found how to build even purely COFF binaries on an ELF-ized > system either. Use a cross-gcc setup. Of course, you mean a.out, but your error doesn't help your case much. > Maybe we should have an official policy of keeping the things > compatible and available for as long as possible even if they are > considered obsolete, unless carrying them on requires a major > effort. We do. And we do. Of course, this effort goes largely unnoticed and unthanked, since you're not going to comment on it unless you're personally inconvenienced by it. I've asked before, I'll ask again. Will folks please just let this die? You're producing a great deal of archive-filling material that's just not accurate or relevant, and your misinformation is harmful to the Project in a very real fashion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message