On Fri, 5 Mar 2010 08:43:30 -0600 Michael Witten wrote: > On Fri, Mar 5, 2010 at 07:58, Michael J Daniel > <michael.j.daniel@xxxxxxxxxxx> wrote: > > Michael Witten wrote: > >> > >> On Thu, Mar 4, 2010 at 11:19, Randy Dunlap <rdunlap@xxxxxxxxxxxx> wrote: > >> > >>> > >>> On Thu, 4 Mar 2010 02:19:37 -0600 Michael Witten wrote: > >>> > >>> > >>>> > >>>> On Thu, Mar 4, 2010 at 01:33, Michael Witten <mfwitten@xxxxxxxxx> wrote: > >>>> > >>>>> > >>>>> + <function>get_cpu()</function> disables preemption on the local > >>>>> CPU > >>>>> + (so you won't suddenly get moved to another CPU) and then returns > >>>>> + the local CPU id as a number ranging from 0 up to (but not > >>>>> including) > >>>>> + <symbol>NR_CPUS</symbol>; subsequently returned CPU ids are not > >>>>> + necessarily contiguous. > >>>>> > >>>> > >>>> It occurred to me that the original 'continuous' means 'constant' > >>>> rather than 'contiguous'. However, given the introduction of the term > >>>> 'local CPU', I don't think that this sentence is even necessary > >>>> anymore. How about just removing it? > >>>> > >>> > >>> Remove that entire paragraph (above) or just the "subsequently returned > >>> CPU ids are not necessarily contiguous." part of it? Removing the latter > >>> makes sense to me. > >>> > >> > >> hah! > >> > >> I knew this would be a point of confusion as soon as I hit 'send'. :-D > >> > >> I did indeed mean just the "subquently returned CPU ids are not > >> necessarily contiguous". > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-doc" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > >> > > > > Please consider this possibility. > > > > Keep the sentence, but replace the word "contiguous" with "numerically > > sequential". > > But what's the point of saying this? Why would anyone think that it > would be numerically sequential anyway? Indeed, I'm certain that the > original meaning (with 'conti**n**uous') is not even 'numerically > sequential' but rather is 'numerically the same', which is also > unnecessary to say, especially now that the term 'local CPU' has been > introduced (and previously defined in the section on > local_irq_{disable,enable,save,destroy}): > > > <function>get_cpu()</function> disables preemption on the > > local CPU (so you won't suddenly get moved to another CPU) > > and then returns the local CPU id... > > There's absolutely no reason to suspect any pattern in the returned > CPU id numbers. > -- Some people don't understand that CPU id numbers can be sparse. --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
