Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to add custom drivers non-intrusively? #650

Closed
FlyingSamson opened this issue May 22, 2024 · 3 comments · Fixed by #665
Closed

How to add custom drivers non-intrusively? #650

FlyingSamson opened this issue May 22, 2024 · 3 comments · Fixed by #665

Comments

@FlyingSamson
Copy link
Contributor

For the project I'm currently working on, I need to write a custom driver.

Inheriting from hdf5::file::Driver works per se, but to overload the pure virtual function id() I need to return a hdf5::file::DriverID, which currently is limited to Posix, Direct, Memory, and MPI.

I could not find any reference to hdf5::file::DriverID other than the once in the existing drivers id() functions, so I'm not sure what the intended use id() is.

Would it be feasible to add another choice (e.g., Custom) to the hdf5::file::DriverID enum?

Alternatively, if the ID should remain unique even when multiple custom drivers are to be used, one might also consider some form of registration, that hands out unique integer ids for each driver. In any case I believe driver should be implemented as an open set, since hdf5 itself implements it that way. The implementation using the enum class makes this difficult, as it inherently makes it a closed set.

@jkotan
Copy link
Collaborator

jkotan commented May 23, 2024

Yes, it would be nice to support H5Pset_driver and H5Pget_driver . I would think about a solution which is backward compatible

@jkotan
Copy link
Collaborator

jkotan commented Jan 20, 2025

Hello @FlyingSamson,

I've just created PR which adds DriverID::Custom=0 (#665)
Does it solve your issue?
Do you have any simple example for your use-case we could add to our tests?

@FlyingSamson
Copy link
Contributor Author

FlyingSamson commented Jan 21, 2025

Yes, that solves my issue.

For an (currently) internal project I'm developing a Virtual File Driver for hdf5, which I would like to use with h5cpp.

I don't think that this offers much testing potential, but maybe one could add an example.

What I currently do to add the VFD to h5cpp is (merged into one header instead of definitions in a separate CU for simplicity):

class MyDriver : public hdf5::file::Driver {
 public:
  MyDriver(<some type> parameters_for_file_access) : _parameters_for_file_access{parameters_for_file_access} {}
  MyDriver(const MyDriver&) = default;

  virtual void operator()(const hdf5::property::FileAccessList& fapl) const override {
    if (H5Pset_fapl_my_vfd(static_cast<hid_t>(fapl), _parameters_for_file_access) < 0) {
      hdf5::error::Singleton::instance().throw_with_stack("Failure setting my_vfd driver!");
    }
  }

  [[nodiscard]] virtual hdf5::file::DriverID id() const noexcept override  {
    return hdf5::file::DriverID::Custom;
  }

 private:
  <some type> _parameters_for_file_access;
};

H5Pset_fapl_my_vfd basically follows the tutorials by the HDF5 group and the hdf5 internal implementations of the existing VFDs.

And then I call on a hdf5::property::FileAccessList object

_fapl.driver(MyDriver());

and use that _fapl in a hdf5::file::open call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants