PSARC 2009/210 uname -c

[Garrett D'Amore]

James Carlson wrote:
> Sebastien Roy writes:
>   
>> This case proposes to add such a feature to the kernel by introducing a
>> new -c option ('c' for "credits) to the uname command.  The output is
>> not an Interface, but consists of a newline separated list of names of
>> people who contributed to the kernel.
>>     
>
> What counts as a "contribution?"  Is it just working code, or do bugs
> count too?  What about slideware and cheerleading?
>
> Or should it be more like a non-profit foundation, with a certain
> monetary contribution level getting you into the "President's Circle?"
>
> We might have to derail to discuss this one.  I suggest that we hold
> the discussion inside a bike shed.
>
>   
I think I agree ... the determination of how the list itself is made up 
and maintained (and also the initial population of such a list) is 
probably within architectural scope for this case.

I'm also concerned about adding a flag to uname.  uname is a standards 
conforming application that is supposed to deal with kernel values.  I'm 
not at all convinced that this is the right place for a "credits" list.

In fact, if the list of credits is simply a text file, I'd think the 
better architecture would be to simply identify the location of the 
file, and let applications or users access the file directly.  Involving 
uname in something that is not intrinsically related to kernel naming 
here (or the utsname structure) seems like an architectural mistake -- 
and one that might someday be regretted.

Is the uname -c supposed to only be for "kernel" credits?  What about 
contributions to associated software in userland, e.g. linker changes, 
tool fixes, or the devfsadm?  And at that point, then what about the 
bourne and korn shells?  And libc?  And...

I'm formally derailing this case -- it fails to meet the obvious and 
non-controversial requirements of a fast track.

    -- Garrett