Hello,
I just added a MEXTADD() routine to the [now getting bigger] mbuf
re-write patch, as well as fixed and changed a few little things here and
there (once again). Thus, so-called "version 2" of the diff is again
available: http://www.technokratis.com/code/mbuf/
This code includes all that was discussed in the previous Email, as
well as a better/actually working external storage facility for clusters.
Previously, it was very difficult to allocate external storage, attach it
to the mbuf, _and_ as well maintain a reference counter for it, primarily
due to the arguments that were taken by ext_free() and ext_buf(). These
have been changed to have a new void * pointer passed in as the second
argument (following the base address of the storage buffer). Also has
been included a void * multi-purpose ext_args pointer in the m_ext
struct, so the caller has much more flexibility now. In fact, the caller
can now attach a "management" or "reference" structure to the m_ext
struct via the ext_args pointer, and have it passed to his ext_free and
ext_buf routines. Naturally, for dynamically sized malloc() external
buffers, the caller can also allocate along with it space for its
reference counter and attach to the mbuf via the ext_args pointer. It
will be incremented/decremented properly as ext_args can be passed as the
second argument to the two functions. When ext_free, ext_buf, and
ext_args are all NULL, but M_EXT is set, then the external storage
corresponds to an mcluster.
These changes will surely help out/make cleaner some code, like some
of Bill Paul's device drivers (if_sk, if_ti, if_wb). For other purposes,
such as sf_bufs, for example, it's not _as_ significant, mainly since
sf_bufs are allocated from their own map such that the system can easily
produce a unique index for a reference counter array just by looking at
the offset base_addr_of_sf_buf - base_addr_of_map, like we do for
mclusters. However, obviously, we don't want a new map for every new type
of external storage we want to attach to an mbuf. :-)
(Yes, this means easy attaching of dynamically sized buffers)
What I still have left to do before I look into
finding/bugging/annoying a committer (sigh) to reviewing/committing
all of this:
* Re-write the mcluster allocations/deallocations in the same style
as the new mbuf allocator/deallocator. ... If someone has a more
suitable proposition, please let me know. I love to hear suggestions.
* I'm thinking of adopting NetBSD's "cute" and "clean" reference
count system; they maintain their mbufs linked through the m_ext when
they reference the same storage object. This will remove all fear
from external callers/code having to deal with references in the
first place, and will isolate it all to the mbuf code. Once this is
done, I can also add a NetBSD-like MEXTMALLOC() macro, in addition to
the just-added MEXTADD() macro. This would automate dynamic
malloc()ing of external storage objects, and make it quite a bit
cleaner/easier for the caller.
* Patch up userland to deal with all of these changes.
* Get some profiling / optimisation done.
Since my initial post, I have received quite a few hits/requests for the
posted code, and have even received a few comments/suggestions. These
have been most helpful. I invite many more,... please!
Regards,
Bosko.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://www.technokratis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
