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

[Andrew]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/