...and it'd help if I provided a pointer to the webrev ;-) http://zhadum.east.sun.com/export/ws/amaguire/nwam1-fixes/webrev/
Alan Alan Maguire wrote: > hi folks > > I'm requesting code review for > > http://defect.opensolaris.org/bz/show_bug.cgi?id=10245 > > Background - the doors interactions in libnwam were > broken. On the door server side, we were sometimes > alloca()ing a return argument, rather than having a client > pass in a maximally-sized buffer. In the course of fixing this > I've addressed another architectural issue relating > to the libnwam backend - namely that when we call > any of the walk() functions for nwam objects, the > walk was carried out by passing back an nvlist of nvlists, > where each nvlist was a property list for each object. > This obviously is problematic as the number of objects > grows. This approach has been amended to passing > back an nvlist containing a list of object names, each > of which is read() individually. This increases the door > traffic for walks, but with the performance improvements > that accrue from moving away from dynamic allocation, > the effects aren't apparent to the user. > > After all this I'm still seeing memory leaks in netcfgd unfortunately, > and these leaks are missing caller information, so ::bufctl_audit > doesn't shed any light on the origin. > > I'm also seeing a 24-byte memory leak in nwamcfg which > only happens when we "list" all objects (doesn't happen > for listing NCUs only for example). > > Any help in tracking down those leaks would be greatly > appreciated, and if any additional background is required > to make sense of these changes, don't hesitate to ask. > Thanks! > > Alan > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
