Date: Mon, 19 Jan 1998 14:23:11 +1030 From: Mike Smith <mike@smith.net.au> To: dennis <dennis@etinc.com> Cc: Eivind Eklund <eivind@yes.no>, hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <199801190353.OAA00932@word.smith.net.au> In-Reply-To: Your message of "Wed, 14 Jan 1998 09:59:30 CDT." <3.0.32.19980114095929.00f92c20@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> A clear and growing problem with the FreeBSD camp is that no one > cares about the RELEASES, which is what most of the real world is > using. telling me that a bug was fixed in 3.0 in March and still hasnt > made it into a release explains why the releases over the past year > have been rather disappointing with much of the FreeBSD talent's > focus elsewhere. This highlights the fact that *you* should be pulling changes back from -current, testing them in your obviously well-equipped lab with your obvious amounts of spare time, and forwarding changes for committing. The "problem" is that people like you would prefer to carp on about nobody caring rather than actually caring yourself. If you are willing to *guarantee* that you will look at one major bugfix per week that's made it into -current, backport it to -stable, test it (and I'd bet you can find a few people to help there), I will match your guarantee with my own; that your diffs *will* be attended to in a timely fashion, and they *will* make it into the next release off the -stable line. > The de driver is another illustration of that. The 'de' driver receives continued attention from various people, most notably Peter Wemm. If we were to follow every one of Matt's updates in -stable, people would be screaming a lot louder than they do now. > >It is wrong if userland can make a kernel panic, I agree. If kernel > >bugs can make the kernel panic, that is OK by me. > > If an add-on driver makes a bad call a warning should be printed and the > operation refused. Its time that FreeBSD recognize that 3rd party > software exists (especially with loadable modules) and that errors > aren't confined to core team's test beds. I don't think you have thought this through very carefully. Many of the interfaces presented to a driver are not procedural; straight memory access not being the least of these. In most cases, where it is possible and reasonable to vet arguments to a function, they are vetted. Generally however it is expected that callers will supply sensible arguments to functions; if they don't then you have a bug that should be caught by the developer during testing, and a panic is a simple means of ensuring this. If a vendor produces a buggy add-on driver, the problem is *solely* the vendor's. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801190353.OAA00932>