On Mon, 10 Sep 2007, James Carlson wrote: > Dan Price writes: >> FWIW, I had simply assumed that the interface would mimic most other >> memory allocating interface: strdup(mystr, KM_SLEEP) (or if we're >> worried that people will make mistakes if it is called "strdup" then >> call it kstrdup). But again, I think this issue is for the implementor > > I'd thought the accepted way to do this was to prefix with "ddi_" if > it was different from the user-space equivalent. We've done this with > other functions, such as ddi_strtol(9F).
And we already do have: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ddi_implfuncs.h#227 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/devcfg.c#2404 > > I agree it ought to carry allocation flags through, but I also agree > that it's possibly a dubious interface. kmem_free requires the user It's the interface actually already used by the above. Precedence, your honour :) And no, due to the fact that there's no "free(addr)" mechanism for the kernel memory allocator, a complete identity between strdup(3C) and 'strdup(9F)' cannot be achieved ... FrankH. > to pass in the original buffer size, so a typical usage pattern is > like this: > > foo->foo_len = strlen(blah) + 1; > foo->foo_str = kmem_alloc(foo->foo_len, KM_SLEEP); > strcpy(foo->foo_str, blah); > ... > kmem_free(foo->foo_str, foo->foo_len); > > ... meaning that callers usually need to know something about the > string length in order to use 'strdup' in a reasonable way. > > Doing the strlen() twice isn't just a duplicate operation. If it's > done at kmem_free time, it's risky, and relies on users of that string > to avoid truncating it. > > On top of that, it's often helpful to think about organizing the data > structures in a way that avoids lots of tiny allocations -- as strdup > encourages. > > But I guess I don't care much. If someone feels strdup is useful, > have at it. > >> to decide. >> >> Probably this belongs on osol-code... :/ > > Redirecting ... > > -- > James Carlson, Solaris Networking <[EMAIL PROTECTED]> > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 > _______________________________________________ > opensolaris-code mailing list > opensolaris-code@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code > _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
