Date: Thu, 20 Dec 2001 23:40:54 +0100 From: "Anthony Atkielski" <anthony@freebie.atkielski.com> To: "John Baldwin" <jhb@FreeBSD.org> Cc: "Jeremiah Gowdy" <jeremiah@sherline.com>, <advocacy@FreeBSD.org>, "Gilbert Gong" <ggong@cal.alumni.berkeley.edu> Subject: Re: Microsoft Advocacy? Message-ID: <027901c189a7$62a133c0$0a00000a@atkielski.com> References: <XFMail.011220140725.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > Uh, this is _specifically_ for UP machines. That occurred to me as I was pressing the send button. > 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? 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. > This only serves to display your ignorance. No, it simply proves that I've been there, done that, and learned from my mistakes. The longer you write system software, the more conservative and cautious you become. > You missed my point: this design goal came > from worrying about user needs (desktop) rather > than server needs. I don't see how that goal would be specific to a desktop environment. > It was when it was first done in BSD. Maybe it was for BSD, but algorithms like that have been around for as long as operating systems have (or at least since CPUs overtook I/O performance-wise). 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?027901c189a7$62a133c0$0a00000a>