Prefix / Naming USERCR API

Prefix / Naming USERCR API

[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 * 
	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

Re: Prefix / Naming USERCR API

[Michel Normand]

Le lundi 05 avril 2010 à 19:02 -0700, Sukadev Bhattiprolu a écrit :
> 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

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

> 
> Other prefixes or naming suggestions ?
> 
> Thanks,
> 
> Sukadev

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: Prefix / Naming USERCR API

[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.

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

Re: Prefix / Naming USERCR API

[Oren Laadan]

Sukadev Bhattiprolu wrote:
> | > 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 :-)
> 

I vote for 'cr_' to match the terminology we use in the docs
and emails ('c/r').

... and for brevity :p

Oren.

Re: Prefix / Naming USERCR API

[Serge E. Hallyn]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> 
> 
> Sukadev Bhattiprolu wrote:
> > | > 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 :-)
> > 
> 
> I vote for 'cr_' to match the terminology we use in the docs
> and emails ('c/r').
> 
> ... and for brevity :p
> 
> Oren.

'me too'