Re: [PATCH 6/18] 2.6.17.9 perfmon2 patch for review: sampling format support

[Stephane Eranian <eranian@hpl.hp.com>]

Andrew,

On Fri, Sep 01, 2006 at 11:09:12AM -0700, Andrew Morton wrote:
> On Fri, 1 Sep 2006 09:09:25 -0700
> Stephane Eranian <eranian@hpl.hp.com> wrote:
> 
> > > Why identify a format with a UUID rather than via a nice human-readable name?
> > > 
> > 
> > Although a UUID is slightly more difficult to manipulate than a clear text string, it
> > offers several advantages:
> > 	- is guaranteed unique
> > 	- generation is fully distributed
> > 	- easy generation with uuidgen
> > 	- fixed size
> > 	- very easy to pass to the kernel, there is not char * in a struct pass to kernel
> > 	- not to worry about '\0'
> 
> The kernel has got along OK using ascii strings for this sort of thing in
> thousands of places for many years.  Is there something special or unique
> about perfmon's requirements which make UUIDs a clearly superior
> implementation?

I don't think there is something special about perfmon. In my mind, uuid looked
more convenient than strings. But if this is too 'unique' for the kernel, I can look
at switching over to an ascii string. Today the uuid is encapsulated into a struct
that is passed to pfm_create_context(). I would like to avoid doing:

	struct pfm_context {
		char *uuid;
		int fd;
		....
	};

We could do:
	struct pfm_context {
		char uuid[UUID_LEN];
		int fd;
		...
	};
Or add the string to the syscall itself:
	pfm_create_context(struct pfm_context *ctx, char *uuid, void *smpl_arg, size_t arg_sz)

When no format is needed uuid=NULL.

Is there a kernel preference on that?

> 
> > We use UUID to idenitfy a format + a version number. The version number can be useful
> > to identify backward compatible versions of a format.
> 
> Interfaces use major and minor version numbering for that.

But here this is not about the perfmon interface, the version applies to the interface of the
sampling format kernel module itself, e.g., we could have a new version with some extensions.
With the string we could use the name to encode the version number. But we could also use
a generic name and have the more detailed version in the remapped smaping buffer header
managed by the format.

-- 
-Stephane

-- 
VGER BF report: H 0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/