RFE: Resolve SCMP_ARCH_* constants to architecture name

[r10r]

What about adding seccomp_arch_name (inverse of seccomp_arch_resolve_name) to the API ?

It would be nice (e.g to debug rule generation) if the SCMP_ARCH_* constants can be resolved to the architecture names.
I noticed that this is already implemented and would require only a small amount of refactoring:

libseccomp/src/gen_pfc.c

Lines 51 to 95 in 3734fdc

	static const char *_pfc_arch(const struct arch_def *arch)
	{
	switch (arch->token) {
	case SCMP_ARCH_X86:
	return "x86";
	case SCMP_ARCH_X86_64:
	return "x86_64";
	case SCMP_ARCH_X32:
	return "x32";
	case SCMP_ARCH_ARM:
	return "arm";
	case SCMP_ARCH_AARCH64:
	return "aarch64";
	case SCMP_ARCH_MIPS:
	return "mips";
	case SCMP_ARCH_MIPSEL:
	return "mipsel";
	case SCMP_ARCH_MIPS64:
	return "mips64";
	case SCMP_ARCH_MIPSEL64:
	return "mipsel64";
	case SCMP_ARCH_MIPS64N32:
	return "mips64n32";
	case SCMP_ARCH_MIPSEL64N32:
	return "mipsel64n32";
	case SCMP_ARCH_PARISC:
	return "parisc";
	case SCMP_ARCH_PARISC64:
	return "parisc64";
	case SCMP_ARCH_PPC64:
	return "ppc64";
	case SCMP_ARCH_PPC64LE:
	return "ppc64le";
	case SCMP_ARCH_PPC:
	return "ppc";
	case SCMP_ARCH_S390X:
	return "s390x";
	case SCMP_ARCH_S390:
	return "s390";
	case SCMP_ARCH_RISCV64:
	return "riscv64";
	default:
	return "UNKNOWN";
	}
	}

So why not expose this in the API ? e.g.

const char * seccomp_arch_name(uint32_t arch);

[pcmoore]

Hi @r10r.

Sure, that sounds reasonable. The right thing to do would probably be to add a const char *name field to struct arch_def and then just leverage the existing arch_def_lookup() to create a new API function seccomp_arch_resolve_token() or similar. Does that sound okay to you?

@drakenclimber any thoughts?

[r10r]

That sounds good.
Does it help when I make the changes (on top of master) and send you a pull request?

[drakenclimber]

@drakenclimber any thoughts?

Yes, this sounds like a good API to add, and I think your proposed implementation should work well.

Does it help when I make the changes (on top of master) and send you a pull request?

Yes, that would be awesome! Once it's in master, we can handle getting it into the v2.5 release branch.

Thanks so much for the help :)

[pcmoore]

Once it's in master, we can handle getting it into the v2.5 release branch.

Since this is adding a new function to the API, I would suggest that this should be a candidate for v2.6.0 and not v2.5.x.