Date: Wed, 14 Mar 2001 09:09:51 -0600 (CST) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Chris Sears <cbsears@ix.netcom.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: ecc kld for FreeBSD 4.2 Message-ID: <Pine.BSF.4.32.0103140843280.67772-100000@mail.wolves.k12.mo.us> In-Reply-To: <3AAF10B9.43280512@ix.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.32.0103140843280.67772-100000>