reiserfs, xfs, ext2, ext3

reiserfs, xfs, ext2, ext3

[Martín Marqués]

Hi,

We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to 
come so we can change our proxy server, that will run on Linux with Squid. 
One disk will go inside (I think?) and the other 4 on a tower conected to the 
RAID, which will be have the cache of the squid server.

One of my partners thinks that we should use reiserfs on all the server (the 
partitions of the Linux distro, and the cache partitions), and I found out 
that reiserfs has had lots of bugs, and is marked as experimental in kernel 
2.4.4. Not to mention that the people of RH discourage there users from using 
it.

There has also been lots of talks about reiserfs being the cause of some data 
lose and performance lose (not sure about this last one).

So what I want is to know which is the status of this 3 journaling FS. Which 
is the one we should look for?

I think that the data lose is not significant in a proxy cache, if the FS is 
really fast, as is said reiserfs is.

Saludos... :-)

-- 
El mejor sistema operativo es aquel que te da de comer.
Cuida tu dieta.
-----------------------------------------------------------------
Martin Marques                  |        mmarques@unl.edu.ar
Programador, Administrador      |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------

Re: reiserfs, xfs, ext2, ext3

[Alan Cox]

> that reiserfs has had lots of bugs, and is marked as experimental in kernel 
> 2.4.4. Not to mention that the people of RH discourage there users from using 
> it.

At the time Red Hat 7.1 was mastered Reiserfs was not stable. The reiserfs in
the RH kernel has some of the tail fixes but newer ones are not present. Also
it had other problems then: the fsck tool was useless, it didnt work on
big endian machines (eg PPC, S/390).

If Hans sent me a patch removing the experimental tag from Reiserfs the only
thing that would make me hesitate the slightest from applying it would be the
endianness thing, and thats not enough to stop it being applied.

> There has also been lots of talks about reiserfs being the cause of some data 
> lose and performance lose (not sure about this last one).

If you are running 2.4.4/2.4.4-ac/2.4.5pre I believe all the relevant reiserfs
patches are applied. The new fsck seems to work a lot better too. The limiters
right now are:
	-	You need a patch for NFS (its on their site no big deal)
	-	You can only use little endian boxes (x86 for you so ok)

> So what I want is to know which is the status of this 3 journaling FS. Which 
> is the one we should look for?
> 
> I think that the data lose is not significant in a proxy cache, if the FS is 
> really fast, as is said reiserfs is.

reiserfs seems to handle large amounts of small files well, up to a point but
it also seems to degrade over time. ext3 isnt generally available for 2.4 but
is proving very solid on 2.2 and has good fsck tools. Ext3 does not add
anything over ext2 in terms of large directories of files and other ext2
performance limits.

XFS is very fast most of the time (deleting a file is sooooo slow its like using
old BSD systems). Im not familiar enough with its behaviour under Linux yet.

What you might want to do is to make a partition for 'mystery journalling fs'
and benchmark a bit.

Alan

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Alan Cox wrote:

> > that reiserfs has had lots of bugs, and is marked as experimental in kernel
> > 2.4.4. Not to mention that the people of RH discourage there users from using
> > it.
>
> At the time Red Hat 7.1 was mastered Reiserfs was not stable. The reiserfs in
> the RH kernel has some of the tail fixes but newer ones are not present. Also
> it had other problems then: the fsck tool was useless, it didnt work on
> big endian machines (eg PPC, S/390).
>
> If Hans sent me a patch removing the experimental tag from Reiserfs the only
> thing that would make me hesitate the slightest from applying it would be the
> endianness thing, and thats not enough to stop it being applied.

Jeff Mahoney has a patch in progress for this, he currently has the kernel code
working, but needs to do the utilities.  I would hesitate to put the endianness
fixes in before 2.5.1 just because I am conservative about disturbing stable code.

There exists one known bug which one user has hit which required a major code
change to fix.  We are now testing the code, and are in the ironic situation
of hesitating to merge in a bug fix out of fear that the bugfix code is large and
untested, and it might have bugs that more than one user will hit.:-/
I think we are going to make the new code an option until it has been
extensively tested.

I think that 2.4.4 is stable, and I say this based upon us getting lots of users
with
hardware bugs and none with bugs not fixed in 2.4.4 in the entire time since 2.4.4
was released.


>
>
> > There has also been lots of talks about reiserfs being the cause of some data
> > lose and performance lose (not sure about this last one).
>
> If you are running 2.4.4/2.4.4-ac/2.4.5pre I believe all the relevant reiserfs
> patches are applied. The new fsck seems to work a lot better too. The limiters
> right now are:
>         -       You need a patch for NFS (its on their site no big deal)
>         -       You can only use little endian boxes (x86 for you so ok)

you also need a patch for quotas.

>
> > I think that the data lose is not significant in a proxy cache, if the FS is
> > really fast, as is said reiserfs is.

you can ask nikita for a copy of reiserfs_raw, a version of reiserfs designed for
squid.  It is substantially faster.

Hans

Re: reiserfs, xfs, ext2, ext3

[Steve Lord]

> 
> XFS is very fast most of the time (deleting a file is sooooo slow its like us
> ing
> old BSD systems). Im not familiar enough with its behaviour under Linux yet.

Hmm, I just removed 2.2 Gbytes of data in 30000 files in 37 seconds (14.4
seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu
linux box with a not very exciting scsi drive.

> 
> What you might want to do is to make a partition for 'mystery journalling fs'
> and benchmark a bit.
> 
> Alan
> 

I agree with Alan here, the only sure fire way to find out which filesystem
will work best for your application is to try it out. I have found reiserfs
to be very fast in some tests, especially those operating on lots of small
files, but contrary to some peoples, belief XFS is good for a lot more than
just messing with Gbyte long data files.

Steve Lord

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Steve Lord wrote:

> >
> > XFS is very fast most of the time (deleting a file is sooooo slow its like us
> > ing
> > old BSD systems). Im not familiar enough with its behaviour under Linux yet.
>
> Hmm, I just removed 2.2 Gbytes of data in 30000 files in 37 seconds (14.4
> seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu
> linux box with a not very exciting scsi drive.
>
> >
> > What you might want to do is to make a partition for 'mystery journalling fs'
> > and benchmark a bit.
> >
> > Alan
> >
>
> I agree with Alan here, the only sure fire way to find out which filesystem
> will work best for your application is to try it out. I have found reiserfs
> to be very fast in some tests, especially those operating on lots of small
> files, but contrary to some peoples, belief XFS is good for a lot more than
> just messing with Gbyte long data files.
>
> Steve Lord
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

XFS used to have the performance problems that Alan described but fixed them in
the linux port, yes?

Hans

Re: reiserfs, xfs, ext2, ext3

[Steve Lord]

Hans Reiser wrote:
> XFS used to have the performance problems that Alan described but fixed them 
> in
> the linux port, yes?
> 
> Hans

Hmm, we do things somewhat differently on linux, but I suspect most of it
is due to hardware getting faster underneath us. 

Steve

Re: reiserfs, xfs, ext2, ext3

[Pekka Pietikainen]

On Wed, May 09, 2001 at 04:25:40PM -0500, Steve Lord wrote:
> 
> > 
> > XFS is very fast most of the time (deleting a file is sooooo slow its like us
> > ing
> > old BSD systems). Im not familiar enough with its behaviour under Linux yet.
> 
> Hmm, I just removed 2.2 Gbytes of data in 30000 files in 37 seconds (14.4
> seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu
> linux box with a not very exciting scsi drive.
Here's some very unscientific numbers I've measured (ancient 4G SCSI
drive on a dual pII/450), XFS 1.0-pre2 and reiserfs is
the version in that kernel. The first bit is from tiobench, the multiple 
files one is a simple 30-line program that creates tons of 1k files and then
removes them.

XFS

         File   Block  Num  Seq Read    Rand Read   Seq Write  Rand Write
  Dir    Size   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
   .     256    4096    1  9.601 8.36% 0.644 1.48% 9.367 20.8% 0.587 1.12%
   .     256    4096    2  7.201 6.51% 0.672 1.50% 9.323 24.3% 0.582 1.63%
   .     256    4096    4  6.867 6.25% 0.693 1.46% 9.280 27.0% 0.590 1.91%
   .     256    4096    8  6.669 6.29% 0.708 1.57% 9.215 31.4% 0.597 1.99%

Create 20000 files: 116.882449
Unlink 20000 files: 47.449201

reiserfs

         File   Block  Num  Seq Read    Rand Read   Seq Write  Rand Write
  Dir    Size   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
   .     256    4096    1  9.591 11.9% 0.480 1.53% 4.506 21.4% 0.581 1.67%
   .     256    4096    2  7.176 8.91% 0.557 1.56% 5.559 30.3% 0.579 1.96%
   .     256    4096    4  6.509 8.34% 0.593 1.69% 6.142 36.9% 0.580 1.96%
   .     256    4096    8  5.602 7.17% 0.621 1.84% 6.430 40.5% 0.581 1.99%

Create 20000 files: 17.862143
Unlink 20000 files: 9.487520

ext2

         File   Block  Num  Seq Read    Rand Read   Seq Write  Rand Write
  Dir    Size   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
   .     256    4096    1  9.533 7.26% 0.472 1.11% 4.505 7.77% 0.582 1.11%
   .     256    4096    2  7.274 5.56% 0.559 1.16% 5.667 12.2% 0.584 1.14%
   .     256    4096    4  6.377 4.84% 0.600 1.13% 6.209 15.2% 0.587 1.40%
   .     256    4096    8  5.613 4.33% 0.623 1.16% 6.433 17.4% 0.589 1.58%

Create 20000 files: 248.758925
Unlink 20000 files: 2.287174

-- 
Pekka Pietikainen

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

I would encourage all of you to consider using a fractal fileset generator such as
reiserfs_fract_tree.c such as we use for mongo.pl which we use for internal
benchmarking.  You can get a copy at www.namesys.com in the benchmarking section,
and then tune it as suits your needs.  I think that one needs randomly generated
non-uniform sized files and directories and directory trees to have a good
benchmark.

We gratefully accept enhancements of it.

Now that we are stable we can go back to tuning things like large file performance.

Hans

Re: reiserfs, xfs, ext2, ext3

[Daniel Phillips]

On Thursday 10 May 2001 12:19, Pekka Pietikainen wrote:
> Here's some very unscientific numbers I've measured (ancient 4G SCSI
> drive on a dual pII/450), XFS 1.0-pre2 and reiserfs is
> the version in that kernel. The first bit is from tiobench, the
> multiple files one is a simple 30-line program that creates tons of
> 1k files and then removes them.
>
> XFS
>
> Create 20000 files: 116.882449
> Unlink 20000 files: 47.449201
>
> reiserfs
>
> Create 20000 files: 17.862143
> Unlink 20000 files: 9.487520
>
> ext2
>
> Create 20000 files: 248.758925
> Unlink 20000 files: 2.287174

Whoops!  The create test is exactly the case my index patch 
accelerates, trying it is highly recommended:

  http://nl.linux.org/~phillips/htree/dx.testme-2.4.3-3

To apply:

    cd source/tree
    zcat ext2-dir-patch-S4.gz | patch -p1
    cat dx.pcache-2.4.4 | patch -p0

Or for the all-in-page-cache version (needs Al Viro's patch, see the 
READ.ME at http://nl.linux.org/~phillips/htree/):

  http://nl.linux.org/~phillips/htree/dx.pcache-2.4.4-4

The testme version is easier to apply but the pcache version is more 
like what the final form will be (waiting for Al's patch to get into 
Linus's tree so I can de-fork this).

--
Daniel

Re: reiserfs, xfs, ext2, ext3

[Andi Kleen]

On Wed, May 09, 2001 at 04:25:40PM -0500, Steve Lord wrote:
> 
> > 
> > XFS is very fast most of the time (deleting a file is sooooo slow its like us
> > ing
> > old BSD systems). Im not familiar enough with its behaviour under Linux yet.
> 
> Hmm, I just removed 2.2 Gbytes of data in 30000 files in 37 seconds (14.4
> seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu
> linux box with a not very exciting scsi drive.

On one not very scientific test: unpacking and deleting a cache hot 40MB/230MB
gzipped/unzipped tar on ext2 and xfs on a IDE drive on a lowend SMP box.

XFS (very recent 2.4.4 CVS, filesystem created with mkxfs defaults)

> time tar xzf ~ak/src.tgz 
real    1m58.125s
user    0m16.410s
sys     0m44.350s
> time rm -rf src/
real    0m50.344s
user    0m0.190s
sys     0m13.950s

ext2 (on same kernel as above)

> time tar xzf ~ak/src.tgz 

real    1m26.126s
user    0m16.100s
sys     0m36.080s

> time rm -rf src/

real    0m1.085s
user    0m0.160s
sys     0m0.930s

ext2 seems to be faster and the difference on deletion is dramatic, so
at least here it looks like Alan's statement is true.

The test did not involve very large files, the biggest files in the 
tar are a few hundred K with most of them being much smaller.

The values stay similar over multiple runs.  I did not do any comparisons
recently with reiserfs, but at least in the past reiserfs usually came out
ahead of ext2 for similar tests (especially being much faster for deletion)

-Andi

Re: reiserfs, xfs, ext2, ext3

[Daniel Podlejski]

On linux-kernel, ak@suse.de (Andi Kleen) wrote:
:  On one not very scientific test: unpacking and deleting a cache hot 40MB/230MB
:  gzipped/unzipped tar on ext2 and xfs on a IDE drive on a lowend SMP box.
:  
:  XFS (very recent 2.4.4 CVS, filesystem created with mkxfs defaults)
:  
: > time tar xzf ~ak/src.tgz 
:  real    1m58.125s
:  user    0m16.410s
:  sys     0m44.350s
: > time rm -rf src/
:  real    0m50.344s
:  user    0m0.190s
:  sys     0m13.950s
:  
:  ext2 (on same kernel as above)
:  
: > time tar xzf ~ak/src.tgz 
:  
:  real    1m26.126s
:  user    0m16.100s
:  sys     0m36.080s
:  
: > time rm -rf src/
:  
:  real    0m1.085s
:  user    0m0.160s
:  sys     0m0.930s

And another test:

ext2:

root@witch:/mobile:# time tar xzf /arc/test.tar.gz

real    5m25.249s
user    1m33.430s
sys     0m31.710s

root@witch:/mobile:# time rm -rf test/

real    0m8.843s
user    0m0.000s
sys     0m0.420s

xfs:

root@witch:/mobile:# time tar xzf /arc/test.tar.gz

real    5m23.744s
user    1m34.800s
sys     0m39.100s
root@witch:/mobile:# time rm -rf test/

real    0m1.364s
user    0m0.030s
sys     0m0.430s

test.tar.gz is tree created by script:

#!/bin/bash

for lev1 in aa bb cc dd ee ff gg hh ii jj kk ll
do

	mkdir $lev1
	cd $lev1

	for lev2 in 0 1 2 3 4 5 6 7
	do
		mkdir $lev2
		cd $lev2

		for fname in a b c d e f g h i
		do
			dd if=/dev/urandom of=$fname bs=4k count=1024
		done

		cd ..
	done

	cd ..
done


-- 
Daniel Podlejski <underley@underley.eu.org>
   ... When you're talkin to yourself and nobody's home
   You can fool yourself, you came in this world alone ...

Re: reiserfs, xfs, ext2, ext3

[Andi Kleen]

On Fri, May 11, 2001 at 12:23:09AM +0200, Daniel Podlejski wrote:
> 
> ext2:
> 
> root@witch:/mobile:# time tar xzf /arc/test.tar.gz

If /arc is not on a different hd it is probably a good idea to make 
sure test.tar.gz is small enough to fit into memory and has been read
at least once to be cache hot (that was the case with my test tar). 
Otherwise you're testing how fast the hd can seek between the two places 
and how far XFS and ext2 are away, and both are not very interesting.


-Andi

Re: reiserfs, xfs, ext2, ext3

[Daniel Podlejski]

On linux-kernel, ak@suse.de (Andi Kleen) wrote:
[...]
:  If /arc is not on a different hd it is probably a good idea to make 
:  sure test.tar.gz is small enough to fit into memory and has been read
:  at least once to be cache hot (that was the case with my test tar). 
:  Otherwise you're testing how fast the hd can seek between the two places 
:  and how far XFS and ext2 are away, and both are not very interesting.

hda: IBM-DTLA-307030, ATA DISK drive
hdc: ST34312A, ATA DISK drive
hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(66)
hdc: 8420832 sectors (4311 MB) w/512KiB Cache, CHS=524/255/63, UDMA(33)

/arc is logical volume on hda, /mobile is partition on hdc (mobile -
becouse it's on disk in mobile rack ;)), so test is good.

Soon I will test this on SCSI disk.

-- 
Daniel Podlejski <underley@underley.eu.org>
   ... A blind man kneels on broken class
   Building the bars of his own case ...

[PATCH] tty canonical mode: nicer erase behaviour

[zefram]

problem rationale
-----------------

One of the long-standing problems preventing Unix from being a
user-friendly desktop OS is its handling of erase keys.  There are
often two such keys on a keyboard (Backspace and Delete), and which one
works depends very much on context -- many text editing programs will
only accept one of the erase-related characters (^H and ^?), and the
mapping from keys to characters is terminal-dependent.  Unfortunately,
any solution to this problem has to be implemented in each program that
faces this problem.

Theoretically every program should be able to determine which erase
character to accept by looking at terminfo, but that's very cumbersome,
particularly in programs that might not otherwise need to use terminfo.
It also utterly fails in programs that don't know what kind of terminal
they are interacting with.  The more practical solution, therefore, is
that the program should accept *both* ^H and ^? as erase characters.
Look at bash's and zsh's command line editors for examples of this
approach.

One of the programs that exhibits the ^H/^? problem is the tty
line discipline in the Linux kernel.  It falls into the category of
programs that don't know (and don't care) what kind of terminal they
are interacting with.  This patch implements the accept-both-characters
solution.

patch rationale
---------------

The exact semantics changed are: in canonical mode, if IEXTEN is on
and the ERASE character is set to either ^H or ^?, then both ^H and
^? are treated as ERASE characters.  The standard single-erase-character
behaviour is followed if IEXTEN is off (which prohibits non-POSIX extended
behaviour) or if the ERASE character is neither ^H or ^? (indicating
that the user actually wants erase behaviour other than the usual use
of the erase keys).

At first glance, a more obvious way to implement handling of both erase
characters would be to have an ERASE2 character setting in the tty state,
much as there is EOL and EOL2.  However, this solution would suffer
some annoying problems.  It would rely on the user setting the two erase
characters properly in order to take advantage of it.  Even if they're
set to ^H and ^? by default, user code that tries to set ERASE based on
the terminal type (and doesn't know about ERASE2) might end up with ERASE
and ERASE2 set to the same character, breaking the solution.  Also, code
(and users) that doesn't know about ERASE2 would get surprising results
if they try to set ERASE to something other than ^H/^?.  All of this
points to it being preferable not to change the tty settings interface,
but only change the behaviour to this preferable form.

the patch
---------

This patch is based on kernel version 2.4.8.  It will also apply cleanly
up to at least kernel version 2.4.10-pre14.

--- drivers/char/n_tty.c.orig	Sat Sep 22 22:14:19 2001
+++ drivers/char/n_tty.c	Sun Sep 23 02:59:30 2001
@@ -329,9 +329,11 @@
 	}
 }
 
-static void eraser(unsigned char c, struct tty_struct *tty)
+enum kill_type { ERASE, WERASE, KILL };
+
+static void eraser(int kill_type, unsigned char cc, struct tty_struct *tty)
 {
-	enum { ERASE, WERASE, KILL } kill_type;
+	unsigned char c;
 	int head, seen_alnums;
 	unsigned long flags;
 
@@ -339,11 +341,7 @@
 		/* opost('\a', tty); */		/* what do you think? */
 		return;
 	}
-	if (c == ERASE_CHAR(tty))
-		kill_type = ERASE;
-	else if (c == WERASE_CHAR(tty))
-		kill_type = WERASE;
-	else {
+	if (kill_type == KILL) {
 		if (!L_ECHO(tty)) {
 			spin_lock_irqsave(&tty->read_lock, flags);
 			tty->read_cnt -= ((tty->read_head - tty->canon_head) &
@@ -359,13 +357,12 @@
 			tty->read_head = tty->canon_head;
 			spin_unlock_irqrestore(&tty->read_lock, flags);
 			finish_erasing(tty);
-			echo_char(KILL_CHAR(tty), tty);
+			echo_char(cc, tty);
 			/* Add a newline if ECHOK is on and ECHOKE is off. */
 			if (L_ECHOK(tty))
 				opost('\n', tty);
 			return;
 		}
-		kill_type = KILL;
 	}
 
 	seen_alnums = 0;
@@ -392,7 +389,7 @@
 				}
 				echo_char(c, tty);
 			} else if (kill_type == ERASE && !L_ECHOE(tty)) {
-				echo_char(ERASE_CHAR(tty), tty);
+				echo_char(cc, tty);
 			} else if (c == '\t') {
 				unsigned int col = tty->canon_column;
 				unsigned long tail = tty->canon_head;
@@ -590,9 +587,19 @@
 		}
 	}
 	if (tty->icanon) {
-		if (c == ERASE_CHAR(tty) || c == KILL_CHAR(tty) ||
-		    (c == WERASE_CHAR(tty) && L_IEXTEN(tty))) {
-			eraser(c, tty);
+		if (c == ERASE_CHAR(tty) ||
+		    (L_IEXTEN(tty) &&
+		     (ERASE_CHAR(tty) == 8 || ERASE_CHAR(tty) == 127) &&
+		     (c == 8 || c == 127))) {
+			eraser(ERASE, c, tty);
+			return;
+		}
+		if (c == KILL_CHAR(tty)) {
+			eraser(KILL, c, tty);
+			return;
+		}
+		if (c == WERASE_CHAR(tty) && L_IEXTEN(tty)) {
+			eraser(WERASE, c, tty);
 			return;
 		}
 		if (c == LNEXT_CHAR(tty) && L_IEXTEN(tty)) {
@@ -822,6 +829,11 @@
 			set_bit('\n', &tty->process_char_map);
 			set_bit(EOL_CHAR(tty), &tty->process_char_map);
 			if (L_IEXTEN(tty)) {
+				if (ERASE_CHAR(tty) == 8 ||
+				    ERASE_CHAR(tty) == 127) {
+					set_bit(8, &tty->process_char_map);
+					set_bit(127, &tty->process_char_map);
+				}
 				set_bit(WERASE_CHAR(tty),
 					&tty->process_char_map);
 				set_bit(LNEXT_CHAR(tty),

-zefram

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Alan Cox]

> One of the long-standing problems preventing Unix from being a
> user-friendly desktop OS is its handling of erase keys.  There are

Not a kernel space issue

> often two such keys on a keyboard (Backspace and Delete), and which one
> works depends very much on context -- many text editing programs will
> only accept one of the erase-related characters (^H and ^?), and the

They do different things, they are different keys.

Erase character policy is precisely defined by posix. Fix problem apps. 
Debian set a policy on this a long time back and have done wonders since

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Nadav Har'El]

On Sun, Sep 23, 2001, Alan Cox wrote about "Re: [PATCH] tty canonical mode: nicer erase behaviour":
> Erase character policy is precisely defined by posix. Fix problem apps. 
> Debian set a policy on this a long time back and have done wonders since

Just too bad Debian's policy is to make ^? the erase character - pretty
much the opposite of what most Unix users used before that. Pretending
ASCII BS (^H) doesn't exist any more is an interesting exercise, but
it isn't easy to change habits and standards that existed for a couple of
decades... The same problem exists for the ASCII DEL (^?) which was also used
in many Unix systems, but usually as a intr key, not a "delete-forward" type
of thing...
[see http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.8
for the mentioned Debian policy]

Debian's solution isn't a silver bullet, in my opinion... It just means the
^H/^? confusion stops being a problem in a stand-alone system (if all your
applications and configuration files come as defaults from Debian, they are
consistent) but it just increased the mess when you log in from one system
type to another (one of them being none-Linux Unix)...

P.S.
The only relation any of this has to the kernel is the behavior of the
"cooked" line discipline, as Zefram already said. I think I like his
erase2 idea better than his forget-the-difference-between-^H-and-^? idea.
However, this former idea will work well only if applications like ssh,
for example, will know how to propegate erase2, and they currently don't.
But this is again not really a kernel issue...

-- 
Nadav Har'El                        |       Sunday, Sep 23 2001, 7 Tishri 5762
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Experience is what causes a person to
http://nadav.harel.org.il           |make new mistakes instead of old ones.

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Alan Cox]

> Debian's solution isn't a silver bullet, in my opinion... It just means the
> ^H/^? confusion stops being a problem in a stand-alone system (if all your
> applications and configuration files come as defaults from Debian, they are
> consistent) but it just increased the mess when you log in from one system
> type to another (one of them being none-Linux Unix)...

Thats in many ways a design flaw in the protocols. Original telnet has
IAC sequences to send a "delete" regardless of keymapping policies that
are not known at end points. X also does it right with the keysyms.
Ssh seems to lack this

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Nadav Har'El]

On Sun, Sep 23, 2001, Alan Cox wrote about "Re: [PATCH] tty canonical mode: nicer erase behaviour":
> Thats in many ways a design flaw in the protocols. Original telnet has
> IAC sequences to send a "delete" regardless of keymapping policies that
> are not known at end points. X also does it right with the keysyms.
> Ssh seems to lack this

Consider the letter "a". There is no such problem of "keymapping policies"
or how to send it on telnet or ssh, because ASCII, in 1965, (or even before
that), standardized it. The last two characters in that acronym stand for
"Information Interchange", of course.
Anyway, ASCII's character 010 (^H) is called "BS", i.e., backspace. What's
so wrong with using that as the standard way to send a backspace? Is it
because someone decided that it would be cool to have help be summoned in
Emacs with a ^H? Next thing we know there'll be someone annoyed by the fact
that the Escape key sends ^[ and ruins his ability to map Control-[ to
something in Emacs (running on a tty), and we'll need to change the way Escape
is coded too?

Of course there are opposite arguments, with people calling their backspace
key a "rubout" and then claiming it is justified to use the ASCII rubout
character (0177, DEL) for it. Which makes this whole situation even uglier :(


-- 
Nadav Har'El                        |       Monday, Sep 24 2001, 7 Tishri 5762
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Hardware, n.: The parts of a computer
http://nadav.harel.org.il           |system that can be kicked.

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Matthias Andree]

On Sun, 23 Sep 2001, Nadav Har'El wrote:

> Just too bad Debian's policy is to make ^? the erase character - pretty
> much the opposite of what most Unix users used before that. Pretending
> ASCII BS (^H) doesn't exist any more is an interesting exercise, but
> it isn't easy to change habits and standards that existed for a couple of
> decades... The same problem exists for the ASCII DEL (^?) which was also used
> in many Unix systems, but usually as a intr key, not a "delete-forward" type
> of thing...

[OT RANT]

Well, it's also fun to log in to a Solaris 2.5.1 ksh (which doesn't talk
bind, but just alias and soft-keys) from a Linux xterm which sends funny
Esc [3~ sequences. You can "fix" that with "Del sends Del", but you then
end up having either Del and Backspace both do Backspace or have their
meanings reversed from what the "left array" on the Backspace key
suggests. The Linux TTYs behave the same way (sending Esc [3~), and you
don't easily fix that without confusing EOF detection or things.

As appreciable a solution to consistently make "Delete" do
"delete-forward" and "Backspace" do "delete-backward" would be, as low
are the chances to get this done before the year 2039.

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Kai Henningsen]

nyh@math.technion.ac.il (Nadav Har'El)  wrote on 23.09.01 in <20010923234111.A16873@leeor.math.technion.ac.il>:

> Just too bad Debian's policy is to make ^? the erase character - pretty
> much the opposite of what most Unix users used before that. Pretending

Actually, the main argument for chosing this was that this *was* the  
traditional behaviour - as seen by vtxxx terminals and traditional Unix  
applications like emacs. (If ^H was the traditional erase, how come emacs  
wants ^H for help? Doesn't add up.)

MfG Kai

Re: reiserfs, xfs, ext2, ext3

[john slee]

On Wed, May 09, 2001 at 10:38:14AM +0300, Mart?n Marqu?s wrote:
> We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to
> come so we can change our proxy server, that will run on Linux with Squid.
> One disk will go inside (I think?) and the other 4 on a tower conected to the
> RAID, which will be have the cache of the squid server.

that's a pretty huge cache, have you considered using 8*9gb disks
instead of 4*18?  what sort of request throughput/latency are you
aiming for?  as the number of requests grows, disk seek times are
a very real problem.

> One of my partners thinks that we should use reiserfs on all the server (the
> partitions of the Linux distro, and the cache partitions), and I found out
> that reiserfs has had lots of bugs, and is marked as experimental in kernel

well, lots of bugs in reiserfs have been fixed.. obviously there are
more bugs to come (as always), but on the whole a lot of people are very
happy with it.  there certainly haven't been many posts of reiserfs
corruption lately at all on linux-kernel.

> 2.4.4. Not to mention that the people of RH discourage there users from using
> it.

they do?

> So what I want is to know which is the status of this 3 journaling FS. Which
> is the one we should look for?

xfs, while wonderful, probably isn't what you're looking for.  AFAIK it
is intended more for very very very large files.

> I think that the data lose is not significant in a proxy cache, if the FS is
> really fast, as is said reiserfs is.

data loss is always significant.  consider the case where you are forced
to rebuild the filesystem squid's cache directories reside on...
admittedly it is an extreme case, but it is a possibility all the same.

reiserfs is supposed to be very good with lots of small files, which is
the typical case for a squid cache.  however there's no substitute for
actual testing.  benchmark your squid server (use polygraph, from the
squid website) with each fs, and remember to test each of squid's
cache_dir options (diskd, aufs, coffs, ufs).

also appropriate could be ext2 with daniel phillips' directory indexing
patches.

test.  test.  test.  good luck.

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: reiserfs, xfs, ext2, ext3

[Daniel Phillips]

On Wednesday 09 May 2001 16:49, john slee wrote:
> On Wed, May 09, 2001 at 10:38:14AM +0300, Mart?n Marqu?s wrote:
> > We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb
> > scsi disks to come so we can change our proxy server, that will run
> > on Linux with Squid. One disk will go inside (I think?) and the
> > other 4 on a tower conected to the RAID, which will be have the
> > cache of the squid server.
[...]
> also appropriate could be ext2 with daniel phillips' directory
> indexing patches.

The ext2 indexing patch is apparently stable but it's still pre-alpha 
until the hash function is finalized.  I could see using it to run 
performance tests of ext2+indexing against the alternatives, but only 
if you are prepared to rerun mke2fs later.  Then there is the matter of 
making fsck index-aware.  As it stands now, if fsck finds an index it 
will remove it.

But by all means please test the patch:

  http://nl.linux.org/~phillips/htree/dx.testme-2.4.4-4

It would be great to see a table of ReiserFS/XFS/Ext2+index performance 
results.  Well, to make it really fair it should be Ext3+index so I'd 
better add 'backport the patch to 2.2' or 'bug Stephen and friends to 
hurry up' to my to-do list.

--
Daniel

Re: reiserfs, xfs, ext2, ext3

[Dan Hollis]

On Thu, 10 May 2001, Daniel Phillips wrote:
> It would be great to see a table of ReiserFS/XFS/Ext2+index performance
> results.  Well, to make it really fair it should be Ext3+index so I'd
> better add 'backport the patch to 2.2' or 'bug Stephen and friends to
> hurry up' to my to-do list.

Is the IBM JFS at a testable state yet, or is it still 'bleedin beta'?

-Dan

Re: reiserfs, xfs, ext2, ext3

[jlnance]

On Wed, May 09, 2001 at 04:19:53PM -0700, Dan Hollis wrote:
> On Thu, 10 May 2001, Daniel Phillips wrote:
> > It would be great to see a table of ReiserFS/XFS/Ext2+index performance
> > results.  Well, to make it really fair it should be Ext3+index so I'd
> > better add 'backport the patch to 2.2' or 'bug Stephen and friends to
> > hurry up' to my to-do list.
> 
> Is the IBM JFS at a testable state yet, or is it still 'bleedin beta'?

It is not stable enough to use in production yet.  It is certainly stable
enough to test/benchmark.  They released a new patch today which is supposed
to fix a long standing deadlock, so thats good news.  Give it a shot.

Jim

Re: reiserfs, xfs, ext2, ext3

[Andreas Dilger]

Daniel writes:
> The ext2 indexing patch is apparently stable but it's still pre-alpha 
> until the hash function is finalized.  I could see using it to run 
> performance tests of ext2+indexing against the alternatives, but only 
> if you are prepared to rerun mke2fs later.  Then there is the matter of 
> making fsck index-aware.  As it stands now, if fsck finds an index it 
> will remove it.

Actually, I would think e2fsck will simply refuse to run if the COMPAT
flag is set...

> It would be great to see a table of ReiserFS/XFS/Ext2+index performance 
> results.  Well, to make it really fair it should be Ext3+index so I'd 
> better add 'backport the patch to 2.2' or 'bug Stephen and friends to 
> hurry up' to my to-do list.

Actually, Andrew Morton has a nearly working ext3 implementation for 2.4.
It is at the stage where it works most of the time, but we are not yet sure
that everything that needs to be journaled is.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: reiserfs, xfs, ext2, ext3

[Helge Hafting]

john slee wrote:
> 
> On Wed, May 09, 2001 at 10:38:14AM +0300, Mart?n Marqu?s wrote:
> > We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to
> > come so we can change our proxy server, that will run on Linux with Squid.
> > One disk will go inside (I think?) and the other 4 on a tower conected to the
> > RAID, which will be have the cache of the squid server.
> 
> that's a pretty huge cache, have you considered using 8*9gb disks
> instead of 4*18?  what sort of request throughput/latency are you
> aiming for?  as the number of requests grows, disk seek times are
> a very real problem.
> 
> > One of my partners thinks that we should use reiserfs on all the server (the
> > partitions of the Linux distro, and the cache partitions), and I found out
> > that reiserfs has had lots of bugs, and is marked as experimental in kernel
> 
> well, lots of bugs in reiserfs have been fixed.. obviously there are
> more bugs to come (as always), but on the whole a lot of people are very
> happy with it.  there certainly haven't been many posts of reiserfs
> corruption lately at all on linux-kernel.
> 
> > 2.4.4. Not to mention that the people of RH discourage there users from using
> > it.
> 
> they do?
> 
> > So what I want is to know which is the status of this 3 journaling FS. Which
> > is the one we should look for?
> 
> xfs, while wonderful, probably isn't what you're looking for.  AFAIK it
> is intended more for very very very large files.
> 
> > I think that the data lose is not significant in a proxy cache, if the FS is
> > really fast, as is said reiserfs is.
> 
> data loss is always significant.  consider the case where you are forced
> to rebuild the filesystem squid's cache directories reside on...
> admittedly it is an extreme case, but it is a possibility all the same.
> 
If you worry about that, put the squid cache in a fs
of its own.  If it ever dies - use mkfs and restart with an empty cache.
No need to spend a long time fsck'ing something with a limited lifetime
that can be re-fetched.

Helge Hafting

Re: reiserfs, xfs, ext2, ext3

[Martin Hamilton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Just to pick up on this thread, to operate the JANET Web Cache Service
(proxy caching thingy used by a lot of ac.uk folk) we currently run
Squid on top of 2.2.18 + Linux Virtual Server 1.0.5 + ReiserFS 3.5.31
and the Magic-SysRq-over-serial-console patch.

In almost a year of operation (admittedly covering a couple of earlier
kernel/ReiserFS/... combos, and gradually migrated to our 40-odd cache
servers) we've only ever had a couple of wibbles which directly
implicated ReiserFS - and these on servers which later turned out to
have hardware problems. Lockups on the older 3c905 and eepro100
drivers have caused us some problems historically, though.

As the JANET backbone has migrated to 2.5Gbit/s we've seen our daily
transaction rate rise to over 100m URLs, with one peak of 120m. Moving
our cache filesystems from ext2 to ReiserFS almost tripled the number
of requests we could process per second before a cache box became
overloaded, and our fastest machines (6 x 10,000 RPM Ultra160 SCSI
cache disks) are now shipping some 230 requests/s with around 50ms
latency for a cache hit.

FWIW, we're currently using Squid 2.2.STABLE5-hno.20000202 and using
ReiserFS as a regular filesystem rather than raw, so there ought to be
quite a bit of scope for improvement.  Commercial caching systems have
demonstrated thoughput of thousands of requests/s with similar
hardware, but I suspect Tux-ification of Squid will be necessary to
catch up with them.  This (in the form of our old chum the proprietary
loadable kernel module :-) seems to be the direction the commercial
vendors are going in to get maximal performance out of their Linux
ports...

Cheers,

Martin



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin

iD8DBQE6+pQyVw+hz3xBJfQRApYsAKCuy1yPe/KarPluSeTB6OKgmfQ+8wCfYPi2
li9nQT05bhlj7Us3fXf3+l8=
=biJi
-----END PGP SIGNATURE-----

Re: reiserfs, xfs, ext2, ext3

[john slee]

> quite a bit of scope for improvement.  Commercial caching systems have
> demonstrated thoughput of thousands of requests/s with similar
> hardware, but I suspect Tux-ification of Squid will be necessary to

not at all, search for X15 in april/may linux-kernel archives.  most of
the specific improvements tux made have been reduced to improvements for
the general case, hence squid (or equivalent) could probably improve a
fair amount.

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

john slee wrote:

> > quite a bit of scope for improvement.  Commercial caching systems have
> > demonstrated thoughput of thousands of requests/s with similar
> > hardware, but I suspect Tux-ification of Squid will be necessary to
>
> not at all, search for X15 in april/may linux-kernel archives.  most of
> the specific improvements tux made have been reduced to improvements for
> the general case, hence squid (or equivalent) could probably improve a
> fair amount.
>
> j.
>
> --
> "Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

squid needs a deep rewrite, and the sponsor for our doing that is flaking
regarding sending us money, so for now I have to say to people that even
though reiserfs is faster for squid than ext2, the bottleneck is squid not
reiserfs, and you really should use the proprietary stuff because the
proprietary guys have taken squid, rewritten its engine which is badly
designed, stolen the gpl code, and nobody is suing them for it and they are
so much faster than squid that the cost of the software is worth paying for
(unless you dislike stolen gpl code:-(, and even then there are some like
Novell that didn't steal from squid and are faster).

Hans

Re: reiserfs, xfs, ext2, ext3

[Joel Jaeggli]

I have a proxy server that's been running 2.4.3pre4 with reiserfs for the
partitions on the cache disks. it has an uptime of 43 days at this point.
it wasn't very stable at all (two crashes in one week) with 2.4.2. I'll be
building 2.4.4 something when I get back from ghana to the US, but I don't
want to reboot it onto a fresh kernel while I'm 11,000 miles away, serial
console notwithstanding.

Overall I'm of the belief that reiserfs is robust enough for mainstream
use, and it's significantly faster than ext2 for the squid box, you do as
usal need to be a bit selective about what kernel you choose to run.

On Wed, 9 May 2001, Martín Marqués wrote:

> Hi,
>
> We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to
> come so we can change our proxy server, that will run on Linux with Squid.
> One disk will go inside (I think?) and the other 4 on a tower conected to the
> RAID, which will be have the cache of the squid server.
>
> One of my partners thinks that we should use reiserfs on all the server (the
> partitions of the Linux distro, and the cache partitions), and I found out
> that reiserfs has had lots of bugs, and is marked as experimental in kernel
> 2.4.4. Not to mention that the people of RH discourage there users from using
> it.
>
> There has also been lots of talks about reiserfs being the cause of some data
> lose and performance lose (not sure about this last one).
>
> So what I want is to know which is the status of this 3 journaling FS. Which
> is the one we should look for?
>
> I think that the data lose is not significant in a proxy cache, if the FS is
> really fast, as is said reiserfs is.
>
> Saludos... :-)
>
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: reiserfs, xfs, ext2, ext3

[Martín Marqués]

On Mié 09 May 2001 21:32, Joel Jaeggli wrote:
> I have a proxy server that's been running 2.4.3pre4 with reiserfs for the
> partitions on the cache disks. it has an uptime of 43 days at this point.
> it wasn't very stable at all (two crashes in one week) with 2.4.2. I'll be
> building 2.4.4 something when I get back from ghana to the US, but I don't
> want to reboot it onto a fresh kernel while I'm 11,000 miles away, serial
> console notwithstanding.
>
> Overall I'm of the belief that reiserfs is robust enough for mainstream
> use, and it's significantly faster than ext2 for the squid box, you do as
> usal need to be a bit selective about what kernel you choose to run.

Could you give un information on the hardware you're using for that proxy?

Saludos... :-)

-- 
El mejor sistema operativo es aquel que te da de comer.
Cuida tu dieta.
-----------------------------------------------------------------
Martin Marques                  |        mmarques@unl.edu.ar
Programador, Administrador      |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------

Re: reiserfs, xfs, ext2, ext3

[Daniel Podlejski]

In linux-kernel, martin@bugs.unl.edu.ar wrote:
:  We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to 
:  come so we can change our proxy server, that will run on Linux with Squid. 
:  One disk will go inside (I think?) and the other 4 on a tower conected to the 
:  RAID, which will be have the cache of the squid server.

Reiser is not good idea for squid cache. Why ? Squids cache is hashed
by default to minimize "big directory effect". Reiserfs is fast on
realy big directories, but it eat more cpu than ext2. On high loaded
cache servers cpu utilization on reiser can be realy big.
Better way is make more subdirectories in squid cache, and use
filesystem, that eat less of cpu.

-- 
Daniel Podlejski <underley@underley.eu.org>
   ... I am immortal, I have inside me blood of kings,
   I have no rival, No man can bemy equal ...

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Daniel Podlejski wrote:

> In linux-kernel, martin@bugs.unl.edu.ar wrote:
> :  We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to
> :  come so we can change our proxy server, that will run on Linux with Squid.
> :  One disk will go inside (I think?) and the other 4 on a tower conected to the
> :  RAID, which will be have the cache of the squid server.
>
> Reiser is not good idea for squid cache. Why ? Squids cache is hashed
> by default to minimize "big directory effect". Reiserfs is fast on
> realy big directories, but it eat more cpu than ext2. On high loaded
> cache servers cpu utilization on reiser can be realy big.
> Better way is make more subdirectories in squid cache, and use
> filesystem, that eat less of cpu.
>
> --
> Daniel Podlejski <underley@underley.eu.org>
>    ... I am immortal, I have inside me blood of kings,
>    I have no rival, No man can bemy equal ...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Nice theory, but the benchmarks say the opposite.  Turn off tails, use reiserfs
raw, and we are the fastest way to do squid, which is still way slower than the
proprietary solutions that don't use squid.  (squid's user space architecture is
poorly threaded, and that becomes the bottleneck.)

Hans

Re: reiserfs, xfs, ext2, ext3

[Matthias Andree]

On Wed, 09 May 2001, Martín Marqués wrote:

> There has also been lots of talks about reiserfs being the cause of
> some data lose and performance lose (not sure about this last one).

I never experienced ReiserFS data loss, but I did experience read
performance loss over ext2fs and switched that file system back to ext2.
The ReiserFS people could not reproduce the problem, so I'm not sure
what was the actual cause.

ext3fs has never given me any problems, but I did not have it in
production use where I discovered major ReiserFS <-> kNFSd
incompatibilities. ext3 has a 0.0.x version number which suggests it's
not meant for production use. 

XFS is claimed to work with NFS, but not currently availabe for Linux
2.4.4.

JFS has some showstopper bugs that would prevent me from using it.

If you're deploying a cache partition such as /var/squid (possibly
having log files in another /var/log partition on another disk drive),
what's the point about not running (e.  g.) mke2fs and squid -z on boot,
as well as mounting the system partitions (/usr) read-only (prevents
fsck on next reboot)? mke2fs is faster than reiserfs recovery probably
;-)

Re: reiserfs, xfs, ext2, ext3

[Tony Hoyle]

Matthias Andree wrote:

> ext3fs has never given me any problems, but I did not have it in
> production use where I discovered major ReiserFS <-> kNFSd
> incompatibilities. ext3 has a 0.0.x version number which suggests it's
> not meant for production use. 

Hmm... Reiserfs is incompatible with knfsd?  That might explain the 
massive data loss I was getting with reiserfs (basically I'd have to 
reformat and reinstall every couple of weeks).  The machine this was 
happening with also exports my apt cache for the rest of the network.

Tony

-- 
Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

tmh@magenta-netlogic.com

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Tony Hoyle wrote:

> Matthias Andree wrote:
>
> > ext3fs has never given me any problems, but I did not have it in
> > production use where I discovered major ReiserFS <-> kNFSd
> > incompatibilities. ext3 has a 0.0.x version number which suggests it's
> > not meant for production use.
>
> Hmm... Reiserfs is incompatible with knfsd?  That might explain the
> massive data loss I was getting with reiserfs (basically I'd have to
> reformat and reinstall every couple of weeks).  The machine this was
> happening with also exports my apt cache for the rest of the network.
>
> Tony
>
> --
> Where a calculator on the ENIAC is equpped with 18,000 vaccuum
> tubes and weighs 30 tons, computers in the future may have only
> 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
> -- Popular Mechanics, March 1949
>
> tmh@magenta-netlogic.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

we have a patch on our website.

Hans

[OT] Linux on ENIAC...

[Laramie Leavitt]

> >
> > Tony
> >
> > Where a calculator on the ENIAC is equipped with 18,000 vaccuum
> > tubes and weighs 30 tons, computers in the future may have only
> > 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
> > -- Popular Mechanics, March 1949
> >

ANNOUNCEMENT: New Linux port.

Announcing the heaviest Linux machine available.  The port
of Linux to the ENIAC is the next step in open source 
productivity and may be the most important invention in the
world.  Since it is so difficult to find a modern
operating system for the world class ENIAC system, ENIAC Linux
will present you an entirely new world.

There were only a few problems with Linux and ENIAC--The smallest
Linux kernel is still a hundreds of thousands bytes. In order to
work around this small detail, we have stripped Linux of all the
unnecessary subsystems.  Now, after removing the SCSI, PCI, IDE,
Memory, NET, USB, Printing, Processes and Scheduling subsystems, 
ENIAC Linux is also the world's smallest Linux.  Since ENIAC lacks
online storage, ENIAC Linux uses a sophisticated paper diagram to
to minimize storage requirements and improve wiring speed.

With all these improvements, however, Linux ENIAC is still a very
buggy system.  We are constantly replacing buggy and burnt-out pieces 
of the ENIAC Linux machine.  We hope that the next-generation EDSAC, 
with a reduction in size by 16,000 tubes and new memory technology,
will improve the responsiveness, effectiveness and reliability of 
the Linux port to the ENIAC architecture.

Re: [OT] Linux on ENIAC...

[mirabilos]

> of the ENIAC Linux machine.  We hope that the next-generation EDSAC, 

Wasn't it EDVAC IIRC?

-mirabilos
-- 
EA F0 FF 00 F0 #$@%CARRIER LOST

Re: reiserfs, xfs, ext2, ext3

[Matthias Andree]

On Thu, 10 May 2001, Hans Reiser wrote:

> > Hmm... Reiserfs is incompatible with knfsd?  That might explain the
> 
> we have a patch on our website.

I'm always wondering why the patch hasn't been merged. Is it so
dangerous to apply in that it might distract other pieces of the system?
Has anyone reported increased problems after applying the patch?

-- 
Matthias Andree

Re: reiserfs, xfs, ext2, ext3

[Chris Mason]

On Friday, May 11, 2001 01:39:13 AM +0200 Matthias Andree
<matthias.andree@stud.uni-dortmund.de> wrote:

> On Thu, 10 May 2001, Hans Reiser wrote:
> 
>> > Hmm... Reiserfs is incompatible with knfsd?  That might explain the
>> 
>> we have a patch on our website.
> 
> I'm always wondering why the patch hasn't been merged. Is it so
> dangerous to apply in that it might distract other pieces of the system?
> Has anyone reported increased problems after applying the patch?

It requires explicit changes to each filesystem that wants to work over
NFS, and is a somewhat large change.

-chris

Re: reiserfs, xfs, ext2, ext3

[Henning P. Schmiedehausen]

Chris Mason <mason@suse.com> writes:

>It requires explicit changes to each filesystem that wants to work over
>NFS, and is a somewhat large change.

Come on, we got zerocopy TCP pushed into a stable kernel release with
the words "get over it". 

So please, push this patch to Linus; I really like to "get over it". 

I think with the growing acceptance of ReiserFS in the Linux
community, it is tiresome to have to apply a patch again and again
just to get working NFS. 2.2 NFS horrors all over again.

	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

"Henning P. Schmiedehausen" wrote:

> Chris Mason <mason@suse.com> writes:
>
> >It requires explicit changes to each filesystem that wants to work over
> >NFS, and is a somewhat large change.
>
> Come on, we got zerocopy TCP pushed into a stable kernel release with
> the words "get over it".
>
> So please, push this patch to Linus; I really like to "get over it".
>
> I think with the growing acceptance of ReiserFS in the Linux
> community, it is tiresome to have to apply a patch again and again
> just to get working NFS. 2.2 NFS horrors all over again.
>
>         Regards
>                 Henning
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de
>
> Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
> D-91054 Buckenhof     Fax.: 09131 / 50654-20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

nikita, ask Neil what the timeline is for it going into Linux.

Hans

Re: reiserfs, xfs, ext2, ext3

[Alan Cox]

> I think with the growing acceptance of ReiserFS in the Linux
> community, it is tiresome to have to apply a patch again and again
> just to get working NFS. 2.2 NFS horrors all over again.

The zero copy patches were basically self contained and tested for 6 months.
The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel.
There is a difference.

Alan

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Alan Cox wrote:

> > I think with the growing acceptance of ReiserFS in the Linux
> > community, it is tiresome to have to apply a patch again and again
> > just to get working NFS. 2.2 NFS horrors all over again.
>
> The zero copy patches were basically self contained and tested for 6 months.
> The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel.
> There is a difference.
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Are you referring to Neil Brown's nfs operations patch as being as ugly as
hell, or something else?  Just want to understand what you are saying before
arguing.....

NFS is ugly as hell, and we just try to conform to whatever is the latest trend
expected to be accepted since I really don't care so long as it works and
doesn't uglify ReiserFS more than necessary.  If you have another approach, one
that is less ugly, please let us know.  This is the first I have heard someone
complain, I thought his patch was liked by Linus architecturally and that it
would be going in sometime real soon now (which is why we coded for it).  Can
you articulate why you dislike it in more detail?

Hans

Re: reiserfs, xfs, ext2, ext3

[Alan Cox]

> Are you referring to Neil Brown's nfs operations patch as being as ugly as
> hell, or something else?  Just want to understand what you are saying before
> arguing.....

Andi has sent me some stuff to look at. He listed four implementations and I've
only seen two of them

> NFS is ugly as hell, and we just try to conform to whatever is the latest trend
> expected to be accepted since I really don't care so long as it works and
> doesn't uglify ReiserFS more than necessary.  If you have another approach, one
> that is less ugly, please let us know.  This is the first I have heard someone

Oh believe me we agree in great detail where the -problem- is. Unfortunately
the spec is kind of stuck.  Its finding a minimally invasive solution for 2.4
pending fixing it properly in 2.5


Alan

Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Alan Cox wrote:

> > Are you referring to Neil Brown's nfs operations patch as being as ugly as
> > hell, or something else?  Just want to understand what you are saying before
> > arguing.....
>
> Andi has sent me some stuff to look at. He listed four implementations and I've
> only seen two of them

did you see an implementation which adds operations to VFS and is written by Neil
Brown (with reiserfs portions by Chris and Nikita)?

>
>
> > NFS is ugly as hell, and we just try to conform to whatever is the latest trend
> > expected to be accepted since I really don't care so long as it works and
> > doesn't uglify ReiserFS more than necessary.  If you have another approach, one
> > that is less ugly, please let us know.  This is the first I have heard someone
>
> Oh believe me we agree in great detail where the -problem- is. Unfortunately
> the spec is kind of stuck.  Its finding a minimally invasive solution for 2.4
> pending fixing it properly in 2.5
>
> Alan

Tell us what to code for, and so long as it doesn't involve looking up files by
their 32 bit inode numbers we'll probably be happy to code to it.  The Neil Brown
stuff is already coded for though.

Hans

Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3

[Albert D. Cahalan]

Hans Reiser writes:

> Tell us what to code for, and so long as it doesn't involve looking
> up files by their 32 bit inode numbers we'll probably be happy to
> code to it.  The Neil Brown stuff is already coded for though.

Next time around, when you update the on-disk format, how about
allowing for such a thing?

You could have a tree that maps from inode number to whatever
you need to find a file. This shouldn't affect much more than
file creation and deletion. Maybe it will allow for a more
robust fsck as well, helping to justify the cost.

It would be really nice to be able to find all filenames that
refer to a given inode number.

Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

"Albert D. Cahalan" wrote:

> Hans Reiser writes:
>
> > Tell us what to code for, and so long as it doesn't involve looking
> > up files by their 32 bit inode numbers we'll probably be happy to
> > code to it.  The Neil Brown stuff is already coded for though.
>
> Next time around, when you update the on-disk format, how about
> allowing for such a thing?
>
> You could have a tree that maps from inode number to whatever
> you need to find a file. This shouldn't affect much more than
> file creation and deletion. Maybe it will allow for a more
> robust fsck as well, helping to justify the cost.
>
> It would be really nice to be able to find all filenames that
> refer to a given inode number.

It would have a significant performance impact and use disk space.

Hans

Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3

[Chris Mason]

On Friday, May 11, 2001 12:07:08 PM -0700 Hans Reiser <reiser@namesys.com>
wrote:

> "Albert D. Cahalan" wrote:
> 
>> Hans Reiser writes:
>> 
>> > Tell us what to code for, and so long as it doesn't involve looking
>> > up files by their 32 bit inode numbers we'll probably be happy to
>> > code to it.  The Neil Brown stuff is already coded for though.
>> 
>> Next time around, when you update the on-disk format, how about
>> allowing for such a thing?
>> 
>> You could have a tree that maps from inode number to whatever
>> you need to find a file. This shouldn't affect much more than
>> file creation and deletion. Maybe it will allow for a more
>> robust fsck as well, helping to justify the cost.
>> 
>> It would be really nice to be able to find all filenames that
>> refer to a given inode number.
> 
> It would have a significant performance impact and use disk space.

inode numbers have in the past been enough to find the object in the
filesystem, and more than a few applications have counted on this.  In my
mind, the difference between an interesting research project and a real
professional grade product is compatibility with these kinds of traditional
expectations.

I think reiserfs has been lucky that we've managed to work around the inode
number problem so far (with help from Neil, Andi and others), but the
number of hours wasted on cramming the 64bit key into various applications
has been huge.

It only makes a speed difference because the original format relies on it.
When redoing the format for v4, this kind of thing should at least be
considered. </soapbox>

-chris

Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3

[Chris Mason]

On Friday, May 11, 2001 04:00:20 AM -0700 Hans Reiser <reiser@namesys.com>
wrote:

> Alan Cox wrote:
> 
>> > Are you referring to Neil Brown's nfs operations patch as being as
>> > ugly as hell, or something else?  Just want to understand what you are
>> > saying before arguing.....
>> 
>> Andi has sent me some stuff to look at. He listed four implementations
>> and I've only seen two of them
> 
> did you see an implementation which adds operations to VFS and is written
> by Neil Brown (with reiserfs portions by Chris and Nikita)?

I coded up a mixture of Andi's 2.2.x apis and Neil's 2.4.x stuff and sent
it out for review a little while ago. It isn't as good as Neil's stuff, but
it doesn't require changing the other filesystems.  If it looked good to
the NFS guys and the other FS guys don't hate it, I'll push it around for
testing/inclusion.

This would be my preferred solution right now, since it could also work for
AFS.

-chris

2.4.6-pre3 + reiserfs + NFS peculiarities

[Guennadi Liakhovetski]

Hello

We've installed reiserfs on a logical volume, consisting of 2 60GB hard
drives, and exported it over NFS. Kernel 2.4.6-pre3. In the beginning
everything seemed to be fine. But then a few strange things have happened:

1. I tried running a program on a host, importing the filesystem in
question, and sending its output to it.  The program uses fwrite function,
and checks the number of items written, so, it didn't match. On the second
run yet another (similar writing)  problem occured, but since then this
program has been running for a few hours already without any noticeable
errors. The remote host is Solaris-2.7 on a Sparc.

2. Another strangeness - this filesystem is also mounted on yet another
Linux machine, running 2.4.5. Actually, the situation is slightly more
complicated: on host a we've got 2 logical volumes with reiserfs: a1 and
a2, mounted in /mnt/lvm/a1 and /mnt/lvm/a2.  And the whole directory
/mnt/lvm is exported over NFS. So, when on a remote host you do df -k on
that mounted filesystem, all 3 values (total, occupied, free) are wrong.

3. All (except ext2, which is used for /) filesystems are compiled as
modules. reiserfs is loaded on boot, when lvols are mounted. I tried
mounting a fat-diskette, and got the following mesage:

read_old_super_block: try to find super block in old location
read_old_super_block: can't find a reiserfs filesystem on dev 02:00.

If all the problems, mentioned above are known and have known solutions
(patches, etc, however, I checked the reiserfs ftp-site - no patches for
2.4.6 yet), please let me know. Shall I use an earlier kernel version? If
they are new, I'll gladly provide any necessary additional information.
Below is lspci output:

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 50)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 7a)

Thanks
Guennadi
___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, Sheffield, U.K.
email: g.liakhovetski@sheffield.ac.uk

Re: reiserfs, xfs, ext2, ext3

[Gregory Maxwell]

On Fri, May 11, 2001 at 05:04:10PM +0100, Alan Cox wrote:
> > I think with the growing acceptance of ReiserFS in the Linux
> > community, it is tiresome to have to apply a patch again and again
> > just to get working NFS. 2.2 NFS horrors all over again.
> 
> The zero copy patches were basically self contained and tested for 6 months.
> The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel.
> There is a difference.

Does NFS server support for one of the included FSes not belong in the
kernel?  or is it that a better way is possible and this ugly one should not
be included?  If the latter, has anyone told Hans how to do it 'right' so he
can assign someone to the task?

Re: reiserfs, xfs, ext2, ext3

[Alan Cox]

> Does NFS server support for one of the included FSes not belong in the
> kernel?  or is it that a better way is possible and this ugly one should not
> be included?  If the latter, has anyone told Hans how to do it 'right' so he
> can assign someone to the task?

The patch Andi forwarded me for NFS still isnt too great but it meets the 
requirements in that it doesnt touch non reiserfs file systems and its fairly
easy to verify that the NFS code paths are not changed for other file systems

Re: reiserfs, xfs, ext2, ext3

[Matthias Andree]

On Thu, 10 May 2001, Tony Hoyle wrote:

> Hmm... Reiserfs is incompatible with knfsd?  That might explain the 
> massive data loss I was getting with reiserfs (basically I'd have to 
> reformat and reinstall every couple of weeks).  The machine this was 
> happening with also exports my apt cache for the rest of the network.

You're not getting data loss, but access denied, when hitting
incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less
of a problem. Please search the reiserfs list archives for details.
vs-13048 is a good search term, I believe.

Re: reiserfs, xfs, ext2, ext3

[Tony Hoyle]

Matthias Andree wrote:

> You're not getting data loss, but access denied, when hitting
> incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less
> of a problem. Please search the reiserfs list archives for details.
> vs-13048 is a good search term, I believe.

Data is lost:

Root can't access the files.
Reiserfsck can't repair the files.
The files that are corrupted are unrelated to the ones exported over NFS 
(which makes me wonder if it's the same bug).

File corruption would begin a couple of hours after the volume was 
formatted, and become catastrophic within a couple of days.

Until the fix is merged I'm not going within 100 miles of reiserfs!

Tony

-- 
Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

tmh@magenta-netlogic.com

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Tony Hoyle wrote:

> Matthias Andree wrote:
>
> > You're not getting data loss, but access denied, when hitting
> > incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less
> > of a problem. Please search the reiserfs list archives for details.
> > vs-13048 is a good search term, I believe.
>
> Data is lost:
>
> Root can't access the files.
> Reiserfsck can't repair the files.
> The files that are corrupted are unrelated to the ones exported over NFS
> (which makes me wonder if it's the same bug).
>
> File corruption would begin a couple of hours after the volume was
> formatted, and become catastrophic within a couple of days.
>
> Until the fix is merged I'm not going within 100 miles of reiserfs!
>
> Tony
>
> --
> Where a calculator on the ENIAC is equpped with 18,000 vaccuum
> tubes and weighs 30 tons, computers in the future may have only
> 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
> -- Popular Mechanics, March 1949
>
> tmh@magenta-netlogic.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

there is a patch, it is on our website, what is the problem?

Re: reiserfs, xfs, ext2, ext3

[Matthias Andree]

On Fri, 11 May 2001, Tony Hoyle wrote:

> Matthias Andree wrote:
> 
> > You're not getting data loss, but access denied, when hitting
> > incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less
> > of a problem. Please search the reiserfs list archives for details.
> > vs-13048 is a good search term, I believe.
> 
> Data is lost:

That's not true, at least not in my case. Data is temporarily
inaccessible, and in extreme cases, the Kernel might panic, but I never
suffered from permanent damage. There might be other reasons, old
kernel, old patch, old user-space utilities, hardware flaws. I'm not a
good friend of ReiserFS on Linux 2.2 in production, but let's please
keep honest, regardless of how big the anger may have grown.

> Root can't access the files.

True, catches EACCES.

> Reiserfsck can't repair the files.

Also true, because they're not broken.

> The files that are corrupted are unrelated to the ones exported over NFS 
> (which makes me wonder if it's the same bug).

It's probably not. vs-13048 can usually be rectified (ugly, slow but
usually works on machines even with 256 MB RAM and 1/2 GB swap) by ls
-laR / or treescan -stat /.

> File corruption would begin a couple of hours after the volume was 
> formatted, and become catastrophic within a couple of days.
> 
> Until the fix is merged I'm not going within 100 miles of reiserfs!

Well, it would be really a good idea to consider if the patch might be
merged into ReiserFS 3.5.33, but AFAICS, the ReiserFS team have focused
on getting 3.6 solid. Hans, does ReiserFS 3.6 suffer from vs-13048 or
similar problems with NFS in plain Linux 2.4.4 or does ist still need
patches as 3.5.x does?

Re: reiserfs, xfs, ext2, ext3

[Tony Hoyle]

Matthias Andree wrote:

> It's probably not. vs-13048 can usually be rectified (ugly, slow but
> usually works on machines even with 256 MB RAM and 1/2 GB swap) by ls
> -laR / or treescan -stat /.


ls can't access the files either, so I don't see how that could rectify 
anything.  The entire directory becomes inaccessible.   This happened to 
/lib once.  Nasty.

I'd like to be able to use something like reiserfs, especially when 
developing (it reduces boot time a lot).  However to call it 'stable' on 
2.4.4 is simply wrong.  If/when the nfs fix gets merged and tested 
*then* it stands a chance of being called stable.


Tony


-- 
Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

tmh@magenta-netlogic.com

Re: reiserfs, xfs, ext2, ext3

[Matthias Andree]

On Fri, 11 May 2001, Tony Hoyle wrote:

> ls can't access the files either, so I don't see how that could rectify 
> anything.  The entire directory becomes inaccessible.   This happened to 
> /lib once.  Nasty.

No-one can access the files once the caches are hosed. Purge the
inode/dentry caches and retry.

> I'd like to be able to use something like reiserfs, especially when 
> developing (it reduces boot time a lot).  However to call it 'stable' on 
> 2.4.4 is simply wrong.  If/when the nfs fix gets merged and tested 
> *then* it stands a chance of being called stable.

Does that actually apply to 2.4.4 or rather to 2.2.19?

Re: reiserfs, xfs, ext2, ext3

[Shawn]

On 05/10, Matthias Andree rearranged the electrons to read:
> On Wed, 09 May 2001, Mart?n Marqu?s wrote:
> 
> > There has also been lots of talks about reiserfs being the cause of
> > some data lose and performance lose (not sure about this last one).
> 
> I never experienced ReiserFS data loss, but I did experience read
> performance loss over ext2fs and switched that file system back to ext2.
> The ReiserFS people could not reproduce the problem, so I'm not sure
> what was the actual cause.
> 
> ext3fs has never given me any problems, but I did not have it in
> production use where I discovered major ReiserFS <-> kNFSd
> incompatibilities. ext3 has a 0.0.x version number which suggests it's
> not meant for production use. 
> 
> XFS is claimed to work with NFS, but not currently availabe for Linux
> 2.4.4.

$ uname -r
2.4.4-ac5.xfs
$ uptime
  9:20am  up 1 day, 18:28,  4 users,  load average: 0.00, 0.00, 0.00

--
Hob Goblin
z3rk@ahkbarr.dynip.com

A society that will trade a little liberty for a little order will lose
both and deserve neither. - Thomas Jefferson

Re: reiserfs, xfs, ext2, ext3

[Hans Reiser]

Matthias Andree wrote:

>
> If you're deploying a cache partition such as /var/squid (possibly
> having log files in another /var/log partition on another disk drive),
> what's the point about not running (e.  g.) mke2fs and squid -z on boot,
> as well as mounting the system partitions (/usr) read-only (prevents
> fsck on next reboot)? mke2fs is faster than reiserfs recovery probably
> ;-)

For that particular application of squid, it happens we are much much faster
than ext2, if you apply all the right tunings and especially if you apply the
reiserfs_raw patch.

Hans

Re: reiserfs, xfs, ext2, ext3

[Gregory Maxwell]

On Thu, May 10, 2001 at 01:44:53PM +0200, Matthias Andree wrote:
[snip]
> If you're deploying a cache partition such as /var/squid (possibly
> having log files in another /var/log partition on another disk drive),
> what's the point about not running (e.  g.) mke2fs and squid -z on boot,
> as well as mounting the system partitions (/usr) read-only (prevents
> fsck on next reboot)? mke2fs is faster than reiserfs recovery probably
> ;-)

A while ago I configured a few squid boxes which ran off of a read-only
system. Mke2fs is actually unacceptably slow on large file systems, faster
then fsck, but still time consuming. I found that zeroing out the disk, then
formating it and saving the non-zero blocks, replaying them on reboot to be
an acceptable solution.

Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Ralph Corderoy]

[Note, suspect this didn't appear earlier because of vger disliking
mention of De*tschland!]

Hi,

I've been talking with UK company Amstrad PLC regarding their
obligations under the GNU GPL for the Linux they ship on their new E3
videophone in the UK.

    http://www.amstrad.com/default.shtml
    http://www.amstrad.com/e3_intro.html

It's based on a TI OMAP ARM SoC and runs MontaVista Linux.

    http://www.linuxdevices.com/news/NS6619549199.html
    http://www.amstrad.com/news_linux.html
    http://www.mvista.com/news/2004/amstrad.html

They're shipping the E3 in a box for sale off the shelf in places like
Dixons, Currys, etc.  I believe they haven't complied with section 3 of
the GNU GPL.  There's no source shipped in the box, i.e. 3(a).  There's
no written notice either, 3(b), in the thick manual, or the other sheets
of paper in the box, printed on the box, or on stickers on the E3.  I
inspected the contents of a box, serial number available if required, at
my local store with the agreement of a staff member who opened all the
wrappings.  The manual had "Issue No. 9 (D1/H4)" printed at the bottom
right corner of page 1, as does the online PDF of the manual available
for download.

    ftp://ftp.amstrad.co.uk/e3_userguide_web_v1.zip   9,614,278 bytes

I am not an E3 owner, nor have I been passed the GPL'd binaries with or
without a written offer under 3(c).

Initially I tried discussing their compliance with
support@amserve.ltd.uk but they were only willing to discuss source
access details on presentation of proof of purchase, e.g. serial number,
registered phone number, etc., and weren't willing to discuss if they
were complying with the GPL.

So I next emailed Sir Alan Sugar, Amstrad Chairman, and got a reply from
Brian Eaton, E-Business Director.  He initially, like Support, seemed
confident they were complying but I got the impression he hadn't
actually read my argument so I tried once more to point out how what
they were doing wasn't complying.  This time I got a reply saying

    "Your comments are noted. We will get back to you shortly. In the
    meantime can you let me have your postal address please so that I
    can send you something?"

This, coupled with activity to my Amstrad Linux page from several
browsers at an IP address similar to Amstrad's public ones around the
time Brian's reply was sent, makes me think I should make the issue
public before anything that would prevent me doing that may happen.

All my correspondence is attached but the most interesting is message 9
where I spell out the license requirements to Brian Eaton, 10 where he
yesterday asked for my address, and 11 where he re-stated they've don't
have to discuss it with me.  I think they're failing to comply with
section 3.  There's other minor things too in the manual that I've
highlighted.  They're right in saying they've no obligation to discuss
their compliance with me.  I'm hoping that by posting here a copyright
holder will query their apparent lack of compliance and Amstrad will be
happy to converse with them.

To re-iterate, there's no source code or written offer in the box.  They
say they'll provide a URL to an E3 owner on proof of ownership but
that's insufficient.  The situation is made more complex by the E3
downloading software updates, including seemingly the kernel, so they'll
be multiple versions to provide source for over time.

Cheers,


Ralph.


------- Forwarded Messages

Return-Path: ralph@inputplus.co.uk
Delivery-Date: Thu Sep 23 23:57:40 2004
Return-Path: <ralph@inputplus.co.uk>
Received: from blake.inputplus.co.uk (ralph@localhost)
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8NMvdI03159;
	Thu, 23 Sep 2004 23:57:40 +0100
Message-Id: <200409232257.i8NMvdI03159@blake.inputplus.co.uk>
To: support@amserve.ltd.uk
Subject: Source for E3's MontaVista Linux.
Date: Thu, 23 Sep 2004 23:57:39 +0100
From: Ralph Corderoy <ralph@inputplus.co.uk>


Hi,

I see from the joint MontaVista/Amstrad press release that MontaVista
Linux has been chosen for the E3's operating system.  I've had a hunt
around the amstrad.co.uk web site and haven't been able to find a
download of the source for the binaries shipped on the E3 that are
covered by the GNU General Public License.

Could you please let me know how to obtain them.

Many thanks,


Ralph.

------- Message 2

Return-Path: support@amserve.ltd.uk
Delivery-Date: Fri Sep 24 14:13:40 2004
Return-Path: <support@amserve.ltd.uk>
Received: from localhost (localhost [127.0.0.1])
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8ODDeu07998
	for <ralph@localhost>; Fri, 24 Sep 2004 14:13:40 +0100
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from inputplus.co.uk [66.39.34.92]
	by localhost with POP3 (fetchmail-5.9.0)
	for ralph@localhost (single-drop); Fri, 24 Sep 2004 14:13:40 +0100 (BST)
Received: (qmail 42269 invoked from network); 24 Sep 2004 13:07:22 -0000
Received: from mail.amstrad.co.uk (HELO mrs.amstrad.co.uk) (193.133.25.43)
  by ruis.pair.com with SMTP; 24 Sep 2004 13:07:22 -0000
Received: from mailserver2.amstrad.co.uk ([192.9.200.8]) by mrs.amstrad.co.uk with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 24 Sep 2004 14:07:21 +0100
Received: by MAILSERVER2 with Internet Mail Service (5.5.2653.19)
	id <SST6CYKP>; Fri, 24 Sep 2004 14:07:21 +0100
Message-ID: <EC49BB70F1DDD6118C620002B3512AD5039BD5D3@MAILSERVER2>
From: Amserve Support <support@amserve.ltd.uk>
To: "'Ralph Corderoy'" <ralph@inputplus.co.uk>
Subject: RE: Source for E3's MontaVista Linux.
Date: Fri, 24 Sep 2004 14:07:19 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 24 Sep 2004 13:07:21.0679 (UTC) FILETIME=[6D7965F0:01C4A237]
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00
X-Spam-Flag: NO
X-Spam-Level: 

Thank you for your email.

Please provide the serial number from your E3 unit (located on the underside
of the unit or by pressing SETUP and option 1) so that we can provide these
details.

Regards

Amserve Support

- -----Original Message-----

[Snip duplicate of message 1.]

------- Message 3

Return-Path: ralph@inputplus.co.uk
Delivery-Date: Sat Sep 25 10:20:53 2004
Return-Path: <ralph@inputplus.co.uk>
Received: from blake.inputplus.co.uk (ralph@localhost)
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8P9Krn05212;
	Sat, 25 Sep 2004 10:20:53 +0100
Message-Id: <200409250920.i8P9Krn05212@blake.inputplus.co.uk>
To: Amserve Support <support@amserve.ltd.uk>
Subject: Re: Source for E3's MontaVista Linux. 
In-Reply-To: Message from Amserve Support <support@amserve.ltd.uk> 
   of "Fri, 24 Sep 2004 14:07:19 BST." <EC49BB70F1DDD6118C620002B3512AD5039BD5D3@MAILSERVER2> 
Date: Sat, 25 Sep 2004 10:20:53 +0100
From: Ralph Corderoy <ralph@inputplus.co.uk>


Dear Support,

Thanks for your prompt reply.

> > I see from the joint MontaVista/Amstrad press release that
> > MontaVista Linux has been chosen for the E3's operating system.
> > I've had a hunt around the amstrad.co.uk web site and haven't been
> > able to find a download of the source for the binaries shipped on
> > the E3 that are covered by the GNU General Public License.
> > 
> > Could you please let me know how to obtain them.
>
> Please provide the serial number from your E3 unit (located on the
> underside of the unit or by pressing SETUP and option 1) so that we
> can provide these details.

I can't do that as I don't have an E3.  I was assuming that out of the
three choices, a, b, or c, from section 3 of the GNU GPL, Amstrad had
chosen b.

    http://www.gnu.org/copyleft/gpl.html#SEC3

    You may copy and distribute the Program (or a work based on it,
    under Section 2) in object code or executable form under the terms
    of Sections 1 and 2 above provided that you also do one of the
    following:

        a) Accompany it with the complete corresponding machine-readable
        source code, which must be distributed under the terms of
        Sections 1 and 2 above on a medium customarily used for software
        interchange; or,

Let me know if a has been chosen and I'll contact an E3 owner who'll
already have the source and may be willing to distribute it to me.

        b) Accompany it with a written offer, valid for at least three
        years, to give any third party, for a charge no more than your
        cost of physically performing source distribution, a complete
        machine-readable copy of the corresponding source code, to be
        distributed under the terms of Sections 1 and 2 above on a
        medium customarily used for software interchange; or,

I assumed Amstrad chose b and I am turning up as `any third party'
requesting a copy of the source code.  

        c) Accompany it with the information you received as to the
        offer to distribute corresponding source code. (This alternative
        is allowed only for noncommercial distribution and only if you
        received the program in object code or executable form with such
        an offer, in accord with Subsection b above.) 

c doesn't seem a possible choice for Amstrad.

a is a useful one because it means that parties cannot request source
from Amstrad as Amstrad ensured source travelled with all binaries.  It
becomes more awkward if the device may update its GPL'd software after
shipping to the customer though.

To save overhead, b can be largely satisfied by making the various
versions of source available on the Internet for download as they are
distributed in binary form.  Most people wanting the source would prefer
this method although as I understand it Internet access alone isn't
sufficient to satisfy section 3 and a physical medium, obtainable by
mail-order, must also be available even if no one ever uses it.

As ever with these things, I am not a lawyer so if you think my
interpretation is wrong I'd like to know.  Otherwise, could you please
let me know which one of 3a, 3b, and 3c Amstrad have chosen so I can
continue in trying to obtain the GPL'd source.

Thanks,


Ralph.

------- Message 4

Return-Path: support@amserve.ltd.uk
Delivery-Date: Mon Sep 27 11:39:07 2004
Return-Path: <support@amserve.ltd.uk>
Received: from localhost (localhost [127.0.0.1])
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8RAd7A05038
	for <ralph@localhost>; Mon, 27 Sep 2004 11:39:07 +0100
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from inputplus.co.uk [66.39.34.92]
	by localhost with POP3 (fetchmail-5.9.0)
	for ralph@localhost (single-drop); Mon, 27 Sep 2004 11:39:07 +0100 (BST)
Received: (qmail 36748 invoked from network); 27 Sep 2004 10:26:30 -0000
Received: from mail.amstrad.co.uk (HELO mrs.amstrad.co.uk) (193.133.25.43)
  by ruis.pair.com with SMTP; 27 Sep 2004 10:26:30 -0000
Received: from mailserver2.amstrad.co.uk ([192.9.200.8]) by mrs.amstrad.co.uk with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 27 Sep 2004 11:26:27 +0100
Received: by MAILSERVER2 with Internet Mail Service (5.5.2653.19)
	id <SST6DJTP>; Mon, 27 Sep 2004 11:26:27 +0100
Message-ID: <EC49BB70F1DDD6118C620002B3512AD5039BD60F@MAILSERVER2>
From: Amserve Support <support@amserve.ltd.uk>
To: "'ralph@inputplus.co.uk'" <ralph@inputplus.co.uk>
Subject: FW: Source for E3's MontaVista Linux. 
Date: Mon, 27 Sep 2004 11:26:21 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 27 Sep 2004 10:26:27.0492 (UTC) FILETIME=[725E9E40:01C4A47C]
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00
X-Spam-Flag: NO
X-Spam-Level: 


Amserve will require the following information in order to divulge any
further informatiom
 
Date of Purchase
 
Retailer
 
Serial Number of E Mailer unit
 
E Mail address.
 
Telephone number
 
Regards  Amserve


- -----Original Message-----

[Snip duplicate of message 3.]

------- Message 5

Return-Path: ralph@inputplus.co.uk
Delivery-Date: Mon Sep 27 13:08:08 2004
Return-Path: <ralph@inputplus.co.uk>
Received: from blake.inputplus.co.uk (ralph@localhost)
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8RC88D06215;
	Mon, 27 Sep 2004 13:08:08 +0100
Message-Id: <200409271208.i8RC88D06215@blake.inputplus.co.uk>
To: Amserve Support <support@amserve.ltd.uk>
Subject: Re: FW: Source for E3's MontaVista Linux. 
In-Reply-To: Message from Amserve Support <support@amserve.ltd.uk> 
   of "Mon, 27 Sep 2004 11:26:21 BST." <EC49BB70F1DDD6118C620002B3512AD5039BD60F@MAILSERVER2> 
Date: Mon, 27 Sep 2004 13:08:08 +0100
From: Ralph Corderoy <ralph@inputplus.co.uk>


Dear Support,

> > > Please provide the serial number from your E3 unit (located on the
> > > underside of the unit or by pressing SETUP and option 1) so that
> > > we can provide these details.
> > 
> > I can't do that as I don't have an E3.  I was assuming that out of
> > the three choices, a, b, or c, from section 3 of the GNU GPL,
> > Amstrad had chosen b.
> > 
> > ...
> > 
> > As ever with these things, I am not a lawyer so if you think my
> > interpretation is wrong I'd like to know.  Otherwise, could you
> > please let me know which one of 3a, 3b, and 3c Amstrad have chosen
> > so I can continue in trying to obtain the GPL'd source.
>
> Amserve will require the following information in order to divulge any
> further informatiom
>  
> Date of Purchase, Retailer, Serial Number of E Mailer unit, E Mail
> address, Telephone number.

Could you answer a simpler question?  If I buy an E3 at Dixons and open
it will I find the GPL'd source code in the box, or will I find a
written offer to provide it?  It must be one of these two otherwise
Amstrad are in violation of the GNU GPL version 2, as explained in my
previous email, that covers some of the binaries shipped in the E3 and
as such their rights under the GPL are terminated, see section 4.

    4. You may not copy, modify, sublicense, or distribute the Program
    except as expressly provided under this License.  Any attempt
    otherwise to copy, modify, sublicense or distribute the Program is
    void, and will automatically terminate your rights under this
    License.  However, parties who have received copies, or rights, from
    you under this License will not have their licenses terminated so
    long as such parties remain in full compliance.

In other words, Amstrad would be infringing copyright by selling E3s
which is a serious and easily avoidable situation.

This almost certainly isn't the case, but issuing a standard `please
supply your serial number' to all enquiries is inadequate if section 3b
of the GPL has been followed.

If that's the only procedure that has been presented to Amserve Support
perhaps my simpler question above can be passed internally to an area
that deals with licensing and copyright.  

Thanks,


Ralph.

------- Message 6

Return-Path: support@amserve.ltd.uk
Delivery-Date: Mon Sep 27 14:16:59 2004
Return-Path: <support@amserve.ltd.uk>
Received: from localhost (localhost [127.0.0.1])
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8RDGwA09799
	for <ralph@localhost>; Mon, 27 Sep 2004 14:16:58 +0100
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from inputplus.co.uk [66.39.34.92]
	by localhost with POP3 (fetchmail-5.9.0)
	for ralph@localhost (single-drop); Mon, 27 Sep 2004 14:16:58 +0100 (BST)
Received: (qmail 91407 invoked from network); 27 Sep 2004 13:08:11 -0000
Received: from mail.amstrad.co.uk (HELO mrs.amstrad.co.uk) (193.133.25.43)
  by ruis.pair.com with SMTP; 27 Sep 2004 13:08:11 -0000
Received: from mailserver2.amstrad.co.uk ([192.9.200.8]) by mrs.amstrad.co.uk with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 27 Sep 2004 14:08:10 +0100
Received: by MAILSERVER2 with Internet Mail Service (5.5.2653.19)
	id <SST6DKP0>; Mon, 27 Sep 2004 14:08:10 +0100
Message-ID: <EC49BB70F1DDD6118C620002B3512AD5039BD615@MAILSERVER2>
From: Amserve Support <support@amserve.ltd.uk>
To: "'Ralph Corderoy'" <ralph@inputplus.co.uk>
Subject: RE: FW: Source for E3's MontaVista Linux. 
Date: Mon, 27 Sep 2004 14:08:08 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 27 Sep 2004 13:08:10.0774 (UTC) FILETIME=[09F9F360:01C4A493]
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00
X-Spam-Flag: NO
X-Spam-Level: 

Thank you for your email.

We are happy to explain how we comply with the GPL to our customers. To
date, it appears that this is not so in your case. Should you purchase an E3
personal communication centre and wish to continue this correspondence,
please provide us with the unit serial number, registered email address and
purchase details we have previously requested. Following which, we will
forward the necessary information.

Regards

Amserve Support 

- -----Original Message-----

[Snip duplicate of message 5.]

------- Message 7

Return-Path: ralph@inputplus.co.uk
Delivery-Date: Mon Sep 27 23:33:22 2004
Return-Path: <ralph@inputplus.co.uk>
Received: from blake.inputplus.co.uk (ralph@localhost)
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8RMXLd04471;
	Mon, 27 Sep 2004 23:33:21 +0100
Message-Id: <200409272233.i8RMXLd04471@blake.inputplus.co.uk>
To: Sir Alan Sugar <asugar@amstrad.com>
Subject: Possible GNU GPL License Violation by Amstrad E3.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <4142.1096322842.0@blake.inputplus.co.uk>
Date: Mon, 27 Sep 2004 23:33:21 +0100
From: Ralph Corderoy <ralph@inputplus.co.uk>

- ------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4142.1096322842.1@blake.inputplus.co.uk>

Dear Sir Alan,

Since last Thursday I've been conversing by email with
support@amserve.ltd.uk regarding the meeting the license conditions of
some parts of the software that ships with Amstrad's E3.  In particular,
the Linux kernel used on the E3, as announced in a joint
Amstrad/MontaVista press release, is covered by the GNU General Public
License, GPL, version 2.

    http://www.amstrad.com/news_linux.html

Perhaps understandably, given their role in supporting owners of an E3,
Support are reluctant to discuss the license compliance further unless I
can provide a serial number, etc., which, given I've not purchased an
E3, I don't have.  Consequently, I'm writing to you in the hope of
straightening out any license infringement, or correcting my
understanding.  Let me make clear, I'm delighted Amstrad have used Linux
on the E3 and wish nothing more than to see Linux's license complied
with allowing me to obtain the GPL'd source code under the terms of the
license -- I have no wish to damage Amstrad's reputation in any way.
I'm hoping you can forward my concerns onto the relevant party inside
Amstrad.

The GNU GPL version 2 aims to ensure that recipients of a GPL'd program
in object code or executable form, e.g. E3 purchaser, can obtain the
exact same source code that created the binary files.  The whole license
is available at

    http://www.gnu.org/copyleft/gpl.html

I think the core issue is that Amstrad received the Linux kernel
licensed under the GPL and must therefore follow its conditions in their
distribution of Linux, as stored in the E3.

I believe section 3 of the GPL is the relevant part.  It starts

    3.  You may copy and distribute the Program (or a work based on it,
    under Section 2) in object code or executable form under the terms
    of Sections 1 and 2 above provided that you also do one of the
    following:

and the E3 contains a work based on Linux in executable form.

The three choices allowed are

        a) Accompany it with the complete corresponding machine-readable
        source code, which must be distributed under the terms of
        Sections 1 and 2 above on a medium customarily used for software
        interchange; or,

        b) Accompany it with a written offer, valid for at least three
        years, to give any third party, for a charge no more than your
        cost of physically performing source distribution, a complete
        machine-readable copy of the corresponding source code, to be
        distributed under the terms of Sections 1 and 2 above on a
        medium customarily used for software interchange; or,

        c) Accompany it with the information you received as to the
        offer to distribute corresponding source code. (This alternative
        is allowed only for noncommercial distribution and only if you
        received the program in object code or executable form with such
        an offer, in accord with Subsection b above.)

Complying with (a) would mean the source code is in the box, probably on
a CD, alongside the E3.

(b) would mean there's a written offer in the E3's box to give *any
third party*, not just an E3 purchaser, i.e. me, the source code at
cost.

I don't believe (c) is available to Amstrad since the E3 is a commercial
distribution and I doubt Amstrad received Linux in non-source form from
MontaVista.

Visiting my local Dixons today, and with the help of an assistant who
let me go through a new E3 box, I have the serial number if that's of
help, I found no source code (a), and no written offer (b).  Just a
"This product contains software that is subject to licence terms."
inside the manual's front cover.  Thus I believe Amstrad are violating
the terms of Linux's license in not doing one of 3(a), 3(b), or 3(c).

This is the most apparent violation but I am not a lawyer and I've no
doubt that Amstrad had lawyers and assistance from MontaVista in looking
over the GPL before shipping the E3.  If I'm wrong I'd like to know
Amstrad's interpretation of the license and how they comply and they may
wish to publicise their compliance in order that others don't follow me
in asking.

Otherwise, if Amstrad are violating the GPL then, under section 4, their
rights to distribute the program are terminated, i.e. distributing the
E3 is copyright infringement.

    4.  You may not copy, modify, sublicense, or distribute the Program
    except as expressly provided under this License. Any attempt
    otherwise to copy, modify, sublicense or distribute the Program is
    void, and will automatically terminate your rights under this
    License. However, parties who have received copies, or rights, from
    you under this License will not have their licenses terminated so
    long as such parties remain in full compliance.

I have further minor issues with GPL compliance but section 3 is the
main one.  Others include

    The manual stating "Software (C) Amstrad plc.  1999-2004.  All
    rights reserved.";  clearly some of the software's copyright doesn't
    reside with Amstrad but with Linux's copyright holders.

    Page 155 states

        "You must not copy, de-compile, modify, change, sell, lend,
        sub-license or by other means interfere with or exploit the
        software of the e-m@iler.  Nor must you change the
        factory-installed software in the e-m@iler, except where such
        change is an upgrade or modification version released by
        Amserve."

    but section 3 allows me to copy and distribute the GPL'd binaries I
    received in the E3 as long as I comply with 3(c), i.e. don't charge
    for distribution and accompany it with the written offer I (didn't)
    receive with the E3.  Attempting to restrict my right to do this
    violates GPL section 6.

        6. Each time you redistribute the Program (or any work based on
        the Program), the recipient automatically receives a license
        from the original licensor to copy, distribute or modify the
        Program subject to these terms and conditions. You may not
        impose any further restrictions on the recipients' exercise of
        the rights granted herein. You are not responsible for enforcing
        compliance by third parties to this License.

I suspect these arise from taking the Emailer Plus manual and altering
it for the E3 without considering GPL compliance.

One further tricky point to consider is section 3 clarifies

    The source code for a work means the preferred form of the work for
    making modifications to it. For an executable work, complete source
    code means all the source code for all modules it contains, plus any
    associated interface definition files, plus the scripts used to
    control compilation and installation of the executable.

This means that each time Amstrad alter and distribute the GPL'd
software on the E3, e.g. an improvement to Linux to support wireless LAN
downloaded to the E3 overnight, they must make available the matching
source code, build, and installation scripts.

I'd like to know if Amstrad agree that they're violating the GPL and
what they intend to change to try and follow the spirit of the GPL
despite having already shipped E3s.  As I'm not a copyright holder of
any part of the Linux kernel I obviously have no right to condone any
changes.  I'm merely trying to obtain the source code and see the
license complied with for the good of all Linux licensees, including
Amstrad.

Below are my recent emails with Support.

Thanks,


Ralph Corderoy.


- ------- =_aaaaaaaaaa0
Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1"
Content-ID: <4142.1096322842.2@blake.inputplus.co.uk>

- ------- =_aaaaaaaaaa1
Content-Type: message/rfc822

[Snip duplicate of message 1-6.]

- ------- =_aaaaaaaaaa1--

- ------- =_aaaaaaaaaa0--

------- Message 8

Return-Path: brian.eaton@amstrad.com
Delivery-Date: Tue Sep 28 11:13:00 2004
Return-Path: <brian.eaton@amstrad.com>
Received: from localhost (localhost [127.0.0.1])
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8SACxh12987
	for <ralph@localhost>; Tue, 28 Sep 2004 11:13:00 +0100
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from inputplus.co.uk [66.39.34.92]
	by localhost with POP3 (fetchmail-5.9.0)
	for ralph@localhost (single-drop); Tue, 28 Sep 2004 11:13:00 +0100 (BST)
Received: (qmail 98079 invoked from network); 28 Sep 2004 09:50:33 -0000
Received: from mail.amstrad.co.uk (HELO mrs.amstrad.co.uk) (193.133.25.43)
  by ruis.pair.com with SMTP; 28 Sep 2004 09:50:33 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Received: from mailserver2.amstrad.co.uk ([192.9.200.8]) by mrs.amstrad.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 10:50:32 +0100
Received: by MAILSERVER2 with Internet Mail Service (5.5.2653.19) id <SST6DRVG>; Tue, 28 Sep 2004 10:50:32 +0100
Message-ID: <EC49BB70F1DDD6118C620002B3512AD50329D2EF@MAILSERVER2>
From: Brian Eaton <brian.eaton@amstrad.com>
To: "'ralph@inputplus.co.uk'" <ralph@inputplus.co.uk>
CC: Amserve Support <support@amserve.ltd.uk>
Subject: RE: Possible GNU GPL License Violation by Amstrad E3.
Date: Tue, 28 Sep 2004 10:50:22 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 28 Sep 2004 09:50:32.0312 (UTC) FILETIME=[9831FF80:01C4A540]
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
X-Spam-Status: No, hits=-1.5 required=4.0 tests=MISSING_OUTLOOK_NAME,BAYES_01
X-Spam-Flag: NO
X-Spam-Level: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by blake.inputplus.co.uk id i8SACxh12987

Dear Mr Corderoy

I refer to the email of 27 Sept that you sent to Sir Alan Sugar. Sir Alan
has asked me to respond.

Please note the following:

We have an obligation to our customers (the recipients of the object code)
to make the source code of the kernel (not the whole of our code) available
to them. You, with respect, are not a customer. Our customer services -
after asking for proof of purchase and registration - will point customers
to a web address where the kernel can be found.

Our position is that
1) You are not one of our customers. We only have obligations to our
customers (the recipients). We do have an obligation to the copyright owners
of Linux, but with respect you are not one of them either.
2) We have told everyone clearly that we are working with MontaVista and
using their Linux.

Yours sincerely

Brian Eaton
E-Business Director
Amstrad Plc 




This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries.

For further information on Amstrad Plc please visit our website: www.amstrad.com

Amstrad Plc.
Brentwood House
169 Kings Road
Brentwood
Essex CM14 4EF
Registered in England : No. 955321



------- Message 9

Return-Path: ralph@inputplus.co.uk
Delivery-Date: Tue Sep 28 16:06:37 2004
Return-Path: <ralph@inputplus.co.uk>
Received: from blake.inputplus.co.uk (ralph@localhost)
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8SF6bG17264;
	Tue, 28 Sep 2004 16:06:37 +0100
Message-Id: <200409281506.i8SF6bG17264@blake.inputplus.co.uk>
To: Brian Eaton <brian.eaton@amstrad.com>
cc: Amserve Support <support@amserve.ltd.uk>
Subject: Re: Possible GNU GPL License Violation by Amstrad E3. 
In-Reply-To: Message from Brian Eaton <brian.eaton@amstrad.com> 
   of "Tue, 28 Sep 2004 10:50:22 BST." <EC49BB70F1DDD6118C620002B3512AD50329D2EF@MAILSERVER2> 
Date: Tue, 28 Sep 2004 16:06:37 +0100
From: Ralph Corderoy <ralph@inputplus.co.uk>


Dear Mr. Eaton,

> I refer to the email of 27 Sept that you sent to Sir Alan Sugar. Sir
> Alan has asked me to respond.

Thank you.

> Please note the following:
> 
> We have an obligation to our customers (the recipients of the object
> code) to make the source code of the kernel (not the whole of our
> code) available to them.

You have an obligation under the GNU GPL to supply your customers, who
are the E3 purchasers and initial recipients of the GPL'd object code,
with either the source code alongside the E3 (3a), or a written offer to
any third party to supply the source code (3b).  From inspection of the
E3's box's contents I believe you're doing neither and hence are in
violation of the GPL.

There is no disagreement that not all of the software on the E3 is
licensed under the GPL.

> You, with respect, are not a customer. Our customer services - after
> asking for proof of purchase and registration - will point customers
> to a web address where the kernel can be found.

No, I'm not a customer.  I'm just someone who's contributing my own free
time to try and help Amstrad comply with the license without it all
snowballing into a situation like the Welte v. Sitecom De*tschland GmbH
case in the Munchen District Court where an injunction on Sitecom was
upheld.

You seem to feel that supplying E3 owners, on proof of purchase, with a
web address where the source can be found meets your obligations under
the GPL.  It doesn't.  You seem to be going for 3(b) of the GPL where
source is made available separately from the object code.  But an
important part of the GPL is that recipients of GPL'd code know it is
GPL'd and what their rights are.  Hence 3(b)'s `written offer' which
informs the E3 owner of their rights and which owners of the E3 can pass
on when copying the E3's GPL'd object code to anyone they wish under
3(c).

Someone who receives the E3's GPL'd binaries along with Amstrad's
written offer, either by purchasing an E3, or by being passed both by
someone who already has them, can take up Amstrad's offer of supplying
the source code *to any third party* despite not owning an E3 or having
its serial number.

Anyone who has the GPL'd source code from Amstrad can, under section 1
of the GPL, make it available, e.g. on the Internet, to all and sundry.
Given this, Amstrad's attempt to seemingly keep it to E3 owners only, or
track distribution by serial number, seems mis-guided.

> Our position is that 1) You are not one of our customers. We only have
> obligations to our customers (the recipients). We do have an
> obligation to the copyright owners of Linux, but with respect you are
> not one of them either.

Despite not being a customer, or a copyright holder, I believe that
Amstrad are failing to comply with the GPL.  If Amstrad continue to fail
to answer the specific points I've made I will take the matter to the
Linux kernel copyright holders by posting the issue on the public Linux
Kernel Mailing List, linux-kernel@vger.kernel.org.

> 2) We have told everyone clearly that we are working with MontaVista
> and using their Linux.

I am surprised MontaVista have not advised Amstrad more precisely over
their obligations.  You may wish to consult them again.

Thanks,


Ralph Corderoy.

------- Message 10

Return-Path: brian.eaton@amstrad.com
Delivery-Date: Tue Sep 28 17:13:43 2004
Return-Path: <brian.eaton@amstrad.com>
Received: from localhost (localhost [127.0.0.1])
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8SGDgh19211
	for <ralph@localhost>; Tue, 28 Sep 2004 17:13:43 +0100
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from inputplus.co.uk [66.39.34.92]
	by localhost with POP3 (fetchmail-5.9.0)
	for ralph@localhost (single-drop); Tue, 28 Sep 2004 17:13:43 +0100 (BST)
Received: (qmail 31142 invoked from network); 28 Sep 2004 16:10:10 -0000
Received: from mail.amstrad.co.uk (HELO mrs.amstrad.co.uk) (193.133.25.43)
  by ruis.pair.com with SMTP; 28 Sep 2004 16:10:10 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Received: from mailserver2.amstrad.co.uk ([192.9.200.8]) by mrs.amstrad.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Sep 2004 17:10:09 +0100
Received: by MAILSERVER2 with Internet Mail Service (5.5.2653.19) id <SST6DT0L>; Tue, 28 Sep 2004 17:10:09 +0100
Message-ID: <EC49BB70F1DDD6118C620002B3512AD50329D2F6@MAILSERVER2>
From: Brian Eaton <brian.eaton@amstrad.com>
To: "'Ralph Corderoy'" <ralph@inputplus.co.uk>
Subject: RE: Possible GNU GPL License Violation by Amstrad E3. 
Date: Tue, 28 Sep 2004 17:10:08 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 28 Sep 2004 16:10:09.0971 (UTC) FILETIME=[A0BCF030:01C4A575]
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
X-Spam-Status: No, hits=-4.9 required=4.0 tests=MISSING_OUTLOOK_NAME,BAYES_00
X-Spam-Flag: NO
X-Spam-Level: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by blake.inputplus.co.uk id i8SGDgh19211

Dear Mr Corderoy
Your comments are noted. We will get back to you shortly. In the meantime
can you let me have your postal address please so that I can send you
something?
Yours sincerely
Brian Eaton
E-Business Director
Amstrad Plc 


- -----Original Message-----

[Snip duplicate of message 9.]


This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries.

For further information on Amstrad Plc please visit our website: www.amstrad.com

Amstrad Plc.
Brentwood House
169 Kings Road
Brentwood
Essex CM14 4EF
Registered in England : No. 955321



------- Message 11

Return-Path: brian.eaton@amstrad.com
Delivery-Date: Wed Sep 29 12:48:50 2004
Return-Path: <brian.eaton@amstrad.com>
Received: from localhost (localhost [127.0.0.1])
	by blake.inputplus.co.uk (8.11.6/8.11.6) with ESMTP id i8TBmmW09654
	for <ralph@localhost>; Wed, 29 Sep 2004 12:48:50 +0100
Delivered-To: inputplu-inputplus:co:uk-ralph@inputplus.co.uk
X-Envelope-To: ralph@inputplus.co.uk
Received: from inputplus.co.uk [66.39.34.92]
	by localhost with POP3 (fetchmail-5.9.0)
	for ralph@localhost (single-drop); Wed, 29 Sep 2004 12:48:50 +0100 (BST)
Received: (qmail 18673 invoked from network); 29 Sep 2004 11:46:24 -0000
Received: from mail.amstrad.co.uk (HELO mrs.amstrad.co.uk) (193.133.25.43)
  by ruis.pair.com with SMTP; 29 Sep 2004 11:46:24 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Received: from mailserver2.amstrad.co.uk ([192.9.200.8]) by mrs.amstrad.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Sep 2004 12:46:22 +0100
Received: by MAILSERVER2 with Internet Mail Service (5.5.2653.19) id <SST6DZBZ>; Wed, 29 Sep 2004 12:46:23 +0100
Message-ID: <EC49BB70F1DDD6118C620002B3512AD50329D301@MAILSERVER2>
From: Brian Eaton <brian.eaton@amstrad.com>
To: "'Ralph Corderoy'" <ralph@inputplus.co.uk>
CC: Amserve Support <support@amserve.ltd.uk>
Subject: RE: Possible GNU GPL License Violation by Amstrad E3. 
Date: Wed, 29 Sep 2004 12:46:22 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 29 Sep 2004 11:46:22.0618 (UTC) FILETIME=[F15047A0:01C4A619]
X-Spam-Filtered: 52d0813afd638bc4ffa68db06ca49a29
X-Spam-Status: No, hits=-3.4 required=4.0 tests=MISSING_OUTLOOK_NAME,NO_OBLIGATION,BAYES_00
X-Spam-Flag: NO
X-Spam-Level: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by blake.inputplus.co.uk id i8TBmmW09654

Dear Mr Corderoy

Any customer who buys one of our videophones will see that our
obligations under the GPL are met and clearly explained to them. If you
were to become a customer it would be clear to you. In the meantime we have
no
obligation to explain to non-customers our policy.

Brian Eaton
E-Business Director
Amstrad Plc 


- -----Original Message-----

[Snip duplicate of message 9.]


This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries.

For further information on Amstrad Plc please visit our website: www.amstrad.com

Amstrad Plc.
Brentwood House
169 Kings Road
Brentwood
Essex CM14 4EF
Registered in England : No. 955321



------- End of Forwarded Messages

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Denis Vlasenko]

On Wednesday 29 September 2004 16:44, Ralph Corderoy wrote:
[snip]

> All my correspondence is attached but the most interesting is message 9
> where I spell out the license requirements to Brian Eaton, 10 where he
> yesterday asked for my address, and 11 where he re-stated they've don't
> have to discuss it with me.  I think they're failing to comply with
> section 3.  There's other minor things too in the manual that I've
> highlighted.  They're right in saying they've no obligation to discuss
> their compliance with me.  I'm hoping that by posting here a copyright
> holder will query their apparent lack of compliance and Amstrad will be
> happy to converse with them.
> 
> To re-iterate, there's no source code or written offer in the box.  They
> say they'll provide a URL to an E3 owner on proof of ownership but
> that's insufficient.  The situation is made more complex by the E3
> downloading software updates, including seemingly the kernel, so they'll
> be multiple versions to provide source for over time.

You did an awesome work. I will save this message as an example
just in case I will need to do something similar.

Unfortunately I have no E3. Hope someone who has will contact you.
--
vda

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Alan Cox]

On Gwe, 2004-10-01 at 15:52, Denis Vlasenko wrote:
> You did an awesome work. I will save this message as an example
> just in case I will need to do something similar.
> 
> Unfortunately I have no E3. Hope someone who has will contact you.

Actually by the time this made the kernel list an answer turned up from
Amstrad - the URL for the GPL source, and an offer valid for three years
to supply it at cost is in the welcome email their units start up with.

Alan

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Ralph Corderoy]

Hi Alan,

Alan Cox wrote:
> Actually by the time this made the kernel list an answer turned up
> from Amstrad - the URL for the GPL source, and an offer valid for
> three years to supply it at cost is in the welcome email their units
> start up with.

dwmw2 is reporting off-list that the URL is "for the [MontaVista] devkit
they started from".

And the written offer is in the welcome email *now* but probably wasn't
until I hassled them.  It also doesn't meet 3(b) so they're not
complying.  The way the E3 works is that it won't do anything after
power on until you plug it into your phone line.  Then it dials Amstrad
(Amsurf), asks you questions, e.g. name, and registers this along with
your phone number, serial number, and preferred email address with
Amstrad.

*After that* you get a `welcome email' containing the written offer.
Sorry, but I have the binaries once I walk out the shop.  Where's my
written offer?  What do I do if I bought one and got it shipped to
France and so it won't `phone home'?

Cheers,


Ralph.

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Alan Cox]

On Gwe, 2004-10-01 at 16:59, Ralph Corderoy wrote:
> And the written offer is in the welcome email *now* but probably wasn't
> until I hassled them. 

Well fine, you can't magically fix mistakes in documentation. You'd also
I think find the law took the same view. 

> *After that* you get a `welcome email' containing the written offer.
> Sorry, but I have the binaries once I walk out the shop.  Where's my
> written offer?  What do I do if I bought one and got it shipped to
> France and so it won't `phone home'?

You know I regularly hear people talking about the "spirit of the
license", but that goes in both directions. From discussions my own
impression is that in this case they may or may not have forgotten to
put it in the manual but they've done their best to be compliant and
they have no desire not to be compliant.

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Jon Masters]

On Fri, 01 Oct 2004 16:59:41 +0100, Ralph Corderoy
<ralph@inputplus.co.uk> wrote:

> Alan Cox wrote:
> > Actually by the time this made the kernel list an answer turned up
> > from Amstrad - the URL for the GPL source, and an offer valid for
> > three years to supply it at cost is in the welcome email their units
> > start up with.

The E3 uses Montavista Linux and as far as I am aware they made little
or no changes to that for the product. Most of the perceived problem
here is, I think, just misunderstanding.

It also seems you're overly keen for Amstrad to be in the wrong here,
but the reality is that Alan Sugar (or his son/relative in charge of
various PR activities) is not going to have these answers readily
available for you. Someone will know and provide you with the
information that you are after - but it's worth treating the lack of
informtation as a small oversight.

While the E3 is quoted as not using any other "Open Source" software,
it does use Monta's Linux. I would suggest that you contact the folks
at Montavista's UK offices in Bracknell and ask them about obtaining a
link to the source.mvista.com and similar websites where you can
obtain a copy of the sources used in their distribution. They are
friendly people.

> And the written offer is in the welcome email *now* but probably wasn't
> until I hassled them.

They probably overlooked it. Yes that's not great - but I wouldn't get
too worked up over it. The reality is that you asked for a copy of the
source and eventually it seems that you will get what you want. It
would be nice if this process were entirely seemless but it's
certainly a lot better than many examples I've seen elsewhere.

> It also doesn't meet 3(b) so they're not complying.

Technically I think you might be correct there - but I'd give them the
benefit of the doubt and assume they just need to read the license
over and make a change to some packaging.

I'm planning to do a review of the E3 so I'll be sure to look in to
these issues then.

Cheers,

Jon.

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Alan Cox]

On Gwe, 2004-10-01 at 17:24, Jon Masters wrote:
> I'm planning to do a review of the E3 so I'll be sure to look in to
> these issues then.

Everything I've seen from Amstrad on the subject has ben friendly,
helpful and clear. I've dealt with a few cases of vendors clearly
trying to break the rules, but Amstrad is not one of them. They answer
email, they give clear and honest answers, and the code is out there.

If anyone has a copy of the emailer source btw (or gets one for review
so has a download option ;)) then it would be nice to stick it up for
ftp for all.

Alan

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Jon Masters]

On Fri, 01 Oct 2004 16:59:44 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Gwe, 2004-10-01 at 17:24, Jon Masters wrote:
> > I'm planning to do a review of the E3 so I'll be sure to look in to
> > these issues then.
> 
> Everything I've seen from Amstrad on the subject has ben friendly,
> helpful and clear. I've dealt with a few cases of vendors clearly
> trying to break the rules, but Amstrad is not one of them. They answer
> email, they give clear and honest answers, and the code is out there.

I don't think they're evil either. Hassling vendors can do more harm
than good, let's not do that.

> If anyone has a copy of the emailer source btw (or gets one for review
> so has a download option ;)) then it would be nice to stick it up for
> ftp for all.

I'll be talking to Monta about doing a review of the E3. I'll look in
to getting hold of the source at that point.

Jon.

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Jonathan McDowell]

On Fri, Oct 01, 2004 at 04:59:44PM +0100, Alan Cox wrote:
> On Gwe, 2004-10-01 at 17:24, Jon Masters wrote:
> > I'm planning to do a review of the E3 so I'll be sure to look in to
> > these issues then.
> Everything I've seen from Amstrad on the subject has ben friendly,
> helpful and clear. I've dealt with a few cases of vendors clearly
> trying to break the rules, but Amstrad is not one of them. They answer
> email, they give clear and honest answers, and the code is out there.
> 
> If anyone has a copy of the emailer source btw (or gets one for review
> so has a download option ;)) then it would be nice to stick it up for
> ftp for all.

No one seems to have done this, and the offer Amstrad makes requires the
sending off of £25 to them to cover admin and distribution costs rather
than allowing a download of it. I did this a few days ago so will
hopefully hear from them in the next week or so.

J.

-- 
  "f u cn rd ths, u cn gt a gd jb  |  .''`.  Debian GNU/Linux Developer
    n cmptr prgrmmng." -- Simon    | : :' :  Happy to accept PGP signed
        Cozens, ox.os.linux        | `. `'   or encrypted mail - RSA +
                                   |   `-    DSA keys on the keyservers.

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Jonathan McDowell]

On Fri, Jan 07, 2005 at 09:48:52PM +0000, Jonathan McDowell wrote:
> On Fri, Oct 01, 2004 at 04:59:44PM +0100, Alan Cox wrote:
> > If anyone has a copy of the emailer source btw (or gets one for review
> > so has a download option ;)) then it would be nice to stick it up for
> > ftp for all.
> No one seems to have done this, and the offer Amstrad makes requires the
> sending off of £25 to them to cover admin and distribution costs rather
> than allowing a download of it. I did this a few days ago so will
> hopefully hear from them in the next week or so.

I've now received this and it's linked from:

http://www.earth.li/~noodles/hardware-e3.html

Interesting (to me at least) points:

* Camera source included and seems to present as a standard v4l device.
* The keyboard driver is a module (not included) - there's a stub
  present presumably so basic init works.
* The Pegasus USB networking module is compiled in; I've confirmed it
  initialises such a device, but see no network traffic (CONFIG_IP_PNP
  and friends are enabled in the .config provided, but I guess this may
  be from a debug tree?)
* There's Belkin USB serial device support in the .config as well, but I
  can't see any output when I hook up such a device.

I've setup a list at:

http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking

for anyone who wants to discuss the hardware/software of the device.

What I'd really like to see is a dump of the flash from the device, in
the hope that the startup scripts might do something with the ethernet.
However I don't have the appropriate kit to be able to do this.
Alternatively it looks like there's a serial console on ttyS0 (UART1 on
the OMAP?), but I can't see any obvious pads where that's brought out
to.

(Oh, and as a semi related aside; if anyone has GPL contacts in Linksys
I'd be most interested to know about them - I'm completely failing to
get hold of kernel source for the WMA11B, which runs 2.4.17-rmk3-cot1.)

J.

-- 
"I can see an opening for the four lusers of the Apocalypse... 'I
didn't change anything', 'My e-mail doesn't work', 'I can't print' and
'Is the network broken?'." -- Paul Mc Auley, asr

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Jonathan McDowell]

On Sat, Jan 15, 2005 at 01:43:10PM +0000, Jonathan McDowell wrote:
> On Fri, Jan 07, 2005 at 09:48:52PM +0000, Jonathan McDowell wrote:
> > On Fri, Oct 01, 2004 at 04:59:44PM +0100, Alan Cox wrote:
> > > If anyone has a copy of the emailer source btw (or gets one for review
> > > so has a download option ;)) then it would be nice to stick it up for
> > > ftp for all.
> > No one seems to have done this, and the offer Amstrad makes requires the
> > sending off of £25 to them to cover admin and distribution costs rather
> > than allowing a download of it. I did this a few days ago so will
> > hopefully hear from them in the next week or so.
> I've now received this.

Which turns out not to actually be what they're using; what I have
source for is "2.4.18_mvl30-E3" whereas my E3 has
"2.4.18_mvl30-ams-delta". Also there's no sign of a dfdblk/MFS-DFD
driver in the provided source, but the dmesg output of the E3 clearly
shows such a driver initialising before any filesystem is mounted,
ruling out the possiblity of it being a module.

I contacted Amstrad about this over a week ago, but to date haven't had
a response.

J.

-- 
9 out of 10 men who tried Camels prefer women.

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[Tigran Aivazian]

On Fri, 1 Oct 2004, Ralph Corderoy wrote:
> *After that* you get a `welcome email' containing the written offer.
> Sorry, but I have the binaries once I walk out the shop.  Where's my
> written offer?  What do I do if I bought one and got it shipped to
> France and so it won't `phone home'?

Greetings Ralph,

I think that the "research" you have been doing was a clear waste of time
of people at Amstrad who were, as it turns out, not even breaking any 
laws.

Alan Cox has cleared up everything, and so your best option, I think, is
to kindly apologize to Amstrad for wasting their time and not continue
with your irritating "what if this" and "what if that"s, unless you are a 
lawyer and therefore delight in the waste of time of this sort (or even 
paid to do that).

Having said that, I also saved your first email in the "useful" folder --- 
as a classical example of what to expect from someone with little clue but 
much "zeal" for the enforcement of GPL putting his nose in every hole he 
can find :)

Kind regards
Tigran

Re: Possible GPL Violation of Linux in Amstrad's E3 Videophone.

[James Courtier-Dutton]

Alan Cox wrote:
> On Gwe, 2004-10-01 at 15:52, Denis Vlasenko wrote:
> 
>>You did an awesome work. I will save this message as an example
>>just in case I will need to do something similar.
>>
>>Unfortunately I have no E3. Hope someone who has will contact you.
> 
> 
> Actually by the time this made the kernel list an answer turned up from
> Amstrad - the URL for the GPL source, and an offer valid for three years
> to supply it at cost is in the welcome email their units start up with.
> 
> Alan
> 

And the URL is?

Re: [Lse-tech] Re: 10.31 second kernel compile

[Andi Kleen]

yodaiken@fsmlabs.com writes:

> is there a 64 bit machine with hardware search of pagetables? Even ibm
> only has a hardware search of hash tables - which we agree are simply
> a means of making your hardware TLB larger and slower.

x86-64 aka AMD Hammer does hardware (or more likely microcode) search of 
page tables.
It has a 4 level page table with 4K pages. Generic Linux MM code only sees
the first slot in 4th level page limit user space to 512GB with 3 levels. 
Direct mappings and kernel mappings are handled specially by architecture 
specific code outside that first slot.

The CPU itself has I/D TLBs split into L1 and L2.

-Andi

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sat, Mar 16, 2002 at 08:32:26PM +0100, Andi Kleen wrote:
> x86-64 aka AMD Hammer does hardware (or more likely microcode) search of 
> page tables.
> It has a 4 level page table with 4K pages. Generic Linux MM code only sees
> the first slot in 4th level page limit user space to 512GB with 3 levels. 

What about 2M pages?

> Direct mappings and kernel mappings are handled specially by architecture 
> specific code outside that first slot.
> 
> The CPU itself has I/D TLBs split into L1 and L2.

There was something in some AMD doc about preventing tlbflush on process
switch - through a context like thing perhaps? Any idea?


> 
> -Andi

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Andi Kleen]

On Sat, Mar 16, 2002 at 12:57:11PM -0700, yodaiken@fsmlabs.com wrote:
> On Sat, Mar 16, 2002 at 08:32:26PM +0100, Andi Kleen wrote:
> > x86-64 aka AMD Hammer does hardware (or more likely microcode) search of 
> > page tables.
> > It has a 4 level page table with 4K pages. Generic Linux MM code only sees
> > the first slot in 4th level page limit user space to 512GB with 3 levels. 
> 
> What about 2M pages?

They are not supported for user space, but used in private mappings
for kernel text and direct memory mappings. Generic code never sees them.

That will hopefully change eventually because 2M pages are a bit help for
a lot of applications that are limited by TLB thrashing, but needs some 
thinking on how to avoid the fragmentation trap (e.g. I'm considering
to add a highmem zone again just for that and use rmap with targetted
physical freeing to allocating them) 

> 
> > Direct mappings and kernel mappings are handled specially by architecture 
> > specific code outside that first slot.
> > 
> > The CPU itself has I/D TLBs split into L1 and L2.
> 
> There was something in some AMD doc about preventing tlbflush on process
> switch - through a context like thing perhaps? Any idea?

There are global pages which are normally not flushed over context switch.
That is used for all kernel mappings. 

There is also some optimization in the CPU that tries to do a selective
flush only when you reload CR3, but as far as I can see doesn't help
for the Linux context switch. It only works around broken TLB flushing
algorithms in some Windows version.

-Andi

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> On Sat, Mar 16, 2002 at 12:57:11PM -0700, yodaiken@fsmlabs.com wrote:
> > On Sat, Mar 16, 2002 at 08:32:26PM +0100, Andi Kleen wrote:
> > > x86-64 aka AMD Hammer does hardware (or more likely microcode) search of 
> > > page tables.
> > > It has a 4 level page table with 4K pages. Generic Linux MM code only sees
> > > the first slot in 4th level page limit user space to 512GB with 3 levels. 
> > 
> > What about 2M pages?
> 
> They are not supported for user space, but used in private mappings
> for kernel text and direct memory mappings. Generic code never sees them.
> 
> That will hopefully change eventually because 2M pages are a bit help for
> a lot of applications that are limited by TLB thrashing, but needs some 
> thinking on how to avoid the fragmentation trap (e.g. I'm considering
> to add a highmem zone again just for that and use rmap with targetted
> physical freeing to allocating them) 

To me, once you have a G of memory, wasting a few meg on unused process 
memory seems no big deal.

> > There was something in some AMD doc about preventing tlbflush on process
> > switch - through a context like thing perhaps? Any idea?
> 
> There are global pages which are normally not flushed over context switch.
> That is used for all kernel mappings. 
> 
> There is also some optimization in the CPU that tries to do a selective
> flush only when you reload CR3, but as far as I can see doesn't help
> for the Linux context switch. It only works around broken TLB flushing
> algorithms in some Windows version.

They say:
	Hammer microarchitecture features a flush filter allowing multiple
	processes to share TLB without SW intervention.

Not a lot of technical detail in that.

> 
> -Andi

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:
> 
> To me, once you have a G of memory, wasting a few meg on unused process 
> memory seems no big deal.

It's not the process memory, and it is a whole lot than a "few meg" if 
your page size is 2M.

Look at "free" output one day, and notice that "cached" line? On my 2G 
machine, I usually have about a gig cached or so. Guess what the most 
common thing in that case is? Yeah, the kernel. 

And my kernel tree (with bk overhead etc) is right not about 25.000 files. 
That's without object files etc. At 2M a pop in the page cache, that's a 
whole lot more memory for caching than I have in my machine.

Ok, so assume you compress that, and you only actually use the full 2M 
when mapping into user space, you now added a lot of complexity, but at 
least you make the ridiculous memory use go down. 

But even in the process space, I've got about 150 processes quite 
normally, and while most of them are idle, if we had 2M pages most of them 
would waste at least 2M of memory (probably more - the stack doesn't even 
need half a page, and the data section would probably waste half a page on 
average).

That's 300M just wasted.

Tell me that's peanuts even if you've got a few gigs of ram on your 
machine. 

Admit it, you're just wrong. 2M page sizes are _not_ useful for the common
case, and won't be for years to come.

In short, youäre 

> They say:
> 	Hammer microarchitecture features a flush filter allowing multiple
> 	processes to share TLB without SW intervention.
> 
> Not a lot of technical detail in that.

I suspect it's some special case for windows with a special MSR that 
enables something illegal that just works well for whatever patterns 
windows does.

		Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sat, Mar 16, 2002 at 12:34:29PM -0800, Linus Torvalds wrote:
> 
> On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:
> > 
> > To me, once you have a G of memory, wasting a few meg on unused process 
> > memory seems no big deal.
> 
> It's not the process memory, and it is a whole lot than a "few meg" if 
> your page size is 2M.

I forget what an extremist you are. My claim is that
some processes benefit from big pages, some do not.
A 16G process needs 2^25 bytes of PTE at 4kbytes/page if I
did the numbers right. Just populating 4 million odd  page tables is a 
pain. I might be wrong about it, but I wonder if just scaling
up from a working 32 bit strategy gets you anywhere.
If you want to optimize for gnome, you get a very different
layout. But Hammer and ia64 are supposedly designed for huge
databases, routing tables, and images. Our good friends at Intel
claim "carrier grade" Linux  needs to run threaded apps
with 10,000 threads to depose Solaris in telecom - all sharing the
same monster address space. 

> Admit it, you're just wrong. 2M page sizes are _not_ useful for the common
> case, and won't be for years to come.

What's the "common case" for 64 bit ? Do you really think it will
be on desktop soon?

> 
> In short, youäre 

Don't use umlauts unless you are ready to back it up.


> 
> > They say:
> > 	Hammer microarchitecture features a flush filter allowing multiple
> > 	processes to share TLB without SW intervention.
> > 
> > Not a lot of technical detail in that.
> 
> I suspect it's some special case for windows with a special MSR that 
> enables something illegal that just works well for whatever patterns 
> windows does.

sounds like it from what Andi wrote. disappointing.

> 
> 		Linus

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:
>
> If you want to optimize for gnome, you get a very different
> layout. But Hammer and ia64 are supposedly designed for huge
> databases, routing tables, and images.

Yeah, and I'm claiming that databases etc count for a whole lot less than
most other apps.

> What's the "common case" for 64 bit ? Do you really think it will
> be on desktop soon?

Oh, not Itanium for sure. But if AMD succeeds even reasonably with Hammer,
Intel will certainly see the error of its ways (except they won't admit
it) and make their version of a 64-bit P4 core available. They're
reportedly working on it already, just in case the Itanic sinks (and
judging by current market behaviour it certainly isn't flying).

> > In short, youäre
>
> Don't use umlauts unless you are ready to back it up.

That's not an umlaut, that's an "ä", which is a real letter in Finnish and
Swedish (it just _looks_ like an a with an umlaut to you uncultured
people), and it happens to be a letter that is just left of the ' mark on
a Finnish keyboard.

		Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 16.03.02 in <Pine.LNX.4.33.0203161342190.24457-100000@home.transmeta.com>:

> On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:

> > > In short, youaere
> >
> > Don't use umlauts unless you are ready to back it up.
>
> That's not an umlaut, that's an "ae", which is a real letter in Finnish and
> Swedish (it just _looks_ like an a with an umlaut to you uncultured
> people), and it happens to be a letter that is just left of the ' mark on
> a Finnish keyboard.

Hey, careful there! Those English speakers stole that name from German,  
and in German those umlauts are real letters, too. Incidentally, my ae is  
next to the '# key ...

MfG Kai

Re: [Lse-tech] Re: 10.31 second kernel compile

[Alan Cox]

> > That's not an umlaut, that's an "ae", which is a real letter in Finnish and
> > Swedish (it just _looks_ like an a with an umlaut to you uncultured
> > people), and it happens to be a letter that is just left of the ' mark on
> > a Finnish keyboard.
> 
> Hey, careful there! Those English speakers stole that name from German,  
> and in German those umlauts are real letters, too. Incidentally, my ae is  
> next to the '# key ...

There are still a couple of places you can legitimaely use an ae symbol in
English. It's not quite dead yet 8)

2.4.19-pre3-ac1 - Quotactl patch

[Shawn Starr]

You might want to upgrade to the newer one, the patch has undergone a lot
of changes and -ac against the XFS merge of the quotactl patch seriously
breaks ;-(

Shawn.

Re: 2.4.19-pre3-ac1 - Quotactl patch

[Alan Cox]

> You might want to upgrade to the newer one, the patch has undergone a lot
> of changes and -ac against the XFS merge of the quotactl patch seriously
> breaks ;-(

The -ac patch is the current stable 2.4 one for 32bit uid quota. XFS is 
a 2.5 problem so for the moment I'm not remotely bothered by it

Re: 2.4.19-pre3-ac1 - Quotactl patch

[Shawn Starr]

oh ok.
Thanks.


On Sun, 17 Mar 2002, Alan Cox wrote:

> > You might want to upgrade to the newer one, the patch has undergone a lot
> > of changes and -ac against the XFS merge of the quotactl patch seriously
> > breaks ;-(
>
> The -ac patch is the current stable 2.4 one for 32bit uid quota. XFS is
> a 2.5 problem so for the moment I'm not remotely bothered by it
>
>
>

OT: "real" letters [Was: 10.31 second kernel compile]

[Itai Nahshon]

> > Hey, careful there! Those English speakers stole that name from German,
> > and in German those umlauts are real letters, too. Incidentally, my ae is
> > next to the '# key ...

There are many ways to count "real" letters. Eg., Hebrew (my
native lang.) counts just 22 but there are 27 glyphs and many
combinations with points (Nikkud) and accents. The Spanish count
27 letters in their alphabet (ñ is a real letter) while the Brazilians
count only 23 (the 26 English letters minus K,W and Y). Some
east-Asian languages haven't finished the count yet (or never
have started)...

> There are still a couple of places you can legitimaely use an ae symbol in
> English. It's not quite dead yet 8)

The only example that I've seen in English texts is use of ï as in "naïve".

I know that ä is used in German and in other languages but if I see
a text that contains a double-ä or 3 ä in one word that's almost certainly
Finnish...

-- Itai

Re: OT: "real" letters [Was: 10.31 second kernel compile]

[Derek Fawcus]

On Mon, Mar 18, 2002 at 03:30:32AM +0200, Itai Nahshon wrote:
> 
> > There are still a couple of places you can legitimaely use an ae symbol in
> > English. It's not quite dead yet 8)
> 
> The only example that I've seen in English texts is use of ï as in "naïve".
> 

The two I can recall off the top of my head are "dæmon" and "færie".

DF

Re: OT: "real" letters [Was: 10.31 second kernel compile]

[Tim Coleman]

On Thu, Mar 21, 2002 at 12:38:13AM +0000, Derek Fawcus wrote:
> On Mon, Mar 18, 2002 at 03:30:32AM +0200, Itai Nahshon wrote:
> > 
> > > There are still a couple of places you can legitimaely use an ae symbol in
> > > English. It's not quite dead yet 8)
> > 
> > The only example that I've seen in English texts is use of ï as in "naïve".
> > 
> 
> The two I can recall off the top of my head are "dæmon" and "færie".

And, of course, encyclopædia.  Or pædiatrician.  Perhaps Lænux?

-- 
Tim Coleman <tim@timcoleman.com>                       [43.28 N 80.31 W]
BMath, Honours Combinatorics and Optimization, University of Waterloo
 "They that can give up essential liberty to obtain a little temporary
  safety deserve neither liberty nor safety." -- Benjamin Franklin

Re: [Lse-tech] Re: 10.31 second kernel compile

[Alan Cox]

> databases, routing tables, and images. Our good friends at Intel
> claim "carrier grade" Linux  needs to run threaded apps
> with 10,000 threads to depose Solaris in telecom - all sharing the
> same monster address space.=20

Thats intel though. The same people who seem to think that hyperthreading
in the CPU is required for carrier grade work 8)

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

On Sat, 16 Mar 2002, Alan Cox wrote:
>
> Thats intel though. The same people who seem to think that hyperthreading
> in the CPU is required for carrier grade work 8)

Well, to be fair, they do seem to be making inroads against Sun.

Maybe that factor-of-five performance edge has something to do with that
part, though ;)

		Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
> > databases, routing tables, and images. Our good friends at Intel
> > claim "carrier grade" Linux  needs to run threaded apps
> > with 10,000 threads to depose Solaris in telecom - all sharing the
> > same monster address space.=20
> 
> Thats intel though. The same people who seem to think that hyperthreading
> in the CPU is required for carrier grade work 8)

I love the whole sound of "carrier grade" though: Do you use "carrier grade"
Linux or just the "recreational boating" version?


-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[rddunlap]

On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:

| On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
| > > databases, routing tables, and images. Our good friends at Intel
| > > claim "carrier grade" Linux  needs to run threaded apps
| > > with 10,000 threads to depose Solaris in telecom - all sharing the
| > > same monster address space.=20
| >
| > Thats intel though. The same people who seem to think that hyperthreading
| > in the CPU is required for carrier grade work 8)
|
| I love the whole sound of "carrier grade" though: Do you use "carrier grade"
| Linux or just the "recreational boating" version?

Don't know what Intel is claiming, but OSDL is
sponsoring a "Carrier Grade Linux Working Group".
See info at www.osdl.org and/or at cglinux.sf.net .

-- 
~Randy

Re: [Lse-tech] Re: 10.31 second kernel compile

[Alan Cox]

> I love the whole sound of "carrier grade" though: Do you use "carrier grade"
> Linux or just the "recreational boating" version?

Linux is alread carrier (pigeon) grade
		-> www.blug.linux.no/rfc1149/

Re: [Lse-tech] Re: 10.31 second kernel compile

[Kai Henningsen]

yodaiken@fsmlabs.com  wrote on 16.03.02 in <20020316161057.A23495@hq.fsmlabs.com>:

> On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
> > > databases, routing tables, and images. Our good friends at Intel
> > > claim "carrier grade" Linux  needs to run threaded apps
> > > with 10,000 threads to depose Solaris in telecom - all sharing the
> > > same monster address space.=20
> >
> > Thats intel though. The same people who seem to think that hyperthreading
> > in the CPU is required for carrier grade work 8)
>
> I love the whole sound of "carrier grade" though: Do you use "carrier grade"
> Linux or just the "recreational boating" version?

Wrong carrier, though. It's not US Navy carriers (those people use NT,  
after all, and this was "depose Solaris"), it's carriers like AT&T - phone  
companies. And I suspect many of those 10,000 threads are handling one  
phone conversation each. Or maybe one half of one.

In fact, that's a problem space I find much more interesting than the  
military. *These* people need to be robust in peacetime. They can't afford  
a big showy piece of hardware that breaks down when it's finally needed,  
because "finally" is a very short-term goal.

MfG Kai

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sun, Mar 17, 2002 at 04:52:00PM +0200, Kai Henningsen wrote:
> yodaiken@fsmlabs.com  wrote on 16.03.02 in <20020316161057.A23495@hq.fsmlabs.com>:
> 
> > On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
> > > > databases, routing tables, and images. Our good friends at Intel
> > > > claim "carrier grade" Linux  needs to run threaded apps
> > > > with 10,000 threads to depose Solaris in telecom - all sharing the
> > > > same monster address space.=20
> > >
> > > Thats intel though. The same people who seem to think that hyperthreading
> > > in the CPU is required for carrier grade work 8)
> >
> > I love the whole sound of "carrier grade" though: Do you use "carrier grade"
> > Linux or just the "recreational boating" version?
> 
> Wrong carrier, though. It's not US Navy carriers (those people use NT,  
> after all, and this was "depose Solaris"), it's carriers like AT&T - phone  

Really? So why are they always talking about that ship SS7 and the 
sonar network - SONET ? I think Alan may have something there about the
carrier pigeon angle, though. Needs more study.

Actually, it makes me think of "as big, manoeuverable, and 
low cost  as an aircraft carrier" although that is certainly unfair.

> companies. And I suspect many of those 10,000 threads are handling one  
> phone conversation each. Or maybe one half of one.
> 
> In fact, that's a problem space I find much more interesting than the  
> military. *These* people need to be robust in peacetime. They can't afford  
> a big showy piece of hardware that breaks down when it's finally needed,  
> because "finally" is a very short-term goal.

But in my, as always ever so humble, opinion, 10,000 threads is a programming
error based on the incorrect Solaris theory that threads were a good
substitute for thinking about scheduling operations. So making Linux
handle 10K threads is not necessarily an appealing idea unless you can
think of some very clever way to do it.
On the other hand, if I just wanted to sell chips, I might think 
differently.



> 
> MfG Kai
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Pavel Machek]

Hi!

> > > To me, once you have a G of memory, wasting a few meg on unused process 
> > > memory seems no big deal.
> > 
> > It's not the process memory, and it is a whole lot than a "few meg" if 
> > your page size is 2M.
> 
> I forget what an extremist you are. My claim is that
> some processes benefit from big pages, some do not.
> A 16G process needs 2^25 bytes of PTE at 4kbytes/page if I
> did the numbers right. Just populating 4 million odd  page tables is a 
> pain. I might be wrong about it, but I wonder if just scaling
> up from a working 32 bit strategy gets you anywhere.
> If you want to optimize for gnome, you get a very different
> layout. But Hammer and ia64 are supposedly designed for huge
> databases, routing tables, and images. Our good friends at Intel

Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
you see?]
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> you see?]

Thanks for the insight. Only by reading LKM could
I have found out that AMD doesn't care about server space.

Re: [Lse-tech] Re: 10.31 second kernel compile

[Chris Friesen]

yodaiken@fsmlabs.com wrote:
> 
> On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> > Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> > you see?]
> 
> Thanks for the insight. Only by reading LKM could
> I have found out that AMD doesn't care about server space.

The sledgehammer is a bit more than a slightly modified athlon...

up to 8 way multiprocessing
64-bit addressing
hypertransport
integrated DDR memory controller


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Tue, Mar 19, 2002 at 05:09:37PM -0500, Chris Friesen wrote:
> yodaiken@fsmlabs.com wrote:
> > 
> > On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> > > Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> > > you see?]
> > 
> > Thanks for the insight. Only by reading LKM could
> > I have found out that AMD doesn't care about server space.
> 
> The sledgehammer is a bit more than a slightly modified athlon...
> 
> up to 8 way multiprocessing
> 64-bit addressing
> hypertransport
> integrated DDR memory controller

Look at www.amd.com front page  for some subtle hints on where
the margin is.


> 
> 
> -- 
> Chris Friesen                    | MailStop: 043/33/F10  
> Nortel Networks                  | work: (613) 765-0557
> 3500 Carling Avenue              | fax:  (613) 765-2986
> Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Bill Davidsen]

On Tue, 19 Mar 2002 yodaiken@fsmlabs.com wrote:

> On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> > Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> > you see?]
> 
> Thanks for the insight. Only by reading LKM could
> I have found out that AMD doesn't care about server space.

You can get BS from Intel lovers in the Intel group as well. If you
believe that 8-way SMP doesn't indicate an interest in server space you
see a larger market for games and DSI than I do.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [Lse-tech] Re: 10.31 second kernel compile

[Richard Gooch]

yodaiken@fsmlabs.com writes:
> On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> > That will hopefully change eventually because 2M pages are a bit help for
> > a lot of applications that are limited by TLB thrashing, but needs some 
> > thinking on how to avoid the fragmentation trap (e.g. I'm considering
> > to add a highmem zone again just for that and use rmap with targetted
> > physical freeing to allocating them) 
> 
> To me, once you have a G of memory, wasting a few meg on unused
> process memory seems no big deal.

I'm not happy to throw away 2 MiB per process. My workstation has 1
GiB of RAM, and 65 processes (and that's fairly low compared to your
average desktop these days, because I just use olwm and don't have a
fancy desktop or lots of windows). You want me to throw over 1/8th of
my RAM away?!?

And in fact, isn't it going to be more than 2 MiB wasted per process?
For each shared object loaded, only partial pages are going to be
used. *My* libc is less than 700 KiB, so I'd be wasting most of a page
to map it in.

I want that 1 GiB of RAM to be used to cache most of my data. Those
NASA 1km/pixel satellite mosaics of the world are pretty big, you know
(21600x21600x3 per hemisphere:-).

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sat, Mar 16, 2002 at 01:27:52PM -0700, Richard Gooch wrote:
> yodaiken@fsmlabs.com writes:
> > On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> > > That will hopefully change eventually because 2M pages are a bit help for
> > > a lot of applications that are limited by TLB thrashing, but needs some 
> > > thinking on how to avoid the fragmentation trap (e.g. I'm considering
> > > to add a highmem zone again just for that and use rmap with targetted
> > > physical freeing to allocating them) 
> > 
> > To me, once you have a G of memory, wasting a few meg on unused
> > process memory seems no big deal.
> 
> I'm not happy to throw away 2 MiB per process. My workstation has 1
> GiB of RAM, and 65 processes (and that's fairly low compared to your
> average desktop these days, because I just use olwm and don't have a
> fancy desktop or lots of windows). You want me to throw over 1/8th of
> my RAM away?!?

Why not?  If you just ran vim on console you'd be more productive and
not need all those worthless processes. 

At 4KB/page and 8bytes/pte a
1G process will need at least 2MB of pte alone ! Add in the 4 layers,
the software VM struct, ...


> 
> And in fact, isn't it going to be more than 2 MiB wasted per process?
> For each shared object loaded, only partial pages are going to be
> used. *My* libc is less than 700 KiB, so I'd be wasting most of a page
> to map it in.

You're using a politically incorrect libc. 
But sure, big pages are not always good.


> I want that 1 GiB of RAM to be used to cache most of my data. Those
> NASA 1km/pixel satellite mosaics of the world are pretty big, you know
> (21600x21600x3 per hemisphere:-).


> 
> 				Regards,
> 
> 					Richard....
> Permanent: rgooch@atnf.csiro.au
> Current:   rgooch@ras.ucalgary.ca

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Richard Gooch]

yodaiken@fsmlabs.com writes:
> On Sat, Mar 16, 2002 at 01:27:52PM -0700, Richard Gooch wrote:
> > yodaiken@fsmlabs.com writes:
> > > On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> > > > That will hopefully change eventually because 2M pages are a bit help for
> > > > a lot of applications that are limited by TLB thrashing, but needs some 
> > > > thinking on how to avoid the fragmentation trap (e.g. I'm considering
> > > > to add a highmem zone again just for that and use rmap with targetted
> > > > physical freeing to allocating them) 
> > > 
> > > To me, once you have a G of memory, wasting a few meg on unused
> > > process memory seems no big deal.
> > 
> > I'm not happy to throw away 2 MiB per process. My workstation has 1
> > GiB of RAM, and 65 processes (and that's fairly low compared to your
> > average desktop these days, because I just use olwm and don't have a
> > fancy desktop or lots of windows). You want me to throw over 1/8th of
> > my RAM away?!?
> 
> Why not?  If you just ran vim on console you'd be more productive and
> not need all those worthless processes. 

Yeah, right.

> At 4KB/page and 8bytes/pte a
> 1G process will need at least 2MB of pte alone ! Add in the 4 layers,
> the software VM struct, ...

This isn't a dedicated bigass-image display box. It's a workstation.
It's where I read email, hack kernels, write visualisation tools and
stuff like that.

And I can afford a few MiB of RAM for PTE's and such for *the one
process which is mapping my huge data files*! That's effectively a
small, one-time cost. Every other process doesn't have a significant
PTE cost.

I'm not using my kernel as a device driver for an image display
programme. I'm using it run a box that's generally useful to me.

> > And in fact, isn't it going to be more than 2 MiB wasted per process?
> > For each shared object loaded, only partial pages are going to be
> > used. *My* libc is less than 700 KiB, so I'd be wasting most of a page
> > to map it in.
> 
> You're using a politically incorrect libc.

Yeah :-) Man it feels good.

> But sure, big pages are not always good.

Hm. With wide TLB's, what are the benefits to big pages? One
pathological case that hit me a few years back was a workload which
bounced around in VM in a pattern that really thrash the cache due to
aliasing. It wouldn't have been a problem if we had truly fully
set-associative caches, rather than N-way (where N is 2, 4 or 8
usually). But big pages won't help that much here (it's just a way of
reducing TLB thrash, but doesn't help with cache thrashing).

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [Lse-tech] Re: 10.31 second kernel compile

[yodaiken]

On Sat, Mar 16, 2002 at 02:05:17PM -0700, Richard Gooch wrote:
> > Why not?  If you just ran vim on console you'd be more productive and
> > not need all those worthless processes. 
> 
> Yeah, right.

I was just trying to be nice.

> > At 4KB/page and 8bytes/pte a
> > 1G process will need at least 2MB of pte alone ! Add in the 4 layers,
> > the software VM struct, ...
> 
> This isn't a dedicated bigass-image display box. It's a workstation.
> It's where I read email, hack kernels, write visualisation tools and
> stuff like that.
> 
> And I can afford a few MiB of RAM for PTE's and such for *the one
> process which is mapping my huge data files*! That's effectively a
> small, one-time cost. Every other process doesn't have a significant
> PTE cost.

Well, it's a matter of target. I'm thinking about our customers who
do high grade image processing on a stream of gig+ bitmaps. They need
64 (some are already painfully stranded on Alphas) and they don't use these
boxes for email. 

> > But sure, big pages are not always good.
> 
> Hm. With wide TLB's, what are the benefits to big pages? One

tlb miss rates, mm structure overhead and setup/teardown, swap speed,

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: [Lse-tech] Re: 10.31 second kernel compile

[Rik van Riel]

On Sat, 16 Mar 2002, Richard Gooch wrote:

> And I can afford a few MiB of RAM for PTE's and such for *the one
> process which is mapping my huge data files*!

Once you have this, you might as well make that granularity
per VMA.

This gives you the advantage of being able to share the
mapping for libc.so ;)

>From what I can see, you'll basically want large pages
for:

1) Oracle and maybe other large shared memory situations
   where the page table overhead would otherwise be
   prohibitively high

2) scientific calculations and other programs with a huge
   dataset where TLB misses would be prohibitively slow

regards,

Rik
-- 
<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/

Re: [Lse-tech] Re: 10.31 second kernel compile

[Chris Wedgwood]

On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:

    On Sat, Mar 16, 2002 at 12:57:11PM -0700, yodaiken@fsmlabs.com
    wrote:

    >
    > What about 2M pages?

    They are not supported for user space, but used in private
    mappings for kernel text and direct memory mappings. Generic code
    never sees them.

Is there any reason we couldn't use them for mapping large
frame-buffers and similar?



  --cw

Re: [Lse-tech] Re: 10.31 second kernel compile

[Alan Cox]

>     They are not supported for user space, but used in private
>     mappings for kernel text and direct memory mappings. Generic code
>     never sees them.
> 
> Is there any reason we couldn't use them for mapping large
> frame-buffers and similar?

You are labouring under the belief that processors touch the frame buffer
nowdays. For a current accelerated frame buffer that isnt very true.

Re: [Lse-tech] Re: 10.31 second kernel compile

[Chris Wedgwood]

On Sun, Mar 17, 2002 at 03:43:29AM +0000, Alan Cox wrote:

    You are labouring under the belief that processors touch the frame
    buffer nowdays. For a current accelerated frame buffer that isnt
    very true.

/s/frame-buffer/hunk-of-memory/

Either way, we have tens of MB of ram where we either put textures,
options or whatever --- the CPU has to meddle with it one way or
another.



  --cw

Re: [Lse-tech] Re: 10.31 second kernel compile

[Alan Cox]

> Either way, we have tens of MB of ram where we either put textures,
> options or whatever --- the CPU has to meddle with it one way or
> another.

The disk DMA's it to RAM, the graphics card fetches it via the GART
mappings. We shouldn't be touching a lot of it. 

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:
> 
> What about 2M pages?

Not useful for generic loads right now, and the latencies for clearing or
copying them them etc (ie single page faults - nopage or COW) are still
big enough that it would likely be a performance problem at that level.  
And while doing IO in 2MB chunks sounds like fun, since most files are
still just a few kB, your page cache memory overhead would be prohibitive
(ie even if you had 64GB of memory, you might want to cache more than a
few thousand files at the same time).

So then you'd need to do page caching at a finer granularity than you do
mmap, which imples absolutely horrible things from a coherency standpoint
(mmap/read/write are supposed to be coherent in a nice UNIX - even if
there are some of non-nice unixes still around).

We may get there some day, but right now 2M pages are not usable for use 
access.

64kB would be fine, though.

Oh, and in the specific case of hammer, one of the main advantages of the 
thing is of course running old binaries unchanged. And old binaries 
certainly do mmap's at smaller granularity than 2M (and have to, because a 
3G user address space won't fit all that many 2M chunks).

Give up on large pages - it's just not happening. Even when a 64kB page 
would make sense from a technology standpoint these days, backwards 
compatibility makes people stay at 4kB.

Instead of large pages, you should be asking for larger and wider TLB's
(for example, nothign says that a TLB entry has to be a single page:
people already do the kind of "super-entries", where one TLB entry
actually contains data for 4 or 8 aligned pages, so you get the _effect_
of a 32kB page that really is 8 consecutive 4kB pages).

Such a "wide" TLB entry has all the advantages of small pages (no 
memory fragmentation, backwards compatibility etc), while still being able 
to load 64kB worth of translations in one go.

(One of the advantages of a page table tree over a hashed setup becomes
clear in this kind of situation: you cannot usefully load multiple entries
from the same cacheline into one TLB entry in a hashed table, while in a
tree it's truly trivial)

		Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[Andi Kleen]

On Sat, Mar 16, 2002 at 12:14:06PM -0800, Linus Torvalds wrote:
> Oh, and in the specific case of hammer, one of the main advantages of the 
> thing is of course running old binaries unchanged. And old binaries 
> certainly do mmap's at smaller granularity than 2M (and have to, because a 
> 3G user address space won't fit all that many 2M chunks).

The idea was to only map selected mappings using large pages, e.g. shared
memory mappings to help all the databases or use a special mmap flag 
for the Beowulf people. 

> Give up on large pages - it's just not happening. Even when a 64kB page 
> would make sense from a technology standpoint these days, backwards 
> compatibility makes people stay at 4kB.

Yes the 4KB page has to be kept at least for now. 

-ANdi

Re: [Lse-tech] Re: 10.31 second kernel compile

[Rusty Russell]

On Sat, 16 Mar 2002 21:22:29 +0100
Andi Kleen <ak@suse.de> wrote:

> On Sat, Mar 16, 2002 at 12:14:06PM -0800, Linus Torvalds wrote:
> > Give up on large pages - it's just not happening. Even when a 64kB page 
> > would make sense from a technology standpoint these days, backwards 
> > compatibility makes people stay at 4kB.
> 
> Yes the 4KB page has to be kept at least for now. 

We have sysconf(_SC_PAGESIZE).  I say, introduce an experimental CONFIG for
64k pagesize in 2.5, so we can start to weed out the problem apps NOW.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [Lse-tech] Re: 10.31 second kernel compile

[Rik van Riel]

On Sat, 16 Mar 2002, Linus Torvalds wrote:
> On Sat, 16 Mar 2002 yodaiken@fsmlabs.com wrote:
> >
> > What about 2M pages?
>
> Not useful for generic loads right now, and the latencies for clearing or
> copying them them etc (ie single page faults - nopage or COW) are still
> big enough that it would likely be a performance problem at that level.
> And while doing IO in 2MB chunks sounds like fun, since most files are
> still just a few kB,

In other words, large pages should be a "special hack" for
special applications, like Oracle and maybe some scientific
calculations ?

Grabbing some bitflags in generic datastructures shouldn't
be an issue since free bits are available.

regards,

Rik
-- 
<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

In article <Pine.LNX.4.44L.0203171021090.2181-100000@imladris.surriel.com>,
Rik van Riel  <riel@conectiva.com.br> wrote:
>
>In other words, large pages should be a "special hack" for
>special applications, like Oracle and maybe some scientific
>calculations ?

Yes, I think so.

That said, a 64kB page would be useful for generic use. 

>Grabbing some bitflags in generic datastructures shouldn't
>be an issue since free bits are available.

I had large-page-support working in the VM a long time ago, back when I
did the original VM portability rewrite.  I actually exposed the kernel
large pages to the VM, and it worked fine - I didn't even need a new
bit, since the code just used the "large page" bit in the page table
directly. 

But it wasn't ever exposed to user space, and in the end I just made the
kenel mapping just not visible to the VM and simplified the x86
pmd_xxx() macros.  The approach definitely worked, though. 

			Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[Davide Libenzi]

On Sun, 17 Mar 2002, Linus Torvalds wrote:

> In article <Pine.LNX.4.44L.0203171021090.2181-100000@imladris.surriel.com>,
> Rik van Riel  <riel@conectiva.com.br> wrote:
> >
> >In other words, large pages should be a "special hack" for
> >special applications, like Oracle and maybe some scientific
> >calculations ?
>
> Yes, I think so.
>
> That said, a 64kB page would be useful for generic use.
>
> >Grabbing some bitflags in generic datastructures shouldn't
> >be an issue since free bits are available.
>
> I had large-page-support working in the VM a long time ago, back when I
> did the original VM portability rewrite.  I actually exposed the kernel
> large pages to the VM, and it worked fine - I didn't even need a new
> bit, since the code just used the "large page" bit in the page table
> directly.
>
> But it wasn't ever exposed to user space, and in the end I just made the
> kenel mapping just not visible to the VM and simplified the x86
> pmd_xxx() macros.  The approach definitely worked, though.

Couldn't we choose the page size depending on the map size ?
If we start mixing page sizes, what about kernel code that assumes PAGE_SIZE ?



- Davide

Re: [Lse-tech] Re: 10.31 second kernel compile

[Rik van Riel]

On Sun, 17 Mar 2002, Davide Libenzi wrote:
> On Sun, 17 Mar 2002, Linus Torvalds wrote:
>
> > In article <Pine.LNX.4.44L.0203171021090.2181-100000@imladris.surriel.com>,
> > Rik van Riel  <riel@conectiva.com.br> wrote:
> > >
> > >In other words, large pages should be a "special hack" for
> > >special applications, like Oracle and maybe some scientific
> > >calculations ?
> >
> > Yes, I think so.

> Couldn't we choose the page size depending on the map size ?

For on-disk files I guess this is better an mmap flag,
but for shared memory segments we could try to do this
automagically.

> If we start mixing page sizes, what about kernel code that assumes
> PAGE_SIZE ?

We fix it.

Rik
-- 
<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/

Re: [Lse-tech] Re: 10.31 second kernel compile

[Davide Libenzi]

On Sun, 17 Mar 2002, Rik van Riel wrote:

> On Sun, 17 Mar 2002, Davide Libenzi wrote:
> > On Sun, 17 Mar 2002, Linus Torvalds wrote:
> >
> > > In article <Pine.LNX.4.44L.0203171021090.2181-100000@imladris.surriel.com>,
> > > Rik van Riel  <riel@conectiva.com.br> wrote:
> > > >
> > > >In other words, large pages should be a "special hack" for
> > > >special applications, like Oracle and maybe some scientific
> > > >calculations ?
> > >
> > > Yes, I think so.
>
> > Couldn't we choose the page size depending on the map size ?
>
> For on-disk files I guess this is better an mmap flag,
> but for shared memory segments we could try to do this
> automagically.

What's the reason that would make more convenient for us, upon receiving a
request to map a NNN MB file, to map it using 4Kb pages instead of 4MB ones ?




- Davide

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

On Sun, 17 Mar 2002, Davide Libenzi wrote:
>
> What's the reason that would make more convenient for us, upon receiving a
> request to map a NNN MB file, to map it using 4Kb pages instead of 4MB ones ?

Ehh.. Let me count the ways:
 - reliably allocation of 4MB of contiguous data
 - graceful fallback when you need to start paging
 - sane coherency with somebody who mapped the same file/segment in a much
   smaller chunk

Guyes, 4MB pages are always going to be a special case. There's no sane
way to make them automatic, for the simple reason that they are USELESS
for "normal" work, and they have tons of problems that are quite
fundamental and just aren't going away and cannot be worked around.

The only sane way to use 4MB segments is:

 - the application does a special system call (or special flag to mmap)
   saying that it wants a big page and doesn't care about coherency with
   anybody else that didn't set the flag (and realize that that probably
   includes things like read/write)

 - the machine has sufficiently enough memory that the user can be allowed
   to _lock_ the area down, so that you don't have to worry about
   swapping out that thing in 4M pieces. (This of course implies that
   per-user memory counters have to work too, or we have to limit it by
   default with a rlimit or something to zero).

In short, very much a special case.

(There are two reasons you don't want to handle paging on 4M chunks: (a)
they may be wonderful for IO throughput, but they are horrible for latency
for other people and (b) you now have basically just a few bits of usage
information for 4M worth of memory, as opposed to a finer granularity view
of which parts are actually _used_).

Once you can count on having memory sizes in the hundreds of Gigs, and
disk throughput speeds in the hundreds of megs a second, and ther are
enough of these machines to _matter_ (and reliably 64-bit address spaces
so that virtual fragmentation doesn't matter), we might make 4MB the
regular mapping entity.

That's probably at least a decade away.

		Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[Davide Libenzi]

On Sun, 17 Mar 2002, Linus Torvalds wrote:

> On Sun, 17 Mar 2002, Davide Libenzi wrote:
> >
> > What's the reason that would make more convenient for us, upon receiving a
> > request to map a NNN MB file, to map it using 4Kb pages instead of 4MB ones ?
>
> Ehh.. Let me count the ways:
>  - reliably allocation of 4MB of contiguous data
>  - graceful fallback when you need to start paging
>  - sane coherency with somebody who mapped the same file/segment in a much
>    smaller chunk
>
> Guyes, 4MB pages are always going to be a special case. There's no sane
> way to make them automatic, for the simple reason that they are USELESS
> for "normal" work, and they have tons of problems that are quite
> fundamental and just aren't going away and cannot be worked around.
>
> The only sane way to use 4MB segments is:
>
>  - the application does a special system call (or special flag to mmap)
>    saying that it wants a big page and doesn't care about coherency with
>    anybody else that didn't set the flag (and realize that that probably
>    includes things like read/write)
>
>  - the machine has sufficiently enough memory that the user can be allowed
>    to _lock_ the area down, so that you don't have to worry about
>    swapping out that thing in 4M pieces. (This of course implies that
>    per-user memory counters have to work too, or we have to limit it by
>    default with a rlimit or something to zero).
>
> In short, very much a special case.
>
> (There are two reasons you don't want to handle paging on 4M chunks: (a)
> they may be wonderful for IO throughput, but they are horrible for latency
> for other people and (b) you now have basically just a few bits of usage
> information for 4M worth of memory, as opposed to a finer granularity view
> of which parts are actually _used_).
>
> Once you can count on having memory sizes in the hundreds of Gigs, and
> disk throughput speeds in the hundreds of megs a second, and ther are
> enough of these machines to _matter_ (and reliably 64-bit address spaces
> so that virtual fragmentation doesn't matter), we might make 4MB the
> regular mapping entity.
>
> That's probably at least a decade away.

Plenty of reason thanks Linus :) ... even if workstations with Gigs of RAM
and no swap are not so uncommon nowadays. Anyway i agree about the flag
driven activation ...




- Davide

Re: [Lse-tech] Re: 10.31 second kernel compile

[Mike Fedyk]

On Sun, Mar 17, 2002 at 05:13:16PM -0800, Davide Libenzi wrote:
> On Sun, 17 Mar 2002, Rik van Riel wrote:
> 
> > On Sun, 17 Mar 2002, Davide Libenzi wrote:
> > > On Sun, 17 Mar 2002, Linus Torvalds wrote:
> > >
> > > > In article <Pine.LNX.4.44L.0203171021090.2181-100000@imladris.surriel.com>,
> > > > Rik van Riel  <riel@conectiva.com.br> wrote:
> > > > >
> > > > >In other words, large pages should be a "special hack" for
> > > > >special applications, like Oracle and maybe some scientific
> > > > >calculations ?
> > > >
> > > > Yes, I think so.
> >
> > > Couldn't we choose the page size depending on the map size ?
> >
> > For on-disk files I guess this is better an mmap flag,
> > but for shared memory segments we could try to do this
> > automagically.
> 
> What's the reason that would make more convenient for us, upon receiving a
> request to map a NNN MB file, to map it using 4Kb pages instead of 4MB ones ?

... the VM chooses to unmap a mmaped page, it chooses a 4mb page, later it
needs just a few bytes from that unmaped page and free 4mb instead of 4kb (worst
case) to map that page again...

Re: [Lse-tech] Re: 10.31 second kernel compile

[Davide Libenzi]

On Sun, 17 Mar 2002, Mike Fedyk wrote:

> On Sun, Mar 17, 2002 at 05:13:16PM -0800, Davide Libenzi wrote:

> > What's the reason that would make more convenient for us, upon receiving a
> > request to map a NNN MB file, to map it using 4Kb pages instead of 4MB ones ?
>
> ... the VM chooses to unmap a mmaped page, it chooses a 4mb page, later it
> needs just a few bytes from that unmaped page and free 4mb instead of 4kb (worst
> case) to map that page again...

The big-page property should be vma related and should be obviously
handled correctly ...



- Davide

Re: [Lse-tech] Re: 10.31 second kernel compile

[Rogier Wolff]

Linus Torvalds wrote:
> We may get there some day, but right now 2M pages are not usable for use 
> access.
> 
> 64kB would be fine, though.

[...]

> Give up on large pages - it's just not happening. Even when a 64kB page 
> would make sense from a technology standpoint these days, backwards 
> compatibility makes people stay at 4kB.

I would think that "large page support" that the processors give you
is indeed unusable, but what do you think about "software large(r)
pages"?

What I mean is that instead of doing the 4k that the ia32 hardware
gives us, we pretend that pages are (e.g.) 8k. Thus we always load a
pair of page table entries. memmap ends up having 8k granularity, IO
is done on page-sized (i.e. 8k in this case) chunks etc etc. (%)

So we have a "PAGE_SIZE" define all around the kernel. Keep that the
same (for compatibility), but make a "REAL_PAGE_SIZE" that governs the
loop that actually sets the page table (or tlb) entries.... Note that
a first implementation may actually effectivly reduce the size of the
TLB on machines with a software loaded TLB....

Why would I want this? Well, suppose I have a machine that unavoidably
has to swap on some of its workload. In practise you will almost
double the disk troughput by increasing the page size by a factor of
two.  If the hit rate on the "extra page" that you swap in by
pretending pages are 8k and not 4k is over a couple of percents (*),
then this is advantageous: A seek plus transfer of 4k costs say 10ms +
0.16us while a seek plus transfer of 8k costs 10ms + .33 us (#). Thus
the "penalty" of the extra 4k transfer is very, very small.

Now, for all the reasons you mention, keeping 4k as the "default" on
Intel is good. But a config option:

                on      on
	       intel   alpha
page size: 	4k
		8k	8k
		16k 	16k 
		32k	32k
		64k	64k
		128k	128k

would also be good for some people. 

				Roger. 

(*) Actually it has to be a "couple of percents better than the 4k
page that we had to evict to be able to accomodate the current extra
4k...

(#) A 10k RPM disk rotates in 6ms, so average rotational latency is
about 3ms, and with an average seek time of 7ms, that comes to 10ms.

(%) And we get ext2 8k block size support on ia32!

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: [Lse-tech] Re: 10.31 second kernel compile

[Andrew Morton]

Rogier Wolff wrote:
> 
> ...
> So we have a "PAGE_SIZE" define all around the kernel. Keep that the
> same (for compatibility), but make a "REAL_PAGE_SIZE" that governs the
> loop that actually sets the page table (or tlb) entries.... Note that
> a first implementation may actually effectivly reduce the size of the
> TLB on machines with a software loaded TLB....
> 
> Why would I want this? Well, suppose I have a machine that unavoidably
> has to swap on some of its workload. In practise you will almost
> double the disk troughput by increasing the page size by a factor of
> two.

swapin and swapout already perform multipage clustering - you'd get
the same benefits from increasing SWAP_CLUSTER_MAX and page_cluster.

Which is a three-line patch.

Frankly, all the discussion I've seen about altering page sizes
threatens to add considerable complexity for very dubious gains.
The only place where I've seen a solid justification is for
scientific applications which have a huge working set, and need
large pages to save on TLB thrashing.

For everything else, I believe we can get the efficiencies
which we need by writing efficient code; no need to go playing
with page sizes.

If someone can point at a real-world workload and say "we suck",
and we can't fix that suckage without altering the page size then
would that person please come forth.
 
-

Re: [Lse-tech] Re: 10.31 second kernel compile

[Nick Craig-Wood]

On Sun, Mar 24, 2002 at 01:35:57PM -0800, Andrew Morton wrote:
> Frankly, all the discussion I've seen about altering page sizes
> threatens to add considerable complexity for very dubious gains.
> The only place where I've seen a solid justification is for
> scientific applications which have a huge working set, and need
> large pages to save on TLB thrashing.

A widely used example is mprime - the mersenne prime finding program (
http://www.mersenne.org/ ).  This typically uses 8 or more MBytes of
RAM which it completely thrashes.

The program is written in very efficient assembler code and has been
designed not to thrash the TLB as much as possible, but with a working
set of > 8 MBs (which is iterated through many times a second at
maximum memory bandwith) large pages would make a real improvement to
it.  Since each run takes weeks any improvement would be eagerly
snatched at by the 1000s of people running this program ;-)

If there was some hack where 4MB pages could be allocated for
applications like this then I'd be very happy!

-- 
Nick Craig-Wood
ncw@axis.demon.co.uk

Re: [Lse-tech] Re: 10.31 second kernel compile

[Andi Kleen]

> If there was some hack where 4MB pages could be allocated for
> applications like this then I'd be very happy!

You could always run it as a kernel module.
Just need to add schedule points or use a preemptive kernel. 
When you allocate data using get_free_pages() it'll return a pointer
in the 2 or 4MB mapped direct mapping of the kernel. It'll only work
when your memory is not fragmented. 

-Andi
> 

Re: [Lse-tech] Re: 10.31 second kernel compile

[Martin J. Bligh]

> Frankly, all the discussion I've seen about altering page sizes
> threatens to add considerable complexity for very dubious gains.

If we don't mix page sizes, but just increase the default from
4k, does this still add a lot of complexity in your eyes? I can't
see why it would ... ?

> If someone can point at a real-world workload and say "we suck",
> and we can't fix that suckage without altering the page size then
> would that person please come forth.

I believe one of the traditional problems stated for this case is
the amount of virtual address space taken up by all the struct pages
for a machine with large amounts of memory (32-64Gb). At the moment, 
the obvious choice of architecture is still 32 bit, but maybe AMD 
Hammer will fix this ... Unless someone has a plan to move all those
up into highmem as well ....

M.

Re: [Lse-tech] Re: 10.31 second kernel compile

[Richard Gooch]

Linus Torvalds writes:
> Instead of large pages, you should be asking for larger and wider TLB's
> (for example, nothign says that a TLB entry has to be a single page:
> people already do the kind of "super-entries", where one TLB entry
> actually contains data for 4 or 8 aligned pages, so you get the _effect_
> of a 32kB page that really is 8 consecutive 4kB pages).
> 
> Such a "wide" TLB entry has all the advantages of small pages (no
> memory fragmentation, backwards compatibility etc), while still
> being able to load 64kB worth of translations in one go.

These are contiguous physical pages, or just logical (virtual) pages?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [Lse-tech] Re: 10.31 second kernel compile

[Linus Torvalds]

On Sat, 16 Mar 2002, Richard Gooch wrote:
> 
> These are contiguous physical pages, or just logical (virtual) pages?

Contiguous virtual pages, but discontiguous physical pages.

The advantage being that you only need one set of virtual tags per "wide" 
entry, and you just fill the whole wide entry directly from the cacheline 
(ie the TLB entry is not really 32 bits any more, it's a full cacheline).

The _real_ advantage being that it should be totally invisible to 
software. I think Intel does something like this, but the point is, I 
don't even have to know, and it still works.

			Linus

Re: [Lse-tech] Re: 10.31 second kernel compile

[Richard Gooch]

Linus Torvalds writes:
> 
> On Sat, 16 Mar 2002, Richard Gooch wrote:
> > 
> > These are contiguous physical pages, or just logical (virtual) pages?
> 
> Contiguous virtual pages, but discontiguous physical pages.

That's what I was hoping. Having both contiguous would be of some
benefit, but of course at the cost of having to unfragment physical
pages. Even if Andi can cleanly do that with rmap, it's still going to
cost (page copies, Dcache footprint, locking and more). I like the
"wide" TLB approach much more.

> The advantage being that you only need one set of virtual tags per
> "wide" entry, and you just fill the whole wide entry directly from
> the cacheline (ie the TLB entry is not really 32 bits any more, it's
> a full cacheline).
> 
> The _real_ advantage being that it should be totally invisible to
> software. I think Intel does something like this, but the point is,
> I don't even have to know, and it still works.

Completely behind the kernel's, back? Even so, is there some hint we
can give to the CPU to help? Or perhaps a hint an application can give
to the kernel to specify better alignment of mappings? The latter
would require a way for the kernel to find out the preferred alignment
from the CPU. Is this information available?

Anyone know if AMD does this as well?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Configure.help editorial policy

[Eric S. Raymond]

I guess it's a pretty quiet week in kernel-hacker land.  Must be,
otherwise people would have better things to do than argue over KB
vs. KiB.  The alternative would be to conclude that significant
portions of the lkml population prefer flaming to coding, and that
couldn't possibly be the case, could it?

Let me make a couple of things clear:

I am by no means in love with the new abbreviations described at
<http://physics.nist.gov/cuu/Units/binary.html>.  I have the same 
reflexes as the rest of you -- they kind of make me want to gag.

If there is a clear consensus from lkml, I will be happy to back
out this change.  Perhaps this terminological standard does not
meet a real need, perhaps it will be rejected by most engineers and 
deserves to wither on the vine.  It's happened before.

However.  In the *absence* of a clear consensus, I will follow best
practices.  Best practice in editing a technical or standards document
is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
to use, follow and reference international standards.

In fact, the first time David Woodhouse submitted this change, some
months ago, I rejected it.  I have since, reluctantly, concluded
that I was wrong to do so.  So when he re-submitted, I merged in
the patch.

My personal esthetic distaste for the new terminology (gack!  "kibi" 
sounds like something I would feed my cat!) is less important
than following best practices.  I'm hoping it will seem less ugly as it
becomes more familiar.

I don't like my duty much in this instance.  But my duty is clear.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"As to the species of exercise, I advise the gun. While this gives [only]
moderate exercise to the body, it gives boldness, enterprise, and independence
to the mind.  Games played with the ball and others of that nature, are too
violent for the body and stamp no character on the mind. Let your gun,
therefore, be the constant companion to your walks."
        -- Thomas Jefferson, writing to his teenaged nephew.

Re: Configure.help editorial policy

[Reid Hekman]

On Thu, 2001-12-20 at 13:32, Eric S. Raymond wrote:
> I am by no means in love with the new abbreviations described at
> <http://physics.nist.gov/cuu/Units/binary.html>.  I have the same 
> reflexes as the rest of you -- they kind of make me want to gag.

I second that emotion.

> If there is a clear consensus from lkml, I will be happy to back
> out this change.  Perhaps this terminological standard does not
> meet a real need, perhaps it will be rejected by most engineers and 
> deserves to wither on the vine.  It's happened before.

I'd vote for that.

> However.  In the *absence* of a clear consensus, I will follow best
> practices.  Best practice in editing a technical or standards document
> is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
> to use, follow and reference international standards.

Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
proposal (of which I learned here:
http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ). I understand
that muddying the waters is not the way to see clearly into the depths
of computer science for the unwashed masses, but the ambiguity that
currently exists is very real. I try to explain these issues on what
seems like a daily basis to many and the duplicitous terms are not
helpful.
 
> My personal esthetic distaste for the new terminology (gack!  "kibi" 
> sounds like something I would feed my cat!) is less important
> than following best practices.  I'm hoping it will seem less ugly as it
> becomes more familiar.

It certainly rated high on my kibbles'n'bits meter as well :-)

Whatever we do with the abbreviations, I would strongly recommend we
spell out documention to help educate ( and ease the transition if we
switch terms) wherever possible. For example:

4 binary kilobyte pages
1024 decimal kilobyte disk
8.4 decimal gigabyte disks
4 binary gigabytes of memory
10 decimal gigabits of bandwith

or if that offends the sensibilities:

4 kilobytes (binary)
1024 kilobytes (decimal)
8.4 gigabytes (decimal)

I know that they are long on keystrokes, but in lieu of an accepted and
aesthetically pleasing standard, they are clear and unambiguous.
 
Regards,
Reid
--
Protect your rights, Geeks with Guns!

Re: Configure.help editorial policy

[Eric S. Raymond]

Reid Hekman <reid.hekman@ndsu.nodak.edu>:
> Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
> proposal (of which I learned here:
> http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ).

Hm.  Attractive, but it doesn't have an ISO standard behind it.

> Whatever we do with the abbreviations, I would strongly recommend we
> spell out documention to help educate ( and ease the transition if we
> switch terms) wherever possible. For example:
> 
> 4 binary kilobyte pages
> 1024 decimal kilobyte disk
> 8.4 decimal gigabyte disks
> 4 binary gigabytes of memory
> 10 decimal gigabits of bandwith
> 
> or if that offends the sensibilities:
> 
> 4 kilobytes (binary)
> 1024 kilobytes (decimal)
> 8.4 gigabytes (decimal)
> 
> I know that they are long on keystrokes, but in lieu of an accepted and
> aesthetically pleasing standard, they are clear and unambiguous.

Good idea.  I will make appropriate changes.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role.	-- Edward Abbey

Re: Configure.help editorial policy

[Rob Landley]

On Thursday 20 December 2001 03:23 pm, Eric S. Raymond wrote:
> Reid Hekman <reid.hekman@ndsu.nodak.edu>:
> > Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
> > proposal (of which I learned here:
> > http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ).
>
> Hm.  Attractive, but it doesn't have an ISO standard behind it.

Two words: "Posix threading."

Somebody had to say it.

How many successful real-world networks have been designed around the OSI 7 
layer burrito networking model?

ISO standards do not define reality much on the internet.  RFCs define 
reality quite often on the internet.  Most RFCs come well after the fact, and 
an amazing number of RFCs are ignored or quickly replaced.  Several of them 
ADMIT to being jokes.  Are you saying an ISO pronouncement has MORE weight 
than an RFC?

ISO got into the computing world largely by rubber-stamping existing 
standards from ANSI, CCITT, IEEE, and elsewhere.  Not by making good 
decisions.  The ISO will happily standardize sugar cube sizes and pencil lead 
density.  They don't HAVE to know anything about the subject in question.

The best standards are the ones that either document practices that already 
exist or define a draft interoperability procol hammered out by the parties 
who are going to implement it (preferably with sample code which ends up 
being worth more than the standards document).

Do you expect Microsoft to start using the term "mebibyte" any time soon?  Or 
hard drive manufacturers (who largely use decimal megabytes anyway for 
marketing reasons)?  Or ram manufacturers who obviously want end users to 
learn a new term to buy their products?  It would be a stupid marketing move. 
 (Sheesh, AMD's launching a major campaign to get away from "megahertz".  And 
failing at it, I might add.)  How long did it take for end users to stop 
referring to the "baud rate" of their modem, which hasn't been technically 
true since the 300 baud days.  (A "2400 baud" modem was actually 600 baud, 4 
symbol if I remember correctly...)

In the short term, this change to the help files (which people look at when 
they DON'T know stuff) is GUARANTEED to confuse WAY more people than it even 
hopes to help over at least the next two years.  Almost everybody who sees it 
is going to have to ask "what's a mebibyte" and go look it up.  Does this 
really make the help file more helpful?

If the term goes into widespread use, THEN switch.  If you want to make a 
policy about it, we currently use binary measures when we measure memory or 
storage in the linux kernel unless otherwise specified.  Always have done.

Rob

Re: Configure.help editorial policy

[Mike Eldridge]

On Thu, Dec 20, 2001 at 02:27:02PM -0600, Reid Hekman wrote:
> Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
> proposal (of which I learned here:
> http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ). I understand
> that muddying the waters is not the way to see clearly into the depths
> of computer science for the unwashed masses, but the ambiguity that
> currently exists is very real. I try to explain these issues on what
> seems like a daily basis to many and the duplicitous terms are not
> helpful.

KKB looks a million times better than KiB.  maybe it's the lowercase
letter, i don't know.

> > My personal esthetic distaste for the new terminology (gack!  "kibi" 
> > sounds like something I would feed my cat!) is less important
> > than following best practices.  I'm hoping it will seem less ugly as it
> > becomes more familiar.
> 
> It certainly rated high on my kibbles'n'bits meter as well :-)
> 
> Whatever we do with the abbreviations, I would strongly recommend we
> spell out documention to help educate ( and ease the transition if we
> switch terms) wherever possible. For example:
> 
> 4 binary kilobyte pages
> 1024 decimal kilobyte disk
> 8.4 decimal gigabyte disks
> 4 binary gigabytes of memory
> 10 decimal gigabits of bandwith
> 
> or if that offends the sensibilities:
> 
> 4 kilobytes (binary)
> 1024 kilobytes (decimal)
> 8.4 gigabytes (decimal)
> 
> I know that they are long on keystrokes, but in lieu of an accepted and
> aesthetically pleasing standard, they are clear and unambiguous.

i will agree that the ambiguity sucks and something needs to be done
about it, but i really do find the SI units for binary plain ugly.  i
doubt that anyone would be willing to type as much text for referencing
simple sizes as you explained above.

perhaps simply a base suffix:
	4KB(2) == 4 * 2^10
	4MB(2) == 4 * 2^20
	4KB(10) == 4 * 10^3
	4MB(10) == 4 * 10^4

it's definitely wierd to look at, but it seems to get the point across
easier.  it defines the base, instead of referencing a name (kibi?
please, i don't think enough people will start using these
grossly-sounding prefixes enough to make it the de facto standard).
or perhaps a (d) or (b) qualifier to refer to decimal or binary.

perhaps everybody should just suck it up and go with what's standard?

-mike

--------------------------------------------------------------------------
   /~\  The ASCII                       all that is gold does not glitter
   \ /  Ribbon Campaign                 not all those who wander are lost
    X   Against HTML                          -- jrr tolkien
   / \  Email!

          radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd           
--------------------------------------------------------------------------

Re: Configure.help editorial policy

[Matthias Andree]

On Thu, 20 Dec 2001, Reid Hekman wrote:

> or if that offends the sensibilities:
> 
> 4 kilobytes (binary)
> 1024 kilobytes (decimal)
> 8.4 gigabytes (decimal)

"decimal" is implied when using SI prefixes.

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

Re: Configure.help editorial policy

[Vojtech Pavlik]

On Thu, Dec 20, 2001 at 02:32:47PM -0500, Eric S. Raymond wrote:

> I guess it's a pretty quiet week in kernel-hacker land.  Must be,
> otherwise people would have better things to do than argue over KB
> vs. KiB.  The alternative would be to conclude that significant
> portions of the lkml population prefer flaming to coding, and that
> couldn't possibly be the case, could it?

The kb versus KB versus KiB versus whatever may come next was always a
very flammable cause.

Now my opinion on this would be: By sticking KiB everywhere nothing is
helped. To the knowledgeable, it's nothing new that memory is measured
in binary units, while ethernet speed in decimal ones. To the newbie,
KiB is about as cryptical as KB and he'll never know which is which,
because as a newbie (s)he didn't read the standards.

And of course, every search-and-replace cleanup will always upset many
people regardless which direction it goes.

On the other hand, making documentation less ambiguous is always a good
thing. I'd suggest a more careful approach, adding descriptive wording
in places where bits and bytes may be confused, and where binary or
decimal prefixes may be.

And speaking of the 1 Mbps connection - I fear that in many cases
that'll be 1024000 bytes per second. What M is that? Binary or decimal?
Who does care?

-- 
Vojtech Pavlik
SuSE Labs

Configure.help editorial policy

[David Garfield]

Eric S. Raymond writes:
 > If there is a clear consensus from lkml, I will be happy to back
 > out this change.  Perhaps this terminological standard does not
 > meet a real need, perhaps it will be rejected by most engineers and 
 > deserves to wither on the vine.  It's happened before.

Another option: maybe the choice of KB vs KiB vs KKB should be a
configuration choice.

--David Garfield

Re: Configure.help editorial policy

[Eric S. Raymond]

David Garfield <garfield@irving.iisd.sra.com>:
> Another option: maybe the choice of KB vs KiB vs KKB should be a
> configuration choice.

You *must* be joking.

Please tell me you're joking.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"
		Law and Contemporary Problems 49, no. 1. (Winter 1986.): 35-62.

Re: Configure.help editorial policy

[Tom Rini]

On Thu, Dec 20, 2001 at 06:52:26PM -0500, Eric S. Raymond wrote:
> David Garfield <garfield@irving.iisd.sra.com>:
> > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > configuration choice.
> 
> You *must* be joking.
> 

Hopefully.  Here's a serious one tho.  Why don't we say at the bottom:
1 kB (or KB or KiB or ...) is 2^10 bytes.  Like we do for code that can
be compiled as a module...  As long as we're consistant in the suffix,
and we define it, it doesn't matter what it is.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Configure.help editorial policy (H20 and K2B)

[Timothy Covell]

On Thursday 20 December 2001 17:52, Eric S. Raymond wrote:
> David Garfield <garfield@irving.iisd.sra.com>:
> > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > configuration choice.
>

Um, you know, all due repect to Knuth, the God, I think that
someof his ideas are downright silly.   Now, my suggestion
is different, namely, inserting a 2 in the unit such as "K2B"
meaning Kilo (base2) Byte.    It's not like we don't have a
precendent from the chemistry and physics fields. 

-- 
timothy.covell@ashavan.org.

Re: Configure.help editorial policy (H20 and K2B)

[Timothy Covell]

On Friday 21 December 2001 07:01, Timothy Covell wrote:
> On Thursday 20 December 2001 17:52, Eric S. Raymond wrote:
> > David Garfield <garfield@irving.iisd.sra.com>:
> > > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > > configuration choice.
>
> Um, you know, all due repect to Knuth, the God, I think that
> someof his ideas are downright silly.   Now, my suggestion
> is different, namely, inserting a 2 in the unit such as "K2B"
> meaning Kilo (base2) Byte.    It's not like we don't have a
> precendent from the chemistry and physics fields.

I've changed my mind.   K2B would seem to imply
2**3 Bytes, which is 8 Bytes.  

I think that way to solve the issue is to just byte 
the bullet and stop equating 1024 with K.   It's
just such an inconsistant and ad hoc hack.

The only truly logical way to do this would be
to base everything on bits and powers of
two.  But, since we run out of common prefixes
at 2**6 (exa), we should just stick to decimal
and scientific format.    1024 = 2**10.





-- 
timothy.covell@ashavan.org.

Re: Configure.help editorial policy

[David Garfield]

Eric S. Raymond writes:
 > David Garfield <garfield@irving.iisd.sra.com>:
 > > Another option: maybe the choice of KB vs KiB vs KKB should be a
 > > configuration choice.
 > 
 > You *must* be joking.
 > 
 > Please tell me you're joking.

No, I'm serious.  I will understand if CML2 does not support
meta-configuration.  A configuration choice as I described above could
be viewed as a minor facet of a language configuration choice.
(Should kernel configuration be internationalized or at least
internationalizable?)

Choice of kB vs KB vs KiB vs KKB could also be used in some places in
the kernel.  For instance, /proc/meminfo currently shows "kB".

--David

Re: Configure.help editorial policy

[Eric S. Raymond]

David Garfield <garfield@irving.iisd.sra.com>:
> Eric S. Raymond writes:
>  > Please tell me you're joking.
> 
> No, I'm serious.  I will understand if CML2 does not support
> meta-configuration.  A configuration choice as I described above could
> be viewed as a minor facet of a language configuration choice.
> (Should kernel configuration be internationalized or at least
> internationalizable?)
> 
> Choice of kB vs KB vs KiB vs KKB could also be used in some places in
> the kernel.  For instance, /proc/meminfo currently shows "kB".

What, and *encourage* non-uniform terminology?  No, I won't do that.
Better to have a single standard set of abbreviations, no matter how
ugly, than this.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The American Republic will endure, until politicians realize they can
bribe the people with their own money.
	-- Alexis de Tocqueville

Re: Configure.help editorial policy

[Benjamin LaHaise]

On Fri, Dec 21, 2001 at 01:40:34PM -0500, Eric S. Raymond wrote:
> What, and *encourage* non-uniform terminology?  No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.

So, encouraging non-uniform terminology, breaking applicates *and* 
confusing the hell out of everyone is better?  Face it, the only 
people trying to confuse things are the disk vendors.  DRAM is sold 
by the MB, everyone talks about MB == 1024*1024...  I'm having a 
hard time giving a sympathetic ear to anyone try to change the well 
established, and consistent (barring the storage venduhs), standard.

		-ben
-- 
Fish.

Re: Configure.help editorial policy

[Oliver Xymoron]

On Fri, 21 Dec 2001, Benjamin LaHaise wrote:

> On Fri, Dec 21, 2001 at 01:40:34PM -0500, Eric S. Raymond wrote:
> > What, and *encourage* non-uniform terminology?  No, I won't do that.
> > Better to have a single standard set of abbreviations, no matter how
> > ugly, than this.
>
> So, encouraging non-uniform terminology, breaking applicates *and*
> confusing the hell out of everyone is better?  Face it, the only
> people trying to confuse things are the disk vendors.  DRAM is sold
> by the MB, everyone talks about MB == 1024*1024...  I'm having a
> hard time giving a sympathetic ear to anyone try to change the well
> established, and consistent (barring the storage venduhs), standard.

Not true. Bandwidth is measured in metric. Pixels are measured in metric.
Basically anything but RAM is measured in metric. RAM is the exception
because of its intimate relation to bus width and that's an obvious
anachronism. There's no reason anyone but a systems programmer should give
a damn about powers of two.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Configure.help editorial policy

[Jeff Mcadams]

Also sprach Oliver Xymoron
>Not true. Bandwidth is measured in metric.

If by this you mean that in networking, a megabit per second is equal to
1000^2, or a gigabit per second is 1000^3, then my response consists of:

Uhm, no.

If your response (I haven't followed this whole thread, so I'm not up on
all of the discussion here) is concerning the capitalization and such
used for it, then I really don't care which it is as the purpose is to
communicate, and strict adherence to capitalization just isn't that
important to communication.  *shrug*

>Basically anything but RAM is measured in metric. RAM is the exception
>because of its intimate relation to bus width and that's an obvious
>anachronism. There's no reason anyone but a systems programmer should
>give a damn about powers of two.

This makes me think you're concerned about powers of 2 versus powers of
10.  In which case, reference my response above.
-- 
Jeff McAdams                            Email: jeffm@iglou.com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Re: Configure.help editorial policy

[Kai Henningsen]

jeffm@iglou.com (Jeff Mcadams)  wrote on 21.12.01 in <20011221180354.A10001@iglou.com>:

> Also sprach Oliver Xymoron
> >Not true. Bandwidth is measured in metric.
>
> If by this you mean that in networking, a megabit per second is equal to
> 1000^2, or a gigabit per second is 1000^3, then my response consists of:
>
> Uhm, no.

Well, 64 kBit/s is certainly equal to 64000 bits per second. (That's  
ISDN.)

And from a quick look through Google, Ethernet - in 10M, 100M, and G  
variants at least - also uses decimal powers.

So I'd say that's "Uhm, yes".

MfG Kai

Re: Configure.help editorial policy

[Chris Wedgwood]

On Fri, Dec 21, 2001 at 02:18:47PM -0500, Benjamin LaHaise wrote:

    So, encouraging non-uniform terminology, breaking applicates *and*
    confusing the hell out of everyone is better?  Face it, the only
    people trying to confuse things are the disk vendors.  DRAM is
    sold by the MB, everyone talks about MB == 1024*1024...  I'm
    having a hard time giving a sympathetic ear to anyone try to
    change the well established, and consistent (barring the storage
    venduhs), standard.

And disks by the GB where GB == 1000^3 so I don't see any problem in
moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
BEYOND THE KERNEL and nothing will change this.



  --CW

Re: Configure.help editorial policy

[Benjamin LaHaise]

On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> And disks by the GB where GB == 1000^3 so I don't see any problem in
> moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> BEYOND THE KERNEL and nothing will change this.

If you think GB == 1000^3, then please go "correct" all the DRAM 
manufacturers out in the world.  They just sent me 1GB of ram and 
it's coming up as 1073741824 bytes.  Please help!  They have no 
option for GiB!!!

		-ben
-- 
Fish.

Re: Configure.help editorial policy

[Rik van Riel]

On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> > And disks by the GB where GB == 1000^3 so I don't see any problem in
> > moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> > BEYOND THE KERNEL and nothing will change this.
>
> If you think GB == 1000^3, then please go "correct" all the DRAM
> manufacturers out in the world.  They just sent me 1GB of ram and
> it's coming up as 1073741824 bytes.  Please help!  They have no
> option for GiB!!!

Also, a GB of disk space really is 2^10 * 10^6 ...

Better make sure we get it consistent ... *runs like hell*

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: Configure.help editorial policy

[Benjamin LaHaise]

On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:
> Also, a GB of disk space really is 2^10 * 10^6 ...
> 
> Better make sure we get it consistent ... *runs like hell*

I always thought they'd like to count the size of disks in bits...  man, 
don't you really want on of those new 240Gbit disks?  I hear they can 
pull in a sustained 200Gbit/s on reads!

		-ben
-- 
Fish.

Re: Configure.help editorial policy

[Chris Wedgwood]

On Fri, Dec 21, 2001 at 03:47:50PM -0500, Benjamin LaHaise wrote:

    On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:

    > Also, a GB of disk space really is 2^10 * 10^6 ...
    >
    > Better make sure we get it consistent ... *runs like hell*

    I always thought they'd like to count the size of disks in bits...
    man, don't you really want on of those new 240Gbit disks?  I hear
    they can pull in a sustained 200Gbit/s on reads!

But what Rik points out shows that right now there is ambiguity
BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
best, disk manufactures get to claim nice marketing numbers.

As for bits/second sort of thing, this is common in networking of
course, especially when they talk about raw data rate and ignore
framing overhead and such like.


   --cw

Re: Configure.help editorial policy

[Rik van Riel]

On Sat, 22 Dec 2001, Chris Wedgwood wrote:
> On Fri, Dec 21, 2001 at 03:47:50PM -0500, Benjamin LaHaise wrote:
>     On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:
>
>     > Also, a GB of disk space really is 2^10 * 10^6 ...

> But what Rik points out shows that right now there is ambiguity
> BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
> best, disk manufactures get to claim nice marketing numbers.

Actually, I was more trying to ridicule the people who believe
we have any chance in hell of "getting it right".

Personally I believe we should stick to tradition. Better let
people be confused about the last 10% of capacity than confused
about the meaning of the text ...

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: Configure.help editorial policy

[Benjamin LaHaise]

On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
> But what Rik points out shows that right now there is ambiguity
> BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
> best, disk manufactures get to claim nice marketing numbers.

GiB is not a useful standard because NOBODY USES IT.  When it's in 
common use, then consider applying it to the kernel, but please, 
not before then.

		-ben
-- 
Fish.

Re: Configure.help editorial policy

[Thomas Dodd]

Benjamin LaHaise wrote:

> GiB is not a useful standard because NOBODY USES IT.  When it's in 
> common use, then consider applying it to the kernel, but please, 
> not before then.


What better place to start "common use" then the kernel source.
Let's lead the way, not wait around to follow others.

Somebody has to be first, why not us?
Then once it get more common, we will have
been a leader forging into a brave new world :)

	-Thomas

Just my 2.8 KiB worth :)

Re: Configure.help editorial policy

[Nicholas Knight]

On Friday 21 December 2001 01:33 pm, Thomas Dodd wrote:
> Benjamin LaHaise wrote:
> > GiB is not a useful standard because NOBODY USES IT.  When it's in
> > common use, then consider applying it to the kernel, but please,
> > not before then.
>
> What better place to start "common use" then the kernel source.
> Let's lead the way, not wait around to follow others.
>
> Somebody has to be first, why not us?
> Then once it get more common, we will have
> been a leader forging into a brave new world :)

Maybe because there's strong resistance to the change in the very place 
you'd evidently like to START the change? That's generaly a clue that 
it'd be best NOT to try and make the change.

>
> 	-Thomas
>
> Just my 2.8 KiB worth :)

Re: Configure.help editorial policy

[Oliver Xymoron]

On Fri, 21 Dec 2001, Benjamin LaHaise wrote:

> On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
> > But what Rik points out shows that right now there is ambiguity
> > BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
> > best, disk manufactures get to claim nice marketing numbers.
>
> GiB is not a useful standard because NOBODY USES IT.  When it's in
> common use, then consider applying it to the kernel, but please,
> not before then.

To summarize: don't use it widely until it's widely used.

Let's apply that standard to aio, shall we? :P

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Configure.help editorial policy

[Benjamin LaHaise]

On Fri, Dec 21, 2001 at 06:07:20PM -0600, Oliver Xymoron wrote:
> To summarize: don't use it widely until it's widely used.

Actually, I just find it the most gratingly ugly thing I've ever seen, 
and pointless as everyone already knows the meaning by context.

		-ben
-- 
Fish.

Re: Configure.help editorial policy

[Cameron Simpson]

On Fri, Dec 21, 2001 at 04:10:30PM -0500, Benjamin LaHaise <bcrl@redhat.com> wrote:
| On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
| > But what Rik points out shows that right now there is ambiguity
| > BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
| > best, disk manufactures get to claim nice marketing numbers.
| 
| GiB is not a useful standard because NOBODY USES IT.  When it's in 
| common use, then consider applying it to the kernel, but please, 
| not before then.

This is poor motivation.

s/GiB/linux/

We can all go to using Windows then... Thus is progress made.
-- 
Cameron Simpson, DoD#743        cs@zip.com.au    http://www.zip.com.au/~cs/

Re: Configure.help editorial policy

[Chris Wedgwood]

On Fri, Dec 21, 2001 at 03:31:36PM -0500, Benjamin LaHaise wrote:

    If you think GB == 1000^3, then please go "correct" all the DRAM
    manufacturers out in the world.  They just sent me 1GB of ram and
    it's coming up as 1073741824 bytes.  Please help!  They have no
    option for GiB!!!

I don't want to get dragged into this silly debate; the point I was
making is that we already have considerable inconsistency and choosing
STANDARDS BASED tokens might not be a bad thing.

The nomenclature in use here is bigger than Linux (yes, believe it or
not such a thing is possible!), and like it or not people should just
get over it.

Standards exist to make peoples lives easier, the fact the hard drive
and memory vendors currently don't use these phrases right now doesn't
make the standard wrong --- this world is full of clue-less marketing
people and nothing will change this.

Accept that KB and GB are *wrong* (this isn't a statement of opinion
but rather of fact [1]) and then choose whether or not Linux
documentation should be wrong or right.



  --cw

[1] IMO anyhow :)

Re: Configure.help editorial policy

[Benjamin LaHaise]

On Sat, Dec 22, 2001 at 09:57:11AM +1300, Chris Wedgwood wrote:
> I don't want to get dragged into this silly debate; the point I was
> making is that we already have considerable inconsistency and choosing
> STANDARDS BASED tokens might not be a bad thing.

They're defacto standards that have been in use for well over a decade.  
If the same could be said about GiB, maybe I could agree with you.

> The nomenclature in use here is bigger than Linux (yes, believe it or
> not such a thing is possible!), and like it or not people should just
> get over it.

Hmmm, all of the advertising, computer media and electrical engineering 
related material I've read recently seems to be using GB.  In fact, there 
was one very article about the whole issue that found the computer 
industry to be remarkably consistent in using terms like "10GB" with no 
space between the number and the measuring unit.  Oh wait, sorry, that's 
not formally approved by any standards bodies.

> Standards exist to make peoples lives easier, the fact the hard drive
> and memory vendors currently don't use these phrases right now doesn't
> make the standard wrong --- this world is full of clue-less marketing
> people and nothing will change this.

Many standards bodies are examples of confusopolies.  Take a look at the 
POSIX threading standards.  Do they make people's lives easier under 
Linux?  Should we accept every standard at face value and follow it 
obediently wherever it takes us?

> Accept that KB and GB are *wrong* (this isn't a statement of opinion
> but rather of fact [1]) and then choose whether or not Linux
> documentation should be wrong or right.

Can you send me replacements for all the documentation I've got that 
mentions GB or KB then?  I wouldn't want to be non-compliant.

		-ben

Re: Configure.help editorial policy

[Rik van Riel]

On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Sat, Dec 22, 2001 at 09:57:11AM +1300, Chris Wedgwood wrote:

> > Accept that KB and GB are *wrong* (this isn't a statement of opinion
> > but rather of fact [1]) and then choose whether or not Linux
> > documentation should be wrong or right.
>
> Can you send me replacements for all the documentation I've got that
> mentions GB or KB then?  I wouldn't want to be non-compliant.

And how about my 17 M-KiByte disk ?

(yes, 17 million kibibytes, plus or minus whatever the amount of
disk space is the factory's low-level format found ... probably
as much as an error as getting the exact word in the manual)

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: Configure.help editorial policy

[Oliver Xymoron]

On Fri, 21 Dec 2001, Benjamin LaHaise wrote:

> On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> > And disks by the GB where GB == 1000^3 so I don't see any problem in
> > moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> > BEYOND THE KERNEL and nothing will change this.
>
> If you think GB == 1000^3, then please go "correct" all the DRAM
> manufacturers out in the world.  They just sent me 1GB of ram and
> it's coming up as 1073741824 bytes.  Please help!  They have no
> option for GiB!!!

If you think GB == 1024^3, then please go "correct" all the disk
manufacturers out in the world.  They just sent me 1GB of disk and
it's coming up as 1000000000 bytes.  Please help!  They have no
option for GiB!!!

It's already clear that the terminology is internally inconsistent, now we
can either clarify it or live with the existing confusion.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Configure.help editorial policy

[Kai Henningsen]

oxymoron@waste.org (Oliver Xymoron)  wrote on 21.12.01 in <Pine.LNX.4.43.0112211438360.16844-100000@waste.org>:

> On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
>
> > On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> > > And disks by the GB where GB == 1000^3 so I don't see any problem in
> > > moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> > > BEYOND THE KERNEL and nothing will change this.
> >
> > If you think GB == 1000^3, then please go "correct" all the DRAM
> > manufacturers out in the world.  They just sent me 1GB of ram and
> > it's coming up as 1073741824 bytes.  Please help!  They have no
> > option for GiB!!!
>
> If you think GB == 1024^3, then please go "correct" all the disk
> manufacturers out in the world.  They just sent me 1GB of disk and
> it's coming up as 1000000000 bytes.  Please help!  They have no
> option for GiB!!!

You've been defrauded. Typical disk GB come up as 1024,000,000 bytes.

Which is bloody awful.

MfG Kai

Re: Configure.help editorial policy

[Kai Henningsen]

bcrl@redhat.com (Benjamin LaHaise)  wrote on 21.12.01 in <20011221160333.K15926@redhat.com>:

> On Sat, Dec 22, 2001 at 09:57:11AM +1300, Chris Wedgwood wrote:
> > I don't want to get dragged into this silly debate; the point I was
> > making is that we already have considerable inconsistency and choosing
> > STANDARDS BASED tokens might not be a bad thing.
>
> They're defacto standards that have been in use for well over a decade.

And it's been wrong for all of that decade, because the rest of the world  
- *all* of it - has been using a different version for quite a bit longer  
than that.

> Hmmm, all of the advertising, computer media and electrical engineering
> related material I've read recently seems to be using GB.  In fact, there
> was one very article about the whole issue that found the computer
> industry to be remarkably consistent in using terms like "10GB" with no
> space between the number and the measuring unit.  Oh wait, sorry, that's
> not formally approved by any standards bodies.

Unfortunately, while the typesetting may be consistent, the *meaning*  
isn't. You cannot swap out 10GB RAM to a 10GB hard disk, it will overflow.

> Many standards bodies are examples of confusopolies.

Well, this particular "de facto standard" certainly is a confusopoly.


MfG Kai

Re: Configure.help editorial policy

[Kai Henningsen]

cw@f00f.org (Chris Wedgwood)  wrote on 22.12.01 in <20011221205711.GA32465@weta.f00f.org>:

> Standards exist to make peoples lives easier, the fact the hard drive
> and memory vendors currently don't use these phrases right now doesn't
> make the standard wrong --- this world is full of clue-less marketing
> people and nothing will change this.

Oh, it can be changed. Just the way car advertising has been changed to  
use kW. (Well, it has over here.) And the way monitor size advertising is  
in the process of being changed to use SI units, not US ones.

Fair advertising laws can be rather effective.

MfG Kai

Re: Configure.help editorial policy

[Timo Jantunen]

On Fri, 21 Dec 2001, Benjamin LaHaise wrote:

> So, encouraging non-uniform terminology, breaking applicates *and*
> confusing the hell out of everyone is better?  Face it, the only people
> trying to confuse things are the disk vendors.  DRAM is sold by the MB,
> everyone talks about MB == 1024*1024...  I'm having a hard time giving a
> sympathetic ear to anyone try to change the well established, and
> consistent (barring the storage venduhs), standard.

And disk vendors aren't even consistant! At least my 30 GB and 40 GB drives 
have 60036480 and 80418240 sectors, respectively (512 bytes each).

That computes to 30.7*10^9 and 41.2*10^9 or 28.6*2^30 and 38.3*2^30 bytes.

If you want numbers near 30 and 40 you need to calculate 30.0*10^6*2^10 and 
40.2*10^6*2^10!


And as somebody else pointed out, 1 Mbit/s line is't 10^6 bit/s nor 2^20 
bit/s line, either, a but 1024000 bit/s line.

=> Even if Configure.help would use kiB, MiB, GiB etc. it wouldn't remove 
many of the ambiguities. Is it worth the pain?


> 		-ben

// /
....................................Timo Jantunen  .......................
       ZZZ      (Used to represent :Kuunsäde 8 A 28: Email: jeti @iki.fi :
the  sound of  a person  snoring.) :02210 Espoo    : http://iki.fi/jeti  :
Webster's  Encyclopedic Unabridged :Finland        : GSM +358-40-5763131 :
Dictionary of the English Language :...............:.....................:

Re: Configure.help editorial policy

[Alan Cox]

> by the MB, everyone talks about MB == 1024*1024...  I'm having a 
> hard time giving a sympathetic ear to anyone try to change the well 
> established, and consistent (barring the storage venduhs), standard.

If someone sells you 16MB of RAM and it turns out to be 16,000,000 bytes,
not only would it be appropriate use of units, it would be quite reasonable
as far as I can see to say it was in accordance with labelling of products.

The world did not begin in 1970, A-Za-z is not English collate order and
M is 1,000,000. When computing meets the rest of planet earth usages for
the odd hundred years its hard to see any reason to believe we are "right"

Eric using MiB seems the right thing. Its an ugly but appropriate unit, its
at least recommended as a solution by a standards body. We can either
redefine SI units ("You cannot change the laws of physics") or find a better
label. What better than a recommended one others use.

Alan

Re: Configure.help editorial policy

[Vojtech Pavlik]

On Sat, Dec 22, 2001 at 12:32:54AM +0000, Alan Cox wrote:
> > by the MB, everyone talks about MB == 1024*1024...  I'm having a 
> > hard time giving a sympathetic ear to anyone try to change the well 
> > established, and consistent (barring the storage venduhs), standard.
> 
> If someone sells you 16MB of RAM and it turns out to be 16,000,000 bytes,
> not only would it be appropriate use of units, it would be quite reasonable
> as far as I can see to say it was in accordance with labelling of products.
> 
> The world did not begin in 1970, A-Za-z is not English collate order and
> M is 1,000,000. When computing meets the rest of planet earth usages for
> the odd hundred years its hard to see any reason to believe we are "right"
> 
> Eric using MiB seems the right thing. Its an ugly but appropriate unit, its
> at least recommended as a solution by a standards body. We can either
> redefine SI units ("You cannot change the laws of physics") or find a better
> label. What better than a recommended one others use.

The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...

4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
20GB harddrive is usually 20 * 10^6 * 2^10 bytes.

The confusion is there. It can't be erradicated by adding Mi's and Gi's,
because they don't cover the whole spectrum.

Well, maybe we could have a 4 kKib/s connection and a 20 MKiB drive, but
that'd be even more confusing than what we have now.

-- 
Vojtech Pavlik
SuSE Labs

Re: Configure.help editorial policy

[Allan Sandfeld]

On Saturday 22 December 2001 17:14, Vojtech Pavlik wrote:
>
> The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
>
> 4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
>
> The confusion is there. It can't be erradicated by adding Mi's and Gi's,
> because they don't cover the whole spectrum.
>
Please, please dont add more confusion.. Fortunatly people how sell harddisk 
and bandwidth are both very consistent.
4Mbit bandwith IS always 4 x 10^9 bits per second
20GB harddrive IS always  20 x 10^20 bytes.

The confusion starts by saying a Mbit is only 1000 Kbit.. Well it is but the 
Kbit here is 1000bit/s
And a GB is only 1000,000 kB, but these kB is only 1000 bytes.

Dont confuse the matter anymore, I am sure someone does, but they are wrong! 

regards
Allan

Re: Configure.help editorial policy

[Acrimon Beet]

On Thursday 27 December 2001 19:44, Allan Sandfeld wrote:

> Please, please dont add more confusion.. Fortunatly people how sell
> harddisk and bandwidth are both very consistent.
> 4Mbit bandwith IS always 4 x 10^9 bits per second
> 20GB harddrive IS always  20 x 10^20 bytes.

This is fantastic!

> The confusion starts by saying a Mbit is only 1000 Kbit.. 

Your confusion seems to start when you are many orders of magnitude out with 
both your previous examples.

> Dont confuse the matter anymore, I am sure someone does, but they are
> wrong!

whoohooo

--
ABeet.

Re: Configure.help editorial policy

[Kai Henningsen]

vojtech@suse.cz (Vojtech Pavlik)  wrote on 22.12.01 in <20011222171438.A10233@suse.cz>:

> The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
>
> 4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.

There's a simple answer. "These people lie."

> The confusion is there. It can't be erradicated by adding Mi's and Gi's,
> because they don't cover the whole spectrum.

We don't *want* something that covers that part of the spectrum. We want  
that part to be *avoided*.

MfG Kai

Re: Configure.help editorial policy

[Vojtech Pavlik]

On Thu, Dec 27, 2001 at 12:45:00PM +0200, Kai Henningsen wrote:
> vojtech@suse.cz (Vojtech Pavlik)  wrote on 22.12.01 in <20011222171438.A10233@suse.cz>:
> 
> > The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
> >
> > 4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> > 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
> 
> There's a simple answer. "These people lie."

Ok, then how *you* would call the abovementioned link that has 4096000
bits per second bandwidth? Yes, it's possible to say 4096 kbit, but then
you'll also have 32768 kbit links and 8388608 kbit links ...

> > The confusion is there. It can't be erradicated by adding Mi's and Gi's,
> > because they don't cover the whole spectrum.
> 
> We don't *want* something that covers that part of the spectrum. We want  
> that part to be *avoided*.

But how do you avoid something that *exists*? I mean - physically. The
devices that are described by these numbers are being produced and used.

-- 
Vojtech Pavlik
SuSE Labs

Re: Configure.help editorial policy

[Rik van Riel]

On Fri, 21 Dec 2001, Eric S. Raymond wrote:

> What, and *encourage* non-uniform terminology?  No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.

Last I checked the purpose of language was _communication_.

Better use words people understand.

Also, the kB vs KiB mess is so ambiguous and complex that
it virtually guarantees that the _writers_ of documentation
will get it wrong occasionally and only confuse the readers
more.

As a last point, we shouldn't forget about the inconsistent
way in which the marketing departments of hardware vendors
apply these units to their products. In many cases binary
and decimal units are mixed, leading to something which is
impossible to "get right".  Disk space would be one example
of this, but I'm sure there are more.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: Configure.help editorial policy

[Cameron Simpson]

On Fri, Dec 21, 2001 at 07:17:45PM -0200, Rik van Riel <riel@conectiva.com.br> wrote:
| On Fri, 21 Dec 2001, Eric S. Raymond wrote:
| > What, and *encourage* non-uniform terminology?  No, I won't do that.
| > Better to have a single standard set of abbreviations, no matter how
| > ugly, than this.
| 
| Last I checked the purpose of language was _communication_.
| Better use words people understand.

Well, what we have is KB, which people _think_ they understand, but do not.
And KiB, which is ugly but well defined, albeit less known (at present).

| Also, the kB vs KiB mess is so ambiguous and complex that
| it virtually guarantees that the _writers_ of documentation
| will get it wrong occasionally and only confuse the readers
| more.

KiB is not ambiguous. KB demonstrably is.
And therefore KB is NOT useful for communication, _especially_ technical
communication.

| As a last point, we shouldn't forget about the inconsistent
| way in which the marketing departments of hardware vendors
| apply these units to their products. In many cases binary
| and decimal units are mixed, leading to something which is
| impossible to "get right".  Disk space would be one example
| of this, but I'm sure there are more.

You're just making the case for KB weaker you know...

For all that KiB is ugly, at least it is not ambiguous.
I'll take "precise" over "vague" in technical documentation any time.

Using KB in places where precision matters puts us all into case #4 below,
because people think they know what KB means, but it means different
things to different people, and so people don't realise they are using
a vague term. Which is very bad.
--
Cameron Simpson, DoD#743        cs@zip.com.au    http://www.zip.com.au/~cs/

Men are four:
    He who knows and knows that he knows; he is wise, follow him.
    He who knows and knows not that he knows; he is asleep, wake him.
    He who knows not and knows that he knows not; he is ignorant, teach him.
    He who knows not and knows not that he knows not; he is a fool, spurn him!

Re: Configure.help editorial policy

[Rik van Riel]

On Mon, 24 Dec 2001, Cameron Simpson wrote:

> Using KB in places where precision matters puts us all into case #4
> below, because people think they know what KB means, but it means
> different things to different people, and so people don't realise they

I take it this is your way of volunteering to always
keep all kernel documentation accurate as well as
answer questions from newbies who've never seen
'KiB' before ? ;)

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

http://www.surriel.com/		http://distro.conectiva.com/

Re: Configure.help editorial policy

[Eric S. Raymond]

Rik van Riel <riel@conectiva.com.br>:
> I take it this is your way of volunteering to always
> keep all kernel documentation accurate as well as
> answer questions from newbies who've never seen
> 'KiB' before ? ;)

One of the arguments for the KiB declaration, despite the ugliness of
"kibibytes", is that a newbie seeing "32KiB" is quite likely to deduce
what's meant from context.  Let's not exaggerate the difficulties
here.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491

Re: Configure.help editorial policy

[Riley Williams]

Hi Eric, Rik.

>> I take it this is your way of volunteering to always keep all
>> kernel documentation accurate as well as answer questions from
>> newbies who've never seen 'KiB' before ? ;)

> One of the arguments for the KiB declaration, despite the ugliness
> of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
> deduce what's meant from context.  Let's not exaggerate the
> difficulties here.

Alternatively, deal with this problem the same way the "This may also be
built as a module..." comment is - either include it several thousand
times in Configure.help or (better still) have the configuration tools
spit it out automatically every time the need for it crops up. The
following ruleset could easily be implemented even in the `make config`
and `make menuconfig` parsers, and should be just as easy in CML2.
Applying rule (1) will result in a considerable reduction in the size of
the file Documentation/Configure.help as it currently stands.

Comments, anybody?

Best wishes from Riley.

===============8<=============== CUT ===============>8===============

RULE 1: If a particular symbol is defined using a command that
	allows it to be selected as "Modular", then tack the
	following to the end of the help description for that
	symbol when a user requests help:

		This driver is also available as a module( = code
		which can be inserted in and removed from the
		running kernel whenever you want). If you want to
		compile it as a module, say M here and read
		Documentation/modules.txt in the kernel source.

RULE 2: If the help text for a particular symbol includes a word
	matching either of the egrep patterns '[KkMmGgTt][Bb]' or
	'[KkMmGgTt]i[Bb]' then tack the following to the end of
	the help description for that symbol when a user requests
	help:

		Differing standards are used for the numeric
		designators in the computing and engineering
		worlds. For the purposes of this document, the
		following designators are used with the stated
		values:

			Symbol	Designation	  Number of Bytes
			~~~~~~	~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~
			KiB	Decimal Kilobyte  1,000
			KB	Binary Kilobyte   1,024

			MiB	Decimal Megabyte  1,000,000
			MB	Binary Megabyte   1,048,576

			GiB	Decimal Gigabyte  1,000,000,000
			GB	Binary Gigabyte   1,073,741,824

			TiB	Decimal Terabyte  1,000,000,000,000
			TB	Binary Terabyte   1,099,511,627,776

		This difference has arisen as a direct consequence of
		the fact that computers naturally talk in a binary
		(base 2) number system rather than the decimal (base
		10) system preferred by mere mortals.

RULE 3: If more than one of the above rules apply, all configuration
	systems shall agree on a common order in which to apply them.

Re: Configure.help editorial policy

[Cameron Simpson]

On Wed, Dec 26, 2001 at 05:44:36PM +0000, Riley Williams <rhw@memalpha.cx> wrote:
| >> I take it this is your way of volunteering to always keep all
| >> kernel documentation accurate as well as answer questions from
| >> newbies who've never seen 'KiB' before ? ;)
| 
| > One of the arguments for the KiB declaration, despite the ugliness
| > of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
| > deduce what's meant from context.  Let's not exaggerate the
| > difficulties here.
| 
| Alternatively, deal with this problem the same way the "This may also be
| built as a module..." comment is - either include it several thousand
| times in Configure.help or (better still) have the configuration tools
| spit it out automatically every time the need for it crops up. The
| following ruleset could easily be implemented even in the `make config`
| and `make menuconfig` parsers, and should be just as easy in CML2.
| Applying rule (1) will result in a considerable reduction in the size of
| the file Documentation/Configure.help as it currently stands.
| 
| Comments, anybody?

I like this!
-- 
Cameron Simpson, DoD#743        cs@zip.com.au    http://www.zip.com.au/~cs/

It was a joke, OK?  If we thought it would actually be used, we wouldn't have
written it!	- Marc Andreessen on the creation of a <blink> tag

Re: Configure.help editorial policy

[Dominik Mierzejewski]

On Wednesday, 26 December 2001, Cameron Simpson wrote:
> On Wed, Dec 26, 2001 at 05:44:36PM +0000, Riley Williams <rhw@memalpha.cx> wrote:
> | >> I take it this is your way of volunteering to always keep all
> | >> kernel documentation accurate as well as answer questions from
> | >> newbies who've never seen 'KiB' before ? ;)
> | 
> | > One of the arguments for the KiB declaration, despite the ugliness
> | > of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
> | > deduce what's meant from context.  Let's not exaggerate the
> | > difficulties here.
> | 
> | Alternatively, deal with this problem the same way the "This may also be
> | built as a module..." comment is - either include it several thousand
> | times in Configure.help or (better still) have the configuration tools
> | spit it out automatically every time the need for it crops up. The
> | following ruleset could easily be implemented even in the `make config`
> | and `make menuconfig` parsers, and should be just as easy in CML2.
> | Applying rule (1) will result in a considerable reduction in the size of
> | the file Documentation/Configure.help as it currently stands.
> | 
> | Comments, anybody?
> 
> I like this!

I second this. Being a translator of the file in question, I have to deal
with ten slightly different versions of "You may also compile this as
a module...". So I have ten slighlty different translations of this text,
too, in the name of accuracy.

Although I thought there was an agreement that decimal kilobyte is kB,
and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB
and so on, wasn't there?
 
-- 
"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Re: Configure.help editorial policy

[Riley Williams]

Hi Dominik.

>>>>> I take it this is your way of volunteering to always keep all
>>>>> kernel documentation accurate as well as answer questions from
>>>>> newbies who've never seen 'KiB' before ? ;)

>>>> One of the arguments for the KiB declaration, despite the ugliness
>>>> of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
>>>> deduce what's meant from context.  Let's not exaggerate the
>>>> difficulties here.

>>> Alternatively, deal with this problem the same way the "This may
>>> also be built as a module..." comment is - either include it several
>>> thousand times in Configure.help or (better still) have the
>>> configuration tools spit it out automatically every time the need
>>> for it crops up. The following ruleset could easily be implemented
>>> even in the `make config` and `make menuconfig` parsers, and should
>>> be just as easy in CML2. Applying rule (1) will result in a
>>> considerable reduction in the size of the file
>>> Documentation/Configure.help as it currently stands.
>>>
>>> Comments, anybody?

>> I like this!

> I second this. Being a translator of the file in question, I have to
> deal with ten slightly different versions of "You may also compile
> this as a module...". So I have ten slighlty different translations
> of this text, too, in the name of accuracy.

I have to admit that I hadn't considered translators, but perhaps it
could be made even simpler for you. How about having the help file start
with a set of standard definitions, such as the following...

===8<=== CUT ===>8===

DEFINE_MODULAR
  This driver is also available as a module ( = code which can be
  inserted in and removed from the running kernel whenever you
  want). If you want to compile it as a module, say M here and
  read Documentation/modules.txt in the kernel source.

DEFINE_UNITS
  Differing standards are used for the numeric designators in the
  computing and engineering worlds. For the purposes of this document,
  the following designators are used with the stated values:

  	Symbol	Designation	  Number of Bytes
  	~~~~~~	~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~
  	KiB	Decimal Kilobyte  1,000
  	KB	Binary Kilobyte   1,024

  	MiB	Decimal Megabyte  1,000,000
  	MB	Binary Megabyte   1,048,576

  	GiB	Decimal Gigabyte  1,000,000,000
  	GB	Binary Gigabyte   1,073,741,824

  	TiB	Decimal Terabyte  1,000,000,000,000
  	TB	Binary Terabyte   1,099,511,627,776

  This difference has arisen as a direct consequence of the fact
  that computers naturally talk in a binary (base 2) number system
  rather than the decimal (base 10) system preferred by mere mortals.

===8<=== CUT ===>8===

The rules would then reduce to "If the relevant condition applies,
append the text associated with the relevant DEFINE_ symbol to the help
text to be issued" and this could be done with an additional call to the
routine to extract the appropriate help text from the file. In addition,
your translation efforts would be restricted to just the COnfigure.help
file, and you wouldn't have to tweak the various configuration scripts
at the same time - and this would also ensure that the various config
scripts all used exactly the same help text.

> Although I thought there was an agreement that decimal kilobyte is
> kB, and binary kilobyte is KiB, decimal megabyte is MB, binary
> megabyte is MiB and so on, wasn't there?

That's the standard that the IEC has defined, and what this thread is
all about. Whether it'll get anywhere remains to be seen - ask Ted T'so
about the dangers of early adoption of proposed standards, and he'll
probably explain where his surname came from...

Best wishes from Riley.

Re: Configure.help editorial policy

[Dominik Mierzejewski]

On Thursday, 27 December 2001, Riley Williams wrote:
> Hi Dominik.
[snip] 
> > I second this. Being a translator of the file in question, I have to
> > deal with ten slightly different versions of "You may also compile
> > this as a module...". So I have ten slighlty different translations
> > of this text, too, in the name of accuracy.
> 
> I have to admit that I hadn't considered translators, but perhaps it
> could be made even simpler for you. How about having the help file start
> with a set of standard definitions, such as the following...
> 
> ===8<=== CUT ===>8===
[cut indeed :-)]
> ===8<=== CUT ===>8===
> 
> The rules would then reduce to "If the relevant condition applies,
> append the text associated with the relevant DEFINE_ symbol to the help
> text to be issued" and this could be done with an additional call to the
> routine to extract the appropriate help text from the file. In addition,
> your translation efforts would be restricted to just the COnfigure.help
> file, and you wouldn't have to tweak the various configuration scripts
> at the same time - and this would also ensure that the various config
> scripts all used exactly the same help text.

Nice, but - as Eric pointed out - there are many options where the
"available as module" text actually contains a module name, which
causes problems and makes your proposition insufficient for our needs.
A complete solution would require serious changes which Eric doesn't
want to introduce into a stable version.
 
> > Although I thought there was an agreement that decimal kilobyte is
> > kB, and binary kilobyte is KiB, decimal megabyte is MB, binary
> > megabyte is MiB and so on, wasn't there?
> 
> That's the standard that the IEC has defined, and what this thread is
> all about. Whether it'll get anywhere remains to be seen - ask Ted T'so
> about the dangers of early adoption of proposed standards, and he'll
> probably explain where his surname came from...

Perhaps I will. But I still don't understand why you insist on choosing
an opposite notation - that is xiB for decimal and xB for binary.
If at all, I would change the traditional convention to something
exactly opposite, i.e. xiB for binary and xB for decimal, because
M(mega),G(giga), etc. are standard SI units.

PS. Don't Cc: me next time you reply, ok? I'm subscribed to lkml.

-- 
"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Re: Configure.help editorial policy

[Riley Williams]

Hi Dominik.

>>> I second this. Being a translator of the file in question, I have to
>>> deal with ten slightly different versions of "You may also compile
>>> this as a module...". So I have ten slighlty different translations
>>> of this text, too, in the name of accuracy.

>> I have to admit that I hadn't considered translators, but perhaps it
>> could be made even simpler for you. How about having the help file
>> start with a set of standard definitions, such as the following...
>> 
>> ===8<=== CUT ===>8===

>[cut indeed :-)]

8-)

>> ===8<=== CUT ===>8===
>> 
>> The rules would then reduce to "If the relevant condition applies,
>> append the text associated with the relevant DEFINE_ symbol to the help
>> text to be issued" and this could be done with an additional call to the
>> routine to extract the appropriate help text from the file. In addition,
>> your translation efforts would be restricted to just the COnfigure.help
>> file, and you wouldn't have to tweak the various configuration scripts
>> at the same time - and this would also ensure that the various config
>> scripts all used exactly the same help text.

> Nice, but - as Eric pointed out - there are many options where the
> "available as module" text actually contains a module name, which
> causes problems and makes your proposition insufficient for our needs.
> A complete solution would require serious changes which Eric doesn't
> want to introduce into a stable version.

Curiously enough, the changes I proposed are ones that I have already
implemented for `make config` and have nearly implemented for `make
menuconfig` at the moment, and I expect to have `make xconfig` ready
early in the new year. The module name part of it is trivially easy to
implement once the code to add the basic DEFINE_MODULAR text is there,
and the only change will be that the module name is always appended to
the end of the boilerplate rather than sometimes being in the middle and
sometimes at the end as it is now.

Because of this, I have no respect for this objection at all, and I have
to say that I would have expected a much better argument from Eric (for
or against this proposal) considering his progranmming skills.

>>> Although I thought there was an agreement that decimal kilobyte
>>> is kB, and binary kilobyte is KiB, decimal megabyte is MB, binary
>>> megabyte is MiB and so on, wasn't there?

>> That's the standard that the IEC has defined, and what this thread
>> is all about. Whether it'll get anywhere remains to be seen - ask
>> Ted T'so about the dangers of early adoption of proposed standards,
>> and he'll probably explain where his surname came from...

> Perhaps I will.

He explained that to me some time ago, and it's a similar story to this.

> But I still don't understand why you insist on choosing an opposite
> notation - that is xiB for decimal and xB for binary.

{Shrug} The exact text is an entry in Configure.help (under the symbol
DEFINE_UNITS as it happens) so in that sense, the fact that I made a
mistake as a result of misunderstanding the proposal is irrelevant.

> If at all, I would change the traditional convention to something
> exactly opposite, i.e. xiB for binary and xB for decimal, because
> M(mega),G(giga), etc. are standard SI units.

No problem - just edit the entries in Configure.help to say whatever
is consistent with the usage of the acronyms elsewhere in that file.

> PS. Don't Cc: me next time you reply, ok? I'm subscribed to lkml.

Blame the SysAdmin for that - if I choose (R)eply to a message, it
always addresses it to whoever posted it, and CC's anybody listed
elsewhere. I don't get the ability to change the "To" field, only the
"Cc" field, so you will always get a copy of any reply I send to an
email you've posted.

Best wishes from Riley.

Re: Configure.help editorial policy

[Pavel Machek]

Hi!

> Nice, but - as Eric pointed out - there are many options where the
> "available as module" text actually contains a module name, which
> causes problems and makes your proposition insufficient for our needs.
> A complete solution would require serious changes which Eric doesn't
> want to introduce into a stable version.

That "module" help text deserves to *die*. Explanation of modules
should be provided *once* in CONFIG_MODULES.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: Configure.help editorial policy

[Daniel Phillips]

On December 27, 2001 12:34 am, Dominik Mierzejewski wrote:
> Although I thought there was an agreement that decimal kilobyte is kB,
> and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB
> and so on, wasn't there?

Not in my book.  As far as I'm concerned, somebody who tells me that one KB 
of memory or disk is 1,000 bytes is a liar.  When a disk manufacturer chooses 
to interpret KB in such a way as to make their disk seem bigger, I just say 
to myself "ok, they lied, that's what they do, they're in business and they 
don't care".  Now could we just ignore the self-serving doublespeak 
promulgated by greedy manufacturers, and continue using KB please?

Kilo, as in memory -> 1024
Kilo, as in distance or weight -> 1,000

Difficult?

/me wonders when the kibblebytes thread is going to end

--
Daniel

Re: Configure.help editorial policy

[Dominik Mierzejewski]

On Thursday, 27 December 2001, Daniel Phillips wrote:
> On December 27, 2001 12:34 am, Dominik Mierzejewski wrote:
> > Although I thought there was an agreement that decimal kilobyte is kB,
> > and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB
> > and so on, wasn't there?
> 
> Not in my book.  As far as I'm concerned, somebody who tells me that one KB 
> of memory or disk is 1,000 bytes is a liar.  When a disk manufacturer chooses 
> to interpret KB in such a way as to make their disk seem bigger, I just say 
> to myself "ok, they lied, that's what they do, they're in business and they 
> don't care".  Now could we just ignore the self-serving doublespeak 
> promulgated by greedy manufacturers, and continue using KB please?
> 
> Kilo, as in memory -> 1024
> Kilo, as in distance or weight -> 1,000
> 
> Difficult?
> 
> /me wonders when the kibblebytes thread is going to end

/me wonders when people will learn to read more carefully
(no offense intended) :-)

If you look at my post more closely, you'll see I used `kB' (that's small
k and capital B) for decimal kilobyte. I would never suggest using `KB'
(that's capital K and capital B) for it. I do agree that `KB' is traditionally
used for binary kilobytes, but what about MB, GB and so on? These _are_
ambiguous. I am in favour of using Ki, Mi and Gi for binary quantities.

-- 
"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Re: Configure.help editorial policy

[Martin Mares]

Hello!

> If you look at my post more closely, you'll see I used `kB' (that's small
> k and capital B) for decimal kilobyte. I would never suggest using `KB'
> (that's capital K and capital B) for it. I do agree that `KB' is traditionally
> used for binary kilobytes, but what about MB, GB and so on? These _are_
> ambiguous. I am in favour of using Ki, Mi and Gi for binary quantities.

Yes, the current MB/GB units are awfully ambiguous, but using Mi/Gi won't
cure the confusion as nobody will know whether MB/GB in that text means
the old-fashioned name of binary megabyte or the decimal megabyte according
to the new standard. Yes, the confusion might die out after a long period
of time of everybody switches to the new system, but I seriously doubt
it will happen in the near future.

It seems that the only way which is going to work is to create a new decimal
prefix for units of information as well. Not a particularly nice solution,
but probable the only working one.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Every program in development at MIT expands until it can read mail.

Re: Configure.help editorial policy

[Daniel Phillips]

On December 27, 2001 12:24 pm, Dominik Mierzejewski wrote:
> On Thursday, 27 December 2001, Daniel Phillips wrote:
> > Kilo, as in memory -> 1024
> > Kilo, as in distance or weight -> 1,000
> > 
> > Difficult?
> > 
> > /me wonders when the kibblebytes thread is going to end
> 
> /me wonders when people will learn to read more carefully
> (no offense intended) :-)
> 
> If you look at my post more closely, you'll see I used `kB' (that's small
> k and capital B) for decimal kilobyte. I would never suggest using `KB'
> (that's capital K and capital B) for it. I do agree that `KB' is 
> traditionally used for binary kilobytes, but what about MB, GB and so on? 
> These _are_ ambiguous. I am in favour of using Ki, Mi and Gi for binary 
> quantities.

So would you be happy with kB -> 1,000 bytes, and KB -> 1024 bytes?  Likewise
mB for 1,000,000 bytes and MB for 1048576 bytes?

Look, there's some precedent for it here:

   http://www.unc.edu/~rowlett/units/dictK.html
   "K - an informal abbreviation for one thousand used in expressions where 
   the unit is understood, such as "10K run" (10 kilometers) or "700K disk" 
   (700 kilobytes or kibibytes). Note that "K" is also the symbol for the 
   kelvin (see below). Also note that the symbol for the metric prefix kilo- 
   (1000) is actually k-, not K-."

If you believe that, then we don't have a problem, we never did:

  kB -> 1,000 bytes
  KB -> 1024 bytes

So, KiB is a silly fix for a problem that doesn't exist.  Let's not have that 
silliness creeping into our documentation, making it look silly too.

--
Daniel

Re: Configure.help editorial policy

[Matthias Andree]

On Fri, 28 Dec 2001, Daniel Phillips wrote:

> So would you be happy with kB -> 1,000 bytes, and KB -> 1024 bytes?  Likewise
> mB for 1,000,000 bytes and MB for 1048576 bytes?

No way. m is the SI prefix for milli, one thousandth. (1/1000). K is the
SI unit Kelvin (absolute temperature). Add to the confusion...

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

Re: Configure.help editorial policy

[Eric S. Raymond]

Riley Williams <rhw@memalpha.cx>:
> Alternatively, deal with this problem the same way the "This may also be
> built as a module..." comment is - either include it several thousand
> times in Configure.help or (better still) have the configuration tools
> spit it out automatically every time the need for it crops up. The
> following ruleset could easily be implemented even in the `make config`
> and `make menuconfig` parsers, and should be just as easy in CML2.
> Applying rule (1) will result in a considerable reduction in the size of
> the file Documentation/Configure.help as it currently stands.

I have said before; I am *not* going to make KB vs. KiB a
metaconfiguration option -- that would defeat the whole purpose of
having standard terminology.  That decision is final, and this subject
is closed.

The other is not a bad idea in principle.  I've thought before about
adding a feature that would add specified boilerplate to the help a
tristate symbol, for exactly the reasons you suggest.  Three things make
it a bit messy in practice.

One is that it would have to be expressed in the rulebase, ruther than
wired into the code.  I will not hardwire specific knowledge about
the Linux-specific properties of tristate symbols into the CML2 engine.
CML2 is already being used by at least two projects other than the kernel
and I know of a third that has it under consideration.  Therefore I must
preserve its generality.

The second problem is that the module boilerplate is not all
boilerplate.  Most instances contain the name of the generated module
object file.  Thus, ypo do this right, I would have to declare module
names in the rulebase, one for each tristate entry.  This implies a
significant extension to the CML2 language, which I'm reluctant to do
right now.  The design is stable.  I want it to stay that way until
(at least) well after CML2 achieves acceptance.

Third, I don't want to do major surgery on Configure.help until after
CML2 enters the tree.  Were I to do so, I would then have to maintain
two different versions of Configure.help.  That would be too big a pain.

Therefore, I'm going to defer consideration of this feature for now.
I certainly will not consider it until after CML2 goes into the 2.5 tree,
and may not consider it until there is some kind of final decision on
a 2.4 backport.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

When only cops have guns, it's called a "police state".
        -- Claire Wolfe, "101 Things To Do Until The Revolution" 

Re: Configure.help editorial policy

[Dominik Mierzejewski]

On Thursday, 27 December 2001, Eric S. Raymond wrote:
> Riley Williams <rhw@memalpha.cx>:
> > Alternatively, deal with this problem the same way the "This may also be
> > built as a module..." comment is - either include it several thousand
> > times in Configure.help or (better still) have the configuration tools
> > spit it out automatically every time the need for it crops up. The
> > following ruleset could easily be implemented even in the `make config`
> > and `make menuconfig` parsers, and should be just as easy in CML2.
> > Applying rule (1) will result in a considerable reduction in the size of
> > the file Documentation/Configure.help as it currently stands.
> 
> I have said before; I am *not* going to make KB vs. KiB a
> metaconfiguration option -- that would defeat the whole purpose of
> having standard terminology.  That decision is final, and this subject
> is closed.

With all due respect, Eric, I think you misunderstood. The way I understand
it, Riley is simply proposing to automatically _attach_ an explanation
of the KB/KiB confusion to help text of every option that uses these units.

> The other is not a bad idea in principle.  I've thought before about
> adding a feature that would add specified boilerplate to the help a
> tristate symbol, for exactly the reasons you suggest.  Three things make
> it a bit messy in practice.
> 
> One is that it would have to be expressed in the rulebase, ruther than
> wired into the code.  I will not hardwire specific knowledge about
> the Linux-specific properties of tristate symbols into the CML2 engine.
> CML2 is already being used by at least two projects other than the kernel
> and I know of a third that has it under consideration.  Therefore I must
> preserve its generality.

Fair enough. I don't think anyone would want you to make it Linux-specific.

> The second problem is that the module boilerplate is not all
> boilerplate.  Most instances contain the name of the generated module
> object file.  Thus, ypo do this right, I would have to declare module
> names in the rulebase, one for each tristate entry.  This implies a
> significant extension to the CML2 language, which I'm reluctant to do
> right now.  The design is stable.  I want it to stay that way until
> (at least) well after CML2 achieves acceptance.
> 
> Third, I don't want to do major surgery on Configure.help until after
> CML2 enters the tree.  Were I to do so, I would then have to maintain
> two different versions of Configure.help.  That would be too big a pain.
> 
> Therefore, I'm going to defer consideration of this feature for now.
> I certainly will not consider it until after CML2 goes into the 2.5 tree,
> and may not consider it until there is some kind of final decision on
> a 2.4 backport.

Again, these are all valid points. I guess you could just put this idea
far on the TODO list for now. :-)
Same thing applies to the first part of Riley's proposition, it would seem.

-- 
"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Re: Configure.help editorial policy

[Riley Williams]

Hi Dominik, Eric.

>>> Alternatively, deal with this problem the same way the "This may
>>> also be built as a module..." comment is - either include it several
>>> thousand times in Configure.help or (better still) have the
>>> configuration tools spit it out automatically every time the need
>>> for it crops up. The following ruleset could easily be implemented
>>> even in the `make config` and `make menuconfig` parsers, and should
>>> be just as easy in CML2. Applying rule (1) will result in a
>>> considerable reduction in the size of the file
>>> Documentation/Configure.help as it currently stands.

>> I have said before; I am *not* going to make KB vs. KiB a
>> metaconfiguration option -- that would defeat the whole purpose of
>> having standard terminology. That decision is final, and this
>> subject is closed.

No such suggestion has come from me.

> With all due respect, Eric, I think you misunderstood. The way I
> understand it, Riley is simply proposing to automatically _attach_
> an explanation of the KB/KiB confusion to help text of every option
> that uses these units.

That is exactly what I'm proposing Dominik - and the patches to do this
for `make config` are all ready for distribution, as are the basic
patches for Configure.help itself. I'm working on the patches for `make
menuconfig` at the moment, and will be doing those for `make xconfig`
once those are complete. Once that's done, CML2 will be the only config
tool not supporting it - and that's Eric's decision, not mine.

>> The other is not a bad idea in principle. I've thought before about
>> adding a feature that would add specified boilerplate to the help a
>> tristate symbol, for exactly the reasons you suggest. Three things
>> make it a bit messy in practice.
>>
>> One is that it would have to be expressed in the rulebase, ruther
>> than wired into the code. I will not hardwire specific knowledge
>> about the Linux-specific properties of tristate symbols into the
>> CML2 engine. CML2 is already being used by at least two projects
>> other than the kernel and I know of a third that has it under
>> consideration. Therefore I must preserve its generality.

> Fair enough. I don't think anyone would want you to make it
> Linux-specific.

I'm certainly not planning on doing so. The changes to `make config` are
on the basis that help requests from the "tristate" or "dep_tristate"
commands automatically adds whatever is attached to the help variable
DEFINE_MODULAR to the end of the help text for the option named. There's
absoultely nothing in that logic that has any more relevance to Linux
than to any other project using the same config toolsets.

>> The second problem is that the module boilerplate is not all
>> boilerplate. Most instances contain the name of the generated module
>> object file. Thus, to do this right, I would have to declare module
>> names in the rulebase, one for each tristate entry. This implies a
>> significant extension to the CML2 language, which I'm reluctant to
>> do right now. The design is stable. I want it to stay that way until
>> (at least) well after CML2 achieves acceptance.

This is already dealt with in the design I'm using. It requires that the
statement naming the module appears as the last line of the boilerplate
after the standard text, but that is already the case for several of the
uses of the "I can be a module" text, and the others can easily be
converted to use the same.

>> Third, I don't want to do major surgery on Configure.help until
>> after CML2 enters the tree. Were I to do so, I would then have to
>> maintain two different versions of Configure.help. That would be too
>> big a pain.

>> Therefore, I'm going to defer consideration of this feature for now.
>> I certainly will not consider it until after CML2 goes into the 2.5
>> tree, and may not consider it until there is some kind of final
>> decision on a 2.4 backport.

You may soon be in the position of having to maintain two different
versions of Configure.help if you don't implement this feature, rather
than if you do, as the code to implement it in the existing config tools
is well under way, and `make config` is ready for testing.

> Again, these are all valid points. I guess you could just put this
> idea far on the TODO list for now. :-) Same thing applies to the
> first part of Riley's proposition, it would seem.

Alternatively, you could have a look at what is actually required. Here
is a summary of the requirements that proved necessary for `make config`
to add boilerplate text to those options that can be selected as being
modular in the current tree:

 1. The help function is split up into three...

	extract_help help-var

		This extracts the help text associated with the
		help variable specified.

	extract_all_help help-var...

		This extracts the help text associated with all
		of the help variables named, and appends it all
		end to end in the order specified. It does so by
		calling extract_help for each argument in turn.

	help help-var...

		This passes its arguments to extract_all_help and
		then arranges for the resulting text to be shown
		to the user.

 2. The places in the tristate and dep_tristate functions where the help
    function is called get an extra fixed parameter of DEFINE_MODULAR in
    each case.

 3. The relevant help text is added to the Configure.help file.

That's it - the sum total changes required. Essentially the same changes
are needed to get `make menuconfig` to do the same thing, but step (2)
is a little more tricky in this case. I haven't looked at `make xconfig`
yet, but that is unlikely to differ much from the above.

Once these changes are made, the additions to deal with adding other
boilerplate for technical acronyms appropriate to the project in
question are restricted to the Configure.help file itself and the
extract_all_help function included above, and nothing else will need
changing.

Incidentally, the changes to Configure.help in the current patches use
empty boilerplate text, so the addition of the relevant lines in
Configure.help to prevent it spewing out error messages results in a
Configure.help file compatible with both the old and revised system.

Best wishes from Riley.

Re: Configure.help editorial policy

[Kai Henningsen]

rhw@MemAlpha.cx (Riley Williams)  wrote on 26.12.01 in <Pine.LNX.4.21.0112261718150.32161-100000@Consulate.UFP.CX>:

> 			Symbol	Designation	  Number of Bytes
> 			~~~~~~	~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~
> 			KiB	Decimal Kilobyte  1,000
> 			KB	Binary Kilobyte   1,024
>
> 			MiB	Decimal Megabyte  1,000,000
> 			MB	Binary Megabyte   1,048,576
>
> 			GiB	Decimal Gigabyte  1,000,000,000
> 			GB	Binary Gigabyte   1,073,741,824
>
> 			TiB	Decimal Terabyte  1,000,000,000,000
> 			TB	Binary Terabyte   1,099,511,627,776

Uh, that's all wrong. The "i" versions are *binary*, the non-"i" versions  
are *decimal*. Completely backward.

MfG Kai

Re: Configure.help editorial policy

[Riley Williams]

Hi Kai.

> rhw@MemAlpha.cx (Riley Williams) wrote on 26.12.01...

>>			Symbol	Designation	  Number of Bytes
>>			~~~~~~	~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~
>>			KiB	Decimal Kilobyte  1,000
>>			KB	Binary Kilobyte   1,024
>>
>>			MiB	Decimal Megabyte  1,000,000
>>			MB	Binary Megabyte   1,048,576
>>
>>			GiB	Decimal Gigabyte  1,000,000,000
>>			GB	Binary Gigabyte   1,073,741,824
>>
>>			TiB	Decimal Terabyte  1,000,000,000,000
>>			TB	Binary Terabyte   1,099,511,627,776

> Uh, that's all wrong. The "i" versions are *binary*, the non-"i"
> versions are *decimal*. Completely backward.

No problem. Just swap the relevant labels over in the first column.

As far as the tweak I proposed (and which I've finished creating for
`make config` and have nearly finished for `make menuconfig` as well),
the whole entry, along with that for any other "Technical Acronyms"
(TM) that one wishes to define in the same way, are simple entries at
the top of Configure.help and can easily be edited by anybody willing
to apply fingers to keycaps.

The only question I'm really interested in hearing answers to is this:

	What other acronyms used in Configure.help could use
	defining in this manner for kernel newbies?

Any takers willing to supply both the acronym and a definition thereof?

Best wishes from Riley.

Re: Configure.help editorial policy

[Cameron Simpson]

On Sun, Dec 23, 2001 at 08:53:41PM -0200, Rik van Riel <riel@conectiva.com.br> wrote:
| On Mon, 24 Dec 2001, Cameron Simpson wrote:
| > Using KB in places where precision matters puts us all into case #4
| > below, because people think they know what KB means, but it means
| > different things to different people, and so people don't realise they
| 
| I take it this is your way of volunteering to always
| keep all kernel documentation accurate as well as
| answer questions from newbies who've never seen
| 'KiB' before ? ;)

Hmm. Not my plan at the time of typing, no.
But KB _is_ ambiguous. KiB is not (and it's ugliness is actually an advantage
here - it's less likely to be misused by people who've not seen the definition).

Just out of curiosity, is there anywhere in the kernel space where KB (et al)
is _not_ used to mean a power of 2 value?
-- 
Cameron Simpson, DoD#743        cs@zip.com.au    http://www.zip.com.au/~cs/

When you're all dressed up and no place to go.	- B.H. Burt (19th cent)

Re: Configure.help editorial policy

[Rik van Riel]

On Mon, 24 Dec 2001, Cameron Simpson wrote:

> | I take it this is your way of volunteering to always
> | keep all kernel documentation accurate as well as
> | answer questions from newbies who've never seen
> | 'KiB' before ? ;)
>
> Hmm. Not my plan at the time of typing, no.
> But KB _is_ ambiguous. KiB is not (and it's ugliness is actually an
> advantage here - it's less likely to be misused by people who've not
> seen the definition).

Now replace 'misused' by 'used'.  I can guarantee you
that half the documentation will go on using KB while
the other half (if that) has KiB.

It doesn't help anything if there are more precise
terms when they're used inconsistently. Somebody will
have to check and fix this, continuously.

regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

http://www.surriel.com/		http://distro.conectiva.com/

Re: Configure.help editorial policy

[Eric S. Raymond]

Rik van Riel <riel@conectiva.com.br>:
> It doesn't help anything if there are more precise
> terms when they're used inconsistently. Somebody will
> have to check and fix this, continuously.

The situation is not as bad as you think, Rik.  I grepped; the Documentation
subtree only has 17 instances of KB, of which about 6 clearly don't need
correcting as they really are referring to disk capacities.  The patch to
fix these references would not be large.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

...Virtually never are murderers the ordinary, law-abiding people
against whom gun bans are aimed.  Almost without exception, murderers
are extreme aberrants with lifelong histories of crime, substance
abuse, psychopathology, mental retardation and/or irrational violence
against those around them, as well as other hazardous behavior, e.g.,
automobile and gun accidents."
        -- Don B. Kates, writing on statistical patterns in gun crime

Re: Configure.help editorial policy

[Mike Galbraith]

On Mon, 24 Dec 2001, Cameron Simpson wrote:

> On Fri, Dec 21, 2001 at 07:17:45PM -0200, Rik van Riel <riel@conectiva.com.br> wrote:
> | On Fri, 21 Dec 2001, Eric S. Raymond wrote:
> | > What, and *encourage* non-uniform terminology?  No, I won't do that.
> | > Better to have a single standard set of abbreviations, no matter how
> | > ugly, than this.
> |
> | Last I checked the purpose of language was _communication_.
> | Better use words people understand.
>
> Well, what we have is KB, which people _think_ they understand, but do not.
> And KiB, which is ugly but well defined, albeit less known (at present).
>
> | Also, the kB vs KiB mess is so ambiguous and complex that
> | it virtually guarantees that the _writers_ of documentation
> | will get it wrong occasionally and only confuse the readers
> | more.
>
> KiB is not ambiguous. KB demonstrably is.
> And therefore KB is NOT useful for communication, _especially_ technical
> communication.

Grep around in your RFC directory, and apply your argument.  The KiB
definition will _create_ ambiguity in technical communication which
did not exist before.

	-Mike

Re: Configure.help editorial policy

[Gábor Lénárt]

On Mon, Dec 24, 2001 at 07:25:44AM +0100, Mike Galbraith wrote:
> > Well, what we have is KB, which people _think_ they understand, but do not.
> > And KiB, which is ugly but well defined, albeit less known (at present).
> >
> > | Also, the kB vs KiB mess is so ambiguous and complex that
> > | it virtually guarantees that the _writers_ of documentation
> > | will get it wrong occasionally and only confuse the readers
> > | more.
> >
> > KiB is not ambiguous. KB demonstrably is.
> > And therefore KB is NOT useful for communication, _especially_ technical
> > communication.
> 
> Grep around in your RFC directory, and apply your argument.  The KiB
> definition will _create_ ambiguity in technical communication which
> did not exist before.

Agreed. I think almost technical guys assumed that 'KB' (or kB, or kb, or
something ;-) IS 1024 bytes. Know even they starting to loose their
belief about old one, and that new and 'strange' 'KiB'. Imho '1000 bytes =
1 kbytes' was only used by some tricky hardware vendors to trick their
costumers (they could show bigger values ...). But even my sister knows
that when someone's speaking about computers, 'kilo' means 1024, not 1000.

It's like when we declared that direction of electrical current is from
positive to negative. Yes, we CAN change it now, because we know that it's
not the right direction of electrons in real.

So, if the 'technical world' already assumed (imho) that 'kilo' is 1024
in computer technology then we shouldn't change it now ...

- Gabor

Re: Configure.help editorial policy

[Stephen Satchell]

At 07:17 PM 12/21/01 -0200, Rik van Riel wrote:
>As a last point, we shouldn't forget about the inconsistent
>way in which the marketing departments of hardware vendors
>apply these units to their products. In many cases binary
>and decimal units are mixed, leading to something which is
>impossible to "get right".  Disk space would be one example
>of this, but I'm sure there are more.
>
>regards,
>
>Rik

OK, how about this silly suggestion:  DON'T USE ABBREVIATIONS IN DOCUMENTATION.

For example, let me propose an "edit" to the text that has been appearing 
in this thread to eliminate the ambiguity:

 > # Choice: himem
 > High Memory support
 > CONFIG_NOHIGHMEM
 >   Linux can use up to 64 * 2^30 bytes (64 gigabytes) of physical memory 
on x86 systems.
 >   However, the address space of 32-bit x86 processors is only 4 * 2^30 
bytes (four gigabytes)
 >   large. That means that, if you have a large amount of
 >   physical memory, not all of it can be "permanently mapped" by the
 >   kernel. The physical memory that's not permanently mapped is called
 >   "high memory".
 >
 >   If you are compiling a kernel which will never run on a machine with
 >   more than 960 * 2^20 bytes (960 megabytes) of total physical RAM, 
answer "off" here
 >   (default choice and suitable for most users). This will result in a
 >   3:1 split: each process sees a 3 * 2^30 byte (three gigabyte)
 >   virtual memory space, and the remaining 1 * 2^30 (one gigabyte) 
of  virtual memory
 >   space is used by the kernel to permanently map as much physical memory
 >   as possible.
 >
 >   If the machine has between one 2^30 bytes and four 2^30 bytes of 
physical RAM, then
 >   answer "4GB" here.

In this edit, the only place where the abbreviation "GB" appears is in the 
symbol definition space.  Configuration symbols are by custom all 
upper-case, so the standard for capitalization as specified in SI is 
violated in the interest of a symbol space that is consistent.

What kills me is that people forget the origin of KB as a standard 
designation for "kilobyte" in the first place.  Does anyone remember the 
KSR-33 teletype, the early dot-matrix printers, and other output devices 
that output only upper-case characters?  Maybe you youngsters don't recall 
that lower-case character devices were EXPENSIVE -- I still have a TI 
Silent 700 terminal that did output lower-case when connected to systems 
that understood the full ASCII alphabet, but those systems were few and far 
between in business applications -- upper-case-only was "good enough."  How 
about tab machines that never did have lower-case, such as the 407 printing 
accounting machine?

It got worse when you need to differentiate between "bytes" and "bits" 
because you didn't have the luxury of using "B" for "byte" and "b" for 
"bit" -- so that's why you see in legacy documentation a lone "K" for 
"kilobit".

Have you noticed that some schematic packages *still* don't support lower 
case for all output devices?

So now you know where the common usage of K, KB, MB, GB and the rest came 
from -- limitations in the early tools for doing electronic documentation 
of computer systems.  Now, some of you may scream that we no longer have 
those limitations -- but what are you going to do with the vast body of 
written knowledge that is written using the accepted abbreviations of the 
time?  Unless someone is going to go back and re-edit 30 years of academic 
papers, journal articles, and legacy documentation of equipment already in 
use (can you say telephone systems?) then any argument about re-doing 
abbreviations "for esthetic reasons" is either pointless or yet another 
cause for confusion.  Especially as this has every stigmata of becoming a 
religious war.

So here we are, campers, arguing about abbreviations when in fact there is 
no real NEED for abbreviations outside of the config symbol space.  Why not 
just take the few extra bytes (they are not a penny each anymore) to spell 
out what you really mean?  Why do we need MB or mB or MiB for 
"megabyte"?  Sometimes we get so wrapped up in our abbreviations that we 
lose sight of the fact that the original job of a HELP FILE is to HELP, to 
COMMUNICATE really useful information to the person trying to configure 
their Linux kernel to a specific purpose.  Don't forget that the audience 
for configure.help goes far beyond the 30K of us (oops, I used an 
abbreviation -- sorry) that work with this sort of stuff on a continuing 
basis -- members of the priesthood, if you will.  What would your mother or 
grandmother say if confronted with this sort of stuff?  Is it necessary to 
obfuscate your meaning to the unwashed?  (Even my edit caters to the expert 
to some extent -- I admit it.)

Frankly, if the reason you use abbreviations is because you type slowly, I 
can't feel any pain for you.  There are lots of courses, sources, and even 
gaming software around the world designed to teach you to type on a QWERTY 
keyboard, far too many for me to feel any pain at all about your lack -- if 
you are too lazy to learn a necessary skill for your craft or hobby, then 
you might want to think about finding another career or passtime.

Oh, before someone quotes my Slashdot interview and says "Hey, it's easy 
for you, you are a professional writer" I'll tell you that my high school 
summer-school typing course increased my keypunching productivity by a 
factor of 15 while I was still a hobbyist, and permitted me to make full 
use of that KSR-33 and glass TTY and so forth as a professional...and that 
I was a programmer for 12 years before I wrote my first article for 
money.  (I hope none of you EVER see that first article, which thank the 
deity of your choice never saw publication.)

Look, I'm sorry if this comes across as harsh, but I can't believe you 
people WANT to alienate users for the sake of an obscurity.  Please 
CONSIDER YOUR AUDIENCE -- ALL of them.  Not just the top one-half of one 
percent.  The worst sin any writer -- professional or amateur, technical or 
popular, fiction or non-fiction -- can do is lose the reader.  And that, 
people, is what you are doing with this debate.

Stephen Satchell

Re: Configure.help editorial policy

[Eric S. Raymond]

Stephen Satchell <list@fluent2.pyramid.net>:
> What kills me is that people forget the origin of KB as a standard 
> designation for "kilobyte" in the first place.  Does anyone remember the 
> KSR-33 teletype, the early dot-matrix printers, and other output devices 
> that output only upper-case characters?  Maybe you youngsters don't recall 
> that lower-case character devices were EXPENSIVE -- I still have a TI 
> Silent 700 terminal that did output lower-case when connected to systems 
> that understood the full ASCII alphabet, but those systems were few and far 
> between in business applications -- upper-case-only was "good enough."  How 
> about tab machines that never did have lower-case, such as the 407 printing 
> accounting machine?

That's right, kids.  And furthermore, we had to walk to the computer
center uphill.  Both ways.  In the snow.  Empty out the chad buckets
twice a day.  And crimp backplane wires with our teeth, while the
machine was *on*!

> So here we are, campers, arguing about abbreviations when in fact there is 
> no real NEED for abbreviations outside of the config symbol space.  Why not 
> just take the few extra bytes (they are not a penny each anymore) to spell 
> out what you really mean?

Alas, this is not a solution -- because expanding all the abbrevs would
just get us into the argument over "kilobytes" vs.  "kibibytes".  And,
while I can just barely make myself choke down "KiB" for the sake of
clarity, "kibibytes" is beyond my tolerance.  Aaarrggghhh....
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
	-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794

Re: Configure.help editorial policy

[Nicholas Knight]

On Friday 21 December 2001 02:53 pm, Stephen Satchell wrote:
> At 07:17 PM 12/21/01 -0200, Rik van Riel wrote:
> >As a last point, we shouldn't forget about the inconsistent
> >way in which the marketing departments of hardware vendors
> >apply these units to their products. In many cases binary
> >and decimal units are mixed, leading to something which is
> >impossible to "get right".  Disk space would be one example
> >of this, but I'm sure there are more.
> >
> >regards,
> >
> >Rik
>
> OK, how about this silly suggestion:  DON'T USE ABBREVIATIONS IN
> DOCUMENTATION.

While pure reason suddenly made me realize that we really shouldn't use 
abbreviations in docs, thus rendering MiB vs MB moot, this still leaves 
us with another problem:

Gigs or Gibs? Kibbles or Kilos? You're still going to end up with 
confusion, because outside of the (limited number of) people who heard 
about this "international" standard, nobody knows what the heck a 
kibibyte is.

Re: Configure.help editorial policy

[T. A.]

    After reading this longish thread, or waste of bandwidth as you may look
at it, I wonder if people have realized how familiar this entire argument
is.  Seams like we have another bunch of elitist snobs trying to tell the
common folk what is or isn't standard.  Wasn't that long ago that teachers
were punishing students for using the word "ain't" because it wasn't
standard Engish despite it being used by virtually everyone else out in the
real world.  Now last I heard a few years back, from an Engish teacher at
that, was that "ain't" was now fully allowed.  Guess it became standard.
Perhaps some people should come off of their high horse and hang around with
the common people for a bit.  For virtually everybody, including my grandma,
KB == kilobytes, MB == megabytes, and GB == Gigabytes.  Memory-wise, at
least, kilos == 1024, Megas == 1024 * 1024.  And as far as network speeds
I've always seen Kbits, Mbits, or Gbits (with lowercase or uppercase 'B').
For all practical purposes its always been like that.  And while computers
haven't been around for ages yet its been around long enougth that the new
standards complient kernel source will be out of sync with the countless
amounts of documentation (of all kinds) out there as well as the standard
operating procedure in the real world.

    Now aren't there better things to do in the world rather that going
around confusing and chastizing people with more talk of "Kibbles and Bits"
and "Men In Black".  Not that pointless flamewars aren't always fun.

    I already gotta put up with Python just to configure my kernel, now
this, and I read he's going after my symbols next.

    Sorry if this seams a bit terse (I did tone it down a lot), however I
was hoping to get some help debugging my lockup problem on the VP6 instead
of corrections from language nannies informing me that the common folk and I
have been speaking and writing incorrectly all this time.  Yes baby, there
is such a thing as a kiwibit.

Re: Configure.help editorial policy

[Rob Landley]

On Friday 21 December 2001 01:40 pm, Eric S. Raymond wrote:
> David Garfield <garfield@irving.iisd.sra.com>:
> > Eric S. Raymond writes:

> > Choice of kB vs KB vs KiB vs KKB could also be used in some places in
> > the kernel.  For instance, /proc/meminfo currently shows "kB".
>
> What, and *encourage* non-uniform terminology?  No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.

 find . -name "*.?" | xargs grep MiB | wc
     46 lines, half of which seem to live in "jedec_probe.c".

 find . -name "*.?" | xargs grep -w MB | wc
    302 lines.  And that's just upper case, whole word, not "MBs" or "Mb" or 
any other fun little variation...

 find . -name "*.?" | xargs grep -i MEGABYTE | wc
     31 lines.

 find . -name "*.?" | xargs grep -i MEBIBYTE | wc
      1 line, and it's a comment saying it's NOT being used (along with one 
of the MiB hits).

If you're going with a uniform terminology argument, you should drop MiB 
altogether.  Unless you want to submit a patch to the kernel to standardize 
all the other occurences everywhere else? :)

Rob

Re: Configure.help editorial policy

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> If you're going with a uniform terminology argument, you should drop MiB 
> altogether.  Unless you want to submit a patch to the kernel to standardize 
> all the other occurences everywhere else? :)

Rob, you haven't looked at the actual changes I made, have you?

If you had, you'd realized that I have not introduced "kibibyte", 
or "mebibyte" or any of those terms anywhere.  The Configure.help
changes involve only the IEC-standard abbreviations KiB, MiB, and GiB.

Try criticizing what I actually did, as opposed to what you merely *assume* 
I did.  You'll be more convincing that way.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The best we can hope for concerning the people at large is that they be
properly armed."
        -- Alexander Hamilton, The Federalist Papers at 184-188

Re: Configure.help editorial policy

[Rob Landley]

On Saturday 22 December 2001 04:58 am, Eric S. Raymond wrote:
> Rob Landley <landley@trommello.org>:
> > If you're going with a uniform terminology argument, you should drop MiB
> > altogether.  Unless you want to submit a patch to the kernel to
> > standardize all the other occurences everywhere else? :)
>
> Rob, you haven't looked at the actual changes I made, have you?

I looked at the patch, which was actually fairly small.  But it didn't seem 
to be the only potential change along these lines, and I thought I'd object 
now and avoid the rush. (Yeah I know, "too late"...)

> If you had, you'd realized that I have not introduced "kibibyte",
> or "mebibyte" or any of those terms anywhere.

Maybe not in this patch, but I got the impression it signified a policy 
decision to change terminology and stick with the new one uniformly, at least 
in the help files.

Since then, another part of the thread has indicated (and the help file now 
says at the top) that the help file will say "binary megabytes" instead of 
mebibytes. "mebibytes" for binary megabytes?  If this policy was there in the 
original patch, I missed it.

> The Configure.help
> changes involve only the IEC-standard abbreviations KiB, MiB, and GiB.

I didn't know the ISO was merely rubber-stamping somebody else's standard, 
but I can't say I'm suprised.  Well, I suppose I'm all for "catalyzing 
progress in the information-industry and university communities", as the 
IEC's web page says (isn't google fun).  Gee, we'd never be able to figure 
out what to call things if these guys weren't around to make decisions for 
us...

Specifically, it seems they adpoted it as amendment 2 to IEC 60027-2, 
standardizing kibi, mebi, gibi, tebi, pebi, and exbi, with symbols Ki, Mi, 
Gi, Ti, Pi, and Ei.  (A PiB obvioiusly and unambiguously being the number of 
bytes required to hold an accurate floating point representation of Pi.  :)

This does not, in fact, remove the term "mebibytes" to the discussion.  It 
means the current policy is to selectively follow part of the standard, and 
explicitly ignore the rest of the standard as too ugly to live.  The prefix 
"mebi" is, in fact, explicitly part of the IEC standard the ISO AOLed, thus 
"mebibytes" is what "MiB" is short for.  (I wasn't even the one to introduce 
the term mebibytes into this thread.)

> Try criticizing what I actually did, as opposed to what you merely *assume*
> I did.  You'll be more convincing that way.

Ooh, why start now? :)

What you did was announce a new editorial policy.  Look at the subject line 
of the thread.  That's noticeably larger than a single patch.

My objection is that this switch does not seem to be based on improving the 
understandability of the documentation to that documentation's intended users 
(who, on the whole, consider "7K RAM" to be sufficiently unambiguous without 
even a B).  We've always used domain based differentiation (ram is binary, 
networking is decimal, disk needs to be specified because manufacturers lie 
for marketing reasons).  This seems to be a solution in search of a problem.

Now I agree that as numbers get bigger the distinction matters more (2% per 
kilobyte, 5% per megabyte, 7% per gigabyte, and almost 10% per terabyte).  
But the binary or decimal nature of the measurement has always been 
application specific up until now, and I'm curious why that's suddenly not 
good enough anymore.  The new method is a much more fine-grained level of 
detail which is, in fact, easier to screw up.

Is the help file even currently accurate with this extra distinction made?  
Look at NCR53c8xx SCSI support, which says the transfer rate is 80 MB/s.  Is 
that really, accurately a million decimal megabytes per second?  Is it 80.3 
or 80.7?  Has anyone ever cared to confirm this who was not capable of 
looking in the code to determine the answer?  Is there a POINT in specifying 
"Men in Black" units everywhere that is currently generally accepted practice 
to default to binary (although using i for bInary makes as much sense as 
using i for decImal, if you ask me)?

The switch appears to be based on the assumption that conformance to a 
standard issued by a bureaucratic body is arbitrarily better than established 
practice.  And yet that's not what it does, because it refuses to use the 
long form...

The help file STILL uses the prefix "mega" without specifying binary or 
decimal in at least these sections:

Synchronous transfer frequency in MHz
Enable kernel debugging symbols
Virtual memory file system support
Remote GDB kernel debugging
GDB Stub kernel debug

Just looking at the first, do you really think saying "binary mega-transfers" 
is going to be less confusing?  How about "mebi-transfers", people will know 
right off what THAT means without having to look it up...

And you've already implied you want to change the symbol set for 
CONFIG_NINO_4MB and such.  How deeply into the kernel will these changes go?

The patch is a can of worms, and abandoning the current domain-based 
defaults (ram is binary, network is decimal, disk needs to pick one) is not 
something I see as an improvement.  But you're the maintainer...

Rob

Re: Configure.help editorial policy

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> Is the help file even currently accurate with this extra distinction made?  

Not completely, but that's because in some cases I don't know whether decimal
or binary multiples are involved.  Where that is the case I have left the
ambiguous terminology in place.

> And you've already implied you want to change the symbol set for 
> CONFIG_NINO_4MB and such.  How deeply into the kernel will these changes go?

I don't know yet.  I can only clean up the bits for which I am maintainer.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The spirit of resistance to government is so valuable on certain occasions, 
that I wish it always to be kept alive.  It will often be exercised when 
wrong, but better so than not to be exercised at all. I like a little 
rebellion now and then.	-- Thomas Jefferson, letter to Abigail Adams, 1787

Re: Configure.help editorial policy

[Kai Henningsen]

landley@trommello.org (Rob Landley)  wrote on 23.12.01 in <20011223174227.NCJM25224.femail12.sdc1.sfba.home.com@there>:

> But the binary or decimal nature of the measurement has always been
> application specific up until now, and I'm curious why that's suddenly not
> good enough anymore.

Would you want to live in a world where 1 litre milk was either more or  
less than 1 litre water?

Why, then, do you think it was *ever* "good enough"?

I certainly never thought that 1 GB disk being a different number of  
usable bits than 1 GB RAM was ever "good enough". *I* considered that to  
be plain old fraud.

> The switch appears to be based on the assumption that conformance to a
> standard issued by a bureaucratic body is arbitrarily better than
> established practice.  And yet that's not what it does, because it refuses
> to use the long form...

"Established practice" is that these prefixes are decimal. It has been  
established practice before the first electronic computer was even built.

> The patch is a can of worms, and abandoning the current domain-based
> defaults (ram is binary, network is decimal, disk needs to pick one) is not
> something I see as an improvement.  But you're the maintainer...

I see it as an unequivocal improvement, even though I don't like the  
actual choice of prefix. But then, I never liked "Exa" or "Peta" either  
...

MfG Kai

Re: Configure.help editorial policy

[David Woodhouse]

garfield@irving.iisd.sra.com said:
> 
>   If the machine has between 1 and 4 Gigabytes physical RAM, then
>   answer "4GB" here.
> Note "3GiB/1GiB" and "4GB".

That's because the config option is named like that, and wasn't corrected 
when the help text was. Maybe the following would be better:

   If the machine has between 1 and 4 Gigabytes physical RAM, then
   answer "4GB"(sic) here.


--
dwmw2

Re: Configure.help editorial policy

[Kai Henningsen]

riel@conectiva.com.br (Rik van Riel)  wrote on 21.12.01 in <Pine.LNX.4.33L.0112211913360.28489-100000@duckman.distro.conectiva>:

> On Fri, 21 Dec 2001, Eric S. Raymond wrote:
>
> > What, and *encourage* non-uniform terminology?  No, I won't do that.
> > Better to have a single standard set of abbreviations, no matter how
> > ugly, than this.
>
> Last I checked the purpose of language was _communication_.
>
> Better use words people understand.

People in general *don't* understand the current so-called "established  
practice", because not only is it inconsistent with all of the rest of the  
world, it's also inconsistent with itself.

A few specialists such as you or me understand those terms in those few  
areas we are familiar with.

> Also, the kB vs KiB mess is so ambiguous and complex that

What is ambiguous or complex about it?

> As a last point, we shouldn't forget about the inconsistent
> way in which the marketing departments of hardware vendors
> apply these units to their products.

Do you know of *any* case where KiB and friends have been applied  
inconsistently? You may not be arguing the side you seem to want to be  
arguing here ...

> In many cases binary
> and decimal units are mixed, leading to something which is
> impossible to "get right".  Disk space would be one example
> of this, but I'm sure there are more.

I have no idea why you think it is impossible to get right. It is fairly  
easy to get right. Of course, that means using different numbers, but then  
I've been saying for more than a decade that those numbers are a lie.


MfG Kai

Re: Configure.help editorial policy

[David Weinehall]

On Fri, Dec 21, 2001 at 01:43:29PM -0500, David Garfield wrote:
> Eric S. Raymond writes:
>  > David Garfield <garfield@irving.iisd.sra.com>:
>  > > Another option: maybe the choice of KB vs KiB vs KKB should be a
>  > > configuration choice.
>  > 
>  > You *must* be joking.
>  > 
>  > Please tell me you're joking.
> 
> No, I'm serious.  I will understand if CML2 does not support
> meta-configuration.  A configuration choice as I described above could
> be viewed as a minor facet of a language configuration choice.
> (Should kernel configuration be internationalized or at least
> internationalizable?)
> 
> Choice of kB vs KB vs KiB vs KKB could also be used in some places in
> the kernel.  For instance, /proc/meminfo currently shows "kB".

Whatever the choice ends up being, KB is always incorrect, unless you
intend to specify some strange formula where the number of bytes (B)
combined with the temperature in Kelvin (K) has anything to do with
things.



/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Configure.help editorial policy

[Keith Owens]

On Fri, 21 Dec 2001 20:12:59 +0100, 
David Weinehall <tao@acc.umu.se> wrote:
>Whatever the choice ends up being, KB is always incorrect, unless you
>intend to specify some strange formula where the number of bytes (B)
>combined with the temperature in Kelvin (K) has anything to do with
>things.

The KB unit has been reserved for the temperature of a linux-kernel
flamewar multiplied by the number of bytes of network traffic wasted on
that flame-war.

:)

Re: Configure.help editorial policy

[David Garfield]

Eric S. Raymond writes:
 > What, and *encourage* non-uniform terminology?  No, I won't do that.
 > Better to have a single standard set of abbreviations, no matter how
 > ugly, than this.

Valid argument.  I will point out that the current version is
non-uniform.  Quoting from Configure.help :


> # Choice: himem
> High Memory support
> CONFIG_NOHIGHMEM
>   Linux can use up to 64 Gigabytes of physical memory on x86 systems.
>   However, the address space of 32-bit x86 processors is only 4
>   Gigabytes large. That means that, if you have a large amount of
>   physical memory, not all of it can be "permanently mapped" by the
>   kernel. The physical memory that's not permanently mapped is called
>   "high memory".
> 
>   If you are compiling a kernel which will never run on a machine with
>   more than 960 megabytes of total physical RAM, answer "off" here
>   (default choice and suitable for most users). This will result in a
>   "3GiB/1GiB" split: 3GiB are mapped so that each process sees a 3GiB
>   virtual memory space and the remaining part of the 4GiB virtual memory
>   space is used by the kernel to permanently map as much physical memory
>   as possible.
> 
>   If the machine has between 1 and 4 Gigabytes physical RAM, then
>   answer "4GB" here.


Note "3GiB/1GiB" and "4GB".

--David

Re: Configure.help editorial policy

[Eric S. Raymond]

David Garfield <garfield@irving.iisd.sra.com>:
> Eric S. Raymond writes:
>  > What, and *encourage* non-uniform terminology?  No, I won't do that.
>  > Better to have a single standard set of abbreviations, no matter how
>  > ugly, than this.
> 
> Valid argument.  I will point out that the current version is
> non-uniform.  Quoting from Configure.help :
> 
> 
> > # Choice: himem
> > High Memory support
> > CONFIG_NOHIGHMEM
> >   Linux can use up to 64 Gigabytes of physical memory on x86 systems.
> >   However, the address space of 32-bit x86 processors is only 4
> >   Gigabytes large. That means that, if you have a large amount of
> >   physical memory, not all of it can be "permanently mapped" by the
> >   kernel. The physical memory that's not permanently mapped is called
> >   "high memory".
> > 
> >   If you are compiling a kernel which will never run on a machine with
> >   more than 960 megabytes of total physical RAM, answer "off" here
> >   (default choice and suitable for most users). This will result in a
> >   "3GiB/1GiB" split: 3GiB are mapped so that each process sees a 3GiB
> >   virtual memory space and the remaining part of the 4GiB virtual memory
> >   space is used by the kernel to permanently map as much physical memory
> >   as possible.
> > 
> >   If the machine has between 1 and 4 Gigabytes physical RAM, then
> >   answer "4GB" here.
> 
> 
> Note "3GiB/1GiB" and "4GB".

Yeah, that's because I can't touch the symbol namespace.  Not yet, anyway.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

He that would make his own liberty secure must guard even his enemy from
oppression: for if he violates this duty, he establishes a precedent that
will reach unto himself.	-- Thomas Paine

Re: Configure.help editorial policy

[Mike Jagdis]

Eric S. Raymond wrote:

> I guess it's a pretty quiet week in kernel-hacker land.  Must be,
> otherwise people would have better things to do than argue over KB
> vs. KiB.  The alternative would be to conclude that significant
> portions of the lkml population prefer flaming to coding, and that
> couldn't possibly be the case, could it?


Surely not?

> However.  In the *absence* of a clear consensus, I will follow best
> practices.  Best practice in editing a technical or standards document
> is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
> to use, follow and reference international standards.


"Best" practice? That's the *only* practice! Guesswork and assumption
has no place in technical documentation!

				Mike

Re: Configure.help editorial policy

[Rob Landley]

On Friday 21 December 2001 05:36 am, Mike Jagdis wrote:
> Eric S. Raymond wrote:
> > I guess it's a pretty quiet week in kernel-hacker land.  Must be,
> > otherwise people would have better things to do than argue over KB
> > vs. KiB.  The alternative would be to conclude that significant
> > portions of the lkml population prefer flaming to coding, and that
> > couldn't possibly be the case, could it?
>
> Surely not?
>
> > However.  In the *absence* of a clear consensus, I will follow best
> > practices.  Best practice in editing a technical or standards document
> > is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
> > to use, follow and reference international standards.
>
> "Best" practice? That's the *only* practice! Guesswork and assumption
> has no place in technical documentation!

This may be why Andrea Arcangelli refuses to write any documentation at all, 
Linus seems to have a prediliction for dropping documentation-only patches, 
why the stuff in /linux/documentation has fallen up to two years out of date 
at times, and why "Rusty's Unreliable Guides" (the best source of 
documentation on the netfilter code, made available by the author himself at 
"http://netfilter.samba.org/unreliable-guides/") says, and I quote:

-----

The Linux Documentation Project has the noble goal to `create the canonical 
set of free Linux documentation'. 

The Open Source Writer's Group wants `to put together a comprehensive "card 
catalogue" of Open Source and Open Source-related documentation'. 

On the other hand, my pet hamster dressed up in a penguin suit, and appeared 
to me in a dream, telling me to write documentation for random stuff, and 
include lots of obscenities. 

The LDP guys no longer return my EMails (from me or my hamster). 

-----

On the net, the way to get information isn't to ask questions, but to post 
errors.  Questions get ignored more often than errors go unflamed.  Perfect 
documentation, like perfect code, isn't something you wait until you have 
before proceeding.

Rob

Re: Configure.help editorial policy

[Eric Windisch]

On Fri, Dec 21, 2001 at 07:23:13PM -0500, Rob Landley wrote:
> 
> This may be why Andrea Arcangelli refuses to write any documentation at all, 
> Linus seems to have a prediliction for dropping documentation-only patches, 
> why the stuff in /linux/documentation has fallen up to two years out of date 
> at times, and why "Rusty's Unreliable Guides" (the best source of 
> documentation on the netfilter code, made available by the author himself at 
> "http://netfilter.samba.org/unreliable-guides/") says, and I quote:
> 

No doubt. The file drivers/block/loop.c has about 21 comments, although most of them are useless. The file is over 1700 lines long.

It would be a lot easier to grok this code if it didn't look like an entry for the IOCCC :) Comments would be nice.

--
Eric Windisch
http://bwbohh.net

Re: Configure.help editorial policy

[Alan Cox]

> Linus seems to have a prediliction for dropping documentation-only patches, 

Send them to the maintainers not to Linus generally helps. Or to Marcelo 
because he seems to understand its important.

> The Open Source Writer's Group wants `to put together a comprehensive "card 
> catalogue" of Open Source and Open Source-related documentation'. 

[Thats out of date btw - OSWG is gone]

> errors.  Questions get ignored more often than errors go unflamed.  Perfect 
> documentation, like perfect code, isn't something you wait until you have 
> before proceeding.

Ah so aio would be perfect code - thats the problem 8)

Re: Configure.help editorial policy

[David Woodhouse]

esr@thyrsus.com said:
>  My personal esthetic distaste for the new terminology (gack!  "kibi"
> sounds like something I would feed my cat!) is less important than
> following best practices.  I'm hoping it will seem less ugly as it
> becomes more familiar. 

It will. The resistance to the new terminology simply on the grounds that 
it's new and not yet widely familiar _will_ pass.

The correctness and the lack of ambiguity will remain.

--
dwmw2

Re: Configure.help editorial policy

[Kai Henningsen]

vojtech@suse.cz (Vojtech Pavlik)  wrote on 20.12.01 in <20011220234939.A32287@suse.cz>:

> Now my opinion on this would be: By sticking KiB everywhere nothing is
> helped. To the knowledgeable, it's nothing new that memory is measured
> in binary units, while ethernet speed in decimal ones. To the newbie,
> KiB is about as cryptical as KB and he'll never know which is which,
> because as a newbie (s)he didn't read the standards.

Well, considering that I had to look at half a dozen web pages via Google  
to make sure that ethernet did, indeed, use decimal, despite having been  
in the industry for about a decade, I'd say that this *would* help.

And the newbie would at least recognize that there is something going on,  
learning about which just might be a good idea. And the answer would  
presumably come not out of a standard, but out of a FAQ.

> And speaking of the 1 Mbps connection - I fear that in many cases
> that'll be 1024000 bytes per second. What M is that? Binary or decimal?

A lied-about one. These abominations deserve to die, yesterday.  
Preferrably messily.

> Who does care?

If you're selling it to me, I certainly do.

MfG Kai

Re: Configure.help editorial policy

[Vojtech Pavlik]

On Thu, Dec 27, 2001 at 01:57:00PM +0200, Kai Henningsen wrote:

> > And speaking of the 1 Mbps connection - I fear that in many cases
> > that'll be 1024000 bytes per second. What M is that? Binary or decimal?
> 
> A lied-about one. These abominations deserve to die, yesterday.  
> Preferrably messily.

You can't kill ISDN that easily. And not just ISDN, actually most phone
lines are based on 2048000 bit per second links ...

-- 
Vojtech Pavlik
SuSE Labs

Re: Configure.help editorial policy

[Alan Cox]

> You can't kill ISDN that easily. And not just ISDN, actually most phone
> lines are based on 2048000 bit per second links ...

Beg to differ. E1 is only 2048000 bits/second if you never send 5
consecutive 1 bits. The actual data rate on an E1 is in fact variable

Re: Configure.help editorial policy

[Dan Hopper]

Alan Cox <alan@lxorguk.ukuu.org.uk> remarked:
> Beg to differ. E1 is only 2048000 bits/second if you never send 5
> consecutive 1 bits. The actual data rate on an E1 is in fact variable

To the best of my recollection, the line bit (symbol) rate is fixed
at, ideally, 2048000 bps.  At least with HDB3 line coding, a
sequence of 4 consecutive zeroes is replaced with three midscale
values one the line, and a mark that violates the normal mark
alternation scheme.  I.e. 1,0,0,0,0 might be replaced with +,0,0,0,+

Thus, the "payload" data rate of 2048000 equals the line symbol
rate of 2048000 symbols/sec.  (Of course, this isn't really the
"payload" data, since it includes the framing slots and all that,
but...)

Dan

Re: [PATCH] tty canonical mode: nicer erase behaviour

[zefram]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>Your xterm is not following Linux policy - this is a solved problem in
>Linuxspace. Debian bit the bullet a few years ago and did the neccessary
>deed to make all their terminal emulators and console match.

So Linux policy is to support only terminals that generate ^? for
backspace?  I thought Unix-like systems were supposed to be usable from a
great variety of text terminals.  Debian's policy works when your universe
consists solely of Linux machines configured to Debian specifications,
where your terminals are just the Linux console, xterm and screen,
but it fails to handle glass ttys, or xterms running on other systems.

I recall the reaction when someone proposed changing zsh's line editor
(ZLE) to treat backspace and delete characters differently.  Just among
the developers we have users of a wide variety of terminals, and the
proposed change would have broken the line editor for many of us.
As it is, ZLE just works, with no extra effort, on any text terminal,
and we get no complaints.

>                                                   Original telnet has
>IAC sequences to send a "delete" regardless of keymapping policies that
>are not known at end points.

Yes, it was a nice model, a pity it fell out of use.  Telnet defined a
Network Virtual Terminal, that was intended to be a common terminal type
to be emulated on all Telnet sessions, which would have eliminated the
need for the server to know what terminal type was being used on the
client end.  Of course, the NVT was a product of its time: no cursor
addressing, no display attributes, and on the input side only a single
erase key.  The closest equivalent to this model that is currently in
use is the de facto almost-universal capability to emulate a VT100.

These days telnet connections (and rsh and ssh) are used more as dumb
pipes to talk to the user's actual terminal.  We can't change that,
and the result is that Unix systems have to handle whatever terminal
type the user is using.

-zefram

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Alan Cox]

> proposed change would have broken the line editor for many of us.
> As it is, ZLE just works, with no extra effort, on any text terminal,
> and we get no complaints.

And bash treats the two delete keys differently - something a similarly
religious group believe to be the right thing to do

> pipes to talk to the user's actual terminal.  We can't change that,
> and the result is that Unix systems have to handle whatever terminal
> type the user is using.

Which is why they have termcap, terminfo, and x keyboard maps. The kernel
is not there to cover up for usermode programmers inability to get
things right. It has enough to do covering up for the hardware folk

Alan

Re: [PATCH] tty canonical mode: nicer erase behaviour

[zefram]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>Which is why they have termcap, terminfo, and x keyboard maps. The kernel
>is not there to cover up for usermode programmers inability to get
>things right.

Aha, I believe I now see a substantive difference of opinion.  You argue
that the tty line discipline depends on being configured for the terminal
by usermode code, and that it should remain so, whereas I am proposing
that it adopt a strategy with some additional logic so that it doesn't
require usermode configuration.  Please correct me if this is not a
fair representation of your position.  I'm now going to switch from
correcting inaccurate statements to an attempt to persuade you on this
underlying disagreement.

Most of the tty's control characters are perfectly simple user choices.
The user can sensibly choose to use ^R or ^L to invoke the REPRINT
function, or indeed not to have any such control character, and such
choices can be executed by a very simple invocation of stty.  This kind
of choice is not affected by what terminal the user is using, because the
^R or whatever keystroke is just the same on any terminal.  This kind
of choice extends to the ERASE character, provided that the user is
picking something like the traditional #.  But uniquely among the tty
control characters, the most commonly desired setting for ERASE is not
a particular character, but rather "whatever my backspace key sends".

Theoretically, a user could set up the ERASE key to whatever their
backspace key sends by doing "stty erase $(echotc kd)".  In practice this
doesn't work nearly as well as it should -- it relies on having echotc,
and on the terminfo database being sufficiently complete and accurate
for the current terminal, which is made particularly difficult by things
like the xterm variations previously mentioned.  It is true that this
is principally a usermode problem, and indeed I would like to see the
usermode improvements that would make this a viable solution.

However, this usermode approach, of using terminfo, seems out of
character with the tty canonical mode code.  In every other aspect, it is
terminal-independent.  For output, the only control characters it uses are
^G, ^M, ^J and ^H, which behave the same way on pretty much any terminal.
(Actually, because of this policy of using only terminal-independent
control characters, backspacing past a line wrap doesn't display
correctly on most terminals.)  For input, with the default control
character settings, the only special keys used are Return and Backspace.

When handling the Return key, under default settings, the tty line
discipline accepts both ^M and ^J as indicating the end of the line.
(Actually, internally it translates ^M to ^J.)  This allows for some
variation in terminal behaviour and in translations that might occur
before the input gets to the tty.  The internal translation can be turned
off or modified, but the particular characters that can be accepted are
hardcoded, and the default behaviour is to accept both.

What I propose is that this manner of handling the Return key -- accepting
both possible characters that can result from the key, without requiring
usermode configuration to tell it which one to use -- be extended to the
Backspace key when used for its normal function.  (Obviously the mechanism
is a little different, since the ERASE character is more configurable than
the end-of-line character.)  By doing this, the tty line discipline code
would become fully terminal-independent under its default settings, which
seems a worthwhile goal for a program that is so nearly there already.

I accept that we have here an issue about which reasonable people can
disagree, and so if the disagreement now persists then I don't intend
to pursue it much further in this forum.

-zefram

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Linus Torvalds]

On Sun, 23 Sep 2001 zefram@fysh.org wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >Your xterm is not following Linux policy - this is a solved problem in
> >Linuxspace. Debian bit the bullet a few years ago and did the neccessary
> >deed to make all their terminal emulators and console match.
>
> So Linux policy is to support only terminals that generate ^? for
> backspace?

No.

Linux supports everything. Try doing a "man stty".

But the default behaviour is ^?, which makes emacs happy, and also happens
to be the default mode for most real vt100 terminals out there.

If you have a terminal that really really wants ^H, just do

	stty erase ^H

and Linux will happily believe you.

		Linus

Re: [PATCH] tty canonical mode: nicer erase behaviour

[zefram]

Pete Zaitcev <zaitcev@redhat.com> wrote:
>Rubbish. Programs get their erase characters from termios(3).

termios(3) gets its erase character from user setting via stty(1) or
tset(1), neither of which know what character will be generated by the
terminal's main backspace key.  The current situation is that the user
has to manually arrange for the correct setting.  My personal portable
shell setup, for example, contains a script that examines $TERM and sets
the tty erase character accordingly; I've never seen this functionality
available as a standard utility anywhere.

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> One of the long-standing problems preventing Unix from being a
>> user-friendly desktop OS is its handling of erase keys.  There are
>
>Not a kernel space issue

Yes, it's a wider issue, which I wanted to present as background for
the specific change I was proposing.

>                                                      Fix problem apps. 

The Linux tty canonical mode is a problem app.  Let's fix it.

Programs that talk to the tty directly, through the tty raw mode or by
any other means, do need to be fixed separately, if they exhibit the
same problem.  The patch I proposed doesn't affect them.

>They do different things, they are different keys.

On some keyboards they are different keys, and in some programs they do
different things.  Both of these are far from universal.

Programs that want to treat backspace and delete keys differently tend
to get it right already.  Under X, for example, the two keys are both
available, and are distinctly and consistently reported to the program;
many X programs implement text editing with both forward and backward
delete.  There is no problem here.

I am concerned, for the moment, with programs that only need one kind of
erase, and that talk to a physical terminal (or a simulation thereof)
via a character-stream interface.  These programs want to invoke their
backspacing erase function whenever the user presses the backspace key,
and they don't care about any other erase-related key.  Linux's tty line
discipline, in canonical mode, is such a program.

Unfortunately, the programs of which I speak can't see what key the
user is pressing, all they can see is the character that the terminal
decides to generate from the keypress.  And terminals are inconsistent
about which character they generate for the backspace key.  Even before
we look at glass ttys, we have the Linux console (with standard setup)
generating ^? for backspace, and xterm generating ^H for backspace.
Shouldn't the tty line editor work by default on these at least?  Among
glass ttys that I've personally used, the ADM3e and KDS7362 generate ^H,
and VT220 and ND120 generate ^?.

So, *for programs that only care about backspace*, by far the best
solution is to treat both ^H and ^? as backspace.  And as I said before,
the Linux tty line discipline is such a program.  Of course, we then have
the issue that the tty is already somewhat configurable in this regard,
though unfortunately not sufficiently to implement this solution.

>Erase character policy is precisely defined by posix.

It is when the IEXTEN bit is not set.  When it is set, the tty is
permitted to accept other non-standard control characters.  For example,
Linux has a WERASE (word erase) character, which is enabled only in
IEXTEN mode.

>Debian set a policy on this a long time back and have done wonders since

This is interesting.  I wasn't aware of their policy before, but I've
examined it now, after Nadav Har'El provided a URL.

Their policy appears to cover more than one related area, in an incomplete
manner.  For programs that need both forward and backward erase, it says,
basically, "programs shall make it work".  With respect to X programs,
the policy makes perfect sense and is just a statement of common sense.
For programs that interact with a tty through a character stream and
don't want to use terminfo, it insists that terminals generate ^? for
backspace, but ignores the cases where this isn't possible.

The Debian policy is a fine example of the original problem -- it shows
the hoops that people have to jump through (non-standard configuration
of xterm) to get a partial solution.

-zefram

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Alan Cox]

> termios(3) gets its erase character from user setting via stty(1) or
> tset(1), neither of which know what character will be generated by the
> terminal's main backspace key.  The current situation is that the user

Which is correct, because mindreading equipment is currently classified
CIA property at best (hello echelon!)

> The Linux tty canonical mode is a problem app.  Let's fix it.

The Debian people have. There is an official Debian policy which other
vendors adopted on the matter

> we look at glass ttys, we have the Linux console (with standard setup)
> generating ^? for backspace, and xterm generating ^H for backspace.

Your xterm is not following Linux policy - this is a solved problem in
Linuxspace. Debian bit the bullet a few years ago and did the neccessary
deed to make all their terminal emulators and console match.

Alan

Re: [PATCH] tty canonical mode: nicer erase behaviour

[Pete Zaitcev]

> Theoretically every program should be able to determine which erase
> character to accept by looking at terminfo,

Rubbish. Programs get their erase characters from termios(3).

> One of the programs that exhibits the ^H/^? problem is the tty
> line discipline in the Linux kernel.

Read man pages for stty(1) and tset(1).

-- Pete

Problem with i810 chipset

[Steve Kieu]

Hi,

Finally I can report that problem after many testings.

System: i810 graphic chipset, intel celeron 400Mhz;
128 Mb ram. Lucent software modem using lt-modem
driver version 5-99b

Linux: 2.4.9 ... together all ac series with new dri
module for XFree 4.1.0

XFree86 4.1.0 (slackware)

Problem description: system lockup when exitting
XFree86 when the internet connection is active.

How to reproduce:

connect to the internet using pppd. Do not disconnect.

then logout gnome or shuttdown/reboot the computer
using halt/reboot. usually I will get the text console
; but now I dont. no keys work ; no hard disk
activity, can not power off using computer button,
have to unplug the power cord.

If I disconnect ppp0 before logout gnome / or
halt/reboot, it doesn't happen.

If I compile the kernel but not choosing build new
modules for xfree 4.1.0 ; choose the old one (in ac
series), no problem at all

More infomation on request.







=====
S.KIEU

http://travel.yahoo.com.au - Yahoo! Travel
- Got Itchy feet? Get inspired!

Re: Problem with i810 chipset

[Alan Cox]

> System: i810 graphic chipset, intel celeron 400Mhz;
> 128 Mb ram. Lucent software modem using lt-modem
> driver version 5-99b

Please report problems with binary only drivers to the driver vendor,
it could be any kind of incompatibility and as we have no source only they
can help you.

Alan

Re: Problem with i810 chipset

[Xavier Bestel]

le lun 10-09-2001 at 15:40 Alan Cox a écrit :
> > System: i810 graphic chipset, intel celeron 400Mhz;
> > 128 Mb ram. Lucent software modem using lt-modem
> > driver version 5-99b
> 
> Please report problems with binary only drivers to the driver vendor,
> it could be any kind of incompatibility and as we have no source only they
> can help you.

Mmmhh ... it's time to add that
"reply_to_binary_only_driver_help_request" button to your mailer.

	Xav

Re: Problem with i810 chipset

[Horst von Brand]

Alan Cox <alan@lxorguk.ukuu.org.uk> said:
> In-Reply-To: <20010910050525.97814.qmail@web10408.mail.yahoo.com> from "=?iso-8
>      ***859-1?q?Steve=20Kieu?=" at Sep 10, 2001 03:05:25 PM
       
> > System: i810 graphic chipset, intel celeron 400Mhz;
> > 128 Mb ram. Lucent software modem using lt-modem
> > driver version 5-99b

> Please report problems with binary only drivers to the driver vendor,
> it could be any kind of incompatibility and as we have no source only they
> can help you.

Check out the latest driver at http://www.heby.de somewhere. If that
doesn't help, bitch at Lucent.
-- 
Dr. Horst H. von Brand                Usuario #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Problem with i810 chipset (solved!)

[Steve Kieu]

> Check out the latest driver at http://www.heby.de
> somewhere. If that
> doesn't help, bitch at Lucent.


It works!, thanks

=====
S.KIEU

http://travel.yahoo.com.au - Yahoo! Travel
- Got Itchy feet? Get inspired!

Request for comment -- a better attribution system

[Eric S. Raymond]

This is a proposal for an attribution metadata system in the Linux kernel 
sources.  The goal of the system is to make it easy for people reading
any given piece of code to identify the responsible maintainer.  The motivation
for this proposal is that the present system, a single top-level MAINTAINERS
file, doesn't seem to be scaling well.

In this system, most files will contain a "map block".  A map block is a
metadata section embedded in a comment near the beginning of the file.
Here is an example map block for my kxref.py tool:

# %Map
# T: CONFIG_ namespace cross-reference generator/analyzer
# P: Eric S. Raymond <esr@thyrsus.com>
# M: esr@thyrsus.com
# L: kbuild-devel@kbuild.sourceforge.net
# W: http://www.tuxedo.org/~esr/cml2
# D: Sat Apr 21 11:41:52 EDT 2001
# S: Maintained

And here's what a map block should look like in general:

%Map:
T: Description of this unit for map purposes
P: Person
M: Mail patches to
L: Mailing list that is relevant to this area
W: Web-page with status/info
C: Controlling configuration symbol
D: Date this meta-info was last updated
S: Status, one of the following:

	Supported:	Someone is actually paid to look after this.
	Maintained:	Someone actually looks after it.
	Odd Fixes:	It has a maintainer but they don't have time to do
			much other than throw the odd patch in. See below..
	Orphan:		No current maintainer [but maybe you could take the
			role as you write your new code].
	Obsolete:	Old code. Something tagged obsolete generally means
			it has been replaced by a better system and you
			should be using that.

There may be more than one P: field per map block.  There should be exactly one
M: field.

The D: field may have the special value `None' meaining that this map block
was translated from old information which has not yet been confirmed with the
responsible maintainer.

Note that this is the same set of conventions presently used in the
MAINTAINERS file, with only the T:, D:, and C: fields being new.  The
contents of the C: field, if present, should be the name of the
CONFIG_ symbol that controls the inclusion of this unit in a kernel.

(Map blocks are terminated by a blank line.)

Not every file need contain a map block.  To locate the responsible maintainer
for a file, use the following algorithm:

1. Look for a map block in the file itself.

2. Look for a file named %Map in the enclosing directory.
   Any map block in that file applies to the entire directory.

3. Look for a map block in the enclosing directory's README.
   Any map block in that file applies to the entire directory.

4. If you are at the root of the source tree, give up.
   Otherwise, move to the parent directory and goto step 2.

If this proposal meets with approval, I am willing to do three things:

1. Generate a patch to distribute the information presently in the
   MAINTAINERS file into map blocks and %Map files.

2. Write a tool for querying the map database.

3. (Background task, with which I would expect help) Chase down more
   map entries and verify information in old entries.

Thanks to Andreas Dilger for suggesting the basic idea.

Comments are solicited.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The day will come when the mystical generation of Jesus by the Supreme
Being as his father, in the womb of a virgin, will be classed with the
fable of the generation of Minerva in the brain of Jupiter.
	-- Thomas Jefferson, 1823

Re: Request for comment -- a better attribution system

[Karsten Keil]

On Sat, Apr 21, 2001 at 11:49:42AM -0400, Eric S. Raymond wrote:
...
> If this proposal meets with approval, I am willing to do three things:

Sounds good for me.

> 
> 1. Generate a patch to distribute the information presently in the
>    MAINTAINERS file into map blocks and %Map files.
> 
> 2. Write a tool for querying the map database.

Since C: is here, it  would be superb if the make ...config tools have
button to show this information, but since you maintain this stuff I'm
sure that you allready think about this :-)

> 
> 3. (Background task, with which I would expect help) Chase down more
>    map entries and verify information in old entries.
> 
> Thanks to Andreas Dilger for suggesting the basic idea.
> 
> Comments are solicited.
> -- 
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> 
> The day will come when the mystical generation of Jesus by the Supreme
> Being as his father, in the womb of a virgin, will be classed with the
> fable of the generation of Minerva in the brain of Jupiter.
> 	-- Thomas Jefferson, 1823
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Karsten Keil
SuSE Labs
ISDN development

Re: Request for comment -- a better attribution system

[Henning P. Schmiedehausen]

"Eric S. Raymond" <esr@thyrsus.com> writes:

>Here is an example map block for my kxref.py tool:

># %Map
># T: CONFIG_ namespace cross-reference generator/analyzer
># P: Eric S. Raymond <esr@thyrsus.com>
># M: esr@thyrsus.com
># L: kbuild-devel@kbuild.sourceforge.net
># W: http://www.tuxedo.org/~esr/cml2
># D: Sat Apr 21 11:41:52 EDT 2001
># S: Maintained

>Comments are solicited.

Hi Eric,

please not. If you really want to redo this, please use a simple XML
markup.  Let's not introduce another kind of markup if there is
already a well distributed and working.

What's wrong with:

<MAP NAME="CONFIG_ namespace cross-reference generator/analyzer"
     URL="http://www.tuxedo.org/~esr/cml2"
     STATUS="Maintained"
     DATE="Sat Apr 21 11:41:52 EDT 2001">
 <MAINTAINER NAME="Eric S. Raymond"
             MAIL="esr@thyrsus.com"/>
 <PATCHES DESC="Send all patches here."
          MAIL="esr@thyrsus.com" />
 <LIST MAIL="kbuild-devel@kbuild.sourceforge.net"
       DESC="List for developers"/>
 <LIST MAIL="kbuild-user@kbuild.sourceforge.net"
       DESC="List for users"/>
</MAP>

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Request for comment -- a better attribution system

[Francois Romieu]

Henning P. Schmiedehausen <mailgate@mail.hometree.net> ecrit :
[...]
> What's wrong with:
> 
[xml]

I'd rather use c/etags.

Seriously, it won't create maintainers automagically.
I don't see the benefit.

-- 
Ueimor

Re: Request for comment -- a better attribution system

[Andi Kleen]

On Sat, Apr 21, 2001 at 04:38:59PM +0000, Henning P. Schmiedehausen wrote:
> What's wrong with:
[...xml horror deleted...]

The myriads of external tools/libraries you will need (and that usually do not 
work properly, spewing out undecryptable error messages, or are currently not 
installed on your machine) and the near impossibility to process XML files 
with standard unix text tools in a meaningfull way?


-Andi

Re: Request for comment -- a better attribution system

[Jes Sorensen]

>>>>> "Henning" == Henning P Schmiedehausen <mailgate@mail.hometree.net> writes:

Henning> "Eric S. Raymond" <esr@thyrsus.com> writes:
>> Here is an example map block for my kxref.py tool:

>> # %Map # T: CONFIG_ namespace cross-reference generator/analyzer #
>> P: Eric S. Raymond <esr@thyrsus.com> # M: esr@thyrsus.com # L:
>> kbuild-devel@kbuild.sourceforge.net # W:
>> http://www.tuxedo.org/~esr/cml2 # D: Sat Apr 21 11:41:52 EDT 2001 #
>> S: Maintained

>> Comments are solicited.

Henning> Hi Eric,

Henning> please not. If you really want to redo this, please use a
Henning> simple XML markup.  Let's not introduce another kind of
Henning> markup if there is already a well distributed and working.

Henning> What's wrong with:

DON'T! go there, please!

A) This sucks to write and maintain, B) it sucks for people bringing
up Linux on a minimum system or new architecture because they don't
want to have to install 217 XML and other tools to just be able to
configure and build a basic kernel.

Jes

Re: Request for comment -- a better attribution system

[Olaf Titz]

> What's wrong with:
>
> <MAP NAME="CONFIG_ namespace cross-reference generator/analyzer"
>      URL="http://www.tuxedo.org/~esr/cml2"
>      STATUS="Maintained"
>      DATE="Sat Apr 21 11:41:52 EDT 2001">

What is wrong with that is that it's serious overkill.
In particular, this application does not need the ability to nest
tags, so what remains is a linear sequence of name=value pairs and the
complicated syntax buys you nothing.

(More formally: it doesn't need a context-free language, a regular
language is enough.)

Eric's suggestion is powerful enough to do the job and can be parsed
with one line of sed script.

The useful thing in your proposal is the ability to give multiple
attributes to one item, e.g. mail="addr" desc="addr". Even this can be
achieved much easier with a bit of syntactical convention, like always
giving mail addresses in <> with the rest of the line being comment.
Most of the stuff is for human consumption only anyway.

Olaf

Re: [kbuild-devel] Request for comment -- a better attribution system

[Giacomo A. Catenazzi]

"Eric S. Raymond" wrote:
> 
> This is a proposal for an attribution metadata system in the Linux kernel
> sources.  The goal of the system is to make it easy for people reading
> any given piece of code to identify the responsible maintainer.  The motivation
> for this proposal is that the present system, a single top-level MAINTAINERS
> file, doesn't seem to be scaling well.
> 
> In this system, most files will contain a "map block".  A map block is a
> metadata section embedded in a comment near the beginning of the file.
> Here is an example map block for my kxref.py tool:
> 

Good!

> And here's what a map block should look like in general:
> 
> %Map:
> T: Description of this unit for map purposes
> P: Person
> M: Mail patches to
> L: Mailing list that is relevant to this area
> W: Web-page with status/info
> C: Controlling configuration symbol
> D: Date this meta-info was last updated
> S: Status, one of the following:
 
> There may be more than one P: field per map block.  There should be exactly one
> M: field.
> 
> The D: field may have the special value `None' meaining that this map block
> was translated from old information which has not yet been confirmed with the
> responsible maintainer.
> 
> Note that this is the same set of conventions presently used in the
> MAINTAINERS file, with only the T:, D:, and C: fields being new.  The
> contents of the C: field, if present, should be the name of the
> CONFIG_ symbol that controls the inclusion of this unit in a kernel.
> 
> (Map blocks are terminated by a blank line.)
> 

We should use the same filed name of CREDITS e.g. D: for Description.
(maybe you can invert D: description and T: time of last update)

It whould nice also if we include the type of the license (GPL,...).
This for a fast parsing (and maybe also to replace the few lines
of license)

Instead of C: it is more important (IMHO) to include the module name.
Maybe we can include both (modules name are always lower case).
I think that the inclusion of the config option is not important (
considering that it can be easily parsed from the kaos' new makefiles).


	giacomo

Re: [kbuild-devel] Request for comment -- a better attribution system

[Eric S. Raymond]

Giacomo A. Catenazzi <cate@dplanet.ch>:
> We should use the same filed name of CREDITS e.g. D: for Description.
> (maybe you can invert D: description and T: time of last update)

Good point.
 
> It whould nice also if we include the type of the license (GPL,...).
> This for a fast parsing (and maybe also to replace the few lines
> of license)

Is there any kernel code that isn't GPLed?

> Instead of C: it is more important (IMHO) to include the module name.

That we get from the name of the file we're visiting, I think.

> Maybe we can include both (modules name are always lower case).
> I think that the inclusion of the config option is not important (
> considering that it can be easily parsed from the kaos' new makefiles).

Interesting point.  Maybe that field should drop out once we transition.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A right is not what someone gives you; it's what no one can take from you. 
	-- Ramsey Clark

Re: [kbuild-devel] Request for comment -- a better attribution system

[Alan Cox]

> Is there any kernel code that isn't GPLed?

There are numerous bits that are dual licensed, some which are licensed
under the BSD non-advertising type license and some of it licensed under the
X license.

Re: [kbuild-devel] Request for comment -- a better attribution system

[Giacomo A. Catenazzi]

Alan Cox wrote:
> 
> > Is there any kernel code that isn't GPLed?

No. Nearly all code is GPL or GPL compatible license.

> 
> There are numerous bits that are dual licensed, some which are licensed
> under the BSD non-advertising type license and some of it licensed under the
> X license.

I resign my proposal. Kernel sources are clean. I confused with the
(obsolete) libg++ which have file that start with GPL license,
at the bottom of file I find the BSD license and sometime in the
middle there is also some univesity license, thus libg++ users
should scann all file to see the copyright. Luckly the linux code is
more clean.


	giacomo

Re: [kbuild-devel] Request for comment -- a better attribution system

[mirabilos]

> > It whould nice also if we include the type of the license (GPL,...).
> > This for a fast parsing (and maybe also to replace the few lines
> > of license)
> 
> Is there any kernel code that isn't GPLed?

It must not, due to the GPL viral effect.

But I know of atleast the BSD compress module.
Because of the licensing it only can be compiled
as a module, so it's not part of the kernel which
if GPL'ed.

-mirabilos

Re: [kbuild-devel] Request for comment -- a better attribution system

[Markus Schaber]

Hi,

mirabilos wrote:

> > > It whould nice also if we include the type of the license (GPL,...).
> > > This for a fast parsing (and maybe also to replace the few lines
> > > of license)
> > Is there any kernel code that isn't GPLed?
> It must not, due to the GPL viral effect.

Well, would it be possible to create some module under LGPL, and then
have included it into the kernel? Maybe it needs to maintain the LGPL
version out of the kernel, and transform a copy to the GPL before
submitting?

Or what about using a "twin-licence" that states "you can apply GPL or
$another_licence, whichever you want"?

And what about real "public domain" software, where the author gave up
all rights? (AFAIK, this is not legally possible in the German copyright
laws, as you can't licence uses that'll be invented in the future).

markus, not a lawyer
-- 
Markus Schaber -- http://www.schabi.de/ -- ICQ: 22042130
+-------------------------------------------------------------+
| Allgemeine Sig-Verletzung 0815/4711  <nicht OK> <Erbrechen> |
+-------------------------------------------------------------+

Re: [kbuild-devel] Request for comment -- a better attribution system

[Alan Cox]

> Well, would it be possible to create some module under LGPL, and then
> have included it into the kernel? Maybe it needs to maintain the LGPL
> version out of the kernel, and transform a copy to the GPL before
> submitting?

There is kernel code under a whole variety of licenses. When linked together
the resulting work is GPL but many of the pieces used on their own or in
conjunction with different code are not GPL.

Alan

Re: [kbuild-devel] Request for comment -- a better attribution system

[Giacomo Catenazzi]

Alan Cox wrote:
> 
> > Well, would it be possible to create some module under LGPL, and then
> > have included it into the kernel? Maybe it needs to maintain the LGPL
> > version out of the kernel, and transform a copy to the GPL before
> > submitting?
> 
> There is kernel code under a whole variety of licenses. When linked together
> the resulting work is GPL but many of the pieces used on their own or in
> conjunction with different code are not GPL.

Unfortunatelly there are exeptions:
the old ppp driver (only lickable to GPL kernel).
and drivers/usb/serial/keyspan_usa18x_fw.h:
1 /* keyspan_usa18x_fw.h
2   
3    Generated from Keyspan firmware image Wed Jul  5 09:18:29
2000 EST
4    This firmware is for the Keyspan USA-18X Serial Adaptor
5 
6    "The firmware contained herein as keyspan_usa18x_fw.h is
7    Copyright (C) 1999-2000 Keyspan, A division of InnoSys
Incorporated
8    ("Keyspan"), as an unpublished work.  This notice does
not imply
9    unrestricted or public access to this firmware which is a
trade secret of
10    Keyspan, and which may not be reproduced, used, sold or
transferred to any
11    third party without Keyspan's prior written consent. 
All Rights Reserved.
12 
13    This firmware may not be modified and may only be used
with the Keyspan 
14    USA-18X Serial Adapter.  Distribution and/or
Modification of the
15    keyspan.c driver which includes this firmware, in whole
or in part,
16    requires the inclusion of this statement."
17 
18 */
with a surelly non-free/non-GPL license.

Maybe we should, as in tetex, check every license in every
file, to remove
the non-free files.
[But anyone (not-M$) will sue us?]

	giacomo

Re: [kbuild-devel] Request for comment -- a better attribution system

[Alan Cox]

> 14    USA-18X Serial Adapter.  Distribution and/or
> Modification of the
> 15    keyspan.c driver which includes this firmware, in whole
> or in part,
> 16    requires the inclusion of this statement."
> 17 
> 18 */
> with a surelly non-free/non-GPL license.

That one is being sorted out currently. The firmware itself is fine (its mere
aggregation) but there are some problems with the firmware distribution aspects
of it.

Going through checking licensing is generally a good idea. Its something that
becomes more important over time and people become more fussy about with unclear
cases (trn, tin, getty-ps for example are probably non free apps but people
assume they are 'free software'). Older versions of glibc (2.1 etc) have 
some odd licensing bits in one area

Re: [kbuild-devel] Request for comment -- a better attribution system

[Horst von Brand]

"Giacomo A. Catenazzi" <cate@dplanet.ch> said:

[...]

> It whould nice also if we include the type of the license (GPL,...).

If it's in-kernel, it is GPLed.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: [kbuild-devel] Request for comment -- a better attribution system

[Giacomo A. Catenazzi]

Horst von Brand wrote:
> 
> "Giacomo A. Catenazzi" <cate@dplanet.ch> said:
> 
> [...]
> 
> > It whould nice also if we include the type of the license (GPL,...).
> 
> If it's in-kernel, it is GPLed.

No if it is build into the kernel is GPL or GPL compatible.
some PPP drivers can be built only as modules because of
the linking restriction of GPL code to non GPL compatible
code.
In kernel there are also some automatic generated file.
GPL requires sources!

But this is off-topic for the main lkml.

	giacomo

Re: Request for comment -- a better attribution system

[Albert D. Cahalan]

Eric S. Raymond writes:

> This is a proposal for an attribution metadata system in the Linux
> kernel sources.  The goal of the system is to make it easy for
> people reading any given piece of code to identify the responsible
> maintainer.  The motivation for this proposal is that the present
> system, a single top-level MAINTAINERS file, doesn't seem to be
> scaling well.

It is nice to have a single file for grep. With the proposed
changes one would sometimes need to grep every file.

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Albert D. Cahalan <acahalan@cs.uml.edu>:
> Eric S. Raymond writes:
> 
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources.  The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintainer.  The motivation for this proposal is that the present
> > system, a single top-level MAINTAINERS file, doesn't seem to be
> > scaling well.
> 
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.

The right way to handle that is to have a report generator that does the
grep for you, or if you like simply returns the concatenation of all the
map blocks so you can grep that.

The point of distributing them is so they're close to the work units they
describe, and are thus (a) easy to find, and (b) more likely to stay up to
date.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never could an increase of comfort or security be a sufficient good to be
bought at the price of liberty.
	-- Hillaire Belloc

Re: Request for comment -- a better attribution system

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Subject: Re: Request for comment -- a better attribution system
> 
> Return-Path: linux-kernel-owner@vger.kernel.org
> Delivery-Date: Sat Apr 21 20:28:52 2001
> Return-Path: <linux-kernel-owner@vger.kernel.org>
> Reply-To: esr@thyrsus.com
> Mail-Followup-To: "Eric S. Raymond" <esr@thyrsus.com>,
> 	 "Albert D. Cahalan" <acahalan@cs.uml.edu>,
> 	 CML2 <linux-kernel@vger.kernel.org>,
> 	 kbuild-devel@lists.sourceforge.net
> References: <20010421114942.A26415@thyrsus.com> <200104212023.f3LKN7P188973@sat
>      ***urn.cs.uml.edu>
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> In-Reply-To: <200104212023.f3LKN7P188973@saturn.cs.uml.edu>; from acahalan@cs.u
>      ***ml.edu on Sat, Apr 21, 2001 at 04:23:06PM -0400
> Organization: Eric Conspiracy Secret Labs
> X-Eric-Conspiracy: There is no conspiracy
> Sender:  linux-kernel-owner@vger.kernel.org
> Precedence: bulk
> X-Mailing-List: linux-kernel@vger.kernel.org
> 
> Albert D. Cahalan <acahalan@cs.uml.edu>:

[...]

> > It is nice to have a single file for grep. With the proposed
> > changes one would sometimes need to grep every file.

> The right way to handle that is to have a report generator that does the
> grep for you, or if you like simply returns the concatenation of all the
> map blocks so you can grep that.

Please, _no_ specialized-just-for-linux-kernel-hacking tools! Unix is great
because it has _no_ such for-one-task-only tools, which you have to learn
how to use each time a reason for using them comes around.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Request for comment -- a better attribution system

[Alexander Viro]

On Sat, 21 Apr 2001, Albert D. Cahalan wrote:

> Eric S. Raymond writes:
> 
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources.  The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintainer.  The motivation for this proposal is that the present
> > system, a single top-level MAINTAINERS file, doesn't seem to be
> > scaling well.
> 
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.

The real problem is that large part of the kernel has no permanent
maintainers. Which makes the whole (overdesigned) idea completely moot.

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> The real problem is that large part of the kernel has no permanent
> maintainers. Which makes the whole (overdesigned) idea completely moot.

One of the problems this `overdesign' can help solve is actually identifying
the parts that have semi-permanent maintainers, and the parts that don't.

One way to use the meta-information, for example, would be to use it to 
periodically poll maintainers to find out if they're still active.

Another is to be able to generate reports on exactly how much of the kernel
is in "Maintained" or "Supported" status.  I think it would be worth 
making this change just so we could know that.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

What if you were an idiot, and what if you were a member of Congress?
But I repeat myself.
        -- Mark Twain

Re: Request for comment -- a better attribution system

[Francois Romieu]

Eric S. Raymond <esr@thyrsus.com> ecrit :
[...]
> One of the problems this `overdesign' can help solve is actually identifying
> the parts that have semi-permanent maintainers, and the parts that don't.
> 
> One way to use the meta-information, for example, would be to use it to 
> periodically poll maintainers to find out if they're still active.
> 
> Another is to be able to generate reports on exactly how much of the kernel
> is in "Maintained" or "Supported" status.  I think it would be worth 
> making this change just so we could know that.

                                  Y    N
The kernel will perform better   [ ]  [ ]
Somebody will have less work     [ ]  [ ]
It's fun (TM)                    [ ]  [ ]

-- 
Ueimor - cd /pub

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Francois Romieu <romieu@cogenit.fr>:
>                                   Y    N
> The kernel will perform better   [ ]  [*]

> Somebody will have less work     [*]  [ ]

Yes, anybody trying to figure out how to get a fix made.

> It's fun (TM)                    [*]  [ ]

Fun for me.  I like solving global problems rather than just local ones.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Extremism in the defense of liberty is no vice; moderation in the
pursuit of justice is no virtue."
	-- Barry Goldwater (actually written by Karl Hess)

Re: Request for comment -- a better attribution system

[Francois Romieu]

Eric S. Raymond <esr@thyrsus.com> ecrit :
> Francois Romieu <romieu@cogenit.fr>:
[...]
> > Somebody will have less work     [*]  [ ]
> 
> Yes, anybody trying to figure out how to get a fix made.

Provided it's kept up-to-date. I.e. it calls for some tools (and these
require the suggested changes).

> > It's fun (TM)                    [*]  [ ]
> 
> Fun for me.  I like solving global problems rather than just local ones.

I'll only object that imvvvvho there is no global problem here:
* If user meets a serious problem, the maintainer will surely ask
him to test some fix, to specify some point or whatever. Thanks to
System, user will save 5 or 10 minutes. To be compared to the time spent
with said maintainer or preparing the bug report.
* If user don't know how to submit and don't use some exotic driver, I bet
he will start by posting to l-k and be eventually redirected.
* If user has identified problem with his FooBar SS6 adapter, chances
are that he knows who he should reach.

I have no problem with it but I'm not sure it's *really* useful.

-- 
Ueimor

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Francois Romieu <romieu@cogenit.fr>:
> Provided it's kept up-to-date. I.e. it calls for some tools (and these
> require the suggested changes).

Yes.  I'll write the tools.

> I'll only object that imvvvvho there is no global problem here:
> * If user meets a serious problem, the maintainer will surely ask
> him to test some fix, to specify some point or whatever. Thanks to
> System, user will save 5 or 10 minutes. To be compared to the time spent
> with said maintainer or preparing the bug report.
> * If user don't know how to submit and don't use some exotic driver, I bet
> he will start by posting to l-k and be eventually redirected.
> * If user has identified problem with his FooBar SS6 adapter, chances
> are that he knows who he should reach.
> 
> I have no problem with it but I'm not sure it's *really* useful.

Reducing friction costs and increasing accountability is always useful.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction.  Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
        -- Colin Greenwood, in the study "Firearms Control", 1972

Re: Request for comment -- a better attribution system

[Alan Cox]

> Another is to be able to generate reports on exactly how much of the kernel
> is in "Maintained" or "Supported" status.  I think it would be worth 
> making this change just so we could know that.

There is no correlation between claimed and actual levels of supportedness.
There are drivers with no-one supporting them that are common and thus get
fixed very rapidly for example.

I actually prefer MAINTAINERS because it breaks things down by area and reflects
the actual maintainership and areas covered. Something that per file does not

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> I actually prefer MAINTAINERS because it breaks things down by area
> and reflects the actual maintainership and areas covered. Something
> that per file does not

Instead of arguing this point, I will demonstrate a solution with 
working code.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
        -- Mike Royko, Chicago Tribune

Re: Request for comment -- a better attribution system

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> I actually prefer MAINTAINERS because it breaks things down by area
>> and reflects the actual maintainership and areas covered. Something
>> that per file does not

Eric> Instead of arguing this point, I will demonstrate a solution
Eric> with working code.  -- <a

A MAINTAINERS file does not need code, as Horst said, no more
specialized tools!

Jes

Re: [kbuild-devel] Re: Request for comment -- a better attribution system

[Giacomo A. Catenazzi]

Alan Cox wrote:
> 
> > Another is to be able to generate reports on exactly how much of the kernel
> > is in "Maintained" or "Supported" status.  I think it would be worth
> > making this change just so we could know that.
> 
> There is no correlation between claimed and actual levels of supportedness.
> There are drivers with no-one supporting them that are common and thus get
> fixed very rapidly for example.
> 
> I actually prefer MAINTAINERS because it breaks things down by area and reflects
> the actual maintainership and areas covered. Something that per file does not
> 

Question about patches you receive:
How many patch from Maintainer do you receive?
How many patch from non-Maintainer do you receive (for maintained code)?
How many patch from non-Maintainer do you receive (for non maintained
code)?
[I don't need absolute values (but only ratios) nor exact numbers, just
for make
me an idea]


IMHO the problem show in this thead is:
Where developers should send patches? To Linus/AC or to driver
maintainer?
ESR proposal enforces this last, but do all mainainers have always time
for linux
developement? Should the maintainers be professional? Should Linus/AC
reject
clean patches from non-maintainers? Do all maintainers read lkml?


I think the idea of ESR is nice for the normal .c codes. The
[Cc]onfig.in and
Makefile are a very special case, and I think after the inclusion of new
kbuild in linux kernel, the maintainement of these files will be not a
big
issue, so I will not discuss this special case.

When I find a bug in a file, I check at the top of the file to find who
is the
maintainer. Normally I found the address of maintainer, and I will use
this address. Thus there is already some duplicate address (but the
addresses
in MAINTAINER are sometime old, or missing).
I see ESR proposal as a clean up/standardization of the head of normal
files.
This is the case of developer that need to contact a maintainer .

The top MAINTAINER it is needed for the normal user that find a bug (and
that don't know the structure of kernel).

Thus my proposal: We implement the ESR proposal and we create a new
MAINTAINER file that will list some bugs ML (for each subsystem).
In this manner the life of not-developer user will be simplified and
maybe we receive some more bug report.
Alternativelly we can generate MAINTAINER from ESR's map headers.
In this case we should include this script in the Linus script to
automagically create the i386 defconfig.


BTW ESR's last threads show us some other problem in linux developement
style.
(or better: the inhomogenity of developement style of some part of
kernel),
and we should convince him that the newer subsystem (and arch) should be
really
developed as cathedral style (untill stabilization) or we will be
flooded by big
kernel patches every few days.


	giacomo


PS: reading again this email (and doing some additions), I see that we
cannot
standardize maintainers (nor ESR proposal nor in the actual
MAINTAINERS).
ESR proposal cannot give us the right solution. We should live with the
incomplete MAINTAINERS file and missing maintainers.

BTW also in Debian we have problems with MIA (and very busy)
maintainers,
but because we are free project, we should live with that (and no-files
could
give us a solution) [in Debian MIA file, here the Date files of ESR
proposal]

Thus ESR: If a maintainer did not reply to you (or if you don't find the
maintainer name), you will be the tmp_maintainer of such files.
Files could help us, but no so much to solve your (and maybe us future)
problems.


	giacomo

Re: [kbuild-devel] Re: Request for comment -- a better attribution

[Alan Cox]

> Where developers should send patches? To Linus/AC or to driver
> maintainer?

All of the above at random. Sometimes with a cc. Often to me/Linus if the
maintainer isnt responding.

> ESR proposal enforces this last, but do all mainainers have always time
> for linux
> developement? Should the maintainers be professional? Should Linus/AC
> reject
> clean patches from non-maintainers? Do all maintainers read lkml?

The scheme I work tends to be something like


If the patch is small and obviously correct and its not to Jes Sorensen's driver
	Apply it to -ac

If the patch is more complex or changes design considerations
	if it seems reasonably sane to apply
		Apply to -ac
		Cc change to maintainer
		Mark not to go to Linus without maintainer approval
	Bounce to maintainer if active
	Apply if not active or not replying

If the patch changes fundamental things - eg syscall numbers, policy in kernel
	Tell them to talk to Linus

And then there are a thousand specific other things like config.h include fixing
typo fixes and such which don't quite follow the rule.

Re: [kbuild-devel] Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Giacomo A. Catenazzi <cate@dplanet.ch>:
> Alternativelly we can generate MAINTAINER from ESR's map headers.
> In this case we should include this script in the Linus script to
> automagically create the i386 defconfig.

Aha!  Somebody is actually *thinking* rather than having a
conservative reflex.  Yes, boys and girls, this is exactly how I
planned to solve the I-want-to-be-able-to-grep-it problem.

Giacomo hasn't resolved the larger question of whether my distributed-
attribution proposal is a good idea or not.  What he *has* done is
demonstrated that the resistance to it is mostly rationalized rather
than rational.  Otherwise somebody else would have seen this a lot
sooner.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Request for comment -- a better attribution system

[Pavel Machek]

Hi!

> > The real problem is that large part of the kernel has no permanent
> > maintainers. Which makes the whole (overdesigned) idea completely moot.
> 
> One of the problems this 

Re: Request for comment -- a better attribution system

[Mr. James W. Laferriere]

	Hello Eric ,

On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources.  The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintainer.  The motivation for this proposal is that the present
> > system, a single top-level MAINTAINERS file, doesn't seem to be
> > scaling well.
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.

	Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
	Hate answering with just one line of credible info , But .
		Hth ,  JimL
       +----------------------------------------------------------------+
       | James   W.   Laferriere | System  Techniques | Give me VMS     |
       | Network        Engineer | 25416      22nd So |  Give me Linux  |
       | babydr@baby-dragons.com | DesMoines WA 98198 |   only  on  AXP |
       +----------------------------------------------------------------+

Re: Request for comment -- a better attribution system

[Albert D. Cahalan]

James  W. Laferriere writes:
> On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
>> Eric S. Raymond writes:

>>> This is a proposal for an attribution metadata system in the Linux
>>> kernel sources.  The goal of the system is to make it easy for
>>> people reading any given piece of code to identify the responsible
>>> maintainer.  The motivation for this proposal is that the present
>>> system, a single top-level MAINTAINERS file, doesn't seem to be
>>> scaling well.
>>
>> It is nice to have a single file for grep. With the proposed
>> changes one would sometimes need to grep every file.
>
> 	Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
> 	Hate answering with just one line of credible info , But .

The above would grep every file. It takes 1 minute and 9.5 seconds.
So the distributed maintainer information does not scale well at all.

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Albert D. Cahalan <acahalan@cs.uml.edu>:
> The above would grep every file. It takes 1 minute and 9.5 seconds.
> So the distributed maintainer information does not scale well at all.

There is an easy solution to this which I will demonstrate with code.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Everything that is really great and inspiring is created by the
individual who can labor in freedom.
	-- Albert Einstein, in H. Eves Return to Mathematical Circles, 
		Boston: Prindle, Weber and Schmidt, 1988.

Re: Request for comment -- a better attribution system

[Jonathan Morton]

>> 	Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
>> 	Hate answering with just one line of credible info , But .
>
>The above would grep every file. It takes 1 minute and 9.5 seconds.
>So the distributed maintainer information does not scale well at all.

No it doesn't.  It allows you to search for files of a specific naming
pattern and greps those.  So if you needed to know the maintainers of all
the config.in files, you say:

find . -name "*onfig.in" -type f -print | xargs grep 'P: '

If you need to know the maintainer(s) of a specific file or directory of
files, simply direct your search there.  The only problem occurs when you
really don't know where to look - so then you search the entire kernel for
the configuration option, and look wherever you find that.

I really don't see the problem.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: Request for comment -- a better attribution system

[Alan Cox]

> files, simply direct your search there.  The only problem occurs when you
> really don't know where to look - so then you search the entire kernel for
> the configuration option, and look wherever you find that.

Which is 99% of the time for most users.

Re: Request for comment -- a better attribution system

[Albert D. Cahalan]

> >> 	Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
> >> 	Hate answering with just one line of credible info , But .
> >
> >The above would grep every file. It takes 1 minute and 9.5 seconds.
> >So the distributed maintainer information does not scale well at all.
> 
> No it doesn't.  It allows you to search for files of a specific naming
> pattern and greps those.  So if you needed to know the maintainers of all
> the config.in files, you say:
> 
> find . -name "*onfig.in" -type f -print | xargs grep 'P: '

That was an easy problem, and try it to see all the bad matches!
This would be more normal:

find . -type f | xargs egrep -i8 '^[^A-Z]*[A-Z]: .*(net|ip|tcp|eth|ppp)'

That is not a nice and easy command for most people, and if it
isn't exactly right you just wasted over a minute.

Re: Request for comment -- a better attribution system

[Ben Ford]

Albert D. Cahalan wrote:

>>>>	Find . -name "*Some-Name*" -type f -print | xargs grep 'Some-Info'
>>>>	Hate answering with just one line of credible info , But .
>>>>
>>>The above would grep every file. It takes 1 minute and 9.5 seconds.
>>>So the distributed maintainer information does not scale well at all.
>>>
>>No it doesn't.  It allows you to search for files of a specific naming
>>pattern and greps those.  So if you needed to know the maintainers of all
>>the config.in files, you say:
>>
>>find . -name "*onfig.in" -type f -print | xargs grep 'P: '
>>
>
>That was an easy problem, and try it to see all the bad matches!
>This would be more normal:
>
>find . -type f | xargs egrep -i8 '^[^A-Z]*[A-Z]: .*(net|ip|tcp|eth|ppp)'
>
>That is not a nice and easy command for most people, and if it
>isn't exactly right you just wasted over a minute.
>

Eric *has* offered to write tools to simplify this.  I would guess that 
it would be something like:

kgrep [-t description] [-p person] [-m mailto] [-l mailing-list] [-w 
webpage] [-c config symbol] [-d date] [-s status]

-b

-- 
Three things are certain:
Death, taxes, and lost data
Guess which has occurred.
- - - - - - - - - - - - - - - - - - - -
Patched Micro$oft servers are secure today . . . but tomorrow is another story!

Re: Request for comment -- a better attribution system

[Olaf Titz]

> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.

With the proposed changes it's nearly trivial to build the traditional
MAINTAINERS file with a Makefile rule, so you've lost nothing. Plus
you get the additional info (which the collecting script, two lines of
sed in my estimate, would duly include[1]) which _file_ actually is
maintained by whom.

Which makes e.g. coordinating patches and bug reporting much easier.

Olaf

[1] Although Eric would probably rather want to use a database
querying tool at this point :-)

Re: Request for comment -- a better attribution system

[Anuradha Ratnaweera]

On Sat, 21 Apr 2001, Albert D. Cahalan wrote:

> Eric S. Raymond writes:
> 
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources.  The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintainer.  The motivation for this proposal is that the present
> > system, a single top-level MAINTAINERS file, doesn't seem to be
> > scaling well.
> 
> It is nice to have a single file for grep. With the proposed
> changes one would sometimes need to grep every file.

What about

grep `find . -name "MAINTAINERS"`

Anuradha

Re: Request for comment -- a better attribution system

[Alan Cox]

> any given piece of code to identify the responsible maintainer.  The motivation
> for this proposal is that the present system, a single top-level MAINTAINERS
> file, doesn't seem to be scaling well.

It scales perfectly. Most of the people you annoyed are _in_ the maintainers
and credits file. The fundamental problem is identical regardless of what
you change - people forget to update things unless there is motivation [1]

Alan
[1] as proof of this claim count the number of CREDIT file updates made shortly
after the RH share offering..

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> It scales perfectly.

I must say, in the most respectful way possible, "bullshit!"

Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend three months
just trying to figure out who was reponsible for each of the [Cc]onfig.in
files.  And even with that amount of effort mostly failing.

You only think the present attribution system scales well because your
position is, shall we say, *privileged*.  Maintainers come to you; you
don't normally have to try to track them down.  Me, I *know* that Andreas 
Dilger identified a real problem, because I've barked my fscking shins on it.
In two separate contexts now.

(There's a related rant I'm not ready to utter yet about how lkml's
social machinery is very poorly adapted to solving problems that cross
boundaries between different hackers' personal fiefdoms.)

I'm an unusually stubborn and persistent person, as you have cause to
know.  I really wonder how much good work we've lost because people less 
stubborn than me simply gave up on the friction costs of trying to identify
the responsible person(s) for the bits they wanted to change.

Andreas saw the problem, and he also saw the solution. It's to make
the structure of the attribution system match the structure of the
code -- and of the social machine that surrounds the code.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one is bound to obey an unconstitutional law and no courts are bound
to enforce it.  
	-- 16 Am. Jur. Sec. 177 late 2d, Sec 256

Re: Request for comment -- a better attribution system

[Alan Cox]

> Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend three months
> just trying to figure out who was reponsible for each of the [Cc]onfig.in
> files.  And even with that amount of effort mostly failing.

99.9999% of problems don't involve querying the set of maintainers of
Confg.in files. The system is optimised to the general case of queries people
need to make. It also happens to be accessible to people who are not
kernel gurus because it uses roughly English terms for the maintainership
and area.

The .0001% case isnt interesting. Thats the difference between real world 
systems and theory.

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> 99.9999% of problems don't involve querying the set of maintainers of
> Confg.in files. The system is optimised to the general case of queries people
> need to make. It also happens to be accessible to people who are not
> kernel gurus because it uses roughly English terms for the maintainership
> and area.
> 
> The .0001% case isnt interesting. Thats the difference between real world 
> systems and theory.

Again with due respect, you haven't gotten it yet.  In fact, you've
got it exactly backwards.  Unsurprising -- you're so magnificently
well adapted to the way things are that certain limiting assumptions
of the system you operate in have become invisible to you.

What you call a rare case is rare not because it *should* be rare but because
the work practices and social mechanisms of lkml combine to heavily discourage
improvements that cross jurisdictional boundaries.  

This is a *problem*.  I won't belabor the point, because I am certain
that you'll believe the conclusion more if you figure it out yourself than
if I tell you.  Hint: think about long-term coherency issues in large
codebases.  Think hard.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

.. a government and its agents are under no general duty to 
provide public services, such as police protection, to any 
particular individual citizen...
        -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)

Re: Request for comment -- a better attribution system

[Alan Cox]

> Again with due respect, you haven't gotten it yet.  In fact, you've
> got it exactly backwards.  Unsurprising -- you're so magnificently
> well adapted to the way things are that certain limiting assumptions
> of the system you operate in have become invisible to you.

Oh Im quite aware of the limitations of the system. Even the _value_ of those
limitations. I am not interested in the .001% because it excessively impacts
the other 99.99% of the problemspace I do care about.

Z

Re: Request for comment -- a better attribution system

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > It scales perfectly.

> I must say, in the most respectful way possible, "bullshit!"

> Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend three months
> just trying to figure out who was reponsible for each of the [Cc]onfig.in
> files.  And even with that amount of effort mostly failing.

What makes you think your scheme will fare any differently?

[...]

> I'm an unusually stubborn and persistent person, as you have cause to
> know.  I really wonder how much good work we've lost because people less 
> stubborn than me simply gave up on the friction costs of trying to identify
> the responsible person(s) for the bits they wanted to change.

They post on LKM as last resort.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Horst von Brand <vonbrand@sleipnir.valparaiso.cl>:
> What makes you think your scheme will fare any differently?

Design better matched to the group's workflow.  But I'm not going to
argue the point when I think I can demonstrate it.  Watch this space.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: [kbuild-devel] Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Horst von Brand <vonbrand@sleipnir.valparaiso.cl>:
> > I'm an unusually stubborn and persistent person, as you have cause to
> > know.  I really wonder how much good work we've lost because people less 
> > stubborn than me simply gave up on the friction costs of trying to identify
> > the responsible person(s) for the bits they wanted to change.
> 
> They post on LKM as last resort.

I tried that, too.  It didn't work either.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

As with the Christian religion, the worst advertisement for Socialism
is its adherents.
	-- George Orwell 

Re: [kbuild-devel] Re: Request for comment -- a better attribution system

[Arjan van de Ven]

In article <20010422112816.B28605@thyrsus.com> you wrote:
>> They post on LKM as last resort.

> I tried that, too.  It didn't work either.

Most lklm readers ignore posts that look like trolls or are for proposals
they disagree with.

Re: Request for comment -- a better attribution system

[Russell King]

On Sat, Apr 21, 2001 at 07:47:06PM -0400, Eric S. Raymond wrote:
> Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend three
> months just trying to figure out who was reponsible for each of the
> [Cc]onfig.in files.  And even with that amount of effort mostly failing.

Could that be because there _is no_ maintainer for the config.in files?
Therefore, splitting up the MAINTAINERS file achieves nothing.

However, for the specific times that you've unfortunately come across
the problem, and one of the times it was to do with the ARM config.in
file, I can definitely say that the information _has_ been in the
maintainers file, and it _is_ up to date.  Here, let me give an
example:

ARM PORT
P:      Russell King
M:      linux@arm.linux.org.uk
L:      linux-arm-kernel@lists.arm.linux.org.uk
W:      http://www.arm.linux.org.uk/
S:      Maintained

I don't think that you can say that the MAINTAINERS file has failed in
this case, and cutting it up into little pieces solves precisely
nothing.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Russell King <rmk@arm.linux.org.uk>:
> Could that be because there _is no_ maintainer for the config.in files?
> Therefore, splitting up the MAINTAINERS file achieves nothing.

It's not just splitting up the file that I'm advocating.  However, as I
said, I'm going to stop arguing and demonstrate,
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
        -- Constitutional scholar and Supreme Court Justice Joseph Story, 1840

Re: Request for comment -- a better attribution system

[Matthew Kirkwood]

On Sat, 21 Apr 2001, Eric S. Raymond wrote:

> Alan, if MAINTAINERS scaled perfectly I wouldn't have had to spend
> three months just trying to figure out who was reponsible for each of
> the [Cc]onfig.in files.  And even with that amount of effort mostly
> failing.

I have a much simpler proposal, which appears to solve your
immediate problem, and would keep most people happy -- add a:

C: CONFIG_SCSI_BLARG

tag to MAINTAINERS.  If you _really_ insist, add an:

F: drivers/scsi/blarg.c
F: drivers/scsi/blarg.h

too.  It removes the ambiguity inherent in the current system,
without adding an overengineered solution with no obvious
advantages.

Matthew.

Re: Request for comment -- a better attribution system

[Russell King]

On Sun, Apr 22, 2001 at 11:22:11AM +0100, Matthew Kirkwood wrote:
> C: CONFIG_SCSI_BLARG
> 
> tag to MAINTAINERS.  If you _really_ insist, add an:
> 
> F: drivers/scsi/blarg.c
> F: drivers/scsi/blarg.h
> 
> too.  It removes the ambiguity inherent in the current system,
> without adding an overengineered solution with no obvious
> advantages.

And what would:

C: CONFIG_ARM

tell you?  Nothing that is not described in the rest of the "ARM PORT"
entry.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Request for comment -- a better attribution system

[Matthew Kirkwood]

On Sun, 22 Apr 2001, Russell King wrote:

> > C: CONFIG_SCSI_BLARG
> > F: drivers/scsi/blarg.c
> > F: drivers/scsi/blarg.h

> And what would:
>
> C: CONFIG_ARM
>
> tell you?  Nothing that is not described in the rest of the "ARM PORT"
> entry.

True, but it would tell it to a script without intervention.

Eric wants an easy way to find the owner of a CONFIG_ entry.
True, the consensus seems to be that this isn't a particularly
useful thing to do, but if it must be done, this seems like an
eminently sane way to do it.

Matthew.

Re: Request for comment -- a better attribution system

[Alan Cox]

> Eric wants an easy way to find the owner of a CONFIG_ entry.
> True, the consensus seems to be that this isn't a particularly
> useful thing to do, but if it must be done, this seems like an
> eminently sane way to do it.

So we need a system to handle the thousand odd entries, a person to maintain
each item and correct all the errors, processes for handling shared CONFIG_
name space, and procedures for handling registering new entries.

It says one thing 'WOMBAT'

Alan

Re: Request for comment -- a better attribution system

[Russell King]

On Sun, Apr 22, 2001 at 02:42:29PM +0100, Matthew Kirkwood wrote:
> On Sun, 22 Apr 2001, Russell King wrote:
> > And what would:
> >
> > C: CONFIG_ARM
> >
> > tell you?  Nothing that is not described in the rest of the "ARM PORT"
> > entry.
> 
> True, but it would tell it to a script without intervention.

I'll grant you that it does solve the "who owns a CONFIG_ symbol", but
that is only one small problem - there's the bigger problem as to who
owns each line of code.  Are we going to start labelling each source
code line as well?

I just don't see what this gets us - its safe to assume that any symbol
in arch/*/config.in which isn't a driver is looked after by the
architecture maintainer.  If not, the architecture maintainer probably
knows who does.

If the purpose of this "documentation" exercise for CONFIG_* symbols
is just that, then shouldn't we be adding it to the Config.in files,
rather than creating yet more files which will become out of sync
with the configuration system?  (maybe we are, but the suggestions
I've seen appear to the contary).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Russell King <rmk@arm.linux.org.uk>:
> I'll grant you that it does solve the "who owns a CONFIG_ symbol", but
> that is only one small problem - there's the bigger problem as to who
> owns each line of code.  Are we going to start labelling each source
> code line as well?

Per-file or per-directory should suffice, I think.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Nearly all men can stand adversity, but if you want to test a man's character,
give him power.
	-- Abraham Lincoln

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Matthew Kirkwood <matthew@hairy.beasts.org>:
> Eric wants an easy way to find the owner of a CONFIG_ entry.

No, I want much more than that.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall grow weary of the existing government,
they can exercise their constitutional right of amending it or their
revolutionary right to dismember it or overthrow it."
	-- Abraham Lincoln, 4 April 1861

Re: Request for comment -- a better attribution system

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> This is a proposal for an attribution metadata system in the Linux kernel
> sources.  The goal of the system is to make it easy for people reading
> any given piece of code to identify the responsible maintainer.  The
> motivation for this proposal is that the present system, a single
> top-level MAINTAINERS file, doesn't seem to be scaling well.

It has been my observation that human organizations over time grow
mechanisms for doing the routine (i.e., frequent) tasks quite efficiently,
while sporadic tasks are usually handled in ad hoc, case by case ways,
which can be very inefficient (and usually frustrating to the would-be
user).

In our case, the whole kernel development system is quite adept at soaking
up point patches (the bread-and-butter in LKM), while larger scope changes
(like the one you are proposing, and also some cleanup patch I proposed a
long while back, and the other scattered changes I've seen fly by) are very
infrequent and so not handled at all well.

Question is, is it really worth it to create specialized tools for this
very rare case? I suspect they would cost an enormous effort to create, and
will rot away before use. The observation by Alan that an applied (and even
a only proposed) patch will make somebody squeal if it steps on their toes
is perhaps the best tool for finding interested parties we can hope for in
a widely distributed, informal, and moreover ever changing development
organization. The MAINTAINERS file itself (maintainace of which is _much_
less work than what you propose) is (by your own account IIRC) incomplete
and out of date.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Horst von Brand <vonbrand@sleipnir.valparaiso.cl>:
> It has been my observation that human organizations over time grow
> mechanisms for doing the routine (i.e., frequent) tasks quite efficiently,
> while sporadic tasks are usually handled in ad hoc, case by case ways,
> which can be very inefficient (and usually frustrating to the would-be
> user).

Right you are.
 
> In our case, the whole kernel development system is quite adept at soaking
> up point patches (the bread-and-butter in LKM), while larger scope changes
> (like the one you are proposing, and also some cleanup patch I proposed a
> long while back, and the other scattered changes I've seen fly by) are very
> infrequent and so not handled at all well.

Indeed this is the case.  I think such global cleanups are, in fact, less
frequent than they should be precisely *because* lkml's social machinery
discourages them.

> Question is, is it really worth it to create specialized tools for this
> very rare case?

Yes, if the rare case of supporting global cleanups actually needs to be a
more common one.  Think about that for a while, please.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill.
	-- H. L. Mencken 

Re: Request for comment -- a better attribution system

[Francois Romieu]

Eric S. Raymond <esr@thyrsus.com> ecrit :
[...]
> Indeed this is the case.  I think such global cleanups are, in fact, less
> frequent than they should be precisely *because* lkml's social machinery
> discourages them.

May be it's a good thing: I^H Joe Average has some bright idea, does a
global cleanup, consume maintainers time. Problem: idea was not so bright or
actually really low priority one. Make him loose some hours and he will
think twice about the best way to spend time improving the kernel.
If we see a growing number of entry in the credits file for global changes
while drivers are not ported from 2.x to 2.x+2 (for example), there is be a 
*real* problem.
People get discouraged because of this ? I hope they'll never have to
elaborate fixes for braindead hardware.
Look again at l-k archive: people do global changes (see VFS, network api, 
etc...).

[...]
> > Question is, is it really worth it to create specialized tools for this
> > very rare case?
> 
> Yes, if the rare case of supporting global cleanups actually needs to be a
> more common one.  Think about that for a while, please.

I did and I feel we're building gaswork for nothing.
 
-- 
Ueimor

Re: Request for comment -- a better attribution system

[Alexander Viro]

On Sun, 22 Apr 2001, Francois Romieu wrote:

> Look again at l-k archive: people do global changes (see VFS, network api, 
> etc...).

And then we have the situation when about a half of filesystems has no
single maintainer - they are taken care of when needed, but that's it.
We also have _no_ official maintainer of VFS, and that's the way it's
gonna be.

Eric, it would save everyone a lot of time if you actually cared to
pull your head out of your... theoretical constructions and spent
some efforts figuring out how the things really work. Building
infrastructure before you get familiar with the problem domain is
generally considered harmful. That's precisely what you are doing.
Trust me, it doesn't earn you any respect from people familiar
with the problem.

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> Eric, it would save everyone a lot of time if you actually cared to
> pull your head out of your... theoretical constructions and spent
> some efforts figuring out how the things really work.

I've had my nose rubbed in how things really work.  That's why I want to
fix the things that are broken about how things really work.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"To disarm the people... was the best and most effectual way to enslave them."
        -- George Mason, speech of June 14, 1788

Re: Request for comment -- a better attribution system

[Alexander Viro]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:

> Alexander Viro <viro@math.psu.edu>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
> 
> I've had my nose rubbed in how things really work.  That's why I want to
> fix the things that are broken about how things really work.

Sigh... Would these broken things, by any chance, be "my grand ideas are
not met with applause"?

Take it from a guy who've done  quite a few global changes: they are pretty
much doable, but spamming maintainers with requests to support your k3wl
ideas is not a way to go. All you are getting that way is a bunch of procmail
rules.

Everyone who had been on l-k for more than a couple of months had seen
$BIGNUM of "visionary" lusers with grand schemes of Changing The World(tm)
and monumental lack of desire to learn. Until you demonstrate that you
understand what you are "fixing" - don't expect special treatment.

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> Sigh... Would these broken things, by any chance, be "my grand ideas are
> not met with applause"?

Nope.  Not at all.  Stay tuned, because I'll explain.

And before you write me off as one of the $BIGNUM clueless
visionaries, you might do well to remember that I actually *have*
radically changed the world lkml operates in.  At least twice.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

In the absence of any evidence tending to show that possession 
or use of a 'shotgun having a barrel of less than eighteen inches 
in length' at this time has some reasonable relationship to the 
preservation or efficiency of a well regulated militia, we cannot 
say that the Second Amendment guarantees the right to keep and bear 
such an instrument. [...] The Militia comprised all males 
physically capable of acting in concert for the common defense.  
        -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939)

Re: Request for comment -- a better attribution system

[Rik van Riel]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:

> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in.  At least twice.

Let me see ...

1) fetchmail, allowing dialup users to get lkml
2) getting snake.thyrsus.com out of ORBS and starting
   the mother of all lkml threads

Did I forget anything ?



Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Rik van Riel <riel@conectiva.com.br>:
> Let me see ...
> 
> 1) fetchmail, allowing dialup users to get lkml
> 2) getting snake.thyrsus.com out of ORBS and starting
>    the mother of all lkml threads
> 
> Did I forget anything ?

Yes, Rik, you did.  It's not `snake', it's `snark'.

:-)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Freedom, morality, and the human dignity of the individual consists
precisely in this; that he does good not because he is forced to do
so, but because he freely conceives it, wants it, and loves it.
	-- Mikhail Bakunin 

Re: Request for comment -- a better attribution system

[Alexander Viro]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:

> Alexander Viro <viro@math.psu.edu>:
> > Sigh... Would these broken things, by any chance, be "my grand ideas are
> > not met with applause"?
> 
> Nope.  Not at all.  Stay tuned, because I'll explain.
> 
> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in.  At least twice.

	So had certain wa.us-based company. If you refer to your "Cathedral
and Bazaar" - pardon me the bluntness, but it doesn't speak well of your
clue level.  L-k is not a place for detailed analysis of that text, so let
me just point to the fact that
	* you've ignored the robustness of design behind the UNIX kernel.
These beasts keep going without falling apart even after serious injuries.
	* you've ignored another factor - maintainer with a taste and ability
to say "no".
	* you've made a completely unwarranted assumption - that widely-used
and available code actually gets reviewed by many people.  It's demonstrably
false.

	Ability to do PR != having a shred of clue in other areas.
I'm sure that you can come up with relevant examples yourself.

Re: Request for comment -- a better attribution system

[Olaf Titz]

> 	* you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.

Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that we don't care any more. Here the robustness is in fact inertia.

Robust operation is possible with any halfway cleanly designed system,
cf. VMS.

Olaf

Re: Request for comment -- a better attribution system

[Alan Cox]

> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in.  At least twice.

I must have missed them 8)

Alan

Re: Request for comment -- a better attribution system

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Alexander Viro <viro@math.psu.edu>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
> 
> I've had my nose rubbed in how things really work.  That's why I want to
> fix the things that are broken about how things really work.

Then explain to everybody here in a language they'll understand _what_ is
wrong and _why_. Then propose a solution. I for one am not convinced you
have a "what", let alone a "why". And AFAIKS your solution will be an
enormous burden to maintain if it is not to rot away in a very short time.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Horst von Brand <vonbrand@sleipnir.valparaiso.cl>:
> Then explain to everybody here in a language they'll understand _what_ is
> wrong and _why_. Then propose a solution.

I'm on it.  You'll see the results fairly shortly.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
        -- Mike Royko, Chicago Tribune

Re: Request for comment -- a better attribution system

[Rik van Riel]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Horst von Brand <vonbrand@sleipnir.valparaiso.cl>:
> > Then explain to everybody here in a language they'll understand _what_ is
> > wrong and _why_. Then propose a solution.
> 
> I'm on it.  You'll see the results fairly shortly.

"Here, have this solution.  I'm sure there must be a problem for it."

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: Request for comment -- a better attribution system

[David Woodhouse]

esr@thyrsus.com said:
>  I've had my nose rubbed in how things really work.  That's why I want
> to fix the things that are broken about how things really work.

Then you're going to conjure up maintainers for the code which is currently 
orphaned?

For most stuff, the way to co-ordinate global changes is to discuss it on
l-k. If there's an active maintainer for parts which are affected, and if
they care, they'll respond to mail on l-k. That statement is a tautology
with my definition of 'active maintainer'. 

Bug reports are a red herring - users don't bother. They'll continue to 
sent idiotic bug reports to l-k for stuff which has already been reported 
and fixed, however we try to make life easy for them.

BTW, please try to ensure your .sig remains within the 4 lines recommended
by RFC1855. I appreciate that it's randomly chosen - but I also believe that
it's not beyond your capability to ensure that excessively long quotes are
not selected by whatever script provides the text to your MUA. If your 
political statement du jour cannot be expressed in one or two lines, it's 
inappropriate to include in mail to public fora.

--
dwmw2

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> esr@thyrsus.com said:
> >  I've had my nose rubbed in how things really work.  That's why I want
> > to fix the things that are broken about how things really work.
> 
> Then you're going to conjure up maintainers for the code which is currently 
> orphaned?

That's a *really* hard problem.  I don't know how to solve that one myself.

There are, however, other things that can be done to improve the way
things work.  Two things in particular: (1) to lower the technical and
social barriers to entry so that maintainers will conjure *themselves*
up with more frequency, and (2) to ... hmm, no, on reflection I think 
won't say that explicitly.  It would scare the conservatives too much.

However, if you think about it, you'll notice there's a common thread
in all the proposals I've been making.  If you still have trouble
seeing it, remember that I hack social systems as much as I hack code.
And consider lkml as a social machine.  And consider -- carefully --
the things it is demonstrably poor at.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Of all tyrannies, a tyranny exercised for the good of its victims may
be the most oppressive. It may be better to live under robber barons
than under omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they
do so with the approval of their consciences.
	-- C. S. Lewis

Re: Request for comment -- a better attribution system

[Rik van Riel]

On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> David Woodhouse <dwmw2@infradead.org>:
> > esr@thyrsus.com said:
> > >  I've had my nose rubbed in how things really work.  That's why I want
> > > to fix the things that are broken about how things really work.
> > 
> > Then you're going to conjure up maintainers for the code which is currently 
> > orphaned?
> 
> That's a *really* hard problem.  I don't know how to solve that one myself.

You could volunteer to maintain all the code you reveal
to be orphaned ...

*runs like hell*

cheers,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: Request for comment -- a better attribution system

[Roger Gammans]

On Sun, Apr 22, 2001 at 01:49:16PM -0300, Rik van Riel wrote:
> On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> > David Woodhouse <dwmw2@infradead.org>:
> > > Then you're going to conjure up maintainers for the code which is currently 
> > > orphaned?
> > 
> > That's a *really* hard problem.  I don't know how to solve that one myself.
> 
> You could volunteer to maintain all the code you reveal
> to be orphaned ...
> 
> *runs like hell*

I'm not sure Eric would have to.

It's entirley possible the problem will solve itself 
when/if people like myself who hang around the edge of 
kernel dev , find their favourite piece of kernel has
no maintainer - and volunteer. 

So Eric solution may get new maintainers to appear for orphaned code
as 'if by magic'

Alternatively not, of course.

TTFN
-- 
Roger
     Think of the mess on the carpet. Sensible people do all their
     demon-summoning in the garage, which you can just hose down afterwards.
        --     damerell@chiark.greenend.org.uk
	

Re: Request for comment -- a better attribution system

[esr]

Roger Gammans <roger@computer-surgery.co.uk>:
> It's entirley possible the problem will solve itself 
> when/if people like myself who hang around the edge of 
> kernel dev , find their favourite piece of kernel has
> no maintainer - and volunteer. 
> 
> So Eric solution may get new maintainers to appear for orphaned code
> as 'if by magic'
> 
> Alternatively not, of course.

This is part of my intention.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.

Re: Request for comment -- a better attribution system

[Horst von Brand]

Roger Gammans <roger@computer-surgery.co.uk> said:

[...]

> It's entirley possible the problem will solve itself 
> when/if people like myself who hang around the edge of 
> kernel dev , find their favourite piece of kernel has
> no maintainer - and volunteer. 

What stops you right now from to trying to find the maintainer(s) and work
with them on that very same piece of code? If nobody shows up, you could
take over if need be.

> So Eric solution may get new maintainers to appear for orphaned code
> as 'if by magic'

People who want to take over "because it is s00 k3w1 to be a maintainer"
with no real interest in the code, just in the fact that it is orphaned...
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Request for comment -- a better attribution system

[Roger Gammans]

On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> Roger Gammans <roger@computer-surgery.co.uk> said:
> 
> People who want to take over "because it is s00 k3w1 to be a maintainer"
> with no real interest in the code, just in the fact that it is orphaned...

No. People who want to give something back to the linux community
and want to find an option within their ability and time constariants.

TTFN
-- 
Roger
     Think of the mess on the carpet. Sensible people do all their
     demon-summoning in the garage, which you can just hose down afterwards.
        --     damerell@chiark.greenend.org.uk
	

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Roger Gammans <roger@computer-surgery.co.uk>:
> On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> > People who want to take over "because it is s00 k3w1 to be a maintainer"
> > with no real interest in the code, just in the fact that it is orphaned...
> 
> No. People who want to give something back to the linux community
> and want to find an option within their ability and time constariants.

Indeed.  Beware elitism.  If lkml become a closed society, it will become
a dead one shortly thereafter.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The great object is, that every man be armed. [...] 
Every one who is able may have a gun."
        -- Patrick Henry, speech of June 14 1788

CML2 Transition experiences

[jeff millar]

1. If I install CML2 and go directly to "make xconfig", it deduces it needs
to set top level options because some of the low level options are set.  For
example SCSI enabled because some SCSI device is set or hot plug because
PCMCIA is set...because some PCMCIA device is set.  The _problem_ is...none
of these options were set in the CML1 generated .config file... and it
_extremely_ tedious to use xconfig to clear out all the cruft.

A much better (but not yet right) way is to use "make ttyconfig" to quickly
generate config.out from .config  relatively fewer errors and ability to say
no at a top level and cause all the lower level stuff to go away.  make
ttyconfig seems to parse the .config file in a different (and better) order.

Suggestion:  On the first pass of CML2 processing through .config, before
first config.out created, trust the top level setting and ignore lower level
settings if top setting off.

2. So after some playing around, I want to go back to CML1.  But the .config
generated by CML2 is not compatible.  I don't know if it's supposed to be
but there's lots of problems.

Suggestion:  Save your .config before you play with this stuff.

Bottom line:  looks promising but I still haven't gotten a good compile from
it, yet.

jeff

Re: CML2 Transition experiences

[Eric S. Raymond]

jeff millar <jeff@wa1hco.mv.com>:
> 1. If I install CML2 and go directly to "make xconfig", it deduces it needs
> to set top level options because some of the low level options are set.  For
> example SCSI enabled because some SCSI device is set or hot plug because
> PCMCIA is set...because some PCMCIA device is set.  The _problem_ is...none
> of these options were set in the CML1 generated .config file... and it
> _extremely_ tedious to use xconfig to clear out all the cruft.
> 
> A much better (but not yet right) way is to use "make ttyconfig" to quickly
> generate config.out from .config  relatively fewer errors and ability to say
> no at a top level and cause all the lower level stuff to go away.  make
> ttyconfig seems to parse the .config file in a different (and better) order.

I'm finding this report very puzzling.  Both front ends parse the
.config in exactly the same order.  In fact, it's done by the same
code.
 
> Suggestion:  On the first pass of CML2 processing through .config, before
> first config.out created, trust the top level setting and ignore lower level
> settings if top setting off.

Because of the order tree traversal is done, I think ttyconfig should give
you the effect you want.
 
> 2. So after some playing around, I want to go back to CML1.  But the .config
> generated by CML2 is not compatible.  I don't know if it's supposed to be
> but there's lots of problems.

The config.out isn't exactly compatible; it has explicit CONFIG_FOO=n settings
in it.  The .config file generated from that by configtrans should be, however;
if it's not that's a bug.  Can you send me your "incompatible" .config so 
I can see the problems?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.

Linux 2.4.3-ac7

[Alan Cox]

	ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

		Intermediate diffs are available from

			http://www.bzimage.org

VIA users should test this kernel carefully. It has what are supposed to be 
the right fixes for the VIA hardware bugs. Obviously the right fixes are not
as tested as the deduced ones.

2.4.3-ac7
o	Updated VIA quirk handling for the chipset	(Andre Hedrick,
	flaws						 George Breese)
	| Experimental version removed
	| VIA users should check this kernel -carefully-!!!!
o	Remove KT7 dma kill				(me)
	| See above note
o	Merge Linus 2.4.4pre3
o	Fix winchip1 oops in mtrr from previous change	(me)
o	Add winchip3 support to mtrr/oostore		(me)
o	Fix the Zoran driver build			(me)
	| This is still not up to date with the master copy
	| that is intentional - first things first.
o	Fix CONFIG_WINCHIP kernel crash on cpu with	(me)
	fxsave
o	Fix UML options help bug			(Jeff Dike)
o	Fix pte corruption in user mode linux		(Jeff Dike)
o	Fix gdb and terminal initialisation in UML	(Jeff Dike)
o	UML code cleanup				(Jeff Dike)
o	Fix saved register corruption in UML		(Jeff Dike)
o	Add pci_disable_device				(Jeff Garzik)
o	Fix a slight bug in the parport help		(Tim Waugh)
o	Hopefully fix the sb1000 driver irq support	(James Anderson)
o	Fix missing signal lock in keventd		(Manfred Spraul)
o	Fix module build with io debugging on		(Markus Kossmann)
o	Fix dcache flag atomicty			(Al Viro)
o	Make cs4281 use pci_set_dma_mask, clean up 	(Jeff Garzik)
	wrappers
o	Use pci_set_dma_mask on maestro3		(Jeff Garzik)
o	Fix 3270 driver build bug 			(Dick Hitt)
o	Fix accidental sb driver bug revert		(Jeff Garzik)
o	Clean up PCI dependancies in sound drivers	(Jeff Garzik)
o	Update synclink driver				(Paul Fulghum)
o	rtl8139 driver update				(Jeff Garzik)
o	Update ps/2 esdi fixes to correct DMA access	(Hal Duston)
o	More aha1542 code marked __init			(Matthias Hanisch)
o	More random.c code marked __init		(Matthias Hanisch)

2.4.3-ac6
o	Remove tables.h include from fatfs_syms		(OGAWA Hirofumi)
o	Update UML					(Jeff Dike)
o	Protect more __KERNEL__ only stuff from 	(Phil Copeland)
	asm-alpha/io.h
o	Fix sound/Config.in bug with ARM		(Russell King)
o	Update network drivers for ARM bits		(Russell King)
	| 8390, pcnet_cs, tulip
o	Fix umount cleanups				(Al Viro)
o	Merge aic7xxx driver 6.11			(Justin Gibbs)
o	Added support for the pentium machine check	(me)
	| Also including thermal check
o	Add support for the winchip machine check	(me)
o	Fix mtrr support of the WinChip2		(me)
	| Existing code set uncachable not write gathering on winchip2
o	Support weak ordering mode on winchip cpus	(me)

2.4.3-ac5
o	Merge Linus 2.4.4pre1
o	New rwsem implementation			(David Howells)
o	Fix rwsem compile problem			(me)
o	Fix bust_spinlocks build fail if !CONFIG_VT	(me)
o	Merge Linus 2.4.4pre2 except for ipv6
o	Fix the corner case non zeroing bug in 		(me)
	copy_from_user for x86

2.4.3-ac4
o	Fix corruption case in ext2 inode handling	(Ingo Molnar, Al Viro)
o	Merge user mode linux port			(Jeff Dike)
o	Remove some surplus ifdefs from init/main.c	(me)
o	Update nwfpe					(Russell King)
o	Fix ps2esdi driver				(Hal Duston)
o	Update ARM documentation			(Russell King)
o	Update Symbios 53c8xx driver			(Gérard Roudier)
o	ARM frame buffer update				(Russell King)
o	Update ARM bootstrap code			(Russell King)
o	Eicon driver fix				(Armin Schindler)
o	Update S/390 Documentation			(Utz Bacher, Carsten
o	Update S/390 math emulation			 Otte, Holger Smolinski
o	S/390 tape driver				 Martin Schwidefsky
o	PAGEX support for Linux/390 under VM		 and probably others)
o	General S/390 fixes
o	Update S/390 tty drivers
o	Update S/390 irq handling
o	Update S/390 channel driver
o	Update S/390 include files
o	Update S/390 networking drivers
o	Update S/390 DASD drivers
o	Update S/390 mm to match generic mm changes
o	Update S/390 makefiles
o	Catch another subspecies of misidentifying CD	(Bob Mende Pie)
o	Fix bluesmoke formatting			(Solar Designer)
o	Fix rx error handling in rtl8139		(Jeff Garzik)
o	Update paths to e2fsprogs			(Steven Cole)
o	Fix proc alloc map locking			(Tom Leete)
o	Console blanking fix (continued..)		(Mikael Pettersson)
o	ARM tools update				(Russell King)
o	Update ARM includes				(Russell King)
o	Update ARM sound drivers			(Russell King)
o	Update the shark ARM support			(Alexander Schulz)
o	Update SA1100 support				(Russell King,
							 Nicolas Pitre)
o	Update ARM make and config files		(Russell King)
o	Update ARM mm/fault handling			(Russell King)
o	Update ARM network driver config		(Russell King)
o	Misc ARM updates				(Russell King)
o	Update ARM footbridge code			(Russell King)
o	EBSA ISA bus fixups				(Russell King)
o	Fix agp copy_from_user bug			(Dawson Engler)
o	Correct devfs docs on /dev/sg			(Herbert Xu)
o	/dev/sg doc update 				(Douglas Gilbert)

2.4.3-ac3
o	Fix console unblank from suspend bug		(Mikael Pettersson)
o	Fix unmap_buffer() race				(Al Viro)
o	Add a proper dmi blacklist			(me)
o	Fix alpha build for new mm changes		(Ivan Kokshaysky)
o	Resync setup-bus.c to pick up Alpha Noritake	(Ivan Kokshaysky)
	fixes
o	Fix swap accounting for major faults		(Marcelo Tosatti)
o	Add some bigendian support and voodoo5 support	(Ani Joshi)
	to tdfxfb
o	Fix failing build with CONFIG_VT=n		(Jason McMullan)
o	Fix some corner cases in iso9660 support	(Andreas Eckleder)
	for symlinks and XA attriubtes
o	Fix NTFS and quota sparc build problems on -ac	(Steve Ralston)
o	Resync to the Linus serial.c + B9600 fix	(me)
o	Avoid nasties with OHCI controller gets no IRQ	(Arjan van de Ven)
	assigned
o	Pull problem lance change			(Jeff Garzik)
o	Fix SMP lockup in usbdevfs			(Tony Hoyle)
o	Firestream atm update			(Patrick van de Lageweg)

2.4.3-ac2
o	Add the VIA C3 to the mtrr/setup code		(Dave Jones)
o	Report PAE mode oopses better			(Ingo Molnar)
o	Fix zap_low_mappings on PAE			(Hugh Dickins)
o	Tidy up parport resource handling, fix bug	(Tim Waugh)
o	Add series 6 backpack driver support		(Tim Waugh)
o	Make lockd use daemonize()			(Paul Mundt)
o	Fix aicasm to specify -I flags needed on some	(Mads Jørgensen)
	distributions
o	Add docbook manual on bus independant I/O	(Matthew Wilcox)
	| + a few additional notes I added
o	Make the VIA superIO driver honour the		(Tim Waugh)
	irq/dma settings passed
o	Update mpt fusion drivers			(Steve Ralston)
o	Add reiserfs maintainer entries			(Steven Cole)
o	Experimental driver for communcation class USB	(Brad Hards)
	| eg Broadcom and Ericsson USB cable modems
o	I2O updates, report SMART errors on i2o_block	(Boji Kannanthanam)
o	Fix shm locking, races on swapping, accounting	(Stephen Tweedie)
	and swapout of already mapped pages
o	Clean up REPORTING-BUGS				(Steven Cole)
o	Fix ACM handling of CLOCAL			(Vojtech Pavlik)
o	Fix sparc64 module_map/vfree bug		(Hugh Dickins)
o	Fix scsi race on requeued requests		(Mark Hemment)
o	Tulip driver update				(Jeff Garzik)
o	Update bmac and gmac driver			(Cort Dougan)
o	Winbond w9966cf webcam parport driver		(Jakob Kemi)

2.4.3-ac1
o	Merge Linus 2.4.3 final, diff versus 2.4.3	(me)

2.4.2-ac28
o	Fix another modules race			(me)
o	Add basic PM hooks to agpgart			(me)
o	Update new xircom_cb driver			(Arjan van de Ven)
o	Fix missing lock_kernel on truncate path	(Al Viro)
o	Update klsi usb ethernet ids			(Brad Hards)
o	Fix missing permission check in shm code	(Matthew Klahn)
o	Add extra doupdate() calls to menuconfig	(Moritz Schulte)
o	Update wireless extensions			(Jean Tourrilhes)
o	Fix cdda reading problem			(Jens Axboe)
o	Fix potential oops in usb-uhci			(David Brownell)

2.4.2-ac27
o	Rely on BIOS to setup apic bits on OSB4		(me)
o	Disable events when unloading cardbus yenta	(me)
	| Fixes shared irq unload hang
o	Fix x86 IPI replay problems			(Stephen Tweedie)
o	Add ALS100 gameport support			(Vojtech Pavlik)
o	Fix wrong path in comment in vesafb		(Andres Salomon)
o	Allow slab caches to force alignment always	(Ingo Molnar)
	and thus fix PAE+ slab poisoning
o	Fix problems in faulting raw I/O pages		(Stephen Tweedie)
o	Fix rawio error handling for raw I/O		(Stephen Tweedie)
	| + other oddments
o	Change default max printer ports to 8		(Tim Waugh)
o	Parport soft control state fixes		(Tim Waugh)
o	Fix cpu info compile				(Constantine Gavrilov)
o	Set warning levels on reiserfs warn etc		(Paul Mundt)
o	Fix duplicate IOVIRT debug config help		(Steven Cole)
o	Revert mmap change that broke assumptions (and	(Martin Diehl)
	it seems SuS) 
o	Clean up fpu emu warnings on gcc 3.0cvs a bit	(me)

2.4.2-ac26
o	Fix es1370 build bug				(me)
o	Fix sbpcd compile warnings			(me)
o	Update usbnet driver				(Oleg Drokin)
o	Update Alpha to pre8 vm changes			(Ivan Kokshaysky)
o	Fix radeonfb config selections			(Chris Lawrence)
o	Fix vmalloc mismerge				(Various)
o	Fix n_r3964 console panic			(Andrew Morton)
o	Update ibm camera drivers
o	Support 701b toshoboe fir
o	New xircom_cb driver		(Arjan van de Ven, Jeff Garzik,
					 Don Becker, Doug Ledford)
o	Fix procfs mount point for binfmt_misc		(Al Viro)
o	Update hpt366 ide blacklist
o	Further ide blacklist updates
o	Smooth vm balancing				(Marcelo Tosatti)
o	Fix irda assert					(Arjan van de Ven)
o	Keep contrack cache sizes sane			(Ben LaHaise)
o	Fix possible file truncate/write race		(Ben LaHaise)
o	Make bootmem panic sanely on out of memory	(Ben LaHaise)
o	Fix unload crash in pci_socket			(me)
o	Revert previous wrong bootmem change		(Ben LaHaise)

2.4.2-ac25
o	Handle PCI/ISA simple MP tables via ELCR	(John William)
o	Fix get_sb_single				(Al Viro)
o	Update es1370, es1371,esssolo			(Thomas Sailer,
							 Tjeerd Mulder,
							 Nathanial Daw)
o	Update orinoco_cs				(Jean Tourilhes)
o	Fix races found in the new kbd/console code	(Andrew Morton)
o	Remove dead timer.h docs			(Tim Wright)
o	Update ppc to new generic mm changes		(Paul Mackerras)
o	Clean up mdacon					(Paul Gortmaker)
o	Remove duplicate configure.help texts		(Steven Cole)
o	Fix symbol export for shm_file_open		(Keith Owens)
o	First batch of pointer reference bug fixes	(Andrew Morton)
	from Stanford report
o	Fix de4x5 oops on Alpha XP1000			(George France)
o	Chipsfb update					(Paul Mackerras)
o	Fix higmem block_prepare_write crash		(Stephen Tweedie)
o	Bring PAE36 back up to date, handle x86 errata	(Ingo Molnar)
o	Fix ov511 crash if opened while loading		(Pete Zaitcev)
o	Merge Linus 2.4.3pre8
o	Update Advansys scsi driver			(Bob Frey)

2.4.2-ac24
o	Fix build bug with tsc in ac23			(me)
o	Update contact info for Phil Blundell		(Phil Blundell)
o	Update mm locking comments/rss locking		(Andrew Morton)
o	Update toshiba SMM driver			(Jonathan Buzzard)
o	Update old adaptec driver to 5.2.4		(Doug Ledford)
o	CS46xx updates					(Tom Woller)
o	Quieten input layer printks a bit		(me)
o	Turn off APIC_DEBUG by default to cut noise down(me)
o	Add Orinoco PCMCIA wireless support		(David Gibson)
o	Go back to 2.4.3pre6 tulip			(Jeff Garzik)
o	Fix double accounting of cpu time bug		(Kevin Buhr)
o	Drop ppp patch					(me)

2.4.2-ac23
o	Fix a nasty shared memory locking bug		(Stephen Tweedie)
o	Fix off by one bootmem memory corruptor		(Ben LaHaise)
o	Fix avmb1 oops on init				(Carsten Paeth)
o	Fix isdn makefile bugs				(Kai Germaschewski)
o	Clean up isdn minor checks			(Julien Gaulmin)
o	Workaround PPP CCP negotiation bugs		(Kai Germaschewski)
o	Fix timer handling bug in ISDN			(Henk-Jan Slotboom)
o	Fix i386 #ifdef bug with notsc disable		(Anton Blanchard)
o	Fix NMI docs					(Keith Owens)
o	Fix oops on out of memory in proc_symlink	(me)
	| Found by Stanford tools
o	Fix oops caused by devfs changes to soundcore	(me)
	| Found by Stanford tools
o	Fix rmmod crash on sundance alta		(me)
	| Found by Stanford tools
o	Fix potential crash in nsc-ircc.c		(me)
	| Found by Stanford tools
o	Fix memory leak in i810 audio			(Doug Ledford)
o	Fix several compile warnings with gcc 3.0 cvs	(J Magallon)
o	Mark 60Hz modes in mac fb modes 		(Geert Uytterhoeven)
o	Chkconfig and ver_linux updates			(Niels Jensen)
o	Fix ctrlfb dac timing				(Takashi Oe)
o	Add vesa powerdown support for ctrlfb		(Takashi Oe)
o	Back out problem via bridge change		(me)
o	Fix bug in aironet4500_cs changes		(Arjan van de Ven)

2.4.2-ac22
o	Fix dereference after free in megaraid driver	(me)
o	Fix crash if we run out of memory during a link	(me)
	follow [found by Stanford tools]
o	Fix crash if we run out of memory during
	block_truncate_page [found by Stanford tools]	(me)
o	Update Alpha to pre6 style pte/pmd_alloc	(Ivan Kokshaysky)
o	Fix ppp memory corruption			(Kevin Buhr)
	| Bizzarely enough a direct re-invention of a 1.2 ppp bug
o	Fix heavy stack usage in tty_foo_devfs()	(Jeff Dike)
o	Make alloc_tty_struct always use kmalloc	(Andrew Morton)
o	Document task struct locking rules		(Andrew Morton)
o	Document SAK properly				(Andrew Morton)
o	Fix SAK deadlocks				(Andrew Morton)
o	Fix inline/type order for picky compiler tools	(Dave Jones)
o	Fix printk levels for various fs printks that	(Andrey Panin)
	lacked them
o	Next incarnation of the i810 audio driver	(Doug Ledford)
o	Add __init stuff to 3c515 driver	(Andrzej Krzysztofowicz)
o	Add __init stuff to ppp layer		(Andrzej Krzysztofowicz)
o	Remove duplicate NF_TARGET_TCPMSS config text	(Steven Cole)
o	Fix missing unlock_kernel in pcwd		(me)
	| Found by Stanford tools
o	Fix missing unlock_kernels in es1371		(me)
	| Found by Stanford tools
o	Fix missing unlock_kernels in es1370		(me)
	| Found by Stanford tools
o	Fix missing unlock_kernels in esssolo1		(me)
	| Found by Stanford tools
o	Fix missing unlock kernels in sonicvibes	(me)
	| Found by Stanford tools
o	Fix missing unlock kernels in fb mmap		(me)
	| Found by Stanford tools
o	Fix missing unlock_super in UFS code		(me)
	| Found by Stanford tools


2.4.2-ac21
o	Merge with Linus 2.4.3pre6
o	Close last known reiserfs tail bug		(Chris Mason)
o	Fix link order bug with iso8859_8 and cp1255	(Dan Aloni)
o	Generate generic CPU namings for 386/486	(Cesar Eduardo Barros)
o	First set of ISDN fixes from Stanford code	(Kai Germaschewski)
	analyser
o	Allow up to 16 parallel ports by default	(Tim Waugh)
o	Use long delays on low speed usb hub ports	(Pete Zaitcev)
o	Update credits for assorted Australians		(Stephen Rothwell)
o	Fix ali_restore_regs thinko			(Pavel Roskin)
o	Fix whiteheat usb driver bugs			(Greg Kroah-Hartman)
o	Fix kfree in belkin_sa				(Greg Kroah-Hartman)
o	Fix omninet copy*user bug			(Greg Kroah-Hartman)
o	Fix modular atyfb				(Geert Uytterhoeven)
o	Update joystick and input drivers		(Vojtech Pavlik)
o	Relax checksum enforcement on ISAPnP CSN	(Gunther Mayer)
o	Resync ids/comments with ISDN cvs		(Kai Germaschewski)
o	Update Harald Hoyer Credits entry		(Harald Hoyer)
o	Fix off by 2* mtrr handling bug			(David Wragg)
o	Fix irda hang on boot				(Dag Brattli)
o	FB device init updates				(Geert Uytterhoeven)
o	Add it8712 misp eval board support		(P. Popov)
o	Update NEC DDB5476 eval board support		(Jun Sun)
o	Update NEC DDB5074 eval board support		(Ralf Baechle)
o	Add Karsten Merker and Michael Engel to credits	(Ralf Baechle)
o	Update Baget port				(Vladimir Roganov,
							 Gleb Raiko)
o	Add LVM ioctls to sparc64 ioctl32 convertor	(Patrick Caulfield)
o	Powerpc updates for openfirmware mm, python etc	(Cort Dougan)
o	Add the casio qv digitalcamera to the usb
	unusual devices list				(Harald Schreiber)
o	atyfb mode updates for powermac			(Olaf Hering)
o	Fix khubd locking				(Pete Zaitcev)
o	More on the great aic7xxx libdb game		(Nathan Dabney)
o	Further console handling updates		(Andrew Morton)
o	Fix i2o build problem when half modular		(Michael Mueller)
o	Fix off by one in prink <foo> check		(Mitchell Blank Jr)
o	Fix do_swap_page hang				(Linus Torvalds)

2.4.2-ac20
o	Add support for the GoHubs GO-COM232		(Greg Kroah-Hartman)
o	Remove cobalt remnants				(Ralf Baechle)
o	First block of mm documentation			(Rik van Riel)
o	Replace ancient Zoran driver with new one	(Serguei Miridonov,
				Wolfgang Scherr, Rainer Johanni, Dave Perks)
o	Fix Alpha build					(Jeff Garzik)
o	Fix K7 mtrr breakage				(Dave Jones)
o	Fix pcnet32 touching resources before enable	(Dave Jones)
o	Merge with Linus 2.4.3pre4

2.4.2-ac19
o	Typo fixes					(David Weinehall)
o	Merge first block of OHCI non x86 support	(Greg Kroah-Hartman)
o	Add Edgeport USB serial support			(David Iacovelli,
							 Greg Kroah-Hartman)
o	Fix doorlock on scsi removables			(Alex Davies)
o	Fix hang when usb storage thread died		(me)
o	Change watchdog disable setup			(Ingo Molnar)
o	Fix bluetooth close and error bugs		(Narayan Mohanram)
o	mpt now has an assigned minor			(me)
	| Remember to fix your /dev/mptctl if using MPT
o	Clean up 3270 ifdefs/printk a little		(me)
o	Fix NBD deadlocks and update it 		(Steve Whitehouse)
o	Fix sercon printk divide by zero bug		(Roger Gammans)
o	Remove cosine support from MIPS tree		(Ralf Baechle)
o	bust_spinlocks for Alpha			(Jeff Garzik)
o	Hopefully fix the buslogic corruptions		(me)
	| This is a 'test if they went away' release not a 'its fixed' one.
o	Some mips makefile fixes			(Ralf Baechle)
	| except mips/kernel/Makefile (I got .rej Ralf)
o	ARC firmware interface fixes			(Harald Koerfgen)
o	DECstation console drivers			(Michael Engel,
							 Karsten Merker,
							 Harald Koerfgen)
o	Fix ipx build bug				(Anton Altaparmakov)
o	Fix ptrace race 				(Stephen Tweedie)
o	Update include/config.h stuff, ver_linux	(Niels Jensen)
o	Add missing pci_enable_device to cs4281		(Marcus Meissner,
							 Thomas Woller)
o	Fix non PPC build of clgenfb			(Andrew Morton)
o	Update CPU docs					(Dave Jones)
o	Add mips atlas/malta reference boards		(Carsten Langgaard)
o	Add gt91600 ethernet support			(SteveL)
o	Add philips SAA9730 ethernet			(Carsten Langgaard)
o	PCnet32 driver fixes				(Carsten Langgaard)
o	MIPS fpu emulator	(Algorithmics, Ralf Baechle, Kevin Kissell, 
			Carsten Langgaard, Harald Koerfgen, Maciej Rozycki)
o	mips network driver updates			(Ralf Baechle)
o	Fix FC920 workarounds in i2o			(me)
o	Fix i2o_block hang on exit, 0 event race	(me)
o	FIx i2o_core thread kill wakeup race		(me)
o	Backport 2.2 VIA 686a clock reset workaround	(Arjan van de Ven)
o	Further documentation updates			(Matthew Wilcox)

2.4.2-ac18
o	Debian has another location for db3		(Marc Volovic)
o	Remove duplicated flush_tlb_page export on 	(Elliot Lee)
	Alpha
o	Fix SB Live! build on SMP Alpha			(Elliot Lee)
o	Fix disk corruption on qlogicisp and qlogicpti	(Arjan van de Ven)
o	Fix reporting of >4Gig of swap			(Hugh Dickins)
o	Fix sign issues in mpt fusion			(Andrew Morton)
o	CMS minidisk file system (read only)		(Rick Troth)
			2.4 port			(me)
o	Disable nmi watchdog by default			(Andrew Morton)
o	Fix elsa_cs eject problems			(Klaus Lichtenwalder)
o	Remove duplicate config entries			(Steven Cole)
o	Fix further wrong license references	(Andrzej Krzysztofowicz)
o	Add nmi watchdog disable for sysrq		(Andrew Morton)
o	Experimental test for serverworks/intel AGP	(me)
	comptability
o	Fix ipx reference counting for routes		(Arnaldo Carvalho
							 de Melo)

2.4.2-ac17
o	Make the aic7xxx code handle multiple db3 paths	(me)
o	Small further via updates			(Vojtech Pavlik)
o	IDE tape updates for Onstream tape drives	(Marcel Mol)
o	Remove some bits of module.c that cant get	(Keith Owens
	executed					 Andrew Morton)
o	Configure.help fixups				(Steven Cole)
o	Add Cyrix MTRR data				(Dave Jones)
o	Fix a slight bogon in the i386 Makefile		(Dave Jones)
o	Kill an escaped modversions.h			(Keith Owens)
o	Further controlfb fixes				(Takashi Oe)
o	Fix console driver oops	in new locking		(Andrew Morton)
o	Add 'broken-psr' so you can command line tell	(Neale Banks)
	APM your BIOS is crap
o	Fix serial console 				(Dave Jones)
o	Fix megaraid kernel_version string		(Arjan van de Ven)
o	Fix off by one error in cpia			(Andrew Morton)
o	Fix lost dmfe typo fix				(Torsten Duwe)
o	Take kernel_lock for i_truncate method in 	(Al Viro)
	vmtruncate
o	Fix i2c sign check bug				(Andrew Morton)

2.4.2-ac16
o	Uniprocessor APIC fixes for misdetect		(Mikael Pettersso)
o	Small ymf_pci fixes/updates			(Pete Zaitcev)
o	Fix break support on sx serial			(Rogier Wolff)
o	Kill another dead config.in entry		(Steven Cole)
o	Add bust spinlocks logic to S/390		(Neale Ferguson)
o	Fix ramdisk buffer only page bug		(Philipp Rumpf)
o	Mark ips scsi experimental until IBM ship a 	(Adam Lackorzynski)
	proper 2.4 driver
o	Update lanstreamer to use module_init and more	(Mike Sullivan)
o	Switch to the updated irda fixes		(Jean Tourrilhes)
o	Vaio kaweth ethernet apparently has its own id	(Sven Anders)
o	d_validate clean ups 				(Petr Vandrovec)
o	Network further fixes from DaveM and co		(Dave Miller
	| This might fix the reported masuqerade crashes Alexey Kuznetsov
							 Werner Almesberger)
o	Acenic updates					(Jes Sorensen)

2.4.2-ac15
o	Add CyrixIII specific kernel configuration	(me)
	| Note there are CyrixIII problems with some distribution installers
	| because -m686 gcc output will not run on a model 6 cpu with no
	| cmov. 
o	Fix aic Makefile for older gnu make		(Keith Owens)
o	Assorted i2o updates/partition handling fixes	(Boji Kannanthanam)
o	Fix dcache problems with ncpfs			(Petr Vandrovec)
o	Update via drivers to 3.22			(Vojtech Pavlik)
o	Account for packet bytes on lmc driver		(Ernst Lehmann)
o	Atyfb rearrange					(Geert Uytterhoeven)
o	Fix sedlbauer_cs build bug add elsa_cs		(Than Ngo)
	| 			elsa_cs driver by	(Klaus Lichtenwalder)
o	Add support for the Fuji FinePix 1400Zoon	(Nate)
o	EISA initialisation changes for 3c59x		(Andrzej Krzysztofowicz)
o	Assorted small net protocol updates		(Dave Miller)
o	Fix dvd physical read bug			(Jens Axboe)
o	Fix ATM hang on SMP 				(Mike Westall)
	| more work left to do on atm_ioctl for someone
o	Changed get_addr and friends to atm_get_addr	(me)
o	Merge Linus 2.4.3pre3
o	Fix do_BUG for both cases this time		(me)
o	Fix prefetch for Athlon build
o	Fix an lvm oops case				(Pete Zaitcev)
o	Remove dead config.in entry			(Steven Cole)
o	Update reiserfs recommended tool revision	(Steven Cole)
o	Kill a few warnings				(Keith Owens)

2.4.2-ac14
o	Fix the non build problem with do_BUG		(Andrew Morton)
o	Fix interface autocreation bug in ipx		(Arnaldo Carvalho
	Also fix pprop routing bugs, tctrl handling	 de Melo)
	Fix wrong comments, fix ipx sysctl handling
	clean up code
o	Updated i810_audio.c 				(Doug Ledford)
o	Fix up printer status readback			(Tim Waugh)
o	Add support for "ide=nodma" on command line	(Arjan van de Ven)
o	More spelling fixes				(Dag Wieers)
o	Add pci vendor table to lanstreamer		(Mike Sullivan)
o	Do extra sanity checks on ext2 mount		(Andreas Dilger)
o	Multithreaded core dump handling		(Don Dugger)
	| This is fairly experimental so the more eyes
	| the better but it does sort out a very annoying weakness
o	Prefetch on lists for parisc and x86		(Arjan Van de Ven,
	| Work about 4% on scheduler performance on PIII Matthew Wilcox)
o	Natsemi power management changes		(Tjeerd Mulder)
o	Fix assorted smb bugs				(Urban Widmark)
o	Fix a sisfb build problem			(Andrew Morton)

2.4.2-ac13
o	Clean up mad16 detection stuff			(Pavel Rabel)
o	Fix epca unload					(Andrey Panin)
o	Change null apic handling			(Maciej Rozycki)
o	aicasm now uses db3				(Sergey Kubushin)
o	Fix aic7xxx cross compile			(Cort Dougan)
o	Merge small net driver fixups/config fixes	(Jeff Garzik)
o	Update symbios drivers				(Gérard Roudier)
o	Rusty has moved					(Rusty Russell)
o	3c509/3c515 compile fixes			(Jeff Garzik)
o	Console locking updates - should fix vesafb	(Andrew Morton)
	clock problems
o	Merge the serial.c 5.0.5 update			(Jeff Garzik, 
							Ted Ts'o)
o	Merge SiS framebuffer updates			(Can-Ru Yeou)
o	Update ctrlfb					(Takashi Oe,
							 Michel Lanners)
o	Add epson 640U scanner to the usb scanner list	(Patrick Dreker)

2.4.2-ac12
o	Move the pci_enable_device for cardbus		(David Hinds)
o	Add Sony MSC-U01N to the unusual devices	(Marcel Holtmann)
o	Final smc-mca fixups - should now work		(James Bottomley)
o	Document kernel string/mem* functions		(Matthew Wilcox)
	| and I added a memcpy warning
o	Update VIA IDE driver to 3.21			(Vojtech Pavlik)
	|No UDMA66 on 82c686, fix /proc and udma on
	|686b, fix dma disables
o	Allow sleeping in ctrl-alt-del callbacks	(Andrew Morton)
	|Fix i2o, dac960, watchdog, gdth hangs on exit
o	Fix binfmt_misc (and make the proc handling	(Al Viro)
	|a filesystem -
	|mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
o	Update the ACI support for sound/radio stuff	(Robert Siemer)
o	Add RDS support to miroRadio			(Robert Siemer)
o	Remove serverworks handling. The BIOS is our	(me)
	best (and right now only) hope for that chip
o	Tune the vm behavioru a bit more		(Mike Galbraith)
o	Update PAS16 documentation			(Thomas Molina)
o	Reiserfs tools recommended are now 0d not 0b	(Steven Cole)
o	Wan driver small fixes				(Jeff Garzik)
o	Net driver fixes for 3c503, 3c509, 3c515,	(Jeff Garzik)
	8139too, de4x5, defxx, dgrs, dmfe, eth16i, 
	ewrk3, natsemi, ni5010, pci-skeleton, rcpci45,
	sis900, sk_g16, smc-ultra, sundance, tlan,
	via-rhine, winbond-840, yellowfin, wavelan_cs
	tms380tr
o	Trim 3K off the aha1542 driver size	(Andrzej Krzysztofowicz)
o	Trim 1K off qlogicfas			(Andrzej Krzysztofowicz)
o	Fix openfirmware/mm boot on ppc			(Cort Dougan)
o	Fix topdir handling in Makefile			(Keith Owens)
o	Minor fusion driver updates			(Steve Ralston)
o	Merge Etrax cris updates			(Bjorn Wesen)
o	Clgen fb copyright update			(Jeff Garzik)
o	AGP linkage fix					(Jeff Garzik)
o	Update visor driver to work with minijam	(Arnim Laeuger)
o	Fix a usb devio return code			(Dan Streetman)
o	Resync a few other net device changes with the
	submits Jeff sent to Linus			(Jeff Garzik)
o	Add missing md export symbol			(Mohammad Haque)

2.4.2-ac11
o	Fix NLS Config.in				(David Weinehall)
o	Sort out one escaped revert from the megaraid	(me)
	update
o	Resync with Linux 2.4.3pre1
	| Except tulip the network driver changes have
	| been used to replace the existing ones
o	Fix parport case where a reader could get stuck	(Tim Waugh)
o	Add ALi15x3 to the list of isa dma hangs	(Angelo Di Filippo)
o	Fix nasty bug in IPX routing of netbios frames	(Arnaldo Carvalho
							 de Melo)
o	Misc code cleanups				(Keith Owens)
o	Updated 3c527 driver				(Richard Proctor)
o	Further tulip updates				(Jeff Garzik)
o	i810_rng fixes (FIPS test, regions)		(Jeff Garzik)
o	Further cs89x0 cleanups				(Andrew Morton)
o	Further USB hub updates				(Dave Brownell)
o	Mall USB resource cleanup			(Jeff Garzik)
o	Resync hp100 changes from Jeff Garzik		(Jeff Garzik)
o	PCI documentation update			(Tim Waugh)
o	Fix irda crash					(Jean Tourrilhes)
o	PPC updates					(Cort Dougan)
o	Resync dmfe, hamachi, pci-skeleton and winbond	(Jeff Garzik)

2.4.2-ac10
o	Add ZF-Logic watchdog driver			(Fernando Fuganti)
o	Add devfs support to USB printers		(Mark McClelland)
o	Fix baud rate handling on keyspan		(Paul Mackerras)
o	USB documentation update			(Dave Brownell)
o	Fix disconnect leak				(Randy Dunlap)
o	ARM constants/fixes				(Russell King)
o	Includes for integrator ARM architecture	(Russell King)
o	Update NLS descriptions to be clearer		(Pablo Saratxaga)
o	Add iso-8859-13 (latvian/lithuanian)		(Pablo Saratxaga)
	iso-8859-4, cp1251 (windows cyrillic), cp1255
	(windows hebrew), and some alises
o	Merge 1.14 Megaraid driver			(Venkatesh Ramamurthy)
o	Reapply other fixes this version dropped	(me)
o	Reformat and clean up ifdefs in 1.14 Megaraid	(me)
o	I/O apic locking fixes				(Maciej Rozycki)
o	Print ioapic id to help debugging		(Maciej Rozycki)
o	Make the tpqic driver work			(Hugh Dickins)
o	USB scanner updates				(David Nelson)
o	Fix usbdevfs multimount				(Al Viro)
o	Fix wrong calculation of path buffer size	(Hugh Dickins)
o	cs89x0 allocated far too much memory		(Hugh Dickins)

2.4.2-ac9
o	misc device fix (ps/2 and drm are now back)	(Tachino Nobuhiro)
	| Believe it or not my main test box used no misc
	| device files..
o	Radeon build without 8bit			(Cha Young-Ho)
o	Fix oops in scc driver				(Andrew Morton)
o	Add __setup for ISAPnP, update docs		(Jaroslav Kysela)
o	Update E820 table sanitizer			(Brian Moyle)
o	i810 audio updates/mmap fixes			(Doug Ledford)
o	Be paranoid about VIA chipset configurations	(Arjan van de Ven)
	| Fixing VIA disk corruption bugs take 2
o	Fix PPC request_irq problems, some fpu emu	(Cort Dougan)
	and timers
o	Allow scsi drivers to limit request sizes	(Jens Axboe,
	(and fixed by Tim)				 Tim Waugh)
o	Configure.help cleanups				(Steve Cole)
o	Loop device fix of the day			(Jens Axboe)
o	CDROM fixes					(Jens Axboe)
o	Reiserfs crash on fsync of dir fix	(Alexander Zarochentcev)

2.4.2-ac8
o	Fix loop over loop crash			(Jens Axboe)
o	Fix radeon build problems			(ISHIKAWA Mutsumi)
o	Stop two people claiming the same misc dev id	(Philipp Rumpf)
o	capable not suser on sx.c			(Rob Radez)
o	Fix an ixj build combination bug	(Andrzej Krzysztofowicz)
o	Add integrator to ARM machines			(Russell King)
o	ARM include/constant cleanups			(Russell King)
o	Update ARM vmlinuz.in				(Russell King)
o	ARM i2c fixes					(Russell King)
o	ARM scsi updates				(Russell King)
o	ARM header updates				(Russell King)
o	Handle E820 bios returns with overlaps		(Brian Moyle)
o	Fix a sparc64 include build bug		(Andrzej Krzysztofowicz)
o	Loop race fix					(Jens Axboe)
o	s_maxbytes wasnt set for old style compat	(Chris Dukes)
	mounts in reiserfs
o	Fix the fact we dont see all busses on some	(Don Dupuis)
	Compaq machines
o	Fix missing watchdog configure.help		(Jakob Ostergaard)
o	Fix oom deadlock (hopefully)			(Rik van Riel)
o	Fix binfmt_aout sign handling bug		(Andrew Morton)

2.4.2-ac7
o	Fusion driver updates				(Steve Ralston)
o	Olympic fix					(Andrew Morton)
o	Work around hardware bug in older Rage128	(Gareth Hughes)
o	Handle broken PIV MP tables with a NULL ioapic
o	Use capable in esp serial driver		(Rob Radez)
o	Use capable not suser in console		(Rob Radez)
o	Small networking fixups				(Dave Miller)
o	Fix make menuconfig breakage			(Keith Owens)
o	Enable cmpxchg8 on Rise P6			(Dave Jones)
o	Fix wakeup losses on cpu_allowed using tasks	(Manfred Spraul)
o	Maestro3 now works with > 256Mb of ram		(Zach Brown)
o	Opl3sa2 isapnp=0 handling was wrong		(Jérôme Augé)
	| I've fixed it a little differently however
o	Turn off slow kmem chain check if not doing	(Ingo Molnar, me)
	slab debugging
o	Fix cpu speed checking code			(Mikael Pettersson)
o	Make bus computation more accurate		(me)
o	Advantech watchdog driver			(Marek Michalkiewicz)
o	dz.c serial clean up				(Rob Radez)
o	Fix MSG_TRUNC for OOB TCP			(Ingo Molnar)
o	Fix oops on unconfigured loop			(Arjan van de Ven)
o	Drop nbd ll_rw_blk change			(Linus has spoken ;))
o	pci resource api				(Jeff Garzik)
o	Further Natsemi updates				(Don Becker, 
							 Jeff Garzik)
o	Switch aurora serial to capable()		(Rob Radez)
o	Radeon frame buffer				(Ani Joshi)

2.4.2-ac6
o	Remove incorrect modules doc changes		(Keith Owens)
o	Fix elf.h defines				(Keith Owens)
o	Add 0x2B mtrr decode for intel/cyrix III	(me)
o	Make bigmem balancing somewhat saner		(Mark Hemment)
o	Update irda 					(Dag Brattli)
o	New FIR dongle support				(Dag Brattli)
o	3ware driver updates				(Adam Radford)
o	Further reiserfs tail conversion fixes		(Chris Mason)
o	Fix tpqic02 to use capable			(Rob Radez)
o	Set last_rx on comtrol hostess driver		(Arnaldo Carvalho 
							 de Melo)
o	Raid Oops fix					(Neil Brown)
o	Fix last_rx/skb refs on cyc_x25			(Arnaldo Carvalho 
							 de Melo)
o	Fix last_rx/skb refs on 3c589			(Arnaldo Carvalho 
							 de Melo)
o	Highmem fixes for deadlock			(Andrea Arcangeli,
							 Ingo Molnar)
o	Another minor tulip fix				(Jeff Garzik)
o	Fix hinote and maybe other ps/aux hangs		(me, Mark Clegg)
o	Fix resource handling on 53c7xxx		(Rasmus Andersen)
o	Fix scsi_register failure handling on AMD scsi	(Rasmus Andersen)
o	Fix resource handling on aha1740		(Rasmus Andersen)
o	Fix resource handling on blz1230		(Rasmus Andersen)
o	Fix resource handling for dec_esp driver	(Rasmus Andersen)
o	Fix resource handling for fastlane scsi		(Rasmus Andersen)
o	Fix scsi_register failure on qlogic_fas		(Rasmus Andersen)
o	Fix scsi_register failure on qlogicfc		(Rasmus Andersen)
o	Fix irq alloc failure leak on sun3x_esp		(Rasmus Andersen)
o	Fix wd7000 init failures			(Rasmus Andersen)
o	Fix nbd device					(Steve Whitehouse)
o	Fix try_atomic_semop				(Manfred Spraul)
o	Parport fixes					(Tim Waugh)
o	Starfire start/stop if fix			(Ion Badulescu)
o	Fix raw.c off by one bug			(Tigran Aivazian)
o	USB hub kmalloc wrong size corruption fix	(Peter Zaitcev)

2.4.2-ac5
o	Add Epson 1240U scanners to usb scanner		(Joel Becker)
o	Fix eth= compatibility				(Andrew Morton)
	| Should fix 3c509 problems for one
o	Add Pnp table to opl3sa2			(Bill Nottingham)
o	Update loop driver fixes			(Jens Axboe, Andrea
							 Arcangeli, Al Viro)
o	Fix busy loop in usb storage			(Arjan van de Ven)
o	Add cardbus support to olympic			(Mike Phillips)
o	Make BUG() configurable to save space		(Arjan van de Ven)
o	Add configurability to most kernel debugging	(various people)
	functions on x86
o	Richard Günther/binfmt_misc page move		(Richard Günther)
o	Fix de4x5 crash					(Nikita Schmidt)
o	Hopefully fix the smc-mca driver		(me)
o	Don't run the disk queue if we didnt launder	(Marcelo Tosatti)
	any pages
o	ALi 6 channel audio and sp/dif updates		(Matt Wu)
o	Fix USB thread wakeup scheduling		(Arjan van de Ven)
o	Fix alignment problems with uni16_to_x8		(Ivan Kokshaysky)

2.4.2-ac4
o	Fix Make xconfig failure			(J Magallon)
o	Fix a typo in the ISDN docs			(Jim Freeman)
o	Fix the 3ware driver a bit more			(Ben LaHaise)
	| should now be usable
o	Update Dave Jones contact info			(Dave Jones)
o	Revert wavelan inline->macro change		(Jean Tourillhes)
	| CVS gcc and 2.96-74 don't accidentally unline it now
o	Zerocopy TCP/IP patches				(Dave Miller, 
							 Alexey Kuznetsov,
							 and many more)
o	Fix up command line options to old ncr driver	(Martin Storsjö)
o	NFS locking should call fs layer locking if	(Brian Dixon)
	present
o	Fix cs46xx wakeup/poll problem			(David Huggins-Daines)
o	Add some missing MTD config help texts		(Steven Cole,
							 David Woodhouse)
o	Fix Alpha build bug				(Sven Koch)
o	Final i386/ptrace bit
o	Finish off the vmalloc/WP fixup			(me)
o	Include file config.h fixes			(Niels Jensen)
o	More dscc4 updates				(Francois Romieu)

2.4.2-ac3
o	Add documentation for the fb interfaces		(Brad Douglas)
o	Work around apic disable_irq hardware bugs	(Maciej Rozycki)
o	Rage128 not "Rage 128"				(Brad Douglas)
o	Make ioremap debugging conditional		(J Magallon)
o	Merge Ninja pcmcia scsi driver			(YOKOTA Hiroshi)
o	Update 8139too docs				(Jeff Garzik)
o	Tulip updates, merge bits from 0.92 		(Jeff Garzik,
							 Don Becker)
o	Epic100 update					(Jeff Garzik)
o	Clean up Ariadne driver				(Jeff Garzik)
o	Remove dead wavelan prototype			(Jeff Garzik)
o	Remove unused arlan variable			(Jeff Garzik)
o	Clean up lance public symbols			(Jeff Garzik)
o	Switch fmv18x to spinlocks, fix other bits	(Jeff Garzik)
o	Clean up acenic global symbols			(Jeff Garzik)
o	Fix IDE blocking kmalloc with irqs off		(Arjan van de Ven)
	| I've redone the code a bit so it might be wrong again 8)

2.4.2-ac2
o	Merge the loop device fixes			(Jens Axboe)
o	Fix af_unix SYSCTL=n build failure		(Russell King)
o	Adjust the throttling point for write		(Jens Axboe)
	throttles
o	Fix sunhme ioremap				(Andrey Panin)
o	Fix disk change handling with removable sd	(Alex Davis)
o	Update/fix irq docs				(Matthew Wilcox)
o	Update PPC gmac and ncr885e drivers		(Cort Dougan)
	| bmac patch dropped as it loses other fixes
o	Kai Petzke has moved				(Kai Petzke)
o	Fix starfire driver so pump doesnt kill it	(Ion Badulescu)

2.4.2-ac1
o	Merge Linus 2.4.2 tree
	| We now have disagreeing ymfpci fixes. I've kept the ones
	| I tested for now.
o	Back out sr.c change				(me)
o	Fix moxa smartio driver				(Tom Mraz)
o	Hugh Blemings change of address			(Hugh Blemings)
o	Allow more i2o config time for slow calls
o	Aty128fb updates				(Brad Douglas,
						      Benjamin Herrenschmidt,
							 Michel Danzer,
							 Andreas Hundt)
o	Add "loop" name to the root dev names		(Barry Nathan)
o	Further spelling cleanups			(Dag Wieers)
o	Remove bogus warning emissions from aha1740	(Nick Holloway)
o	Remove surplus assignment in vmalloc		(Francis Galiegue)
o	Remove unneeded ifdef in i386/kernel/irq.c	(Francis Galiegue)
o	Add door locking ioctl to ide-floppy		(Francis Galiegue)
o	Allow scsi disk opening O_NDELAY for removables	(me)
o	Fix cosa compile warnings			(me)
o	Clean up dumpable/setuid write ordering		(me)
o	Hopefully fix the 3ware crashes 		(me)


---
Alan Cox <alan@lxorguk.ukuu.org.uk>
Red Hat Kernel Hacker
& Linux 2.2 Maintainer                        Brainbench MVP for TCP/IP
http://www.linux.org.uk/diary                 http://www.brainbench.com

Re: Linux 2.4.3-ac7

[Chris Meadors]

On Mon, 16 Apr 2001, Alan Cox wrote:

> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.

I saw no mention of the ACPI idle problem I see on my Athlons.  Is the
acpi=no-idle work around the perminate fix?

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..."                         --David Lynch, Twin Peaks

Re: Linux 2.4.3-ac7

[Alan Cox]

> On Mon, 16 Apr 2001, Alan Cox wrote:
> > VIA users should test this kernel carefully. It has what are supposed to be
> > the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> > as tested as the deduced ones.
> 
> I saw no mention of the ACPI idle problem I see on my Athlons.  Is the
> acpi=no-idle work around the perminate fix?

Ask Andrew Grover. I don't follow the ACPI threads. Having attempted to use
ACPI both on Linux and other OS's I've given up. Adding a bloated interpreter 
for an obscure, misdesigned bios hardware description language is simply not
my idea of progress. Its an extremely complicated way for intel to try and
keep stuff like speedstep proprietary, nothing more. 

APM works nicely on all my Athlons. 

Alan

Re: Linux 2.4.3-ac7

[Martin Hamilton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Alan Cox writes:

| Adding a bloated interpreter for an obscure, misdesigned bios hardware
| description language is simply not my idea of progress. 

Pardon me for butting in, but perhaps this is relevant...

I've seen the odd program which manipulates the ACPI tables/registers
directly rather than through an ASL compiler then an AML interpreter.
These appear to use the "magic numbers" which the interpreter would
eventually spit out.

Being a newbie on ACPI internals (still ploughing through the 400 page
'specification' document), I'm not sure whether there would be nasty
implications from doing this on a larger scale - e.g. needing to tweak
those magic numbers for each and every ACPI BIOS implementation.

Back in the real world, some people using ACPI BIOSes (e.g. owners of
recent Sony Vaio boxes like my C1VE) are finding that the legacy APM
support is losing when they try to do things like suspend to disk.  A
minimalist ACPI implementation could be just the ticket...

Just wondering if people have any thoughts on this!

Cheers,

Martin

PS Blatant plug :-)  I've set up a mailing list for people doing Linux
stuff on the Sony C1's:  http://mail.gnu.org/mailman/listinfo/linux-c1



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin

iD8DBQE63BxrVw+hz3xBJfQRAhZEAJ9wYOmOpbaA4z0qZpSmn43IGJJZdgCfbLo7
L9ZG4E/Z97LI87u5iK+TOvY=
=/ItG
-----END PGP SIGNATURE-----

Re: Linux 2.4.3-ac7

[John Cavan]

Alan Cox wrote:
> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.
> 
> 2.4.3-ac7
> o       Updated VIA quirk handling for the chipset      (Andre Hedrick,
>         flaws                                            George Breese)
>         | Experimental version removed
>         | VIA users should check this kernel -carefully-!!!!

I tried it on my dual P3 box with the VIA chipset and I'm definitely
getting timeouts for the USB devices. Booting with "noapic" resolves the
problem for me. Output of lspci for the VIA stuff is:

00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev
c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO]
(rev 23)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10)
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 11)
00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev
30)

The motherboard is a Tyan Tiger 133 (slot 1).

I'd be happy to provide more info, just tell me what you need.

Thanks,
John

Re: Linux 2.4.3-ac7

[Alan Cox]

> I tried it on my dual P3 box with the VIA chipset and I'm definitely
> getting timeouts for the USB devices. Booting with "noapic" resolves the
> problem for me. Output of lspci for the VIA stuff is:

Thats an unrelated problem. The BIOS on the tyan tiger is broken

> 

Re: Linux 2.4.3-ac7

[Geert Uytterhoeven]

On Mon, 16 Apr 2001, Alan Cox wrote:
> o	Fix the Zoran driver build			(me)
> 	| This is still not up to date with the master copy
> 	| that is intentional - first things first.

Probably that's why drivers/media/video/Makefile contains references to
zoran.o, while zoran.c was ditched?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 2.4.3-ac7

[Alan Cox]

> > 	| that is intentional - first things first.
> 
> Probably that's why drivers/media/video/Makefile contains references to
> zoran.o, while zoran.c was ditched?

zoran.c moved, because zoran.o is the output name of the module itself