Prefix / Naming USERCR API
Prefix / Function names for USERCR API
I guess the long term plan is to export the USERCR funtionality to management or other applications as a library. We are trying to choose a good prefix for the USERCR API.
The current prefix for the API is, which was cooked up on the fly, is "app_". This prefix is currently used in structures/functions like:
struct app_checkpoint_args *
struct app_restart_args *
app_checkpoint()
app_restart()
In the future we may have additional apis like:
xxx_freeze() xxx_migrate() xxx_cr_advise() ?
Kernel api already uses some prefixes like (checkpoint, ckpt_ etc:
<linux/checkpoint.h> <linux/checkpoint_hdr.h> struct ckpt_hdr_header struct ckpt_hdr checkpoint(2) restart(2) #define RESTART_TASKSELF 0x1 #define CHECKPOINT_SUBTREE 0x1
Having a prefix would make it easy to identify the API and avoid collision with other libraries that the application might link against. Eg: the "pam_" prefixes PAM api.
Having a prefix like "cr_" or "acr_" could cause some redundancy in some names, like cr_checkpoint(), but is probably ok, like pam_authenticate() ?
So, what would be a good prefix ?
cr_
cr_checkpoint.h, libcr.a
cr_checkpoint() cr_restart() cr_freeze() cr_migrate() struct cr_checkpoint_args, struct cr_restart_args
acr_
Only advantage over 'cr_' is lesser likelihood of collision
acr_checkpoint.h, libacr.a
acr_checkpoint() acr_restart() acr_freeze() acr_migrate() struct acr_checkpoint_args, struct acr_restart_args
lxcr_
lxcr_checkpoint.h, liblxcr.a
lxcr_checkpoint() lxcr_restart() lxcr_freeze() lxcr_migrate() struct lxcr_checkpoint_args, struct lxcr_restart_args
Other prefixes or naming suggestions ?
Thanks,
Sukadev
A message that is not in the archive (sent off-list or not yet received): 20100406020221.GA647-r/[email protected]
Quoted 50 lines · Sukadev Bhattiprolu
Prefix / Function names for USERCR API
I guess the long term plan is to export the USERCR funtionality to management or other applications as a library. We are trying to choose a good prefix for the USERCR API.
The current prefix for the API is, which was cooked up on the fly, is "
app_". This prefix is currently used in structures/functions like:struct
app_checkpoint_args*
structapp_restart_args*
app_checkpoint()
app_restart()In the future we may have additional apis like:
xxx_freeze() xxx_migrate() xxx_cr_advise() ?Kernel api already uses some prefixes like (checkpoint,
ckpt_etc:<linux/checkpoint.h> <linux/checkpoint_hdr.h> struct ckpt_hdr_header struct ckpt_hdr checkpoint(2) restart(2) #define RESTART_TASKSELF 0x1 #define CHECKPOINT_SUBTREE 0x1Having a prefix would make it easy to identify the API and avoid collision with other libraries that the application might link against. Eg: the "
pam_" prefixes PAM api.Having a prefix like "
cr_" or "acr_" could cause some redundancy in some names, likecr_checkpoint(), but is probably ok, likepam_authenticate()?So, what would be a good prefix ?
cr_
cr_checkpoint.h, libcr.a
cr_checkpoint()cr_restart()cr_freeze()cr_migrate()structcr_checkpoint_args, structcr_restart_args
acr_
Only advantage over 'cr_' is lesser likelihood of collision
Quoted 8 lines
acr_checkpoint.h, libacr.a
acr_checkpoint()acr_restart()acr_freeze()acr_migrate()structacr_checkpoint_args, structacr_restart_args
lxcr_
lxcr_checkpoint.h, liblxcr.a
lxcr_checkpoint()lxcr_restart()lxcr_freeze()lxcr_migrate()structlxcr_checkpoint_args, structlxcr_restart_args
I do not think lxcr_ prefix is a good choice as lxc is about container and could use different libraries for the checkpoint/restart function.
---
Michel
Quoted 6 lines
Other prefixes or naming suggestions ?
Thanks,
Sukadev
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
| > So, what would be a good prefix ? | > | > cr_ | > cr_checkpoint.h, libcr.a | > cr_checkpoint() cr_restart() cr_freeze() cr_migrate() | > struct cr_checkpoint_args, struct cr_restart_args | > acr_ | > Only advantage over 'cr_' is lesser likelihood of collision | > | > acr_checkpoint.h, libacr.a | > acr_checkpoint() acr_restart() acr_freeze() acr_migrate() | > struct acr_checkpoint_args, struct acr_restart_args | > | > lxcr_ | > lxcr_checkpoint.h, liblxcr.a | > lxcr_checkpoint() lxcr_restart() lxcr_freeze() lxcr_migrate() | > struct lxcr_checkpoint_args, struct lxcr_restart_args | | I do not think lxcr_ prefix is a good choice as lxc is about container | and could use different libraries for the checkpoint/restart function.
I was thinking of lx as short for linux, but ok. we can drop lxcr_.
Any NACKS to 'acr_' ? If not, I will go with it - for now :-)
Sukadev
A message that is not in the archive (sent off-list or not yet received): 20100410034840.GA11028-r/[email protected]
Quoted 21 lines · Sukadev Bhattiprolu
| > So, what would be a good prefix ? | > | > cr_ | > cr_checkpoint.h, libcr.a | > cr_checkpoint() cr_restart() cr_freeze() cr_migrate() | > struct cr_checkpoint_args, struct cr_restart_args | > acr_ | > Only advantage over 'cr_' is lesser likelihood of collision | > | > acr_checkpoint.h, libacr.a | > acr_checkpoint() acr_restart() acr_freeze() acr_migrate() | > struct acr_checkpoint_args, struct acr_restart_args | > | > lxcr_ | > lxcr_checkpoint.h, liblxcr.a | > lxcr_checkpoint() lxcr_restart() lxcr_freeze() lxcr_migrate() | > struct lxcr_checkpoint_args, struct lxcr_restart_args | | I do not think lxcr_ prefix is a good choice as lxc is about container | and could use different libraries for the checkpoint/restart function.
Quoted 4 lines
I was thinking of lx as short for linux, but ok. we can drop
lxcr_.Any NACKS to '
acr_' ? If not, I will go with it - for now :-)
I vote for 'cr_' to match the terminology we use in the docs and emails ('c/r').
... and for brevity :p
Oren.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 29 lines · Oren Laadan
Quoted 21 lines · Sukadev Bhattiprolu
| > So, what would be a good prefix ? | > | > cr_ | > cr_checkpoint.h, libcr.a | > cr_checkpoint() cr_restart() cr_freeze() cr_migrate() | > struct cr_checkpoint_args, struct cr_restart_args | > acr_ | > Only advantage over 'cr_' is lesser likelihood of collision | > | > acr_checkpoint.h, libacr.a | > acr_checkpoint() acr_restart() acr_freeze() acr_migrate() | > struct acr_checkpoint_args, struct acr_restart_args | > | > lxcr_ | > lxcr_checkpoint.h, liblxcr.a | > lxcr_checkpoint() lxcr_restart() lxcr_freeze() lxcr_migrate() | > struct lxcr_checkpoint_args, struct lxcr_restart_args | | I do not think lxcr_ prefix is a good choice as lxc is about container | and could use different libraries for the checkpoint/restart function.Quoted 4 lines
I was thinking of lx as short for linux, but ok. we can drop
lxcr_.Any NACKS to '
acr_' ? If not, I will go with it - for now :-)
Quoted 6 lines
I vote for '
cr_' to match the terminology we use in the docs and emails ('c/r').... and for brevity :p
Oren.
'me too'