On Thu, Jan 21, 2016 at 02:39:21PM +0100, Michał Kępień wrote: > > Another idea: > > > > What about passing struct calling_interface_buffer from caller allocated > > memory (either from stack or kernel alloc) to dell-smbios which will > > copy it into own buffer under 4GB and then pass it to dcdbas? > > > > This will avoid to use that get/release function and there will be only > > one send_request. > > Well, yes, these two functions could then be ripped out, but the callers > would have to do the error checking on their own. Of course that's not > a bad thing per se, but it changes the currently used concept. > > > But I will let decision for API to other people as I do not know what > > the best API to use here... > > In order to avoid delaying this any further, I'll post a v2 soon and > hopefully it'll be good enough for your Acked-by. If it turns out more > people have misgivings about it, I'll adjust the code. > It seems to me the question is primarily over whether or not the interface protects a shared resource (a common buffer) or if that buffer should be independent for every caller. I favor minimal and incremental change and avoiding complexity where it is not needed. I don't believe there is anything performance critical in any of these paths, e.g. nothing requires a better response time than about 100ms and nothing is likely to occur at a frequency above 10Hz or so. Assuming the above is an accurate view, I don't see any reason to go beyond the minimal change to the existing SMBIOS code to make it a usable API. If the need arises, we can always make such optimizations and performance improvements later. This is an internal API and we can change it whenever we need to so long as we update the call sites. Does anyone have a compelling reason to look for changes to the v2 submitted by Michał? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
