Could we have access to BPFMap private fields?

[geyslan]

Once BPFMap already maintains private fields which could be needed further in the code, could the consumer have access to them? E.g.:

func (b *BPFMap) CloseObject() {
  b.module.Close()
}

func (b *BPFMap) GetName() (string) {
  return b.name
}

func (b *BPFMap) GetFD() (int) {
  return int(b.fd)
}

[yanivagman]

I don't see a reason why not to have GetName() and GetFd(), but I don't think that a map should be able to close the module itself as this should be done with the module object.
You are welcome to open a PR for this.

[geyslan]

I don't think that a map should be able to close the module itself as this should be done with the module object.

I suppose that closing itself could provide de-duplication of the Module object for the consumer. The consumer would store only the *BPFMap after the Module.BPFLoadObject() call.

You are welcome to open a PR for this.

Sure thing, thanks. Please, let me know about the CloseObject() (or CloseModule()) suggestion too.

P.S.:
The suggestions could scale to BPFProg.

[rafaeldtinoco]

I don't think that a map should be able to close the module itself as this should be done with the module object.

I suppose that closing itself could provide de-duplication of the Module object for the consumer. The consumer would store only the *BPFMap after the Module.BPFLoadObject() call.

You mean for BPFModule that has single maps ? That won't always be the case AND might cause problems if there are multiple maps. For example: closure would have to check if other maps exist and if they do, if they are attached.

That is not what libbpf does to bpf_object (which is closest thing we have to BPFModule):

	struct bpf_program *programs;
	size_t nr_programs;
	struct bpf_map *maps;
	size_t nr_maps; <- would need to be checked, and if the maps are mmaped, etc...
	size_t maps_cap;

[geyslan]

You mean for BPFModule that has single maps ?

Yes, exactly that. A single map inside a single ebpf object.

For example: closure would have to check if other maps exist and if they do, if they are attached.

Current implementation of the Module.Close() is just calling bpf_object__close() without taking care of maps. So I got your concerns. Checking the other maps existence would be necessary for that.

[rafaeldtinoco]

Current implementation of the Module.Close() is just calling bpf_object__close() without taking care of maps. So I got your concerns. Checking the other maps existence would be necessary for that.

Yes, you are right. libbpfgo is basically a wrapper around libbpf. By calling Module.Close() we are calling bpf_object_close() and then bpf_link__destroy(). That will call call bpf_map__destroy() for all existing maps for that bpf_object.

It is weird for me that a map is capable of calling the object to cleanup itself and all other existing maps (thus my concern, which is also not addressed by libbpf, because calling link destroy should be made separately).

I'm in favor of explicitly making consumer to call Close from the link only by the Module (and object closure).

[geyslan]

It is weird for me that a map is capable of calling the object to cleanup itself and all other existing maps (thus my concern, which is also not addressed by libbpf, because calling link destroy should be made separately).
I'm in favor of explicitly making consumer to call Close from the link only by the Module (and object closure).

On second thought, I agree with you.

[rafaeldtinoco]

And could you also give an example on why getting BPF name and FD could be good ? That could help others.

[yanivagman]

I can see why one want to know about the name of the map later in the code.
For exame, say that you save an array of BPFMaps and you close/update/do something with it. Then it might be usefull to print/log the name of the map that you did something with.
Not sure about the fd usecase though.

[geyslan]

@rafaeldtinoco @itaysk @yanivagman

Sure. One might want to store FD to feed other maps entries, depending on the software whole logic. Or one might just want to recover this FD and feed other software that doesn't make use of libbpfgo.

For exame, say that you save an array of BPFMaps and you close/update/do something with it. Then it might be usefull to print/log the name of the map that you did something with.

Exactly, @yanivagman. This is also related to the CloseXXX() suggestion.

[rafaeldtinoco]

@rafaeldtinoco @itaysk @yanivagman

Sure. One might want to store FD to feed other maps entries, depending on the software whole logic. Or one might just want to recover this FD and feed other software that doesn't make use of libbpfgo.

To get the MAP file-descriptor from other software you would either have to pin it (check bpftool map pin) or message it through something like this. No ?

[geyslan]

To get the MAP file-descriptor from other software you would either have to pin it (check bpftool map pin) or message it through something like this. No ?

It's a way. The maps in question are being pinned, but I think it would be nice to get the FD programmatically from the lib used to pin it. What about to provide the pinpath instead?

[rafaeldtinoco]

Yes, to implement BPFMap->GetPinPath() wouldn't be bad.