-
Notifications
You must be signed in to change notification settings - Fork 123
[new-backend] Extend kdbOpen contracts for adding mountpoints #4442
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This should be changed to
👍
Thank you, for so carefully investigating what is to be done! 💟 I am missing the information what should be done if such a mountpoint already exists. Are you sure that simply inserting the keys, possibly kicking out other keys that were there, is safe with our definition of backends in the new-backend branch? |
It would probably be safer, to do appropriate
|
I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. |
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. |
The
contract
KeySet passed tokdbOpen
currently supports only two types of contract: adding global plugins and adding keys to the global keyset (see docs)This is enough for the currently supported use cases of: configuring
gopts
and setting up I/O bindings and notifications. However, another use case is the newkdb
(and possibly other applications). There we want to embed its specification into the application itself to ensure the tool always works and isn't dependent on files/mountpoints being present on the system.To solve this a new type of contract
mountpoint
shall be added, i.e. keys belowsystem:/elektra/contract/mountpoint
can be used to define an in-process mountpoint. This mountpoint acts like any other mountpoint present on disk. It is added after the boostrapkdbGet
, i.e. mountpoints defined in the contract override the ones present on disk.Because this issue is concerned with mountpoints, it should only be implemented on the
new-backend
branch.Proposal for structure
This is a proposal for the structure of the mountpoints contract. IMO the simplest solution would be to use
system:/elektra/contract/mountpoint/<mountpointkey>/...
where<mountpointkey>
is the escaped form of the key at which the backend will be mounted and...
is the definition of the mountpoint. In other words, the contract would be exactly the same as a real mountpoint atsystem:/elektra/mountpoints
, but moved tosystem:/elektra/contract/mountpoint
.For example to add a modified
specload
as a new backend atspec:/sw/myapp
:Required changes to
libelektra-kdb
To make this new contract work, a few changes need to be made to
libelektra-kdb
.The starting point is
ensureContract
, the helper function responsible for processing contracts.libelektra/src/libs/elektra/kdb.c
Lines 343 to 355 in 5f0895b
Since the new contract shouldn't have any interaction with the previous ones, we can just add a new
ensureContractMountpoint
call in line 351.Since
ensureContract
is already called at the right place inkdbOpen
(after the bootstrapkdbGet
, but before mountpoints are processed into the internal structure), this newensureContractMountpoint
is very simple. It basically boils down to: 1) move the keys fromsystem:/elektra/contract/mountpoint
tosystem:/elektra/mountpoints
& 2) add them to the existing mountpoints keyset to override.For the second point we need to pass
elektraKs
fromkdbOpen
toensureContract
and thenensureContractMountpoint
. Then it should simply be a case of:The text was updated successfully, but these errors were encountered: