[request-sponsor] 4884338:There should be a generic implementation of strdup() in the kernel
On Thu 06 Sep 2007 at 09:16PM, madhav chauhan wrote: Hi, I came across this bug while browsing through the bug database. I am working on this bug .I have already signed the Sun Contributor Agreement and my SCA number is OS0106. Please let me know the procedure for working on this. Madhav, For some reason I remember Roger objecting to strdup() on principal, but I don't exactly remember why ... although that was 6 or 7 years ago. I have CC'd him. Admittedly, since then we've seen a bunch of new code which defines its own version of strdup. I'm going to move some stuff from the comments part of that bug report into the description... it should show up there in about 24 hours, and might help you. The other interesting question would be whether this should be placed into the DDI (i.e. strdup(9f) as a peer to strcpy(9f)), although I suppose that could be done later. You'll also want to ensure that you have some consumers for this functionality-- the obvious thing would be to rip out the various other strdup's which exist. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
[request-sponsor] 4884338:There should be a generic implementation of strdup() in the kernel
Quoting Dan Price, who wrote the following on Fri, 7 Sep 2007: On Thu 06 Sep 2007 at 09:16PM, madhav chauhan wrote: Hi, I came across this bug while browsing through the bug database. I am working on this bug .I have already signed the Sun Contributor Agreement and my SCA number is OS0106. Please let me know the procedure for working on this. Madhav, For some reason I remember Roger objecting to strdup() on principal, but I don't exactly remember why ... although that was 6 or 7 years ago. I have CC'd him. Admittedly, since then we've seen a bunch of new code which defines its own version of strdup. I'm going to move some stuff from the comments part of that bug report into the description... it should show up there in about 24 hours, and might help you. The other interesting question would be whether this should be placed into the DDI (i.e. strdup(9f) as a peer to strcpy(9f)), although I suppose that could be done later. You'll also want to ensure that you have some consumers for this functionality-- the obvious thing would be to rip out the various other strdup's which exist. The obvious question is-- how does one specify whether KM_SLEEP/KM_NOSLEEP is used for the underlying allocation (for kernel applications). --S
[request-sponsor] 4884338:There should be a generic implementation of strdup() in the kernel
On Fri, Sep 07, 2007 at 01:34:15PM -0700, Seth Goldberg wrote: You'll also want to ensure that you have some consumers for this functionality-- the obvious thing would be to rip out the various other strdup's which exist. The obvious question is-- how does one specify whether KM_SLEEP/KM_NOSLEEP is used for the underlying allocation (for kernel applications). The first-cut obvious answer is KM_NOSLEEP, since strdup() CAN return NULL on failure. The reason I put obvious in quotes is because KM_SLEEP allocations have unusual properties that can cause starvation or some other undesirable system effect. I can't recall the bugid, but there's an RFE out there for a lighter-weight KM_NOSLEEP, which has the semantics of KM_SLEEP but for the actual blocking, instead returning NULL. I'm Bcc:-ing someone who discovered this problem, and may know the bugid, as well as the precise issue with using KM_NOSLEEP. Dan
[request-sponsor] 4884338:There should be a generic implementation of strdup() in the kernel
On Fri 07 Sep 2007 at 04:40PM, Dan McDonald wrote: On Fri, Sep 07, 2007 at 01:34:15PM -0700, Seth Goldberg wrote: You'll also want to ensure that you have some consumers for this functionality-- the obvious thing would be to rip out the various other strdup's which exist. The obvious question is-- how does one specify whether KM_SLEEP/KM_NOSLEEP is used for the underlying allocation (for kernel applications). The first-cut obvious answer is KM_NOSLEEP, since strdup() CAN return NULL on failure. The obvious answer to me is that you would survey all the kernel code which has implemented strdup()-like functionality and then make a decision based on this requirements gathering exercise. 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 to decide. Probably this belongs on osol-code... :/ -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
