public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Mike Travis <travis@sgi.com>
Cc: bert.wesarg@googlemail.com, mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] x86: modify show_shared_cpu_map in intel_cacheinfo
Date: Mon, 31 Mar 2008 12:56:11 -0500	[thread overview]
Message-ID: <20080331125611.9ad42e8f.pj@sgi.com> (raw)
In-Reply-To: <47F112BD.4050801@sgi.com>

>>  I did an informal survey and you are right, the majority of references do use
>>  cpumask_scnprintf instead of cpulist_scnprintf.  Maybe the later function was
>>  added later?

My recollection is that I added cpulist_scnprintf later, yes.
Looking at my email archives, I see the mask versions mentioned
starting Feb 2004, and the list versions starting Aug 2004.

My rule of thumb has been to use the mask style (00000000,0000ffff)
for lower level interfaces, and the list style (0-15) for higher level
interfaces.

For long lists, the list style is easier for humans to read, but for
one word masks, the mask style can be easier to read for -some-
purposes and are more commonly used.

If you throw enough user level software at them, the lists are no more
or less difficult to form or parse.  Hand coded C parsers are probably
easier to write for the mask style, and might be closer to what low
level (closer to the hardware) programmers expect.

Certainly, a particular interface should not change once it goes public.

Once picked for a new interface, I don't recall ever seeing any significant
controversy over which one was picked.  So another of my rules of thumb
might apply here -- coders choice.  He who writes the code gets to make
the open choices.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

      parent reply	other threads:[~2008-03-31 17:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 23:16 [PATCH 0/2] x86: add functions in preparation of cpumask changes Mike Travis
2008-03-27 23:16 ` [PATCH 1/2] x86: Convert cpumask_of_cpu macro to allocated array Mike Travis
2008-03-27 23:16 ` [PATCH 2/2] x86: modify show_shared_cpu_map in intel_cacheinfo Mike Travis
2008-03-28  9:01   ` Bert Wesarg
2008-03-28 14:40     ` Mike Travis
2008-03-28 14:54       ` Bert Wesarg
2008-03-28 18:19         ` Mike Travis
2008-03-29  8:59           ` Bert Wesarg
2008-03-31 16:35             ` Mike Travis
2008-03-31 17:24               ` Bert Wesarg
2008-03-31 18:18                 ` Paul Jackson
2008-03-31 17:56               ` Paul Jackson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080331125611.9ad42e8f.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=bert.wesarg@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=travis@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox