Date: Thu, 20 Dec 2001 14:51:12 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Anthony Atkielski <anthony@freebie.atkielski.com> Cc: Gilbert Gong <ggong@cal.alumni.berkeley.edu>, advocacy@FreeBSD.org, Jeremiah Gowdy <jeremiah@sherline.com> Subject: Re: Microsoft Advocacy? Message-ID: <XFMail.011220145112.jhb@FreeBSD.org> In-Reply-To: <027901c189a7$62a133c0$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Dec-01 Anthony Atkielski wrote: > John writes: > >> Yes, I have read them. I also note that the >> ones I am willing to sign do not make restrictions >> on the open source software I develop. > > Even if you are willing to stand your ground, can you be certain that all > others do the same? Yes, I'm quite certain of Mike and Jordan since we worked together at our last jobs and they fought rather vehemently to have the IP agreement toned down to allow unrestricted Open Source development. >> Unmaskable interrupts are usually fatal >> machine exceptions where we are about >> to panic anyway, so they are not a concern. > > Usually? What are the exceptions, and how do you handle them? NMI's on a PC, or a double fault, which you can't really handle. If you get a page fault or some such while holding a spin lock, it is always a panic (usually a null pointer dereference) since we only hold spin locks in very small sections. > If you have locks that are set only within code that inhibits interrupts, > you don't have to worry about the overhead of spinning on them, because they > will always be unlocked. If you remove the locks, though, and for any > reason the code is interrupted by an unmaskable interrupt, you may > experience an unpredictable system failure. Leaving the lock in incurs very > little overhead and offers a sanity check, just in case you overlooked > something. Uh, no. Atomic operations are _quite_ expensive. On x86, they lock the bus which means waiting until the bus is free. On sparc64, they involve using a barrier that forces the CPU to flush its store buffer before handling the actual atomic operation. Alpha, ia64, and ppc have similar expenses. But anyways, this isn't an advocacy issue. If you really care, first go look at some actual code to see where these things are used and how, then you can bring up a discussion on -arch, -hackers, -smp, or some other more appropriate list in response to whenever I get around to committing it after testing. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011220145112.jhb>