Messages in this thread | | | Date | Wed, 27 Oct 2004 12:31:52 -0400 | From | Andrew <> | Subject | Re: [Patch] 2.6.10.rc1.bk6 /lib/kobject_uevent.c buffer issues |
| |
Greg KH wrote: > > > Why not just use the same buffer? We should be able to do that. > > > I'd prefer we use the same buffer. Care to respin your patch? >
Sure, I can only see two ways of achieving that however. 1) Change the API of kset_hotplug_ops.hotplug() to return the amount of consumed buffer (and possibly an updated value for i (num_envp) and then changing every real function that implements that interface or 2) Spin through the envp[] starting at i to NUM_ENVP looking for a NULL pointer dropping back 1 (last_used) then do a scratch += strlen(envp[last_used]) + 1
I don't know if you would rather keep the kset_hotplug_ops.hotplug() API unchanged and have a "find the NULL" or vice-versa? -- or are both too ugly? Ultimately the first option would generate the "cleanest" solution, but I would be wary to change an API (especially one I didn't create myself)
I can also see variation of 2), where buffer is prefilled with something like '0xff' then the find the null would run in reverse from buffer+BUFFER_SIZE-1. Either way with 2), the reservation in envp[] for the seq_num would have to stay, but its locaton in buffer would be at the end. As a bonus of course then the call to send_uevent could see the entire buffer.
I'm looking now for how many changes would be required to do option 1.
Andrew
> thanks, > > greg k-h > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |