From hch@caldera.de  Thu Jan  3 22:26:51 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Thu, 3 Jan 2002 23:26:51 +0100
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <20020103232651.A878@caldera.de>

LSB> /proc/cpuinfo
LSB>
LSB> This file is a text file that contains information about one or more
LSB> processors. A blank line seperates the information for each processor.
LSB> Each processor is described by an unordered set of lines. Each line
LSB> contains a key followed by a seperator followed by a value. The key may
LSB> be any combination of alphanumeric, underscore, and space characters.
LSB> The seperator is a tab followed by a colon followed by a space ('\t: ').
LSB> The format of the value is defined below, and in architectures-specific
LSB> LSB specifications.

This differs from current practice on some Linux architectures, e.g.
PowerPc, ARM or Sparc/SMP.

Also /proc/cpuinfo is one of the abuses of the Linux /proc filesystem
that might be removed in the mid-term timeframe (e.g. Linux 2.6).

Please do not document anything in /proc besides the per-process
information.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


From esr@thyrsus.com  Thu Jan  3 22:34:01 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 17:34:01 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103232651.A878@caldera.de>; from hch@caldera.de on Thu, Jan 03, 2002 at 11:26:51PM +0100
References: <20020103232651.A878@caldera.de>
Message-ID: <20020103173401.A25141@thyrsus.com>

Christoph Hellwig <hch@caldera.de>:
> Please do not document anything in /proc besides the per-process
> information.

I disagree with this request.  Files like /proc/cpuinfo are very helpful
for autoconfigurastion and cluster management.  LSB's constituency would
be better served by more such information, not less.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The United States is in no way founded upon the Christian religion
	-- George Washington & John Adams, in a diplomatic message to Malta.


From anderson@metrolink.com  Thu Jan  3 22:53:38 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Thu, 3 Jan 2002 17:53:38 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103232651.A878@caldera.de>
Message-ID: <20020103175058.S616-100000@trantor.sc.metrolink.com>

On Thu, 3 Jan 2002, Christoph Hellwig wrote:

> This differs from current practice on some Linux architectures, e.g.
> PowerPc, ARM or Sparc/SMP.

Can you please provide some examples? All of the examples I was able to aquire
fit the description (actually, it was written to fit the exmaples 8-)).

> Also /proc/cpuinfo is one of the abuses of the Linux /proc filesystem
> that might be removed in the mid-term timeframe (e.g. Linux 2.6).
>
> Please do not document anything in /proc besides the per-process
> information.

I'd like avoid /proc completely, but we needed a way to determine what
processor features are available (especially on IA32). Without this, we have
to choose the i486 feature set as the least common denominator (ie no MMX, etc).


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From hch@caldera.de  Thu Jan  3 22:54:41 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Thu, 3 Jan 2002 23:54:41 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103173401.A25141@thyrsus.com>; from esr@thyrsus.com on Thu, Jan 03, 2002 at 05:34:01PM -0500
References: <20020103232651.A878@caldera.de> <20020103173401.A25141@thyrsus.com>
Message-ID: <20020103235441.A3021@caldera.de>

On Thu, Jan 03, 2002 at 05:34:01PM -0500, Eric S. Raymond wrote:
> Christoph Hellwig <hch@caldera.de>:
> > Please do not document anything in /proc besides the per-process
> > information.
> 
> I disagree with this request.  Files like /proc/cpuinfo are very helpful
> for autoconfigurastion and cluster management.  LSB's constituency would
> be better served by more such information, not less.

You missed the point.  There very major reasons why it shouldn't be
standardized (this is Al Viro's wording with whom I just discussed the
issue):

 a) proposed standard doesn't match existing practice
 b) any program relying on described contents is broken at least on
    some platforms for all existing versions of Linux
 c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

Besides that your above two applications won't be LSB-compliant due to a
variety of other reason in the near future.

	Christoph

--
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world.


From esr@thyrsus.com  Thu Jan  3 22:51:18 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 17:51:18 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103235441.A3021@caldera.de>; from hch@caldera.de on Thu, Jan 03, 2002 at 11:54:41PM +0100
References: <20020103232651.A878@caldera.de> <20020103173401.A25141@thyrsus.com> <20020103235441.A3021@caldera.de>
Message-ID: <20020103175118.A25423@thyrsus.com>

Christoph Hellwig <hch@caldera.de>:
>  a) proposed standard doesn't match existing practice

Then this is one of the areas where practice should be changed to meet
the standard.

>  b) any program relying on described contents is broken at least on
>     some platforms for all existing versions of Linux

Then this is one of the areas where practice should be changed to meet
the standard.

>  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

That should not happen, and I will campaign to prevent it from happening.
It's nice to talk about /proc being "per-process information only" but
that does not even begin to describe the clearly most useful features of
/proc, let alone the marginal ones.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No kingdom can be secured otherwise than by arming the people.  The possession
of arms is the distinction between a freeman and a slave. 
        -- "Political Disquisitions", a British republican tract of 1774-1775


From tbm@cyrius.com  Thu Jan  3 23:16:06 2002
From: tbm@cyrius.com (Martin Michlmayr)
Date: Fri, 4 Jan 2002 00:16:06 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104001606.A19522@fisch.cyrius.com>

* Stuart Anderson <anderson@metrolink.com> [20020103 17:53]:
> > > A blank line seperates the information for each processor
> > This differs from current practice on some Linux architectures

> Can you please provide some examples?

cpu             : TI UltraSparc II  (BlackBird)
fpu             : UltraSparc II integrated FPU
promlib         : Version 3 Revision 17
prom            : 3.17.0
type            : sun4u
ncpus probed    : 2
ncpus active    : 2
Cpu0Bogo        : 897.84
Cpu0ClkTck      : 000000001ad2bd21
Cpu2Bogo        : 897.84
Cpu2ClkTck      : 000000001ad2bd21
MMU Type        : Spitfire
State:
CPU0:           online
CPU2:           online

-- 
Martin Michlmayr
tbm@cyrius.com


From taggart@carmen.fc.hp.com  Thu Jan  3 23:21:56 2002
From: taggart@carmen.fc.hp.com (Matt Taggart)
Date: Thu, 03 Jan 2002 16:21:56 -0700
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: Message from Martin Michlmayr <tbm@cyrius.com>
 of "Fri, 04 Jan 2002 00:16:06 +0100." <20020104001606.A19522@fisch.cyrius.com>
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>  <20020104001606.A19522@fisch.cyrius.com>
Message-ID: <20020103232156.EB0DF37CB8@carmen.fc.hp.com>


Martin Michlmayr writes...

> * Stuart Anderson <anderson@metrolink.com> [20020103 17:53]:
> > > > A blank line seperates the information for each processor
> > > This differs from current practice on some Linux architectures
> 
> > Can you please provide some examples?
> 
> cpu             : TI UltraSparc II  (BlackBird)
> fpu             : UltraSparc II integrated FPU
> promlib         : Version 3 Revision 17
> prom            : 3.17.0
> type            : sun4u
> ncpus probed    : 2
> ncpus active    : 2
> Cpu0Bogo        : 897.84
> Cpu0ClkTck      : 000000001ad2bd21
> Cpu2Bogo        : 897.84
> Cpu2ClkTck      : 000000001ad2bd21
> MMU Type        : Spitfire
> State:
> CPU0:           online
> CPU2:           online

processor	: 0
cpu family	: PA-RISC 2.0
cpu		: PA8500 (PCX-W)
cpu MHz		: 400.000000
model		: 9000/785/C3000
model name	: AllegroHigh W
hversion	: 0x00005bb0
sversion	: 0x00000481
I-cache		: 512 KB
D-cache		: 1024 KB (WB)
ITLB entries	: 160
DTLB entries	: 160 - shared with ITLB
BTLB		: not supported
bogomips	: 799.53
software id	: 2011698862

processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium
model      : 0
revision   : 6
archrev    : 0
features   : standard
cpu number : 0
cpu regs   : 4
cpu MHz    : 799.926960
itc MHz    : 799.926960
BogoMIPS   : 796.91


-- 
Matt Taggart        Linux Development Lab
taggart@fc.hp.com   HP Linux Systems Operation



From hch@caldera.de  Thu Jan  3 23:28:37 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 4 Jan 2002 00:28:37 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>; from anderson@metrolink.com on Thu, Jan 03, 2002 at 05:53:38PM -0500
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104002837.A5883@caldera.de>

On Thu, Jan 03, 2002 at 05:53:38PM -0500, Stuart Anderson wrote:
> On Thu, 3 Jan 2002, Christoph Hellwig wrote:
> 
> > This differs from current practice on some Linux architectures, e.g.
> > PowerPc, ARM or Sparc/SMP.
> 
> Can you please provide some examples? All of the examples I was able to aquire
> fit the description (actually, it was written to fit the exmaples 8-)).

What about checking yourself :)

I have collected a number of examples on:

	http://people.nl.linux.org/~hch/cpuinfo/

> I'd like avoid /proc completely, but we needed a way to determine what
> processor features are available (especially on IA32). Without this, we have
> to choose the i486 feature set as the least common denominator (ie no MMX, etc).

Maybe you should introduce something like uname -f (f for features) in
LSB and make this backed by /proc/cpuinfo in the current implementation?

This way applications do not have to worry about changes to kernel
internals.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From anderson@metrolink.com  Thu Jan  3 23:35:34 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Thu, 3 Jan 2002 18:35:34 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104002837.A5883@caldera.de>
Message-ID: <20020103183322.P616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Christoph Hellwig wrote:

> What about checking yourself :)

If I only had all of the hardware ....

> I have collected a number of examples on:
>
> 	http://people.nl.linux.org/~hch/cpuinfo/

Thanks, this is very helpful.

> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?

I would prefer to document something that already exists, and not require
that a new feature has to be implemented by everyone. Also, it's slightly
easier for an application to just open a text file instead of having to popen()
a command.

> This way applications do not have to worry about changes to kernel
> internals.

That is one of our goals 8-).


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From hch@caldera.de  Thu Jan  3 23:41:29 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 4 Jan 2002 00:41:29 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103183322.P616-100000@trantor.sc.metrolink.com>; from anderson@metrolink.com on Thu, Jan 03, 2002 at 06:35:34PM -0500
References: <20020104002837.A5883@caldera.de> <20020103183322.P616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104004129.A6739@caldera.de>

On Thu, Jan 03, 2002 at 06:35:34PM -0500, Stuart Anderson wrote:
> > 	http://people.nl.linux.org/~hch/cpuinfo/
> 
> Thanks, this is very helpful.

Btw, the number of example is still growing..

> I would prefer to document something that already exists, and not require
> that a new feature has to be implemented by everyone. Also, it's slightly
> easier for an application to just open a text file instead of having to popen()
> a command.

The problem is just that current Linux /proc is full of abuse.
cpuinfo is one of the very good example why it should NOT be set in
stone.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From esr@thyrsus.com  Thu Jan  3 23:29:07 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 18:29:07 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104002837.A5883@caldera.de>; from hch@caldera.de on Fri, Jan 04, 2002 at 12:28:37AM +0100
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com> <20020104002837.A5883@caldera.de>
Message-ID: <20020103182907.A27084@thyrsus.com>

Christoph Hellwig <hch@caldera.de>:
> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?

That would solve my problem.  I just need the /proc/cpuinfo information
to be available in a portable way.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Americans have the right and advantage of being armed - unlike the citizens
of other countries whose governments are afraid to trust the people with arms.
	-- James Madison, The Federalist Papers


From venom@DarkStar.sns.it  Thu Jan  3 23:52:53 2002
From: venom@DarkStar.sns.it (Luigi Genoni)
Date: Fri, 4 Jan 2002 00:52:53 +0100 (CET)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <Pine.LNX.4.43.0201040052090.1109-100000@DarkStar.sns.it>

On Thu, 3 Jan 2002, Stuart Anderson wrote:

> Date: Thu, 3 Jan 2002 17:53:38 -0500 (EST)
> From: Stuart Anderson <anderson@metrolink.com>
> To: Christoph Hellwig <hch@caldera.de>
> Cc: lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org
> Subject: Re: LSB1.1: /proc/cpuinfo
> Resent-Date: Fri, 4 Jan 2002 00:03:56 +0100
> Resent-From: lsb-spec@lists.linuxbase.org
>
> On Thu, 3 Jan 2002, Christoph Hellwig wrote:
>
> > This differs from current practice on some Linux architectures, e.g.
> > PowerPc, ARM or Sparc/SMP.
>
> Can you please provide some examples? All of the examples I was able to aquire
> fit the description (actually, it was written to fit the exmaples 8-)).
>
> > Also /proc/cpuinfo is one of the abuses of the Linux /proc filesystem
> > that might be removed in the mid-term timeframe (e.g. Linux 2.6).
> >
> > Please do not document anything in /proc besides the per-process
> > information.
>
> I'd like avoid /proc completely, but we needed a way to determine what
> processor features are available (especially on IA32). Without this, we have
> to choose the i486 feature set as the least common denominator (ie no MMX, etc).
>
what about x86info ?
mmhh...
then there are problems about the other processors...



From schilling@fokus.gmd.de  Thu Jan  3 23:55:59 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 00:55:59 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201032355.g03Ntx911860@burner.fokus.gmd.de>

>From: Christoph Hellwig <hch@caldera.de>


>> I would prefer to document something that already exists, and not require
>> that a new feature has to be implemented by everyone. Also, it's slightly
>> easier for an application to just open a text file instead of having to popen()
>> a command.

>The problem is just that current Linux /proc is full of abuse.
>cpuinfo is one of the very good example why it should NOT be set in
>stone.


I really hope that /proc/<non-number> will vanish in the future.

It definitely is an abuse of the /proc filesystem that is rerserved
for process.

First let me give some background information:

The way /proc works has been introduced by Plan 9 in the first half of the 80s.
What Linux added as an abuse of the /proc filesytem in principle is a Plan 9
idea too. It makes sense to  have something similar, but please please _not_
inside the /proc tree.

Sun is planning to have /sys with similar backgound in a future version of 
Solaris so it wouls make sense to talk to the Solaris kernel kackers to have a 
common way to go for the new /sys tree.


If you like to look for other ideas on how to retrieve the needed information 
it makes sense to look at Solaris too. The reason is that Solaris uses "prtconf"
which is close to the device tree from the IEEE standard Boot loader.

prtconf -p is giving exactly the IEEE device tree

prtconf -p -v gives more verbose information.

If you don't use -p you will see the kernel view of the device tree.

On MacOS X which also uses the IEEE Boot architecture the same beast
will be shown via a 'ioreg -l'

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:15:06 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:15:06 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103235441.A3021@caldera.de> from "Christoph Hellwig" at Jan 03, 2002 11:54:41 PM
Message-ID: <E16MI0o-0001g5-00@the-village.bc.nu>

>  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

That will break glibc for one thing, so I doubt it

Alan


From hch@caldera.de  Fri Jan  4 00:06:41 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 4 Jan 2002 01:06:41 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MI0o-0001g5-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:15:06AM +0000
References: <20020103235441.A3021@caldera.de> <E16MI0o-0001g5-00@the-village.bc.nu>
Message-ID: <20020104010641.A8577@caldera.de>

On Fri, Jan 04, 2002 at 12:15:06AM +0000, Alan Cox wrote:
> >  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>
> 
> That will break glibc for one thing, so I doubt it

Never major versions break things.
There is no reason to stay broken because glibc is a piece of shit.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:19:29 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:19:29 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103173401.A25141@thyrsus.com> from "Eric S. Raymond" at Jan 03, 2002 05:34:01 PM
Message-ID: <E16MI53-0001i4-00@the-village.bc.nu>

> I disagree with this request.  Files like /proc/cpuinfo are very helpful
> for autoconfigurastion and cluster management.  LSB's constituency would
> be better served by more such information, not less.

The question is whether programs should be parsing it. Right now glibc 
relies on it for certain things. We need /proc/cpuinfo if only for back
compatibility. Documenting it has the disadvantage people will try to parse
it, while not documenting it has the advantage that it can be provided to
the pet human which generally has better error handling.

Alan


From schilling@fokus.gmd.de  Fri Jan  4 00:08:13 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:08:13 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040008.g0408Ds11901@burner.fokus.gmd.de>


>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>>  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

>That will break glibc for one thing, so I doubt it

If glibc has been cleanly written, then it will hide the fact that
it uses /proc/cpuinfo from the user so it could be easily changed to use
the feature that has been implemented as sucessor instead of /proc/cpuinfo
to implement the public features.


J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:22:17 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:22:17 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104010641.A8577@caldera.de> from "Christoph Hellwig" at Jan 04, 2002 01:06:41 AM
Message-ID: <E16MI7l-0001ia-00@the-village.bc.nu>

> > That will break glibc for one thing, so I doubt it
> 
> Never major versions break things.
> There is no reason to stay broken because glibc is a piece of shit.

Well if you don't want any users its not my problem. When you've finished
writing calderux with its own libc, that runs no normal Linux apps you
can go and join the hurd team.

Real world customers (the sort who pay sensible amounts) expect and demand
forward compatibility and the ability to roll back cleanly. Even if Linus
were to take it out of his kernel it would be relevant to the LSB as all
the vendors will have to put it back compatibly.

Alan


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:23:58 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:23:58 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040008.g0408Ds11901@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 01:08:13 AM
Message-ID: <E16MI9O-0001ir-00@the-village.bc.nu>

> If glibc has been cleanly written, then it will hide the fact that
> it uses /proc/cpuinfo from the user so it could be easily changed to use
> the feature that has been implemented as sucessor instead of /proc/cpuinfo
> to implement the public features.

Only if you upgrade the C library. That requires requalifying the entire
system for things like Oracle and SAP and simply isnt going to fly with
enterprise.

You can still run libc2.2 or higher on the current 2.4 kernel. Thats how
careful our compatibility is.


From esr@thyrsus.com  Fri Jan  4 00:02:19 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 19:02:19 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 12:55:59AM +0100
References: <200201032355.g03Ntx911860@burner.fokus.gmd.de>
Message-ID: <20020103190219.B27938@thyrsus.com>

Joerg Schilling <schilling@fokus.gmd.de>:
> The way /proc works has been introduced by Plan 9 in the first half
> of the 80s.  What Linux added as an abuse of the /proc filesytem in
> principle is a Plan 9 idea too. It makes sense to have something
> similar, but please please _not_ inside the /proc tree.
> 
> Sun is planning to have /sys with similar backgound in a future
> version of Solaris so it wouls make sense to talk to the Solaris
> kernel kackers to have a common way to go for the new /sys tree.

Well, hell.  If the "/proc is a blight on the face of the planet" ranting that
I've been hearing is just about the *name* /proc, then let's separate the
name issue from the content issue.

The kind of non-per-process information that is now in /proc needs to still
be there for many purposes; autoconfiguration is the one that is bugging 
me right now, but cluster management is just as important.

If moving /proc/cpuinfo to /sys/cpuinfo means people will stop trying to make
the cpuinfo information go away, then By all means let's move it.

I want /sys/dmi, too.

I'm willing to write up a proposal for /sys that would migrate the `unclean'
/proc stuff over to ./sys, and I'm willing to write the kernel patches to
implement the renaming.

I'm motivated to attack this right now because it touches the work I'm
doing on kernel autoconfiguration.

(Copied to the linux-kernel mailing list because of a parallel argument
happening there...)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:27:13 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:27:13 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 12:55:59 AM
Message-ID: <E16MICX-0001jb-00@the-village.bc.nu>

> The way /proc works has been introduced by Plan 9 in the first half of the 80s.
> What Linux added as an abuse of the /proc filesytem in principle is a Plan 9
> idea too. It makes sense to  have something similar, but please please _not_
> inside the /proc tree.

Linux is not Plan 9 (yet). What the Linux /proc subsystem does is nothing
to do with what Sun, Plan 9, Microsoft or your pet hamster do. Nor is it
remotely meaningful to argue about it that way. Using /sys is also extremely
inappropriate as many BSD derived folks use /sys already and it would make
LSB on non Linux systems unneccessarily hard.

> On MacOS X which also uses the IEEE Boot architecture the same beast
> will be shown via a 'ioreg -l'

The PC world doesnt have an IEEE boot architecture. The ARM world doesn't
the HPPA world doesn't, the MIPS world mostly doesn't, the SH3 world
doesnt.


From hch@infradead.org  Fri Jan  4 00:16:52 2002
From: hch@infradead.org (Christoph Hellwig)
Date: Fri, 4 Jan 2002 01:16:52 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MI7l-0001ia-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:22:17AM +0000
References: <20020104010641.A8577@caldera.de> <E16MI7l-0001ia-00@the-village.bc.nu>
Message-ID: <20020104011652.A9180@caldera.de>

On Fri, Jan 04, 2002 at 12:22:17AM +0000, Alan Cox wrote:
> Well if you don't want any users its not my problem. When you've finished
> writing calderux with its own libc

[Sender address changed to stop your silly assumptions.]

Hurd uses the same glibc, that's not the point.
What I mean is that we there is no reason to support a feature
forever just because glibc (ab)uses it.  /proc is not set in stone.

> that runs no normal Linux apps you, that runs no normal Linux apps you
> can go and join the hurd team.

IF LSB would be designed in a sane way there would be no reason to not
to do so.  But as it contains numerous random glibc internal symbols
it gets rather difficult to use a different libc.

Same is for specifying all those GNU options in the tools, that's very,
very bad style.


> Real world customers (the sort who pay sensible amounts) expect and demand
> forward compatibility and the ability to roll back cleanly. Even if Linus
> were to take it out of his kernel it would be relevant to the LSB as all
> the vendors will have to put it back compatibly.

Glibc already contains so much version checking code that it would be no
problem to use /proc/cpuinfo if the kernel version is smaller than
foo.bar.baz and a sane interface if later.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:34:18 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:34:18 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104011652.A9180@caldera.de> from "Christoph Hellwig" at Jan 04, 2002 01:16:52 AM
Message-ID: <E16MIJO-0001lU-00@the-village.bc.nu>

> Glibc already contains so much version checking code that it would be no
> problem to use /proc/cpuinfo if the kernel version is smaller than
> foo.bar.baz and a sane interface if later.

Wake up, hello, anyone home ?

The _current_ glibc doesn't know about this, so you will break existing 
systems. Unless you can grasp that elementary detail you aren't going to
have a userbase.

Alan


From anderson@metrolink.com  Fri Jan  4 00:23:24 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Thu, 3 Jan 2002 19:23:24 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104011652.A9180@caldera.de>
Message-ID: <20020103192239.R616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Christoph Hellwig wrote:

> IF LSB would be designed in a sane way there would be no reason to not
> to do so.  But as it contains numerous random glibc internal symbols
> it gets rather difficult to use a different libc.

Many of those ugly symbols have been deprecated in 1.1, and will be gone soon.
They showed up as we tried to balance doing it right with the real world.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From esr@thyrsus.com  Fri Jan  4 00:11:56 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 19:11:56 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MI53-0001i4-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:19:29AM +0000
References: <20020103173401.A25141@thyrsus.com> <E16MI53-0001i4-00@the-village.bc.nu>
Message-ID: <20020103191156.D27938@thyrsus.com>

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > I disagree with this request.  Files like /proc/cpuinfo are very helpful
> > for autoconfigurastion and cluster management.  LSB's constituency would
> > be better served by more such information, not less.
> 
> The question is whether programs should be parsing it. Right now glibc 
> relies on it for certain things. We need /proc/cpuinfo if only for back
> compatibility. Documenting it has the disadvantage people will try to parse
> it, while not documenting it has the advantage that it can be provided to
> the pet human which generally has better error handling.

I grant your implied point.

However, I think it's worth noting that the nature of the languages
used to do the parsing is changing.  Nowadays it's less likely to be C
munching individual bytes and more likely to be Perl or Python
slinging regexp matches, which makes the programs a bit less sensitive to
format variations or misunderstandings.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
        -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.


From hch@infradead.org  Fri Jan  4 00:27:13 2002
From: hch@infradead.org (Christoph Hellwig)
Date: Fri, 4 Jan 2002 01:27:13 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MIJO-0001lU-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:34:18AM +0000
References: <20020104011652.A9180@caldera.de> <E16MIJO-0001lU-00@the-village.bc.nu>
Message-ID: <20020104012713.B10266@caldera.de>

On Fri, Jan 04, 2002 at 12:34:18AM +0000, Alan Cox wrote:
> The _current_ glibc doesn't know about this, so you will break existing 
> systems. Unless you can grasp that elementary detail you aren't going to
> have a userbase.

Current glibc won't stay current forever.
If Documentation/Changes says you need never binutils for a new
development kernel or a new stable series you update it, there is no
reason not to do so for glibc.


From dank@kegel.com  Fri Jan  4 00:35:18 2002
From: dank@kegel.com (Dan Kegel)
Date: Thu, 03 Jan 2002 16:35:18 -0800
Subject: LSB1.1: /proc/cpuinfo
References: <200201032355.g03Ntx911860@burner.fokus.gmd.de>
Message-ID: <3C34F8C6.6B5C4C67@kegel.com>

Joerg Schilling wrote:
> ...
> The way /proc works has been introduced by Plan 9 in the first half of the 80s.
> What Linux added as an abuse of the /proc filesytem in principle is a Plan 9
> idea too. It makes sense to  have something similar, but please please _not_
> inside the /proc tree.
> 
> Sun is planning to have /sys with similar backgound in a future version of
> Solaris so it wouls make sense to talk to the Solaris kernel kackers to have a
> common way to go for the new /sys tree.

FWIW, Rusty Russell is working on a replacement for /proc/sys in Linux;
see http://lwn.net/2002/0103/a/proc.php3
I wonder if he's talked to the Solaris people about their /sys plans.

> If you like to look for other ideas on how to retrieve the needed information
> it makes sense to look at Solaris too. The reason is that Solaris uses "prtconf"
> which is close to the device tree from the IEEE standard Boot loader.
> 
> prtconf -p is giving exactly the IEEE device tree
> 
> prtconf -p -v gives more verbose information.
> 
> If you don't use -p you will see the kernel view of the device tree.
> 
> On MacOS X which also uses the IEEE Boot architecture the same beast
> will be shown via a 'ioreg -l'

That's interesting stuff, thanks.
- Dan


From schilling@fokus.gmd.de  Fri Jan  4 00:34:07 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:34:07 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040034.g040Y7E11953@burner.fokus.gmd.de>

>From: Christoph Hellwig <hch@infradead.org>

>Same is for specifying all those GNU options in the tools, that's very,
>very bad style.

Many man pages contain EXAMPLES sections that only list the GNU options
instead of the standard options of the program. If people don't know how a 
program officially works thy tend to copy examples. 

BTW: sorry for being off topic but does anybody know how to write a test that 
finds that GNU rm is not UNIX-98 compliant?

>From http://www.opengroup.org/onlinepubs/7908799/xcu/rm.html:

4.If the current file is a directory, rm will perform actions equivalent to the 
XSH specification rmdir() function called with a pathname of the current file 
used as the path argument.

... but GNU rm has a -d option that makes it behave like the unlink command.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:45:23 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:45:23 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104012713.B10266@caldera.de> from "Christoph Hellwig" at Jan 04, 2002 01:27:13 AM
Message-ID: <E16MIU7-0001nO-00@the-village.bc.nu>

> If Documentation/Changes says you need never binutils for a new
> development kernel or a new stable series you update it, there is no
> reason not to do so for glibc.

Is there anyone home ?

Think like a business end user

"We updated the kernel it broke"
"Our app isnt certified with the new glibc"
"Why do we have to change two components at a time - how will we test it"

At the moment I repeat - I can run any app back to libc 2.2 on a 2.4.x
kernel. Thats back to the days of Linux 0.98 or so. 

I concur we should consider hard if we want to document the internals of
/proc/cpuinfo except when needed (eg mips cache stuff)


From tytso@mit.edu  Fri Jan  4 00:37:14 2002
From: tytso@mit.edu (Theodore Tso)
Date: Thu, 3 Jan 2002 19:37:14 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MIJO-0001lU-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:34:18AM +0000
References: <20020104011652.A9180@caldera.de> <E16MIJO-0001lU-00@the-village.bc.nu>
Message-ID: <20020103193714.C14256@thunk.org>

On Fri, Jan 04, 2002 at 12:34:18AM +0000, Alan Cox wrote:
> > Glibc already contains so much version checking code that it would be no
> > problem to use /proc/cpuinfo if the kernel version is smaller than
> > foo.bar.baz and a sane interface if later.
> 
> Wake up, hello, anyone home ?
> 
> The _current_ glibc doesn't know about this, so you will break existing 
> systems. Unless you can grasp that elementary detail you aren't going to
> have a userbase.

Absolutely --- Alan is 100% correct here.  The earliest /proc/cpuinfo
could disappear is 2.8 (assuming it was deprecated in 2.6).  And I'm
not convinced it's non-pid /proc entries are so horrible that they
have to go away at all costs --- there are far more important things
for us to worry about in the kernel at the moment than aesthetic
issues like this.

Sometimes, practicality needs to take a back seat to "the Right
Thing".  Remember, sometimes "Worse is Better"
(http://www.dreamsongs.com/WIB.html); in fact, many people would argue
that Linux is a prime example of how sometimes "Worse is Better"
approach is far better than trying to do the Right Thing.  (That way
lies NetBSD --- the organization that took three years to rearchitect
their entire device driver interface before they had full PCMCIA
support.)

More often than not, practicality and support of the existing user
base is far more important that being Architecturally Pure.

						- Ted


From schilling@fokus.gmd.de  Fri Jan  4 00:42:17 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:42:17 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040042.g040gHR11989@burner.fokus.gmd.de>


>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>Think like a business end user

>"We updated the kernel it broke"
>"Our app isnt certified with the new glibc"
>"Why do we have to change two components at a time - how will we test it"

>At the moment I repeat - I can run any app back to libc 2.2 on a 2.4.x
>kernel. Thats back to the days of Linux 0.98 or so. 

Why do you tell us this?

This is wrong and you should know about it as we had more then one personal
discussion about exactly this fact. Not even a simple program that uses only
ctype.h will run correctly if you go <= glibc-2.1.

Glibc-2.1 has a broken large file interface that if an application tris to work 
around make it non binary compliant, the /dev/sg interface did change many 
times the signal interface is incompatible. I hope that I don't need to tell you more.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:59:26 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:59:26 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040042.g040gHR11989@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 01:42:17 AM
Message-ID: <E16MIhi-0001py-00@the-village.bc.nu>

> This is wrong and you should know about it as we had more then one personal
> discussion about exactly this fact. Not even a simple program that uses only
> ctype.h will run correctly if you go <= glibc-2.1.

Take an RH box with glibc 2.0.7. You'll note that while glibc had (and has!)
plenty of bugs they were not biting the apps people were using (otherwise
they wouldnt have been able to use glibc 2.0.7) and that release.

It isnt about buggyness. Its about production solid. It worked for 2 years
so statistically it should continue to do so. This makes sysadmins happy.


From schilling@fokus.gmd.de  Fri Jan  4 00:54:07 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:54:07 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040054.g040s7X12008@burner.fokus.gmd.de>


>From alan@lxorguk.ukuu.org.uk Fri Jan  4 01:48:32 2002

>> This is wrong and you should know about it as we had more then one personal
>> discussion about exactly this fact. Not even a simple program that uses only
>> ctype.h will run correctly if you go <= glibc-2.1.

>Take an RH box with glibc 2.0.7. You'll note that while glibc had (and has!)
>plenty of bugs they were not biting the apps people were using (otherwise
>they wouldnt have been able to use glibc 2.0.7) and that release.

I received many "bug reports" for cdrecord about 2 years ago.

The reason was that "cdrecord dev=xxx ..." won't work because the bit mask 
definitions in ctype.h did change and for this reason, cdrecold by using 
getallargs would assume that dev= is not an option but a file type argument.

I had to send plenty of mails stating: don't use precompiled versions of 
cdrecord because Linux is not binary compatible to itself. You need to compile 
an application on the machine you like to run it :-(

As you see there _have_ been incompatible changes without a reason.

If you like to care Linux users starting from now this is a nice idea, however 
it was not done in former times.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From viro@math.psu.edu  Fri Jan  4 00:56:51 2002
From: viro@math.psu.edu (Alexander Viro)
Date: Thu, 3 Jan 2002 19:56:51 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103190219.B27938@thyrsus.com>
Message-ID: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>



On Thu, 3 Jan 2002, Eric S. Raymond wrote:

> Well, hell.  If the "/proc is a blight on the face of the planet" ranting that
> I've been hearing is just about the *name* /proc, then let's separate the
> name issue from the content issue.

It's more than just a name.
	a) granularity.  Current "all or nothing" policy in procfs has
a lot of obvious problems.
	b) tree layout policy (lack thereof, to be precise).
	c) horribly bad layout of many, many files.  Any file exported by
kernel should be treated as user-visible API.  As it is, common mentality
is "it's a common dump; anything goes here".  Inconsistent across
architectures for no good reason, inconsistent across kernel versions,
just plain stupid, choke-full of buffer overruns...

Fixing these problems will _hurt_.  Badly.  We have to do it, but it
won't be fast and it certainly won't happen overnight.


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 01:10:24 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 01:10:24 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040054.g040s7X12008@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 01:54:07 AM
Message-ID: <E16MIsK-0001uc-00@the-village.bc.nu>

> The reason was that "cdrecord dev=xxx ..." won't work because the bit mask 
> definitions in ctype.h did change and for this reason, cdrecold by using 
> getallargs would assume that dev= is not an option but a file type argument.

SuSE and Red Hat managed to get different glibc 2.0 ones. Thats a somewhat
seperate issue, and thats the kind of thing the LSB is precisely there
to ensure doesn't happen again.

Thats not a compatibility argument so much as a clear explanation of why
the LSB matters

Alan


From schilling@fokus.gmd.de  Fri Jan  4 01:03:48 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 02:03:48 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040103.g0413m012034@burner.fokus.gmd.de>

>From alan@lxorguk.ukuu.org.uk Fri Jan  4 01:59:30 2002

>> The reason was that "cdrecord dev=xxx ..." won't work because the bit mask 
>> definitions in ctype.h did change and for this reason, cdrecold by using 
>> getallargs would assume that dev= is not an option but a file type argument.

>SuSE and Red Hat managed to get different glibc 2.0 ones. Thats a somewhat
>seperate issue, and thats the kind of thing the LSB is precisely there
>to ensure doesn't happen again.

>Thats not a compatibility argument so much as a clear explanation of why
>the LSB matters

I am happy to see LSB as it makes Linux go towards a system that may be used 
by combining binary compilations of programs on many systems if it is done 
right.

Right now, when I am forced to make binary only versions of programs like
e.g. the the Plextor firmware upgrade program, I can only do it for libc.so.5 
and for glibc-2.2. Anything in between gives problems.


J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From esr@thyrsus.com  Fri Jan  4 00:52:07 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 19:52:07 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, Jan 03, 2002 at 07:56:51PM -0500
References: <20020103190219.B27938@thyrsus.com> <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
Message-ID: <20020103195207.A31252@thyrsus.com>

Alexander Viro <viro@math.psu.edu>:
> It's more than just a name.
> 	a) granularity.  Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> 	b) tree layout policy (lack thereof, to be precise).
> 	c) horribly bad layout of many, many files.  Any file exported by
> kernel should be treated as user-visible API.  As it is, common mentality
> is "it's a common dump; anything goes here".  Inconsistent across
> architectures for no good reason, inconsistent across kernel versions,
> just plain stupid, choke-full of buffer overruns...
> 
> Fixing these problems will _hurt_.  Badly.  We have to do it, but it
> won't be fast and it certainly won't happen overnight.

I'm willing to work on this.  Is there anywhere I can go to read up on 
current proposals before I start coding?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

When all government ...in little as in great things... shall be drawn to
Washington as the center of all power; it will render powerless the checks
provided of one government on another, and will become as venal and oppressive
as the government from which we separated."	-- Thomas Jefferson, 1821


From jgarzik@mandrakesoft.com  Fri Jan  4 01:18:48 2002
From: jgarzik@mandrakesoft.com (Jeff Garzik)
Date: Thu, 03 Jan 2002 20:18:48 -0500
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
References: <200201032355.g03Ntx911860@burner.fokus.gmd.de> <20020103190219.B27938@thyrsus.com>
Message-ID: <3C3502F8.4834077@mandrakesoft.com>

To run offtopic a bit, it was a huge mistake for LSB 1.0 to document
GNU-specific command line extensions.

Each command should be compared with SuSv2 or POSIX, and if an argument
or behavior is extraneous, careful thought should be put into leaving it
in LSB.

To do otherwise places an unrealistic burden on implementors of embedded
and otherwise small systems.

Does a standard Linux implementation of /bin/cat really require
supporting --number-nonblank and --squeeze-blank and --show-nonprinting?

I humbly urge members and readers to reconsider this course of action. 
As it stands, LSB is currently not a standards document but really a
common-practices document.

Best regards,

	Jeff



-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 01:38:27 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 01:38:27 +0000 (GMT)
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
In-Reply-To: <3C3502F8.4834077@mandrakesoft.com> from "Jeff Garzik" at Jan 03, 2002 08:18:48 PM
Message-ID: <E16MJJT-0001yM-00@the-village.bc.nu>

> Each command should be compared with SuSv2 or POSIX, and if an argument
> or behavior is extraneous, careful thought should be put into leaving it
> in LSB.

Please go and read the LSB mission statement and the original mailing
list discussions first.

> To do otherwise places an unrealistic burden on implementors of embedded
> and otherwise small systems.

Please go and read the old LSB archives. This is a long old discussion

> Does a standard Linux implementation of /bin/cat really require
> supporting --number-nonblank and --squeeze-blank and --show-nonprinting?
> 
Please go and read the old LSB archives. This is a long old discussion

> I humbly urge members and readers to reconsider this course of action. 
> As it stands, LSB is currently not a standards document but really a
> common-practices document.

Guess what, thats what the whole bloody idea is. But if you'd actually
bothered to read before writing you'd have known that.

Alan


From jgarzik@mandrakesoft.com  Fri Jan  4 01:30:53 2002
From: jgarzik@mandrakesoft.com (Jeff Garzik)
Date: Thu, 03 Jan 2002 20:30:53 -0500
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
References: <E16MJJT-0001yM-00@the-village.bc.nu>
Message-ID: <3C3505CD.B85B6D7E@mandrakesoft.com>

Alan Cox wrote:
> > I humbly urge members and readers to reconsider this course of action.
> > As it stands, LSB is currently not a standards document but really a
> > common-practices document.
> 
> Guess what, thats what the whole bloody idea is. But if you'd actually
> bothered to read before writing you'd have known that.

A common practices document that is going to need continual updating as
people start using more and more non-GNU command utilities.  Which is
why the crud should be removed now.

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 01:43:10 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 01:43:10 +0000 (GMT)
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
In-Reply-To: <3C3505CD.B85B6D7E@mandrakesoft.com> from "Jeff Garzik" at Jan 03, 2002 08:30:53 PM
Message-ID: <E16MJO2-0001zE-00@the-village.bc.nu>

> > Guess what, thats what the whole bloody idea is. But if you'd actually
> > bothered to read before writing you'd have known that.
> 
> A common practices document that is going to need continual updating as
> people start using more and more non-GNU command utilities.  Which is
> why the crud should be removed now.

For god sake go and read the archive. Then come back.

Alan


From timothy.covell@ashavan.org  Fri Jan  4 01:56:46 2002
From: timothy.covell@ashavan.org (Timothy Covell)
Date: Thu, 3 Jan 2002 19:56:46 -0600
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
References: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
Message-ID: <200201040200.g0420PSr029316@svr3.applink.net>

On Thursday 03 January 2002 18:56, Alexander Viro wrote:
> On Thu, 3 Jan 2002, Eric S. Raymond wrote:
> > Well, hell.  If the "/proc is a blight on the face of the planet" ranting
> > that I've been hearing is just about the *name* /proc, then let's
> > separate the name issue from the content issue.
>
> It's more than just a name.
> 	a) granularity.  Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> 	b) tree layout policy (lack thereof, to be precise).
> 	c) horribly bad layout of many, many files.  Any file exported by
> kernel should be treated as user-visible API.  As it is, common mentality
> is "it's a common dump; anything goes here".  Inconsistent across
> architectures for no good reason, inconsistent across kernel versions,
> just plain stupid, choke-full of buffer overruns...
>
> Fixing these problems will _hurt_.  Badly.  We have to do it, but it
> won't be fast and it certainly won't happen overnight.


Talking from the SysAdmin point of view, procfs is one of the truly
cool things which separates Linux from the others.   I'd rather tune
/proc/sys stuff than use sysctl or Solaris' funky /etc/system and
ndd crap.  It's the next best thing to "point and click" without going
over to the dark side.

Sure /system is a better name (extra typing becaue we can't have 
/sys/sys can we??).  

And while you all are  at it, why not take a look at some of the naming 
conventions that BeOS makes too.  I'm _not_ being sarcastic.    


Example1: Excellent devfs layout.

Example 2:  BeOS root directory is a ramfs off of which the
other drives/filesystems are mounted.   (I haven't thought 
this one out too much but I could image that it would make
some things easier.)

Example 3:  Kernel Modules are in the directory:
	/boot/beos/system/add-ons/kernel
Perhaps we could have directories something like:

/boot/kernel
/boot/grub
/boot/lilo
/dev	 using devfs !
/etc
/home
/system/config/sys
                    /net
/system/modules/kernelversion/ (modules in devfs similar tree)
/system/info  (for cpuinfo, ioports, meminfo, filesystems, etc.)
/sbin	(or even in /system/bin ???)
/tmp
/usr
/var

Example 3:    BeOS moves /usr/local stuff to more of a per user 
configuration where each user has a $HOME/config directory.
Of course, we would put things like .Xdefaults, kde, gnome, etc.
directories here which vary according to user while still keeping
/usr/local for all users.

My ~/config contains things like "find ~/config -type d | hand edit some"

config/add-ons/media/decoders
config/add-ons/media/encoders
config/add-ons/media/extractors
config/add-ons/media/writers
config/add-ons/net_server
config/be/Applications
config/be/Demos
config/be/Preferences
config/bin
config/boot		(Things my personal boot/login preferences)
config/doc
config/doc/postgresql
config/doc/postgresql/html
config/documentation
config/etc
config/fonts
config/include
config/include/openssl
config/include/postgresql
config/include/postgresql/lib
config/include/postgresql/libpq
config/lib
config/lib/perl5
config/lib/perl5/5.00503
config/lib/perl5/site_perl
config/lib/perl5/site_perl/5.005/BePC-beos
config/man
config/man/man1
config/servers
config/settings
config/settings/beos_mime
config/settings/beos_mime/application
config/settings/beos_mime/audio
config/settings/beos_mime/image
config/settings/beos_mime/message
config/settings/beos_mime/text
config/settings/beos_mime/video
config/share
config/share/postgresql
config/ssl
config/ssl/certs
config/ssl/lib
config/ssl/man
config/ssl/man/man1


Of course, on heavily user subscribed systems, some sort of
NT like COW technique might be nesc. if too many file duplications
occur in the ~/config directories.  Having a good /usr/local would
prevent much of this growth, at least in theory.  As would strict
quotas. :-)



Just some thoughts.

-- 
timothy.covell@ashavan.org.


From wichert@wiggy.net  Fri Jan  4 12:15:49 2002
From: wichert@wiggy.net (Wichert Akkerman)
Date: Fri, 4 Jan 2002 13:15:49 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104121549.GP12696@wiggy.net>

Previously Stuart Anderson wrote:
> I'd like avoid /proc completely, but we needed a way to determine what
> processor features are available (especially on IA32). Without this,
> we have to choose the i486 feature set as the least common denominator
> (ie no MMX, etc).

I'm not quite sure that is a bad thing actually.

Wichert.

-- 
  _________________________________________________________________
 /wichert@wiggy.net         This space intentionally left occupied \
| wichert@deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 12:36:45 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 12:36:45 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104121549.GP12696@wiggy.net> from "Wichert Akkerman" at Jan 04, 2002 01:15:49 PM
Message-ID: <E16MTaX-0003oJ-00@the-village.bc.nu>

> > we have to choose the i486 feature set as the least common denominator
> > (ie no MMX, etc).
> 
> I'm not quite sure that is a bad thing actually.

Its a very bad thing for large numbers of applications. However for x86 it
isnt the case that we need to look at /proc. If you follow the AMD and Intel
guidelines for identifying their processors you will be fine, and cpuid is
user space. The minimal feature set btw is 386. The 486 adds instructions
like BSWAP that may not be present on some other chips right up to the
nexgen 586.

This is not always the case for non x86 platforms, but that is a matter
for the architecture specific LSB parts.

Alan


From Ralf Flaxa <rf@caldera.de>  Fri Jan  4 12:30:51 2002
From: Ralf Flaxa <rf@caldera.de> (Ralf Flaxa)
Date: Fri, 4 Jan 2002 13:30:51 +0100
Subject: [New Proposal] cpuinfo, but not directly via /proc
In-Reply-To: <20020104002837.A5883@caldera.de>; from hch@caldera.de on Fri, Jan 04, 2002 at 12:28:37AM +0100
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com> <20020104002837.A5883@caldera.de>
Message-ID: <20020104133051.A10241@lst.de>

Disclaimer:
[ Inappropriate bashing by Christoph against the glibc folks removed.   ]
[ This is *NOT* Caldera's position and we very much appreciate all the  ]
[ hard work people put into glibc. Caldera believes instead that Linux  ]
[ needs certain standards in order to maintain and improve its success  ]
[ in the business and enterprise world. That's why we support e.g. LSB. ]

We would like to make a new proposal - see below.

On Fri, Jan 04, 2002 at 12:28:37AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 03, 2002 at 05:53:38PM -0500, Stuart Anderson wrote:
> 
> > I'd like avoid /proc completely, but we needed a way to determine what
> > processor features are available (especially on IA32). Without this, we have
> > to choose the i486 feature set as the least common denominator (ie no MMX, etc).
> 
> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?
> 
> This way applications do not have to worry about changes to kernel
> internals.

I like this idea, be it implemented via "uname" or some other interface.

Reading this thread and previous requests I see a need by ISVs and
applications to determine at runtime certain processor related features.

They can roughly be grouped into:

1. number-crunching power in general

	o number of CPUs
	o CPU family and type
	o BogoMips (per CPU and/or overall)
	o SMP capabilities (here kernel scalability could be an item)

2. features specific to a processor

	o for x86 e.g. the "flags" and *_bug fields
	o info about FPU, MMU and the like

I have asked Christoph to work on a proposal and present it
to this list. I think we agree that there is a need and demand
for a standard way to gather this info and that /proc/cpuinfo
was just a bad start - so I would like to give it another chance.

This is Ralf speaking as director of Linux development at Caldera
and as technical lead for the LSB sample implementation.

	Ralf



From mstone@cs.loyola.edu  Fri Jan  4 14:25:35 2002
From: mstone@cs.loyola.edu (Michael Stone)
Date: Fri, 4 Jan 2002 09:25:35 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040034.g040Y7E11953@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 01:34:07AM +0100
References: <200201040034.g040Y7E11953@burner.fokus.gmd.de>
Message-ID: <20020104092535.B20024@justice.loyola.edu>

On Fri, Jan 04, 2002 at 01:34:07AM +0100, Joerg Schilling wrote:
> BTW: sorry for being off topic but does anybody know how to write a test that 
> finds that GNU rm is not UNIX-98 compliant?
> 
> From http://www.opengroup.org/onlinepubs/7908799/xcu/rm.html:
> 
> 4.If the current file is a directory, rm will perform actions equivalent to the 
> XSH specification rmdir() function called with a pathname of the current file 
> used as the path argument.
> 
> ... but GNU rm has a -d option that makes it behave like the unlink command.

If you use an out-of-standard option, why would you expect a
standards-compliant result? 

-- 
Mike Stone


From schilling@fokus.gmd.de  Fri Jan  4 14:34:34 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 15:34:34 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041434.g04EYYq12867@burner.fokus.gmd.de>


>From: Michael Stone <mstone@cs.loyola.edu>

>On Fri, Jan 04, 2002 at 01:34:07AM +0100, Joerg Schilling wrote:
>> BTW: sorry for being off topic but does anybody know how to write a test that 
>> finds that GNU rm is not UNIX-98 compliant?
>> 
>> From http://www.opengroup.org/onlinepubs/7908799/xcu/rm.html:
>> 
>> 4.If the current file is a directory, rm will perform actions equivalent to the 
>> XSH specification rmdir() function called with a pathname of the current file 
>> used as the path argument.
>> 
>> ... but GNU rm has a -d option that makes it behave like the unlink command.

>If you use an out-of-standard option, why would you expect a
>standards-compliant result? 

My question was: 

"How could a standard compliance test find out that GNU rm includes a nonstandard
option that gives GNU rm properties that are not allowed from SUSv2?"

The problem ius that such incompatibilities cannot be found by starting a 
compliance test and waiting for the results. You have to read the standard, 
memorize it, read the man pages of the programs to test and then check whether 
the untestable behavior would be alloed to exists by the standard.




J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From kukuk@suse.de  Fri Jan  4 14:44:37 2002
From: kukuk@suse.de (Thorsten Kukuk)
Date: Fri, 4 Jan 2002 15:44:37 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041434.g04EYYq12867@burner.fokus.gmd.de>
References: <200201041434.g04EYYq12867@burner.fokus.gmd.de>
Message-ID: <20020104154437.A30760@suse.de>

On Fri, Jan 04, Joerg Schilling wrote:

> My question was: 
> 
> "How could a standard compliance test find out that GNU rm includes a nonstandard
> option that gives GNU rm properties that are not allowed from SUSv2?"

Where is the problem? You don't use this nonstandard option and
everything is ok. There is no rule that a software is not allowed
to have more options than specified in the LSB. So you don't need
to check, if software can do more, you only need to check that
software can do that, what the spec requires and don't do things,
which are explicit forbidden.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


From mstone@cs.loyola.edu  Fri Jan  4 14:46:23 2002
From: mstone@cs.loyola.edu (Michael Stone)
Date: Fri, 4 Jan 2002 09:46:23 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041434.g04EYYq12867@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 03:34:34PM +0100
References: <200201041434.g04EYYq12867@burner.fokus.gmd.de>
Message-ID: <20020104094623.C20024@justice.loyola.edu>

On Fri, Jan 04, 2002 at 03:34:34PM +0100, Joerg Schilling wrote:
> "How could a standard compliance test find out that GNU rm includes a nonstandard
> option that gives GNU rm properties that are not allowed from SUSv2?"

It's irrelevant. If the standard says that undefined options produce
undefined behavior, the conclusion is obvious. If the standard says that
undefined options are disallowed, then you test to see whether the
program accepts undefined options. IOW, the specific behavior of
undefined options is orthogonal to your test.

-- 
Mike Stone


From schilling@fokus.gmd.de  Fri Jan  4 14:55:22 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 15:55:22 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041455.g04EtMd12890@burner.fokus.gmd.de>


>From kukuk@suse.de Fri Jan  4 15:44:41 2002

>On Fri, Jan 04, Joerg Schilling wrote:

>> My question was: 
>> 
>> "How could a standard compliance test find out that GNU rm includes a nonstandard
>> option that gives GNU rm properties that are not allowed from SUSv2?"

>Where is the problem? You don't use this nonstandard option and
>everything is ok. There is no rule that a software is not allowed
>to have more options than specified in the LSB. So you don't need
>to check, if software can do more, you only need to check that
>software can do that, what the spec requires and don't do things,
>which are explicit forbidden.


Please READ the standard before you try to find arguments!

The standard says that the rm command has to use the rmdir() behavior in 
order to remove directories.

As - if you are root- you may unlink a non-empty diretory using GNUrm -d 
this is

-	a behavior that is not compliant with the general rules for the
	rm program.

-	a risk fot the data integrity of the machine

If you call GNUrm -d on a non-empty directory you need to run fsck later to move
the orhpaned files into lost+found. As this is nothing you should really like
this behavior is reserved to the SUSv2 command "unlink" - you will not by chance
of a typo call unlink <dir> instead of rm <dir>

Check your keyboard: the letter "d" and the letter "f" are close to each other.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From schilling@fokus.gmd.de  Fri Jan  4 14:56:36 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 15:56:36 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041456.g04Euak12902@burner.fokus.gmd.de>


>From mstone@justice.loyola.edu Fri Jan  4 15:46:26 2002

>On Fri, Jan 04, 2002 at 03:34:34PM +0100, Joerg Schilling wrote:
>> "How could a standard compliance test find out that GNU rm includes a nonstandard
>> option that gives GNU rm properties that are not allowed from SUSv2?"

>It's irrelevant. If the standard says that undefined options produce
>undefined behavior, the conclusion is obvious. If the standard says that
>undefined options are disallowed, then you test to see whether the
>program accepts undefined options. IOW, the specific behavior of
>undefined options is orthogonal to your test.

For you too: Please READ the standard and try to understand it before you start
argumenting about it.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From anderson@metrolink.com  Fri Jan  4 15:10:09 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 10:10:09 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MTaX-0003oJ-00@the-village.bc.nu>
Message-ID: <20020104100841.O616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> > > we have to choose the i486 feature set as the least common denominator
> > > (ie no MMX, etc).
> >
> > I'm not quite sure that is a bad thing actually.
>
> Its a very bad thing for large numbers of applications. However for x86 it
> isnt the case that we need to look at /proc. If you follow the AMD and Intel
> guidelines for identifying their processors you will be fine, and cpuid is
> user space.

I did read the app notes pertaining to this, and felt that it was an excessive
burdon on the application considering the kernel had already done the work.




                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From kukuk@suse.de  Fri Jan  4 15:09:32 2002
From: kukuk@suse.de (Thorsten Kukuk)
Date: Fri, 4 Jan 2002 16:09:32 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041455.g04EtMd12890@burner.fokus.gmd.de>
References: <200201041455.g04EtMd12890@burner.fokus.gmd.de>
Message-ID: <20020104160932.A6040@suse.de>

On Fri, Jan 04, Joerg Schilling wrote:

> 
> >From kukuk@suse.de Fri Jan  4 15:44:41 2002
> 
> >On Fri, Jan 04, Joerg Schilling wrote:
> 
> >> My question was: 
> >> 
> >> "How could a standard compliance test find out that GNU rm includes a nonstandard
> >> option that gives GNU rm properties that are not allowed from SUSv2?"
> 
> >Where is the problem? You don't use this nonstandard option and
> >everything is ok. There is no rule that a software is not allowed
> >to have more options than specified in the LSB. So you don't need
> >to check, if software can do more, you only need to check that
> >software can do that, what the spec requires and don't do things,
> >which are explicit forbidden.
> 
> 
> Please READ the standard before you try to find arguments!

I read it. And did not found the answer. So, please explain, where the
standard forbids additional options, which are not standard conform.

> The standard says that the rm command has to use the rmdir() behavior in 
> order to remove directories.

Yes, this is what the standard says, here we agree.

> As - if you are root- you may unlink a non-empty diretory using GNUrm -d 

You are doing here something which is not in the standard. The standard says
nothing about "-d". So, if you use a non-standard option, the behavior
is not documented in the standard. rm says, that it will remove directories
with unlink if "-d" is used. So, everything is ok.

> this is
> 
> -	a behavior that is not compliant with the general rules for the
> 	rm program.

It is. You use a non-standard option to overwrite the standard. The standard
says nothing about unspecified arguments.

> -	a risk fot the data integrity of the machine

But the manual page for GNUrm clearly writes that it will use "unlink".
So it is your problem.

> Check your keyboard: the letter "d" and the letter "f" are close to each other.

Then you should be more carefull what you type.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


From tytso@mit.edu  Fri Jan  4 15:40:43 2002
From: tytso@mit.edu (Theodore Tso)
Date: Fri, 4 Jan 2002 10:40:43 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040103.g0413m012034@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 02:03:48AM +0100
References: <200201040103.g0413m012034@burner.fokus.gmd.de>
Message-ID: <20020104104043.A17545@thunk.org>

On Fri, Jan 04, 2002 at 02:03:48AM +0100, Joerg Schilling wrote:
> Right now, when I am forced to make binary only versions of programs
> like e.g. the the Plextor firmware upgrade program, I can only do it
> for libc.so.5 and for glibc-2.2. Anything in between gives problems.

Why don't you just link your binary-only program statically?  If you
do that, then it is entirely irrelevant which libc is installed on the
system, and core kernel backwards compatibility has been quite good,
actually.  

Yes, there have been some small problems, but most of them have been
device driver specific --- which I know is a sore point for you, since
a number of those problems have been in the scsi sg/cdrom/cd-recorder
space, where you spend a lot of time.  (And thank you, by the way,
it's much appreciated!)  And when people make (or suggest)
irresponsible changes like that, whether it's non-compatible changes
to device driver bitmaps which are referenced in public API's, or
whether it's in proposing that /proc/cpuinfo should be removed, they
should be spanked.

So if you link statically, your programs will run sanely accross a
much larger part of the Linux installed base, and across a much larger
set of programs than if you link dynamically and hope for the best.

						- Ted

P.S.  On a completely unrelated note, while I have you here, how well
do DVD recorders work with Linux these days?  Some folks have claimed
that cdreocrd will "just work" --- is that true?


From schilling@fokus.gmd.de  Fri Jan  4 15:52:13 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 16:52:13 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041552.g04FqDD12946@burner.fokus.gmd.de>

>From tytso@thunk.org Fri Jan  4 16:41:00 2002

>On Fri, Jan 04, 2002 at 02:03:48AM +0100, Joerg Schilling wrote:
>> Right now, when I am forced to make binary only versions of programs
>> like e.g. the the Plextor firmware upgrade program, I can only do it
>> for libc.so.5 and for glibc-2.2. Anything in between gives problems.

>Why don't you just link your binary-only program statically?  If you
>do that, then it is entirely irrelevant which libc is installed on the
>system, and core kernel backwards compatibility has been quite good,
>actually.  

Due to a bug inside either the linker or glibc it is not possible
to link cdrecord and similar programs statically. If you like, I could
check again and send you the error messages.


>So if you link statically, your programs will run sanely accross a
>much larger part of the Linux installed base, and across a much larger
>set of programs than if you link dynamically and hope for the best.

If the ld/libc problem was fixed - may be...



>P.S.  On a completely unrelated note, while I have you here, how well
>do DVD recorders work with Linux these days?  Some folks have claimed
>that cdreocrd will "just work" --- is that true?

cdrecord-ProDVD is one of the very first DVD-R/DVD-RW recording programs.
It started 4 years ago, when a drive was 18000 $ and a media was 70 $.

As DVD recording is not a common feature and from some bad experiences with
companies who did steel in one case e.g. cdrecord/Linux for a commercial
closed source project, I am curently not making this program OSS. It would be too
simple for companies that currently don't have DVD-R technoligy to steel the
code....

You may check a test binary from

ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ProDVD/

it writes unlimited in dummy mode and limited to 1 GB in real mode.

... don't forget to use one of the latest Linux kernels as there was a bug in 
the ISO-9660 filesystem code that prevented DVD sized media to work in Linux.

Mkisofs did recently get UDF support and passed the Philips UDF conformance test
for Video DVD media. It still has to be enhanced as it currently binds
UDF name space to Joliet namespace which is a bad idea.




J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From schilling@fokus.gmd.de  Fri Jan  4 16:01:14 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 17:01:14 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041601.g04G1Ev12955@burner.fokus.gmd.de>

>From: Thorsten Kukuk <kukuk@suse.de>


>> The standard says that the rm command has to use the rmdir() behavior in 
>> order to remove directories.

>Yes, this is what the standard says, here we agree.

And as the standard does not say that the program may have nonstandard
options that remove the need to follow the rmdir() rules, it is obvious that
the rm program must follow the rmdir() rules in all cases even when
using nonstandard options.

>> As - if you are root- you may unlink a non-empty diretory using GNUrm -d 

>You are doing here something which is not in the standard. The standard says
>nothing about "-d". So, if you use a non-standard option, the behavior
>is not documented in the standard. rm says, that it will remove directories
>with unlink if "-d" is used. So, everything is ok.

See aboove: If the nonstandard option makes the rm program to ignore the SUSv2
rules, then you must either remove the -d option or aggree that GNUrm is not
compliant to the SUSv2 standard.

>> -	a risk fot the data integrity of the machine

>But the manual page for GNUrm clearly writes that it will use "unlink".
>So it is your problem.

>> Check your keyboard: the letter "d" and the letter "f" are close to each other.

>Then you should be more carefull what you type.

There is no need to have the -d option in GNU rm as there is a "unlink" command
that doesn't have this problem and is documented in SUSv2.

The fact that there is a one letter option that is able to make gnu rm behave
different than documented in the standard is at least a risk that could easily 
be avoided if you would be forced to use the long option to activate id _and_
if the man page for GNU rm would clearly state that this option is non 
standard.

If you call "star H=gnutar ...." you will create nonstandard "tar" archives
but you will need to type a lot to do this _and_ the star man page clearly 
states that this will cause non-standard archives to be created.

If you call mkisofs with the -Joliet option or any other option that allows
mkisofs to create non ISO-9960 images to be created, it warns you that the
resulting archive will be non standard.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From ak@suse.de  Fri Jan  4 16:04:30 2002
From: ak@suse.de (Andi Kleen)
Date: 04 Jan 2002 17:04:30 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: Theodore Tso's message of "4 Jan 2002 16:41:30 +0100"
References: <200201040103.g0413m012034@burner.fokus.gmd.de.suse.lists.lsb-spec> <20020104104043.A17545@thunk.org.suse.lists.lsb-spec>
Message-ID: <p73sn9m9k6p.fsf@oldwotan.suse.de>

Theodore Tso <tytso@mit.edu> writes:

> On Fri, Jan 04, 2002 at 02:03:48AM +0100, Joerg Schilling wrote:
> > Right now, when I am forced to make binary only versions of programs
> > like e.g. the the Plextor firmware upgrade program, I can only do it
> > for libc.so.5 and for glibc-2.2. Anything in between gives problems.
> 
> Why don't you just link your binary-only program statically?  If you
> do that, then it is entirely irrelevant which libc is installed on the
> system, and core kernel backwards compatibility has been quite good,
> actually.  

If he wants to link to any LGPLed library like glibc he would need
to ship object files in this case, allowing a relink. Otherwise it would
violate the LGPL. 

Also glibc needs to be rebuilt to be able to link completely statically;
by default it always loads the name service modules dynamically. 

-Andi


From kukuk@suse.de  Fri Jan  4 16:06:46 2002
From: kukuk@suse.de (Thorsten Kukuk)
Date: Fri, 4 Jan 2002 17:06:46 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041601.g04G1Ev12955@burner.fokus.gmd.de>
References: <200201041601.g04G1Ev12955@burner.fokus.gmd.de>
Message-ID: <20020104170646.A4558@suse.de>

On Fri, Jan 04, Joerg Schilling wrote:

> >> The standard says that the rm command has to use the rmdir() behavior in 
> >> order to remove directories.
> 
> >Yes, this is what the standard says, here we agree.
> 
> And as the standard does not say that the program may have nonstandard
> options that remove the need to follow the rmdir() rules, it is obvious that
> the rm program must follow the rmdir() rules in all cases even when
> using nonstandard options.

No, where does this stand? Nonstandard options are for nonstandard 
cases. If you use only standard options, GNUrm is standard conform.

As already written: Please show me the text in the standard, which
forbids this.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:23:10 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:23:10 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041601.g04G1Ev12955@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 05:01:14 PM
Message-ID: <E16MX7e-0004WQ-00@the-village.bc.nu>

> And as the standard does not say that the program may have nonstandard
> options that remove the need to follow the rmdir() rules, it is obvious that
> the rm program must follow the rmdir() rules in all cases even when
> using nonstandard options.

The standard does not say that a command cannot have non standard options
that do nonstandard things.

Alan


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:26:24 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:26:24 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104100841.O616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 10:10:09 AM
Message-ID: <E16MXAm-0004XZ-00@the-village.bc.nu>

> I did read the app notes pertaining to this, and felt that it was an excessive
> burdon on the application considering the kernel had already done the work.

The things that actually matter are like 10 lines of GNU C with a little
__asm__ block. The code is out there in GPL form and its shorter than
parsing /proc


From dbb@caldera.com  Fri Jan  4 16:23:35 2002
From: dbb@caldera.com (Doug Beattie)
Date: Fri, 04 Jan 2002 09:23:35 -0700
Subject: LSB1.1: /proc/cpuinfo
References: <E16MX7e-0004WQ-00@the-village.bc.nu>
Message-ID: <3C35D707.84E7E9CA@caldera.com>

Then, in general the specification should state that any options not
documented, but found to be present in any command/function, should
not be used as they will not have been tested and results cannot be
guaranteed.

Can we make a blanket statement that will satisfy all such conditions
so we don't have to go through and document each and every situation
within the specification?


Alan Cox wrote:
> 
> > And as the standard does not say that the program may have nonstandard
> > options that remove the need to follow the rmdir() rules, it is obvious that
> > the rm program must follow the rmdir() rules in all cases even when
> > using nonstandard options.
> 
> The standard does not say that a command cannot have non standard options
> that do nonstandard things.
> 
> Alan
> 
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org

-- 
Douglas B. Beattie
------------------
Test Architect - Caldera, Inc.
dbb@caldera.com


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:36:47 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:36:47 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <3C35D707.84E7E9CA@caldera.com> from "Doug Beattie" at Jan 04, 2002 09:23:35 AM
Message-ID: <E16MXKp-0004Za-00@the-village.bc.nu>

> Then, in general the specification should state that any options not
> documented, but found to be present in any command/function, should
> not be used as they will not have been tested and results cannot be
> guaranteed.

The LSB doesn't define what happens when you use a command or library
function that is not in the LSB. If you use glibc internal functions you
will get burned (especially if the folks trying to replace glibc with 
something much lighter actually succeed)


From dbb@caldera.com  Fri Jan  4 16:30:21 2002
From: dbb@caldera.com (Doug Beattie)
Date: Fri, 04 Jan 2002 09:30:21 -0700
Subject: LSB1.1: /proc/cpuinfo
References: <E16MXKp-0004Za-00@the-village.bc.nu>
Message-ID: <3C35D89D.BC2DBF4D@caldera.com>

Alan Cox wrote:
> 
> > Then, in general the specification should state that any options not
> > documented, but found to be present in any command/function, should
> > not be used as they will not have been tested and results cannot be
> > guaranteed.
> 
> The LSB doesn't define what happens when you use a command or library
> function that is not in the LSB. If you use glibc internal functions you
> will get burned (especially if the folks trying to replace glibc with
> something much lighter actually succeed)

So are you saying that we should go through the process of adding
specifics to each command for the next version of the specification so
such problems can be avoided?

What would you recommend?


From anderson@metrolink.com  Fri Jan  4 16:34:01 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 11:34:01 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXAm-0004XZ-00@the-village.bc.nu>
Message-ID: <20020104113135.E616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> > I did read the app notes pertaining to this, and felt that it was an excessive
> > burdon on the application considering the kernel had already done the work.
>
> The things that actually matter are like 10 lines of GNU C with a little
> __asm__ block. The code is out there in GPL form and its shorter than
> parsing /proc

If you are refering to the code in arch/i386/kernel/setup.c, the code that
determines the features is spread over several hundred lines of code which
makes decisions based on model info and various erratta.

If an application included this directly into itself, then it wouldn't be able
to handle new CPU models, erratta, etc. By letting the kernel handle it, it
will always get the best possible info.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From anderson@metrolink.com  Fri Jan  4 16:38:09 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 11:38:09 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXKp-0004Za-00@the-village.bc.nu>
Message-ID: <20020104113642.S616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> The LSB doesn't define what happens when you use a command or library
> function that is not in the LSB. If you use glibc internal functions you
> will get burned (especially if the folks trying to replace glibc with
> something much lighter actually succeed)

>From Chapter 1: Definitions.

Non-LSB-Compliant Application

An application which has been written to include system routines, commands, or
other resources not included in this document, or which has been compiled into
a format different from those specified here, or which does not behave as
specified in this document.



This sort of says it, though in an indirect way.



                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:52:47 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:52:47 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104113135.E616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 11:34:01 AM
Message-ID: <E16MXaJ-0004dv-00@the-village.bc.nu>

> If you are refering to the code in arch/i386/kernel/setup.c, the code that
> determines the features is spread over several hundred lines of code which
> makes decisions based on model info and various erratta.

What do apps actually care about
	-	MMX
	-	Athlon MMX2
	-	SSE
	-	SSE2
and occasionally
	-	CPU vendor
	-	CPU model

Not rocket science


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:54:56 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:54:56 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <3C35D89D.BC2DBF4D@caldera.com> from "Doug Beattie" at Jan 04, 2002 09:30:21 AM
Message-ID: <E16MXcO-0004eo-00@the-village.bc.nu>

> So are you saying that we should go through the process of adding
> specifics to each command for the next version of the specification so
> such problems can be avoided?

We already have the needed specifics I think. If you use options that are
not documented well bad luck. Jeff took the view that we documented too much
and had we been working "from scratch" not "from existing practice" I'd
agree. Certainly we don't want to add documentation of more options unless
we can't avoid it.


From anderson@metrolink.com  Fri Jan  4 16:50:11 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 11:50:11 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXaJ-0004dv-00@the-village.bc.nu>
Message-ID: <20020104114855.X616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> What do apps actually care about
> 	-	MMX
> 	-	Athlon MMX2
> 	-	SSE
> 	-	SSE2

Image manipulation programs need a way to determine the most efficient
algorithm/instructions to use.

> and occasionally
> 	-	CPU vendor
> 	-	CPU model

Probably not as much here, except as how this info may be used to identify
erratta on a feature that is important to the program.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:05:06 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:05:06 +0000 (GMT)
Subject: [New Proposal] cpuinfo, but not directly via /proc
In-Reply-To: <20020104133051.A10241@lst.de> from "Ralf Flaxa" at Jan 04, 2002 01:30:51 PM
Message-ID: <E16MXmE-0004kc-00@the-village.bc.nu>

> 	o number of CPUs

sysconf() - there is a documented interface for this already

> 	o CPU family and type
> 	o BogoMips (per CPU and/or overall)

Bogomips are pretty worthless values

> 2. features specific to a processor
> 	o for x86 e.g. the "flags" and *_bug fields
> 	o info about FPU, MMU and the like

FPU/MMU/cache stuff is one place where not everything can be acquired
trivially - especially non x86

Alan


From mei@asdis.de  Fri Jan  4 16:54:10 2002
From: mei@asdis.de (Bodo Meissner)
Date: Fri, 4 Jan 2002 17:54:10 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>; from anderson@metrolink.com on Don, Jan 03, 2002 at 23:53:38 +0100
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104175410.A3882@natira>

On Tue, 03 Jan 2002 23:53:38 Stuart Anderson wrote:
> Can you please provide some examples? All of the examples I was able to
> aquire
> fit the description (actually, it was written to fit the exmaples 8-)).

SuSE Linux running on S/390 (emulator "hercules"):

hercules%mei ~> uname -a
Linux hercules 2.2.16 #1 SMP Wed May 30 08:45:25 GMT 2001 s390 unknown
hercules%mei ~> cat /proc/cpuinfo
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 86.42
processor 0: version = 00,  identification = 002623,  machine = 3090
processor 1: version = 00,  identification = 102623,  machine = 3090

SuSE Linux (newer version) running on S/390 (real system, don't know exact
type):

asdis@linux0:~ > uname -a
Linux linux0 2.4.7-SuSE-SMP #1 SMP Tue Oct 30 22:39:07 GMT 2001 s390
unknown
asdis@linux0:~ > cat /proc/cpuinfo 
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 411.23
processor 0: version = FF,  identification = 111000,  machine = 7060
processor 1: version = FF,  identification = 111111,  machine = 7060




From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:07:11 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:07:11 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104114855.X616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 11:50:11 AM
Message-ID: <E16MXoF-0004lA-00@the-village.bc.nu>

> > What do apps actually care about
> > 	-	MMX
> > 	-	Athlon MMX2
> > 	-	SSE
> > 	-	SSE2
> 
> Image manipulation programs need a way to determine the most efficient
> algorithm/instructions to use.

Which is down to MMX, MMX2, SSE, SSE2. Take a look at real existing apps
like mplayer, mp1e and xine.

> Probably not as much here, except as how this info may be used to identify
> erratta on a feature that is important to the program.

The x86 CPU errata are kernel handled so Im not sure that is actually an
issue.


From mats.d.wichmann@intel.com  Fri Jan  4 17:00:36 2002
From: mats.d.wichmann@intel.com (Wichmann, Mats D)
Date: Fri, 4 Jan 2002 09:00:36 -0800
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <39B5C4829263D411AA93009027AE9EBB140DA64F@FMSMSX35>

> What do apps actually care about
> 	-	MMX
> 	-	Athlon MMX2
> 	-	SSE
> 	-	SSE2
> and occasionally
> 	-	CPU vendor
> 	-	CPU model
> 
> Not rocket science

And CPU speed, plus #CPUs.

Although it's probably anathema to mention it,
some of these criteria are used to determine
licensing thingies in some circles, as in
"price depends on raw power of the machine".

 


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:17:01 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:17:01 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <39B5C4829263D411AA93009027AE9EBB140DA64F@FMSMSX35> from "Wichmann, Mats D" at Jan 04, 2002 09:00:36 AM
Message-ID: <E16MXxl-0004nU-00@the-village.bc.nu>

> And CPU speed, plus #CPUs.

#CPU's is in sysconf() already. (Yes glibc happens to then go poke in 
/proc at the moment but that doesnt mean we have to assume glibc wont in
the future use a kernel facility thats more convenient. In fact newer
glibcs will probably need updating to get the full benefit of the upcoming
CPU hot plug patches (sysconf in POSIX/SuS already supports asking for
"number of cpus" and "number of cpus online"

> some of these criteria are used to determine
> licensing thingies in some circles, as in
> "price depends on raw power of the machine".

Which has nothing to do with the CPU speed nowdays. A 2GHz PIV is much like
a 1.6GHz Athlon. A 1GHz C3 is much like a 700MHz Celeron. And of course the
ratio is heavily application dependant since the DDR RAM on an Athlon
matters to some apps while the bus bandwidth of the PIV matters to others.

Alan


From anderson@metrolink.com  Fri Jan  4 17:10:59 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 12:10:59 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXoF-0004lA-00@the-village.bc.nu>
Message-ID: <20020104120701.C616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> > > What do apps actually care about
> > > 	-	MMX
> > > 	-	Athlon MMX2
> > > 	-	SSE
> > > 	-	SSE2
> >
> > Image manipulation programs need a way to determine the most efficient
> > algorithm/instructions to use.
>
> Which is down to MMX, MMX2, SSE, SSE2. Take a look at real existing apps
> like mplayer, mp1e and xine.

Are you saying that these are all that is needed, and that this problem has
already been solved?

I've seen comments that indicate that depending on SIGILL and SIGFPE to
determine that something isn't present may not be fool proof. Also, it takes
as much or more code to set up and test this as it would to read /proc/cpuinfo.

> > Probably not as much here, except as how this info may be used to identify
> > erratta on a feature that is important to the program.
>
> The x86 CPU errata are kernel handled so Im not sure that is actually an
> issue.

In setup.c there are several place where feature bits are turned on or off
based model and errata info. Why should this kind of handlig be duplicated?
Also, what about furture situations? There is no gurantee that a future bug
can be handled transparently to the app, and at no performance cost.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:32:31 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:32:31 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104120701.C616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 12:10:59 PM
Message-ID: <E16MYCl-0004qZ-00@the-village.bc.nu>

> > Which is down to MMX, MMX2, SSE, SSE2. Take a look at real existing apps
> > like mplayer, mp1e and xine.
> 
> Are you saying that these are all that is needed, and that this problem has
> already been solved?

I am saying that the existing applications don't show any evidence that
we need to document these and use cpuid quite successfully themselves

> I've seen comments that indicate that depending on SIGILL and SIGFPE to
> determine that something isn't present may not be fool proof. Also, it takes

For x86 SIGILL is safe barring some obscure errata which are not going to
bite anyone in normal use. FPU is always present but may be emulated. You
can again check this with cpuid.

> In setup.c there are several place where feature bits are turned on or off
> based model and errata info. Why should this kind of handlig be duplicated?

It wouldn't be. Applications cannot control those feature flags. 

If the code was complex I would be worry, but it is less code to use
cpuid for things like MMX checking than to go regexping through the /proc
file. It is also very well documented (once you realise Intel try and make
you run the competitors chips as a 486 and the others likewise about
chips that they didnt make)

Alan


From mats.d.wichmann@intel.com  Fri Jan  4 18:10:43 2002
From: mats.d.wichmann@intel.com (Wichmann, Mats D)
Date: Fri, 4 Jan 2002 10:10:43 -0800
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <39B5C4829263D411AA93009027AE9EBB140DA680@FMSMSX35>

> #CPU's is in sysconf() already. (Yes glibc happens to then go poke in 
> /proc at the moment but that doesnt mean we have to assume 
> glibc wont in
> the future use a kernel facility thats more convenient. In fact newer
> glibcs will probably need updating to get the full benefit of 
> the upcoming
> CPU hot plug patches (sysconf in POSIX/SuS already supports asking for
> "number of cpus" and "number of cpus online"

Just curious... is there any mechanism for processor reservation/binding
present or planned?


> > some of these criteria are used to determine
> > licensing thingies in some circles, as in
> > "price depends on raw power of the machine".
> 
> Which has nothing to do with the CPU speed nowdays. A 2GHz 
> PIV is much like
> a 1.6GHz Athlon. A 1GHz C3 is much like a 700MHz Celeron. And 
> of course the
> ratio is heavily application dependant since the DDR RAM on an Athlon
> matters to some apps while the bus bandwidth of the PIV 
> matters to others.

Who ever said irrelevant criteria didn't still matter to people? 

'Far as I can tell, the software industry has been trying to
figure out how to license enterprise-class software for the
whole 21 years I've been in the business and probably a lot
longer, and still don't really have a good model.

Mats


From hpa@zytor.com  Sat Jan  5 02:53:57 2002
From: hpa@zytor.com (H. Peter Anvin)
Date: Fri, 04 Jan 2002 18:53:57 -0800
Subject: LSB1.1: /proc/cpuinfo
References: <E16MX7e-0004WQ-00@the-village.bc.nu> <3C35D707.84E7E9CA@caldera.com>
Message-ID: <3C366AC5.1070607@zytor.com>

Doug Beattie wrote:

> Then, in general the specification should state that any options not
> documented, but found to be present in any command/function, should
> not be used as they will not have been tested and results cannot be
> guaranteed.
> 
> Can we make a blanket statement that will satisfy all such conditions
> so we don't have to go through and document each and every situation
> within the specification?
> 


This is usually handled by invoking the magic phrase "a strictly 
conforming application shall not invoke undefined behaviour."

	-hpa



From alan@lxorguk.ukuu.org.uk  Sat Jan  5 00:32:26 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Sat, 5 Jan 2002 00:32:26 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <39B5C4829263D411AA93009027AE9EBB140DA680@FMSMSX35> from "Wichmann, Mats D" at Jan 04, 2002 10:10:43 AM
Message-ID: <E16Mel8-0006C9-00@the-village.bc.nu>

> > CPU hot plug patches (sysconf in POSIX/SuS already supports asking for
> > "number of cpus" and "number of cpus online"
> 
> Just curious... is there any mechanism for processor reservation/binding
> present or planned?

Open discussion at the moment. The kernel has the hooks. There are arguments
about which scheme to use. The pset one is probably the most standard.

> 'Far as I can tell, the software industry has been trying to
> figure out how to license enterprise-class software for the
> whole 21 years I've been in the business and probably a lot
> longer, and still don't really have a good model.

Fine. But that is their problem 8). VIA already has documentation for
how to check the speed of a CPU. Intel seem to have NDA'd theirs but I'm
sure they can provide that algorithm easily enough.


From hp@redhat.com  Sat Jan  5 18:16:03 2002
From: hp@redhat.com (Havoc Pennington)
Date: 05 Jan 2002 13:16:03 -0500
Subject: bugs just filed
Message-ID: <y5wvgegfyu4.fsf@icon.labs.redhat.com>


Hi,

I'm not normally involved in LSB stuff and haven't followed this list,
but have been writing some docs for Red Hat related to the "Command
Behavior" section and saw the link to the nice review form on Slashdot
yesterday, so just went through the commands section and filed a bunch
of bugs. I know it's annoying to do that mere hours after the
deadline. ;-) As I said, I am clueless LSB-wise. Hopefully the
comments are useful for the next version of the spec.

I filed separate reports for each change but they are mostly in some
major groups:

 - command line options that conflict with SUS in current
   implementations but are not really essential should not be 
   specified. e.g. "df -t" can just be left implementation dependent, 
   there is no reason to force SUS incompliance here, the option 
   isn't exactly a vital feature.
   
   At minimum, annotation should be added that POSIXLY_CORRECT 
   may change the behavior of these options, right?

 - the wording "--foo is not supported" seems to imply that an 
   option must not be supported, though I doubt that was intended.
   I think wording such as "--foo is undefined" or "--foo is
   implementation-dependent" would be better.
 
 - I don't understand why the LSB specifies interactive programs;
   those are not designed to be an ABI/API and are not a reasonable
   ABI/API. For example, I don't see how "su" can be used
   programatically (or if it can, only its noninteractive aspects
   should be described in the spec, IMO).

   Due to internationalization, checks such as isatty(), possible
   UI enhancements that change prompts, etc., interactive 
   command behavior is just not a reasonable thing to rely on.

Something I didn't file bugs on for the most part: in many cases LSB
seems to simply catalog all options in some version of a
utility. Wouldn't it be better to start with SUS options and
conservatively add only some of the really useful extensions, instead
of listing them wholesale?

I did file a bug on one egregious example, "patch --debug" makes no
sense whatsoever as part of an API/ABI spec, IMO. It's not like an ISV
app should or could use that option, so why is it required for LSB
compliance?

Thanks for everyone's hard work.

Havoc



From anderson@metrolink.com  Mon Jan  7 00:02:45 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Sun, 6 Jan 2002 19:02:45 -0500 (EST)
Subject: bugs just filed
In-Reply-To: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
Message-ID: <20020106190216.V422-100000@trantor.sc.metrolink.com>

On 5 Jan 2002, Havoc Pennington wrote:

>
> Hi,
>
> I'm not normally involved in LSB stuff and haven't followed this list,
> but have been writing some docs for Red Hat related to the "Command
> Behavior" section and saw the link to the nice review form on Slashdot
> yesterday, so just went through the commands section and filed a bunch
> of bugs. I know it's annoying to do that mere hours after the
> deadline. ;-) As I said, I am clueless LSB-wise. Hopefully the
> comments are useful for the next version of the spec.

Don't worry about it being as little late. They are still very useful, and
greatly appreciated.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From cyeoh@samba.org  Mon Jan  7 01:34:20 2002
From: cyeoh@samba.org (Christopher Yeoh)
Date: Mon, 7 Jan 2002 12:34:20 +1100
Subject: bugs just filed
In-Reply-To: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
References: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
Message-ID: <15416.64284.803080.568825@gargle.gargle.HOWL>

Havoc Pennington writes:
>  - the wording "--foo is not supported" seems to imply that an 
>    option must not be supported, though I doubt that was intended.
>    I think wording such as "--foo is undefined" or "--foo is
>    implementation-dependent" would be better.

I agree the wording could be clearer.  The above sort of wording is
used where an option for a command is required by the SUS but at the
time of the writing of the specifiction was not supported by the
implementations of that command on Linux. In other words for people
porting to Linux they can't rely on that behaviour even if their app
is SUS compliant.

>  - I don't understand why the LSB specifies interactive programs;
>    those are not designed to be an ABI/API and are not a reasonable
>    ABI/API. For example, I don't see how "su" can be used
>    programatically (or if it can, only its noninteractive aspects
>    should be described in the spec, IMO).

Some interactive programs are useful when developers want to give
users documentation on what to do when some manual configuration or
repairing is required.

> I did file a bug on one egregious example, "patch --debug" makes no
> sense whatsoever as part of an API/ABI spec, IMO. It's not like an ISV
> app should or could use that option, so why is it required for LSB
> compliance?

I agree this option didn't need to have been included. In general I
think that including options beyond what is required by SUS is better
as writing scripts can be a lot easier when you don't have to
constrain yourself to SUS only options. From a distribution
implementation point of view the options that were included with the
commands were a subset that existed on most distributions (except in
cases where implementations of a given command were so different
between distributions that the one that was seen as best was chosen).

Regards,

Chris
-- 
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia


From rusty@rustcorp.com.au  Mon Jan  7 01:05:45 2002
From: rusty@rustcorp.com.au (Rusty Russell)
Date: Mon, 7 Jan 2002 12:05:45 +1100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
References: <20020103190219.B27938@thyrsus.com>
 <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
Message-ID: <20020107120545.57570c8a.rusty@rustcorp.com.au>

On Thu, 3 Jan 2002 19:56:51 -0500 (EST)
Alexander Viro <viro@math.psu.edu> wrote:

> It's more than just a name.
> 	a) granularity.  Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> 	b) tree layout policy (lack thereof, to be precise).
> 	c) horribly bad layout of many, many files.  Any file exported by

As usual, Al has hit the highpoints (five lines vs. >> 1000 msgs of proc
flamewars over time).  At risk of boring regular readers, I shall expand:

There is /proc, and /proc/sys.  /proc is a pain to use in the kernel (seq_*
made this better recently, but far from perfect), but is flexible.
/proc/sys (aka sysctl) is easier to use, but a PITA for dynamic entries.

The "manual formatting" nature of /proc entries has lead to (c) mentioned by
Al.  This can be alleviated by making the simplest method of exporting data
the correct one (ie. more like /proc/sys).

The tree layout issues are more complicated.  In particular, the following
namespaces should be equivalent:
   Boot command line: 3c509.debug=1
   Module parameter: insmod 3c509 debug=1
   proc entry: echo 1 > .../3c509/debug

Finally, I consider the granularity issue a red-herring: if it's in the
kernel, it should be in a logical location.

Now, I have a sample patch for a simple "/proc/sys" replacement which follows
the "one value per file" (similar to the current proc/sys) and
"dynamic is easy" principle (required for widespread use).  I also have
module loader rewrite and boot param unification patches.

	http://www.kernel.org/pub/linux/kernel/people/rusty

Important to realize that we will be stuck with the current interfaces for
another stable kernel version (backwards compatibility is a WIP).

Once Linus accepts general patches again I shall start pushing things to
him.

Hope that helps,
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.


From hpa@zytor.com  Mon Jan  7 17:26:50 2002
From: hpa@zytor.com (H. Peter Anvin)
Date: Mon, 07 Jan 2002 09:26:50 -0800
Subject: LSB1.1: /proc/cpuinfo
References: <E16Mel8-0006C9-00@the-village.bc.nu>
Message-ID: <3C39DA5A.8070102@zytor.com>

Alan Cox wrote:

> 
> Fine. But that is their problem 8). VIA already has documentation for
> how to check the speed of a CPU. Intel seem to have NDA'd theirs but I'm
> sure they can provide that algorithm easily enough.
> 


If with "speed" you mean "frequency" it's trivial to measure using RDTSC.
 This measurement can be done in userspace, and is also exported by the
kernel into /proc/cpuinfo.

	-hpa



From hch@caldera.de  Mon Jan  7 19:59:00 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Mon, 7 Jan 2002 20:59:00 +0100
Subject: Proposal: cpuinfo(1)
Message-ID: <20020107205900.A28710@caldera.de>

[Caldera hat on and switch to constructive mode]

As current /proc/cpuinfo is unportable and thus not suitable for LSB
in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.

Cpuinfo is supposed to allow retrieving a subset of the contents of
the i386 /proc/cpuinfo in a portable way.

Below is my current design in form of a manpage:


cpuinfo(1)              System General Commands Manual              cpuinfo=
(1)

N=08NA=08AM=08ME=08E
     c=08cp=08pu=08ui=08in=08nf=08fo=08o - get information about installed =
CPU(s)

S=08SY=08YN=08NO=08OP=08PS=08SI=08IS=08S
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-b=08b
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-c=08c
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-f=08f
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-n=08n
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-p=08p

D=08DE=08ES=08SC=08CR=08RI=08IP=08PT=08TI=08IO=08ON=08N
     c=08cp=08pu=08ui=08in=08nf=08fo=08o is used to retreive information ab=
out the processor installed in
     the currently running system.  supports the following options:

     -=08-b=08b      Report the sum of the bogo-mips values of all online p=
rocessors.

     -=08-c=08c      Report cache-size of the biggest CPU-controlled hardwa=
re cache.

     -=08-f=08f      Report CPU features that are supported by all online p=
rocessors.
             For each CPU feature a word with up to ten characters is outpu=
t,
             a whitespace is used as separator.  The values are architectur=
e-
             dependand.

     -=08-n=08n      Report number of online processors.

     -=08-p=08p      Report CPU types of all online processors.  For each C=
PU one
             there is one line of output, containing the free-formed string
             reported by the hardware/firmware.

     If c=08cp=08pu=08ui=08in=08nf=08fo=08o is unable to determine the want=
ed information it returns the
     sring "unknown".

S=08ST=08TA=08AN=08ND=08DA=08AR=08RD=08DS=08S
     LSB 1.1

B=08BU=08UG=08GS=08S
     Due to incoherent underlying interfaces c=08cp=08pu=08ui=08in=08nf=08f=
o=08o might give inaccurate
     results on some kernel versions or architectures.

S=08SE=08EE=08E A=08AL=08LS=08SO=08O
     uname(1), proc(5)

LSB 1.1                        January 04, 2002                        LSB =
1.1


From wichert@wiggy.net  Mon Jan  7 21:00:56 2002
From: wichert@wiggy.net (Wichert Akkerman)
Date: Mon, 7 Jan 2002 22:00:56 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107205900.A28710@caldera.de>
References: <20020107205900.A28710@caldera.de>
Message-ID: <20020107210055.GA14287@wiggy.net>

Previously Christoph Hellwig wrote:
>      -=08-b=08b      Report the sum of the bogo-mips values of all online=
 processors.

Having them individually would be useful as well I guess. I suspect
they are not guaranteerd the same for all processors in a multiprocessor
machine.

>      -=08-c=08c      Report cache-size of the biggest CPU-controlled hard=
ware cache.

Is this useful?=20

>      If c=08cp=08pu=08ui=08in=08nf=08fo=08o is unable to determine the wa=
nted information it returns the
>      sring "unknown".

sring -> string

Having a subarchitecture might also be useful. Consider the multiple
types of m68k machines for example. This information can be gotten
from either /proc/hardware or /proc/cpuinfo depending on the
architecture.

Wichert.
--=20
  _________________________________________________________________
 /wichert@wiggy.net         This space intentionally left occupied \
| wichert@deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


From mstone@cs.loyola.edu  Mon Jan  7 21:23:20 2002
From: mstone@cs.loyola.edu (Michael Stone)
Date: Mon, 7 Jan 2002 16:23:20 -0500
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107210055.GA14287@wiggy.net>; from wichert@wiggy.net on Mon, Jan 07, 2002 at 10:00:56PM +0100
References: <20020107205900.A28710@caldera.de> <20020107210055.GA14287@wiggy.net>
Message-ID: <20020107162320.A31771@justice.loyola.edu>

On Mon, Jan 07, 2002 at 10:00:56PM +0100, Wichert Akkerman wrote:
> Previously Christoph Hellwig wrote:
> >      -=08-b=08b      Report the sum of the bogo-mips values of all onli=
ne processors.
>=20
> Having them individually would be useful as well I guess. I suspect
> they are not guaranteerd the same for all processors in a multiprocessor
> machine.
>=20
> >      -=08-c=08c      Report cache-size of the biggest CPU-controlled ha=
rdware cache.
>=20
> Is this useful?=20

You asked if that was useful but didn't ask if reporting bogomips was
useful?

--=20
Mike Stone


From alan@lxorguk.ukuu.org.uk  Tue Jan  8 13:57:33 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue, 8 Jan 2002 13:57:33 +0000 (GMT)
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107205900.A28710@caldera.de> from "Christoph Hellwig" at Jan 07, 2002 08:59:00 PM
Message-ID: <E16Nwkv-0006TW-00@the-village.bc.nu>

> As current /proc/cpuinfo is unportable and thus not suitable for LSB
> in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> 
> Cpuinfo is supposed to allow retrieving a subset of the contents of
> the i386 /proc/cpuinfo in a portable way.

I think thats an excellent idea.

> 


From gk4@austin.ibm.com  Tue Jan  8 14:30:06 2002
From: gk4@austin.ibm.com (George Kraft IV)
Date: Tue, 08 Jan 2002 08:30:06 -0600
Subject: gLSB and psLSB review extended until Monday January 14th, 2002
Message-ID: <3C3B026E.2DFF04E3@austin.ibm.com>

This is a multi-part message in MIME format.
--------------EF2ABF44D87F2E7DD3C21927
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The LSB delivers again, the LSB has updated and published the gLSB v1.1 draft
for review. The LSB has also published for review the new psLSB for IA32 v1.1
draft and the completed LSB v1.0.1 Test Suites.  Review has been extended to
Monday January 14th, 2002; however, the LSB welcomes comments from the
community at any time.

-- 
George Kraft IV
gk4@austin.ibm.com
--------------EF2ABF44D87F2E7DD3C21927
Content-Type: text/html; charset=us-ascii;
 name="gLSB.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="gLSB.html"

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i686) [Netscape]">
   <title>LSB Delivers Again</title>
</head>
<body>
The LSB delivers again, the LSB has updated and published
the <a href="http://www.linuxbase.org/spec/lsbreview.html">gLSB v1.1 draft</a>
for review. The LSB has also published for review the new
<a href="http://www.linuxbase.org/spec/lsbia32review.html">psLSB
for IA32 v1.1 draft</a> and the completed
<a href="ftp://ftp.freestandards.org/pub/lsb/test_suites/released-1.0.1/">LSB
v1.0.1 Test Suites</a>.&nbsp; Review has been extended to Monday January
14th, 2002; however, the LSB welcomes comments from the community at any
time."
<p>George (gk4)
</body>
</html>

--------------EF2ABF44D87F2E7DD3C21927--


From hp@redhat.com  Tue Jan  8 22:36:14 2002
From: hp@redhat.com (Havoc Pennington)
Date: 08 Jan 2002 17:36:14 -0500
Subject: bugs just filed
In-Reply-To: <15416.64284.803080.568825@gargle.gargle.HOWL>
References: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
 <15416.64284.803080.568825@gargle.gargle.HOWL>
Message-ID: <y5wn0zoii75.fsf@icon.labs.redhat.com>


Christopher Yeoh <cyeoh@samba.org> writes: 
> >  - I don't understand why the LSB specifies interactive programs;
> >    those are not designed to be an ABI/API and are not a reasonable
> >    ABI/API. For example, I don't see how "su" can be used
> >    programatically (or if it can, only its noninteractive aspects
> >    should be described in the spec, IMO).
> 
> Some interactive programs are useful when developers want to give
> users documentation on what to do when some manual configuration or
> repairing is required.

That makes sense, but perhaps the spec should make a point of saying
that only the existence of the command and its general behavior are
guaranteed - that its prompts and such may change. It worries me a
bit that developers may be misled into thinking that su or passwd or
whatever have a fixed ABI.
 
> I agree this option didn't need to have been included. In general I
> think that including options beyond what is required by SUS is better
> as writing scripts can be a lot easier when you don't have to
> constrain yourself to SUS only options. From a distribution
> implementation point of view the options that were included with the
> commands were a subset that existed on most distributions (except in
> cases where implementations of a given command were so different
> between distributions that the one that was seen as best was chosen).

I'd agree that useful extensions to the SUS make sense. I don't see
including extensions that are clearly silly like --debug, or those
that are not especially useful and conflict with (vs. extend) the SUS,
though, such as df -t. Just adding a note that POSIXLY_CORRECT may
change behavior is a possible compromise here.

As currently written, I don't think it's possible to be both SUS and
LSB compliant, and that's kind of an unfortunate limitation for
Linux. I didn't see any cases in the "commands" section where the
SUS/LSB conflict was really compellingly worth having.

Havoc


From cyeoh@samba.org  Wed Jan  9 02:53:07 2002
From: cyeoh@samba.org (Christopher Yeoh)
Date: Wed, 9 Jan 2002 13:53:07 +1100
Subject: bugs just filed
In-Reply-To: <y5wn0zoii75.fsf@icon.labs.redhat.com>
References: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
 <15416.64284.803080.568825@gargle.gargle.HOWL>
 <y5wn0zoii75.fsf@icon.labs.redhat.com>
Message-ID: <15419.45203.341095.51462@gargle.gargle.HOWL>

Havoc Pennington writes:
> 
> That makes sense, but perhaps the spec should make a point of saying
> that only the existence of the command and its general behavior are
> guaranteed - that its prompts and such may change. It worries me a
> bit that developers may be misled into thinking that su or passwd or
> whatever have a fixed ABI.

Sure, and this is also true for non-interactive commands. If the
output format is not defined, then relying on it staying the same is
dangerous.

> I'd agree that useful extensions to the SUS make sense. I don't see
> including extensions that are clearly silly like --debug, or those
> that are not especially useful and conflict with (vs. extend) the SUS,
> though, such as df -t. Just adding a note that POSIXLY_CORRECT may
> change behavior is a possible compromise here.

In the case of "df -t" I would suggest that the -t option be stated as
undefined behaviour, but --type preserved so the functionality is
still available. Its a bit trickier where the functionality is only
available through an option which would conflict with SUS. Longer term
we should speak with the maintainer of the command(s) in question.

Regards,

Chris
-- 
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia


From hch@caldera.de  Wed Jan  9 20:50:45 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Wed, 9 Jan 2002 21:50:45 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <E16Nwkv-0006TW-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Tue, Jan 08, 2002 at 01:57:33PM +0000
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu>
Message-ID: <20020109215045.A11217@caldera.de>

On Tue, Jan 08, 2002 at 01:57:33PM +0000, Alan Cox wrote:
> > As current /proc/cpuinfo is unportable and thus not suitable for LSB
> > in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> > 
> > Cpuinfo is supposed to allow retrieving a subset of the contents of
> > the i386 /proc/cpuinfo in a portable way.
> 
> I think thats an excellent idea.

The first release of cpuinfo(1), which is still i386-only can be found
at:

	http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz

Please give me feedback (and/or patches) for this version if possible.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From gk4@austin.ibm.com  Wed Jan  9 22:39:05 2002
From: gk4@austin.ibm.com (George Kraft IV)
Date: Wed, 09 Jan 2002 16:39:05 -0600
Subject: Proposal: cpuinfo(1)
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de>
Message-ID: <3C3CC689.9D7D439C@austin.ibm.com>

Christoph Hellwig wrote:
> 
> On Tue, Jan 08, 2002 at 01:57:33PM +0000, Alan Cox wrote:
> > > As current /proc/cpuinfo is unportable and thus not suitable for LSB
> > > in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> > >
> > > Cpuinfo is supposed to allow retrieving a subset of the contents of
> > > the i386 /proc/cpuinfo in a portable way.
> >
> > I think thats an excellent idea.
> 
> The first release of cpuinfo(1), which is still i386-only can be found
> at:
> 
>         http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz
> 
> Please give me feedback (and/or patches) for this version if possible.
> 
>         Christoph
> 

Per the LSB forums, the FSG board, and the LSB core team, the /proc/cpuinfo will
be removed from gLSB v1.1.0.   The LSB core team would like to wait for an
established solution (meaning we need to get cpuinfo(1) in the distros).

Thanks Christoph for the cpuinfo(1) command!

I would like to thank everyone who helped with this gLSB issue.

Cheers,

-- 
George Kraft IV
gk4@austin.ibm.com


From srivasta@acm.org  Thu Jan 10 23:29:51 2002
From: srivasta@acm.org (Manoj Srivastava)
Date: Thu, 10 Jan 2002 17:29:51 -0600
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020109215045.A11217@caldera.de> (Christoph Hellwig's message
 of "Wed, 9 Jan 2002 21:50:45 +0100")
References: <20020107205900.A28710@caldera.de>
 <E16Nwkv-0006TW-00@the-village.bc.nu>
 <20020109215045.A11217@caldera.de>
Message-ID: <87wuypg4y8.fsf@glaurung.green-gryphon.com>

Hi,

	First, a nit:
======================================================================
static void
grep_cputypes(const char *prefix, int len)
======================================================================

Should be
======================================================================
static void
grep_cputypes(const char *prefix, size_t len)
======================================================================

	Just a nit, but it silences the warning:
======================================================================
cc -ansi -pedantic -Wall -W -Wtraditional -Wconversion -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fshort-enums -fno-common -Dgets=DONT_USE_GETS -Dlint -Woverloaded-virtual -Wnested-externs -Winline -O2 -D_XOPEN_SOURCE=600   -c -o arch_i386.o arch_i386.c
arch_i386.c: In function `grep_cputypes':
arch_i386.c:23: warning: passing arg 3 of `strncmp' as unsigned due to prototype
======================================================================

	Secondly, why are you passing the length explicitly in the
 call to grep_cputypes? The following implementation removes the
 requirement (and I often miscount, in my old age.
======================================================================
static void
grep_cputypes(const char *prefix)
{
        FILE *f;
        char buf[LINE_MAX];
        int n = 0;

        f = fopen(_PATH_CPUINFO, "r");
        if (f) {
                while (fgets(buf, sizeof(buf), f)) {
                        if (!strncmp(buf, prefix, strlen(prefix))) {
                                printf("cpu%d: %s", n++, (buf+len+3));
                        }
                }
                fclose(f);
        }
        if (!n) {
                printf("unknown\n");
        }
}
======================================================================


	Am I missing a reason to allow the caller to specify a subset
 of the prefix as relevant for comparison?

	manoj
        
-- 
 You should never wear your best trousers when you go out to fight for
 freedom and liberty. Henrik Ibsen
Manoj Srivastava   <srivasta@acm.org>  <http://www.datasync.com/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


From jockgrrl@austin.rr.com  Fri Jan 11 06:30:18 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Fri, 11 Jan 2002 00:30:18 -0600
Subject: Proposal: cpuinfo(1)
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de>
Message-ID: <3C3E867A.13070FBE@austin.rr.com>

Christoph Hellwig wrote:
> 
> On Tue, Jan 08, 2002 at 01:57:33PM +0000, Alan Cox wrote:
> > > As current /proc/cpuinfo is unportable and thus not suitable for LSB
> > > in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> > >
> > > Cpuinfo is supposed to allow retrieving a subset of the contents of
> > > the i386 /proc/cpuinfo in a portable way.
> >
> > I think thats an excellent idea.
> 
> The first release of cpuinfo(1), which is still i386-only can be found
> at:
> 
>         http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz
> 
> Please give me feedback (and/or patches) for this version if possible.

The first thing I noticed is that only one flag at a time is
allowed, so I can't go "cpuinfo -bp" and get my BogoMips and
CPU names at the same time.

The usage message is "cpuinfo [ -bcfnp ]" which implies I can
mix and match flags.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From schilling@fokus.gmd.de  Fri Jan 11 12:25:32 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 11 Jan 2002 13:25:32 +0100 (MET)
Subject: Proposal: cpuinfo(1)
Message-ID: <200201111225.g0BCPWY04972@burner.fokus.gmd.de>


>> The first release of cpuinfo(1), which is still i386-only can be found
>> at:
>> 
>>         http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz
>> 
>> Please give me feedback (and/or patches) for this version if possible.

Is there any reason why the man page does not use standard "man" troff
macros?



J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From hch@caldera.de  Fri Jan 11 16:14:38 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 11 Jan 2002 17:14:38 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <87wuypg4y8.fsf@glaurung.green-gryphon.com>; from srivasta@acm.org on Thu, Jan 10, 2002 at 05:29:51PM -0600
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de> <87wuypg4y8.fsf@glaurung.green-gryphon.com>
Message-ID: <20020111171438.A21023@caldera.de>

On Thu, Jan 10, 2002 at 05:29:51PM -0600, Manoj Srivastava wrote:
> Hi,
> 
> 	First, a nit:
> ======================================================================
> static void
> grep_cputypes(const char *prefix, int len)
> ======================================================================
> 
> Should be
> ======================================================================
> static void
> grep_cputypes(const char *prefix, size_t len)
> ======================================================================
> 
> 	Just a nit, but it silences the warning:

I did that first but then reversed it.
Ok, back to the initial version, thanks for spotting it.

> 	Secondly, why are you passing the length explicitly in the
>  call to grep_cputypes? The following implementation removes the
>  requirement (and I often miscount, in my old age.

Expclicitly passing it gives a const expression, but if counting
is a problem (:)) I can change it - cpuinfo should really be used in
any fastpath..

> 	Am I missing a reason to allow the caller to specify a subset
>  of the prefix as relevant for comparison?

No - at least that was not intended.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From hch@caldera.de  Fri Jan 11 16:15:21 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 11 Jan 2002 17:15:21 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <3C3E867A.13070FBE@austin.rr.com>; from jockgrrl@austin.rr.com on Fri, Jan 11, 2002 at 12:30:18AM -0600
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de> <3C3E867A.13070FBE@austin.rr.com>
Message-ID: <20020111171521.B21023@caldera.de>

On Fri, Jan 11, 2002 at 12:30:18AM -0600, Julie wrote:
> The first thing I noticed is that only one flag at a time is
> allowed, so I can't go "cpuinfo -bp" and get my BogoMips and
> CPU names at the same time.
> 
> The usage message is "cpuinfo [ -bcfnp ]" which implies I can
> mix and match flags.

Okay, I'll fix the usage info for 0.2.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From hch@caldera.de  Fri Jan 11 16:15:57 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 11 Jan 2002 17:15:57 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <200201111225.g0BCPWY04972@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 11, 2002 at 01:25:32PM +0100
References: <200201111225.g0BCPWY04972@burner.fokus.gmd.de>
Message-ID: <20020111171557.C21023@caldera.de>

On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> Is there any reason why the man page does not use standard "man" troff
> macros?

They use standard mdoc macros.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From jockgrrl@austin.rr.com  Sat Jan 12 01:48:57 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Fri, 11 Jan 2002 19:48:57 -0600
Subject: Proposal: cpuinfo(1)
References: <200201111225.g0BCPWY04972@burner.fokus.gmd.de> <20020111171557.C21023@caldera.de>
Message-ID: <3C3F9609.916B46FB@austin.rr.com>

Christoph Hellwig wrote:
> 
> On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> > Is there any reason why the man page does not use standard "man" troff
> > macros?
> 
> They use standard mdoc macros.

Which aren't standard "man" macros.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From hch@caldera.de  Sat Jan 12 13:19:12 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Sat, 12 Jan 2002 14:19:12 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <3C3F9609.916B46FB@austin.rr.com>; from jockgrrl@austin.rr.com on Fri, Jan 11, 2002 at 07:48:57PM -0600
References: <200201111225.g0BCPWY04972@burner.fokus.gmd.de> <20020111171557.C21023@caldera.de> <3C3F9609.916B46FB@austin.rr.com>
Message-ID: <20020112141912.A27136@caldera.de>

On Fri, Jan 11, 2002 at 07:48:57PM -0600, Julie wrote:
> > On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> > > Is there any reason why the man page does not use standard "man" troff
> > > macros?
> > 
> > They use standard mdoc macros.
> 
> Which aren't standard "man" macros.

They are (since 4.4BSD).

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From schilling@fokus.gmd.de  Sat Jan 12 13:32:08 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Sat, 12 Jan 2002 14:32:08 +0100 (MET)
Subject: Proposal: cpuinfo(1)
Message-ID: <200201121332.g0CDW8D05546@burner.fokus.gmd.de>

>From: Christoph Hellwig <hch@caldera.de>

>On Fri, Jan 11, 2002 at 07:48:57PM -0600, Julie wrote:
>> > On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
>> > > Is there any reason why the man page does not use standard "man" troff
>> > > macros?
>> > 
>> > They use standard mdoc macros.
>> 
>> Which aren't standard "man" macros.

>They are (since 4.4BSD).

They are a proprietary 4.4BSD format. 

As your program is completely nonportable it makes no difference....
but if you are going to write a portable program it is a really bad
idea to use them as are not present on a typical UNIX system.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From jockgrrl@austin.rr.com  Sat Jan 12 13:40:28 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Sat, 12 Jan 2002 07:40:28 -0600
Subject: Proposal: cpuinfo(1)
References: <200201121332.g0CDW8D05546@burner.fokus.gmd.de>
Message-ID: <3C403CCC.E53CF1C3@austin.rr.com>

Joerg Schilling wrote:
> 
> >From: Christoph Hellwig <hch@caldera.de>
> 
> >On Fri, Jan 11, 2002 at 07:48:57PM -0600, Julie wrote:
> >> > On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> >> > > Is there any reason why the man page does not use standard "man" troff
> >> > > macros?
> >> >
> >> > They use standard mdoc macros.
> >>
> >> Which aren't standard "man" macros.
> 
> >They are (since 4.4BSD).
> 
> They are a proprietary 4.4BSD format.
> 
> As your program is completely nonportable it makes no difference....
> but if you are going to write a portable program it is a really bad
> idea to use them as are not present on a typical UNIX system.

It would also be nice if they used the format of the operating
system currently under discussion.

Hint: It isn't 4.4BSD.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From hch@caldera.de  Sat Jan 12 13:50:45 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Sat, 12 Jan 2002 14:50:45 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <3C403CCC.E53CF1C3@austin.rr.com>; from jockgrrl@austin.rr.com on Sat, Jan 12, 2002 at 07:40:28AM -0600
References: <200201121332.g0CDW8D05546@burner.fokus.gmd.de> <3C403CCC.E53CF1C3@austin.rr.com>
Message-ID: <20020112145045.A28624@caldera.de>

On Sat, Jan 12, 2002 at 07:40:28AM -0600, Julie wrote:
> It would also be nice if they used the format of the operating
> system currently under discussion.
> 
> Hint: It isn't 4.4BSD.

Groff which is used for *roff formating on usual Linux systems
has -mdoc support since 1991 and I don't remember any version
of man(1) on Linux that didn't support it.

Please browse you /usr/share/man/ directory and see how many
mdoc users already are an your system.

If you have nothing to worry about I'm happy to include your
cpuinfo manpage rewrittem using -man macros.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From jockgrrl@austin.rr.com  Sat Jan 12 14:22:50 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Sat, 12 Jan 2002 08:22:50 -0600
Subject: Proposal: cpuinfo(1)
References: <200201121332.g0CDW8D05546@burner.fokus.gmd.de> <3C403CCC.E53CF1C3@austin.rr.com> <20020112145045.A28624@caldera.de>
Message-ID: <3C4046BA.C863541A@austin.rr.com>

Christoph Hellwig wrote:
> 
> On Sat, Jan 12, 2002 at 07:40:28AM -0600, Julie wrote:
> > It would also be nice if they used the format of the operating
> > system currently under discussion.
> >
> > Hint: It isn't 4.4BSD.
> 
> Groff which is used for *roff formating on usual Linux systems
> has -mdoc support since 1991 and I don't remember any version
> of man(1) on Linux that didn't support it.

Thanks.  Yes, that does work.  I guess I'm really starting
to show how old and moldy I've become ...
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From BudgetLife4@eudoramail.com  Sun Jan 13 16:34:04 2002
From: BudgetLife4@eudoramail.com (BudgetLife4@eudoramail.com)
Date: Sat, 12 Jan 2002 22:34:04 -1800
Subject: Are You Paying too Much for Life Insurance?             RYPP
Message-ID: <00002a5d4f21$00007f86$00003da7@mx1.eudoramail.com>

<html><body><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:center>M=
ost likely, <b>YES <span style=3Dfont-size:14.0pt;mso-bidi-font-size:12.0p=
t>!<o:p></o:p></span></b><o:p></o:p></p><p class=3DMsoNormal align=3Dcente=
r style=3Dtext-align:center>Here's why.<span style=3D"mso-spacerun: yes">&=
nbsp; </span><b><span style=3Dcolor:#FF3300>F</span><span style=3Dcolor:#F=
F9900>i</span><span style=3Dcolor:#FF3300>e</span><span style=3Dcolor:#FF9=
900>r</span><span style=3Dcolor:#FF3300>c</span><span style=3Dcolor:#FF990=
0>e</span></b> ... take no prisoner ... insurance industry <b><span style=3D=
color:red>PRICE WARS</span></b> have driven premiums <b><span style=3Dfont=
-size:14.0pt;mso-bidi-font-size:12.0pt;color:#003300>DOWN</span></b>, and =
<b>down</b>, and <b><span style=3Dfont-size:10.0pt;mso-bidi-font-size:12.0=
pt>down</span></b> --30 -- 40 -- 50 -- even <b><span style=3D"font-size:14=
0pt;mso-bidi-font-size:
12.0pt">70%</span></b> from where they were just a short time ago!<o:p></o=
:p></p><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:center><b><s=
pan style=3Dcolor:#9900CC>YOUR INSURANCE COMPANY </span><span style=3Dcolo=
r:#FF3300>DOESN'T </span><span style=3Dcolor:#9900CC>WANT YOU TO READ THIS=
</span><span style=3Dfont-size:18.0pt;mso-bidi-font-size:12.0pt>...</span>=
<o:p></o:p></b><o:p></o:p></p><p class=3DMsoNormal align=3Dcenter style=3D=
text-align:center>They will <b><span style=3Dcolor:#009900>continue </span=
></b>to <b><span style=3Dcolor:#009900>take your money</span></b>, while o=
ffering lower rates (up to 50%, even 70% lower) to <b><span style=3Dcolor:=
black>new</span></b> buyers.<o:p></o:p></p><p class=3DMsoNormal align=3Dce=
nter style=3Dtext-align:center><b><span style=3Dfont-size:14.0pt;mso-bidi-=
font-size:12.0pt;color:black>B</span></b>UT DON'T TAKE OUR WORD FOR IT<b><=
span style=3D"font-size:16.0pt;mso-bidi-font-size:
12.0pt">...</span></b> <b><span style=3D"font-size:14.0pt;mso-bidi-font-si=
ze:
12.0pt">Visit<o:p></o:p></span></b><o:p></o:p></p><p class=3DMsoNormal ali=
gn=3Dcenter style=3Dtext-align:center><b><span style=3Dfont-size:14.0pt;ms=
o-bidi-font-size:12.0pt;color:blue><p><center><a href=3Dhttp://www.lifeins=
urance.net.cn/email>http://www.lifeinsurance.net.cn/email/</a></p><o:p></o=
:p></span></b><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:cente=
r>and request an online quote today.<span style=3D"mso-spacerun: yes">&nbs=
p; </span>Be prepared to be surprised by how <b><span style=3Dcolor:#00990=
0>cheaply</span></b> you can buy <b><span style=3Dcolor:#009900>large</spa=
n></b> amounts of term life insurance!</p><p class=3DMsoNormal align=3Dcen=
ter style=3Dtext-align:center>&nbsp;</p><p class=3DMsoNormal align=3Dcente=
r style=3Dtext-align:center>If you think, that you will not benefit from t=
his correspondence, please reply with =FFFFFF93remove key=FFFFFF94 as the =
subject matter.</p><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:=
center>&nbsp;<o:p></o:p></p></body></html>




From hp@redhat.com  Mon Jan 14 21:27:55 2002
From: hp@redhat.com (Havoc Pennington)
Date: 14 Jan 2002 16:27:55 -0500
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107205900.A28710@caldera.de>
References: <20020107205900.A28710@caldera.de>
Message-ID: <y5wn0zghbc4.fsf@icon.labs.redhat.com>


Hi,

Instead of creating a new cpuinfo command, why not just specify
getconf, e.g. on my machine:

  $ getconf _NPROCESSORS_CONF
  2
  $ getconf _NPROCESSORS_ONLN
  2

Havoc


From xyl@xyl.com  Tue Jan 22 10:31:51 2002
From: xyl@xyl.com (iceshow)
Date: Tue, 22 Jan 2002 18:31:51 +0800
Subject: =?GB2312?B?1rvT0LPJuabDu9PQyqew3A==?=
Message-ID: <GV2EfD.A.UPF.A_TT8@murphy>



lsb-spec:您好!
<html>

<head>
<meta http-equiv="Content-Language" content="zh-cn">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>新建网页 1</title>
</head>

<body bgcolor="#FF9933" topmargin="0" leftmargin="0">

<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber1">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p align="center">
    <img border="0" src="http://518.shareyou.net/images/yearpic1.jpg" width="139" height="107">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    <img border="0" src="http://518.shareyou.net/images/yearpic2.jpg" width="136" height="106"><font face="华文彩云" size="7"><br>
    欢迎加入<font color="#FF0000">新盈利</font>商务信息网络</font></p>
    <p align="center"><a href="http://www.xinyingli.com/zhuce.php?mid=iceshow">
    <font color="#FF0000">》》》》在此加入《《《《</font></a></p>
    <table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber2">
      <tr>
        <td width="100%" align="center" style="border-style: none; border-width: medium">
        <p class="p4" align="left" style="line-height: 150%">&nbsp;&nbsp;&nbsp; 
        亲爱的朋友：互联网的春天来了，改变一生的命运从此开始，我们的系统决定你只有成功没有失败。就从<font color="#FF0000">110</font>元起步你将迈向富翁的行列。用<font 
color="#FF0000">110</font>元钱换几包已知的香烟和用<font color="#FF0000">110</font>元去搏一个未知的百万富翁，你如何选择？是贤是愚立见分晓。牌局中不知豪爽地送出多少
<font color="#FF0000">110</font>元,用它换来一条致富之路不是更好吗。请相信互联网是创造奇迹的地方，成功只青睐有胆有识的人。成功人士从也不会拖延一分钟，快把握先机，抢占
制高点。心动不如行动，行动才能梦想成真！错过季节，秋天收获什么？</td>
      </tr>
    </table>
    </td>
  </tr>
</table>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 7" bordercolor="#111111" width="100%" id="AutoNumber3" 
bordercolordark="#000000" bordercolorlight="#C0C0C0">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p align="center"><a href="http://www.xinyingli.com/zhuce.php?mid=iceshow">
    <img border="0" src="http://518.shareyou.net/images/banner.gif" width="100%" height="102"></a></td>
  </tr>
</table>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber4">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p style="line-height: 150%"><br>
&nbsp;&nbsp;&nbsp; 朋友，请不要在犹豫，我<a href="http://www.xinyingli.com/zhuce.php?mid=iceshow">加入</a>了，我赚了钱，这实在是一个很好的机会。也许你看过很多类似推
广的信件，你会觉得这是垃圾邮件，那么你就误会了。这是一个绝对真实的会让你赚到巨大财富的网络营销计划。我之所以会象你来推荐，那是因为你跟我一样的明白，天下没有免费的午
餐，是的，互联网也没有免费的钞票让你来捡，那么加入我们的营销网络，你需要付出的仅仅是<font color="#FF0000">110</font>元的代价，也正是因为你付出了，就会象我和我的朋友
一样获得更大的回报。想想看，为什么有这么多被你称为“垃圾邮件”的推广信会来到你的面前，其实也正是因为有那么多朋友明智的选择了我们的营销计划的结果，他们加入进来，他们
同样的也只是付出了仅仅<font color="#FF0000">110</font>元的成本，但是现在已经有人在开心的体会成功所带来的愉悦了。好了，我不再罗嗦了，怎么样<a 
href="http://www.xinyingli.com/?mid=iceshow">到我的网站去看看吧&gt;&gt;&gt;&gt;&gt;&gt;</a></td>
  </tr>
</table>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber5">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p align="center"><font face="宋体" size="6">
    <a href="http://www.xinyingli.com/?mid=iceshow"><font color="#000000">
    欢迎加入新盈利商务信息网络</font></a></font></td>
  </tr>
  <tr>
    <td width="100%" style="border-left: medium none #111111; border-right: medium none #111111; border-top-style: none; border-top-width: medium; border-bottom-
style: none; border-bottom-width: medium">
    <p align="center"><a href="http://www.19.com.cn/click.asp?id=16647">
    <img border="0" src="http://www.softreg.com/baimages/18848.gif" width="468" height="60"></a></p>
    <p align="center">　</p>
    <p align="center">
    <a href="http://www.softreg.com/shareware_view.asp?id={80A6A87D-FC7A-40EE-BA14-37EED522FF06}&sysopid=16647">
    <font color="#000000">本信息由《亿虎Email邮差 v2002b》全力发送<br>
    <br>
    亿虎邮差，你网络营销的最佳助手。立即注册购买获得《亿虎Email邮差 v2002b》<br>
    <br>
    无需smtp服务器，第一时间到达客户邮箱</font></a></p>
    <p align="center">　</p>
    <p align="center">　</td>
  </tr>
</table>

</body>

</html>
    


　　　　　　　　致
礼!
  　　　　　　　　　　　　　　 iceshow
  　　　　　　　　　　　　　　 xyl@xyl.com
  　　　　　　　　　　　　　　 2002-22-01


From Viagra9009@eudoramail.com  Thu Jan 31 21:12:42 2002
From: Viagra9009@eudoramail.com (Viagra9009@eudoramail.com)
Date: Thu, 31 Jan 2002 03:12:42 -1800
Subject: Valentine Must: Viagra Orders Made Easy                   PN
Message-ID: <000040765449$0000117a$00001175@mx2.eudoramail.com>

<html><head><meta http-equiv=3DContent-Language content=3Den-us><meta http-=
equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1252"><title>=
Orders Today will be Shipped Tomorrow</title></head><body><font face=3DAri=
al size=3D2><table cellSpacing=3D0 cellPadding=3D1 width=3D500 align=3Dcen=
ter bgColor=3D#ffffff border=3D0><tr><td vAlign=3Dtop align=3Dmiddle><tabl=
e borderColor=3D#ffffff cellSpacing=3D0 borderColorDark=3D#ffffff cellPadd=
ing=3D0 width=3D100% bgColor=3D#ffffff borderColorLight=3D#ffffff border=3D=
0><tr><td vAlign=3Dtop bgColor=3D#ffffff><center><p><br> <font color=3D#00=
00ff size=3D2><a href=3Dhttp://216.240.159.59/?iAffiliateID=3D20043 target=
=3D_blank><font color=3D#0000ff><img style=3D"width: 500px; height: 315px"=
 alt hspace=3D0 src=3Dhttp://216.240.159.59/em/image/promo/vm.jpeg border=3D=
0 NOSEND=3D1></font>&nbsp;</a></font></p></center></td></tr><tr><td align=3D=
middle bgColor=3D#ffffff><ul><ul><li><div align=3Dleft><font face=3DVerdan=
a><b><font color=3D#ff0000>Orders</font> Today will be Shipped Tomorrow</b=
></font></div></li><li><div align=3Dleft><font face=3DVerdana><font color=3D=
#ff0000><b>No <font color=3D#000000>Prescription Necessary</font></b></fon=
t></font></div></li><li><div align=3Dleft><font face=3DVerdana><b><font co=
lor=3D#ff0000>U.<font color=3D#0000ff>S. </font><font color=3D#000000>Doct=
ors and Pharmacy&nbsp;</font></font><font color=3D#000000>available for co=
nsultation</font></b></font></div></li><li><div align=3Dleft><font face=3D=
Verdana><b><font color=3D#ff0000>All </font>orders shipped <font color=3D#=
000080>Fed</font> <font color=3D#ff0000>Ex</font> Overnight</b></font></di=
v></li></ul></ul><div><font color=3D#ff0000 face=3DVerdana size=3D4><b><a =
target=3D_blank href=3Dhttp://216.240.159.59/?iAffiliateID=3D20043>Click H=
ere and Order Online Today!!!</a></b></font></div></td></tr><tr><td vAlign=
=3Dtop align=3Dmiddle><div><br> &nbsp;</div><div>&nbsp;</div><div>&nbsp;</=
div><div>&nbsp;</div><div><font size=3D2>To be removed from future mailing=
s, please reply with &quot;Remove&quot; as subject. <br> &nbsp;</font></di=
v></td></tr></table></td></tr></table></font></body></html>




From hch@caldera.de  Thu Jan  3 22:26:51 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Thu, 3 Jan 2002 23:26:51 +0100
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <20020103232651.A878@caldera.de>

LSB> /proc/cpuinfo
LSB>
LSB> This file is a text file that contains information about one or more
LSB> processors. A blank line seperates the information for each processor.
LSB> Each processor is described by an unordered set of lines. Each line
LSB> contains a key followed by a seperator followed by a value. The key may
LSB> be any combination of alphanumeric, underscore, and space characters.
LSB> The seperator is a tab followed by a colon followed by a space ('\t: ').
LSB> The format of the value is defined below, and in architectures-specific
LSB> LSB specifications.

This differs from current practice on some Linux architectures, e.g.
PowerPc, ARM or Sparc/SMP.

Also /proc/cpuinfo is one of the abuses of the Linux /proc filesystem
that might be removed in the mid-term timeframe (e.g. Linux 2.6).

Please do not document anything in /proc besides the per-process
information.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


From esr@thyrsus.com  Thu Jan  3 22:34:01 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 17:34:01 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103232651.A878@caldera.de>; from hch@caldera.de on Thu, Jan 03, 2002 at 11:26:51PM +0100
References: <20020103232651.A878@caldera.de>
Message-ID: <20020103173401.A25141@thyrsus.com>

Christoph Hellwig <hch@caldera.de>:
> Please do not document anything in /proc besides the per-process
> information.

I disagree with this request.  Files like /proc/cpuinfo are very helpful
for autoconfigurastion and cluster management.  LSB's constituency would
be better served by more such information, not less.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The United States is in no way founded upon the Christian religion
	-- George Washington & John Adams, in a diplomatic message to Malta.


From anderson@metrolink.com  Thu Jan  3 22:53:38 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Thu, 3 Jan 2002 17:53:38 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103232651.A878@caldera.de>
Message-ID: <20020103175058.S616-100000@trantor.sc.metrolink.com>

On Thu, 3 Jan 2002, Christoph Hellwig wrote:

> This differs from current practice on some Linux architectures, e.g.
> PowerPc, ARM or Sparc/SMP.

Can you please provide some examples? All of the examples I was able to aquire
fit the description (actually, it was written to fit the exmaples 8-)).

> Also /proc/cpuinfo is one of the abuses of the Linux /proc filesystem
> that might be removed in the mid-term timeframe (e.g. Linux 2.6).
>
> Please do not document anything in /proc besides the per-process
> information.

I'd like avoid /proc completely, but we needed a way to determine what
processor features are available (especially on IA32). Without this, we have
to choose the i486 feature set as the least common denominator (ie no MMX, etc).


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From hch@caldera.de  Thu Jan  3 22:54:41 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Thu, 3 Jan 2002 23:54:41 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103173401.A25141@thyrsus.com>; from esr@thyrsus.com on Thu, Jan 03, 2002 at 05:34:01PM -0500
References: <20020103232651.A878@caldera.de> <20020103173401.A25141@thyrsus.com>
Message-ID: <20020103235441.A3021@caldera.de>

On Thu, Jan 03, 2002 at 05:34:01PM -0500, Eric S. Raymond wrote:
> Christoph Hellwig <hch@caldera.de>:
> > Please do not document anything in /proc besides the per-process
> > information.
> 
> I disagree with this request.  Files like /proc/cpuinfo are very helpful
> for autoconfigurastion and cluster management.  LSB's constituency would
> be better served by more such information, not less.

You missed the point.  There very major reasons why it shouldn't be
standardized (this is Al Viro's wording with whom I just discussed the
issue):

 a) proposed standard doesn't match existing practice
 b) any program relying on described contents is broken at least on
    some platforms for all existing versions of Linux
 c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

Besides that your above two applications won't be LSB-compliant due to a
variety of other reason in the near future.

	Christoph

--
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world.


From esr@thyrsus.com  Thu Jan  3 22:51:18 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 17:51:18 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103235441.A3021@caldera.de>; from hch@caldera.de on Thu, Jan 03, 2002 at 11:54:41PM +0100
References: <20020103232651.A878@caldera.de> <20020103173401.A25141@thyrsus.com> <20020103235441.A3021@caldera.de>
Message-ID: <20020103175118.A25423@thyrsus.com>

Christoph Hellwig <hch@caldera.de>:
>  a) proposed standard doesn't match existing practice

Then this is one of the areas where practice should be changed to meet
the standard.

>  b) any program relying on described contents is broken at least on
>     some platforms for all existing versions of Linux

Then this is one of the areas where practice should be changed to meet
the standard.

>  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

That should not happen, and I will campaign to prevent it from happening.
It's nice to talk about /proc being "per-process information only" but
that does not even begin to describe the clearly most useful features of
/proc, let alone the marginal ones.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No kingdom can be secured otherwise than by arming the people.  The possession
of arms is the distinction between a freeman and a slave. 
        -- "Political Disquisitions", a British republican tract of 1774-1775


From tbm@cyrius.com  Thu Jan  3 23:16:06 2002
From: tbm@cyrius.com (Martin Michlmayr)
Date: Fri, 4 Jan 2002 00:16:06 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104001606.A19522@fisch.cyrius.com>

* Stuart Anderson <anderson@metrolink.com> [20020103 17:53]:
> > > A blank line seperates the information for each processor
> > This differs from current practice on some Linux architectures

> Can you please provide some examples?

cpu             : TI UltraSparc II  (BlackBird)
fpu             : UltraSparc II integrated FPU
promlib         : Version 3 Revision 17
prom            : 3.17.0
type            : sun4u
ncpus probed    : 2
ncpus active    : 2
Cpu0Bogo        : 897.84
Cpu0ClkTck      : 000000001ad2bd21
Cpu2Bogo        : 897.84
Cpu2ClkTck      : 000000001ad2bd21
MMU Type        : Spitfire
State:
CPU0:           online
CPU2:           online

-- 
Martin Michlmayr
tbm@cyrius.com


From taggart@carmen.fc.hp.com  Thu Jan  3 23:21:56 2002
From: taggart@carmen.fc.hp.com (Matt Taggart)
Date: Thu, 03 Jan 2002 16:21:56 -0700
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: Message from Martin Michlmayr <tbm@cyrius.com>
 of "Fri, 04 Jan 2002 00:16:06 +0100." <20020104001606.A19522@fisch.cyrius.com>
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>  <20020104001606.A19522@fisch.cyrius.com>
Message-ID: <20020103232156.EB0DF37CB8@carmen.fc.hp.com>


Martin Michlmayr writes...

> * Stuart Anderson <anderson@metrolink.com> [20020103 17:53]:
> > > > A blank line seperates the information for each processor
> > > This differs from current practice on some Linux architectures
> 
> > Can you please provide some examples?
> 
> cpu             : TI UltraSparc II  (BlackBird)
> fpu             : UltraSparc II integrated FPU
> promlib         : Version 3 Revision 17
> prom            : 3.17.0
> type            : sun4u
> ncpus probed    : 2
> ncpus active    : 2
> Cpu0Bogo        : 897.84
> Cpu0ClkTck      : 000000001ad2bd21
> Cpu2Bogo        : 897.84
> Cpu2ClkTck      : 000000001ad2bd21
> MMU Type        : Spitfire
> State:
> CPU0:           online
> CPU2:           online

processor	: 0
cpu family	: PA-RISC 2.0
cpu		: PA8500 (PCX-W)
cpu MHz		: 400.000000
model		: 9000/785/C3000
model name	: AllegroHigh W
hversion	: 0x00005bb0
sversion	: 0x00000481
I-cache		: 512 KB
D-cache		: 1024 KB (WB)
ITLB entries	: 160
DTLB entries	: 160 - shared with ITLB
BTLB		: not supported
bogomips	: 799.53
software id	: 2011698862

processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium
model      : 0
revision   : 6
archrev    : 0
features   : standard
cpu number : 0
cpu regs   : 4
cpu MHz    : 799.926960
itc MHz    : 799.926960
BogoMIPS   : 796.91


-- 
Matt Taggart        Linux Development Lab
taggart@fc.hp.com   HP Linux Systems Operation



From hch@caldera.de  Thu Jan  3 23:28:37 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 4 Jan 2002 00:28:37 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>; from anderson@metrolink.com on Thu, Jan 03, 2002 at 05:53:38PM -0500
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104002837.A5883@caldera.de>

On Thu, Jan 03, 2002 at 05:53:38PM -0500, Stuart Anderson wrote:
> On Thu, 3 Jan 2002, Christoph Hellwig wrote:
> 
> > This differs from current practice on some Linux architectures, e.g.
> > PowerPc, ARM or Sparc/SMP.
> 
> Can you please provide some examples? All of the examples I was able to aquire
> fit the description (actually, it was written to fit the exmaples 8-)).

What about checking yourself :)

I have collected a number of examples on:

	http://people.nl.linux.org/~hch/cpuinfo/

> I'd like avoid /proc completely, but we needed a way to determine what
> processor features are available (especially on IA32). Without this, we have
> to choose the i486 feature set as the least common denominator (ie no MMX, etc).

Maybe you should introduce something like uname -f (f for features) in
LSB and make this backed by /proc/cpuinfo in the current implementation?

This way applications do not have to worry about changes to kernel
internals.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From anderson@metrolink.com  Thu Jan  3 23:35:34 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Thu, 3 Jan 2002 18:35:34 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104002837.A5883@caldera.de>
Message-ID: <20020103183322.P616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Christoph Hellwig wrote:

> What about checking yourself :)

If I only had all of the hardware ....

> I have collected a number of examples on:
>
> 	http://people.nl.linux.org/~hch/cpuinfo/

Thanks, this is very helpful.

> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?

I would prefer to document something that already exists, and not require
that a new feature has to be implemented by everyone. Also, it's slightly
easier for an application to just open a text file instead of having to popen()
a command.

> This way applications do not have to worry about changes to kernel
> internals.

That is one of our goals 8-).


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From hch@caldera.de  Thu Jan  3 23:41:29 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 4 Jan 2002 00:41:29 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103183322.P616-100000@trantor.sc.metrolink.com>; from anderson@metrolink.com on Thu, Jan 03, 2002 at 06:35:34PM -0500
References: <20020104002837.A5883@caldera.de> <20020103183322.P616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104004129.A6739@caldera.de>

On Thu, Jan 03, 2002 at 06:35:34PM -0500, Stuart Anderson wrote:
> > 	http://people.nl.linux.org/~hch/cpuinfo/
> 
> Thanks, this is very helpful.

Btw, the number of example is still growing..

> I would prefer to document something that already exists, and not require
> that a new feature has to be implemented by everyone. Also, it's slightly
> easier for an application to just open a text file instead of having to popen()
> a command.

The problem is just that current Linux /proc is full of abuse.
cpuinfo is one of the very good example why it should NOT be set in
stone.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From esr@thyrsus.com  Thu Jan  3 23:29:07 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 18:29:07 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104002837.A5883@caldera.de>; from hch@caldera.de on Fri, Jan 04, 2002 at 12:28:37AM +0100
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com> <20020104002837.A5883@caldera.de>
Message-ID: <20020103182907.A27084@thyrsus.com>

Christoph Hellwig <hch@caldera.de>:
> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?

That would solve my problem.  I just need the /proc/cpuinfo information
to be available in a portable way.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Americans have the right and advantage of being armed - unlike the citizens
of other countries whose governments are afraid to trust the people with arms.
	-- James Madison, The Federalist Papers


From venom@DarkStar.sns.it  Thu Jan  3 23:52:53 2002
From: venom@DarkStar.sns.it (Luigi Genoni)
Date: Fri, 4 Jan 2002 00:52:53 +0100 (CET)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <Pine.LNX.4.43.0201040052090.1109-100000@DarkStar.sns.it>

On Thu, 3 Jan 2002, Stuart Anderson wrote:

> Date: Thu, 3 Jan 2002 17:53:38 -0500 (EST)
> From: Stuart Anderson <anderson@metrolink.com>
> To: Christoph Hellwig <hch@caldera.de>
> Cc: lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org
> Subject: Re: LSB1.1: /proc/cpuinfo
> Resent-Date: Fri, 4 Jan 2002 00:03:56 +0100
> Resent-From: lsb-spec@lists.linuxbase.org
>
> On Thu, 3 Jan 2002, Christoph Hellwig wrote:
>
> > This differs from current practice on some Linux architectures, e.g.
> > PowerPc, ARM or Sparc/SMP.
>
> Can you please provide some examples? All of the examples I was able to aquire
> fit the description (actually, it was written to fit the exmaples 8-)).
>
> > Also /proc/cpuinfo is one of the abuses of the Linux /proc filesystem
> > that might be removed in the mid-term timeframe (e.g. Linux 2.6).
> >
> > Please do not document anything in /proc besides the per-process
> > information.
>
> I'd like avoid /proc completely, but we needed a way to determine what
> processor features are available (especially on IA32). Without this, we have
> to choose the i486 feature set as the least common denominator (ie no MMX, etc).
>
what about x86info ?
mmhh...
then there are problems about the other processors...



From schilling@fokus.gmd.de  Thu Jan  3 23:55:59 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 00:55:59 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201032355.g03Ntx911860@burner.fokus.gmd.de>

>From: Christoph Hellwig <hch@caldera.de>


>> I would prefer to document something that already exists, and not require
>> that a new feature has to be implemented by everyone. Also, it's slightly
>> easier for an application to just open a text file instead of having to popen()
>> a command.

>The problem is just that current Linux /proc is full of abuse.
>cpuinfo is one of the very good example why it should NOT be set in
>stone.


I really hope that /proc/<non-number> will vanish in the future.

It definitely is an abuse of the /proc filesystem that is rerserved
for process.

First let me give some background information:

The way /proc works has been introduced by Plan 9 in the first half of the 80s.
What Linux added as an abuse of the /proc filesytem in principle is a Plan 9
idea too. It makes sense to  have something similar, but please please _not_
inside the /proc tree.

Sun is planning to have /sys with similar backgound in a future version of 
Solaris so it wouls make sense to talk to the Solaris kernel kackers to have a 
common way to go for the new /sys tree.


If you like to look for other ideas on how to retrieve the needed information 
it makes sense to look at Solaris too. The reason is that Solaris uses "prtconf"
which is close to the device tree from the IEEE standard Boot loader.

prtconf -p is giving exactly the IEEE device tree

prtconf -p -v gives more verbose information.

If you don't use -p you will see the kernel view of the device tree.

On MacOS X which also uses the IEEE Boot architecture the same beast
will be shown via a 'ioreg -l'

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:15:06 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:15:06 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103235441.A3021@caldera.de> from "Christoph Hellwig" at Jan 03, 2002 11:54:41 PM
Message-ID: <E16MI0o-0001g5-00@the-village.bc.nu>

>  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

That will break glibc for one thing, so I doubt it

Alan


From hch@caldera.de  Fri Jan  4 00:06:41 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 4 Jan 2002 01:06:41 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MI0o-0001g5-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:15:06AM +0000
References: <20020103235441.A3021@caldera.de> <E16MI0o-0001g5-00@the-village.bc.nu>
Message-ID: <20020104010641.A8577@caldera.de>

On Fri, Jan 04, 2002 at 12:15:06AM +0000, Alan Cox wrote:
> >  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>
> 
> That will break glibc for one thing, so I doubt it

Never major versions break things.
There is no reason to stay broken because glibc is a piece of shit.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:19:29 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:19:29 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103173401.A25141@thyrsus.com> from "Eric S. Raymond" at Jan 03, 2002 05:34:01 PM
Message-ID: <E16MI53-0001i4-00@the-village.bc.nu>

> I disagree with this request.  Files like /proc/cpuinfo are very helpful
> for autoconfigurastion and cluster management.  LSB's constituency would
> be better served by more such information, not less.

The question is whether programs should be parsing it. Right now glibc 
relies on it for certain things. We need /proc/cpuinfo if only for back
compatibility. Documenting it has the disadvantage people will try to parse
it, while not documenting it has the advantage that it can be provided to
the pet human which generally has better error handling.

Alan


From schilling@fokus.gmd.de  Fri Jan  4 00:08:13 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:08:13 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040008.g0408Ds11901@burner.fokus.gmd.de>


>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>>  c) /proc/cpuinfo WILL disappear from /proc <unholy words snipped>

>That will break glibc for one thing, so I doubt it

If glibc has been cleanly written, then it will hide the fact that
it uses /proc/cpuinfo from the user so it could be easily changed to use
the feature that has been implemented as sucessor instead of /proc/cpuinfo
to implement the public features.


J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:22:17 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:22:17 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104010641.A8577@caldera.de> from "Christoph Hellwig" at Jan 04, 2002 01:06:41 AM
Message-ID: <E16MI7l-0001ia-00@the-village.bc.nu>

> > That will break glibc for one thing, so I doubt it
> 
> Never major versions break things.
> There is no reason to stay broken because glibc is a piece of shit.

Well if you don't want any users its not my problem. When you've finished
writing calderux with its own libc, that runs no normal Linux apps you
can go and join the hurd team.

Real world customers (the sort who pay sensible amounts) expect and demand
forward compatibility and the ability to roll back cleanly. Even if Linus
were to take it out of his kernel it would be relevant to the LSB as all
the vendors will have to put it back compatibly.

Alan


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:23:58 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:23:58 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040008.g0408Ds11901@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 01:08:13 AM
Message-ID: <E16MI9O-0001ir-00@the-village.bc.nu>

> If glibc has been cleanly written, then it will hide the fact that
> it uses /proc/cpuinfo from the user so it could be easily changed to use
> the feature that has been implemented as sucessor instead of /proc/cpuinfo
> to implement the public features.

Only if you upgrade the C library. That requires requalifying the entire
system for things like Oracle and SAP and simply isnt going to fly with
enterprise.

You can still run libc2.2 or higher on the current 2.4 kernel. Thats how
careful our compatibility is.


From esr@thyrsus.com  Fri Jan  4 00:02:19 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 19:02:19 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 12:55:59AM +0100
References: <200201032355.g03Ntx911860@burner.fokus.gmd.de>
Message-ID: <20020103190219.B27938@thyrsus.com>

Joerg Schilling <schilling@fokus.gmd.de>:
> The way /proc works has been introduced by Plan 9 in the first half
> of the 80s.  What Linux added as an abuse of the /proc filesytem in
> principle is a Plan 9 idea too. It makes sense to have something
> similar, but please please _not_ inside the /proc tree.
> 
> Sun is planning to have /sys with similar backgound in a future
> version of Solaris so it wouls make sense to talk to the Solaris
> kernel kackers to have a common way to go for the new /sys tree.

Well, hell.  If the "/proc is a blight on the face of the planet" ranting that
I've been hearing is just about the *name* /proc, then let's separate the
name issue from the content issue.

The kind of non-per-process information that is now in /proc needs to still
be there for many purposes; autoconfiguration is the one that is bugging 
me right now, but cluster management is just as important.

If moving /proc/cpuinfo to /sys/cpuinfo means people will stop trying to make
the cpuinfo information go away, then By all means let's move it.

I want /sys/dmi, too.

I'm willing to write up a proposal for /sys that would migrate the `unclean'
/proc stuff over to ./sys, and I'm willing to write the kernel patches to
implement the renaming.

I'm motivated to attack this right now because it touches the work I'm
doing on kernel autoconfiguration.

(Copied to the linux-kernel mailing list because of a parallel argument
happening there...)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:27:13 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:27:13 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 12:55:59 AM
Message-ID: <E16MICX-0001jb-00@the-village.bc.nu>

> The way /proc works has been introduced by Plan 9 in the first half of the 80s.
> What Linux added as an abuse of the /proc filesytem in principle is a Plan 9
> idea too. It makes sense to  have something similar, but please please _not_
> inside the /proc tree.

Linux is not Plan 9 (yet). What the Linux /proc subsystem does is nothing
to do with what Sun, Plan 9, Microsoft or your pet hamster do. Nor is it
remotely meaningful to argue about it that way. Using /sys is also extremely
inappropriate as many BSD derived folks use /sys already and it would make
LSB on non Linux systems unneccessarily hard.

> On MacOS X which also uses the IEEE Boot architecture the same beast
> will be shown via a 'ioreg -l'

The PC world doesnt have an IEEE boot architecture. The ARM world doesn't
the HPPA world doesn't, the MIPS world mostly doesn't, the SH3 world
doesnt.


From hch@infradead.org  Fri Jan  4 00:16:52 2002
From: hch@infradead.org (Christoph Hellwig)
Date: Fri, 4 Jan 2002 01:16:52 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MI7l-0001ia-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:22:17AM +0000
References: <20020104010641.A8577@caldera.de> <E16MI7l-0001ia-00@the-village.bc.nu>
Message-ID: <20020104011652.A9180@caldera.de>

On Fri, Jan 04, 2002 at 12:22:17AM +0000, Alan Cox wrote:
> Well if you don't want any users its not my problem. When you've finished
> writing calderux with its own libc

[Sender address changed to stop your silly assumptions.]

Hurd uses the same glibc, that's not the point.
What I mean is that we there is no reason to support a feature
forever just because glibc (ab)uses it.  /proc is not set in stone.

> that runs no normal Linux apps you, that runs no normal Linux apps you
> can go and join the hurd team.

IF LSB would be designed in a sane way there would be no reason to not
to do so.  But as it contains numerous random glibc internal symbols
it gets rather difficult to use a different libc.

Same is for specifying all those GNU options in the tools, that's very,
very bad style.


> Real world customers (the sort who pay sensible amounts) expect and demand
> forward compatibility and the ability to roll back cleanly. Even if Linus
> were to take it out of his kernel it would be relevant to the LSB as all
> the vendors will have to put it back compatibly.

Glibc already contains so much version checking code that it would be no
problem to use /proc/cpuinfo if the kernel version is smaller than
foo.bar.baz and a sane interface if later.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:34:18 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:34:18 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104011652.A9180@caldera.de> from "Christoph Hellwig" at Jan 04, 2002 01:16:52 AM
Message-ID: <E16MIJO-0001lU-00@the-village.bc.nu>

> Glibc already contains so much version checking code that it would be no
> problem to use /proc/cpuinfo if the kernel version is smaller than
> foo.bar.baz and a sane interface if later.

Wake up, hello, anyone home ?

The _current_ glibc doesn't know about this, so you will break existing 
systems. Unless you can grasp that elementary detail you aren't going to
have a userbase.

Alan


From anderson@metrolink.com  Fri Jan  4 00:23:24 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Thu, 3 Jan 2002 19:23:24 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104011652.A9180@caldera.de>
Message-ID: <20020103192239.R616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Christoph Hellwig wrote:

> IF LSB would be designed in a sane way there would be no reason to not
> to do so.  But as it contains numerous random glibc internal symbols
> it gets rather difficult to use a different libc.

Many of those ugly symbols have been deprecated in 1.1, and will be gone soon.
They showed up as we tried to balance doing it right with the real world.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From esr@thyrsus.com  Fri Jan  4 00:11:56 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 19:11:56 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MI53-0001i4-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:19:29AM +0000
References: <20020103173401.A25141@thyrsus.com> <E16MI53-0001i4-00@the-village.bc.nu>
Message-ID: <20020103191156.D27938@thyrsus.com>

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > I disagree with this request.  Files like /proc/cpuinfo are very helpful
> > for autoconfigurastion and cluster management.  LSB's constituency would
> > be better served by more such information, not less.
> 
> The question is whether programs should be parsing it. Right now glibc 
> relies on it for certain things. We need /proc/cpuinfo if only for back
> compatibility. Documenting it has the disadvantage people will try to parse
> it, while not documenting it has the advantage that it can be provided to
> the pet human which generally has better error handling.

I grant your implied point.

However, I think it's worth noting that the nature of the languages
used to do the parsing is changing.  Nowadays it's less likely to be C
munching individual bytes and more likely to be Perl or Python
slinging regexp matches, which makes the programs a bit less sensitive to
format variations or misunderstandings.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
        -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.


From hch@infradead.org  Fri Jan  4 00:27:13 2002
From: hch@infradead.org (Christoph Hellwig)
Date: Fri, 4 Jan 2002 01:27:13 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MIJO-0001lU-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:34:18AM +0000
References: <20020104011652.A9180@caldera.de> <E16MIJO-0001lU-00@the-village.bc.nu>
Message-ID: <20020104012713.B10266@caldera.de>

On Fri, Jan 04, 2002 at 12:34:18AM +0000, Alan Cox wrote:
> The _current_ glibc doesn't know about this, so you will break existing 
> systems. Unless you can grasp that elementary detail you aren't going to
> have a userbase.

Current glibc won't stay current forever.
If Documentation/Changes says you need never binutils for a new
development kernel or a new stable series you update it, there is no
reason not to do so for glibc.


From dank@kegel.com  Fri Jan  4 00:35:18 2002
From: dank@kegel.com (Dan Kegel)
Date: Thu, 03 Jan 2002 16:35:18 -0800
Subject: LSB1.1: /proc/cpuinfo
References: <200201032355.g03Ntx911860@burner.fokus.gmd.de>
Message-ID: <3C34F8C6.6B5C4C67@kegel.com>

Joerg Schilling wrote:
> ...
> The way /proc works has been introduced by Plan 9 in the first half of the 80s.
> What Linux added as an abuse of the /proc filesytem in principle is a Plan 9
> idea too. It makes sense to  have something similar, but please please _not_
> inside the /proc tree.
> 
> Sun is planning to have /sys with similar backgound in a future version of
> Solaris so it wouls make sense to talk to the Solaris kernel kackers to have a
> common way to go for the new /sys tree.

FWIW, Rusty Russell is working on a replacement for /proc/sys in Linux;
see http://lwn.net/2002/0103/a/proc.php3
I wonder if he's talked to the Solaris people about their /sys plans.

> If you like to look for other ideas on how to retrieve the needed information
> it makes sense to look at Solaris too. The reason is that Solaris uses "prtconf"
> which is close to the device tree from the IEEE standard Boot loader.
> 
> prtconf -p is giving exactly the IEEE device tree
> 
> prtconf -p -v gives more verbose information.
> 
> If you don't use -p you will see the kernel view of the device tree.
> 
> On MacOS X which also uses the IEEE Boot architecture the same beast
> will be shown via a 'ioreg -l'

That's interesting stuff, thanks.
- Dan


From schilling@fokus.gmd.de  Fri Jan  4 00:34:07 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:34:07 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040034.g040Y7E11953@burner.fokus.gmd.de>

>From: Christoph Hellwig <hch@infradead.org>

>Same is for specifying all those GNU options in the tools, that's very,
>very bad style.

Many man pages contain EXAMPLES sections that only list the GNU options
instead of the standard options of the program. If people don't know how a 
program officially works thy tend to copy examples. 

BTW: sorry for being off topic but does anybody know how to write a test that 
finds that GNU rm is not UNIX-98 compliant?

>From http://www.opengroup.org/onlinepubs/7908799/xcu/rm.html:

4.If the current file is a directory, rm will perform actions equivalent to the 
XSH specification rmdir() function called with a pathname of the current file 
used as the path argument.

... but GNU rm has a -d option that makes it behave like the unlink command.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:45:23 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:45:23 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104012713.B10266@caldera.de> from "Christoph Hellwig" at Jan 04, 2002 01:27:13 AM
Message-ID: <E16MIU7-0001nO-00@the-village.bc.nu>

> If Documentation/Changes says you need never binutils for a new
> development kernel or a new stable series you update it, there is no
> reason not to do so for glibc.

Is there anyone home ?

Think like a business end user

"We updated the kernel it broke"
"Our app isnt certified with the new glibc"
"Why do we have to change two components at a time - how will we test it"

At the moment I repeat - I can run any app back to libc 2.2 on a 2.4.x
kernel. Thats back to the days of Linux 0.98 or so. 

I concur we should consider hard if we want to document the internals of
/proc/cpuinfo except when needed (eg mips cache stuff)


From tytso@mit.edu  Fri Jan  4 00:37:14 2002
From: tytso@mit.edu (Theodore Tso)
Date: Thu, 3 Jan 2002 19:37:14 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MIJO-0001lU-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 12:34:18AM +0000
References: <20020104011652.A9180@caldera.de> <E16MIJO-0001lU-00@the-village.bc.nu>
Message-ID: <20020103193714.C14256@thunk.org>

On Fri, Jan 04, 2002 at 12:34:18AM +0000, Alan Cox wrote:
> > Glibc already contains so much version checking code that it would be no
> > problem to use /proc/cpuinfo if the kernel version is smaller than
> > foo.bar.baz and a sane interface if later.
> 
> Wake up, hello, anyone home ?
> 
> The _current_ glibc doesn't know about this, so you will break existing 
> systems. Unless you can grasp that elementary detail you aren't going to
> have a userbase.

Absolutely --- Alan is 100% correct here.  The earliest /proc/cpuinfo
could disappear is 2.8 (assuming it was deprecated in 2.6).  And I'm
not convinced it's non-pid /proc entries are so horrible that they
have to go away at all costs --- there are far more important things
for us to worry about in the kernel at the moment than aesthetic
issues like this.

Sometimes, practicality needs to take a back seat to "the Right
Thing".  Remember, sometimes "Worse is Better"
(http://www.dreamsongs.com/WIB.html); in fact, many people would argue
that Linux is a prime example of how sometimes "Worse is Better"
approach is far better than trying to do the Right Thing.  (That way
lies NetBSD --- the organization that took three years to rearchitect
their entire device driver interface before they had full PCMCIA
support.)

More often than not, practicality and support of the existing user
base is far more important that being Architecturally Pure.

						- Ted


From schilling@fokus.gmd.de  Fri Jan  4 00:42:17 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:42:17 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040042.g040gHR11989@burner.fokus.gmd.de>


>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>Think like a business end user

>"We updated the kernel it broke"
>"Our app isnt certified with the new glibc"
>"Why do we have to change two components at a time - how will we test it"

>At the moment I repeat - I can run any app back to libc 2.2 on a 2.4.x
>kernel. Thats back to the days of Linux 0.98 or so. 

Why do you tell us this?

This is wrong and you should know about it as we had more then one personal
discussion about exactly this fact. Not even a simple program that uses only
ctype.h will run correctly if you go <= glibc-2.1.

Glibc-2.1 has a broken large file interface that if an application tris to work 
around make it non binary compliant, the /dev/sg interface did change many 
times the signal interface is incompatible. I hope that I don't need to tell you more.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 00:59:26 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 00:59:26 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040042.g040gHR11989@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 01:42:17 AM
Message-ID: <E16MIhi-0001py-00@the-village.bc.nu>

> This is wrong and you should know about it as we had more then one personal
> discussion about exactly this fact. Not even a simple program that uses only
> ctype.h will run correctly if you go <= glibc-2.1.

Take an RH box with glibc 2.0.7. You'll note that while glibc had (and has!)
plenty of bugs they were not biting the apps people were using (otherwise
they wouldnt have been able to use glibc 2.0.7) and that release.

It isnt about buggyness. Its about production solid. It worked for 2 years
so statistically it should continue to do so. This makes sysadmins happy.


From schilling@fokus.gmd.de  Fri Jan  4 00:54:07 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 01:54:07 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040054.g040s7X12008@burner.fokus.gmd.de>


>From alan@lxorguk.ukuu.org.uk Fri Jan  4 01:48:32 2002

>> This is wrong and you should know about it as we had more then one personal
>> discussion about exactly this fact. Not even a simple program that uses only
>> ctype.h will run correctly if you go <= glibc-2.1.

>Take an RH box with glibc 2.0.7. You'll note that while glibc had (and has!)
>plenty of bugs they were not biting the apps people were using (otherwise
>they wouldnt have been able to use glibc 2.0.7) and that release.

I received many "bug reports" for cdrecord about 2 years ago.

The reason was that "cdrecord dev=xxx ..." won't work because the bit mask 
definitions in ctype.h did change and for this reason, cdrecold by using 
getallargs would assume that dev= is not an option but a file type argument.

I had to send plenty of mails stating: don't use precompiled versions of 
cdrecord because Linux is not binary compatible to itself. You need to compile 
an application on the machine you like to run it :-(

As you see there _have_ been incompatible changes without a reason.

If you like to care Linux users starting from now this is a nice idea, however 
it was not done in former times.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From viro@math.psu.edu  Fri Jan  4 00:56:51 2002
From: viro@math.psu.edu (Alexander Viro)
Date: Thu, 3 Jan 2002 19:56:51 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103190219.B27938@thyrsus.com>
Message-ID: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>



On Thu, 3 Jan 2002, Eric S. Raymond wrote:

> Well, hell.  If the "/proc is a blight on the face of the planet" ranting that
> I've been hearing is just about the *name* /proc, then let's separate the
> name issue from the content issue.

It's more than just a name.
	a) granularity.  Current "all or nothing" policy in procfs has
a lot of obvious problems.
	b) tree layout policy (lack thereof, to be precise).
	c) horribly bad layout of many, many files.  Any file exported by
kernel should be treated as user-visible API.  As it is, common mentality
is "it's a common dump; anything goes here".  Inconsistent across
architectures for no good reason, inconsistent across kernel versions,
just plain stupid, choke-full of buffer overruns...

Fixing these problems will _hurt_.  Badly.  We have to do it, but it
won't be fast and it certainly won't happen overnight.


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 01:10:24 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 01:10:24 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040054.g040s7X12008@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 01:54:07 AM
Message-ID: <E16MIsK-0001uc-00@the-village.bc.nu>

> The reason was that "cdrecord dev=xxx ..." won't work because the bit mask 
> definitions in ctype.h did change and for this reason, cdrecold by using 
> getallargs would assume that dev= is not an option but a file type argument.

SuSE and Red Hat managed to get different glibc 2.0 ones. Thats a somewhat
seperate issue, and thats the kind of thing the LSB is precisely there
to ensure doesn't happen again.

Thats not a compatibility argument so much as a clear explanation of why
the LSB matters

Alan


From schilling@fokus.gmd.de  Fri Jan  4 01:03:48 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 02:03:48 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201040103.g0413m012034@burner.fokus.gmd.de>

>From alan@lxorguk.ukuu.org.uk Fri Jan  4 01:59:30 2002

>> The reason was that "cdrecord dev=xxx ..." won't work because the bit mask 
>> definitions in ctype.h did change and for this reason, cdrecold by using 
>> getallargs would assume that dev= is not an option but a file type argument.

>SuSE and Red Hat managed to get different glibc 2.0 ones. Thats a somewhat
>seperate issue, and thats the kind of thing the LSB is precisely there
>to ensure doesn't happen again.

>Thats not a compatibility argument so much as a clear explanation of why
>the LSB matters

I am happy to see LSB as it makes Linux go towards a system that may be used 
by combining binary compilations of programs on many systems if it is done 
right.

Right now, when I am forced to make binary only versions of programs like
e.g. the the Plextor firmware upgrade program, I can only do it for libc.so.5 
and for glibc-2.2. Anything in between gives problems.


J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From esr@thyrsus.com  Fri Jan  4 00:52:07 2002
From: esr@thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Jan 2002 19:52:07 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, Jan 03, 2002 at 07:56:51PM -0500
References: <20020103190219.B27938@thyrsus.com> <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
Message-ID: <20020103195207.A31252@thyrsus.com>

Alexander Viro <viro@math.psu.edu>:
> It's more than just a name.
> 	a) granularity.  Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> 	b) tree layout policy (lack thereof, to be precise).
> 	c) horribly bad layout of many, many files.  Any file exported by
> kernel should be treated as user-visible API.  As it is, common mentality
> is "it's a common dump; anything goes here".  Inconsistent across
> architectures for no good reason, inconsistent across kernel versions,
> just plain stupid, choke-full of buffer overruns...
> 
> Fixing these problems will _hurt_.  Badly.  We have to do it, but it
> won't be fast and it certainly won't happen overnight.

I'm willing to work on this.  Is there anywhere I can go to read up on 
current proposals before I start coding?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

When all government ...in little as in great things... shall be drawn to
Washington as the center of all power; it will render powerless the checks
provided of one government on another, and will become as venal and oppressive
as the government from which we separated."	-- Thomas Jefferson, 1821


From jgarzik@mandrakesoft.com  Fri Jan  4 01:18:48 2002
From: jgarzik@mandrakesoft.com (Jeff Garzik)
Date: Thu, 03 Jan 2002 20:18:48 -0500
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
References: <200201032355.g03Ntx911860@burner.fokus.gmd.de> <20020103190219.B27938@thyrsus.com>
Message-ID: <3C3502F8.4834077@mandrakesoft.com>

To run offtopic a bit, it was a huge mistake for LSB 1.0 to document
GNU-specific command line extensions.

Each command should be compared with SuSv2 or POSIX, and if an argument
or behavior is extraneous, careful thought should be put into leaving it
in LSB.

To do otherwise places an unrealistic burden on implementors of embedded
and otherwise small systems.

Does a standard Linux implementation of /bin/cat really require
supporting --number-nonblank and --squeeze-blank and --show-nonprinting?

I humbly urge members and readers to reconsider this course of action. 
As it stands, LSB is currently not a standards document but really a
common-practices document.

Best regards,

	Jeff



-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 01:38:27 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 01:38:27 +0000 (GMT)
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
In-Reply-To: <3C3502F8.4834077@mandrakesoft.com> from "Jeff Garzik" at Jan 03, 2002 08:18:48 PM
Message-ID: <E16MJJT-0001yM-00@the-village.bc.nu>

> Each command should be compared with SuSv2 or POSIX, and if an argument
> or behavior is extraneous, careful thought should be put into leaving it
> in LSB.

Please go and read the LSB mission statement and the original mailing
list discussions first.

> To do otherwise places an unrealistic burden on implementors of embedded
> and otherwise small systems.

Please go and read the old LSB archives. This is a long old discussion

> Does a standard Linux implementation of /bin/cat really require
> supporting --number-nonblank and --squeeze-blank and --show-nonprinting?
> 
Please go and read the old LSB archives. This is a long old discussion

> I humbly urge members and readers to reconsider this course of action. 
> As it stands, LSB is currently not a standards document but really a
> common-practices document.

Guess what, thats what the whole bloody idea is. But if you'd actually
bothered to read before writing you'd have known that.

Alan


From jgarzik@mandrakesoft.com  Fri Jan  4 01:30:53 2002
From: jgarzik@mandrakesoft.com (Jeff Garzik)
Date: Thu, 03 Jan 2002 20:30:53 -0500
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
References: <E16MJJT-0001yM-00@the-village.bc.nu>
Message-ID: <3C3505CD.B85B6D7E@mandrakesoft.com>

Alan Cox wrote:
> > I humbly urge members and readers to reconsider this course of action.
> > As it stands, LSB is currently not a standards document but really a
> > common-practices document.
> 
> Guess what, thats what the whole bloody idea is. But if you'd actually
> bothered to read before writing you'd have known that.

A common practices document that is going to need continual updating as
people start using more and more non-GNU command utilities.  Which is
why the crud should be removed now.

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 01:43:10 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 01:43:10 +0000 (GMT)
Subject: LSB and GNU (was Re: LSB1.1: /proc/cpuinfo)
In-Reply-To: <3C3505CD.B85B6D7E@mandrakesoft.com> from "Jeff Garzik" at Jan 03, 2002 08:30:53 PM
Message-ID: <E16MJO2-0001zE-00@the-village.bc.nu>

> > Guess what, thats what the whole bloody idea is. But if you'd actually
> > bothered to read before writing you'd have known that.
> 
> A common practices document that is going to need continual updating as
> people start using more and more non-GNU command utilities.  Which is
> why the crud should be removed now.

For god sake go and read the archive. Then come back.

Alan


From timothy.covell@ashavan.org  Fri Jan  4 01:56:46 2002
From: timothy.covell@ashavan.org (Timothy Covell)
Date: Thu, 3 Jan 2002 19:56:46 -0600
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
References: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
Message-ID: <200201040200.g0420PSr029316@svr3.applink.net>

On Thursday 03 January 2002 18:56, Alexander Viro wrote:
> On Thu, 3 Jan 2002, Eric S. Raymond wrote:
> > Well, hell.  If the "/proc is a blight on the face of the planet" ranting
> > that I've been hearing is just about the *name* /proc, then let's
> > separate the name issue from the content issue.
>
> It's more than just a name.
> 	a) granularity.  Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> 	b) tree layout policy (lack thereof, to be precise).
> 	c) horribly bad layout of many, many files.  Any file exported by
> kernel should be treated as user-visible API.  As it is, common mentality
> is "it's a common dump; anything goes here".  Inconsistent across
> architectures for no good reason, inconsistent across kernel versions,
> just plain stupid, choke-full of buffer overruns...
>
> Fixing these problems will _hurt_.  Badly.  We have to do it, but it
> won't be fast and it certainly won't happen overnight.


Talking from the SysAdmin point of view, procfs is one of the truly
cool things which separates Linux from the others.   I'd rather tune
/proc/sys stuff than use sysctl or Solaris' funky /etc/system and
ndd crap.  It's the next best thing to "point and click" without going
over to the dark side.

Sure /system is a better name (extra typing becaue we can't have 
/sys/sys can we??).  

And while you all are  at it, why not take a look at some of the naming 
conventions that BeOS makes too.  I'm _not_ being sarcastic.    


Example1: Excellent devfs layout.

Example 2:  BeOS root directory is a ramfs off of which the
other drives/filesystems are mounted.   (I haven't thought 
this one out too much but I could image that it would make
some things easier.)

Example 3:  Kernel Modules are in the directory:
	/boot/beos/system/add-ons/kernel
Perhaps we could have directories something like:

/boot/kernel
/boot/grub
/boot/lilo
/dev	 using devfs !
/etc
/home
/system/config/sys
                    /net
/system/modules/kernelversion/ (modules in devfs similar tree)
/system/info  (for cpuinfo, ioports, meminfo, filesystems, etc.)
/sbin	(or even in /system/bin ???)
/tmp
/usr
/var

Example 3:    BeOS moves /usr/local stuff to more of a per user 
configuration where each user has a $HOME/config directory.
Of course, we would put things like .Xdefaults, kde, gnome, etc.
directories here which vary according to user while still keeping
/usr/local for all users.

My ~/config contains things like "find ~/config -type d | hand edit some"

config/add-ons/media/decoders
config/add-ons/media/encoders
config/add-ons/media/extractors
config/add-ons/media/writers
config/add-ons/net_server
config/be/Applications
config/be/Demos
config/be/Preferences
config/bin
config/boot		(Things my personal boot/login preferences)
config/doc
config/doc/postgresql
config/doc/postgresql/html
config/documentation
config/etc
config/fonts
config/include
config/include/openssl
config/include/postgresql
config/include/postgresql/lib
config/include/postgresql/libpq
config/lib
config/lib/perl5
config/lib/perl5/5.00503
config/lib/perl5/site_perl
config/lib/perl5/site_perl/5.005/BePC-beos
config/man
config/man/man1
config/servers
config/settings
config/settings/beos_mime
config/settings/beos_mime/application
config/settings/beos_mime/audio
config/settings/beos_mime/image
config/settings/beos_mime/message
config/settings/beos_mime/text
config/settings/beos_mime/video
config/share
config/share/postgresql
config/ssl
config/ssl/certs
config/ssl/lib
config/ssl/man
config/ssl/man/man1


Of course, on heavily user subscribed systems, some sort of
NT like COW technique might be nesc. if too many file duplications
occur in the ~/config directories.  Having a good /usr/local would
prevent much of this growth, at least in theory.  As would strict
quotas. :-)



Just some thoughts.

-- 
timothy.covell@ashavan.org.


From wichert@wiggy.net  Fri Jan  4 12:15:49 2002
From: wichert@wiggy.net (Wichert Akkerman)
Date: Fri, 4 Jan 2002 13:15:49 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104121549.GP12696@wiggy.net>

Previously Stuart Anderson wrote:
> I'd like avoid /proc completely, but we needed a way to determine what
> processor features are available (especially on IA32). Without this,
> we have to choose the i486 feature set as the least common denominator
> (ie no MMX, etc).

I'm not quite sure that is a bad thing actually.

Wichert.

-- 
  _________________________________________________________________
 /wichert@wiggy.net         This space intentionally left occupied \
| wichert@deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 12:36:45 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 12:36:45 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104121549.GP12696@wiggy.net> from "Wichert Akkerman" at Jan 04, 2002 01:15:49 PM
Message-ID: <E16MTaX-0003oJ-00@the-village.bc.nu>

> > we have to choose the i486 feature set as the least common denominator
> > (ie no MMX, etc).
> 
> I'm not quite sure that is a bad thing actually.

Its a very bad thing for large numbers of applications. However for x86 it
isnt the case that we need to look at /proc. If you follow the AMD and Intel
guidelines for identifying their processors you will be fine, and cpuid is
user space. The minimal feature set btw is 386. The 486 adds instructions
like BSWAP that may not be present on some other chips right up to the
nexgen 586.

This is not always the case for non x86 platforms, but that is a matter
for the architecture specific LSB parts.

Alan


From Ralf Flaxa <rf@caldera.de>  Fri Jan  4 12:30:51 2002
From: Ralf Flaxa <rf@caldera.de> (Ralf Flaxa)
Date: Fri, 4 Jan 2002 13:30:51 +0100
Subject: [New Proposal] cpuinfo, but not directly via /proc
In-Reply-To: <20020104002837.A5883@caldera.de>; from hch@caldera.de on Fri, Jan 04, 2002 at 12:28:37AM +0100
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com> <20020104002837.A5883@caldera.de>
Message-ID: <20020104133051.A10241@lst.de>

Disclaimer:
[ Inappropriate bashing by Christoph against the glibc folks removed.   ]
[ This is *NOT* Caldera's position and we very much appreciate all the  ]
[ hard work people put into glibc. Caldera believes instead that Linux  ]
[ needs certain standards in order to maintain and improve its success  ]
[ in the business and enterprise world. That's why we support e.g. LSB. ]

We would like to make a new proposal - see below.

On Fri, Jan 04, 2002 at 12:28:37AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 03, 2002 at 05:53:38PM -0500, Stuart Anderson wrote:
> 
> > I'd like avoid /proc completely, but we needed a way to determine what
> > processor features are available (especially on IA32). Without this, we have
> > to choose the i486 feature set as the least common denominator (ie no MMX, etc).
> 
> Maybe you should introduce something like uname -f (f for features) in
> LSB and make this backed by /proc/cpuinfo in the current implementation?
> 
> This way applications do not have to worry about changes to kernel
> internals.

I like this idea, be it implemented via "uname" or some other interface.

Reading this thread and previous requests I see a need by ISVs and
applications to determine at runtime certain processor related features.

They can roughly be grouped into:

1. number-crunching power in general

	o number of CPUs
	o CPU family and type
	o BogoMips (per CPU and/or overall)
	o SMP capabilities (here kernel scalability could be an item)

2. features specific to a processor

	o for x86 e.g. the "flags" and *_bug fields
	o info about FPU, MMU and the like

I have asked Christoph to work on a proposal and present it
to this list. I think we agree that there is a need and demand
for a standard way to gather this info and that /proc/cpuinfo
was just a bad start - so I would like to give it another chance.

This is Ralf speaking as director of Linux development at Caldera
and as technical lead for the LSB sample implementation.

	Ralf



From mstone@cs.loyola.edu  Fri Jan  4 14:25:35 2002
From: mstone@cs.loyola.edu (Michael Stone)
Date: Fri, 4 Jan 2002 09:25:35 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040034.g040Y7E11953@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 01:34:07AM +0100
References: <200201040034.g040Y7E11953@burner.fokus.gmd.de>
Message-ID: <20020104092535.B20024@justice.loyola.edu>

On Fri, Jan 04, 2002 at 01:34:07AM +0100, Joerg Schilling wrote:
> BTW: sorry for being off topic but does anybody know how to write a test that 
> finds that GNU rm is not UNIX-98 compliant?
> 
> From http://www.opengroup.org/onlinepubs/7908799/xcu/rm.html:
> 
> 4.If the current file is a directory, rm will perform actions equivalent to the 
> XSH specification rmdir() function called with a pathname of the current file 
> used as the path argument.
> 
> ... but GNU rm has a -d option that makes it behave like the unlink command.

If you use an out-of-standard option, why would you expect a
standards-compliant result? 

-- 
Mike Stone


From schilling@fokus.gmd.de  Fri Jan  4 14:34:34 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 15:34:34 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041434.g04EYYq12867@burner.fokus.gmd.de>


>From: Michael Stone <mstone@cs.loyola.edu>

>On Fri, Jan 04, 2002 at 01:34:07AM +0100, Joerg Schilling wrote:
>> BTW: sorry for being off topic but does anybody know how to write a test that 
>> finds that GNU rm is not UNIX-98 compliant?
>> 
>> From http://www.opengroup.org/onlinepubs/7908799/xcu/rm.html:
>> 
>> 4.If the current file is a directory, rm will perform actions equivalent to the 
>> XSH specification rmdir() function called with a pathname of the current file 
>> used as the path argument.
>> 
>> ... but GNU rm has a -d option that makes it behave like the unlink command.

>If you use an out-of-standard option, why would you expect a
>standards-compliant result? 

My question was: 

"How could a standard compliance test find out that GNU rm includes a nonstandard
option that gives GNU rm properties that are not allowed from SUSv2?"

The problem ius that such incompatibilities cannot be found by starting a 
compliance test and waiting for the results. You have to read the standard, 
memorize it, read the man pages of the programs to test and then check whether 
the untestable behavior would be alloed to exists by the standard.




J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From kukuk@suse.de  Fri Jan  4 14:44:37 2002
From: kukuk@suse.de (Thorsten Kukuk)
Date: Fri, 4 Jan 2002 15:44:37 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041434.g04EYYq12867@burner.fokus.gmd.de>
References: <200201041434.g04EYYq12867@burner.fokus.gmd.de>
Message-ID: <20020104154437.A30760@suse.de>

On Fri, Jan 04, Joerg Schilling wrote:

> My question was: 
> 
> "How could a standard compliance test find out that GNU rm includes a nonstandard
> option that gives GNU rm properties that are not allowed from SUSv2?"

Where is the problem? You don't use this nonstandard option and
everything is ok. There is no rule that a software is not allowed
to have more options than specified in the LSB. So you don't need
to check, if software can do more, you only need to check that
software can do that, what the spec requires and don't do things,
which are explicit forbidden.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


From mstone@cs.loyola.edu  Fri Jan  4 14:46:23 2002
From: mstone@cs.loyola.edu (Michael Stone)
Date: Fri, 4 Jan 2002 09:46:23 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041434.g04EYYq12867@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 03:34:34PM +0100
References: <200201041434.g04EYYq12867@burner.fokus.gmd.de>
Message-ID: <20020104094623.C20024@justice.loyola.edu>

On Fri, Jan 04, 2002 at 03:34:34PM +0100, Joerg Schilling wrote:
> "How could a standard compliance test find out that GNU rm includes a nonstandard
> option that gives GNU rm properties that are not allowed from SUSv2?"

It's irrelevant. If the standard says that undefined options produce
undefined behavior, the conclusion is obvious. If the standard says that
undefined options are disallowed, then you test to see whether the
program accepts undefined options. IOW, the specific behavior of
undefined options is orthogonal to your test.

-- 
Mike Stone


From schilling@fokus.gmd.de  Fri Jan  4 14:55:22 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 15:55:22 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041455.g04EtMd12890@burner.fokus.gmd.de>


>From kukuk@suse.de Fri Jan  4 15:44:41 2002

>On Fri, Jan 04, Joerg Schilling wrote:

>> My question was: 
>> 
>> "How could a standard compliance test find out that GNU rm includes a nonstandard
>> option that gives GNU rm properties that are not allowed from SUSv2?"

>Where is the problem? You don't use this nonstandard option and
>everything is ok. There is no rule that a software is not allowed
>to have more options than specified in the LSB. So you don't need
>to check, if software can do more, you only need to check that
>software can do that, what the spec requires and don't do things,
>which are explicit forbidden.


Please READ the standard before you try to find arguments!

The standard says that the rm command has to use the rmdir() behavior in 
order to remove directories.

As - if you are root- you may unlink a non-empty diretory using GNUrm -d 
this is

-	a behavior that is not compliant with the general rules for the
	rm program.

-	a risk fot the data integrity of the machine

If you call GNUrm -d on a non-empty directory you need to run fsck later to move
the orhpaned files into lost+found. As this is nothing you should really like
this behavior is reserved to the SUSv2 command "unlink" - you will not by chance
of a typo call unlink <dir> instead of rm <dir>

Check your keyboard: the letter "d" and the letter "f" are close to each other.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From schilling@fokus.gmd.de  Fri Jan  4 14:56:36 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 15:56:36 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041456.g04Euak12902@burner.fokus.gmd.de>


>From mstone@justice.loyola.edu Fri Jan  4 15:46:26 2002

>On Fri, Jan 04, 2002 at 03:34:34PM +0100, Joerg Schilling wrote:
>> "How could a standard compliance test find out that GNU rm includes a nonstandard
>> option that gives GNU rm properties that are not allowed from SUSv2?"

>It's irrelevant. If the standard says that undefined options produce
>undefined behavior, the conclusion is obvious. If the standard says that
>undefined options are disallowed, then you test to see whether the
>program accepts undefined options. IOW, the specific behavior of
>undefined options is orthogonal to your test.

For you too: Please READ the standard and try to understand it before you start
argumenting about it.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From anderson@metrolink.com  Fri Jan  4 15:10:09 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 10:10:09 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MTaX-0003oJ-00@the-village.bc.nu>
Message-ID: <20020104100841.O616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> > > we have to choose the i486 feature set as the least common denominator
> > > (ie no MMX, etc).
> >
> > I'm not quite sure that is a bad thing actually.
>
> Its a very bad thing for large numbers of applications. However for x86 it
> isnt the case that we need to look at /proc. If you follow the AMD and Intel
> guidelines for identifying their processors you will be fine, and cpuid is
> user space.

I did read the app notes pertaining to this, and felt that it was an excessive
burdon on the application considering the kernel had already done the work.




                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From kukuk@suse.de  Fri Jan  4 15:09:32 2002
From: kukuk@suse.de (Thorsten Kukuk)
Date: Fri, 4 Jan 2002 16:09:32 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041455.g04EtMd12890@burner.fokus.gmd.de>
References: <200201041455.g04EtMd12890@burner.fokus.gmd.de>
Message-ID: <20020104160932.A6040@suse.de>

On Fri, Jan 04, Joerg Schilling wrote:

> 
> >From kukuk@suse.de Fri Jan  4 15:44:41 2002
> 
> >On Fri, Jan 04, Joerg Schilling wrote:
> 
> >> My question was: 
> >> 
> >> "How could a standard compliance test find out that GNU rm includes a nonstandard
> >> option that gives GNU rm properties that are not allowed from SUSv2?"
> 
> >Where is the problem? You don't use this nonstandard option and
> >everything is ok. There is no rule that a software is not allowed
> >to have more options than specified in the LSB. So you don't need
> >to check, if software can do more, you only need to check that
> >software can do that, what the spec requires and don't do things,
> >which are explicit forbidden.
> 
> 
> Please READ the standard before you try to find arguments!

I read it. And did not found the answer. So, please explain, where the
standard forbids additional options, which are not standard conform.

> The standard says that the rm command has to use the rmdir() behavior in 
> order to remove directories.

Yes, this is what the standard says, here we agree.

> As - if you are root- you may unlink a non-empty diretory using GNUrm -d 

You are doing here something which is not in the standard. The standard says
nothing about "-d". So, if you use a non-standard option, the behavior
is not documented in the standard. rm says, that it will remove directories
with unlink if "-d" is used. So, everything is ok.

> this is
> 
> -	a behavior that is not compliant with the general rules for the
> 	rm program.

It is. You use a non-standard option to overwrite the standard. The standard
says nothing about unspecified arguments.

> -	a risk fot the data integrity of the machine

But the manual page for GNUrm clearly writes that it will use "unlink".
So it is your problem.

> Check your keyboard: the letter "d" and the letter "f" are close to each other.

Then you should be more carefull what you type.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


From tytso@mit.edu  Fri Jan  4 15:40:43 2002
From: tytso@mit.edu (Theodore Tso)
Date: Fri, 4 Jan 2002 10:40:43 -0500
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201040103.g0413m012034@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 02:03:48AM +0100
References: <200201040103.g0413m012034@burner.fokus.gmd.de>
Message-ID: <20020104104043.A17545@thunk.org>

On Fri, Jan 04, 2002 at 02:03:48AM +0100, Joerg Schilling wrote:
> Right now, when I am forced to make binary only versions of programs
> like e.g. the the Plextor firmware upgrade program, I can only do it
> for libc.so.5 and for glibc-2.2. Anything in between gives problems.

Why don't you just link your binary-only program statically?  If you
do that, then it is entirely irrelevant which libc is installed on the
system, and core kernel backwards compatibility has been quite good,
actually.  

Yes, there have been some small problems, but most of them have been
device driver specific --- which I know is a sore point for you, since
a number of those problems have been in the scsi sg/cdrom/cd-recorder
space, where you spend a lot of time.  (And thank you, by the way,
it's much appreciated!)  And when people make (or suggest)
irresponsible changes like that, whether it's non-compatible changes
to device driver bitmaps which are referenced in public API's, or
whether it's in proposing that /proc/cpuinfo should be removed, they
should be spanked.

So if you link statically, your programs will run sanely accross a
much larger part of the Linux installed base, and across a much larger
set of programs than if you link dynamically and hope for the best.

						- Ted

P.S.  On a completely unrelated note, while I have you here, how well
do DVD recorders work with Linux these days?  Some folks have claimed
that cdreocrd will "just work" --- is that true?


From schilling@fokus.gmd.de  Fri Jan  4 15:52:13 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 16:52:13 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041552.g04FqDD12946@burner.fokus.gmd.de>

>From tytso@thunk.org Fri Jan  4 16:41:00 2002

>On Fri, Jan 04, 2002 at 02:03:48AM +0100, Joerg Schilling wrote:
>> Right now, when I am forced to make binary only versions of programs
>> like e.g. the the Plextor firmware upgrade program, I can only do it
>> for libc.so.5 and for glibc-2.2. Anything in between gives problems.

>Why don't you just link your binary-only program statically?  If you
>do that, then it is entirely irrelevant which libc is installed on the
>system, and core kernel backwards compatibility has been quite good,
>actually.  

Due to a bug inside either the linker or glibc it is not possible
to link cdrecord and similar programs statically. If you like, I could
check again and send you the error messages.


>So if you link statically, your programs will run sanely accross a
>much larger part of the Linux installed base, and across a much larger
>set of programs than if you link dynamically and hope for the best.

If the ld/libc problem was fixed - may be...



>P.S.  On a completely unrelated note, while I have you here, how well
>do DVD recorders work with Linux these days?  Some folks have claimed
>that cdreocrd will "just work" --- is that true?

cdrecord-ProDVD is one of the very first DVD-R/DVD-RW recording programs.
It started 4 years ago, when a drive was 18000 $ and a media was 70 $.

As DVD recording is not a common feature and from some bad experiences with
companies who did steel in one case e.g. cdrecord/Linux for a commercial
closed source project, I am curently not making this program OSS. It would be too
simple for companies that currently don't have DVD-R technoligy to steel the
code....

You may check a test binary from

ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ProDVD/

it writes unlimited in dummy mode and limited to 1 GB in real mode.

... don't forget to use one of the latest Linux kernels as there was a bug in 
the ISO-9660 filesystem code that prevented DVD sized media to work in Linux.

Mkisofs did recently get UDF support and passed the Philips UDF conformance test
for Video DVD media. It still has to be enhanced as it currently binds
UDF name space to Joliet namespace which is a bad idea.




J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From schilling@fokus.gmd.de  Fri Jan  4 16:01:14 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 4 Jan 2002 17:01:14 +0100 (MET)
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <200201041601.g04G1Ev12955@burner.fokus.gmd.de>

>From: Thorsten Kukuk <kukuk@suse.de>


>> The standard says that the rm command has to use the rmdir() behavior in 
>> order to remove directories.

>Yes, this is what the standard says, here we agree.

And as the standard does not say that the program may have nonstandard
options that remove the need to follow the rmdir() rules, it is obvious that
the rm program must follow the rmdir() rules in all cases even when
using nonstandard options.

>> As - if you are root- you may unlink a non-empty diretory using GNUrm -d 

>You are doing here something which is not in the standard. The standard says
>nothing about "-d". So, if you use a non-standard option, the behavior
>is not documented in the standard. rm says, that it will remove directories
>with unlink if "-d" is used. So, everything is ok.

See aboove: If the nonstandard option makes the rm program to ignore the SUSv2
rules, then you must either remove the -d option or aggree that GNUrm is not
compliant to the SUSv2 standard.

>> -	a risk fot the data integrity of the machine

>But the manual page for GNUrm clearly writes that it will use "unlink".
>So it is your problem.

>> Check your keyboard: the letter "d" and the letter "f" are close to each other.

>Then you should be more carefull what you type.

There is no need to have the -d option in GNU rm as there is a "unlink" command
that doesn't have this problem and is documented in SUSv2.

The fact that there is a one letter option that is able to make gnu rm behave
different than documented in the standard is at least a risk that could easily 
be avoided if you would be forced to use the long option to activate id _and_
if the man page for GNU rm would clearly state that this option is non 
standard.

If you call "star H=gnutar ...." you will create nonstandard "tar" archives
but you will need to type a lot to do this _and_ the star man page clearly 
states that this will cause non-standard archives to be created.

If you call mkisofs with the -Joliet option or any other option that allows
mkisofs to create non ISO-9960 images to be created, it warns you that the
resulting archive will be non standard.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From ak@suse.de  Fri Jan  4 16:04:30 2002
From: ak@suse.de (Andi Kleen)
Date: 04 Jan 2002 17:04:30 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: Theodore Tso's message of "4 Jan 2002 16:41:30 +0100"
References: <200201040103.g0413m012034@burner.fokus.gmd.de.suse.lists.lsb-spec> <20020104104043.A17545@thunk.org.suse.lists.lsb-spec>
Message-ID: <p73sn9m9k6p.fsf@oldwotan.suse.de>

Theodore Tso <tytso@mit.edu> writes:

> On Fri, Jan 04, 2002 at 02:03:48AM +0100, Joerg Schilling wrote:
> > Right now, when I am forced to make binary only versions of programs
> > like e.g. the the Plextor firmware upgrade program, I can only do it
> > for libc.so.5 and for glibc-2.2. Anything in between gives problems.
> 
> Why don't you just link your binary-only program statically?  If you
> do that, then it is entirely irrelevant which libc is installed on the
> system, and core kernel backwards compatibility has been quite good,
> actually.  

If he wants to link to any LGPLed library like glibc he would need
to ship object files in this case, allowing a relink. Otherwise it would
violate the LGPL. 

Also glibc needs to be rebuilt to be able to link completely statically;
by default it always loads the name service modules dynamically. 

-Andi


From kukuk@suse.de  Fri Jan  4 16:06:46 2002
From: kukuk@suse.de (Thorsten Kukuk)
Date: Fri, 4 Jan 2002 17:06:46 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041601.g04G1Ev12955@burner.fokus.gmd.de>
References: <200201041601.g04G1Ev12955@burner.fokus.gmd.de>
Message-ID: <20020104170646.A4558@suse.de>

On Fri, Jan 04, Joerg Schilling wrote:

> >> The standard says that the rm command has to use the rmdir() behavior in 
> >> order to remove directories.
> 
> >Yes, this is what the standard says, here we agree.
> 
> And as the standard does not say that the program may have nonstandard
> options that remove the need to follow the rmdir() rules, it is obvious that
> the rm program must follow the rmdir() rules in all cases even when
> using nonstandard options.

No, where does this stand? Nonstandard options are for nonstandard 
cases. If you use only standard options, GNUrm is standard conform.

As already written: Please show me the text in the standard, which
forbids this.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:23:10 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:23:10 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <200201041601.g04G1Ev12955@burner.fokus.gmd.de> from "Joerg Schilling" at Jan 04, 2002 05:01:14 PM
Message-ID: <E16MX7e-0004WQ-00@the-village.bc.nu>

> And as the standard does not say that the program may have nonstandard
> options that remove the need to follow the rmdir() rules, it is obvious that
> the rm program must follow the rmdir() rules in all cases even when
> using nonstandard options.

The standard does not say that a command cannot have non standard options
that do nonstandard things.

Alan


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:26:24 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:26:24 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104100841.O616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 10:10:09 AM
Message-ID: <E16MXAm-0004XZ-00@the-village.bc.nu>

> I did read the app notes pertaining to this, and felt that it was an excessive
> burdon on the application considering the kernel had already done the work.

The things that actually matter are like 10 lines of GNU C with a little
__asm__ block. The code is out there in GPL form and its shorter than
parsing /proc


From dbb@caldera.com  Fri Jan  4 16:23:35 2002
From: dbb@caldera.com (Doug Beattie)
Date: Fri, 04 Jan 2002 09:23:35 -0700
Subject: LSB1.1: /proc/cpuinfo
References: <E16MX7e-0004WQ-00@the-village.bc.nu>
Message-ID: <3C35D707.84E7E9CA@caldera.com>

Then, in general the specification should state that any options not
documented, but found to be present in any command/function, should
not be used as they will not have been tested and results cannot be
guaranteed.

Can we make a blanket statement that will satisfy all such conditions
so we don't have to go through and document each and every situation
within the specification?


Alan Cox wrote:
> 
> > And as the standard does not say that the program may have nonstandard
> > options that remove the need to follow the rmdir() rules, it is obvious that
> > the rm program must follow the rmdir() rules in all cases even when
> > using nonstandard options.
> 
> The standard does not say that a command cannot have non standard options
> that do nonstandard things.
> 
> Alan
> 
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org

-- 
Douglas B. Beattie
------------------
Test Architect - Caldera, Inc.
dbb@caldera.com


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:36:47 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:36:47 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <3C35D707.84E7E9CA@caldera.com> from "Doug Beattie" at Jan 04, 2002 09:23:35 AM
Message-ID: <E16MXKp-0004Za-00@the-village.bc.nu>

> Then, in general the specification should state that any options not
> documented, but found to be present in any command/function, should
> not be used as they will not have been tested and results cannot be
> guaranteed.

The LSB doesn't define what happens when you use a command or library
function that is not in the LSB. If you use glibc internal functions you
will get burned (especially if the folks trying to replace glibc with 
something much lighter actually succeed)


From dbb@caldera.com  Fri Jan  4 16:30:21 2002
From: dbb@caldera.com (Doug Beattie)
Date: Fri, 04 Jan 2002 09:30:21 -0700
Subject: LSB1.1: /proc/cpuinfo
References: <E16MXKp-0004Za-00@the-village.bc.nu>
Message-ID: <3C35D89D.BC2DBF4D@caldera.com>

Alan Cox wrote:
> 
> > Then, in general the specification should state that any options not
> > documented, but found to be present in any command/function, should
> > not be used as they will not have been tested and results cannot be
> > guaranteed.
> 
> The LSB doesn't define what happens when you use a command or library
> function that is not in the LSB. If you use glibc internal functions you
> will get burned (especially if the folks trying to replace glibc with
> something much lighter actually succeed)

So are you saying that we should go through the process of adding
specifics to each command for the next version of the specification so
such problems can be avoided?

What would you recommend?


From anderson@metrolink.com  Fri Jan  4 16:34:01 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 11:34:01 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXAm-0004XZ-00@the-village.bc.nu>
Message-ID: <20020104113135.E616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> > I did read the app notes pertaining to this, and felt that it was an excessive
> > burdon on the application considering the kernel had already done the work.
>
> The things that actually matter are like 10 lines of GNU C with a little
> __asm__ block. The code is out there in GPL form and its shorter than
> parsing /proc

If you are refering to the code in arch/i386/kernel/setup.c, the code that
determines the features is spread over several hundred lines of code which
makes decisions based on model info and various erratta.

If an application included this directly into itself, then it wouldn't be able
to handle new CPU models, erratta, etc. By letting the kernel handle it, it
will always get the best possible info.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From anderson@metrolink.com  Fri Jan  4 16:38:09 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 11:38:09 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXKp-0004Za-00@the-village.bc.nu>
Message-ID: <20020104113642.S616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> The LSB doesn't define what happens when you use a command or library
> function that is not in the LSB. If you use glibc internal functions you
> will get burned (especially if the folks trying to replace glibc with
> something much lighter actually succeed)

>From Chapter 1: Definitions.

Non-LSB-Compliant Application

An application which has been written to include system routines, commands, or
other resources not included in this document, or which has been compiled into
a format different from those specified here, or which does not behave as
specified in this document.



This sort of says it, though in an indirect way.



                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:52:47 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:52:47 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104113135.E616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 11:34:01 AM
Message-ID: <E16MXaJ-0004dv-00@the-village.bc.nu>

> If you are refering to the code in arch/i386/kernel/setup.c, the code that
> determines the features is spread over several hundred lines of code which
> makes decisions based on model info and various erratta.

What do apps actually care about
	-	MMX
	-	Athlon MMX2
	-	SSE
	-	SSE2
and occasionally
	-	CPU vendor
	-	CPU model

Not rocket science


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 16:54:56 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 16:54:56 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <3C35D89D.BC2DBF4D@caldera.com> from "Doug Beattie" at Jan 04, 2002 09:30:21 AM
Message-ID: <E16MXcO-0004eo-00@the-village.bc.nu>

> So are you saying that we should go through the process of adding
> specifics to each command for the next version of the specification so
> such problems can be avoided?

We already have the needed specifics I think. If you use options that are
not documented well bad luck. Jeff took the view that we documented too much
and had we been working "from scratch" not "from existing practice" I'd
agree. Certainly we don't want to add documentation of more options unless
we can't avoid it.


From anderson@metrolink.com  Fri Jan  4 16:50:11 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 11:50:11 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXaJ-0004dv-00@the-village.bc.nu>
Message-ID: <20020104114855.X616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> What do apps actually care about
> 	-	MMX
> 	-	Athlon MMX2
> 	-	SSE
> 	-	SSE2

Image manipulation programs need a way to determine the most efficient
algorithm/instructions to use.

> and occasionally
> 	-	CPU vendor
> 	-	CPU model

Probably not as much here, except as how this info may be used to identify
erratta on a feature that is important to the program.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:05:06 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:05:06 +0000 (GMT)
Subject: [New Proposal] cpuinfo, but not directly via /proc
In-Reply-To: <20020104133051.A10241@lst.de> from "Ralf Flaxa" at Jan 04, 2002 01:30:51 PM
Message-ID: <E16MXmE-0004kc-00@the-village.bc.nu>

> 	o number of CPUs

sysconf() - there is a documented interface for this already

> 	o CPU family and type
> 	o BogoMips (per CPU and/or overall)

Bogomips are pretty worthless values

> 2. features specific to a processor
> 	o for x86 e.g. the "flags" and *_bug fields
> 	o info about FPU, MMU and the like

FPU/MMU/cache stuff is one place where not everything can be acquired
trivially - especially non x86

Alan


From mei@asdis.de  Fri Jan  4 16:54:10 2002
From: mei@asdis.de (Bodo Meissner)
Date: Fri, 4 Jan 2002 17:54:10 +0100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020103175058.S616-100000@trantor.sc.metrolink.com>; from anderson@metrolink.com on Don, Jan 03, 2002 at 23:53:38 +0100
References: <20020103232651.A878@caldera.de> <20020103175058.S616-100000@trantor.sc.metrolink.com>
Message-ID: <20020104175410.A3882@natira>

On Tue, 03 Jan 2002 23:53:38 Stuart Anderson wrote:
> Can you please provide some examples? All of the examples I was able to
> aquire
> fit the description (actually, it was written to fit the exmaples 8-)).

SuSE Linux running on S/390 (emulator "hercules"):

hercules%mei ~> uname -a
Linux hercules 2.2.16 #1 SMP Wed May 30 08:45:25 GMT 2001 s390 unknown
hercules%mei ~> cat /proc/cpuinfo
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 86.42
processor 0: version = 00,  identification = 002623,  machine = 3090
processor 1: version = 00,  identification = 102623,  machine = 3090

SuSE Linux (newer version) running on S/390 (real system, don't know exact
type):

asdis@linux0:~ > uname -a
Linux linux0 2.4.7-SuSE-SMP #1 SMP Tue Oct 30 22:39:07 GMT 2001 s390
unknown
asdis@linux0:~ > cat /proc/cpuinfo 
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 411.23
processor 0: version = FF,  identification = 111000,  machine = 7060
processor 1: version = FF,  identification = 111111,  machine = 7060




From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:07:11 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:07:11 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104114855.X616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 11:50:11 AM
Message-ID: <E16MXoF-0004lA-00@the-village.bc.nu>

> > What do apps actually care about
> > 	-	MMX
> > 	-	Athlon MMX2
> > 	-	SSE
> > 	-	SSE2
> 
> Image manipulation programs need a way to determine the most efficient
> algorithm/instructions to use.

Which is down to MMX, MMX2, SSE, SSE2. Take a look at real existing apps
like mplayer, mp1e and xine.

> Probably not as much here, except as how this info may be used to identify
> erratta on a feature that is important to the program.

The x86 CPU errata are kernel handled so Im not sure that is actually an
issue.


From mats.d.wichmann@intel.com  Fri Jan  4 17:00:36 2002
From: mats.d.wichmann@intel.com (Wichmann, Mats D)
Date: Fri, 4 Jan 2002 09:00:36 -0800
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <39B5C4829263D411AA93009027AE9EBB140DA64F@FMSMSX35>

> What do apps actually care about
> 	-	MMX
> 	-	Athlon MMX2
> 	-	SSE
> 	-	SSE2
> and occasionally
> 	-	CPU vendor
> 	-	CPU model
> 
> Not rocket science

And CPU speed, plus #CPUs.

Although it's probably anathema to mention it,
some of these criteria are used to determine
licensing thingies in some circles, as in
"price depends on raw power of the machine".

 


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:17:01 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:17:01 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <39B5C4829263D411AA93009027AE9EBB140DA64F@FMSMSX35> from "Wichmann, Mats D" at Jan 04, 2002 09:00:36 AM
Message-ID: <E16MXxl-0004nU-00@the-village.bc.nu>

> And CPU speed, plus #CPUs.

#CPU's is in sysconf() already. (Yes glibc happens to then go poke in 
/proc at the moment but that doesnt mean we have to assume glibc wont in
the future use a kernel facility thats more convenient. In fact newer
glibcs will probably need updating to get the full benefit of the upcoming
CPU hot plug patches (sysconf in POSIX/SuS already supports asking for
"number of cpus" and "number of cpus online"

> some of these criteria are used to determine
> licensing thingies in some circles, as in
> "price depends on raw power of the machine".

Which has nothing to do with the CPU speed nowdays. A 2GHz PIV is much like
a 1.6GHz Athlon. A 1GHz C3 is much like a 700MHz Celeron. And of course the
ratio is heavily application dependant since the DDR RAM on an Athlon
matters to some apps while the bus bandwidth of the PIV matters to others.

Alan


From anderson@metrolink.com  Fri Jan  4 17:10:59 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Fri, 4 Jan 2002 12:10:59 -0500 (EST)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <E16MXoF-0004lA-00@the-village.bc.nu>
Message-ID: <20020104120701.C616-100000@trantor.sc.metrolink.com>

On Fri, 4 Jan 2002, Alan Cox wrote:

> > > What do apps actually care about
> > > 	-	MMX
> > > 	-	Athlon MMX2
> > > 	-	SSE
> > > 	-	SSE2
> >
> > Image manipulation programs need a way to determine the most efficient
> > algorithm/instructions to use.
>
> Which is down to MMX, MMX2, SSE, SSE2. Take a look at real existing apps
> like mplayer, mp1e and xine.

Are you saying that these are all that is needed, and that this problem has
already been solved?

I've seen comments that indicate that depending on SIGILL and SIGFPE to
determine that something isn't present may not be fool proof. Also, it takes
as much or more code to set up and test this as it would to read /proc/cpuinfo.

> > Probably not as much here, except as how this info may be used to identify
> > erratta on a feature that is important to the program.
>
> The x86 CPU errata are kernel handled so Im not sure that is actually an
> issue.

In setup.c there are several place where feature bits are turned on or off
based model and errata info. Why should this kind of handlig be duplicated?
Also, what about furture situations? There is no gurantee that a future bug
can be handled transparently to the app, and at no performance cost.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From alan@lxorguk.ukuu.org.uk  Fri Jan  4 17:32:31 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Jan 2002 17:32:31 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <20020104120701.C616-100000@trantor.sc.metrolink.com> from "Stuart Anderson" at Jan 04, 2002 12:10:59 PM
Message-ID: <E16MYCl-0004qZ-00@the-village.bc.nu>

> > Which is down to MMX, MMX2, SSE, SSE2. Take a look at real existing apps
> > like mplayer, mp1e and xine.
> 
> Are you saying that these are all that is needed, and that this problem has
> already been solved?

I am saying that the existing applications don't show any evidence that
we need to document these and use cpuid quite successfully themselves

> I've seen comments that indicate that depending on SIGILL and SIGFPE to
> determine that something isn't present may not be fool proof. Also, it takes

For x86 SIGILL is safe barring some obscure errata which are not going to
bite anyone in normal use. FPU is always present but may be emulated. You
can again check this with cpuid.

> In setup.c there are several place where feature bits are turned on or off
> based model and errata info. Why should this kind of handlig be duplicated?

It wouldn't be. Applications cannot control those feature flags. 

If the code was complex I would be worry, but it is less code to use
cpuid for things like MMX checking than to go regexping through the /proc
file. It is also very well documented (once you realise Intel try and make
you run the competitors chips as a 486 and the others likewise about
chips that they didnt make)

Alan


From mats.d.wichmann@intel.com  Fri Jan  4 18:10:43 2002
From: mats.d.wichmann@intel.com (Wichmann, Mats D)
Date: Fri, 4 Jan 2002 10:10:43 -0800
Subject: LSB1.1: /proc/cpuinfo
Message-ID: <39B5C4829263D411AA93009027AE9EBB140DA680@FMSMSX35>

> #CPU's is in sysconf() already. (Yes glibc happens to then go poke in 
> /proc at the moment but that doesnt mean we have to assume 
> glibc wont in
> the future use a kernel facility thats more convenient. In fact newer
> glibcs will probably need updating to get the full benefit of 
> the upcoming
> CPU hot plug patches (sysconf in POSIX/SuS already supports asking for
> "number of cpus" and "number of cpus online"

Just curious... is there any mechanism for processor reservation/binding
present or planned?


> > some of these criteria are used to determine
> > licensing thingies in some circles, as in
> > "price depends on raw power of the machine".
> 
> Which has nothing to do with the CPU speed nowdays. A 2GHz 
> PIV is much like
> a 1.6GHz Athlon. A 1GHz C3 is much like a 700MHz Celeron. And 
> of course the
> ratio is heavily application dependant since the DDR RAM on an Athlon
> matters to some apps while the bus bandwidth of the PIV 
> matters to others.

Who ever said irrelevant criteria didn't still matter to people? 

'Far as I can tell, the software industry has been trying to
figure out how to license enterprise-class software for the
whole 21 years I've been in the business and probably a lot
longer, and still don't really have a good model.

Mats


From hpa@zytor.com  Sat Jan  5 02:53:57 2002
From: hpa@zytor.com (H. Peter Anvin)
Date: Fri, 04 Jan 2002 18:53:57 -0800
Subject: LSB1.1: /proc/cpuinfo
References: <E16MX7e-0004WQ-00@the-village.bc.nu> <3C35D707.84E7E9CA@caldera.com>
Message-ID: <3C366AC5.1070607@zytor.com>

Doug Beattie wrote:

> Then, in general the specification should state that any options not
> documented, but found to be present in any command/function, should
> not be used as they will not have been tested and results cannot be
> guaranteed.
> 
> Can we make a blanket statement that will satisfy all such conditions
> so we don't have to go through and document each and every situation
> within the specification?
> 


This is usually handled by invoking the magic phrase "a strictly 
conforming application shall not invoke undefined behaviour."

	-hpa



From alan@lxorguk.ukuu.org.uk  Sat Jan  5 00:32:26 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Sat, 5 Jan 2002 00:32:26 +0000 (GMT)
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <39B5C4829263D411AA93009027AE9EBB140DA680@FMSMSX35> from "Wichmann, Mats D" at Jan 04, 2002 10:10:43 AM
Message-ID: <E16Mel8-0006C9-00@the-village.bc.nu>

> > CPU hot plug patches (sysconf in POSIX/SuS already supports asking for
> > "number of cpus" and "number of cpus online"
> 
> Just curious... is there any mechanism for processor reservation/binding
> present or planned?

Open discussion at the moment. The kernel has the hooks. There are arguments
about which scheme to use. The pset one is probably the most standard.

> 'Far as I can tell, the software industry has been trying to
> figure out how to license enterprise-class software for the
> whole 21 years I've been in the business and probably a lot
> longer, and still don't really have a good model.

Fine. But that is their problem 8). VIA already has documentation for
how to check the speed of a CPU. Intel seem to have NDA'd theirs but I'm
sure they can provide that algorithm easily enough.


From hp@redhat.com  Sat Jan  5 18:16:03 2002
From: hp@redhat.com (Havoc Pennington)
Date: 05 Jan 2002 13:16:03 -0500
Subject: bugs just filed
Message-ID: <y5wvgegfyu4.fsf@icon.labs.redhat.com>


Hi,

I'm not normally involved in LSB stuff and haven't followed this list,
but have been writing some docs for Red Hat related to the "Command
Behavior" section and saw the link to the nice review form on Slashdot
yesterday, so just went through the commands section and filed a bunch
of bugs. I know it's annoying to do that mere hours after the
deadline. ;-) As I said, I am clueless LSB-wise. Hopefully the
comments are useful for the next version of the spec.

I filed separate reports for each change but they are mostly in some
major groups:

 - command line options that conflict with SUS in current
   implementations but are not really essential should not be 
   specified. e.g. "df -t" can just be left implementation dependent, 
   there is no reason to force SUS incompliance here, the option 
   isn't exactly a vital feature.
   
   At minimum, annotation should be added that POSIXLY_CORRECT 
   may change the behavior of these options, right?

 - the wording "--foo is not supported" seems to imply that an 
   option must not be supported, though I doubt that was intended.
   I think wording such as "--foo is undefined" or "--foo is
   implementation-dependent" would be better.
 
 - I don't understand why the LSB specifies interactive programs;
   those are not designed to be an ABI/API and are not a reasonable
   ABI/API. For example, I don't see how "su" can be used
   programatically (or if it can, only its noninteractive aspects
   should be described in the spec, IMO).

   Due to internationalization, checks such as isatty(), possible
   UI enhancements that change prompts, etc., interactive 
   command behavior is just not a reasonable thing to rely on.

Something I didn't file bugs on for the most part: in many cases LSB
seems to simply catalog all options in some version of a
utility. Wouldn't it be better to start with SUS options and
conservatively add only some of the really useful extensions, instead
of listing them wholesale?

I did file a bug on one egregious example, "patch --debug" makes no
sense whatsoever as part of an API/ABI spec, IMO. It's not like an ISV
app should or could use that option, so why is it required for LSB
compliance?

Thanks for everyone's hard work.

Havoc



From anderson@metrolink.com  Mon Jan  7 00:02:45 2002
From: anderson@metrolink.com (Stuart Anderson)
Date: Sun, 6 Jan 2002 19:02:45 -0500 (EST)
Subject: bugs just filed
In-Reply-To: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
Message-ID: <20020106190216.V422-100000@trantor.sc.metrolink.com>

On 5 Jan 2002, Havoc Pennington wrote:

>
> Hi,
>
> I'm not normally involved in LSB stuff and haven't followed this list,
> but have been writing some docs for Red Hat related to the "Command
> Behavior" section and saw the link to the nice review form on Slashdot
> yesterday, so just went through the commands section and filed a bunch
> of bugs. I know it's annoying to do that mere hours after the
> deadline. ;-) As I said, I am clueless LSB-wise. Hopefully the
> comments are useful for the next version of the spec.

Don't worry about it being as little late. They are still very useful, and
greatly appreciated.


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
http://www.metrolink.com/                        XFree86 Core Team


From cyeoh@samba.org  Mon Jan  7 01:34:20 2002
From: cyeoh@samba.org (Christopher Yeoh)
Date: Mon, 7 Jan 2002 12:34:20 +1100
Subject: bugs just filed
In-Reply-To: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
References: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
Message-ID: <15416.64284.803080.568825@gargle.gargle.HOWL>

Havoc Pennington writes:
>  - the wording "--foo is not supported" seems to imply that an 
>    option must not be supported, though I doubt that was intended.
>    I think wording such as "--foo is undefined" or "--foo is
>    implementation-dependent" would be better.

I agree the wording could be clearer.  The above sort of wording is
used where an option for a command is required by the SUS but at the
time of the writing of the specifiction was not supported by the
implementations of that command on Linux. In other words for people
porting to Linux they can't rely on that behaviour even if their app
is SUS compliant.

>  - I don't understand why the LSB specifies interactive programs;
>    those are not designed to be an ABI/API and are not a reasonable
>    ABI/API. For example, I don't see how "su" can be used
>    programatically (or if it can, only its noninteractive aspects
>    should be described in the spec, IMO).

Some interactive programs are useful when developers want to give
users documentation on what to do when some manual configuration or
repairing is required.

> I did file a bug on one egregious example, "patch --debug" makes no
> sense whatsoever as part of an API/ABI spec, IMO. It's not like an ISV
> app should or could use that option, so why is it required for LSB
> compliance?

I agree this option didn't need to have been included. In general I
think that including options beyond what is required by SUS is better
as writing scripts can be a lot easier when you don't have to
constrain yourself to SUS only options. From a distribution
implementation point of view the options that were included with the
commands were a subset that existed on most distributions (except in
cases where implementations of a given command were so different
between distributions that the one that was seen as best was chosen).

Regards,

Chris
-- 
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia


From rusty@rustcorp.com.au  Mon Jan  7 01:05:45 2002
From: rusty@rustcorp.com.au (Rusty Russell)
Date: Mon, 7 Jan 2002 12:05:45 +1100
Subject: LSB1.1: /proc/cpuinfo
In-Reply-To: <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
References: <20020103190219.B27938@thyrsus.com>
 <Pine.GSO.4.21.0201031944320.23693-100000@weyl.math.psu.edu>
Message-ID: <20020107120545.57570c8a.rusty@rustcorp.com.au>

On Thu, 3 Jan 2002 19:56:51 -0500 (EST)
Alexander Viro <viro@math.psu.edu> wrote:

> It's more than just a name.
> 	a) granularity.  Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> 	b) tree layout policy (lack thereof, to be precise).
> 	c) horribly bad layout of many, many files.  Any file exported by

As usual, Al has hit the highpoints (five lines vs. >> 1000 msgs of proc
flamewars over time).  At risk of boring regular readers, I shall expand:

There is /proc, and /proc/sys.  /proc is a pain to use in the kernel (seq_*
made this better recently, but far from perfect), but is flexible.
/proc/sys (aka sysctl) is easier to use, but a PITA for dynamic entries.

The "manual formatting" nature of /proc entries has lead to (c) mentioned by
Al.  This can be alleviated by making the simplest method of exporting data
the correct one (ie. more like /proc/sys).

The tree layout issues are more complicated.  In particular, the following
namespaces should be equivalent:
   Boot command line: 3c509.debug=1
   Module parameter: insmod 3c509 debug=1
   proc entry: echo 1 > .../3c509/debug

Finally, I consider the granularity issue a red-herring: if it's in the
kernel, it should be in a logical location.

Now, I have a sample patch for a simple "/proc/sys" replacement which follows
the "one value per file" (similar to the current proc/sys) and
"dynamic is easy" principle (required for widespread use).  I also have
module loader rewrite and boot param unification patches.

	http://www.kernel.org/pub/linux/kernel/people/rusty

Important to realize that we will be stuck with the current interfaces for
another stable kernel version (backwards compatibility is a WIP).

Once Linus accepts general patches again I shall start pushing things to
him.

Hope that helps,
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.


From hpa@zytor.com  Mon Jan  7 17:26:50 2002
From: hpa@zytor.com (H. Peter Anvin)
Date: Mon, 07 Jan 2002 09:26:50 -0800
Subject: LSB1.1: /proc/cpuinfo
References: <E16Mel8-0006C9-00@the-village.bc.nu>
Message-ID: <3C39DA5A.8070102@zytor.com>

Alan Cox wrote:

> 
> Fine. But that is their problem 8). VIA already has documentation for
> how to check the speed of a CPU. Intel seem to have NDA'd theirs but I'm
> sure they can provide that algorithm easily enough.
> 


If with "speed" you mean "frequency" it's trivial to measure using RDTSC.
 This measurement can be done in userspace, and is also exported by the
kernel into /proc/cpuinfo.

	-hpa



From hch@caldera.de  Mon Jan  7 19:59:00 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Mon, 7 Jan 2002 20:59:00 +0100
Subject: Proposal: cpuinfo(1)
Message-ID: <20020107205900.A28710@caldera.de>

[Caldera hat on and switch to constructive mode]

As current /proc/cpuinfo is unportable and thus not suitable for LSB
in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.

Cpuinfo is supposed to allow retrieving a subset of the contents of
the i386 /proc/cpuinfo in a portable way.

Below is my current design in form of a manpage:


cpuinfo(1)              System General Commands Manual              cpuinfo=
(1)

N=08NA=08AM=08ME=08E
     c=08cp=08pu=08ui=08in=08nf=08fo=08o - get information about installed =
CPU(s)

S=08SY=08YN=08NO=08OP=08PS=08SI=08IS=08S
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-b=08b
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-c=08c
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-f=08f
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-n=08n
     c=08cp=08pu=08ui=08in=08nf=08fo=08o -=08-p=08p

D=08DE=08ES=08SC=08CR=08RI=08IP=08PT=08TI=08IO=08ON=08N
     c=08cp=08pu=08ui=08in=08nf=08fo=08o is used to retreive information ab=
out the processor installed in
     the currently running system.  supports the following options:

     -=08-b=08b      Report the sum of the bogo-mips values of all online p=
rocessors.

     -=08-c=08c      Report cache-size of the biggest CPU-controlled hardwa=
re cache.

     -=08-f=08f      Report CPU features that are supported by all online p=
rocessors.
             For each CPU feature a word with up to ten characters is outpu=
t,
             a whitespace is used as separator.  The values are architectur=
e-
             dependand.

     -=08-n=08n      Report number of online processors.

     -=08-p=08p      Report CPU types of all online processors.  For each C=
PU one
             there is one line of output, containing the free-formed string
             reported by the hardware/firmware.

     If c=08cp=08pu=08ui=08in=08nf=08fo=08o is unable to determine the want=
ed information it returns the
     sring "unknown".

S=08ST=08TA=08AN=08ND=08DA=08AR=08RD=08DS=08S
     LSB 1.1

B=08BU=08UG=08GS=08S
     Due to incoherent underlying interfaces c=08cp=08pu=08ui=08in=08nf=08f=
o=08o might give inaccurate
     results on some kernel versions or architectures.

S=08SE=08EE=08E A=08AL=08LS=08SO=08O
     uname(1), proc(5)

LSB 1.1                        January 04, 2002                        LSB =
1.1


From wichert@wiggy.net  Mon Jan  7 21:00:56 2002
From: wichert@wiggy.net (Wichert Akkerman)
Date: Mon, 7 Jan 2002 22:00:56 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107205900.A28710@caldera.de>
References: <20020107205900.A28710@caldera.de>
Message-ID: <20020107210055.GA14287@wiggy.net>

Previously Christoph Hellwig wrote:
>      -=08-b=08b      Report the sum of the bogo-mips values of all online=
 processors.

Having them individually would be useful as well I guess. I suspect
they are not guaranteerd the same for all processors in a multiprocessor
machine.

>      -=08-c=08c      Report cache-size of the biggest CPU-controlled hard=
ware cache.

Is this useful?=20

>      If c=08cp=08pu=08ui=08in=08nf=08fo=08o is unable to determine the wa=
nted information it returns the
>      sring "unknown".

sring -> string

Having a subarchitecture might also be useful. Consider the multiple
types of m68k machines for example. This information can be gotten
from either /proc/hardware or /proc/cpuinfo depending on the
architecture.

Wichert.
--=20
  _________________________________________________________________
 /wichert@wiggy.net         This space intentionally left occupied \
| wichert@deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


From mstone@cs.loyola.edu  Mon Jan  7 21:23:20 2002
From: mstone@cs.loyola.edu (Michael Stone)
Date: Mon, 7 Jan 2002 16:23:20 -0500
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107210055.GA14287@wiggy.net>; from wichert@wiggy.net on Mon, Jan 07, 2002 at 10:00:56PM +0100
References: <20020107205900.A28710@caldera.de> <20020107210055.GA14287@wiggy.net>
Message-ID: <20020107162320.A31771@justice.loyola.edu>

On Mon, Jan 07, 2002 at 10:00:56PM +0100, Wichert Akkerman wrote:
> Previously Christoph Hellwig wrote:
> >      -=08-b=08b      Report the sum of the bogo-mips values of all onli=
ne processors.
>=20
> Having them individually would be useful as well I guess. I suspect
> they are not guaranteerd the same for all processors in a multiprocessor
> machine.
>=20
> >      -=08-c=08c      Report cache-size of the biggest CPU-controlled ha=
rdware cache.
>=20
> Is this useful?=20

You asked if that was useful but didn't ask if reporting bogomips was
useful?

--=20
Mike Stone


From alan@lxorguk.ukuu.org.uk  Tue Jan  8 13:57:33 2002
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue, 8 Jan 2002 13:57:33 +0000 (GMT)
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107205900.A28710@caldera.de> from "Christoph Hellwig" at Jan 07, 2002 08:59:00 PM
Message-ID: <E16Nwkv-0006TW-00@the-village.bc.nu>

> As current /proc/cpuinfo is unportable and thus not suitable for LSB
> in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> 
> Cpuinfo is supposed to allow retrieving a subset of the contents of
> the i386 /proc/cpuinfo in a portable way.

I think thats an excellent idea.

> 


From gk4@austin.ibm.com  Tue Jan  8 14:30:06 2002
From: gk4@austin.ibm.com (George Kraft IV)
Date: Tue, 08 Jan 2002 08:30:06 -0600
Subject: gLSB and psLSB review extended until Monday January 14th, 2002
Message-ID: <3C3B026E.2DFF04E3@austin.ibm.com>

This is a multi-part message in MIME format.
--------------EF2ABF44D87F2E7DD3C21927
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The LSB delivers again, the LSB has updated and published the gLSB v1.1 draft
for review. The LSB has also published for review the new psLSB for IA32 v1.1
draft and the completed LSB v1.0.1 Test Suites.  Review has been extended to
Monday January 14th, 2002; however, the LSB welcomes comments from the
community at any time.

-- 
George Kraft IV
gk4@austin.ibm.com
--------------EF2ABF44D87F2E7DD3C21927
Content-Type: text/html; charset=us-ascii;
 name="gLSB.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="gLSB.html"

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i686) [Netscape]">
   <title>LSB Delivers Again</title>
</head>
<body>
The LSB delivers again, the LSB has updated and published
the <a href="http://www.linuxbase.org/spec/lsbreview.html">gLSB v1.1 draft</a>
for review. The LSB has also published for review the new
<a href="http://www.linuxbase.org/spec/lsbia32review.html">psLSB
for IA32 v1.1 draft</a> and the completed
<a href="ftp://ftp.freestandards.org/pub/lsb/test_suites/released-1.0.1/">LSB
v1.0.1 Test Suites</a>.&nbsp; Review has been extended to Monday January
14th, 2002; however, the LSB welcomes comments from the community at any
time."
<p>George (gk4)
</body>
</html>

