Date: Sun, 21 Oct 2001 21:04:06 -0400 From: Sergey Babkin <babkin@bellatlantic.net> To: Mike Smith <msmith@freebsd.org> Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, msmith@mass.dis.org Subject: Re: FYI Message-ID: <3BD37086.7A14C464@bellatlantic.net> References: <200110190319.f9J3Jfo06174@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > > > 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. What about between 3.x and 4.x ? And 5.x is going to be yet another major change. > > 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). And if some code uses these macros and has to be recompiled then this becomes an issue. And not only for the drivers but for applications too. Remember, that the thing that broke in -current was vi. Another example would be the compatibility PCI infrastructure ripped out of -current together with a few drivers that were not newbussified yet. If people don't bother about the drivers in the source form that are parts of the official tree, they bother even less about the third-party drivers. I can understand when supporting some old piece of technology requires extra effort which is not available, so it gets into disrepair and eventually gets ripped out. But when people spend _extra_ effort on ripping out the perfectly working things which can stay in the tree for a few more years without any need for support, this amazes me to no end. > > 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. Think of newbussification. Or of CAM-ifying. > > 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. Sorry, I've meant to say a.out, not COFF. > Of course there isn't, and there'd be no point in it. Why do you think so ? I've given you one real example why it could be useful. > > 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. Which is not a too easy and obvious thing to set up. Plus at least install the static a.out libraries and headers from 3.x. > > 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. Maybe I'm missing something but I can't see how keeping compatibility can inconvenience someone. On the contrary, the inconvenience happens when this policy is not followed. > 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. If we hide our heads in the sand in an ostrich fashion, it won't help that much either. And this information is relevant though maybe not always quite accurate. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BD37086.7A14C464>