split logging from root object

[igaw]

Let's refactor the logging out from the root object and accept the full defeat against no global variables fight.

[tbzatek]

Thanks, I like it. It always puzzled me to have a global root object with dubious memory ownership, though the code appeared safe.

Don't worry too much about global variables, I have a similar mental block for goto... 😳

[igaw]

We do create multiple root objects in libblockdev since it's often used in threads and need separate memory objects. While not currently used, it might be useful to grab the log for certain operations and present it as a buffer back to the user (e.g. via D-Bus).

If I got you right, the idea is to introduce a global log buffer with multiple readers. This indeed would also solve the issue.

Besides, as backwards compatibility is concerned, I would keep it there. Reconsider later for libnvme 2.0?

Yeah, let's start with the default global logging fix here and see if anyone is really unhappy with it. We can discuss/play with the two idea (either introducing a library handle or your idea with a log buffer) for libnvme 2.0.

[tbzatek]

We do create multiple root objects in libblockdev since it's often used in threads and need separate memory objects. While not currently used, it might be useful to grab the log for certain operations and present it as a buffer back to the user (e.g. via D-Bus).

If I got you right, the idea is to introduce a global log buffer with multiple readers. This indeed would also solve the issue.

It was more an idea than any proposal and we don't plan to make use of anything like this in the near term.

To be precise, we need multiple root objects to be supported, due to threading. However logging is a different affair, at the moment we basically silence/disable libnvme logging in libblockdev and rely solely on error codes.

My only concern is that whenever a root object takes fp or log_level args via e.g. nvme_mi_create_root() or nvme_create_root() and global logging has been initialized already, it should not get overridden. I.e. either use the global logging only or keep it separate for each root object. Theoretically, in a process that pulls multiple libraries in that use libnvme for something, we don't want our global logging settings to be reset by a foreign library. No big deal though, just customers are sometimes picky with any single message on stderr. 😑

[martin-belanger]

To be precise, we need multiple root objects to be supported, due to threading.

Just thought I'd chime in to say that threading is precisely why nvme-stas also requires multiple root objects.