> From [EMAIL PROTECTED] Fri Nov  8 11:30:05 2002
> Date: Fri, 08 Nov 2002 09:27:32 -0700 (MST)
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] note the __sF change in src/UPDATING
> From: "M. Warner Losh" <[EMAIL PROTECTED]>
>
> In message: <[EMAIL PROTECTED]>
>             Ray Kohler <[EMAIL PROTECTED]> writes:
> : > From [EMAIL PROTECTED] Fri Nov  8 02:45:04 2002
> : > Date: Fri, 08 Nov 2002 00:39:35 -0700 (MST)
> : > To: [EMAIL PROTECTED]
> : > Subject: Re: [PATCH] note the __sF change in src/UPDATING
> : > From: "M. Warner Losh" <[EMAIL PROTECTED]>
> : >
> : > In message: <[EMAIL PROTECTED]>
> : >             Ray Kohler <[EMAIL PROTECTED]> writes:
> : > : Hear hear, I agree. There's no need to expose what ought to be
> : > : "private" data to the world, especially when we can get the additional
> : > : benefit here of letting us play with the implementation.
> : >
> : > -current already does this.  The problem is that we're trying to shoot
> : > the bad access in the head, and that is what is screwing people.  So
> : > the problem isn't that we're trying to export private data to the
> : > world.  Quite the contrary, we're trying to eliminate it and having
> : > growing pains.
> : 
> : Exactly. That's why I'm arguing against putting __sF back (or
> : adopting equally crapulent measures). Growing pains are a necessary evil.
> : (I also agree that we probably ought to staticize any other things of
> : this nature while we're at it and get the pain over with.)
>
> Yes, but this is too painful.  If we were going to do this, the time
> for the pain was 6-9 months ago, not just before the release.

Yeah, that's true. I think unfortunately we ought to wait and do it
next cycle, but when we do, do it completely and as quickly as possible.

- @

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to