From owner-freebsd-hackers Wed Mar 14 7:10:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 52F0A37B71A for ; Wed, 14 Mar 2001 07:10:01 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id JAA68648; Wed, 14 Mar 2001 09:09:51 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 14 Mar 2001 09:09:51 -0600 (CST) From: Chris Dillon To: Chris Sears Cc: Subject: Re: ecc kld for FreeBSD 4.2 In-Reply-To: <3AAF10B9.43280512@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Mar 2001, Chris Sears wrote: > THANKS! and compliments on your name. It was a quick and simple > port to see if people were interested. I've sent it to the > author/maintainer Dan Hollis but I haven't gotten a response yet. > He has an email list on Yahoo/Groups and there is occasional > traffic so it isn't dead code. I'm sure there would be much interest, especially since FreeBSD is run on many systems with ECC memory subsystems. I, for one, don't build a server without ECC memory and a chipset that does auto-correction/scrubbing. It would be taboo. Even my workstations have it. :-) > Yes, I did notice that there was no licensing. I will broach that > with him. I can live with GPL since I see this as being a KLD > which can be installed from source. But I prefer BSD. Since not everybody would want to use a module, or even could use a module, a BSD license would be ideal so that it could be compiled directly into the kernel. It is entirely up to the author what he wants to use, of course. > DEV_MODULE vs DRIVER_MODULE. It is true that DEV_MODULE is much > less common but it is minimally sufficient. If it were a > DRIVER_MODULE, then it would just be allocating a bunch of > structures and entry points and noop'ing them out. But perhaps > someone else could lend an opinion. Looking at the differences, DEV_MODULE did look quite a bit easier to use. :-) > Thanks for the 440BX patch, I'll add it. As far as the > ServerWorks III chipset, the necessary documentation has *not* > been available. I think they are a small company and a little > paranoid WRT intellectual property. If you have it, or if you can > get it, this would be great. It wasn't really a 440BX-related patch, just some pretty-print information when the module was loaded, some of which is probably irrelevant and could be removed (such as the SBE/MBE stuff). Just saying that the ECC module was loaded was a little bit too light on the information side. :-) On a similar note, how can we go about getting similar run-time information out of this, such as the current count of SBEs and MBEs? Some sysctls perhaps? The current code uses procfs under Linux, but that seems ugly to me. > Basically, I would like to break the file into Linux, BSD and ecc > sections. This would simplify things for the author who has > expressed interest in a kernel patch as well as a module. The > reason for kernel was that module support can be config'd out on > Linux. I talked to Daniel O'Connor on IRC, and he mentioned he would like to clean it up a bit. Splitting it into OS-specific and OS-independant parts would be a good idea, I think. > I'm not sure how kld's are distributed as there don't seem to be > any in the ports collection. And I wouldn't mind cleaning it up a > bit. Actually, I can think of at least two -- ports/emulators/rtc, depended on by the ports/emulators/vmware2 port, which has yet another kernel module in it. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message