On Fri, 31 May 2002, Bosko Milekic wrote:
>
> I don't remember why the ext_size here was this originally (as you
> mention, it was imported that way), but it certainly seems bogus and
> you catching it now is hopefully going to solve some really wierd and
> difficult-to-debug problems we've had involving mbufs over the years.
>
It was imported from FreeBSD-1.x by rod.
The size argument was for two reasons.
1/ to allow the M_LEADINGSPACE and M_TRAILINGSPACE calculations
to be done if it was a single reference object.
2/ to allow the free function (in the case of non cluster external
objects) to know what sized object they had in the case that they needed
this information.
I know because I added it, because I needed to do both of these at TRW in
'90-'95 under MACH/BSD and when I moved the code to FreeBSD1.x it cam
along.. there was no M_LEADINGSPACE/M_TRAILINGSPACE macro at that time..
I did it in my code explicitly.
It was not used in standard code because only in my own protocol stack
did I know that the damned object was not shared and writable..
This has improved with time..
Having the size set to 0 however stopped users from hitting
cases where the WRITABILITY of the ext objext has not been correctly
tracked as it always returns "not enough space" (sometimes -ve).
If we change this we need to audit the WRITABILTY..
e.g. it is not checked in M_TRAILINGSPACE
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
