Date: Wed, 05 Feb 2003 10:56:59 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: phk@freebsd.org Cc: Dag-Erling Smorgrav <des@ofug.org>, David Schultz <dschultz@uclink.Berkeley.EDU>, arch@freebsd.org Subject: Re: New kernel allocation API Message-ID: <3E415E7B.25C1D42@mindspring.com> References: <40415.1044456946@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
phk@freebsd.org wrote:
> If we are going to implement a new kernel allocator API, there are
> a host of issues we should consider, Jeff already mentioned one of
> them, passing size to ::free, and we must also design the API so that
> we can implement debugging and correctness checks in an efficient
> and usable manner.
For someone who uses C++ scope identification in the listing of the
function name "free", your support of knowing the size of the object
being freed is mystifying. If the size of the object is passed in
to the free function, it means that it can't be freed by a function
which destructs a superclass. E.g.:
struct superclass {
...
};
struct class1 { /* 1024 bytes */
struct superclass c1_sc;
...
};
struct class2 { /* 512 bytes */
struct superclass c2_sc;
...
}
struct superclass *
zifmeac1()
{
struct class1 *c1p;
c2p = malloc(sizeof *c1p);
...
return((struct superclass *)c1p);
}
struct superclass *
zifmeac2()
{
struct class2 *c2p;
c2p = malloc(sizeof *c2p);
...
return((struct superclass *)c2p);
}
main()
{
struct superclass *sc;
...
if( condition)
sc = zifmeac1();
else
sc = zifmeac2();
...
free( sc);
}
> Considering the problems our kernel suffers from at the moment,
> inventing a new memory allocation API is not even on the top 50
> list of things we need to do.
>
> So can we just shelve this proposal until we have time and need for
> it and until we know (even) more about the needs of our SMPng kernel ?
You mean like "the ability to deprecate blocking allocations
incrementally, by changing which API is used"? That's what DES's
patch provides.
-- Terry
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?3E415E7B.25C1D42>