[RFC] Proof-of-concept for netlink listener for mdev -i

[Laurent Bercot]

On 20/03/2015 17:47, Isaac Dunham wrote:
> I'm not sure I follow you on the malloc/free/realloc bit:
> -as far as I know, getenv() does not malloc() anything, but returns
> the numeric value of a pointer within char ** environ

  getenv() is not a problem indeed. (Reading is rarely a problem,
it's writing that's tricky.)


> -according to the manpage, putenv() does not copy the string, but
> modifies environ by inserting a pointer to the string.
> If the environ buffer is too short, environ may be expanded by
> calling realloc() - is this what you refer to?

  Yes, partly. But you would *also* have to copy the string. You
cannot have an environment variable pointing into a temporary buffer,
that you may overwrite on subsequent reads. Sure, it's very unlikely
to happen, given the kind of data coming out of the netlink, but you
cannot guarantee it won't. Generally, you don't want to store pointers
to short-lived storage.


> since I'm using pointers into msgbuf.

  I don't think you can do that safely. You can use pointers into
msgbuf for the current event's lifetime, because nothing's going to
overwrite msgbuf during that span; but the environment is more
permanent.


> I'm thinking that it may make sense to use
> 	getkey(char *key, char *buf, size_t n);
> in places that use
> 	getenv(key);

  Yes, I think it's the right solution. Don't tie your key-value store
interface to a given implementation. :)


> I should probably replace the memset() before read() with
> msgbuf[len] = 0; after read().
>
> I was just using a hammer to deal with strlen possibly overrunning
> the buffer, should we ever read something that ends with a partial
> KEY=VAL pair and no NUL terminator.

  The function you're looking for is strnlen().


[ circular buffer code ]
> If that's desired, someone else will need to do it.

  I already have that code in skalibs. But as I said, I'm not going
to skalibsify busybox - as much as I'd like it, it is too slippery
a slope.


> I waited as long as I did in hope that someone else would pick it up.

  Same here. Thanks for being even less patient than I am. ;)

-- 
  Laurent