Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-13496

Create a plan of action for implementing module privacy in WiredTiger

    • Type: Icon: Task Task
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Not Applicable
    • None
    • Storage Engines
    • 5
    • StorEng - 2024-09-17

      The modularity team want to define two headers for a module. One public .h for all functions a structs that are accessible outside the module, and one _internal.h header for functions and structs that are internal only. We have a PoC here that can be used for reference.

      This ticket is to:

      • Create a proposal to let the team know what we're planning, demonstrate the benefits, address potential tradeoffs
      • Expand on the PoC and make sure we've addressed potential pain points and unknowns. Some of these include:
        • How do we minimise backporting issues? Can we make most of the changes in s_all, so on a backport the conflicts are resolved automatically?
        • How do we decide which functions go into the `.h` versus the `private.h`? We want this to still be automatic and handled by `s_prototypes`.
        • Where do the existing `_inline.h` files fit into this? I assume they belong in the .h file, but does this make the size of the file unweildy?
        • Do the files stay in src/include, or do we co-locate them inside the src/module_name/ folders?

            Assignee:
            keith.smith@mongodb.com Keith Smith
            Reporter:
            andrew.morton@mongodb.com Andrew Morton
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: