I am currently porting an application from Tru64 with behavior that depends on
the number of CPUs in the system. (For example, How many buffers should I
allocate?)
Sure. I can write some code to parse /proc/stat or /proc/cpuinfo. Tru64 has
the sysconf(_SC_NPROCESSORS_CONF) call, and it would be nice if Linux did the
same. (especially since /proc/ has been known to change...)
Why not have both? Keep /proc/cpuinfo for the perl script, but use
sysconf(_SC_NPROCESSORS_CONF) for the libraries. Plus, what if people don't
compile with /proc?
--Phil
Compaq: Business Critical Servers Division/Benchmark Performance Engineering
---------------- Alpha, The Fastest Processor on Earth --------------------
Phillip.Ezolt@compaq.com |C|O|M|P|A|Q| ezolt@perf.zko.dec.com
On 1 Sep 1999, Jes Sorensen wrote:
> >>>>> "David" == david parsons <o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s> writes:
>
> David> In article <linux.kernel.d3r9kjzjjl.fsf@lxp03.cern.ch>, Jes
> David> Sorensen <Jes.Sorensen@cern.ch> wrote:
> >> Since none of the info in /proc/cpuinfo should be of interest to
> >> any tools
>
> David> Why not? I'd say that the contents of /proc/cpuinfo would
> David> be very interesting to tools, because it's what the operating
> David> system thinks it's running on.
>
> Why, it's a name of the CPU, MMU and FPU a bunch of version levels and
> a list of bugs. In principle these are of no interest to user space
> applications except for "my **** is bigger than your ****"
> applications.
>
> Now while we are at it, please fix your mail client to stop eating the
> References: lines - it's very rude.
>
> Jes
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/