Peter Wemm wrote:
> Luigi Rizzo wrote:
> > The change below has been committed to STABLE 7 weeks ago, but did
> > not go into CURRENT because there was some disagreement on the
> > semantics of M_LEADINGSPACE. However I would strongly vote for
> > committing this change to CURRENT as well, given the huge performance
> > implications (even if the 21143 were not buggy, not being able to
> > write into clusters hurts a lot of pieces of the networking stack).
> Incidently, this is a poster-child example of why fixes are not to go to
> -stable first. It leads to exactly this sort of lossage.
If we waited for all disagreement about semantics in -current to be
resolved, we would all be tripping over our beards before some things
would be committed.
Is the semantic complain going to be overridden by the performance
advantages of not caring about the semantics, only the speed?
> rev 220.127.116.11:
> This does not go in CURRENT as is: as discussed in -net,
> M_LEADINGSPACE should not check for writability, just report
> available space, leaving the check to some other piece of code.
> Unfortunately, some code in the tree depends on M_LEADINGSPACE
> checking for writability, and so implementing M_LEADINGSPACE
> in the correct way also requires to fix the incorrect usage.
> This is what will be done in CURRENT, but for STABLE, this is
> probably more than we want, and so we are happy (more or less) with
> this simple fix.
> How about fixing it for real as described in the commit message?
Uh... "patches welcome from the people who complained about the
writability check"? 8^) 8^)...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message