--------------EF2ABF44D87F2E7DD3C21927--


From hp@redhat.com  Tue Jan  8 22:36:14 2002
From: hp@redhat.com (Havoc Pennington)
Date: 08 Jan 2002 17:36:14 -0500
Subject: bugs just filed
In-Reply-To: <15416.64284.803080.568825@gargle.gargle.HOWL>
References: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
 <15416.64284.803080.568825@gargle.gargle.HOWL>
Message-ID: <y5wn0zoii75.fsf@icon.labs.redhat.com>


Christopher Yeoh <cyeoh@samba.org> writes: 
> >  - I don't understand why the LSB specifies interactive programs;
> >    those are not designed to be an ABI/API and are not a reasonable
> >    ABI/API. For example, I don't see how "su" can be used
> >    programatically (or if it can, only its noninteractive aspects
> >    should be described in the spec, IMO).
> 
> Some interactive programs are useful when developers want to give
> users documentation on what to do when some manual configuration or
> repairing is required.

That makes sense, but perhaps the spec should make a point of saying
that only the existence of the command and its general behavior are
guaranteed - that its prompts and such may change. It worries me a
bit that developers may be misled into thinking that su or passwd or
whatever have a fixed ABI.
 
> I agree this option didn't need to have been included. In general I
> think that including options beyond what is required by SUS is better
> as writing scripts can be a lot easier when you don't have to
> constrain yourself to SUS only options. From a distribution
> implementation point of view the options that were included with the
> commands were a subset that existed on most distributions (except in
> cases where implementations of a given command were so different
> between distributions that the one that was seen as best was chosen).

I'd agree that useful extensions to the SUS make sense. I don't see
including extensions that are clearly silly like --debug, or those
that are not especially useful and conflict with (vs. extend) the SUS,
though, such as df -t. Just adding a note that POSIXLY_CORRECT may
change behavior is a possible compromise here.

As currently written, I don't think it's possible to be both SUS and
LSB compliant, and that's kind of an unfortunate limitation for
Linux. I didn't see any cases in the "commands" section where the
SUS/LSB conflict was really compellingly worth having.

Havoc


From cyeoh@samba.org  Wed Jan  9 02:53:07 2002
From: cyeoh@samba.org (Christopher Yeoh)
Date: Wed, 9 Jan 2002 13:53:07 +1100
Subject: bugs just filed
In-Reply-To: <y5wn0zoii75.fsf@icon.labs.redhat.com>
References: <y5wvgegfyu4.fsf@icon.labs.redhat.com>
 <15416.64284.803080.568825@gargle.gargle.HOWL>
 <y5wn0zoii75.fsf@icon.labs.redhat.com>
Message-ID: <15419.45203.341095.51462@gargle.gargle.HOWL>

Havoc Pennington writes:
> 
> That makes sense, but perhaps the spec should make a point of saying
> that only the existence of the command and its general behavior are
> guaranteed - that its prompts and such may change. It worries me a
> bit that developers may be misled into thinking that su or passwd or
> whatever have a fixed ABI.

Sure, and this is also true for non-interactive commands. If the
output format is not defined, then relying on it staying the same is
dangerous.

> I'd agree that useful extensions to the SUS make sense. I don't see
> including extensions that are clearly silly like --debug, or those
> that are not especially useful and conflict with (vs. extend) the SUS,
> though, such as df -t. Just adding a note that POSIXLY_CORRECT may
> change behavior is a possible compromise here.

In the case of "df -t" I would suggest that the -t option be stated as
undefined behaviour, but --type preserved so the functionality is
still available. Its a bit trickier where the functionality is only
available through an option which would conflict with SUS. Longer term
we should speak with the maintainer of the command(s) in question.

Regards,

Chris
-- 
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia


From hch@caldera.de  Wed Jan  9 20:50:45 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Wed, 9 Jan 2002 21:50:45 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <E16Nwkv-0006TW-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Tue, Jan 08, 2002 at 01:57:33PM +0000
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu>
Message-ID: <20020109215045.A11217@caldera.de>

On Tue, Jan 08, 2002 at 01:57:33PM +0000, Alan Cox wrote:
> > As current /proc/cpuinfo is unportable and thus not suitable for LSB
> > in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> > 
> > Cpuinfo is supposed to allow retrieving a subset of the contents of
> > the i386 /proc/cpuinfo in a portable way.
> 
> I think thats an excellent idea.

The first release of cpuinfo(1), which is still i386-only can be found
at:

	http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz

Please give me feedback (and/or patches) for this version if possible.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From gk4@austin.ibm.com  Wed Jan  9 22:39:05 2002
From: gk4@austin.ibm.com (George Kraft IV)
Date: Wed, 09 Jan 2002 16:39:05 -0600
Subject: Proposal: cpuinfo(1)
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de>
Message-ID: <3C3CC689.9D7D439C@austin.ibm.com>

Christoph Hellwig wrote:
> 
> On Tue, Jan 08, 2002 at 01:57:33PM +0000, Alan Cox wrote:
> > > As current /proc/cpuinfo is unportable and thus not suitable for LSB
> > > in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> > >
> > > Cpuinfo is supposed to allow retrieving a subset of the contents of
> > > the i386 /proc/cpuinfo in a portable way.
> >
> > I think thats an excellent idea.
> 
> The first release of cpuinfo(1), which is still i386-only can be found
> at:
> 
>         http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz
> 
> Please give me feedback (and/or patches) for this version if possible.
> 
>         Christoph
> 

Per the LSB forums, the FSG board, and the LSB core team, the /proc/cpuinfo will
be removed from gLSB v1.1.0.   The LSB core team would like to wait for an
established solution (meaning we need to get cpuinfo(1) in the distros).

Thanks Christoph for the cpuinfo(1) command!

I would like to thank everyone who helped with this gLSB issue.

Cheers,

-- 
George Kraft IV
gk4@austin.ibm.com


From srivasta@acm.org  Thu Jan 10 23:29:51 2002
From: srivasta@acm.org (Manoj Srivastava)
Date: Thu, 10 Jan 2002 17:29:51 -0600
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020109215045.A11217@caldera.de> (Christoph Hellwig's message
 of "Wed, 9 Jan 2002 21:50:45 +0100")
References: <20020107205900.A28710@caldera.de>
 <E16Nwkv-0006TW-00@the-village.bc.nu>
 <20020109215045.A11217@caldera.de>
Message-ID: <87wuypg4y8.fsf@glaurung.green-gryphon.com>

Hi,

	First, a nit:
======================================================================
static void
grep_cputypes(const char *prefix, int len)
======================================================================

Should be
======================================================================
static void
grep_cputypes(const char *prefix, size_t len)
======================================================================

	Just a nit, but it silences the warning:
======================================================================
cc -ansi -pedantic -Wall -W -Wtraditional -Wconversion -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fshort-enums -fno-common -Dgets=DONT_USE_GETS -Dlint -Woverloaded-virtual -Wnested-externs -Winline -O2 -D_XOPEN_SOURCE=600   -c -o arch_i386.o arch_i386.c
arch_i386.c: In function `grep_cputypes':
arch_i386.c:23: warning: passing arg 3 of `strncmp' as unsigned due to prototype
======================================================================

	Secondly, why are you passing the length explicitly in the
 call to grep_cputypes? The following implementation removes the
 requirement (and I often miscount, in my old age.
======================================================================
static void
grep_cputypes(const char *prefix)
{
        FILE *f;
        char buf[LINE_MAX];
        int n = 0;

        f = fopen(_PATH_CPUINFO, "r");
        if (f) {
                while (fgets(buf, sizeof(buf), f)) {
                        if (!strncmp(buf, prefix, strlen(prefix))) {
                                printf("cpu%d: %s", n++, (buf+len+3));
                        }
                }
                fclose(f);
        }
        if (!n) {
                printf("unknown\n");
        }
}
======================================================================


	Am I missing a reason to allow the caller to specify a subset
 of the prefix as relevant for comparison?

	manoj
        
-- 
 You should never wear your best trousers when you go out to fight for
 freedom and liberty. Henrik Ibsen
Manoj Srivastava   <srivasta@acm.org>  <http://www.datasync.com/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


From jockgrrl@austin.rr.com  Fri Jan 11 06:30:18 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Fri, 11 Jan 2002 00:30:18 -0600
Subject: Proposal: cpuinfo(1)
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de>
Message-ID: <3C3E867A.13070FBE@austin.rr.com>

Christoph Hellwig wrote:
> 
> On Tue, Jan 08, 2002 at 01:57:33PM +0000, Alan Cox wrote:
> > > As current /proc/cpuinfo is unportable and thus not suitable for LSB
> > > in my eyes, I'd like to propose a new tool, cpuinfo(1) as replacement.
> > >
> > > Cpuinfo is supposed to allow retrieving a subset of the contents of
> > > the i386 /proc/cpuinfo in a portable way.
> >
> > I think thats an excellent idea.
> 
> The first release of cpuinfo(1), which is still i386-only can be found
> at:
> 
>         http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz
> 
> Please give me feedback (and/or patches) for this version if possible.

The first thing I noticed is that only one flag at a time is
allowed, so I can't go "cpuinfo -bp" and get my BogoMips and
CPU names at the same time.

The usage message is "cpuinfo [ -bcfnp ]" which implies I can
mix and match flags.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From schilling@fokus.gmd.de  Fri Jan 11 12:25:32 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Fri, 11 Jan 2002 13:25:32 +0100 (MET)
Subject: Proposal: cpuinfo(1)
Message-ID: <200201111225.g0BCPWY04972@burner.fokus.gmd.de>


>> The first release of cpuinfo(1), which is still i386-only can be found
>> at:
>> 
>>         http://people.nl.linux.org/~hch/cpuinfo/cpuinfo-0.1.tar.gz
>> 
>> Please give me feedback (and/or patches) for this version if possible.

Is there any reason why the man page does not use standard "man" troff
macros?



J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From hch@caldera.de  Fri Jan 11 16:14:38 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 11 Jan 2002 17:14:38 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <87wuypg4y8.fsf@glaurung.green-gryphon.com>; from srivasta@acm.org on Thu, Jan 10, 2002 at 05:29:51PM -0600
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de> <87wuypg4y8.fsf@glaurung.green-gryphon.com>
Message-ID: <20020111171438.A21023@caldera.de>

On Thu, Jan 10, 2002 at 05:29:51PM -0600, Manoj Srivastava wrote:
> Hi,
> 
> 	First, a nit:
> ======================================================================
> static void
> grep_cputypes(const char *prefix, int len)
> ======================================================================
> 
> Should be
> ======================================================================
> static void
> grep_cputypes(const char *prefix, size_t len)
> ======================================================================
> 
> 	Just a nit, but it silences the warning:

I did that first but then reversed it.
Ok, back to the initial version, thanks for spotting it.

> 	Secondly, why are you passing the length explicitly in the
>  call to grep_cputypes? The following implementation removes the
>  requirement (and I often miscount, in my old age.

Expclicitly passing it gives a const expression, but if counting
is a problem (:)) I can change it - cpuinfo should really be used in
any fastpath..

> 	Am I missing a reason to allow the caller to specify a subset
>  of the prefix as relevant for comparison?

No - at least that was not intended.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From hch@caldera.de  Fri Jan 11 16:15:21 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 11 Jan 2002 17:15:21 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <3C3E867A.13070FBE@austin.rr.com>; from jockgrrl@austin.rr.com on Fri, Jan 11, 2002 at 12:30:18AM -0600
References: <20020107205900.A28710@caldera.de> <E16Nwkv-0006TW-00@the-village.bc.nu> <20020109215045.A11217@caldera.de> <3C3E867A.13070FBE@austin.rr.com>
Message-ID: <20020111171521.B21023@caldera.de>

On Fri, Jan 11, 2002 at 12:30:18AM -0600, Julie wrote:
> The first thing I noticed is that only one flag at a time is
> allowed, so I can't go "cpuinfo -bp" and get my BogoMips and
> CPU names at the same time.
> 
> The usage message is "cpuinfo [ -bcfnp ]" which implies I can
> mix and match flags.

Okay, I'll fix the usage info for 0.2.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From hch@caldera.de  Fri Jan 11 16:15:57 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Fri, 11 Jan 2002 17:15:57 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <200201111225.g0BCPWY04972@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 11, 2002 at 01:25:32PM +0100
References: <200201111225.g0BCPWY04972@burner.fokus.gmd.de>
Message-ID: <20020111171557.C21023@caldera.de>

On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> Is there any reason why the man page does not use standard "man" troff
> macros?

They use standard mdoc macros.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From jockgrrl@austin.rr.com  Sat Jan 12 01:48:57 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Fri, 11 Jan 2002 19:48:57 -0600
Subject: Proposal: cpuinfo(1)
References: <200201111225.g0BCPWY04972@burner.fokus.gmd.de> <20020111171557.C21023@caldera.de>
Message-ID: <3C3F9609.916B46FB@austin.rr.com>

Christoph Hellwig wrote:
> 
> On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> > Is there any reason why the man page does not use standard "man" troff
> > macros?
> 
> They use standard mdoc macros.

Which aren't standard "man" macros.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From hch@caldera.de  Sat Jan 12 13:19:12 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Sat, 12 Jan 2002 14:19:12 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <3C3F9609.916B46FB@austin.rr.com>; from jockgrrl@austin.rr.com on Fri, Jan 11, 2002 at 07:48:57PM -0600
References: <200201111225.g0BCPWY04972@burner.fokus.gmd.de> <20020111171557.C21023@caldera.de> <3C3F9609.916B46FB@austin.rr.com>
Message-ID: <20020112141912.A27136@caldera.de>

On Fri, Jan 11, 2002 at 07:48:57PM -0600, Julie wrote:
> > On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> > > Is there any reason why the man page does not use standard "man" troff
> > > macros?
> > 
> > They use standard mdoc macros.
> 
> Which aren't standard "man" macros.

They are (since 4.4BSD).

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From schilling@fokus.gmd.de  Sat Jan 12 13:32:08 2002
From: schilling@fokus.gmd.de (Joerg Schilling)
Date: Sat, 12 Jan 2002 14:32:08 +0100 (MET)
Subject: Proposal: cpuinfo(1)
Message-ID: <200201121332.g0CDW8D05546@burner.fokus.gmd.de>

>From: Christoph Hellwig <hch@caldera.de>

>On Fri, Jan 11, 2002 at 07:48:57PM -0600, Julie wrote:
>> > On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
>> > > Is there any reason why the man page does not use standard "man" troff
>> > > macros?
>> > 
>> > They use standard mdoc macros.
>> 
>> Which aren't standard "man" macros.

>They are (since 4.4BSD).

They are a proprietary 4.4BSD format. 

As your program is completely nonportable it makes no difference....
but if you are going to write a portable program it is a really bad
idea to use them as are not present on a typical UNIX system.

J鰎g

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J鰎g Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


From jockgrrl@austin.rr.com  Sat Jan 12 13:40:28 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Sat, 12 Jan 2002 07:40:28 -0600
Subject: Proposal: cpuinfo(1)
References: <200201121332.g0CDW8D05546@burner.fokus.gmd.de>
Message-ID: <3C403CCC.E53CF1C3@austin.rr.com>

Joerg Schilling wrote:
> 
> >From: Christoph Hellwig <hch@caldera.de>
> 
> >On Fri, Jan 11, 2002 at 07:48:57PM -0600, Julie wrote:
> >> > On Fri, Jan 11, 2002 at 01:25:32PM +0100, Joerg Schilling wrote:
> >> > > Is there any reason why the man page does not use standard "man" troff
> >> > > macros?
> >> >
> >> > They use standard mdoc macros.
> >>
> >> Which aren't standard "man" macros.
> 
> >They are (since 4.4BSD).
> 
> They are a proprietary 4.4BSD format.
> 
> As your program is completely nonportable it makes no difference....
> but if you are going to write a portable program it is a really bad
> idea to use them as are not present on a typical UNIX system.

It would also be nice if they used the format of the operating
system currently under discussion.

Hint: It isn't 4.4BSD.
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From hch@caldera.de  Sat Jan 12 13:50:45 2002
From: hch@caldera.de (Christoph Hellwig)
Date: Sat, 12 Jan 2002 14:50:45 +0100
Subject: Proposal: cpuinfo(1)
In-Reply-To: <3C403CCC.E53CF1C3@austin.rr.com>; from jockgrrl@austin.rr.com on Sat, Jan 12, 2002 at 07:40:28AM -0600
References: <200201121332.g0CDW8D05546@burner.fokus.gmd.de> <3C403CCC.E53CF1C3@austin.rr.com>
Message-ID: <20020112145045.A28624@caldera.de>

On Sat, Jan 12, 2002 at 07:40:28AM -0600, Julie wrote:
> It would also be nice if they used the format of the operating
> system currently under discussion.
> 
> Hint: It isn't 4.4BSD.

Groff which is used for *roff formating on usual Linux systems
has -mdoc support since 1991 and I don't remember any version
of man(1) on Linux that didn't support it.

Please browse you /usr/share/man/ directory and see how many
mdoc users already are an your system.

If you have nothing to worry about I'm happy to include your
cpuinfo manpage rewrittem using -man macros.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.


From jockgrrl@austin.rr.com  Sat Jan 12 14:22:50 2002
From: jockgrrl@austin.rr.com (Julie)
Date: Sat, 12 Jan 2002 08:22:50 -0600
Subject: Proposal: cpuinfo(1)
References: <200201121332.g0CDW8D05546@burner.fokus.gmd.de> <3C403CCC.E53CF1C3@austin.rr.com> <20020112145045.A28624@caldera.de>
Message-ID: <3C4046BA.C863541A@austin.rr.com>

Christoph Hellwig wrote:
> 
> On Sat, Jan 12, 2002 at 07:40:28AM -0600, Julie wrote:
> > It would also be nice if they used the format of the operating
> > system currently under discussion.
> >
> > Hint: It isn't 4.4BSD.
> 
> Groff which is used for *roff formating on usual Linux systems
> has -mdoc support since 1991 and I don't remember any version
> of man(1) on Linux that didn't support it.

Thanks.  Yes, that does work.  I guess I'm really starting
to show how old and moldy I've become ...
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl@austin.rr.com                 or nothing at all.
					    -- Helen Keller


From BudgetLife4@eudoramail.com  Sun Jan 13 16:34:04 2002
From: BudgetLife4@eudoramail.com (BudgetLife4@eudoramail.com)
Date: Sat, 12 Jan 2002 22:34:04 -1800
Subject: Are You Paying too Much for Life Insurance?             RYPP
Message-ID: <00002a5d4f21$00007f86$00003da7@mx1.eudoramail.com>

<html><body><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:center>M=
ost likely, <b>YES <span style=3Dfont-size:14.0pt;mso-bidi-font-size:12.0p=
t>!<o:p></o:p></span></b><o:p></o:p></p><p class=3DMsoNormal align=3Dcente=
r style=3Dtext-align:center>Here's why.<span style=3D"mso-spacerun: yes">&=
nbsp; </span><b><span style=3Dcolor:#FF3300>F</span><span style=3Dcolor:#F=
F9900>i</span><span style=3Dcolor:#FF3300>e</span><span style=3Dcolor:#FF9=
900>r</span><span style=3Dcolor:#FF3300>c</span><span style=3Dcolor:#FF990=
0>e</span></b> ... take no prisoner ... insurance industry <b><span style=3D=
color:red>PRICE WARS</span></b> have driven premiums <b><span style=3Dfont=
-size:14.0pt;mso-bidi-font-size:12.0pt;color:#003300>DOWN</span></b>, and =
<b>down</b>, and <b><span style=3Dfont-size:10.0pt;mso-bidi-font-size:12.0=
pt>down</span></b> --30 -- 40 -- 50 -- even <b><span style=3D"font-size:14=
0pt;mso-bidi-font-size:
12.0pt">70%</span></b> from where they were just a short time ago!<o:p></o=
:p></p><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:center><b><s=
pan style=3Dcolor:#9900CC>YOUR INSURANCE COMPANY </span><span style=3Dcolo=
r:#FF3300>DOESN'T </span><span style=3Dcolor:#9900CC>WANT YOU TO READ THIS=
</span><span style=3Dfont-size:18.0pt;mso-bidi-font-size:12.0pt>...</span>=
<o:p></o:p></b><o:p></o:p></p><p class=3DMsoNormal align=3Dcenter style=3D=
text-align:center>They will <b><span style=3Dcolor:#009900>continue </span=
></b>to <b><span style=3Dcolor:#009900>take your money</span></b>, while o=
ffering lower rates (up to 50%, even 70% lower) to <b><span style=3Dcolor:=
black>new</span></b> buyers.<o:p></o:p></p><p class=3DMsoNormal align=3Dce=
nter style=3Dtext-align:center><b><span style=3Dfont-size:14.0pt;mso-bidi-=
font-size:12.0pt;color:black>B</span></b>UT DON'T TAKE OUR WORD FOR IT<b><=
span style=3D"font-size:16.0pt;mso-bidi-font-size:
12.0pt">...</span></b> <b><span style=3D"font-size:14.0pt;mso-bidi-font-si=
ze:
12.0pt">Visit<o:p></o:p></span></b><o:p></o:p></p><p class=3DMsoNormal ali=
gn=3Dcenter style=3Dtext-align:center><b><span style=3Dfont-size:14.0pt;ms=
o-bidi-font-size:12.0pt;color:blue><p><center><a href=3Dhttp://www.lifeins=
urance.net.cn/email>http://www.lifeinsurance.net.cn/email/</a></p><o:p></o=
:p></span></b><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:cente=
r>and request an online quote today.<span style=3D"mso-spacerun: yes">&nbs=
p; </span>Be prepared to be surprised by how <b><span style=3Dcolor:#00990=
0>cheaply</span></b> you can buy <b><span style=3Dcolor:#009900>large</spa=
n></b> amounts of term life insurance!</p><p class=3DMsoNormal align=3Dcen=
ter style=3Dtext-align:center>&nbsp;</p><p class=3DMsoNormal align=3Dcente=
r style=3Dtext-align:center>If you think, that you will not benefit from t=
his correspondence, please reply with =FFFFFF93remove key=FFFFFF94 as the =
subject matter.</p><p class=3DMsoNormal align=3Dcenter style=3Dtext-align:=
center>&nbsp;<o:p></o:p></p></body></html>




From hp@redhat.com  Mon Jan 14 21:27:55 2002
From: hp@redhat.com (Havoc Pennington)
Date: 14 Jan 2002 16:27:55 -0500
Subject: Proposal: cpuinfo(1)
In-Reply-To: <20020107205900.A28710@caldera.de>
References: <20020107205900.A28710@caldera.de>
Message-ID: <y5wn0zghbc4.fsf@icon.labs.redhat.com>


Hi,

Instead of creating a new cpuinfo command, why not just specify
getconf, e.g. on my machine:

  $ getconf _NPROCESSORS_CONF
  2
  $ getconf _NPROCESSORS_ONLN
  2

Havoc


From xyl@xyl.com  Tue Jan 22 10:31:51 2002
From: xyl@xyl.com (iceshow)
Date: Tue, 22 Jan 2002 18:31:51 +0800
Subject: =?GB2312?B?1rvT0LPJuabDu9PQyqew3A==?=
Message-ID: <GV2EfD.A.UPF.A_TT8@murphy>



lsb-spec:您好!
<html>

<head>
<meta http-equiv="Content-Language" content="zh-cn">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>新建网页 1</title>
</head>

<body bgcolor="#FF9933" topmargin="0" leftmargin="0">

<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber1">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p align="center">
    <img border="0" src="http://518.shareyou.net/images/yearpic1.jpg" width="139" height="107">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    <img border="0" src="http://518.shareyou.net/images/yearpic2.jpg" width="136" height="106"><font face="华文彩云" size="7"><br>
    欢迎加入<font color="#FF0000">新盈利</font>商务信息网络</font></p>
    <p align="center"><a href="http://www.xinyingli.com/zhuce.php?mid=iceshow">
    <font color="#FF0000">》》》》在此加入《《《《</font></a></p>
    <table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber2">
      <tr>
        <td width="100%" align="center" style="border-style: none; border-width: medium">
        <p class="p4" align="left" style="line-height: 150%">&nbsp;&nbsp;&nbsp; 
        亲爱的朋友：互联网的春天来了，改变一生的命运从此开始，我们的系统决定你只有成功没有失败。就从<font color="#FF0000">110</font>元起步你将迈向富翁的行列。用<font 
color="#FF0000">110</font>元钱换几包已知的香烟和用<font color="#FF0000">110</font>元去搏一个未知的百万富翁，你如何选择？是贤是愚立见分晓。牌局中不知豪爽地送出多少
<font color="#FF0000">110</font>元,用它换来一条致富之路不是更好吗。请相信互联网是创造奇迹的地方，成功只青睐有胆有识的人。成功人士从也不会拖延一分钟，快把握先机，抢占
制高点。心动不如行动，行动才能梦想成真！错过季节，秋天收获什么？</td>
      </tr>
    </table>
    </td>
  </tr>
</table>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 7" bordercolor="#111111" width="100%" id="AutoNumber3" 
bordercolordark="#000000" bordercolorlight="#C0C0C0">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p align="center"><a href="http://www.xinyingli.com/zhuce.php?mid=iceshow">
    <img border="0" src="http://518.shareyou.net/images/banner.gif" width="100%" height="102"></a></td>
  </tr>
</table>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber4">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p style="line-height: 150%"><br>
&nbsp;&nbsp;&nbsp; 朋友，请不要在犹豫，我<a href="http://www.xinyingli.com/zhuce.php?mid=iceshow">加入</a>了，我赚了钱，这实在是一个很好的机会。也许你看过很多类似推
广的信件，你会觉得这是垃圾邮件，那么你就误会了。这是一个绝对真实的会让你赚到巨大财富的网络营销计划。我之所以会象你来推荐，那是因为你跟我一样的明白，天下没有免费的午
餐，是的，互联网也没有免费的钞票让你来捡，那么加入我们的营销网络，你需要付出的仅仅是<font color="#FF0000">110</font>元的代价，也正是因为你付出了，就会象我和我的朋友
一样获得更大的回报。想想看，为什么有这么多被你称为“垃圾邮件”的推广信会来到你的面前，其实也正是因为有那么多朋友明智的选择了我们的营销计划的结果，他们加入进来，他们
同样的也只是付出了仅仅<font color="#FF0000">110</font>元的成本，但是现在已经有人在开心的体会成功所带来的愉悦了。好了，我不再罗嗦了，怎么样<a 
href="http://www.xinyingli.com/?mid=iceshow">到我的网站去看看吧&gt;&gt;&gt;&gt;&gt;&gt;</a></td>
  </tr>
</table>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse; border-width: 0" bordercolor="#111111" width="100%" id="AutoNumber5">
  <tr>
    <td width="100%" style="border-style: none; border-width: medium">
    <p align="center"><font face="宋体" size="6">
    <a href="http://www.xinyingli.com/?mid=iceshow"><font color="#000000">
    欢迎加入新盈利商务信息网络</font></a></font></td>
  </tr>
  <tr>
    <td width="100%" style="border-left: medium none #111111; border-right: medium none #111111; border-top-style: none; border-top-width: medium; border-bottom-
style: none; border-bottom-width: medium">
    <p align="center"><a href="http://www.19.com.cn/click.asp?id=16647">
    <img border="0" src="http://www.softreg.com/baimages/18848.gif" width="468" height="60"></a></p>
    <p align="center">　</p>
    <p align="center">
    <a href="http://www.softreg.com/shareware_view.asp?id={80A6A87D-FC7A-40EE-BA14-37EED522FF06}&sysopid=16647">
    <font color="#000000">本信息由《亿虎Email邮差 v2002b》全力发送<br>
    <br>
    亿虎邮差，你网络营销的最佳助手。立即注册购买获得《亿虎Email邮差 v2002b》<br>
    <br>
    无需smtp服务器，第一时间到达客户邮箱</font></a></p>
    <p align="center">　</p>
    <p align="center">　</td>
  </tr>
</table>

</body>

</html>
    


　　　　　　　　致
礼!
  　　　　　　　　　　　　　　 iceshow
  　　　　　　　　　　　　　　 xyl@xyl.com
  　　　　　　　　　　　　　　 2002-22-01


From Viagra9009@eudoramail.com  Thu Jan 31 21:12:42 2002
From: Viagra9009@eudoramail.com (Viagra9009@eudoramail.com)
Date: Thu, 31 Jan 2002 03:12:42 -1800
Subject: Valentine Must: Viagra Orders Made Easy                   PN
Message-ID: <000040765449$0000117a$00001175@mx2.eudoramail.com>

<html><head><meta http-equiv=3DContent-Language content=3Den-us><meta http-=
equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1252"><title>=
Orders Today will be Shipped Tomorrow</title></head><body><font face=3DAri=
al size=3D2><table cellSpacing=3D0 cellPadding=3D1 width=3D500 align=3Dcen=
ter bgColor=3D#ffffff border=3D0><tr><td vAlign=3Dtop align=3Dmiddle><tabl=
e borderColor=3D#ffffff cellSpacing=3D0 borderColorDark=3D#ffffff cellPadd=
ing=3D0 width=3D100% bgColor=3D#ffffff borderColorLight=3D#ffffff border=3D=
0><tr><td vAlign=3Dtop bgColor=3D#ffffff><center><p><br> <font color=3D#00=
00ff size=3D2><a href=3Dhttp://216.240.159.59/?iAffiliateID=3D20043 target=
=3D_blank><font color=3D#0000ff><img style=3D"width: 500px; height: 315px"=
 alt hspace=3D0 src=3Dhttp://216.240.159.59/em/image/promo/vm.jpeg border=3D=
0 NOSEND=3D1></font>&nbsp;</a></font></p></center></td></tr><tr><td align=3D=
middle bgColor=3D#ffffff><ul><ul><li><div align=3Dleft><font face=3DVerdan=
a><b><font color=3D#ff0000>Orders</font> Today will be Shipped Tomorrow</b=
></font></div></li><li><div align=3Dleft><font face=3DVerdana><font color=3D=
#ff0000><b>No <font color=3D#000000>Prescription Necessary</font></b></fon=
t></font></div></li><li><div align=3Dleft><font face=3DVerdana><b><font co=
lor=3D#ff0000>U.<font color=3D#0000ff>S. </font><font color=3D#000000>Doct=
ors and Pharmacy&nbsp;</font></font><font color=3D#000000>available for co=
nsultation</font></b></font></div></li><li><div align=3Dleft><font face=3D=
Verdana><b><font color=3D#ff0000>All </font>orders shipped <font color=3D#=
000080>Fed</font> <font color=3D#ff0000>Ex</font> Overnight</b></font></di=
v></li></ul></ul><div><font color=3D#ff0000 face=3DVerdana size=3D4><b><a =
target=3D_blank href=3Dhttp://216.240.159.59/?iAffiliateID=3D20043>Click H=
ere and Order Online Today!!!</a></b></font></div></td></tr><tr><td vAlign=
=3Dtop align=3Dmiddle><div><br> &nbsp;</div><div>&nbsp;</div><div>&nbsp;</=
div><div>&nbsp;</div><div><font size=3D2>To be removed from future mailing=
s, please reply with &quot;Remove&quot; as subject. <br> &nbsp;</font></di=
v></td></tr></table></td></tr></table></font></body></html>