> The main ideal that we're shooting for is to have one ASCII value per> file. The ASCII part is mandatory, but there will definitely be exceptions> where we will have an array of or multiple values per file. We want to> minimize those instances, though. Both for the sake of easy parsing, but> also for easy formatting within the drivers.

On IA-64, I've got the arch/ia64/kernel/efivars.c module that exports/proc/efi/vars/{NVRAM-variables}. It violates several rules of /procwhich I'd like to address in 2.5.x via driverfs.1) It's in /proc but isn't process-related.2) It exports its data as binary, not ascii.Proc was chosen because it was simple, didn't require a major/minornumber, showed easily the set of NVRAM variables that were availablewithout needing a separate program to go and query a /dev/efivars fileto list them; cat and tar are sufficient for making copies ofvariables and restoring them back again. These exact features makedriverfs make sense too.

1) is easy to fix. 2) a little less so. The data structure beingexported is a little over 2KB in length; The data is binary (itself avariable length set of structures each with no ascii representation).An ascii representation in "%02x" format will be longer than a 4K pagegiven to fill out and return. Undoubtedly there's a better way tohandle this, and I'm open to suggestions. The thing being exported isefi_variable_t.

For such cases where the data being exported is really binary,having a common set of parse/unparse routines would be nice.