Date: Tue, 21 Jan 2003 16:48:45 -0800 From: Alfred Perlstein <bright@mu.org> To: Sam Leffler <sam@errno.com> Cc: Marcel Moolenaar <marcel@xcllnt.net>, "M. Warner Losh" <imp@bsdimp.com>, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122004845.GM42333@elvis.mu.org> In-Reply-To: <082501c2c1ae$83015c90$52557f42@errno.com> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030122001611.GJ42333@elvis.mu.org> <20030122002453.GA1290@dhcp01.pn.xcllnt.net> <20030122002758.GL42333@elvis.mu.org> <082501c2c1ae$83015c90$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Sam Leffler <sam@errno.com> [030121 16:38] wrote: > > * Marcel Moolenaar <marcel@xcllnt.net> [030121 16:25] wrote: > > > > > The md5s on the generated object files for LINT didn't change except > > for 2 or 3 files where I had to update strings. > > > > But more to the point, do you actually have a technical reason to > > back it out or are you just feeding on the mass hysteria and picking > > nits? > > I disagree with your changes but that's immaterial. To make widespread > changes w/o any review is contrary to the way a _GROUP_ project like this > works. Then to react as you have simply compounds the matter. I value the > contributions you make but you've got to work with folks. I don't know of > anyone involved in FreeBSD that has the right to say f*ck off; and that's > what I hear you saying. I haven't said that. What I keep asking for is a solution other than "back it out". Do I really need to give a message that implies premature ejactulation as much respect as I already have? The only other solution that makes some sense would be to do this: restore M_WAITOK, but make it a bit, 0x02 Now either just share them with the mbuf subsystem... or make the mbuf flags MB_WAIT/MB_NOWAIT. Without looking at the manpages I'd like you to try to remeber which of the old flags went with which interface. Of course we'll still have people making mistakes, and if assertions are sprinkled in to "catch" this, we'll have user or even remote DoS's when it creeps into uncommon code paths. Before we even go down that path, can you show me some code that is not completely obviously wrong that can cause a problem with the current change? There's plenty of cvs history that shows that old flags/interface caused problems. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122004845.GM42333>