Re: [Patch] 2.6.10.rc1.bk6 /lib/kobject_uevent.c buffer issues

[Andrew <cmkrnl@speakeasy.net>]

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
> 
>