Add get methods for name of program and map

[aibor]

When working with objects loaded from fds, it can be useful to have access to their names. This is already possible via their *Info structs. The objects themself have a name field, though, which are provisioned with the *Info's value. So, the name is already present in the objects, but not exposed yet.

This commit adds methods to Program and Map to access the value of their name field.

[ti-mo]

obj_info has been around since 4.15 (which is fairly old) but since it was a relatively late addition, we never considered it to be a part of the core Map or Program abstractions. They're only used minimally for Map/Program string representations, and since we've never been able to depend on their presence, we're sloppy about populating the field. We still officially support 4.9 and 4.14 where this info can't be retrieved, so it would only return output on some kernel versions.

Adding these accessors would add a second way of retrieving the same information, which isn't good UX. obj_info name is also limited to 20 chars, which is guaranteed to surprise users expecting MapSpec.Name and Map.Name() of the resulting object to always match. Is going through MapInfo really too cumbersome?

[aibor]

I agree that exposing basically the same value at two locations is not ideal. Also, the name string length limitation and potential for surprise potential are definitely not ideal as well.

When retrieving name via Info(), those limitations apply as well, though. But you also need to handle the error that Info() may return. There is a reason why this field exists in the object structs and is not always retrieved via Info(). So, since the field is already there, it appeared natural to expose it as well.

In case the change is approved, I should probably add documentation for the the limitations (length and kernel version requirement) to avoid surprises before it is merged.

[lmb]

I agree with Timo, exposing this information in addition to .Info() is a bit problematic. Timo already mentioned the problems with old kernels, but there are additional wrinkles with maps and programs retrieved from a pin. Also NewMapFromFD and similar.

[aibor]

Fair enough. Thanks for the review and the explanation. Appreciate it. :)