Ok,
despite some naming confusion (expanation: I'm a retard), I did end up
doing the 2.6.9 release today. And it wasn't the same as the "-final" test
release (see explanation above).
Excuses aside, not a lot of changes since -rc4 (which was the last
announced test-kernel), mainly some UML updates that don't affect anybody
else. And a number of one-liners or compiler fixes. Full list appended.
Linus
----
Summary of changes from v2.6.9-rc4 to v2.6.9
============================================
<mgoodman:csua.berkeley.edu>:
o Fix NFS3 krb5 clients on x86-64
Al Borchers:
o USB: corrected digi_acceleport 2.6.9-rc1 fix for hang on disconnect
Andrea Arcangeli:
o ptep_establish smp race x86 PAE >4G
Andrew Morton:
o revert writeback threshold changes
o ext3 direct io assert fix
Anton Blanchard:
o ppc64: fix some issues with mem_reserve
Benjamin Herrenschmidt:
o ppc64: Split iomap implementation & eeh !
o ppc32: Add "native" iomap interfaces
o ppc64: more issues with mem_reserve
Chris Wright:
o uml: fix ubd deadlock on SMP
Christoph Hellwig:
o [XFS] fix a freeze/thaw deadlock
Christoph Lameter:
o time interpolator fixes
David Brownell:
o USB: EHCI SMP fix
o USB: net2280 updates
David Woodhouse:
o ppc64: one more explicit cmp instruction sizing
Dmitry Torokhov:
o Fix oops in parkbd
Greg Kroah-Hartman:
o USB: handle NAK packets in input devices
Herbert Xu:
o USB: Fix hiddev devfs oops
Hirokazu Takata:
o m32r: fix syscall table
o m32r: remove obsolete system calls
Ingo Molnar:
o tailcall prevention in sys_wait4() and sys_waitid()
James Morris:
o SELinux: fix bugs in mprotect hook
John L. Byrne:
o fix oops in fork() cleanup path
John Rose:
o PCI Hotplug: rpaphp safe list traversal
Lars Ellenberg:
o uml: fix critical IP checksum corruption
Linus Torvalds:
o Fix threaded user page write memory ordering
o Take the whole PCI bus range into account when scanning PCI bridges
Nathan Lynch:
o ppc64: fix smp_startup_cpu for cpu hotplug
Nathan Scott:
o [XFS] Fix up write_inode return type to use the right signedness
o [XFS] Fix regression when running in laptop mode, causes hangs on
sync
Nick Piggin:
o ACPI: check parameter for NULL
o kswapd lockup fix
Nicolas Pitre:
o Fix MTD build error for Lubbock map driver
o unbalanced locking in MTD Intel chip driver
o Duh. _Really_ unbalanced locking in MTD Intel chip driver
Olaf Hering:
o joydump needs gameport
Olaf Kirch:
o auth_domain_lookup fix
Oliver Neukum:
o security issue in firmware system
Paolo 'Blaisorblade' Giarrusso:
o uml: don't declare cpu_online - fix compilation error
o uml: fix wrong type for rb_entry call
o uml: fix warning for unused var
o uml: finish update for 2.6.8 API changes
o uml: fix an "unused" warnings
o uml: export more Symbols
o uml: Set cflags before including arch Makefile
o uml: force using /bin/bash for building
o uml: no extraversion in arch/um/Makefile for mainline
o uml: Single Linking Step for vmlinux
o uml: make -j fix
o uml: update makefile to new kbuild API names
o uml: kbuild - add even more cleaning
o uml: mark broken configs
o uml: use always a separate io thread for UBD
Pavel Machek:
o swsusp: fix x86-64 - do not use memory in copy loop
Randy Dunlap:
o cyber2000: fix init/exit section confusion
o intel_agp: dangling devexit reference
Sreenivas Bagalkote:
o megaraid 2.20.4: fix a data corruption bug
Stephen D. Smalley:
o SELinux: retain ptracer SID across fork
Tim Schmielau:
o Fix reporting of process start times
Vojtech Pavlik:
o USB: Fix oops in usblp driver
Yoshinori Sato:
o H8/300 some error/warning fix
Hi,
it seems you forgot to remove LATEST-IS-2.6.8.1 so the kernel.org start
page is still not listing 2.6.9.
Tom
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
finger [email protected] for key
Programmer: A biological machine designed to convert caffeine into code.
Linus Torvalds <[email protected]> writes:
> Ok,
> despite some naming confusion (expanation: I'm a retard), I did end up
> doing the 2.6.9 release today. And it wasn't the same as the "-final" test
> release (see explanation above).
>
> Excuses aside, not a lot of changes since -rc4 (which was the last
> announced test-kernel), mainly some UML updates that don't affect anybody
> else. And a number of one-liners or compiler fixes. Full list appended.
The ChangeLog-2.6.9 only list changes from v2.6.9-rc4 and not 2.6.8
ChangeLogs that don't cover the same set of changes their corresponding
patches cover just don't seem right somehow.
Eric
No changes...
Linux 2.6 Compile Statistics (gcc 3.2.2)
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.9 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-final 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
2.6.3-rc4 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
2.6.3-rc3 1w/0e 0w/0e 145w/ 7e 9w/0e 3w/0e 148w/0e
2.6.3-rc2 1w/0e 0w/0e 141w/ 0e 9w/0e 3w/0e 144w/0e
2.6.3-rc1 1w/0e 0w/0e 145w/ 0e 9w/0e 3w/0e 177w/0e
2.6.2 1w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.2-rc3 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.2-rc2 0w/0e 0w/0e 153w/ 8e 12w/0e 3w/0e 188w/0e
2.6.2-rc1 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.1 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
2.6.1-rc3 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
2.6.1-rc2 0w/0e 0w/0e 166w/ 0e 12w/0e 3w/0e 205w/0e
2.6.1-rc1 0w/0e 0w/0e 167w/ 0e 12w/0e 3w/0e 206w/0e
2.6.0 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5
John
--
John Cherry
[email protected]
503-626-2455x29
Open Source Development Labs
These are x86-based stats, yes? I'm sure other arches will likely tease
out more...
A lot of these seem to be related to readl/writel (readb/writeb, etc).
Those should be straightforward one-line changes, I think... perhaps a job
for more automated scripting?
At the very least, it would be nice to post-process the data to show which
modules are the offenders (and by how much).
Matt
On Tue, Oct 19, 2004 at 07:36:15AM -0700, John Cherry wrote:
> No changes...
>
> Linux 2.6 Compile Statistics (gcc 3.2.2)
>
> Web page with links to complete details:
> http://developer.osdl.org/cherry/compile/
>
> Kernel bzImage bzImage bzImage modules bzImage modules
> (defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
> ----------- ----------- -------- -------- -------- -------- ---------
> 2.6.9 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> 2.6.9-final 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> 2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> 2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
> 2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
> 2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
> 2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> 2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> 2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> 2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> 2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
> 2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
> 2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
> 2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
> 2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
> 2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
> 2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
> 2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
> 2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
> 2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
> 2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
> 2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
> 2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
> 2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
> 2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
> 2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
> 2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
> 2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
> 2.6.3-rc4 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
> 2.6.3-rc3 1w/0e 0w/0e 145w/ 7e 9w/0e 3w/0e 148w/0e
> 2.6.3-rc2 1w/0e 0w/0e 141w/ 0e 9w/0e 3w/0e 144w/0e
> 2.6.3-rc1 1w/0e 0w/0e 145w/ 0e 9w/0e 3w/0e 177w/0e
> 2.6.2 1w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> 2.6.2-rc3 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> 2.6.2-rc2 0w/0e 0w/0e 153w/ 8e 12w/0e 3w/0e 188w/0e
> 2.6.2-rc1 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> 2.6.1 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
> 2.6.1-rc3 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
> 2.6.1-rc2 0w/0e 0w/0e 166w/ 0e 12w/0e 3w/0e 205w/0e
> 2.6.1-rc1 0w/0e 0w/0e 167w/ 0e 12w/0e 3w/0e 206w/0e
> 2.6.0 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
>
> Daily compiles (ia32):
> http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
> Latest changes in Linus' bitkeeper tree:
> http://linux.bkbits.net:8080/linux-2.5
>
> John
>
>
> --
> John Cherry
> [email protected]
> 503-626-2455x29
> Open Source Development Labs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
I think the problem is there's a nut loose on your keyboard.
-- Greg to Customer
User Friendly, 1/5/1999
Linus Torvalds wrote:
>Ok,
> despite some naming confusion (expanation: I'm a retard), I did end up
>doing the 2.6.9 release today. And it wasn't the same as the "-final" test
>release (see explanation above).
>
>Excuses aside, not a lot of changes since -rc4 (which was the last
>announced test-kernel), mainly some UML updates that don't affect anybody
>else. And a number of one-liners or compiler fixes. Full list appended.
>
> Linus
>
>
The memory sickness with disappearing buffers, and the BIO callback
problems with the
SCSI layer previously reported appear to be corrected. This release is
very solid and
withstands 400 MB/S I/O to disk from 3GB/1GB split kernel/user memory
configurations
and does not have the disappearing memory problems I was experiencing
with massive
BIO/skb I/O loading. The memory pressure being exerted is constant and
the kernel
holds steady and stable enough for us to use and ship in our products
based on our
testing of the 2.6.9 release over two days.
On a side note, the GPL buyout previously offered has been modified. We
will be contacting
individual contributors and negotiating with each copyright holder for
the code we wish to
convert on a case by case basis. The remaining portions of code will
remain GPL
The 50K per copy offer still stands for the whole thing if you guys can
ever figure out
how to set something like this up.
:-)
Although we do not work with them and are in fact on the the other side
of Unixware from a
competing viewpoint, SCO has contacted us and identifed with precise
detail and factual
documentation the code and intellectual property in Linux they claim was
taken from Unix.
We have reviewed their claims and they appear to create enough
uncertianty to warrant
removal of the infringing portions.
We have identified and removed the infringing portions of Linux for our
products that
SCO claims was stolen from Unix. They are:
JFS, XFS, All SMP support in Linux, and RCU.
They make claims of other portions of Linux which were taken, however,
these other claims
do not appear to be supported with factual evidence.
Jeff
On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
> On a side note, the GPL buyout previously offered has been modified. We
> will be contacting
> individual contributors and negotiating with each copyright holder for
> the code we wish to
> convert on a case by case basis. The remaining portions of code will
> remain GPL
> The 50K per copy offer still stands for the whole thing if you guys can
> ever figure out
> how to set something like this up.
> :-)
Don't bother contacting me. I'll give you my answer now. Refused for
all work contributed by myself.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Tue, Oct 19, 2004, Jeff V. Merkey took 66 lines to troll:
>
> Although we do not work with them and are in fact on the the other side
> of Unixware from a
> competing viewpoint, SCO has contacted us and identifed with precise
> detail and factual
> documentation the code and intellectual property in Linux they claim was
> taken from Unix.
> We have reviewed their claims and they appear to create enough
> uncertianty to warrant
> removal of the infringing portions.
But, naturally, you can't reveal the precise files and lines of code that
SCO claim was stolen. For $DEITY's sake, you're still a Canopy stooge and
hanger on, even though you're smart enough to know better. How much did
NFT or Canopy give you to agree to this preposterous claim?
Welcome to my killfile.
Kurt
--
Naeser's Law:
You can make it foolproof, but you can't make it
damnfoolproof.
Jeff,
I can ship you some hippie cabbage from Berkeley California if you are
fresh out of Peyote.
Cheers,
Andre
Andre Hedrick
LAD Storage Consulting Group
On Tue, 19 Oct 2004, Jeff V. Merkey wrote:
> Linus Torvalds wrote:
>
> >Ok,
> > despite some naming confusion (expanation: I'm a retard), I did end up
> >doing the 2.6.9 release today. And it wasn't the same as the "-final" test
> >release (see explanation above).
> >
> >Excuses aside, not a lot of changes since -rc4 (which was the last
> >announced test-kernel), mainly some UML updates that don't affect anybody
> >else. And a number of one-liners or compiler fixes. Full list appended.
> >
> > Linus
> >
> >
> The memory sickness with disappearing buffers, and the BIO callback
> problems with the
> SCSI layer previously reported appear to be corrected. This release is
> very solid and
> withstands 400 MB/S I/O to disk from 3GB/1GB split kernel/user memory
> configurations
> and does not have the disappearing memory problems I was experiencing
> with massive
> BIO/skb I/O loading. The memory pressure being exerted is constant and
> the kernel
> holds steady and stable enough for us to use and ship in our products
> based on our
> testing of the 2.6.9 release over two days.
>
> On a side note, the GPL buyout previously offered has been modified. We
> will be contacting
> individual contributors and negotiating with each copyright holder for
> the code we wish to
> convert on a case by case basis. The remaining portions of code will
> remain GPL
> The 50K per copy offer still stands for the whole thing if you guys can
> ever figure out
> how to set something like this up.
> :-)
>
> Although we do not work with them and are in fact on the the other side
> of Unixware from a
> competing viewpoint, SCO has contacted us and identifed with precise
> detail and factual
> documentation the code and intellectual property in Linux they claim was
> taken from Unix.
> We have reviewed their claims and they appear to create enough
> uncertianty to warrant
> removal of the infringing portions.
>
> We have identified and removed the infringing portions of Linux for our
> products that
> SCO claims was stolen from Unix. They are:
>
> JFS, XFS, All SMP support in Linux, and RCU.
>
> They make claims of other portions of Linux which were taken, however,
> these other claims
> do not appear to be supported with factual evidence.
>
> Jeff
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 19 Oct 2004, Jeff V. Merkey wrote:
> We have identified and removed the infringing portions of Linux for our
> products that SCO claims was stolen from Unix. They are:
>
> JFS, XFS, All SMP support in Linux, and RCU.
Don't tell your customers you removed all the cool stuff.
Oh wait, they'll find your lkml post through Google...
Lets just hope your marketing folks don't find out about
this mail. ;)
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Andre Hedrick wrote:
>Jeff,
>
>I can ship you some hippie cabbage from Berkeley California if you are
>fresh out of Peyote.
>
>Cheers,
>
>Andre
>
>Andre Hedrick
>LAD Storage Consulting Group
>
>
>
Hey Andre,
I've got plenty of peyote around -- just watered them this morning.
Hippie Cabbage is legal in California?
Jeff
Rik van Riel wrote:
>On Tue, 19 Oct 2004, Jeff V. Merkey wrote:
>
>
>
>>We have identified and removed the infringing portions of Linux for our
>>products that SCO claims was stolen from Unix. They are:
>>
>>JFS, XFS, All SMP support in Linux, and RCU.
>>
>>
>
>Don't tell your customers you removed all the cool stuff.
>Oh wait, they'll find your lkml post through Google...
>
>Lets just hope your marketing folks don't find out about
>this mail. ;)
>
>
>
Rik,
You're awesome. We don't use XFS, JFS, or SMP for our appliances so
these changes
have little impact for us.
:-)
Jeff
Jeff V. Merkey <[email protected]>
IIRC, SCO bought drdos a long time ago (when they were caldera). That
makes me think your evaluation of the situation is a little biased.
And to save you time, I'm with Russell, none of the work I've ever
contributed is available under any license other than the GPL.
On Tue, 19 Oct 2004, Kurt Wall wrote:
> On Tue, Oct 19, 2004, Jeff V. Merkey took 66 lines to troll:
>>
>> Although we do not work with them and are in fact on the the other side
>> of Unixware from a
>> competing viewpoint, SCO has contacted us and identifed with precise
>> detail and factual
>> documentation the code and intellectual property in Linux they claim was
>> taken from Unix.
>> We have reviewed their claims and they appear to create enough
>> uncertianty to warrant
>> removal of the infringing portions.
>
> But, naturally, you can't reveal the precise files and lines of code that
> SCO claim was stolen. For $DEITY's sake, you're still a Canopy stooge and
> hanger on, even though you're smart enough to know better. How much did
> NFT or Canopy give you to agree to this preposterous claim?
>
> Welcome to my killfile.
>
> Kurt
Some people just don't know how to tell a joke! I wonder how
many companies have "non-exclusive" licenses to UNIX from AT&T?
I don't recall SCO buying back any of those licenses. In particular,
AT&T gave a non-exclusive license to many universities, including
UC/Berkeley, where most of the student-written code came from
before there was a Linux. Don't let SCO crap bother you. They
don't have a leg to stand on. They think they "own" Unix while,
in fact, it was given away long before they latched onto its last
craze.
FYI, this DR-DOS is pretty interesting. I knew the founder of
Digital Research, Gary Kildall. They probably would do well
to check their facts before they put a history-rewrite on
their web-pages. I think the DR-DOS is a hack of freedos
and I think they might try the same thing with Linux.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
[email protected] wrote:
>On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
>
>
>>On a side note, the GPL buyout previously offered has been modified. We
>>will be contacting
>>individual contributors and negotiating with each copyright holder for
>>the code we wish to
>>convert on a case by case basis. The remaining portions of code will
>>remain GPL
>>
>>
>
>... thus making the result impossible to distribute unless you satisfy all
>requirements imposed by GPL. Have fun.
>
>Oh, and don't bother contacting me regarding any code I'd worked on - the
>answer hadn't changed. If English translation had been unclear, maybe the
>original will help: poshel ty na huj so swoimi predlozheniyami.
>
>
Cherokee:
U-ne-la-nv-hi U-da-do-li-s-di Ka-ne i-s-di Go-we-la-i Do-na-da Go-Hv-i
Go-li-ga-hi Ni-go-di-s-ge-di
Translation:
Bless you for your frank answer, and your words. Til meet meet again and
I understand that's
just the way it is.
The GPL code will remain GPL and the license will be complied with -- to
the letter.
Wa-do
Jeff
Wa-ya Ge-tlv-hv-s-di
(The wolf that howls)
Kurt Wall wrote:
>On Tue, Oct 19, 2004, Jeff V. Merkey took 66 lines to troll:
>
>
>>Although we do not work with them and are in fact on the the other side
>>of Unixware from a
>>competing viewpoint, SCO has contacted us and identifed with precise
>>detail and factual
>>documentation the code and intellectual property in Linux they claim was
>>taken from Unix.
>>We have reviewed their claims and they appear to create enough
>>uncertianty to warrant
>>removal of the infringing portions.
>>
>>
>
>But, naturally, you can't reveal the precise files and lines of code that
>SCO claim was stolen. For $DEITY's sake, you're still a Canopy stooge and
>hanger on, even though you're smart enough to know better. How much did
>NFT or Canopy give you to agree to this preposterous claim?
>
>Welcome to my killfile.
>
>Kurt
>
>
Yes, I can reveal them. All of XFS, All of JFS, and All of the SMP
Support in Linux. I have no
idea what the hell RCU is and when I find it, I'll remove it from the code.
I don't work for Canopy. I know those guys but we parted ways a few
years back. Utah Valley
is sort of incenstuous, if you lived here, you would understand. It's a
small place.
Jeff
On Tuesday 19 October 2004 18:38, Jeff V. Merkey wrote:
>
> The 50K per copy offer still stands for the whole thing if you guys can
> ever figure out
> how to set something like this up.
>
You seem to be under the misapprehension that people actually want to do this.
But don't worry, I'm sure that will be cleared up real soon.
Ross Biro wrote:
>Jeff V. Merkey <[email protected]>
>
>IIRC, SCO bought drdos a long time ago (when they were caldera). That
>makes me think your evaluation of the situation is a little biased.
>
>And to save you time, I'm with Russell, none of the work I've ever
>contributed is available under any license other than the GPL.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Bryan Sparks (who left Caldera years back and bought DRDOS from Canopy)
owns DRDOS and
not SCO. Bryan also supports Linux and always has. Bryan also is the
person who backed M$
into a corner and stopped them from crushing planet earth. He's one of
the biggest friends Linux has
and was pushing Linux in the early 1990s. Caldera and Canopy do not deal
in DRDOS anymore.
Jeff
El Tue, 19 Oct 2004 13:05:34 -0600 "Jeff V. Merkey" <[email protected]> escribi?:
> You're awesome. We don't use XFS, JFS, or SMP for our appliances so
> these changes
> have little impact for us.
Just wondering, how did you remove RCU? From a quick grep it's used in generic
code like fs/dcache.c or kernel/sched.c. Did you remove process scheduler and
filesystem support for your customers too? Or I'm missing something about RCU?
Diego Calleja wrote:
>El Tue, 19 Oct 2004 13:05:34 -0600 "Jeff V. Merkey" <[email protected]> escribi?:
>
>
>
>
>>You're awesome. We don't use XFS, JFS, or SMP for our appliances so
>>these changes
>>have little impact for us.
>>
>>
>
>Just wondering, how did you remove RCU? From a quick grep it's used in generic
>code like fs/dcache.c or kernel/sched.c. Did you remove process scheduler and
>filesystem support for your customers too? Or I'm missing something about RCU?
>
>
>
Good question. One version we are working on doesn't even use Linus'
kernel. The appliance
does however. This one does require some tough work. The FS's were
easy. We have something up our
sleeve that will be a bit of a surprise to SCO on the horizon. Stay
tuned ......
Jeff
Richard B. Johnson wrote:
> Note it's all 3-letter stuff. They just couldn't do
> any better...... Maybe SCO has a patent on all 3-letter
> logos and that's what they are complaining about!! I'm
> pretty sure the Intel guys will get a kick out of the
> "SMP" claim!
>
> Cheers,
> Dick Johnson
They also claim Linux NUMA (a four letter word) is their as well, I
forgot to mention
this one. I removed this one also. This claim is a little more out there
since Dolphin
and Sequent developed hardware around it and on other Unixes. I don't
think I agree with
this one but we don't use NUMA either.
Jeff
Diego Calleja wrote:
>Just wondering, how did you remove RCU? From a quick grep it's used in generic
>code like fs/dcache.c or kernel/sched.c. Did you remove process scheduler and
>filesystem support for your customers too? Or I'm missing something about RCU?
>-
>
>
That's one's a mess. Looks like some late nights. I guess we could
claim "essential facility" on this one,
this will be some serious work ......
Jeff
On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
> On a side note, the GPL buyout previously offered has been modified. We
> will be contacting
> individual contributors and negotiating with each copyright holder for
> the code we wish to
> convert on a case by case basis. The remaining portions of code will
> remain GPL
... thus making the result impossible to distribute unless you satisfy all
requirements imposed by GPL. Have fun.
Oh, and don't bother contacting me regarding any code I'd worked on - the
answer hadn't changed. If English translation had been unclear, maybe the
original will help: poshel ty na huj so swoimi predlozheniyami.
On Tue, Oct 19, 2004 at 04:01:22PM -0400, Richard B. Johnson wrote:
> FYI, this DR-DOS is pretty interesting. I knew the founder of
> Digital Research, Gary Kildall. They probably would do well
> to check their facts before they put a history-rewrite on
> their web-pages. I think the DR-DOS is a hack of freedos
> and I think they might try the same thing with Linux.
Dear wrongbot,
DR-DOS dates back to the mid-80's, about a decade before FreeDOS.
Anyone who was anywhere near a PC back then should know this.
--
Mathematics is the supreme nostalgia of our time.
On Tue, 2004-10-19 at 21:38, Jeff V. Merkey wrote:
> Richard B. Johnson wrote:
>
> > Note it's all 3-letter stuff. They just couldn't do
> > any better...... Maybe SCO has a patent on all 3-letter
> > logos and that's what they are complaining about!! I'm
> > pretty sure the Intel guys will get a kick out of the
> > "SMP" claim!
> >
> > Cheers,
> > Dick Johnson
>
>
> They also claim Linux NUMA (a four letter word) is their as well, I
> forgot to mention
> this one. I removed this one also. This claim is a little more out there
> since Dolphin
> and Sequent developed hardware around it and on other Unixes. I don't
> think I agree with
> this one but we don't use NUMA either.
>
Hey, why do you rip out all the code ?
http://kernel.org/pub/linux/kernel/v1.0/linux-1.0.tar.bz2
contains none of it.
tglx
On Tue, 2004-10-19 at 11:38, Jeff V. Merkey wrote:
> Although we do not work with them and are in fact on the the other side
> of Unixware from a
> competing viewpoint, SCO has contacted us and identifed with precise
> detail and factual
> documentation the code and intellectual property in Linux they claim was
> taken from Unix.
> We have reviewed their claims and they appear to create enough
> uncertianty to warrant
> removal of the infringing portions.
>
> We have identified and removed the infringing portions of Linux for our
> products that
> SCO claims was stolen from Unix. They are:
>
> JFS, XFS, All SMP support in Linux, and RCU.
>
This isn't SCO code. This goes back to SCO's claims of "control rights"
over any source code that has been in the same room as UNIX code.
These "control rights" depend on SCOs interpretation of what a
derivative work is. This is a contractual dispute, an attempt of SCO to
reframe what a derivative work is and a big up hill battle for SCO as
virtually all the parties of original contracts have in their
declarations not supported SCO claims of "control rights".
Stephen D. Vuksanovich, Scott Nelson, Richard A. McDonough III, Robert
C. Swanson, Ira Kistenberg, David Frasure, and Geoffrey D. Green.
Four of them are (or were at relevant time periods) AT&T employees.
See: http://www.groklaw.net/article.php?story=20041007032319488
Besides the declarations, there is other items that don't back SCO
"control rights" claims such as the $echo newletter, and amendment X to
the contract.
Dax Kelson
On Tue, 19 Oct 2004, Rik van Riel wrote:
> On Tue, 19 Oct 2004, Jeff V. Merkey wrote:
>
>> We have identified and removed the infringing portions of Linux for our
>> products that SCO claims was stolen from Unix. They are:
>>
>> JFS, XFS, All SMP support in Linux, and RCU.
>
> Don't tell your customers you removed all the cool stuff.
> Oh wait, they'll find your lkml post through Google...
>
> Lets just hope your marketing folks don't find out about
> this mail. ;)
Note it's all 3-letter stuff. They just couldn't do
any better...... Maybe SCO has a patent on all 3-letter
logos and that's what they are complaining about!! I'm
pretty sure the Intel guys will get a kick out of the
"SMP" claim!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
> On a side note, the GPL buyout previously offered has been modified. We
> will be contacting individual contributors and negotiating with each
> copyright holder for the code we wish to convert on a case by case basis.
Hi
arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two beers
(I believe nobody else has touched it so it should be all mine).
The other files of the port to that very fine architecture are largely done
by other people, so unfortunately I can't relicense those.
Dax Kelson wrote:
>>
>>JFS, XFS, All SMP support in Linux, and RCU.
>>
>>
And Numa also.
>>
>>
>
>This isn't SCO code. This goes back to SCO's claims of "control rights"
>over any source code that has been in the same room as UNIX code.
>
>These "control rights" depend on SCOs interpretation of what a
>derivative work is. This is a contractual dispute, an attempt of SCO to
>reframe what a derivative work is and a big up hill battle for SCO as
>virtually all the parties of original contracts have in their
>declarations not supported SCO claims of "control rights".
>
>Stephen D. Vuksanovich, Scott Nelson, Richard A. McDonough III, Robert
>C. Swanson, Ira Kistenberg, David Frasure, and Geoffrey D. Green.
>
>Four of them are (or were at relevant time periods) AT&T employees.
>
>See: http://www.groklaw.net/article.php?story=20041007032319488
>
>Besides the declarations, there is other items that don't back SCO
>"control rights" claims such as the $echo newletter, and amendment X to
>the contract.
>
>Dax Kelson
>
>
>
>
No. They seem to have some factual concrete evidence IP covered under
Employee
agreements was used and subsequently converted into Linux, and they are
very
confident of this. From a cursory viewpoint, it looks valid. I think
they have a case
(having been sued and nailed for the same type of thing by Novell).
It's better to remove
these code areas and make the vendors maintain them as separate patches
not in the tree,
like what happened to intermezzo. It's low impact for Linux and the
other vendors.
XFS, JFS and NUMA are easy ones.
RCU and NUMA are not. Hey, Novell just handed over their patent
portfolio to Linux,
use their patents for SMP and RCU. These areas are not trivial to dump
out of the kernel.
If Linux did dump the infringing FS's, it would be a good faith effort
to limit SCO's claims.
SMP and RCU look a little tougher to defend. I remember a Brainshare
session at SLC
where the unixware guys were disclosing this stuff in public sessions.
Perhaps Novell
could go back and publish those Brainshare slides on their website. So
much for claiming
SMP and RCU are not in the public domain.
Dump the FS's and NUMA guys. Then you are nearly there for being
squeaky clean.
Jeff
On Tue, 2004-10-19 at 16:02, Pekka Pietikainen wrote:
> arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two beers
Hmmm... what brand?
I hope you hold out for more than Coors Light.
--
Paul Fulghum
[email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff V. Merkey wrote:
| On a side note, the GPL buyout previously offered has been modified. We
| will be contacting
| individual contributors and negotiating with each copyright holder for
| the code we wish to
| convert on a case by case basis. The remaining portions of code will
| remain GPL
BSD "revisited" license is GPL-compatible, but
http://www.fsf.org/licenses/gpl-faq.html#MereAggregation
Mere aggregation of two programs means putting them side by side on the
same CD-ROM or hard disk. We use this term in the case where they are
separate programs, not parts of a single program. In this case, if one
of the programs is covered by the GPL, it has no effect on the other
program.
Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't,
do that, you may not combine them.
What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes,
rpc, function calls within a shared address space, etc.) and the
semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But
if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider
the two parts as combined into a larger program.
- --
Ram?n Rey Vicente <ramon.rey en hispalinux.es>
JID [email protected] - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBdYaQw4Wp058o43cRAq+wAJ4+BISSW8RTPLIoW5SWgnU9GwgPJgCeNKUY
lGiMA0vZgcS48T7Gr7uvfuw=
=Pfg5
-----END PGP SIGNATURE-----
Thomas Gleixner wrote:
>Hey, why do you rip out all the code ?
>
>http://kernel.org/pub/linux/kernel/v1.0/linux-1.0.tar.bz2
>
>contains none of it.
>
>tglx
>
>
>
>
>
Not a bad suggestion.
:-)
Jeff
Jeff V. Merkey wrote:
> Dax Kelson wrote:
>
>>>
>>> JFS, XFS, All SMP support in Linux, and RCU.
>>>
>
> And Numa also.
>
>>>
>>
>>
>> This isn't SCO code. This goes back to SCO's claims of "control rights"
>> over any source code that has been in the same room as UNIX code.
>>
>> These "control rights" depend on SCOs interpretation of what a
>> derivative work is. This is a contractual dispute, an attempt of SCO to
>> reframe what a derivative work is and a big up hill battle for SCO as
>> virtually all the parties of original contracts have in their
>> declarations not supported SCO claims of "control rights".
>>
>> Stephen D. Vuksanovich, Scott Nelson, Richard A. McDonough III, Robert
>> C. Swanson, Ira Kistenberg, David Frasure, and Geoffrey D. Green.
>>
>> Four of them are (or were at relevant time periods) AT&T employees.
>>
>> See: http://www.groklaw.net/article.php?story=20041007032319488
>>
>> Besides the declarations, there is other items that don't back SCO
>> "control rights" claims such as the $echo newletter, and amendment X to
>> the contract.
>>
>> Dax Kelson
>>
>>
>>
>>
> No. They seem to have some factual concrete evidence IP covered under
> Employee
> agreements was used and subsequently converted into Linux, and they are
> very
> confident of this. From a cursory viewpoint, it looks valid. I think
> they have a case
> (having been sued and nailed for the same type of thing by Novell).
> It's better to remove
> these code areas and make the vendors maintain them as separate patches
> not in the tree,
> like what happened to intermezzo. It's low impact for Linux and the
> other vendors.
>
> XFS, JFS and NUMA are easy ones.
>
> RCU and NUMA are not. Hey, Novell just handed over their patent
> portfolio to Linux,
> use their patents for SMP and RCU. These areas are not trivial to dump
> out of the kernel.
> If Linux did dump the infringing FS's, it would be a good faith effort
> to limit SCO's claims.
>
> SMP and RCU look a little tougher to defend. I remember a Brainshare
> session at SLC
> where the unixware guys were disclosing this stuff in public sessions.
> Perhaps Novell
> could go back and publish those Brainshare slides on their website. So
> much for claiming
> SMP and RCU are not in the public domain.
>
> Dump the FS's and NUMA guys. Then you are nearly there for being
> squeaky clean.
>
> Jeff
>
<troll-bite>
You know, SCO sounds like the guys I've worked with when they failed a
drug test - "C'mon, I was at a party, I was only around the stuff, I
never touched it, you can't fire me!"
From http://en.wikipedia.org/wiki/SCO_v._IBM :
SCO currently claims:
* Any code belonging to SCO that might have been GPL'd was done by
SCO employees without proper legal authorization, and thus is not
legally GPL'd.
* That for code to be GPL'd, the code's copyright owner must put a
GPL notice before the code, but since SCO itself wasn't the one to add
the notices, the code was never GPL'd.
and:
SCO's major claims have now been reported as relating to the following
components of the Linux kernel:
* symmetric multiprocessing (SMP),
* non-uniform memory access (NUMA) multiprocessing,
* the read-copy-update (RCU) locking strategy,
* SGI's Extended File System (XFS),
* and IBM's JFS journaling file system
These claims flow from the accusation of breach of contract. The
contract between IBM and AT&T (to which SCO claims to be successor in
interest) allows IBM to use the SVR4 code, but the SVR4 code, plus any
derivative works made from that code, must be held confidential by IBM.
According to IBM's interpretation of the contract, and the
interpretation published by AT&T in their "$ echo" newsletter in 1985,
"derivative works" means any works containing SVR4 code. But according
to SCO's interpretation, "derivative works" also includes any code built
on top of SVR4, even if that does not contain, or even never contained,
any SVR4 code. Thus, according to SCO, any AIX operating system code
that IBM developed must be kept confidential, even if it contains
nothing from SVR4.
so:
If SCO is saying that any code in the kernel that belongs to SCO was
done by SCO employees, then why are they suing IBM?
Are they claiming that AIX was developed by SCO employees?
Or are they claiming that Linux was developed former SCO employees
working for IBM?
</troll-bite>
Jeff V. Merkey wrote:
> I've got plenty of peyote around -- just watered them this morning.
What happened to your peyote-based cure for arthritis? I can't seem to
find either timpanogas.org or utah-nac.org at the moment.
> Dump the FS's and NUMA guys. Then you are nearly there for being
> squeaky clean.
Now, far be it for this old Coyote to sense something amiss in a person
who's associated with both SCO and a controlled substance. Yes, I'm
aware of recent Utah Court rulings; they only apply to members of the
Native American Church.
Not that SCO would mind "tainting" Linux by associating its developers
with an illegal substance...
Gosh darn, there I go again, getting all conspiratorial...
..Scott
--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com
On Tue, 19 Oct 2004 11:38:03 -0600, Jeff V. Merkey <[email protected]> wrote:
> Although we do not work with them and are in fact on the the other side
> of Unixware from a
> competing viewpoint, SCO has contacted us and identifed with precise
> detail and factual
> documentation the code and intellectual property in Linux they claim was
> taken from Unix.
> We have reviewed their claims and they appear to create enough
> uncertianty to warrant
> removal of the infringing portions.
I can only see two possible explanations for this remarkable event.
1. You're lying through your teeth.
2. You are a SCO puppet.
I'm guessing 2. You don't exist. Go away.
Cheers,
Buddy
On Wed, 2004-10-20 at 00:16, Jim Nelson wrote:
> <troll-bite>
[...]
> done by SCO employees, then why are they suing IBM?
[...]
> </troll-bite>
Because they wanted IBM to buy SCO thus rising the stocks even more.
Nothing else, pure greed.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Tue, 19 Oct 2004, Matt Mackall wrote:
> On Tue, Oct 19, 2004 at 04:01:22PM -0400, Richard B. Johnson wrote:
>> FYI, this DR-DOS is pretty interesting. I knew the founder of
>> Digital Research, Gary Kildall. They probably would do well
>> to check their facts before they put a history-rewrite on
>> their web-pages. I think the DR-DOS is a hack of freedos
>> and I think they might try the same thing with Linux.
>
> Dear wrongbot,
>
> DR-DOS dates back to the mid-80's, about a decade before FreeDOS.
> Anyone who was anywhere near a PC back then should know this.
Read their web page. The current "DR-DOS" is an embedded MS-DOS
clone. The original DR-DOS was an 8086 "CP/M"-like DOS that
Gary didn't get to show to IBM because he was out flying is
airplane.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
On Tue, 2004-10-19 at 22:09, Jeff V. Merkey wrote:
> >>JFS, XFS, All SMP support in Linux, and RCU.
> And Numa also.
>
> >This isn't SCO code. This goes back to SCO's claims of "control rights"
> >over any source code that has been in the same room as UNIX code.
> No. They seem to have some factual concrete evidence IP covered under
> Employee agreements was used and subsequently converted into Linux, and they
> are very confident of this.
bwhahaha...
nice try..
Do you reallly think you (on your own) can defend al those claims?
(better than all lawyers/persons involved???!?!?!)
Even though all of them (claims) have been disputed by people more
knowledgeable than you?
Please leave LKML.
We don't like you nor anything you have to say.
Not sincerely,
Bastiaan Spandaw
On Tue, Oct 19, 2004 at 02:09:28PM -0600, Jeff V. Merkey wrote:
> XFS, JFS and NUMA are easy ones.
As I understand it, JFS was originally written for AIX. The OS/2 team
at IBM rewrote it from scratch for OS/2. Their version was cleaner, so
*that* got ported to AIX. (Maybe 5L, not really sure on versions here.)
The JFS for OS/2 is the predecessor to the Linux version.
Where's the Unix IP infection come from?
> RCU and NUMA are not.
RCU - originally a paper, implemented in Dynix and in other operating
systems from the paper (and patent), implemented in Linux as well.
Oh, and disclaimers:
IANAL, all knowledge gleaned from extensive reading, not personal
experience. Feel free to flame me if I screwed something up. (And I
apologize if I did so.)
--
Ryan Anderson
sometimes Pug Majere
On Tue, 2004-10-19 at 23:45, Ryan Anderson wrote:
> RCU - originally a paper, implemented in Dynix and in other operating
> systems from the paper (and patent), implemented in Linux as well.
You could also make a strong argument that that patent is invalid
because RCU is obvious. I was doing this with perl and SQL before I
ever heard of RCU. If you don't want to lock a table (or didn't realize
SQL had such a thing as table locking :-) you just fetch a value, make
some calculation on it, then do the update iff that value has not
changed. If it has changed you fetch the new value and go back to step
1. It's just the obvious way to update a shared data structure if you
have cmpxchg but no locking.
Lee
On Wed, 2004-10-20 at 00:18, Lee Revell wrote:
> On Tue, 2004-10-19 at 23:45, Ryan Anderson wrote:
> > RCU - originally a paper, implemented in Dynix and in other operating
> > systems from the paper (and patent), implemented in Linux as well.
>
> You could also make a strong argument that that patent is invalid
> because RCU is obvious.
(replying to myself to avert flames) OK, after reading the RCU docs, in
all fairness there is a lot more to it than I described, in particular
the database analogy is not quite valid because most of the hard parts
are handled automagically by the DB. But, my point remains valid, RCU
seems like too general a concept to be patentable, and would probably be
obvious to many people on this list.
Lee
On Tue, Oct 19, 2004 at 08:06:07PM -0400, Richard B. Johnson wrote:
> On Tue, 19 Oct 2004, Matt Mackall wrote:
>
> >On Tue, Oct 19, 2004 at 04:01:22PM -0400, Richard B. Johnson wrote:
> >>FYI, this DR-DOS is pretty interesting. I knew the founder of
> >>Digital Research, Gary Kildall. They probably would do well
> >>to check their facts before they put a history-rewrite on
> >>their web-pages. I think the DR-DOS is a hack of freedos
> >>and I think they might try the same thing with Linux.
> >
> >Dear wrongbot,
> >
> >DR-DOS dates back to the mid-80's, about a decade before FreeDOS.
> >Anyone who was anywhere near a PC back then should know this.
>
> Read their web page. The current "DR-DOS" is an embedded MS-DOS
> clone. The original DR-DOS was an 8086 "CP/M"-like DOS that
> Gary didn't get to show to IBM because he was out flying is
> airplane.
And they're the same. Novell acquired it from DR around the time it
was famously killed in the marketplace by Win3.1 compatibility
bogosity and Win95 bundling of DOS. Then they sold it to Noorda's
Caldera, who used it in their famous antitrust suit against Microsoft.
By this time it was already positioned as an embedded MS-DOS
replacement as Microsoft had EOLed its DOS offerings and there wasn't
any use for desktop DOS at that point.
--
Mathematics is the supreme nostalgia of our time.
On Wed, 20 Oct 2004 00:18:25 -0400, Lee Revell <[email protected]>
wrote:
>On Tue, 2004-10-19 at 23:45, Ryan Anderson wrote:
>> RCU - originally a paper, implemented in Dynix and in other operating
>> systems from the paper (and patent), implemented in Linux as well.
>
>You could also make a strong argument that that patent is invalid
>because RCU is obvious. I was doing this with perl and SQL before I
>ever heard of RCU. If you don't want to lock a table (or didn't realize
>SQL had such a thing as table locking :-) you just fetch a value, make
>some calculation on it, then do the update iff that value has not
>changed. If it has changed you fetch the new value and go back to step
>1. It's just the obvious way to update a shared data structure if you
>have cmpxchg but no locking.
1972, IBM S/370 instruction set, CS Compare and Swap (32 bits) and CDS
Compare Double and Swap (64 bits), atomic compare and replace if test
equal. The Principles of Operation book even had sample code...
john alvord
On Tue, 2004-10-19 at 13:41 -0600, Jeff V. Merkey wrote:
[...]
> easy. We have something up our
> sleeve that will be a bit of a surprise to SCO on the horizon. Stay
> tuned ......
SCO is already as good as dead. No need to invest any work in that ...
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Wed, Oct 20 2004, Bernd Petrovitsch wrote:
> On Tue, 2004-10-19 at 13:41 -0600, Jeff V. Merkey wrote:
> [...]
> > easy. We have something up our
> > sleeve that will be a bit of a surprise to SCO on the horizon. Stay
> > tuned ......
>
> SCO is already as good as dead. No need to invest any work in that ...
And Jeff is a nutter, no need to invest more time on that issue.
I'll sell my parts of the block layer for ONE BILLION DOLLARS! Murhaha.
--
Jens Axboe
On Wed, 20 Oct 2004, Lee Revell wrote:
> On Wed, 2004-10-20 at 00:18, Lee Revell wrote:
>> On Tue, 2004-10-19 at 23:45, Ryan Anderson wrote:
>>> RCU - originally a paper, implemented in Dynix and in other operating
>>> systems from the paper (and patent), implemented in Linux as well.
>>
>> You could also make a strong argument that that patent is invalid
>> because RCU is obvious.
>
> (replying to myself to avert flames) OK, after reading the RCU docs, in
> all fairness there is a lot more to it than I described, in particular
> the database analogy is not quite valid because most of the hard parts
> are handled automagically by the DB. But, my point remains valid, RCU
> seems like too general a concept to be patentable, and would probably be
> obvious to many people on this list.
>
> Lee
>
Next SCO will show that some company they bought in bankrupcy
for a dollar had patented register move instructions, to whit;
"The copying of the contents of one register to another without
changing the contents of the source register...."
Then they will require that Intel, Motorola, and others pay them
billions and billions.... It's all lawyering (spelled wrong).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
hoi :)
On Wed, Oct 20, 2004 at 12:18:25AM -0400, Lee Revell wrote:
> I was doing this with perl and SQL before I
> ever heard of RCU. If you don't want to lock a table (or didn't realize
> SQL had such a thing as table locking :-) you just fetch a value, make
> some calculation on it, then do the update iff that value has not
> changed. If it has changed you fetch the new value and go back to step
what you described is not RCU.
it's more something like seqlocks
RCU means: you always read without any locking.
when you want to write, you create a new copy of the data instead
and switch over a pointer when you are done.
if you are sure that the old pointer is not used any move, you can
free the old value.
--
Martin Waitz
Scott Robert Ladd wrote:
> Jeff V. Merkey wrote:
> > I've got plenty of peyote around -- just watered them this morning.
>
> What happened to your peyote-based cure for arthritis? I can't seem to
> find either timpanogas.org or utah-nac.org at the moment.
>
> > Dump the FS's and NUMA guys. Then you are nearly there for being
> > squeaky clean.
>
> Now, far be it for this old Coyote to sense something amiss in a person
> who's associated with both SCO and a controlled substance. Yes, I'm
> aware of recent Utah Court rulings; they only apply to members of the
> Native American Church.
>
> Not that SCO would mind "tainting" Linux by associating its developers
> with an illegal substance...
You mean they're gonna give us some weed?
;-) if it isn't obvious...
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Dax Kelson wrote:
> On Tue, 2004-10-19 at 11:38, Jeff V. Merkey wrote:
>
>>Although we do not work with them and are in fact on the the other side
>>of Unixware from a
>>competing viewpoint, SCO has contacted us and identifed with precise
>>detail and factual
>>documentation the code and intellectual property in Linux they claim was
>>taken from Unix.
>>We have reviewed their claims and they appear to create enough
>>uncertianty to warrant
>>removal of the infringing portions.
>>
>>We have identified and removed the infringing portions of Linux for our
>>products that
>>SCO claims was stolen from Unix. They are:
>>
>>JFS, XFS, All SMP support in Linux, and RCU.
>>
>
>
> This isn't SCO code. This goes back to SCO's claims of "control rights"
> over any source code that has been in the same room as UNIX code.
>
> These "control rights" depend on SCOs interpretation of what a
> derivative work is. This is a contractual dispute, an attempt of SCO to
> reframe what a derivative work is and a big up hill battle for SCO as
> virtually all the parties of original contracts have in their
> declarations not supported SCO claims of "control rights".
This "we gave you the idea" is dangerous ground, Honeywell bought the
rights to MULTICS, from which UNIX was derivative at the acronym level,
and LINUX is clearly derived from UNIX since it uses the same symbols,
upper and lower case alpha, digits, and the smoking gun the underscore.
Maybe Honeywell should sue SCO?
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Wed, 20 Oct 2004, Pekka Pietikainen wrote:
> On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
> > On a side note, the GPL buyout previously offered has been modified. We
> > will be contacting individual contributors and negotiating with each
> > copyright holder for the code we wish to convert on a case by case basis.
>
> arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two beers
> (I believe nobody else has touched it so it should be all mine).
>
> The other files of the port to that very fine architecture are largely done
> by other people, so unfortunately I can't relicense those.
Aarghl, a shameless m68k hacker!
And I thought we all did it for The Big Fun(tm), and cannot be bought ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Tue, 2004-10-19 at 09:18, Matthew Dharm wrote:
> These are x86-based stats, yes? I'm sure other arches will likely tease
> out more...
Yes, they are x86-based. Other archs are on my list of things to do.
If you would like to pick up the ball with these other archs, the
compile tools are at http://developer.osdl.org/cherry/compile/tools/
>
> A lot of these seem to be related to readl/writel (readb/writeb, etc).
> Those should be straightforward one-line changes, I think... perhaps a job
> for more automated scripting?
A lot of these readl/writel warnings HAVE been addressed. In 2.6.9-rc2,
there were about 3000 of these warnings. In 2.6.9, there are less than
1900.
>
> At the very least, it would be nice to post-process the data to show which
> modules are the offenders (and by how much).
Check out the complete details page
(http://developer.osdl.org/cherry/compile/). Under "Warning/Error
Module Build Summaries", you can see how the warnings break down by
module. For 2.6.9, they are...
drivers/atm: 6 warnings, 0 errors
drivers/block: 1 warnings, 0 errors
drivers/cpufreq: 2 warnings, 0 errors
drivers/isdn: 90 warnings, 0 errors
drivers/media: 86 warnings, 0 errors
drivers/misc: 2 warnings, 0 errors
drivers/mtd: 464 warnings, 0 errors
drivers/net: 756 warnings, 0 errors
drivers/pcmcia: 3 warnings, 0 errors
drivers/scsi/megaraid: 10 warnings, 0 errors
drivers/scsi/pcmcia: 3 warnings, 0 errors
drivers/scsi: 148 warnings, 0 errors
drivers/telephony: 2 warnings, 0 errors
drivers/video/aty: 4 warnings, 0 errors
drivers/video/kyro: 112 warnings, 0 errors
drivers/video/matrox: 1 warnings, 0 errors
drivers/video: 11 warnings, 0 errors
drivers/w1: 4 warnings, 0 errors
net: 2 warnings, 0 errors
sound/drivers: 2 warnings, 0 errors
sound/oss: 51 warnings, 0 errors
sound/pci: 193 warnings, 0 errors
The module output of these compiles can be found under "Other files".
For 2.6.9, check out...
http://developer.osdl.org/cherry/compile/2.6/linux-2.6.9.results/
John
>
> Matt
>
> On Tue, Oct 19, 2004 at 07:36:15AM -0700, John Cherry wrote:
> > No changes...
> >
> > Linux 2.6 Compile Statistics (gcc 3.2.2)
> >
> > Web page with links to complete details:
> > http://developer.osdl.org/cherry/compile/
> >
> > Kernel bzImage bzImage bzImage modules bzImage modules
> > (defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
> > ----------- ----------- -------- -------- -------- -------- ---------
> > 2.6.9 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> > 2.6.9-final 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> > 2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> > 2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
> > 2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
> > 2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
> > 2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
> > 2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
> > 2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
> > 2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
> > 2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
> > 2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
> > 2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
> > 2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
> > 2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
> > 2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
> > 2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
> > 2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
> > 2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
> > 2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
> > 2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
> > 2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
> > 2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
> > 2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
> > 2.6.3-rc4 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
> > 2.6.3-rc3 1w/0e 0w/0e 145w/ 7e 9w/0e 3w/0e 148w/0e
> > 2.6.3-rc2 1w/0e 0w/0e 141w/ 0e 9w/0e 3w/0e 144w/0e
> > 2.6.3-rc1 1w/0e 0w/0e 145w/ 0e 9w/0e 3w/0e 177w/0e
> > 2.6.2 1w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> > 2.6.2-rc3 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> > 2.6.2-rc2 0w/0e 0w/0e 153w/ 8e 12w/0e 3w/0e 188w/0e
> > 2.6.2-rc1 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> > 2.6.1 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
> > 2.6.1-rc3 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
> > 2.6.1-rc2 0w/0e 0w/0e 166w/ 0e 12w/0e 3w/0e 205w/0e
> > 2.6.1-rc1 0w/0e 0w/0e 167w/ 0e 12w/0e 3w/0e 206w/0e
> > 2.6.0 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
> >
> > Daily compiles (ia32):
> > http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
> > Latest changes in Linus' bitkeeper tree:
> > http://linux.bkbits.net:8080/linux-2.5
> >
> > John
> >
> >
> > --
> > John Cherry
> > [email protected]
> > 503-626-2455x29
> > Open Source Development Labs
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
John Cherry
[email protected]
503-626-2455x29
Open Source Development Labs
On Wed, Oct 20, 2004 at 03:11:26PM -0700, John Cherry wrote:
> On Tue, 2004-10-19 at 09:18, Matthew Dharm wrote:
> > These are x86-based stats, yes? I'm sure other arches will likely tease
> > out more...
>
> Yes, they are x86-based. Other archs are on my list of things to do.
> If you would like to pick up the ball with these other archs, the
> compile tools are at http://developer.osdl.org/cherry/compile/tools/
I've got a setup of my own dealing with i386/amd64/alpha/sparc32/sparc64/ppc
for now (both build and sparse). If you want results published, it's not
a problem...
> A lot of these readl/writel warnings HAVE been addressed. In 2.6.9-rc2,
> there were about 3000 of these warnings. In 2.6.9, there are less than
> 1900.
> drivers/net: 756 warnings, 0 errors
Dealt with.
> drivers/pcmcia: 3 warnings, 0 errors
> drivers/scsi/megaraid: 10 warnings, 0 errors
Ditto.
> drivers/scsi/pcmcia: 3 warnings, 0 errors
> drivers/scsi: 148 warnings, 0 errors
Mostly dealt with, but I'm still messing with SATA parts.
> drivers/telephony: 2 warnings, 0 errors
> drivers/video/aty: 4 warnings, 0 errors
> drivers/video/kyro: 112 warnings, 0 errors
Ditto.
I'll carve up today's fixes and post the patchset in an hour or so...
On Tuesday 19 October 2004 12:38 pm, you wrote:
> On a side note, the GPL buyout previously offered has been modified. We
> will be contacting
> individual contributors and negotiating with each copyright holder for
> the code we wish to
> convert on a case by case basis. The remaining portions of code will
> remain GPL
> The 50K per copy offer still stands for the whole thing if you guys can
> ever figure out
> how to set something like this up.
>
*sigh*
Although I own no code in the kernel, I hope to some day and offers like this
sicken me. It seems that most of the coders have either ignored this person
or flat out said no. His offer is ridiculous and he wants to rip out some of
the most useful code to get what he wants.
However I urge all you developers to stand up and say no. Just out of
curiosity can we get AM, CK, AC,Linus and other major devolpers to say no
publicly? As I understand it these people have all made significant
contributions to the kernel and keeping their code GPL would ensure all this
joker could get (for proprietary greed only shady-business practice purposes)
would be useless in any real project.
I think a large "no" from key players would be a great show of strength in
the ideaologies and commitment many of the developers on this list hold about
the kernel. It would also go a long way in affirming that the true len
----------------------------------------
EB
> All is fine except that I can reliably "oops" it simply by trying to read
> from /proc/apm (e.g. cat /proc/apm).
> oops output and ksymoops-2.3.4 output is attached.
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.
--Alan Cox 2000-12-08
----------------------------------------
> However I urge all you developers to stand up and say no.
What's the point? It's a troll, so just ignore him. Does he himself
sincerely believe this "business plan"? I don't think so. He just tries to
annoy and disturb people.
Hua
On Wednesday 20 October 2004 18:43, Eric Bambach wrote:
> Although I own no code in the kernel, I hope to some day and offers like
> this sicken me. It seems that most of the coders have either ignored this
> person or flat out said no. His offer is ridiculous and he wants to rip out
> some of the most useful code to get what he wants.
>
I have about five lines of code fairly deep in the kernel, and It is only
released under the GPL. Even better, I'm not going to tell where. :)
--Russell
--
Russell Miller - [email protected] - Le Mars, IA
Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs.
http://www.duskglow.com - 712-546-5886
On Wed, 20 Oct 2004 [email protected] wrote:
>
> > drivers/scsi/pcmcia: 3 warnings, 0 errors
> > drivers/scsi: 148 warnings, 0 errors
>
> Mostly dealt with, but I'm still messing with SATA parts.
Jeff had SATA patches - it needs to use the new iomap interfaces, and then
it's much cleaner. I tested that his patches worked for me several weeks
ago, but nor all architectures had the iomap interface, so I assume Jeff
wasn't very eager to push it out.
Anyway, Al, talk to Jeff. Jeff?
Linus
On Wed, 20 Oct 2004, Russell Miller wrote:
> I have about five lines of code fairly deep in the kernel, and It is only
> released under the GPL. Even better, I'm not going to tell where. :)
I'll do that even better. I may have sent patches in the past. I forget what
about. I don't want those changes under anything except the GPL.
Sorry, I have been having this nasty habit of sending out unfinished e-mail
lately(mis-clicks). Anyways in summary a large affirmative no from key
players would solidify Linux's position as being a collaborative and open
project ultimately never for sale. I think it would also show large companies
who are giving support like Novell and IBM a better idea and a concrete
example of what open source and collaborative development is all about.
----------------------------------------
EB
> All is fine except that I can reliably "oops" it simply by trying to read
> from /proc/apm (e.g. cat /proc/apm).
> oops output and ksymoops-2.3.4 output is attached.
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.
--Alan Cox 2000-12-08
----------------------------------------
Linus Torvalds wrote:
>
> On Wed, 20 Oct 2004 [email protected] wrote:
>
>>> drivers/scsi/pcmcia: 3 warnings, 0 errors
>>> drivers/scsi: 148 warnings, 0 errors
>>
>>Mostly dealt with, but I'm still messing with SATA parts.
>
>
> Jeff had SATA patches - it needs to use the new iomap interfaces, and then
> it's much cleaner. I tested that his patches worked for me several weeks
> ago, but nor all architectures had the iomap interface, so I assume Jeff
> wasn't very eager to push it out.
>
> Anyway, Al, talk to Jeff. Jeff?
Current patch is at
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/patch.iomap.bz2
I still merging stuff, so won't get around to it for another day or so :)
I certainly don't mind anyone stealing the task from me, but the effort
is larger than the other iomap conversions. The patch above hits all
the easily-picked fruit, leaving the stuff that requires a modicum of
effort:
* map/unmap N PCI bars (N >= 4, per controller)
* map/unmap 2 ISA I/O regions (0x170, 0x1f0)
* accurately handle the odd situation where IDE driver steals 0x170
while libata steals 0x1f0 (or vice versa), a.k.a. the reason for
quirk_intel_ide_combined() and the ____request_resource nastiness
Currently the code is set up to handle:
* N PIO ports
or
* a single MMIO address that contains all the registers the driver needs
(mmio_base)
On Wed, Oct 20, 2004 at 08:29:59PM -0400, Jeff Garzik wrote:
> Current patch is at
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/patch.iomap.bz2
Got it.
> I still merging stuff, so won't get around to it for another day or so :)
>
> I certainly don't mind anyone stealing the task from me, but the effort
> is larger than the other iomap conversions. The patch above hits all
> the easily-picked fruit, leaving the stuff that requires a modicum of
> effort:
Hey, it's not that there wasn't enough work in other places... I've
picked the patch above for -bird and will happily leave further sata
stuff to you, TYVM ;-)
Speaking of which, since -bk5 is out there now... Could you drop the delta
between it and your current netdev-2.6 somewhere on anonftp? AFAICS there
are 6 patches missing from the pile I've sent to you (3 out of them with
objections I've seen + 1 you've asked to postpone), but there's another
pile waiting to be sent (11 more)...
[email protected] wrote:
> On Wed, Oct 20, 2004 at 08:29:59PM -0400, Jeff Garzik wrote:
>
>>I still merging stuff, so won't get around to it for another day or so :)
>>
>>I certainly don't mind anyone stealing the task from me, but the effort
>>is larger than the other iomap conversions. The patch above hits all
>>the easily-picked fruit, leaving the stuff that requires a modicum of
>>effort:
>>
>>* map/unmap N PCI bars (N >= 4, per controller)
>>* map/unmap 2 ISA I/O regions (0x170, 0x1f0)
>>* accurately handle the odd situation where IDE driver steals 0x170
>>while libata steals 0x1f0 (or vice versa), a.k.a. the reason for
>>quirk_intel_ide_combined() and the ____request_resource nastiness
>>
>>Currently the code is set up to handle:
>>* N PIO ports
>> or
>>* a single MMIO address that contains all the registers the driver needs
>>(mmio_base)
>
>
> Hmm... It misses a bunch of easy stuff, actually (tons of casts to void *
> from what used to be unsigned long and is void __iomem * with your patch).
feel free to send a delta :)
> I don't see where you handle PIO stuff, though - no ioport_map() _or_
> pci_iomap() in sight.
Correct, that part doesn't exist yet. grep in the above quoted text for
"* map/unap" for the to-do list.
The mapping of the PIO PCI BARs requires independently mapping at least
5 (but varies from controller to controller) IO port ranges, and
tracking those mappings in a coherent manner.
Jeff
On Wed, Oct 20, 2004 at 08:29:59PM -0400, Jeff Garzik wrote:
> I still merging stuff, so won't get around to it for another day or so :)
>
> I certainly don't mind anyone stealing the task from me, but the effort
> is larger than the other iomap conversions. The patch above hits all
> the easily-picked fruit, leaving the stuff that requires a modicum of
> effort:
>
> * map/unmap N PCI bars (N >= 4, per controller)
> * map/unmap 2 ISA I/O regions (0x170, 0x1f0)
> * accurately handle the odd situation where IDE driver steals 0x170
> while libata steals 0x1f0 (or vice versa), a.k.a. the reason for
> quirk_intel_ide_combined() and the ____request_resource nastiness
>
> Currently the code is set up to handle:
> * N PIO ports
> or
> * a single MMIO address that contains all the registers the driver needs
> (mmio_base)
Hmm... It misses a bunch of easy stuff, actually (tons of casts to void *
from what used to be unsigned long and is void __iomem * with your patch).
I don't see where you handle PIO stuff, though - no ioport_map() _or_
pci_iomap() in sight. Note that ioport_map() is not equivalent to a cast -
we add a constant there. How does ioread/iowrite work on the results?
On Wed, Oct 20, 2004 at 09:59:47PM -0400, Jeff Garzik wrote:
> >Hmm... It misses a bunch of easy stuff, actually (tons of casts to void *
> >from what used to be unsigned long and is void __iomem * with your patch).
>
> feel free to send a delta :)
Will do.
> >I don't see where you handle PIO stuff, though - no ioport_map() _or_
> >pci_iomap() in sight.
>
> Correct, that part doesn't exist yet. grep in the above quoted text for
> "* map/unap" for the to-do list.
>
> The mapping of the PIO PCI BARs requires independently mapping at least
> 5 (but varies from controller to controller) IO port ranges, and
> tracking those mappings in a coherent manner.
IDGI. Why do you insist on releasing these guys in library code? Even
with iomem case you are creating mappings in driver code, so the reverse
should also be done there...
[email protected] wrote:
> IDGI. Why do you insist on releasing these guys in library code? Even
Because there are two distinct and separate models of port mapping/usage:
1) A bunch of separate IO address spaces (PIO). The "mapping" is
currently done in ata_pci_init_native_mode() and ata_pci_init_legacy_mode()
2) One single linear address space (MMIO). The mapping is done in the
low-level driver.
#1 is in the library because the logic is duplicated _precisely_, across
multiple host controllers, according to a hardware specification.
Thus, if the mapping is done in the library core, so should the unmapping.
Jeff
Hi;
After running 2.6.7 and 2.6.8.1 for ages with no problems,
I just booted into 2.6.9 last night, (using the same .config, and
unchanged userspace) and have been encountering a strange problem:
I generally have 9 'aterm's running on my desktop. The
ones using /dev/pts/[1-8] have been running fine, but the terminal
that uses /dev/pts/9+ have been getting what looks like a burst
of line noise on at the shell prompt, and then it becomes
permanently unresponsive. (this burst of 'noise', seems to happen
periodicly, and is a repetition of this:
~?}#?!}!}!} }8}!}$}"} }"}&} } } } }%}&]O='}'}"}(}"D?~ )
Nothing I do seems to trigger this, it will occur even if
the terminal window doesnt have focus and the machine is idle.
Im not sure if Ive ever seen it happen to two aterms at once-- it
seems to prefer to happen to the first /dev/pts/ number above 8.
(I have see it happen with good old xterm too.)
Currently, I am looking at the shell using /dev/pts/12:
#echo hi > /dev/pts/12
-bash: /dev/pts/12: Device or resource busy
#strace -p <pid-of-bash>
fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR)
read(0, 0xbfffedff, 1) = -1 EAGAIN (Resource temporarily unavailable)
(endlessly repeated, bash is taking most of the cpu spinning on this.)
There are no messages/complaints from the kernel.
Can anyone recommend a patch I can test backing out?
Or suggest what else could explain this?
Paul
[email protected]
machine is an older pIIx2 @400 running Gentoo
.config is attached
On Wed, Oct 20, 2004 at 03:11:26PM -0700, John Cherry wrote:
> Check out the complete details page
> (http://developer.osdl.org/cherry/compile/). Under "Warning/Error
> Module Build Summaries", you can see how the warnings break down by
> module. For 2.6.9, they are...
>
> drivers/cpufreq: 2 warnings, 0 errors
false alarms like these (created by explicit #warnings) really
should be ignored IMO. There's nothing to be fixed here.
At least, not yet.
Dave
On Wed, Oct 20, 2004 at 10:37:10PM -0400, Jeff Garzik wrote:
> [email protected] wrote:
> >IDGI. Why do you insist on releasing these guys in library code? Even
>
> Because there are two distinct and separate models of port mapping/usage:
>
> 1) A bunch of separate IO address spaces (PIO). The "mapping" is
> currently done in ata_pci_init_native_mode() and ata_pci_init_legacy_mode()
>
> 2) One single linear address space (MMIO). The mapping is done in the
> low-level driver.
>
> #1 is in the library because the logic is duplicated _precisely_, across
> multiple host controllers, according to a hardware specification.
>
> Thus, if the mapping is done in the library core, so should the unmapping.
Not really. You are making the case for having a helper that would unmap
for case 1 and having it in the library, just as we do for mapping in that
case. What you have is different, though - it's a single function that does
entire ->remove() for all (AFAICS) SATA drivers.
And that's where the problem is - decision on releasing resource should belong
to the driver; sure, it can and should use library helper, just as it did
when it was grabbing these resources.
Note, BTW, that current ata_pci_remove_one() is begging for trouble - for
one thing, it does iounmap() before we get to ata_scsi_release(), i.e.
ata_host_remove(), i.e. ->port_stop(). And the first look at the drivers
that provide ->port_stop() shows that ahci_port_stop() does readl()/writel()
on the ->mmio_base. Oops...
free_irq() also looks fishy, BTW. How about moving all that group past the
point where you are done with individual ports and merging it (and any other
unmapping we might want to do) into a single callback? Depending on whether
->host_stop() is really needed early we might use ->host_stop for that...
Comments?
Bastiaan Spandaw wrote:
> On Tue, 2004-10-19 at 22:09, Jeff V. Merkey wrote:
>
>
>>>>JFS, XFS, All SMP support in Linux, and RCU.
>>
>>And Numa also.
>>
>>
>>>This isn't SCO code. This goes back to SCO's claims of "control rights"
>>>over any source code that has been in the same room as UNIX code.
>
>
>>No. They seem to have some factual concrete evidence IP covered under
>>Employee agreements was used and subsequently converted into Linux, and they
>>are very confident of this.
Non-compete agreements are VERY tricky, and in some cases are only valid
until/unless the information is made available to the public. Let a
lawyer explain the details, but available to the public seems to mean
that if A steals the info and publishes it, B is no longer bound, or
something like that. Again, let a lawyer clarify, I know there is an
issue but I don't claim to understand the ramifications.
>
>
> bwhahaha...
>
> nice try..
>
> Do you reallly think you (on your own) can defend al those claims?
Since they are SCO's claims, why should he? Or do you wish to attach his
opinion that SCO seems confident?
> (better than all lawyers/persons involved???!?!?!)
> Even though all of them (claims) have been disputed by people more
> knowledgeable than you?
>
> Please leave LKML.
>
> We don't like you nor anything you have to say.
You don't like what he says so you try to shut him up? That argument
doesn't go far in court.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
[email protected] wrote:
> On Wed, Oct 20, 2004 at 10:37:10PM -0400, Jeff Garzik wrote:
>
>>[email protected] wrote:
>>
>>>IDGI. Why do you insist on releasing these guys in library code? Even
>>
>>Because there are two distinct and separate models of port mapping/usage:
>>
>>1) A bunch of separate IO address spaces (PIO). The "mapping" is
>>currently done in ata_pci_init_native_mode() and ata_pci_init_legacy_mode()
>>
>>2) One single linear address space (MMIO). The mapping is done in the
>>low-level driver.
>>
>>#1 is in the library because the logic is duplicated _precisely_, across
>>multiple host controllers, according to a hardware specification.
>>
>>Thus, if the mapping is done in the library core, so should the unmapping.
>
>
> Not really. You are making the case for having a helper that would unmap
> for case 1 and having it in the library, just as we do for mapping in that
Sure: libata is a library, so all functions are helpers. It's just one
more helper function.
> case. What you have is different, though - it's a single function that does
> entire ->remove() for all (AFAICS) SATA drivers.
That's intentional, see below.
> And that's where the problem is - decision on releasing resource should belong
> to the driver; sure, it can and should use library helper, just as it did
> when it was grabbing these resources.
> Note, BTW, that current ata_pci_remove_one() is begging for trouble - for
> one thing, it does iounmap() before we get to ata_scsi_release(), i.e.
> ata_host_remove(), i.e. ->port_stop(). And the first look at the drivers
> that provide ->port_stop() shows that ahci_port_stop() does readl()/writel()
> on the ->mmio_base. Oops...
Ah the perils of an undocumented API :) You're misunderstanding
->port_stop.
That's a bug in ahci: port_stop should never touch the hardware.
port_stop is only for releasing per-driver resources like kmalloc or DMA
memory.
Note... another thing to keep in mind is that all libata drivers use
ata_pci_remove_one() because that makes it possible to smooth over the
differences between 2.4 and 2.6 scsi drivers.
> And that's where the problem is - decision on releasing resource should belong
> to the driver; sure, it can and should use library helper, just as it did
> when it was grabbing these resources.
[...]
> free_irq() also looks fishy, BTW. How about moving all that group past the
> point where you are done with individual ports and merging it (and any other
> unmapping we might want to do) into a single callback? Depending on whether
> ->host_stop() is really needed early we might use ->host_stop for that...
I don't see any problems, given what I just wrote above.
Just the annoyance of individually mapping and unmapping 4 or 5 PCI
BARs, and mixing 4 ranges of ISA legacy ioports for good measure.
Now... addressing the overall theme of your message... eventually
libata wants to move to a strict port_{start,stop}, host_{start,stop}
mechanism where the driver does more of the heavy lifting [by providing
hooks that call libata helpers, rather than a helper calling hooks as
ata_pci_remove_one does now].
But to get there will take _many_ iterations, since two things get in
the way there:
* 2.4 compat
* the necessity to issue several ATA commands before we can respond to
-any- SCSI commands
Jeff
On Iau, 2004-10-21 at 03:41, Paul wrote:
> permanently unresponsive. (this burst of 'noise', seems to happen
> periodicly, and is a repetition of this:
> ~}#!}!}!} }8}!}$}"} }"}&} } } } }%}&]O='}'}"}(}"D~ )
Thats a PPP LCP conf request as far as I can decode it. You've got
a stuck pppd somewhere - thats a minor bug in 2.6.9rc and 2.6.9 that got
introduced by the tty changes. I'll try and fix it ASAP if Paul doesn't
beat me to it.
kill the stuck pppd
>
On Thu, Oct 21, 2004 at 10:07:42AM +0100, Alan Cox wrote:
> On Iau, 2004-10-21 at 03:41, Paul wrote:
> > permanently unresponsive. (this burst of 'noise', seems to happen
> > periodicly, and is a repetition of this:
> > ~}#!}!}!} }8}!}$}"} }"}&} } } } }%}&]O='}'}"}(}"D~ )
>
> Thats a PPP LCP conf request as far as I can decode it. You've got
> a stuck pppd somewhere - thats a minor bug in 2.6.9rc and 2.6.9 that got
> introduced by the tty changes. I'll try and fix it ASAP if Paul doesn't
> beat me to it.
I'm seeing random failures of krb5 login with 2.6.9 kernels - which has
happened somewhere between 2.6.8.1 and 2.6.9-rc3. It's proving impossible
to debug because stracing eklogin results in the problem completely
vanishing.
Without the strace, it's reproducable in about 50% of cases.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, 2004-10-21 at 04:07, Alan Cox wrote:
> Thats a PPP LCP conf request as far as I can decode it. You've got
> a stuck pppd somewhere - thats a minor bug in 2.6.9rc and 2.6.9 that got
> introduced by the tty changes. I'll try and fix it ASAP if Paul doesn't
> beat me to it.
I'm just about to start.
I was thinking a reasonable solution would be
to queue work in tty_do_hangup() if ldisc->hangup()
is not defined (== NULL) to switch the ldisc back to N_TTY.
It looks like Alan may have tried something similar
with tty_deferred_ldisc_switch(N_TTY).
If tty_set_ldisc() is called before the work runs
then the work is cancelled. This also cancels
the work if close is called before it runs.
(close sets back to N_TTY anyways)
This restores the original behavior for
devices that have not yet implemented ldisc->hangup()
and should work with the new locking.
--
Paul Fulghum
[email protected]
On Thu, 2004-10-21 at 08:20, Paul Fulghum wrote:
> I was thinking a reasonable solution would be
> to queue work in tty_do_hangup() if ldisc->hangup()
> is not defined (== NULL) to switch the ldisc back to N_TTY.
Nevermind, I now see why this won't work.
tty_set_ldisc() calls flush_scheduled_work() so
it can't be called from a work routine on the
default events queue.
I'll now look at adding the hangup() method to ppp_*.c
--
Paul Fulghum
[email protected]
On Iau, 2004-10-21 at 14:20, Paul Fulghum wrote:
> This restores the original behavior for
> devices that have not yet implemented ldisc->hangup()
> and should work with the new locking.
Unfortunately that re-introduces another existing unfixed problem. The
N_TTY layer echoes bytes back up the stack into the drivers which are in
hangup state.
I did try calling the set_tty_ldisc but not every driver in that
situation then did the right thing and I got stuck ttys too. I think
that is fixed but 2.6.9rc4 was a bit tight.
If you want to do the tty_ldisc_set then add a "nulldisc" that just eats
anything it is fed and EOF's anything the other direction. That
would avoid the driver reflect crash I suspect.
On Thu, 2004-10-21 at 10:37, Alan Cox wrote:
> On Iau, 2004-10-21 at 14:20, Paul Fulghum wrote:
> > This restores the original behavior for
> > devices that have not yet implemented ldisc->hangup()
> > and should work with the new locking.
>
> Unfortunately that re-introduces another existing unfixed problem.
I also realized that the original code *only*
called ldisc->close if the current ldisc != N_TTY.
So I was wrong in interpreting this as using
ldisc->close to indicate hangup in a general sense
because it does not apply to N_TTY.
So depending on this behavior is wrong,
and implementing ldisc->hangup is the way to go.
I'm working on the PPP ldisc now.
--
Paul Fulghum
[email protected]
On Thu, 2004-10-21 at 04:07, Alan Cox wrote:
> introduced by the tty changes. I'll try and fix it ASAP if Paul doesn't
> beat me to it.
I reviewed, patched, and tested ppp_async.c to
implement ldisc->hangup(). This correctly terminates
the PPP connection on hangup.
Paul Mackerras already did an excellent job of
ensuring safe shutdown and I/O completion
in ldisc->close so the change is trivial:
just add the ldisc->hangup and call the
existing close routine.
One question to Alan: what is the return code
in ldisc->hangup for? The docs don't say.
--
Paul Fulghum
[email protected]
--- linux-2.6.9-bk4/drivers/net/ppp_async.c 2004-10-18 16:54:40.000000000 -0500
+++ b/drivers/net/ppp_async.c 2004-10-21 12:50:50.000000000 -0500
@@ -238,6 +238,18 @@ ppp_asynctty_close(struct tty_struct *tt
}
/*
+ * Called on tty hangup in process context.
+ *
+ * Wait for I/O to driver to complete and unregister PPP channel.
+ * This is already done by the close routine, so just call that.
+ */
+static int ppp_asynctty_hangup(struct tty_struct *tty)
+{
+ ppp_asynctty_close(tty);
+ return 0;
+}
+
+/*
* Read does nothing - no data is ever available this way.
* Pppd reads and writes packets via /dev/ppp instead.
*/
@@ -380,6 +392,7 @@ static struct tty_ldisc ppp_ldisc = {
.name = "ppp",
.open = ppp_asynctty_open,
.close = ppp_asynctty_close,
+ .hangup = ppp_asynctty_hangup,
.read = ppp_asynctty_read,
.write = ppp_asynctty_write,
.ioctl = ppp_asynctty_ioctl,
[I now pronounce the following benediction: IANAL. $DEITY, give
me the strength to show reasoned restraint.]
On Tuesday 19 October 2004 03:09 pm, you wrote:
> No. They seem to have some factual concrete evidence IP
> covered under Employee
> agreements was used and subsequently converted into Linux, and
> they are very
> confident of this. From a cursory viewpoint, it looks valid.
> I think they have a case
> (having been sued and nailed for the same type of thing by
> Novell).
So very certain you are...
...but in any case, that doesn't mean much to me.
I think it's perfectly reasonable for me to believe what SCO
admits in court, rather than what SCO might have fooled you into
believing (after all of a cursory inspection) or persuaded you
to lie about. And what SCO is lately forced to admit in court
is that it has no evidence of copyright infringement in Linux.
After over a year of claiming to have "mountains" of this
evidence and after multiple court orders to disclose this
evidence, the best SCO can cough up doesn't pass muster. SCO's
"smoking gun" samples were either nonprotectable or were cobbled
together in a half-assed attempt at evidence doctoring.
Not to mention which, "non-literal coypright infringement" is an
oxymoron in almost all federal circuits, so don't even go down
that road.
[If this sounds to you like an ad-hominem attack, well...tough
shit in advance, I'm just being realistic. Grow some thicker
skin.]
> Dump the FS's and NUMA guys. Then you are nearly there for
> being squeaky clean.
So far I've seen no plausible evidence that we aren't already
there. The bare word of a company/CEO that's already been
caught stretching the truth counts for pretty much nothing.
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
On Tue, 2004-10-19 at 09:18, Matthew Dharm wrote:
> These are x86-based stats, yes? I'm sure other arches will likely tease
> out more...
Yes, they are x86-based. Other archs are on my list of things to do.
If you would like to pick up the ball with these other archs, the
compile tools are at http://developer.osdl.org/cherry/compile/tools/
>
> A lot of these seem to be related to readl/writel (readb/writeb, etc).
> Those should be straightforward one-line changes, I think... perhaps a job
> for more automated scripting?
A lot of these readl/writel warnings HAVE been addressed. In 2.6.9-rc2,
there were about 3000 of these warnings. In 2.6.9, there are less than
1900.
>
> At the very least, it would be nice to post-process the data to show which
> modules are the offenders (and by how much).
Check out the complete details page
(http://developer.osdl.org/cherry/compile/). Under "Warning/Error
Module Build Summaries", you can see how the warnings break down by
module. For 2.6.9, they are...
drivers/atm: 6 warnings, 0 errors
drivers/block: 1 warnings, 0 errors
drivers/cpufreq: 2 warnings, 0 errors
drivers/isdn: 90 warnings, 0 errors
drivers/media: 86 warnings, 0 errors
drivers/misc: 2 warnings, 0 errors
drivers/mtd: 464 warnings, 0 errors
drivers/net: 756 warnings, 0 errors
drivers/pcmcia: 3 warnings, 0 errors
drivers/scsi/megaraid: 10 warnings, 0 errors
drivers/scsi/pcmcia: 3 warnings, 0 errors
drivers/scsi: 148 warnings, 0 errors
drivers/telephony: 2 warnings, 0 errors
drivers/video/aty: 4 warnings, 0 errors
drivers/video/kyro: 112 warnings, 0 errors
drivers/video/matrox: 1 warnings, 0 errors
drivers/video: 11 warnings, 0 errors
drivers/w1: 4 warnings, 0 errors
net: 2 warnings, 0 errors
sound/drivers: 2 warnings, 0 errors
sound/oss: 51 warnings, 0 errors
sound/pci: 193 warnings, 0 errors
The module output of these compiles can be found under "Other files".
For 2.6.9, check out...
http://developer.osdl.org/cherry/compile/2.6/linux-2.6.9.results/
John
>
> Matt
>
> On Tue, Oct 19, 2004 at 07:36:15AM -0700, John Cherry wrote:
> > No changes...
> >
> > Linux 2.6 Compile Statistics (gcc 3.2.2)
> >
> > Web page with links to complete details:
> > http://developer.osdl.org/cherry/compile/
> >
> > Kernel bzImage bzImage bzImage modules bzImage modules
> > (defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
> > ----------- ----------- -------- -------- -------- -------- ---------
> > 2.6.9 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> > 2.6.9-final 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> > 2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> > 2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
> > 2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
> > 2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
> > 2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
> > 2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
> > 2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
> > 2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
> > 2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
> > 2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
> > 2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
> > 2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
> > 2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
> > 2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
> > 2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
> > 2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
> > 2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
> > 2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
> > 2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
> > 2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
> > 2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
> > 2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
> > 2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
> > 2.6.3-rc4 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
> > 2.6.3-rc3 1w/0e 0w/0e 145w/ 7e 9w/0e 3w/0e 148w/0e
> > 2.6.3-rc2 1w/0e 0w/0e 141w/ 0e 9w/0e 3w/0e 144w/0e
> > 2.6.3-rc1 1w/0e 0w/0e 145w/ 0e 9w/0e 3w/0e 177w/0e
> > 2.6.2 1w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> > 2.6.2-rc3 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> > 2.6.2-rc2 0w/0e 0w/0e 153w/ 8e 12w/0e 3w/0e 188w/0e
> > 2.6.2-rc1 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
> > 2.6.1 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
> > 2.6.1-rc3 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
> > 2.6.1-rc2 0w/0e 0w/0e 166w/ 0e 12w/0e 3w/0e 205w/0e
> > 2.6.1-rc1 0w/0e 0w/0e 167w/ 0e 12w/0e 3w/0e 206w/0e
> > 2.6.0 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
> >
> > Daily compiles (ia32):
> > http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
> > Latest changes in Linus' bitkeeper tree:
> > http://linux.bkbits.net:8080/linux-2.5
> >
> > John
> >
> >
> > --
> > John Cherry
> > [email protected]
> > 503-626-2455x29
> > Open Source Development Labs
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
Pekka Pietikainen wrote:
>On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
>
>
>>On a side note, the GPL buyout previously offered has been modified. We
>>will be contacting individual contributors and negotiating with each
>>copyright holder for the code we wish to convert on a case by case basis.
>>
>>
>Hi
>
>arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two beers
>(I believe nobody else has touched it so it should be all mine).
>
>The other files of the port to that very fine architecture are largely done
>by other people, so unfortunately I can't relicense those.
>
>
>
Hurray! Got one. You're added to the list.
:-)
Jeff
Russell King wrote:
>On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
>
>
>>On a side note, the GPL buyout previously offered has been modified. We
>>will be contacting
>>individual contributors and negotiating with each copyright holder for
>>the code we wish to
>>convert on a case by case basis. The remaining portions of code will
>>remain GPL
>>The 50K per copy offer still stands for the whole thing if you guys can
>>ever figure out
>>how to set something like this up.
>>:-)
>>
>>
>
>Don't bother contacting me. I'll give you my answer now. Refused for
>all work contributed by myself.
>
>
>
Hadn't gotten that far down the list yet, but thanks for the feedback.
I put an X through that one.
Jeff
On Tue Oct 19, 2004 at 02:27:30PM -0600, Jeff V. Merkey wrote:
> Pekka Pietikainen wrote:
> >arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two
> >beers (I believe nobody else has touched it so it should be all mine).
> >
> >The other files of the port to that very fine architecture are largely done
> >by other people, so unfortunately I can't relicense those.
> >
> >
> >
> Hurray! Got one. You're added to the list.
Do remember to replace the included inlines with your own code.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Tue, 18 Oct 2004 [email protected] wrote:
> Linus Torvalds <[email protected]> writes:
>
> > Ok,
> > despite some naming confusion (expanation: I'm a retard), I did end up
> > doing the 2.6.9 release today. And it wasn't the same as the "-final" test
> > release (see explanation above).
> >
> > Excuses aside, not a lot of changes since -rc4 (which was the last
> > announced test-kernel), mainly some UML updates that don't affect anybody
> > else. And a number of one-liners or compiler fixes. Full list appended.
>
> The ChangeLog-2.6.9 only list changes from v2.6.9-rc4 and not 2.6.8
>
> ChangeLogs that don't cover the same set of changes their corresponding
> patches cover just don't seem right somehow.
>
I agree, that was bugging me as well. Having the full ChangeLog to the
previous version in kernel.org/pub/linux/kernel/v2.6/ is useful, having
only a partial log is less so.
Could we please get the complete 2.6.8 -> 2.6.9 ChangeLog there?
--
Jesper Juhl
On Tue, Oct 19, 2004 at 09:18:34AM -0700, Matthew Dharm wrote:
> These are x86-based stats, yes? I'm sure other arches will likely tease
> out more...
>
> A lot of these seem to be related to readl/writel (readb/writeb, etc).
> Those should be straightforward one-line changes, I think... perhaps a job
> for more automated scripting?
>
> At the very least, it would be nice to post-process the data to show which
> modules are the offenders (and by how much).
Note that quite a few of them are already fixed, and no, not all fixes
had been trivial (read: there had been real bugs found by these warnings).
I'm going to do 2.6.9-bird1 once netdev situation settles down (a bunch of
patches from -bird are getting merged into bk-net).
[ shortened CC: because it is not that inreseting ]
On Tue, 2004-10-19 at 14:09 -0600, Jeff V. Merkey wrote:
[...]
> No. They seem to have some factual concrete evidence IP covered under
> Employee
> agreements was used and subsequently converted into Linux, and they are
> very
> confident of this. From a cursory viewpoint, it looks valid. I think
They did not and do not show in court anything (and didn't showed
anything that passed the simple checks in other places) though they were
askes several times by the judge.
So AFAICT and IMHO (and IANAL) there is no reason to believe they have
anything (except false accusations, rumors, FUD, creative selection of
truth, and lies).
So even from cursory viewpoint one should primarily see the pure facts
and afterwards (with separate quality) believe in words.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
first i was slighly puzzled and suspected that your mail server somehow
delayed your outgoing email for ~1.5 years then i found what i believe
is the secret message hidden in your email:
* Jeff V. Merkey <[email protected]> wrote:
> [...] The memory sickness [...]
> [...] I was experiencing [...]
> [...] is constant [...]
please confirm decoding was correct! Meanwhile our secret message back
to agent 000 is:
IN THAT CONDITION MUST NOT POST TO LKML UNDER ANY CIRCUMSTANCE!
[this message has been caps-encrypted. COMPARTMENTED 12B3. EYES ONLY.]
Ingo
On Tue, Oct 19, 2004 at 02:09:28PM -0600, Jeff V. Merkey wrote:
[snip]
> No. They seem to have some factual concrete evidence IP covered under
> Employee
> agreements was used and subsequently converted into Linux, and they are
> very
> confident of this. From a cursory viewpoint, it looks valid. I think
> they have a case
> (having been sued and nailed for the same type of thing by Novell).
(Quoting from groklaw wrt that lawsuit:)
"The judge had a few descriptive words for Mr. Merkey, as you will note
particularly in paragraph 123 - 125 of the Findings of Fact:
124. In fact, however, Merkey is not just prone to exaggeration, he also
is and can be deceptive, not only to his adversaries, but also to his
own partners, his business associates and to the court. He deliberately
describes his own, separate reality."
[snip]
Meanwhile, life goes on as usual in the real world.
Oh, and if you happen to need any code I might have contributed to the
kernel, it's available under the GPL. Only.
Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
David Weinehall wrote:
>On Tue, Oct 19, 2004 at 02:09:28PM -0600, Jeff V. Merkey wrote:
>[snip]
>
>
>
>>No. They seem to have some factual concrete evidence IP covered under
>>Employee
>>agreements was used and subsequently converted into Linux, and they are
>>very
>>confident of this. From a cursory viewpoint, it looks valid. I think
>>they have a case
>>(having been sued and nailed for the same type of thing by Novell).
>>
>>
>
>(Quoting from groklaw wrt that lawsuit:)
>
>"The judge had a few descriptive words for Mr. Merkey, as you will note
> particularly in paragraph 123 - 125 of the Findings of Fact:
>
> 124. In fact, however, Merkey is not just prone to exaggeration, he also
> is and can be deceptive, not only to his adversaries, but also to his
> own partners, his business associates and to the court. He deliberately
> describes his own, separate reality."
>
>[snip]
>
>Meanwhile, life goes on as usual in the real world.
>
>Oh, and if you happen to need any code I might have contributed to the
>kernel, it's available under the GPL. Only.
>
>
>Regards: David Weinehall
>
>
This was written by Novell's stooge Judge Schoefield. It's total
fiction. Don't worry, it will get cleared up soon.
More bugs to find ....
Jeff
On Fri, Oct 22, 2004 at 10:15:00AM -0600, Jeff V. Merkey wrote:
> This was written by Novell's stooge Judge Schoefield. It's total
> fiction. Don't worry, it will get cleared up soon.
>
> More bugs to find ....
Out of curiosity, which bugs are you using? Never heard of hallucinogenic
insects to be found in Utah...
Al Viro wrote:
>On Fri, Oct 22, 2004 at 10:15:00AM -0600, Jeff V. Merkey wrote:
>
>
>>This was written by Novell's stooge Judge Schoefield. It's total
>>fiction. Don't worry, it will get cleared up soon.
>>
>>More bugs to find ....
>>
>>
>
>Out of curiosity, which bugs are you using? Never heard of hallucinogenic
>insects to be found in Utah...
>
>
>
Al,
This is a high traffic list. I am refering to the bugs in my code and
occasionally the ones I find in Linux
that for some reason get challenged everytime I post, then get fixed in
subsequent patches. :-)
So I am sticking to bugs from now on. On the GPL buyout, when stuff gets
released publically,
it will be clear this was an an attempt to help you guys and shut down
the SCO/Canopy/Novell
legal ranglings. I just want to develop code and have fun. Time to get
back to that.
At least the bugs get fixed. There is a hallucinogenic toad (Bufus
Coloradus) the colorado river toad that lives
about 4 hours drive from here, and it secretes 5-DMT when you lick it's
back. Some indian showed this to california hippies
and now the toads are endamgered. It's the closest thing to a
hallucingenic bug I can think of. It's a felony to
possess these toads now in the US (Freeze - drop that toad - your honor,
upon approaching the vehicle I heard
a strange croaking noise coming from the trunk, upon inspection, I found
these -- colorado river toads).
Jeff
Jeff V. Merkey wrote:
SCO Just sent over a list of contaminated files with a "bill of health"
certification for Linux that if we remove the identified files
they will certify our Linux distribution as clean. They are also sending
out some form of statement that we are
not affiliated with them, and that we are competitors of SCO since we
use Linux. They claim the following and I have
a listing of files, lines numbers, etc. they told us we must remove in
order for our Linux appliances to be considered
"clean." This info might be useful to others. They have a cert program
to remove the areas.
Here it is. I can get the line numbers of the file and their names if
anyone needs it, but the list is very big.
RCU
46 files
109,688 lines
NUMA
101 files
56,587 lines
JFS
44 files
32,224 lines
XFS
173 Files
119,130 lines
SMP
1,185 files
829,393 lines
Total files/lines they [allege] contains SCO source code
1,549 files
1,147,022 lines
If you guys want the specific line numbers and filenames, I will ask
them to post the specific filenames/line numbers they claim
are theirs. They stated we can ship Linux with fear of being sued if we
comply with their Linux Certification Program.
> If you guys want the specific line numbers and filenames, I will ask
> them to post the specific filenames/line numbers they claim
> are theirs. They stated we can ship Linux with fear of being sued if we
> comply with their Linux Certification Program.
Looking at the previous actions of SCO I 100% believe that.
Grahame
On Fri, 22 Oct 2004 13:37:28 -0600, Jeff V. Merkey <[email protected]> wrote:
> Jeff V. Merkey wrote:
[ snip ]
> are theirs. They stated we can ship Linux with fear of being sued if we
> comply with their Linux Certification Program.
Whoops, better not comply then.
Later,
Buddy
On Fri, 22 Oct 2004, Jeff V. Merkey wrote:
> Jeff V. Merkey wrote:
>
> SCO Just sent over a list of contaminated files with a "bill of health"
> certification for Linux that if we remove the identified files
> they will certify our Linux distribution as clean. They are also sending out
> some form of statement that we are
> not affiliated with them, and that we are competitors of SCO since we use
> Linux. They claim the following and I have
> a listing of files, lines numbers, etc. they told us we must remove in order
> for our Linux appliances to be considered
> "clean." This info might be useful to others. They have a cert program to
> remove the areas.
>
> Here it is. I can get the line numbers of the file and their names if anyone
> needs it, but the list is very big.
>
> RCU
> 46 files
> 109,688 lines
>
> NUMA
> 101 files
> 56,587 lines
>
> JFS
> 44 files
> 32,224 lines
>
> XFS
> 173 Files
> 119,130 lines
>
> SMP
> 1,185 files
> 829,393 lines
>
> Total files/lines they [allege] contains SCO source code
> 1,549 files
> 1,147,022 lines
>
> If you guys want the specific line numbers and filenames, I will ask them to
> post the specific filenames/line numbers they claim
> are theirs. They stated we can ship Linux with fear of being sued if we
> comply with their Linux Certification Program.
>
You can ship Linux without fear of being sued anyway.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
On Fri, 2004-10-22 at 13:37 -0600, Jeff V. Merkey wrote:
> Jeff V. Merkey wrote:
> ...
> They stated we can ship Linux with fear of being sued if we
> comply with their Linux Certification Program.
Sure, sounds like SCO.
if (comply)
fear_to_be_sued = true;
else
fear_to_be_sued = true;
hahahaha
tglx
Salut,
On Tue, Oct 19, 2004 at 10:30:40PM +0200, Thomas Gleixner wrote:
> Hey, why do you rip out all the code ?
>
> http://kernel.org/pub/linux/kernel/v1.0/linux-1.0.tar.bz2
>
> contains none of it.
ftp://zeus.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz
which is a clean... err.. dark and messy room implementation, and is
essentially free of code that might have been contributed by others.
Tonnerre
On Tue, 19 Oct 2004 11:38:03 -0600, Jeff V. Merkey <[email protected]> wrote:
> The memory sickness with disappearing buffers, and the BIO callback
> problems with the SCSI layer previously reported appear to be corrected.
Do you even know anything about the above?
> This release is very solid and withstands 400 MB/S I/O to disk from
> 3GB/1GB split kernel/user memory configurations
Oh good.
> stable enough for us to use and ship in our products based on our
> testing of the 2.6.9 release over two days.
Wow! That's quality there. Do you model your testing process on SCO
directly? i.e. can I have you go on record that your testing process
is satisfied after two days of testing?
> On a side note, the GPL buyout previously offered has been modified. We
> will be contacting individual contributors and negotiating with each copyright holder
Please do keep me aprised of this Jeff. I am quite certain that my
readers will find your anecdotes more than amusing.
> SCO has contacted us and identifed with precise detail and factual
> documentation the code and intellectual property in Linux they claim was
> taken from Unix. We have reviewed their claims and they appear to create enough
> uncertianty to warrant removal of the infringing portions.
Will you offer that as an undertaking, properly signed and sealed,
though? If these unfortunate sections of code are removed, will you
guarantee SCO won't sue?
> We have identified and removed the infringing portions of Linux for our
> products that SCO claims was stolen from Unix.
> and RCU.
But elsewhere you said:
> I have no idea what the hell RCU is
Since this came up in this week's LWN kernel page (you really should
read LWN, it's filled with fascinating content and even features a
special discussion relating to your posting), one simply must ask -
how did you remove code that you do not understand? I really
absolutely want to know how this is possible, because if you have
found a technique for doing this then we can farm off all the really
complex cleanups to MCSE qualified technicians to do instead. This
would save core kernel developers unnecessary hassle and free up their
time to consider your offer in further levels of detail.
> They make claims of other portions of Linux which were taken, however,
> these other claims do not appear to be supported with factual evidence.
Can you guarantee that?
Jon.
Jon Masters wrote:
>On Tue, 19 Oct 2004 11:38:03 -0600, Jeff V. Merkey <[email protected]> wrote:
>
>
>
>>The memory sickness with disappearing buffers, and the BIO callback
>>problems with the SCSI layer previously reported appear to be corrected.
>>
>>
>
>Do you even know anything about the above?
>
>
Yeah. I reported both in two threads.
>
>
>>This release is very solid and withstands 400 MB/S I/O to disk from
>>3GB/1GB split kernel/user memory configurations
>>
>>
>
>Oh good.
>
>
>
>>stable enough for us to use and ship in our products based on our
>>testing of the 2.6.9 release over two days.
>>
>>
>
>Wow! That's quality there. Do you model your testing process on SCO
>directly? i.e. can I have you go on record that your testing process
>is satisfied after two days of testing?
>
>
>
No. It's still running with the following metrics, it's been up all
week, and it doesn't
crash in 20 minutes, which it always did before, and my BIO multiple
page requests
don't corrupt memory anymore:
MemTotal: 2983468 kB
MemFree: 140692 kB
Buffers: 218568 kB
Cached: 128308 kB
SwapCached: 0 kB
Active: 169904 kB
Inactive: 191432 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 2983468 kB
LowFree: 140692 kB
SwapTotal: 1052248 kB
SwapFree: 1052248 kB
Dirty: 132 kB
Writeback: 0 kB
Mapped: 18608 kB
Slab: 2472572 kB
Committed_AS: 95480 kB
PageTables: 1060 kB
VmallocTotal: 122804 kB
VmallocUsed: 3248 kB
VmallocChunk: 119088 kB
slabinfo - version: 2.0
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> :
tunables <batchcount> <limit> <sharedfactor> : slabdata <active_slabs>
<num_slabs> <sharedavail>
bt_sock 3 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0
ip_fib_alias 11 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_hash 11 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_cmd_cache 160 160 384 10 1 : tunables 54 27 0 : slabdata 16 16 0
sgpool-128 32 32 2048 2 1 : tunables 24 12 0 : slabdata 16 16 0
sgpool-64 32 32 1024 4 1 : tunables 54 27 0 : slabdata 8 8 0
sgpool-32 79 136 512 8 1 : tunables 54 27 0 : slabdata 11 17 0
sgpool-16 45 45 256 15 1 : tunables 120 60 0 : slabdata 3 3 0
sgpool-8 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
dm_tio 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0
dm_io 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0
uhci_urb_priv 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0
dn_fib_info_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
dn_dst_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0
dn_neigh_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0
decnet_socket_cache 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
clip_arp_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0
xfrm6_tunnel_spi 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0
fib6_nodes 13 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 51 90 256 15 1 : tunables 120 60 0 : slabdata 6 6 0
ndisc_cache 9 30 256 15 1 : tunables 120 60 0 : slabdata 2 2 0
rawv6_sock 3 6 640 6 1 : tunables 54 27 0 : slabdata 1 1 0
udpv6_sock 0 0 640 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcpv6_sock 2 7 1152 7 2 : tunables 24 12 0 : slabdata 1 1 0
unix_sock 40 40 384 10 1 : tunables 54 27 0 : slabdata 4 4 0
ip_mrt_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
tcp_tw_bucket 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
tcp_bind_bucket 1 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0
tcp_open_request 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0
secpath_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
xfrm_dst_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0
ip_dst_cache 7 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
arp_cache 1 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
raw_sock 2 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0
udp_sock 4 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0
tcp_sock 0 0 1024 4 1 : tunables 54 27 0 : slabdata 0 0 0
flow_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
isofs_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
fat_inode_cache 0 0 340 11 1 : tunables 54 27 0 : slabdata 0 0 0
ext2_inode_cache 0 0 400 10 1 : tunables 54 27 0 : slabdata 0 0 0
journal_handle 37 135 28 135 1 : tunables 120 60 0 : slabdata 1 1 0
journal_head 92 243 48 81 1 : tunables 120 60 0 : slabdata 3 3 0
revoke_table 4 290 12 290 1 : tunables 120 60 0 : slabdata 1 1 0
revoke_record 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0
ext3_inode_cache 389931 397737 440 9 1 : tunables 54 27 0 : slabdata
44193 44193 0
ext3_xattr 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0
reiser_inode_cache 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
dquot 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
eventpoll_pwq 0 0 36 107 1 : tunables 120 60 0 : slabdata 0 0 0
eventpoll_epi 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
kioctx 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_cache 0 0 20 185 1 : tunables 120 60 0 : slabdata 0 0 0
fasync_cache 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 4 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0
posix_timers_cache 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 1 61 64 61 1 : tunables 120 60 0 : slabdata 1 1 0
cfq_pool 64 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0
crq_pool 0 0 36 107 1 : tunables 120 60 0 : slabdata 0 0 0
deadline_drq 0 0 48 81 1 : tunables 120 60 0 : slabdata 0 0 0
as_arq 205 390 60 65 1 : tunables 120 60 0 : slabdata 6 6 0
blkdev_ioc 42 185 20 185 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_queue 21 24 456 8 1 : tunables 54 27 0 : slabdata 3 3 0
blkdev_requests 218 234 152 26 1 : tunables 120 60 0 : slabdata 9 9 0
biovec-(256) 256 256 3072 2 2 : tunables 24 12 0 : slabdata 128 128 0
biovec-128 256 260 1536 5 2 : tunables 24 12 0 : slabdata 52 52 0
biovec-64 256 260 768 5 1 : tunables 54 27 0 : slabdata 52 52 0
biovec-16 131331 131340 256 15 1 : tunables 120 60 0 : slabdata 8756 8756 0
biovec-4 256 305 64 61 1 : tunables 120 60 0 : slabdata 5 5 0
biovec-1 319 452 16 226 1 : tunables 120 60 0 : slabdata 2 2 0
bio 131370 131394 64 61 1 : tunables 120 60 0 : slabdata 2154 2154 0
file_lock_cache 45 45 88 45 1 : tunables 120 60 0 : slabdata 1 1 0
sock_inode_cache 70 70 384 10 1 : tunables 54 27 0 : slabdata 7 7 0
skbuff_head_cache 2076 2115 256 15 1 : tunables 120 60 0 : slabdata 141
141 0
sock 22 30 384 10 1 : tunables 54 27 0 : slabdata 3 3 0
proc_inode_cache 320 416 308 13 1 : tunables 54 27 0 : slabdata 32 32 0
sigqueue 27 27 148 27 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 14371 20552 276 14 1 : tunables 54 27 0 : slabdata 1468
1468 0
bdev_cache 9 14 512 7 1 : tunables 54 27 0 : slabdata 2 2 0
mnt_cache 21 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
inode_cache 3465 3484 292 13 1 : tunables 54 27 0 : slabdata 268 268 0
dentry_cache 325624 352016 140 28 1 : tunables 120 60 0 : slabdata 12572
12572 0
filp 651 735 256 15 1 : tunables 120 60 0 : slabdata 49 49 0
names_cache 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
idr_layer_cache 101 116 136 29 1 : tunables 120 60 0 : slabdata 4 4 0
buffer_head 56316 60750 48 81 1 : tunables 120 60 0 : slabdata 750 750 0
mm_struct 73 84 640 6 1 : tunables 54 27 0 : slabdata 14 14 0
vm_area_struct 1508 1645 84 47 1 : tunables 120 60 0 : slabdata 35 35 0
fs_cache 119 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 77 77 512 7 1 : tunables 54 27 0 : slabdata 11 11 0
signal_cache 124 124 128 31 1 : tunables 120 60 0 : slabdata 4 4 0
sighand_cache 105 105 1408 5 2 : tunables 24 12 0 : slabdata 21 21 0
task_struct 105 105 1376 5 2 : tunables 24 12 0 : slabdata 21 21 0
anon_vma 754 1221 8 407 1 : tunables 120 60 0 : slabdata 3 3 0
pgd 73 73 4096 1 1 : tunables 24 12 0 : slabdata 73 73 0
size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
size-131072 1 1 131072 1 32 : tunables 8 4 0 : slabdata 1 1 0
size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
size-65536 32950 32950 65536 1 16 : tunables 8 4 0 : slabdata 32950 32950 0
size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0
size-32768 7 7 32768 1 8 : tunables 8 4 0 : slabdata 7 7 0
size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0
size-16384 35 35 16384 1 4 : tunables 8 4 0 : slabdata 35 35 0
size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0
size-8192 107 107 8192 1 2 : tunables 8 4 0 : slabdata 107 107 0
size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 0 : slabdata 0 0 0
size-4096 2101 2101 4096 1 1 : tunables 24 12 0 : slabdata 2101 2101 0
size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 0 : slabdata 0 0 0
size-2048 32964 32964 2048 2 1 : tunables 24 12 0 : slabdata 16482 16482 0
size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 0 : slabdata 0 0 0
size-1024 195 200 1024 4 1 : tunables 54 27 0 : slabdata 50 50 0
size-512(DMA) 0 0 512 8 1 : tunables 54 27 0 : slabdata 0 0 0
size-512 186 560 512 8 1 : tunables 54 27 0 : slabdata 70 70 0
size-256(DMA) 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0
size-256 263 465 256 15 1 : tunables 120 60 0 : slabdata 31 31 0
size-128(DMA) 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
size-128 2267 2294 128 31 1 : tunables 120 60 0 : slabdata 74 74 0
size-64(DMA) 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0
size-64 4152 4453 64 61 1 : tunables 120 60 0 : slabdata 73 73 0
size-32(DMA) 0 0 32 119 1 : tunables 120 60 0 : slabdata 0 0 0
size-32 53338 53431 32 119 1 : tunables 120 60 0 : slabdata 449 449 0
kmem_cache 124 124 128 31 1 : tunables 120 60 0 : slabdata 4 4 0
>>SCO has contacted us and identifed with precise detail and factual
>>documentation the code and intellectual property in Linux they claim was
>>taken from Unix. We have reviewed their claims and they appear to create enough
>>uncertianty to warrant removal of the infringing portions.
>>
>>
>
>Will you offer that as an undertaking, properly signed and sealed,
>though? If these unfortunate sections of code are removed, will you
>guarantee SCO won't sue?
>
>
I have convinced Darl to post a program that will state exactly this.
When we have completed our
Linux code removal he will allow anyone to do the same and he told us he
would agree not to sue
and state this to whomever would remove the code and complete this
process. Seems reasonable.
>
>Jon.
>
>
>
As far as RCU goes, there's so many three letter acronyms, RCU could
stand for anything. How
about Read Copy Update for locking primitives.
Jeff
On Sat, 2004-10-23 at 01:14 +0100, Jon Masters wrote:
> > We have identified and removed the infringing portions of Linux for our
> > products that SCO claims was stolen from Unix.
>
> > and RCU.
>
> But elsewhere you said:
>
> > I have no idea what the hell RCU is
Merkey is a troll. QED.
Please stop feeding him!
Lee
Lee Revell wrote:
>Merkey is a troll. QED.
>
>Lee
>
>
>
Not!
Jeff
On Fri, 22 Oct 2004 17:46:54 -0600, Jeff V. Merkey <[email protected]> wrote:
> Jon Masters wrote:
> > Do you model your testing process on SCO
> > directly? i.e. can I have you go on record that your testing process
> > is satisfied after two days of testing?
> No. It's still running with the following metrics, it's been up all
> week, and it doesn't crash in 20 minutes, which it always did
> before, and my BIO multiple page requests don't corrupt
> memory anymore:
Ok great, that sounds good.
What happens when you try resetting those metrics with dd if=/dev/zero
of=/dev/mem?
> >>SCO has contacted us and identifed with precise detail and factual
> >>documentation the code and intellectual property in Linux they claim was
> >>taken from Unix. We have reviewed their claims and they appear to create enough
> >>uncertianty to warrant removal of the infringing portions.
> >Will you offer that as an undertaking, properly signed and sealed,
> >though? If these unfortunate sections of code are removed, will you
> >guarantee SCO won't sue?
> I have convinced Darl to post a program that will state exactly this.
I need you to commit to this in writing, signed and sealed though. Any
chance of doing this as per previous allusion?
> As far as RCU goes, there's so many three letter acronyms, RCU could
> stand for anything.
Yes it could indeed. However in the context of the Linux kernel it
tends to usually refer to the Read Copy Update technique as an
alternative to explicit locks.
Jon.
On Fri, 2004-10-22 at 18:07 -0600, Jeff V. Merkey wrote:
> Lee Revell wrote:
>
> >Merkey is a troll. QED.
> >
> >Lee
> >
> >
> >
>
> Not!
>
In your last message you say "who wants to use this stuff except IBM
anyway", where "this stuff" includes SMP. That statement is both absurd
and inflammatory. Therefore you are a troll.
If I have to explain why you are also stupider than I thought.
Anyway, thanks for your posts - now I know how to use the kill file in
Evolution 2.0.
Lee
>I need you to commit to this in writing, signed and sealed though. Any
>chance of doing this as per previous allusion?
>
>
>
>Jon.
>
>
I forward this email to Jon Masters digital signature, secret spy,
magic, digital signing email address:
The following offer was formerly made to Jeff V. Merkey and the entire
Linux Community by Darl McBride of the SCO Group
On October 22, 2004, at around 14:00 p.m. MST. I was in a room with
Blake Stowell, Director of Public Relations, and
Darl McBride, CEO of the SCO Group, and Mr. McBride stated the following
offer. Prior to the offer I reviewed the
Evidence SCO had in their possession to present regarding their claims
that IBM Corporation took their intellectual
property and in violation of contracts used it for linux development.
Their agreements and source code appear to chart
and track a detailed evolution of Unix technologies into Linux. Their
presentation is extremely thorough, valid,
and credible from a technical viewpoint. I make formal affidavit under
penalty of perjury as to the statements made.
Darl McBride said:
" .... The SCO has identified Intellectual Property in the Linux Kernel
that we believe infringes on our intellectual property
rights. We believe the Linux code which comprises source files of the
following subsystems listed in the foregoing
document (which I, Jeff V. Merkey have posted at
ftp://ftp.kernel.org/pub/linux/kernel/people/sco_stuff, and which
document was taped to Blake Stowell's wall directly above his telephone
-- I will put the document up when I can get
to a scanner this weekend -- try Saturday afternoon). We have a detailed
listing of the files
in Linux and the specific line numbers in these files which comprise
source code and intellectual property that infringes
our intellectual property rights based on contracts we hold with IBM and
others. We can provide this listing to any
interested parties who wish for us to identify the infringing code so
that they may remove this code from Linux for
commerical use. We are not trying to stop people from using Linux,
however, we would request that our intellectual
property be removed from the Linux kernel and we will offer
certification to any Linux user, developer, maintainer,
contributor, that their code and the Linux code is free from claim from
SCO. Any Linux kernel which does not use
the attached subsystems or distribute the code is considered
non-infringing. Any code written by any IBM employee
may potentially contain SCO's intellectual property and should be
removed, including device drivers. SCO will certify
the use of and hosting of any Linux system or source code and release
all claims if the following subsystems are removed
from the distribution:
RCU
46 files
109,688 lines
NUMA
101 files
56,587 lines
JFS
44 files
32,224
XFS
173 files
119,130 lines
SMP
1,185 files
829,393 lines
Total
1,549 files
1,147,022 lines
Darl McBride then instructed Mr. Blake Stowell, Director of public
relation to give me his personal card and further stated
that this offer was made to Jeff V. Merkey, the Linux Community, and any
companies I was affiliated with if the terms
of this offer were complied with. Blake Stowell's contact information:
[email protected]
355 South 520 West Suite 100
Lindon, Utah 84042
801-932-5703 phone
801-852-9088 fax
801-369-5595 cell
Sworn before The Linux Commnity as the Truth under penalty of perjuy
October 22, 2004 10:41 p.m. MST
Jeffrey Vernon Merkey
Ingo Molnar wrote:
>first i was slighly puzzled and suspected that your mail server somehow
>delayed your outgoing email for ~1.5 years then i found what i believe
>is the secret message hidden in your email:
>
>* Jeff V. Merkey <[email protected]> wrote:
>
>
>
>>[...] The memory sickness [...]
>>[...] I was experiencing [...]
>>[...] is constant [...]
>>
>>
>
>please confirm decoding was correct! Meanwhile our secret message back
>to agent 000 is:
>
> IN THAT CONDITION MUST NOT POST TO LKML UNDER ANY CIRCUMSTANCE!
>
>[this message has been caps-encrypted. COMPARTMENTED 12B3. EYES ONLY.]
>
> Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Ingo,
Bite me.
:-)
Jeff
Erik Andersen wrote:
>On Tue Oct 19, 2004 at 02:27:30PM -0600, Jeff V. Merkey wrote:
>
>
>>Pekka Pietikainen wrote:
>>
>>
>>>arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two
>>>beers (I believe nobody else has touched it so it should be all mine).
>>>
>>>The other files of the port to that very fine architecture are largely done
>>>by other people, so unfortunately I can't relicense those.
>>>
>>>
>>>
>>>
>>>
>>Hurray! Got one. You're added to the list.
>>
>>
>
>Do remember to replace the included inlines with your own code.
>
> -Erik
>
>--
>Erik B. Andersen http://codepoet-consulting.com/
>--This message was written using 73% post-consumer electrons--
>
>
>
Erik,
Ok. Byran says hi.
Jeff
Jeff V. Merkey wrote:
> Sworn before The Linux Commnity as the Truth under penalty of perjuy
> October 22, 2004 10:41 p.m. MST
>
> Jeffrey Vernon Merkey
>
Jeff mate, I think you've missed the SCO boat by about 12 months!
Nick
PS. I love all the stories about your peyote trips. Can you start
another mailing list and post them all there instead of here so I
don't miss any installments, please? :)
On Saturday 23 October 2004 00:42, Jeff V. Merkey wrote:
>>I need you to commit to this in writing, signed and sealed though.
>> Any chance of doing this as per previous allusion?
>>
>>
>>
>>Jon.
>
>I forward this email to Jon Masters digital signature, secret spy,
>magic, digital signing email address:
>
>The following offer was formerly made to Jeff V. Merkey and the
> entire Linux Community by Darl McBride of the SCO Group
>On October 22, 2004, at around 14:00 p.m. MST. I was in a room with
>Blake Stowell, Director of Public Relations, and
>Darl McBride, CEO of the SCO Group, and Mr. McBride stated the
> following offer. Prior to the offer I reviewed the
>Evidence SCO had in their possession to present regarding their
> claims that IBM Corporation took their intellectual
>property and in violation of contracts used it for linux
> development. Their agreements and source code appear to chart
>and track a detailed evolution of Unix technologies into Linux.
> Their presentation is extremely thorough, valid,
>and credible from a technical viewpoint. I make formal affidavit
> under penalty of perjury as to the statements made.
>Darl McBride said:
>
>" .... The SCO has identified Intellectual Property in the Linux
> Kernel that we believe infringes on our intellectual property
>rights. We believe the Linux code which comprises source files of
> the following subsystems listed in the foregoing
>document (which I, Jeff V. Merkey have posted at
>ftp://ftp.kernel.org/pub/linux/kernel/people/sco_stuff, and which
>document was taped to Blake Stowell's wall directly above his
> telephone -- I will put the document up when I can get
>to a scanner this weekend -- try Saturday afternoon). We have a
> detailed listing of the files
>in Linux and the specific line numbers in these files which comprise
>source code and intellectual property that infringes
>our intellectual property rights based on contracts we hold with IBM
> and others. We can provide this listing to any
>interested parties who wish for us to identify the infringing code
> so that they may remove this code from Linux for
>commerical use. We are not trying to stop people from using Linux,
>however, we would request that our intellectual
>property be removed from the Linux kernel and we will offer
>certification to any Linux user, developer, maintainer,
>contributor, that their code and the Linux code is free from claim
> from SCO. Any Linux kernel which does not use
>the attached subsystems or distribute the code is considered
>non-infringing. Any code written by any IBM employee
>may potentially contain SCO's intellectual property and should be
>removed, including device drivers. SCO will certify
>the use of and hosting of any Linux system or source code and
> release all claims if the following subsystems are removed
>from the distribution:
>
>RCU
>46 files
>109,688 lines
>
>NUMA
>101 files
>56,587 lines
>
>JFS
>44 files
>32,224
>
>XFS
>173 files
>119,130 lines
>
>SMP
>1,185 files
>829,393 lines
>
>Total
>1,549 files
>1,147,022 lines
>
>
>Darl McBride then instructed Mr. Blake Stowell, Director of public
>relation to give me his personal card and further stated
>that this offer was made to Jeff V. Merkey, the Linux Community, and
> any companies I was affiliated with if the terms
>of this offer were complied with. Blake Stowell's contact
> information:
>
>[email protected]
>355 South 520 West Suite 100
>Lindon, Utah 84042
>801-932-5703 phone
>801-852-9088 fax
>801-369-5595 cell
>
>
>Sworn before The Linux Commnity as the Truth under penalty of perjuy
>October 22, 2004 10:41 p.m. MST
>
>Jeffrey Vernon Merkey
And its all nothing but an artistic arrangement in the glowng of the
phosphers of my screen, painted there by the electrons from the
cathode in MY crt. I don't see a notary seal, or the handwritten
signature of all parties including the notary public. So why waste
everyones time with this charade?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
[ again Cc: trimmed ]
On Fri, 2004-10-22 at 21:37, Jeff V. Merkey wrote:
> Jeff V. Merkey wrote:
>
> SCO Just sent over a list of contaminated files with a "bill of health"
So please put all that stuff (which surely includes verifiable proofs of
the claims) on some web page so that everyone can check on his own if
the claims are not as completely false as all the previous ones.
[...]
> If you guys want the specific line numbers and filenames, I will ask
> them to post the specific filenames/line numbers they claim
Especially the reasoning behind the claim is interesting - without such
reasoning there is absolutely no reason to believe a word.
> are theirs. They stated we can ship Linux with fear of being sued if we
> comply with their Linux Certification Program.
So why do you want to do it in the first place?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Geert Uytterhoeven wrote:
>On Wed, 20 Oct 2004, Pekka Pietikainen wrote:
>
>
>>On Tue, Oct 19, 2004 at 11:38:03AM -0600, Jeff V. Merkey wrote:
>>
>>
>>>On a side note, the GPL buyout previously offered has been modified. We
>>>will be contacting individual contributors and negotiating with each
>>>copyright holder for the code we wish to convert on a case by case basis.
>>>
>>>
>>arch/m68k/sun3/leds.c is available (dual BSD/GPL) for the price of two beers
>>(I believe nobody else has touched it so it should be all mine).
>>
>>The other files of the port to that very fine architecture are largely done
>>by other people, so unfortunately I can't relicense those.
>>
>>
>
>Aarghl, a shameless m68k hacker!
>
>And I thought we all did it for The Big Fun(tm), and cannot be bought ;-)
>
>
With leds.c, that's 13 lines down and only 5982412 more to go at my
count. At a rate of one per day it'll only take him 1260 years to
finish his acquisition (dependent on 63 more US copyright extension acts
of course). It'll also take 920 thousand beers, though Germans might
demand a better rate than 54ml per line of code (2 * 12 US fluid oz / 13
lines).
In all seriousness, this is all pretty obvious given SCO's past actions
to inflate their stock. Jeff wants us to remove the code in a "good
faith effort", and then SCO would simply turn around and say "See, the
Linux people are acting guilty by removing all that code! We need past
damages now!". Anything you do, or do not do, is spun by them as an
admission. Even the press has tired of this by now, thankfully. Jeff
it seems, has not.
Now if only we could get him to leave us alone for 1260 years...
- Jim
Jeff,
can you plkease stop Cc'ing me on this thread?
No, nobody I know (certainly not me) is willing to re-license Linux under
anything else than the GPL. Quite frankly, I suspect you'll have an easier
time just rewriting the whole thing.
And no, the only offer from SCO I'm interested in is a public apology from
Darl McSwine. Their made-up stories about copyright ownership weren't
really that amusing a year ago, and now they're boring and stale.
So please just remove me from the cc, ok?
Linus
[ Removed Linus from the Cc list. ]
On Fri, 22 Oct 2004 22:42:30 -0600, Jeff V. Merkey <[email protected]> wrote:
>
[ snipped insult ]
> Sworn before The Linux Commnity as the Truth under penalty of perjuy
> October 22, 2004 10:41 p.m. MST
>
> Jeffrey Vernon Merkey
Pathetic. Really.
On Sat, 23 Oct 2004, Linus Torvalds wrote:
>
>
> Jeff,
> can you plkease stop Cc'ing me on this thread?
>
> No, nobody I know (certainly not me) is willing to re-license Linux under
> anything else than the GPL. Quite frankly, I suspect you'll have an easier
> time just rewriting the whole thing.
>
> And no, the only offer from SCO I'm interested in is a public apology from
> Darl McSwine. Their made-up stories about copyright ownership weren't
> really that amusing a year ago, and now they're boring and stale.
>
> So please just remove me from the cc, ok?
>
> Linus
Thank you so much Linus, that was a much needed reply.
---
Jesper Juhl
PS. All code I have ever contributed to the Linux kernel is available
under the GPL *only*.
Linus Torvalds wrote:
>Jeff,
> can you plkease stop Cc'ing me on this thread?
>
>
>
Linus,
I never Cc'd you on this thread. The person who added you somewhere way
back there was
someone else. Talk to them. Beyond this response, I won't cc you
ever again.
>No, nobody I know (certainly not me) is willing to re-license Linux under
>anything else than the GPL. Quite frankly, I suspect you'll have an easier
>time just rewriting the whole thing.
>
>
I won't be "re-writing" anything. I've written something different that
takes all the Linux device drivers,
application layer, and a handful of file systems, and drops out most of
the core of Linux, and these
drivers I suspect will get rewritten over time. Since it's all open
source anyway, doesn't really matter.
>And no, the only offer from SCO I'm interested in is a public apology from
>Darl McSwine. Their made-up stories about copyright ownership weren't
>really that amusing a year ago, and now they're boring and stale.
>
>
>
Linus, you took code from these companies without bothering to check if
there were any agreements
that made certain they weren't contaminating Linux. You have an
obligation under US Law if you
are doing business in this country to perform due diligence and this
stuff. Then rather than be reasonable
and honorable about it, and say something like, " I have not verified
that associated intellectual property
with this submission nor have I received a release of claims from the
contributor. I have been informed
that several companies have conflicting claims regarding ownership and I
have removed the code from
the Linux Kernel and asked these vendors to maintain it as separate
patches until these claims are resolved.",
you keep right on sending it out, hosting it on your servers, all the
while Linux Community members
make statements that even if the code was someone else's "it's ours now
because it was GPL'd".
This flies in the face of every precept of contract law and intellectual
property law in the United States.
The facts are that there is some code which is the subject of a dispute
and you are distributing it, willfully,
knowingly, and with malicious intent to keep it for yourself. Whether
it's has their copyrights, or even
their trade secrets doesn't bother you one bit. I felt like Novell
should apologize to me after what
happened with them, but in all the crap with Novell, I never took their
source code, and now that
GrokSmear has posted the ruling everyone knows this as well. And guess
what, I was in the wrong.
I was doing exactly what you are doing. Using lawyers and sophistry to
conceal taking their
trade secrets and using them for myself, and I paid dearly for it. You
will too, and so will a
lot of other people who depend on you.
I don't think SCO has to apologize to you if you are not even willing to
take a mature, adult, responsible
position regarding intellectual property, and even try to work with
these people. You owe them an apology
for running an IP laundry mat, cleverly disguised as a "freedom for all"
open source effort.
This is not good leadership or responsible stewardship of the IP of
others. No one can trust you
if this is how you are going to operate, or trust that your effort is
free from contamination from
others.
>So please just remove me
>
You code has been removed.
from the cc, ok?
ok
Jeff
On Fri, 22 Oct 2004, Jeff V. Merkey wrote:
> This was written by Novell's stooge Judge Schoefield. It's total
> fiction. Don't worry, it will get cleared up soon.
I wonder if the court accepts outside evidence for disrespecting the
court. That by itself is punishable in most legislations.
--
Matthias Andree
On Sat, 23 Oct 2004 23:11:25 -0600, Jeff V. Merkey <[email protected]> wrote:
> I won't be "re-writing" anything. I've written something different that
> takes all the Linux device drivers, application layer, and a handful
> of file systems, and drops out most of the core of Linux, and these
> drivers I suspect will get rewritten over time.
Are you shipping or providing this to customers?
> Since it's all open source anyway, doesn't really matter.
You must, of course, be aware of your GPL obligations if you were to
be shipping such a system to the world? I would hate to hear that you
were violating the GPL yourself Jeff.
In fact, let's go one stage further with this - Jeff Merkey, *prove*
you're not in violation.
Jon.
<removing Linus from CC>
Jeff V. Merkey wrote:
<snip rambling nonsense>
> GrokSmear has posted the ruling everyone knows this as well. And guess
>
<snip more rambling nonsense>
If you wish to be taken seriously, perhaps you might not want to use insults when
you are obviously trying to act as SCO's representative.
How much are they paying you?
God knows, I wouldn't be a self-righteous, obnoxious prick at another's behalf
unless I was paid for it. Lawyers are much better at both being a prick and
documenting their case - and SCO has more than enough (lawyers, that is) to go around.
But, I can be rude and insulting, since I am not trying to be taken seriously.
Jim
* Jeff V. Merkey <[email protected]> wrote:
> I don't think SCO has to apologize to you [...]
Jeff, you seem to have proven once more that you live in a fantasy world
that has its own private rules of physics, ethics and rule of law.
While this appears to be a dangerous phenomenon, it is fortunately a
relatively rare one.
Linus has been intentionally, deliberately and maliciously lied to,
smeared and mislead for more than 1.5 years. Linus has not mislead
anyone, let alone lied to anyone. The so-called 'contamination'
accusations that you repeated are just that: unfounded accusations. A
simple question: do you know the concept of "truth"? Another simple
question: do you even care about it? In the world i live SCO owes Linus
more than just a simple apology. I personally find it admirable that the
only thing Linus expects of SCO is a simple apology.
(it is your free choice to join SCO's ranks but it is really not Linus'
fault that whenever it comes to Novell you apparently tick out and start
behaving seemingly irrationally. You should not fault him for happening
to be in the line of fire of your apparent personal vendetta against
Novell.)
(it is also your free choice to rewrite any part of Linux as long as you
respect the license. You are not the first one and you will not be the
last one trying. Good luck with it.)
Ingo
[ Cc: trimmed again ]
On Sun, 2004-10-24 at 07:11, Jeff V. Merkey wrote:
> Linus Torvalds wrote:
> >Jeff,
> > can you plkease stop Cc'ing me on this thread?
>
> Linus,
[...]
> >No, nobody I know (certainly not me) is willing to re-license Linux under
> >anything else than the GPL. Quite frankly, I suspect you'll have an easier
> >time just rewriting the whole thing.
> >
> I won't be "re-writing" anything. I've written something different that
> takes all the Linux device drivers,
> application layer, and a handful of file systems, and drops out most of
> the core of Linux, and these
> drivers I suspect will get rewritten over time. Since it's all open
> source anyway, doesn't really matter.
Yup. And whatever you create will be GPLed completely anyway.
> >And no, the only offer from SCO I'm interested in is a public apology from
> >Darl McSwine. Their made-up stories about copyright ownership weren't
> >really that amusing a year ago, and now they're boring and stale.
> >
> Linus, you took code from these companies without bothering to check if
Which is the prime question and has not yet been proved (not even in the
juristical meaning, let alone in the technical/mathematical) - neither
by you nor by SCO or anyone else. Even worse SCO is telling exactly that
since months (without providing detailed or even any reasonable
explanations that hold why one should believe in these words) and all
supporting (so-called) "facts" from SCO vanished and did not proove
anything.
BTW this lead to a verdict in Germany that disallows all of these claims
by SCO.
[ all of the propaganda removed ]
Bernd, not believing your and/or SCOs empty claims
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
[email protected] (Jeff V. Merkey) wrote on 22.10.04 in <[email protected]>:
> David Weinehall wrote:
> >(Quoting from groklaw wrt that lawsuit:)
> >
> >"The judge had a few descriptive words for Mr. Merkey, as you will note
> > particularly in paragraph 123 - 125 of the Findings of Fact:
> >
> > 124. In fact, however, Merkey is not just prone to exaggeration, he also
> > is and can be deceptive, not only to his adversaries, but also to his
> > own partners, his business associates and to the court. He deliberately
> > describes his own, separate reality."
> >
> >[snip]
> This was written by Novell's stooge Judge Schoefield. It's total
> fiction. Don't worry, it will get cleared up soon.
Ah, yes, like you claimed that commission was looking at the video of the
case when it actually wasn't ...
You seem to be pretty much the personified definition of a reality
distortion field.
Makes me wonder if you *ever*, in your whole life, told the unvarnished
truth even once.
MfG Kai
[email protected] (Jeff V. Merkey) wrote on 22.10.04 in <[email protected]>:
> are theirs. They stated we can ship Linux with fear of being sued if we
> comply with their Linux Certification Program.
Judhing from past performance, there is only one thing that makes it
certain SCO won't sue you.
That is, not to be a customer of SCO.
*Everyone* they sued to date was a customer.
MfG Kai
Kai Henningsen wrote:
> [email protected] (Jeff V. Merkey) wrote on 22.10.04 in <[email protected]>:
>
>
>>David Weinehall wrote:
>
>
>>>(Quoting from groklaw wrt that lawsuit:)
>>>
>>>"The judge had a few descriptive words for Mr. Merkey, as you will note
>>>particularly in paragraph 123 - 125 of the Findings of Fact:
>>>
>>>124. In fact, however, Merkey is not just prone to exaggeration, he also
>>>is and can be deceptive, not only to his adversaries, but also to his
>>>own partners, his business associates and to the court. He deliberately
>>>describes his own, separate reality."
>>>
>>>[snip]
>
>
>>This was written by Novell's stooge Judge Schoefield. It's total
>>fiction. Don't worry, it will get cleared up soon.
>
>
> Ah, yes, like you claimed that commission was looking at the video of the
> case when it actually wasn't ...
>
> You seem to be pretty much the personified definition of a reality
> distortion field.
>
> Makes me wonder if you *ever*, in your whole life, told the unvarnished
> truth even once.
I think in one of the depositions he said "I don't understand."
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Linus, please check this out.
This 'C' compiler destroys parameters passed to functions
even though the code does not alter that parameter.
gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The 'C' compiler is provided in a recent Fedora distribution.
For instance:
asmlinkage void __up(struct semaphore *sem)
{
wake_up(&sem->wait);
}
This was from /usr/src/linux-2.6.9/arch/i386/kernel/semaphore.c
It this case, the value of 'sem' is destroyed which means that
certain assembly-language helper functions no longer work.
This was discovered by Aleksey Gorelov <[email protected]>.
This patch fixes it, but I think somebody may need to rework
the semaphore code to eliminate the assembly because the newer
compilers are not consistent in their handling of passed parameters
so some assembly optimization may no longer be possible.
--- linux-2.6.9/arch/i386/kernel/semaphore.c.orig 2004-08-14 01:36:56.000000000 -0400
+++ linux-2.6.9/arch/i386/kernel/semaphore.c 2004-10-19 08:06:15.000000000 -0400
@@ -198,9 +198,11 @@
#endif
"pushl %eax\n\t"
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Register to save
+ "pushl %ecx\n\t" // Passed parameter
"call __down\n\t"
- "popl %ecx\n\t"
+ "addl $0x04, %esp\t\n" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore original
"popl %edx\n\t"
"popl %eax\n\t"
#if defined(CONFIG_FRAME_POINTER)
@@ -220,9 +222,11 @@
"movl %esp,%ebp\n\t"
#endif
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Save register
+ "pushl %ecx\n\t" // Passed parameter
"call __down_interruptible\n\t"
- "popl %ecx\n\t"
+ "addl $0x04, %esp\n\t" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore register
"popl %edx\n\t"
#if defined(CONFIG_FRAME_POINTER)
"movl %ebp,%esp\n\t"
@@ -241,9 +245,11 @@
"movl %esp,%ebp\n\t"
#endif
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Save register
+ "pushl %ecx\n\t" // Passed parameter
"call __down_trylock\n\t"
- "popl %ecx\n\t"
+ "addl $0x04, %esp\n\t" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore register
"popl %edx\n\t"
#if defined(CONFIG_FRAME_POINTER)
"movl %ebp,%esp\n\t"
@@ -259,9 +265,11 @@
"__up_wakeup:\n\t"
"pushl %eax\n\t"
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Save register
+ "pushl %ecx\n\t" // Passed parameter
"call __up\n\t"
- "popl %ecx\n\t"
+ "addl $0x04, %esp\n\t" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore register
"popl %edx\n\t"
"popl %eax\n\t"
"ret"
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Fri, 29 Oct 2004, linux-os wrote:
>
> Linus, please check this out.
Yes, I concur. However, I'd suggest changing the "addl $4,%esp" into a
"popl %ecx", which is smaller and apparently faster on some CPU's (ecx
obviously gets immediately overwritten by the next popl).
Btw, this is another case where we _really_ want "asmlinkage" to mean that
the compiler does not own the argument stack. Is there any chance of
getting a function attribute like that into future versions of gcc?
Richard, Jan, Andi? Or does it already exist somewhere?
Linus
--- saved for gcc people commentary ---
>
> asmlinkage void __up(struct semaphore *sem)
> {
> wake_up(&sem->wait);
> }
>
> This was from /usr/src/linux-2.6.9/arch/i386/kernel/semaphore.c
> It this case, the value of 'sem' is destroyed which means that
> certain assembly-language helper functions no longer work.
>
> This was discovered by Aleksey Gorelov <[email protected]>.
>
> This patch fixes it, but I think somebody may need to rework
> the semaphore code to eliminate the assembly because the newer
> compilers are not consistent in their handling of passed parameters
> so some assembly optimization may no longer be possible.
>
>
> --- linux-2.6.9/arch/i386/kernel/semaphore.c.orig 2004-08-14 01:36:56.000000000 -0400
> +++ linux-2.6.9/arch/i386/kernel/semaphore.c 2004-10-19 08:06:15.000000000 -0400
> @@ -198,9 +198,11 @@
> #endif
> "pushl %eax\n\t"
> "pushl %edx\n\t"
> - "pushl %ecx\n\t"
> + "pushl %ecx\n\t" // Register to save
> + "pushl %ecx\n\t" // Passed parameter
> "call __down\n\t"
> - "popl %ecx\n\t"
> + "addl $0x04, %esp\t\n" // Bypass corrupted parameter
> + "popl %ecx\n\t" // Restore original
> "popl %edx\n\t"
> "popl %eax\n\t"
> #if defined(CONFIG_FRAME_POINTER)
> @@ -220,9 +222,11 @@
> "movl %esp,%ebp\n\t"
> #endif
> "pushl %edx\n\t"
> - "pushl %ecx\n\t"
> + "pushl %ecx\n\t" // Save register
> + "pushl %ecx\n\t" // Passed parameter
> "call __down_interruptible\n\t"
> - "popl %ecx\n\t"
> + "addl $0x04, %esp\n\t" // Bypass corrupted parameter
> + "popl %ecx\n\t" // Restore register
> "popl %edx\n\t"
> #if defined(CONFIG_FRAME_POINTER)
> "movl %ebp,%esp\n\t"
> @@ -241,9 +245,11 @@
> "movl %esp,%ebp\n\t"
> #endif
> "pushl %edx\n\t"
> - "pushl %ecx\n\t"
> + "pushl %ecx\n\t" // Save register
> + "pushl %ecx\n\t" // Passed parameter
> "call __down_trylock\n\t"
> - "popl %ecx\n\t"
> + "addl $0x04, %esp\n\t" // Bypass corrupted parameter
> + "popl %ecx\n\t" // Restore register
> "popl %edx\n\t"
> #if defined(CONFIG_FRAME_POINTER)
> "movl %ebp,%esp\n\t"
> @@ -259,9 +265,11 @@
> "__up_wakeup:\n\t"
> "pushl %eax\n\t"
> "pushl %edx\n\t"
> - "pushl %ecx\n\t"
> + "pushl %ecx\n\t" // Save register
> + "pushl %ecx\n\t" // Passed parameter
> "call __up\n\t"
> - "popl %ecx\n\t"
> + "addl $0x04, %esp\n\t" // Bypass corrupted parameter
> + "popl %ecx\n\t" // Restore register
> "popl %edx\n\t"
> "popl %eax\n\t"
> "ret"
>
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
> Notice : All mail here is now cached for review by John Ashcroft.
> 98.36% of all statistics are fiction.
>
> Btw, this is another case where we _really_ want "asmlinkage" to mean that
> the compiler does not own the argument stack. Is there any chance of
> getting a function attribute like that into future versions of gcc?
> Richard, Jan, Andi? Or does it already exist somewhere?
How about just using __attribute__((regparm(1))) ? Then the
problem doesn't appear.
Would be faster too. It should work reliable on all supported compilers.
-Andi
Linus Torvalds wrote:
>
> On Fri, 29 Oct 2004, linux-os wrote:
>
>>Linus, please check this out.
>
>
> Yes, I concur. However, I'd suggest changing the "addl $4,%esp" into a
> "popl %ecx", which is smaller and apparently faster on some CPU's (ecx
> obviously gets immediately overwritten by the next popl).
Hmm, I didn't check the instruction length but modern CPUs usually work
best with the following:
leal 4(%esp),%esp
--
Andreas Steinmetz SPAMmers use [email protected]
On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
> Linus Torvalds wrote:
>>
>> On Fri, 29 Oct 2004, linux-os wrote:
>>
>>> Linus, please check this out.
>>
>>
>> Yes, I concur. However, I'd suggest changing the "addl $4,%esp" into a
>> "popl %ecx", which is smaller and apparently faster on some CPU's (ecx
>> obviously gets immediately overwritten by the next popl).
>
> Hmm, I didn't check the instruction length but modern CPUs usually work best
> with the following:
>
> leal 4(%esp),%esp
>
> --
> Andreas Steinmetz SPAMmers use [email protected]
>
Probably so because I'm pretty certain that the 'pop' (a memory
access) is not going to be faster than a simple register operation.
I'll make another patch and post it (if the machine will boot!)
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Fri, 29 Oct 2004, Linus Torvalds wrote:
>
>
> On Fri, 29 Oct 2004, linux-os wrote:
>>
>> Linus, please check this out.
>
> Yes, I concur. However, I'd suggest changing the "addl $4,%esp" into a
> "popl %ecx", which is smaller and apparently faster on some CPU's (ecx
> obviously gets immediately overwritten by the next popl).
>
> Btw, this is another case where we _really_ want "asmlinkage" to mean that
> the compiler does not own the argument stack. Is there any chance of
> getting a function attribute like that into future versions of gcc?
> Richard, Jan, Andi? Or does it already exist somewhere?
>
> Linus
>
Here's a version that uses `leal 4(esp), esp` to add
4 to the stack-pointer. Since this 'address-calculation`
is done in an different portion of Intel CPUs, there
is some parallel operation that can occur. The 'pop ecx'
would access memory and, therefore be slower than
simple register operations.
FYI I'm running a kernel with this patch already.
--- linux-2.6.9/arch/i386/kernel/semaphore.c.orig 2004-10-29 13:00:17.961579368 -0400
+++ linux-2.6.9/arch/i386/kernel/semaphore.c 2004-10-29 13:03:35.046617888 -0400
@@ -198,9 +198,11 @@
#endif
"pushl %eax\n\t"
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Register to save
+ "pushl %ecx\n\t" // Passed parameter
"call __down\n\t"
- "popl %ecx\n\t"
+ "leal 0x04(%esp), %esp\t\n" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore original
"popl %edx\n\t"
"popl %eax\n\t"
#if defined(CONFIG_FRAME_POINTER)
@@ -220,9 +222,11 @@
"movl %esp,%ebp\n\t"
#endif
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Save register
+ "pushl %ecx\n\t" // Passed parameter
"call __down_interruptible\n\t"
- "popl %ecx\n\t"
+ "leal 0x04(%esp), %esp\n\t" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore register
"popl %edx\n\t"
#if defined(CONFIG_FRAME_POINTER)
"movl %ebp,%esp\n\t"
@@ -241,9 +245,11 @@
"movl %esp,%ebp\n\t"
#endif
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Save register
+ "pushl %ecx\n\t" // Passed parameter
"call __down_trylock\n\t"
- "popl %ecx\n\t"
+ "leal 0x04(%esp), %esp\n\t" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore register
"popl %edx\n\t"
#if defined(CONFIG_FRAME_POINTER)
"movl %ebp,%esp\n\t"
@@ -259,9 +265,11 @@
"__up_wakeup:\n\t"
"pushl %eax\n\t"
"pushl %edx\n\t"
- "pushl %ecx\n\t"
+ "pushl %ecx\n\t" // Save register
+ "pushl %ecx\n\t" // Passed parameter
"call __up\n\t"
- "popl %ecx\n\t"
+ "leal 0x04(%esp), %esp\n\t" // Bypass corrupted parameter
+ "popl %ecx\n\t" // Restore register
"popl %edx\n\t"
"popl %eax\n\t"
"ret"
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Fri, Oct 29, 2004 at 07:46:06AM -0700, Linus Torvalds wrote:
> Btw, this is another case where we _really_ want "asmlinkage" to mean that
> the compiler does not own the argument stack. Is there any chance of
> getting a function attribute like that into future versions of gcc?
Certainly we'd accept the feature, it's just a matter of
doing the work.
r~
On Fri, Oct 29, 2004 at 01:22:52PM -0400, linux-os wrote:
> Here's a version that uses `leal 4(esp), esp` to add
> 4 to the stack-pointer. Since this 'address-calculation`
> is done in an different portion of Intel CPUs....
Incorrect, at least i686 and beyond. These interpret to the
same micro-ops.
> The 'pop ecx' would access memory and, therefore be slower than
> simple register operations.
Also not necessarily correct. Intel cpus special-case pop
instructions; two pops can be dual issued, whereas a different
kind of stack pointer manipulation will not.
r~
On Fri, 29 Oct 2004, linux-os wrote:
> > with the following:
> >
> > leal 4(%esp),%esp
>
> Probably so because I'm pretty certain that the 'pop' (a memory
> access) is not going to be faster than a simple register operation.
Bzzt, wrong answer.
It's not "simple register operation". It's really about the fact that
modern CPU's are smarter - yet dumber - then you think. They do things
like speculate the value of %esp in order to avoid having to calculate it,
and it's entirely possible that "pop" is much faster, simply because I
guarantee you that a CPU will speculate %esp correctly across a "pop", but
the same is not necessarily true for "lea %esp".
Somebody should check what the Pentium M does. It might just notice that
"lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
possible that lea will confuse its stack engine logic and cause
stack-related address generation stalls..
Linus
On Fri, 29 Oct 2004, Andi Kleen wrote:
>
> > Richard, Jan, Andi? Or does it already exist somewhere?
>
> How about just using __attribute__((regparm(1))) ? Then the
> problem doesn't appear.
Yes, we could use regparm for all assembly. Right now "asmlinkage"
actually _disables_ regparm so that we always have the same calling
convention for assembly regardless of whether the rest of the kernel is
compiled with regparm or not, but we could certainly change that
#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
to use "regparm(3)" instead. I guess it's stable these days, since we use
it for FASTCALL() and friends too.
> Would be faster too. It should work reliable on all supported compilers.
What's happens if there are more arguments than three? It happens for
several system calls - does gcc still consider the stack part of the thing
to be owned by the callee?
Linus
On Fri, 29 Oct 2004, Richard Henderson wrote:
> On Fri, Oct 29, 2004 at 01:22:52PM -0400, linux-os wrote:
>> Here's a version that uses `leal 4(esp), esp` to add
>> 4 to the stack-pointer. Since this 'address-calculation`
>> is done in an different portion of Intel CPUs....
>
> Incorrect, at least i686 and beyond. These interpret to the
> same micro-ops.
>
>> The 'pop ecx' would access memory and, therefore be slower than
>> simple register operations.
>
> Also not necessarily correct. Intel cpus special-case pop
> instructions; two pops can be dual issued, whereas a different
> kind of stack pointer manipulation will not.
>
Then I guess the Intel documentation is incorrect, too.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Fri, Oct 29, 2004 at 11:18:33AM -0700, Linus Torvalds wrote:
> What's happens if there are more arguments than three? It happens for
> several system calls - does gcc still consider the stack part of the thing
> to be owned by the callee?
Yes.
r~
Linus Torvalds wrote:
> Somebody should check what the Pentium M does. It might just notice that
> "lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
> possible that lea will confuse its stack engine logic and cause
> stack-related address generation stalls..
Now especially Intel tells everybody in their Pentium Optimization
manuals to *use* lea whereever possible as this operation doesn't depend
on the ALU and is processed in other parts of the CPU.
Sample quote from said manual (P/N 248966-05):
"Use the lea instruction and the full range of addressing modes to do
address calculation"
I would guess Intel would add caveats about such stalls in this manual
if there would be any.
--
Andreas Steinmetz SPAMmers use [email protected]
Here's a totally untested patch to make the semaphores use "fastcall"
instead of "asmlinkage", and thus pass the argument in %eax instead of on
the stack. Does it work? I have no idea. If it does, it should fix the
particular bug that started this thread..
Linus
---
===== arch/i386/kernel/semaphore.c 1.10 vs edited =====
--- 1.10/arch/i386/kernel/semaphore.c 2004-04-12 10:53:59 -07:00
+++ edited/arch/i386/kernel/semaphore.c 2004-10-29 12:19:22 -07:00
@@ -49,12 +49,12 @@
* we cannot lose wakeup events.
*/
-asmlinkage void __up(struct semaphore *sem)
+fastcall void __up(struct semaphore *sem)
{
wake_up(&sem->wait);
}
-asmlinkage void __sched __down(struct semaphore * sem)
+fastcall void __sched __down(struct semaphore * sem)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
@@ -91,7 +91,7 @@
tsk->state = TASK_RUNNING;
}
-asmlinkage int __sched __down_interruptible(struct semaphore * sem)
+fastcall int __sched __down_interruptible(struct semaphore * sem)
{
int retval = 0;
struct task_struct *tsk = current;
@@ -154,7 +154,7 @@
* single "cmpxchg" without failure cases,
* but then it wouldn't work on a 386.
*/
-asmlinkage int __down_trylock(struct semaphore * sem)
+fastcall int __down_trylock(struct semaphore * sem)
{
int sleepers;
unsigned long flags;
@@ -183,9 +183,9 @@
* need to convert that sequence back into the C sequence when
* there is contention on the semaphore.
*
- * %ecx contains the semaphore pointer on entry. Save the C-clobbered
- * registers (%eax, %edx and %ecx) except %eax when used as a return
- * value..
+ * %eax contains the semaphore pointer on entry. Save the C-clobbered
+ * registers (%eax, %edx and %ecx) except %eax whish is either a return
+ * value or just clobbered..
*/
asm(
".section .sched.text\n"
@@ -196,13 +196,11 @@
"pushl %ebp\n\t"
"movl %esp,%ebp\n\t"
#endif
- "pushl %eax\n\t"
"pushl %edx\n\t"
"pushl %ecx\n\t"
"call __down\n\t"
"popl %ecx\n\t"
"popl %edx\n\t"
- "popl %eax\n\t"
#if defined(CONFIG_FRAME_POINTER)
"movl %ebp,%esp\n\t"
"popl %ebp\n\t"
@@ -257,13 +255,11 @@
".align 4\n"
".globl __up_wakeup\n"
"__up_wakeup:\n\t"
- "pushl %eax\n\t"
"pushl %edx\n\t"
"pushl %ecx\n\t"
"call __up\n\t"
"popl %ecx\n\t"
"popl %edx\n\t"
- "popl %eax\n\t"
"ret"
);
===== include/asm-i386/linkage.h 1.4 vs edited =====
--- 1.4/include/asm-i386/linkage.h 2004-10-16 18:24:37 -07:00
+++ edited/include/asm-i386/linkage.h 2004-10-29 11:32:18 -07:00
@@ -1,7 +1,7 @@
#ifndef __ASM_LINKAGE_H
#define __ASM_LINKAGE_H
-#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
+#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(3)))
#define FASTCALL(x) x __attribute__((regparm(3)))
#define fastcall __attribute__((regparm(3)))
===== include/asm-i386/semaphore.h 1.9 vs edited =====
--- 1.9/include/asm-i386/semaphore.h 2004-08-27 00:02:38 -07:00
+++ edited/include/asm-i386/semaphore.h 2004-10-29 12:06:48 -07:00
@@ -87,15 +87,15 @@
sema_init(sem, 0);
}
-asmlinkage void __down_failed(void /* special register calling convention */);
-asmlinkage int __down_failed_interruptible(void /* params in registers */);
-asmlinkage int __down_failed_trylock(void /* params in registers */);
-asmlinkage void __up_wakeup(void /* special register calling convention */);
-
-asmlinkage void __down(struct semaphore * sem);
-asmlinkage int __down_interruptible(struct semaphore * sem);
-asmlinkage int __down_trylock(struct semaphore * sem);
-asmlinkage void __up(struct semaphore * sem);
+fastcall void __down_failed(void /* special register calling convention */);
+fastcall int __down_failed_interruptible(void /* params in registers */);
+fastcall int __down_failed_trylock(void /* params in registers */);
+fastcall void __up_wakeup(void /* special register calling convention */);
+
+fastcall void __down(struct semaphore * sem);
+fastcall int __down_interruptible(struct semaphore * sem);
+fastcall int __down_trylock(struct semaphore * sem);
+fastcall void __up(struct semaphore * sem);
/*
* This is ugly, but we want the default case to fall through.
@@ -111,12 +111,13 @@
"js 2f\n"
"1:\n"
LOCK_SECTION_START("")
- "2:\tcall __down_failed\n\t"
+ "2:\tlea %0,%%eax\n\t"
+ "call __down_failed\n\t"
"jmp 1b\n"
LOCK_SECTION_END
:"=m" (sem->count)
- :"c" (sem)
- :"memory");
+ :
+ :"memory","ax");
}
/*
@@ -135,11 +136,12 @@
"xorl %0,%0\n"
"1:\n"
LOCK_SECTION_START("")
- "2:\tcall __down_failed_interruptible\n\t"
+ "2:\tlea %1,%%eax\n\t"
+ "call __down_failed_interruptible\n\t"
"jmp 1b\n"
LOCK_SECTION_END
:"=a" (result), "=m" (sem->count)
- :"c" (sem)
+ :
:"memory");
return result;
}
@@ -159,11 +161,12 @@
"xorl %0,%0\n"
"1:\n"
LOCK_SECTION_START("")
- "2:\tcall __down_failed_trylock\n\t"
+ "2:\tlea %1,%%eax\n\t"
+ "call __down_failed_trylock\n\t"
"jmp 1b\n"
LOCK_SECTION_END
:"=a" (result), "=m" (sem->count)
- :"c" (sem)
+ :
:"memory");
return result;
}
@@ -182,13 +185,14 @@
"jle 2f\n"
"1:\n"
LOCK_SECTION_START("")
- "2:\tcall __up_wakeup\n\t"
+ "2:\tlea %0,%%eax\n\t"
+ "call __up_wakeup\n\t"
"jmp 1b\n"
LOCK_SECTION_END
".subsection 0\n"
:"=m" (sem->count)
- :"c" (sem)
- :"memory");
+ :
+ :"memory","ax");
}
#endif
===== include/linux/spinlock.h 1.32 vs edited =====
--- 1.32/include/linux/spinlock.h 2004-10-24 16:24:20 -07:00
+++ edited/include/linux/spinlock.h 2004-10-29 12:08:14 -07:00
@@ -27,7 +27,7 @@
extra \
".ifndef " LOCK_SECTION_NAME "\n\t" \
LOCK_SECTION_NAME ":\n\t" \
- ".endif\n\t"
+ ".endif\n"
#define LOCK_SECTION_END \
".previous\n\t"
On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
> Linus Torvalds wrote:
> > Somebody should check what the Pentium M does. It might just notice that
> > "lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
> > possible that lea will confuse its stack engine logic and cause
> > stack-related address generation stalls..
>
> Now especially Intel tells everybody in their Pentium Optimization
> manuals to *use* lea whereever possible as this operation doesn't depend
> on the ALU and is processed in other parts of the CPU.
>
> Sample quote from said manual (P/N 248966-05):
> "Use the lea instruction and the full range of addressing modes to do
> address calculation"
Does it say this about %esp?
The stack pointer is SPECIAL, guys. It's special exactly because there is
potentially extra hardware in CPU's that track its value _independently_
of the actual physical register.
Just for fun, google for 'x86 "stack engine"', and you'll hit for example
http://arstechnica.com/articles/paedia/cpu/pentium-m.ars/5 which talks
about this and perhaps explains it in ways that I apparently haven't been
able to.
Linus
Linus Torvalds wrote:
>
> On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
>
>
>>Linus Torvalds wrote:
>>
>>>Somebody should check what the Pentium M does. It might just notice that
>>>"lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
>>>possible that lea will confuse its stack engine logic and cause
>>>stack-related address generation stalls..
>>
>>Now especially Intel tells everybody in their Pentium Optimization
>>manuals to *use* lea whereever possible as this operation doesn't depend
>>on the ALU and is processed in other parts of the CPU.
>>
>>Sample quote from said manual (P/N 248966-05):
>>"Use the lea instruction and the full range of addressing modes to do
>>address calculation"
>
>
> Does it say this about %esp?
>
> The stack pointer is SPECIAL, guys. It's special exactly because there is
> potentially extra hardware in CPU's that track its value _independently_
> of the actual physical register.
It doesn't say anything about esp being specially treated by the
underlying hardware as far as I can see. Thus either you know details
about the cpu not being publically available or you're speculating about
undocumented features.
Some more data from said manual (lea is better on P3 and the same as add
on P4):
Instruction Latency Execution Unit
ADD/SUB: 0.5 ALU
POP 1.5 MEM_LOAD,ALU
Now, a P4 had two ALUs (Ports 0 and 1) but only one MEM_LOAD Unit (Port
2). So after all you will be stalled more likely by an additional pop
instruction than by lea/add. I don't know about P4 internals but let me
make some guess: There's lot of software around that needs to run on
older processors where lea has quite some performance advantage. Thus I
would guess that the P4 design respects this by handling lea x(esp),esp
efficiently.
If you still believe in features I can't find any manufacturer
documentation for, well, you're Linus so it's your decision.
--
Andreas Steinmetz SPAMmers use [email protected]
On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
>
> If you still believe in features I can't find any manufacturer
> documentation for, well, you're Linus so it's your decision.
It's not that I'm Linus. It's that I am apparently better informed than
you are, and the numbers you are looking at are irrelevant. For example,
have you even _looked_ at the Pentium M stack engine documentation, which
is what this whole argument is all about?
And the documentation you look at is not revelant. For example, when you
look at the latency of "pop", who _cares_? That's the latency to use the
data, and has no meaning, since in this case we don't actually ever use
it. So what matters is other things entirely, like how well the
instructions can run in parallell.
Try it.
popl %eax
popl %ecx
should one cycle on a Pentium. I pretty much _guarantee_ that
lea 4(%esp),%esp
popl %ecx
takes longer, since they have a data dependency on %esp that is hard to
break (the P4 trace-cache _may_ be able to break it, but the only CPU that
I think is likely to break it is actually the Transmeta CPU's, which did
that kind of thing by default and _will_ parallelise the two, and even
combine the stack offsetting into one single micro-op).
So my argument is that "popl" is smaller, and I doubt you can find a
machine where it's actually slower (most will take two cycles). And I am
pretty confident that I can find machines where it is faster (ie regular
Pentium).
Not that any of this matters, since there's a patch that makes all of this
moot. If it works.
Linus
On Fri, 29 Oct 2004, Linus Torvalds wrote:
>
> Here's a totally untested patch to make the semaphores use "fastcall"
> instead of "asmlinkage"
Ok, I tested it, looked through the assembly code, and did a general size
comparison. Everything looks good, and it should fix the problem that
caused this discussion. Checked in.
The patch actually improves code generation by moving the failure case
argument generation _into_ the failure case: this makes the inline asm one
instruction longer, but it means that the fastpath is often one
instruction shorter. In fact, the fastpath is usually improved even _more_
than that, because gcc does sucketh at generating code that uses fixed
registers (ie the old code often caused gcc to first generate the value
into another register, and then _move_ it into %eax, rather than just
generating it into %eax in the first place).
My test-kernel shrunk by a whopping 2kB in size from this change.
Linus
On Fri, 29 Oct 2004, Linus Torvalds wrote:
>
>
> Here's a totally untested patch to make the semaphores use "fastcall"
> instead of "asmlinkage", and thus pass the argument in %eax instead of on
> the stack. Does it work? I have no idea. If it does, it should fix the
> particular bug that started this thread..
Oh, sorry, please remove this part, it was totally unintentional (I _told_
you this wasn't tested):
> --- 1.4/include/asm-i386/linkage.h 2004-10-16 18:24:37 -07:00
> +++ edited/include/asm-i386/linkage.h 2004-10-29 11:32:18 -07:00
> @@ -1,7 +1,7 @@
> #ifndef __ASM_LINKAGE_H
> #define __ASM_LINKAGE_H
>
> -#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
> +#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(3)))
> #define FASTCALL(x) x __attribute__((regparm(3)))
> #define fastcall __attribute__((regparm(3)))
>
We're not making all asmlinkage things fastcalls here, we're only doing
the semaphores..
Linus
Linus Torvalds wrote:
>
> popl %eax
> popl %ecx
>
> should one cycle on a Pentium. I pretty much _guarantee_ that
>
> lea 4(%esp),%esp
> popl %ecx
>
> takes longer, since they have a data dependency on %esp that is hard to
> break (the P4 trace-cache _may_ be able to break it, but the only CPU that
> I think is likely to break it is actually the Transmeta CPU's, which did
> that kind of thing by default and _will_ parallelise the two, and even
> combine the stack offsetting into one single micro-op).
One of my favorite "optimizing for Pentium" docs is
http://www.agner.org/assem/pentopt.pdf
from
http://www.agner.org/assem/
which is current through newer P4's AFAICS.
It notes on the P4 specifically that LEA is split into additions and
shifts. Not sure what it does on the P3, but I bet it generates more
uops in addition to the data dependency.
Jeff
On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
> > On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
> > > Sample quote from said manual (P/N 248966-05):
> > > "Use the lea instruction and the full range of addressing modes to do
> > > address calculation"
...
> Some more data from said manual (lea is better on P3 and the same as add on
> P4):
you really need to understand intel optimisation guides. it helps to diff
them over time to see the types of things that go in and out of fashion.
> I don't know about P4 internals but let me make some guess:
> There's lot of software around that needs to run on older processors where lea
> has quite some performance advantage. Thus I would guess that the P4 design
> respects this by handling lea x(esp),esp efficiently.
your guess is generally wrong... try measuring it.
for p4 model 0 through 2 it was faster to avoid lea and shl and generate
code like:
add %ebx,%ebx
add %ebx,%ebx
add %ebx,%ebx
add %ebx,%ebx
which would complete in 2 cycles, compared to 4 cycles for lea or a shift.
but that crap doesn't apply to any other x86 (except efficeon which
notices this crud and converts it to its own optimal sequence).
p4 model 2 is probably way more common than p4 model 3 still.
you also need to be aware of k7/k8. AMD has their own optimisation guide
(i'm too lazy to find url/#). but the important point for lea and AMD is
that it is a 2 cycle latency operation, and add is 1 cycle.
but you know what? we can talk about what the optimization guides say
until we're blue... the only thing which matters is experience. go
measure it. (i've measured a bazillion things like this.)
use pop, don't use lea to modify esp.
-dean
On Fri, 29 Oct 2004, dean gaudet wrote:
>
> for p4 model 0 through 2 it was faster to avoid lea and shl and generate
> code like:
>
> add %ebx,%ebx
> add %ebx,%ebx
> add %ebx,%ebx
> add %ebx,%ebx
I think that is true only for the lea's that have a shifted input. The
weakness of the original P4 is its shifter, not lea itself. And for a
simple lea like 4(%esp), it's likely no worse than a regular "add", and
there lea has the advantage that you can put the result in another
register, which can be advantageous in other circumstances.
So lea actually _is_ useful for doing adds, in many cases. Of course, on
older CPU's you'll see the effect of the address generation adder being
one cycle "off" (earlier) the regular ALU execution unit, so lea often
causes AGI stalls. I don't think this is an issue on the P6 or P4 because
of how they actually end up implementing the lea in the regular ALU path.
How the hell did we get to worrying about this in the first place?
Linus
On Fri, 29 Oct 2004, Linus Torvalds wrote:
> On Fri, 29 Oct 2004, linux-os wrote:
> > > with the following:
> > >
> > > leal 4(%esp),%esp
> >
> > Probably so because I'm pretty certain that the 'pop' (a memory
> > access) is not going to be faster than a simple register operation.
>
> Bzzt, wrong answer.
>
> It's not "simple register operation". It's really about the fact that
> modern CPU's are smarter - yet dumber - then you think. They do things
> like speculate the value of %esp in order to avoid having to calculate it,
> and it's entirely possible that "pop" is much faster, simply because I
> guarantee you that a CPU will speculate %esp correctly across a "pop", but
> the same is not necessarily true for "lea %esp".
>
> Somebody should check what the Pentium M does. It might just notice that
> "lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
> possible that lea will confuse its stack engine logic and cause
> stack-related address generation stalls..
it's worse than that in general -- lea typically goes through the AGU
which has either less throughput or longer latency than the ALUs...
depending on which x86en. it's 4 cycles for a lea on p4, vs. 1 for a pop.
it's 2 cycles for a lea on k8 vs. 1 for a pop.
use pop.
-dean
On Fri, 29 Oct 2004, linux-os wrote:
>
> Linus, there is no way in hell that you are going to move
> a value from memory into a register (pop ecx) faster than
> you are going to do anything to the stack-pointer or
> any other register.
Sorry, but you're wrong.
Learn about modern CPU's some day, and realize that cached accesses are
fast, and pipeline stalls are relatively much more expensive.
Now, if it was uncached, you'd have a point.
Also think about why
call xxx
jmp yy
is often much faster than
push $yy
jmp xxx
and other small interesting facts about how CPU's actually work these
days.
Linus
On Fri, 29 Oct 2004, linux-os wrote:
> On Fri, 29 Oct 2004, Richard Henderson wrote:
> >
> > Also not necessarily correct. Intel cpus special-case pop
> > instructions; two pops can be dual issued, whereas a different
> > kind of stack pointer manipulation will not.
> >
>
> Then I guess the Intel documentation is incorrect, too.
Where?
It definitely depends on the CPU. Some CPU's dual-issue pops, some don't.
I think the Pentium can dual-issue, while the PPro/P4 does not. And AMD
has some other rules, and I think older ones dual-issue stack accesses
only if esp doesn't change. Haven't looked at K8 rules.
And Pentium M is to some degree more interesting than P4 and Ppro, because
it's apparently the architecture Intel is going forward with for the
future of x86, and it is a "improved PPro" core that has a special stack
engine, iirc.
Anyway, it's quite likely that for several CPU's the fastest sequence ends
up actually being
movl 4(%esp),%ecx
movl 8(%esp),%edx
movl 12(%esp),%eax
addl $16,%esp
which is also one of the biggest alternatives.
Anyway, making "asmlinkage" imply "regparm(3)" would make the whole
discussion moot, so I'm wondering if anybody has the patches to try it
out? It requires pretty big changes to all the x86 asm code, but I do know
that people _had_ patches like that at least long ago (from when people
like Jan were playing with -mregaparm=3 originally). Maybe some of them
still exist..
Linus
On Fri, Oct 29, 2004 at 07:46:06AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 29 Oct 2004, linux-os wrote:
> >
> > Linus, please check this out.
>
> Yes, I concur. However, I'd suggest changing the "addl $4,%esp" into a
> "popl %ecx", which is smaller and apparently faster on some CPU's (ecx
> obviously gets immediately overwritten by the next popl).
Rather popl %eax or popl %edx then, a basic and MMX Pentium
cannot pair:
popl %ecx
popl %ecx
for the simple reason that two instructions that have the
same destination register can't be paired.
OTOH, the other argument about reading or not memory in
this thread are a red herring. An additional memory read
is cheap for data that is guaranteed to be in a cache line
used by adjacent (in time) instructions.
Otherwise regparm(1) might even be better, movl %ecx,%eax is
the same size as push+pop, is faster, and may even reduce
stack usage by 4 bytes.
On Fri, 29 Oct 2004, Linus Torvalds wrote:
>
>
> On Fri, 29 Oct 2004, linux-os wrote:
>>> with the following:
>>>
>>> leal 4(%esp),%esp
>>
>> Probably so because I'm pretty certain that the 'pop' (a memory
>> access) is not going to be faster than a simple register operation.
>
> Bzzt, wrong answer.
>
> It's not "simple register operation". It's really about the fact that
> modern CPU's are smarter - yet dumber - then you think. They do things
> like speculate the value of %esp in order to avoid having to calculate it,
> and it's entirely possible that "pop" is much faster, simply because I
> guarantee you that a CPU will speculate %esp correctly across a "pop", but
> the same is not necessarily true for "lea %esp".
>
> Somebody should check what the Pentium M does. It might just notice that
> "lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
> possible that lea will confuse its stack engine logic and cause
> stack-related address generation stalls..
>
> Linus
Linus, there is no way in hell that you are going to move
a value from memory into a register (pop ecx) faster than
you are going to do anything to the stack-pointer or
any other register. The register operations operate
at the internal CPU clock-rate (GHz). The memory operations
operate at the front-side bus rate (MHz), and the data-
movement must actually occur before anything else can.
In other words, with stack operations, modern CPUs will
stall until the operation has completed.
Using the rdtsc, on this computer, both of the stack-pointer
additions (leal or add) take 6 +/- 2 clocks. The pop ecx
takes 12 +/- 3 clocks.
Things that should take only one clock, according to the
documentation, take 4 or 5 even when subtracting-out
the time necessary to do the rdtsc, because this machine
(and probably others) is very noisy, so all I can state
with certainty is that the pop from the stack takes longer.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Fri, 29 Oct 2004, Linus Torvalds wrote:
>
> Anyway, making "asmlinkage" imply "regparm(3)" would make the whole
> discussion moot, so I'm wondering if anybody has the patches to try it
> out? It requires pretty big changes to all the x86 asm code, but I do know
> that people _had_ patches like that at least long ago (from when people
> like Jan were playing with -mregaparm=3 originally). Maybe some of them
> still exist..
Looking at just doing this for the semaphore code, I hit on the fact that
we already do this for the rwsem's.. So changing just the regular
semaphore code to use "fastcall" should fix this particular bug, but I'm
still interested in hearing whether somebody has a patch for the system
calls and faults too?
Linus
dean gaudet <[email protected]> writes:
>
> it's worse than that in general -- lea typically goes through the AGU
> which has either less throughput or longer latency than the ALUs...
> depending on which x86en. it's 4 cycles for a lea on p4, vs. 1 for a pop.
> it's 2 cycles for a lea on k8 vs. 1 for a pop.
On D stepping and later K8 the lea is 1 cycle latency because the
decoder optimizes the lea into an add.
-Andi
Linus Torvalds <[email protected]> writes:
> Anyway, it's quite likely that for several CPU's the fastest sequence ends
> up actually being
>
> movl 4(%esp),%ecx
> movl 8(%esp),%edx
> movl 12(%esp),%eax
> addl $16,%esp
>
> which is also one of the biggest alternatives.
For K8 it should be the fastest way. K7 probably too.
-Andi
Linus Torvalds wrote:
> Anyway, it's quite likely that for several CPU's the fastest sequence ends
> up actually being
>
> movl 4(%esp),%ecx
> movl 8(%esp),%edx
> movl 12(%esp),%eax
> addl $16,%esp
>
> which is also one of the biggest alternatives.
That's how I'm coding the sparse "compiler backend"... the mov's and
add's tend to be tiny instructions (i-cache friendly), and you can often
issue a bunch of them through multiple pipes/ports.
Jeff
On Saturday 30 October 2004 05:13, Andi Kleen wrote:
> Linus Torvalds <[email protected]> writes:
>
> > Anyway, it's quite likely that for several CPU's the fastest sequence ends
> > up actually being
> >
> > movl 4(%esp),%ecx
> > movl 8(%esp),%edx
> > movl 12(%esp),%eax
> > addl $16,%esp
> >
> > which is also one of the biggest alternatives.
>
> For K8 it should be the fastest way. K7 probably too.
Pity. I always loved 1 byte insns :)
/me hopes that K8 rev E or K9 will have optimized pop.
--
vda
On Sat, 30 Oct 2004, Denis Vlasenko wrote:
>
> On Saturday 30 October 2004 05:13, Andi Kleen wrote:
> > Linus Torvalds <[email protected]> writes:
> >
> > > Anyway, it's quite likely that for several CPU's the fastest sequence ends
> > > up actually being
> > >
> > > movl 4(%esp),%ecx
> > > movl 8(%esp),%edx
> > > movl 12(%esp),%eax
> > > addl $16,%esp
> > >
> > > which is also one of the biggest alternatives.
> >
> > For K8 it should be the fastest way. K7 probably too.
>
> Pity. I always loved 1 byte insns :)
I personally am a _huge_ believer in small code.
The sequence
popl %eax
popl %ecx
popl %edx
popl %eax
is four bytes. In contrast, the three moves and an add is 15 bytes. That's
almost 4 times as big.
And size _does_ matter. The extra 11 bytes means that if you have six of
these sequences in your program, you are pretty much _guaranteed_ one more
icache miss from memory. That's a few hundred cycles these days.
Considering that you _maybe_ won a cycle or two each time it was executed,
it's not at all clear that it's a win, except in benchmarks that have huge
repeat-rates. Real life doesn't usually have that. In many real-life
schenarios, repeat rates are in the tens of hundreds for most code...
And that's ignoring things like disk load times etc.
Sadly, the situation is often one where when you actually do all the
performance testing, you artificially increase the repeat-rates hugely:
you run the same program a thousand times in order to get a good profile,
and you keep in the the cache all the time. So performance analysis often
doesn't actually _see_ the downsides.
Linus
On Saturday 30 October 2004 20:53, Linus Torvalds wrote:
> > > > movl 4(%esp),%ecx
> > > > movl 8(%esp),%edx
> > > > movl 12(%esp),%eax
> > > > addl $16,%esp
> > > >
> > > > which is also one of the biggest alternatives.
> > >
> > > For K8 it should be the fastest way. K7 probably too.
> >
> > Pity. I always loved 1 byte insns :)
>
> I personally am a _huge_ believer in small code.
Thankfully you are not alone - a horde of uclibc/dietlibc/busybox
users shares these views. Also see http://smarden.org/pape/
> The sequence
>
> popl %eax
> popl %ecx
> popl %edx
> popl %eax
>
> is four bytes. In contrast, the three moves and an add is 15 bytes. That's
> almost 4 times as big.
>
> And size _does_ matter. The extra 11 bytes means that if you have six of
> these sequences in your program, you are pretty much _guaranteed_ one more
> icache miss from memory. That's a few hundred cycles these days.
> Considering that you _maybe_ won a cycle or two each time it was executed,
> it's not at all clear that it's a win, except in benchmarks that have huge
> repeat-rates. Real life doesn't usually have that. In many real-life
> schenarios, repeat rates are in the tens of hundreds for most code...
If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail
20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin
1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X
1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit
3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole
--
vda
On Sun, 2004-10-31 at 00:00 +0300, Denis Vlasenko wrote:
> If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
> 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail
> 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin
> 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X
> 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit
> 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole
Wow. evolution is now more bloated than kmail.
1424 rlrevell 15 0 125m 47m 29m S 7.8 10.1 1:41.78 evolution
1508 rlrevell 15 0 92432 30m 29m S 0.0 6.4 0:14.15 mozilla-bin
1090 root 16 0 55676 18m 40m S 24.8 3.9 0:46.98 XFree86
1379 rlrevell 15 0 33776 16m 18m S 0.3 3.5 0:06.65 nautilus
1377 rlrevell 15 0 19392 11m 15m S 0.0 2.5 0:03.29 gnome-panel
1458 rlrevell 16 0 28188 11m 15m S 3.9 2.5 0:10.44 gnome-terminal
1307 rlrevell 15 0 20828 11m 17m S 0.0 2.4 0:03.08 gnome-settings-
Lee
On Sunday 31 October 2004 00:14, Lee Revell wrote:
> On Sun, 2004-10-31 at 00:00 +0300, Denis Vlasenko wrote:
> > If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
> >
> > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
> > 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail
> > 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin
> > 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X
> > 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit
> > 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole
>
> Wow. evolution is now more bloated than kmail.
>
> 1424 rlrevell 15 0 125m 47m 29m S 7.8 10.1 1:41.78 evolution
> 1508 rlrevell 15 0 92432 30m 29m S 0.0 6.4 0:14.15 mozilla-bin
> 1090 root 16 0 55676 18m 40m S 24.8 3.9 0:46.98 XFree86
> 1379 rlrevell 15 0 33776 16m 18m S 0.3 3.5 0:06.65 nautilus
> 1377 rlrevell 15 0 19392 11m 15m S 0.0 2.5 0:03.29 gnome-panel
> 1458 rlrevell 16 0 28188 11m 15m S 3.9 2.5 0:10.44 gnome-terminal
> 1307 rlrevell 15 0 20828 11m 17m S 0.0 2.4 0:03.08 gnome-settings-
Well, I can try to compile packages with different options
for size, I can link against small libc, but I feel this
does not solve the problem: the code itself is bloated...
I am not a code genius, but want to help.
Hmm probably some bloat-detection tools would be helpful,
like "show me source_lines/object_size ratios of fonctions in
this ELF object file". Those with low ratio are suspects of
excessive inlining etc.
More ideas, anyone?
--
vda
On Sun, 2004-10-31 at 01:11 +0300, Denis Vlasenko wrote:
> Well, I can try to compile packages with different options
> for size, I can link against small libc, but I feel this
> does not solve the problem: the code itself is bloated...
>
> I am not a code genius, but want to help.
>
> Hmm probably some bloat-detection tools would be helpful,
> like "show me source_lines/object_size ratios of fonctions in
> this ELF object file". Those with low ratio are suspects of
> excessive inlining etc.
>
> More ideas, anyone?
I ageww it's a hard problem. Right now there is massive pressure on
Linux application developers to add features to catch up with MS and
Apple. This inevitably leads to bloat, we all know that efficiency is
the first thing to go out the window in that situation, the problem is
exacerbated by the wide availability of fast machines. It's an old,
depressing story...
That being said it would indeed be nice if we had more tools to quantify
bloat.
Lee
On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote:
> I am not a code genius, but want to help.
>
> Hmm probably some bloat-detection tools would be helpful,
> like "show me source_lines/object_size ratios of fonctions in
> this ELF object file". Those with low ratio are suspects of
> excessive inlining etc.
The problem with apps of this sort is the multiple layers of abstraction.
Xlib, GLib, GTK, GNOME, Pango, XML, etc.
No one wants to duplicate effort (rightly so). Each of these libs tries
to do EVERY POSSIBLE thing. They all end up bloated. Then you have to
link them all in. You end up bloated. Then it is very easy to rely on
those libs for EVERYTHING, rather thank actually thinking.
So you end up with the mindset of, for example, "if it's text it's XML".
You have to parse everything as XML, when simple parsers would be tons
faster and simpler and smaller.
Bloat is cause by feature creep at every layer, not just the app.
Youck.
Tim Hockin wrote:
> So you end up with the mindset of, for example, "if it's text it's XML".
> You have to parse everything as XML, when simple parsers would be tons
> faster and simpler and smaller.
hehehe. One of the reasons why I like XML is that you don't have to
keep cloning new parsers.
Jeff
On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote:
> Tim Hockin wrote:
> >So you end up with the mindset of, for example, "if it's text it's XML".
> >You have to parse everything as XML, when simple parsers would be tons
> >faster and simpler and smaller.
>
>
> hehehe. One of the reasons why I like XML is that you don't have to
> keep cloning new parsers.
I'm fine with XML, when it makes sense. In fact, I wrote an XML parser.
It's blazingly fast. But it doesn't try to do everything for everyone.
It does just as much as I needed. And Whn I need XML, I don;t have any
problem linking it in. It's only a couple hundred lines of C.
What irks me is best demonstrated by this:
At OLS last year or the year before, at a talk about DBUS, someone asked
about the DBUS protocol. When told that it was binary, they asked if
there was any advantage to that over text. The reply "We didn't want to
link an XML parser in".
Now, I am fine with not wanting to ad bloat. But umm, the question was
about TEXT, not XML. They are not the same thing. Not all text should be
XML.
On Sunday 31 October 2004 01:27, Tim Hockin wrote:
> On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote:
> > I am not a code genius, but want to help.
> >
> > Hmm probably some bloat-detection tools would be helpful,
> > like "show me source_lines/object_size ratios of fonctions in
> > this ELF object file". Those with low ratio are suspects of
> > excessive inlining etc.
>
> The problem with apps of this sort is the multiple layers of abstraction.
>
> Xlib, GLib, GTK, GNOME, Pango, XML, etc.
I think it makes sense to start from lower layers first:
Kernel team is reasonably aware of the bloat danger.
glibc is worse, but thanks to heroic actions of Eric Andersen
we have mostly feature complete uclibc, 4 times (!)
smaller than glibc.
Xlib, GLib.... - didn't look into them apart from cases
when they do not build or in bug hunting sessions.
Quick data point: glib-1.2.10 is 1/2 of uclibc in size.
glib-2.2.2 is 2 times uclibc. x4 growth :(
> No one wants to duplicate effort (rightly so). Each of these libs tries
> to do EVERY POSSIBLE thing. They all end up bloated. Then you have to
> link them all in. You end up bloated. Then it is very easy to rely on
> those libs for EVERYTHING, rather thank actually thinking.
>
> So you end up with the mindset of, for example, "if it's text it's XML".
> You have to parse everything as XML, when simple parsers would be tons
> faster and simpler and smaller.
>
> Bloat is cause by feature creep at every layer, not just the app.
I actually tried to convince maintainers of one package
that their code is needlessly complex. I did send patches
to remedy that a bit while fixing real bugs. Rejected.
Bugs were planned to be fixed by adding more code.
I've lost all hope on that case.
I guess this is a reason why bloat problem tend to be solved
by rewrite from scratch. I could name quite a few cases:
glibc -> dietlibc,uclibc
coreutils -> busybox
named -> djbdns
inetd -> daemontools+ucspi-tcp
sendmail -> qmail
syslogd -> socklog (http://smarden.org/socklog/)
It's sort of frightening that someone will need to
rewrite Xlib or, say, OpenOffice :(
--
vda
On Sun, 2004-10-31 at 02:13 +0300, Denis Vlasenko wrote:
> It's sort of frightening that someone will need to
> rewrite Xlib or, say, OpenOffice :(
I think very few application developers understand the point Linus made
- that bigger code IS slower code due to cache misses. If this were
widely understood we would be in pretty good shape.
Lee
On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote:
> > Bloat is cause by feature creep at every layer, not just the app.
>
> I actually tried to convince maintainers of one package
> that their code is needlessly complex. I did send patches
> to remedy that a bit while fixing real bugs. Rejected.
> Bugs were planned to be fixed by adding more code.
> I've lost all hope on that case.
See, there is an ego problem, too. If you rewrite my code, it means
you're better than I am. Rejected.
Features win over efficiency. Seriously, look at glibc. Hav eyou ever
tried to fix a bug in it? Holy CRAP is that horrible code. Each chunk of
code itself is OK (though it abuses macrso so thoroughly I hesitate to
call it C code). But it tried to support every architecture x every OS.
You know what? I don't CARE if the glibc code compiles on HPUX or not.
HPUX has it's own libc.
> I guess this is a reason why bloat problem tend to be solved
> by rewrite from scratch. I could name quite a few cases:
From-scratch is a huge risk. But yeah, sometimes it has to be.
> It's sort of frightening that someone will need to
> rewrite Xlib or, say, OpenOffice :(
Never gonna happen.
The gnome/gtk folks know they have a lot of code bloat, and know how to
shave about 10Mb off the desktop size already. What they don't have is
enough hands and brains to do this and the other stuff that is pressing.
So if the desktop stuff is annoying you join gnome-love or whatever the
kde equivalent is 8)
Alan
On Sul, 2004-10-31 at 00:20, Lee Revell wrote:
> I think very few application developers understand the point Linus made
> - that bigger code IS slower code due to cache misses. If this were
> widely understood we would be in pretty good shape.
On my laptop both Openoffice and gnome are measurably faster if you
build the lot with -Os (except a couple of image libs)
> I personally am a _huge_ believer in small code.
>
> The sequence
>
> popl %eax
> popl %ecx
> popl %edx
> popl %eax
>
> is four bytes. In contrast, the three moves and an add is 15 bytes. That's
> almost 4 times as big.
Using the long stack setup code was found to be a significant
win when enough registers were saved (several percent in real benchmarks)
on K8 gcc. It speed up all function calls considerably because it
eliminates several stalls for each function entry/exit. The popls
will all depend on each other because of their implicied reference
to esp.
Yes, it bloats the code, but function calls happen so often that having them
faster is really noticeable.
The K8 has quite big caches and is not decoding limited, so it
wasn't a too bad tradeoff there.
Ideally you would want to only do it on hot functions and optimize
rarely called functions for code size, but that would require profile
feedback which is often not feasible (JITs have an advantage here)
Unfortunately I don't think it is practically feasible for the kernel because
we rely on to be able to recreate the same vmlinuxs for debugging.
[It's a pity actually because modern compilers do a lot better
with profile feedback]
On P4 on the other hand it doesn't help at all and only makes
the code bigger. I did it from hand in the x86-64 syscall
code too (that was before there was EM64T, but I still think it was a
good idea). Perhaps AMD adds special hardware in some future CPU that
also makes it unnecessary, but currently it's like this and it helps.
-Andi
On Sat, Oct 30, 2004 at 07:20:04PM -0400, Lee Revell wrote:
> On Sun, 2004-10-31 at 02:13 +0300, Denis Vlasenko wrote:
> > It's sort of frightening that someone will need to
> > rewrite Xlib or, say, OpenOffice :(
>
> I think very few application developers understand the point Linus made
> - that bigger code IS slower code due to cache misses. If this were
> widely understood we would be in pretty good shape.
It's true in some cases, but not true in others. Don't make it your
gospel.
-Andi
On Sat, 30 Oct 2004, Alan Cox wrote:
> On Sul, 2004-10-31 at 00:20, Lee Revell wrote:
> > I think very few application developers understand the point Linus made
> > - that bigger code IS slower code due to cache misses. If this were
> > widely understood we would be in pretty good shape.
>
> On my laptop both Openoffice and gnome are measurably faster if you
> build the lot with -Os (except a couple of image libs)
>
Depends how much of gnome you use. I used to swear by -Os for
non-toolchain stuff, but in the end I got bitten by gnumeric on x86.
http://bugs.gnome.org/show_bug.cgi?id=128834 is similar, but in my case
opening *any* spreadsheet would cause gnumeric to segfault (gcc-3.3
series). Add in the time spent rebuilding gnome before I found this bug
report, and adding extra parts of gnome just in case I missed something,
and the time to load it is irrelevant. Since then I've had an anecdotal
report that -Os is known to cause problems with gnome. I s'pose people
will say it serves me right for doing my initial testing on ppc which
didn't have this problem ;) The point is that -Os is *much* less tested
than -O2 at the moment.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
Alan Cox wrote:
> So if the desktop stuff is annoying you join gnome-love or whatever the
> kde equivalent is 8)
Or join me in my effort to limit bloat. Why use an X server
that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
of code with very minimal kmallocing?
home.comcast.net/~plinius/fbui.html
Zack Smith
Bloat Liberation Front
On Sun, 31 Oct 2004, Andi Kleen wrote:
>
> Using the long stack setup code was found to be a significant
> win when enough registers were saved (several percent in real benchmarks)
> on K8 gcc.
For _what_?
Real applications, or SpecInt?
The fact is, SpecInt is not very interesting, because it has almost _zero_
icache footprint, and it has generally big repeat-rates, and to make
matters worse, you are allowed (and everybody does) warm up the caches by
running before you actually do the benchmark run.
_None_ of these are realistic for real life workloads.
> It speed up all function calls considerably because it
> eliminates several stalls for each function entry/exit.
.. it shaves off a few cycles in the cached case, yes.
> The popls will all depend on each other because of their implicied
> reference to esp.
Which is only true on moderately stupid CPU's. Two pop's don't _really_
depend on each other in any real sense, and there are CPU's that will
happily dual-issue them, or at least not stall in between (ie the pop's
will happily keep the memory unit 100% busy).
Linus
On 10/31/04 07:28, Tim Hockin wrote:
> On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote:
>
>>>Bloat is cause by feature creep at every layer, not just the app.
>>
>>I actually tried to convince maintainers of one package
>>that their code is needlessly complex. I did send patches
>>to remedy that a bit while fixing real bugs. Rejected.
>>Bugs were planned to be fixed by adding more code.
>>I've lost all hope on that case.
>
>
> See, there is an ego problem, too. If you rewrite my code, it means
> you're better than I am. Rejected.
>
> Features win over efficiency. Seriously, look at glibc. Hav eyou ever
> tried to fix a bug in it? Holy CRAP is that horrible code. Each chunk of
> code itself is OK (though it abuses macrso so thoroughly I hesitate to
> call it C code). But it tried to support every architecture x every OS.
> You know what? I don't CARE if the glibc code compiles on HPUX or not.
> HPUX has it's own libc.
>
>
>>I guess this is a reason why bloat problem tend to be solved
>>by rewrite from scratch. I could name quite a few cases:
>
>
> From-scratch is a huge risk. But yeah, sometimes it has to be.
>
>
>>It's sort of frightening that someone will need to
>>rewrite Xlib or, say, OpenOffice :(
Well, the xlib rewrite is happening (XCB/XCL).
One of the reasons cited is the size of xlib.
http://www.freedesktop.org/Software/xcb
~mc
On Sat, Oct 30, 2004 at 06:43:21PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 31 Oct 2004, Andi Kleen wrote:
> >
> > Using the long stack setup code was found to be a significant
> > win when enough registers were saved (several percent in real benchmarks)
> > on K8 gcc.
>
> For _what_?
>
> Real applications, or SpecInt?
iirc gcc itself was faster (the modern one, not the old version in SpecInt)
KDE startup ended up being faster too, but that may have been due to other
improvements too.
This was all tested on CPUs with very large caches (1MB L2), you
can pack a lot of code into that.
Also when people benchmark -m64 code compared to -m32 they often
see large improvements on AMD64 (as long as the code isn't long or pointer
memory bound), and I suspect at least part of that can be explained
by the -m64 gcc defaulting to the long function prologues.
Another example of larger code usually being better is x87 vs SSE2 floating
point math.
> The fact is, SpecInt is not very interesting, because it has almost _zero_
> icache footprint, and it has generally big repeat-rates, and to make
I don't think it's generally true. one counter example is the gcc subtest
in SpecInt.
> > It speed up all function calls considerably because it
> > eliminates several stalls for each function entry/exit.
>
> .. it shaves off a few cycles in the cached case, yes.
I would expect it to help in the uncached case too because
the CPU does very aggressive prefetching of code. Once
it gets started on a function it will fetch it very quickly.
>
> > The popls will all depend on each other because of their implicied
> > reference to esp.
>
> Which is only true on moderately stupid CPU's. Two pop's don't _really_
I don't see the K8 as a stupid CPU.
> depend on each other in any real sense, and there are CPU's that will
> happily dual-issue them, or at least not stall in between (ie the pop's
> will happily keep the memory unit 100% busy).
Yes, there are. And there are others that don't.
-Andi
Ken Moffat <[email protected]> said on Sun, 31 Oct 2004 01:09:54 +0000 (GMT):
> and the time to load it is irrelevant. Since then I've had an anecdotal
> report that -Os is known to cause problems with gnome. I s'pose people
> will say it serves me right for doing my initial testing on ppc which
> didn't have this problem ;) The point is that -Os is *much* less tested
> than -O2 at the moment.
Because people suck, and don't use it and hence test it.
Ie, test it!
I can't, because I prefer to stay away from gnome instead.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
"Warning: Do not look into laser with remaining eye" -- a physics experiment
"Press emergency laser shutdown button with remaining hand" -- J.D.Baldwin @ ASR
Z Smith wrote:
> Alan Cox wrote:
>
>> So if the desktop stuff is annoying you join gnome-love or whatever the
>> kde equivalent is 8)
>
>
> Or join me in my effort to limit bloat. Why use an X server
> that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
> of code with very minimal kmallocing?
>
> home.comcast.net/~plinius/fbui.html
>
> Zack Smith
> Bloat Liberation Front
>
Because some of us use remote X clients on big iron with an X server on your
desktop. IIRC (been a long time since my CAD classes), a whole bunch of FEA and
CAE/CAD applications worked this way.
There is a lot more flexibility inherent in user-space compared to kernel-space.
You can use PAM, Kerberos, and a whole host of other security devices that would
be difficult to implement efficiently in kernel-space.
Dude, that's a cool hack, but just about everything you did could be done with
svgalib and the input core interface. The advantage to svgalib is that if that
interface dies, you can recover the machine pretty easily, whereas kernel panics
are a bit more disruptive.
Still - it would be a nifty add-on for POS terminals, etc., just not the kind of
thing I'd expect to see in the kernel anytime soon. Once 2.7 is started, see if
people are more receptive. Take the time to flesh it out, get some more people on
board, see if Sourceforge will host the project, and lose the advertising campaign
- that's not likely to win any friends or supporters around here.
I don't mean to be harsh, but c'mon - "Bloat Liberation Front" - err... okaaay...
Good luck,
Jim
Tim Connors <[email protected]>, on Sun Oct 31, 2004 [01:42:34 PM] said:
> Ken Moffat <[email protected]> said on Sun, 31 Oct 2004 01:09:54 +0000 (GMT):
> > and the time to load it is irrelevant. Since then I've had an anecdotal
> > report that -Os is known to cause problems with gnome. I s'pose people
> > will say it serves me right for doing my initial testing on ppc which
> > didn't have this problem ;) The point is that -Os is *much* less tested
> > than -O2 at the moment.
>
> Because people suck, and don't use it and hence test it.
>
> Ie, test it!
>
> I can't, because I prefer to stay away from gnome instead.
>
Hi;
Ive been using -Os as my default compile flag under
Gentoo for probably over 2 years now. Havent noted any real
problems, and thats nearly 3gig of compressed source code
compiled on what is just my current system image.
(Well, I might suck a little because I havent done any
benchmarks or comparisons as to the actual benifits of doing
so. Also, I use fvwm;)
Paul
[email protected]
> --
> TimC -- http://astronomy.swin.edu.au/staff/tconnors/
>> If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
>>
>> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
>> 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail
>> 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin
>> 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X
>> 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit
>> 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole
Heh, and guess what: the people in #kde (irc.freenode.net for example) deny
that it's their fault with the statement "bah, that's shared libraries"!
If that's a lie or not, or a semi-lie, I'm definitely sure THAT libdcop libmcop
and every shitcrap that's running makes it almost impossible to run even on
Duron-800 w/256.
>Wow. evolution is now more bloated than kmail.
>
> 1424 rlrevell 15 0 125m 47m 29m S 7.8 10.1 1:41.78 evolution
> 1508 rlrevell 15 0 92432 30m 29m S 0.0 6.4 0:14.15 mozilla-bin
> 1090 root 16 0 55676 18m 40m S 24.8 3.9 0:46.98 XFree86
> 1379 rlrevell 15 0 33776 16m 18m S 0.3 3.5 0:06.65 nautilus
> 1377 rlrevell 15 0 19392 11m 15m S 0.0 2.5 0:03.29 gnome-panel
> 1458 rlrevell 16 0 28188 11m 15m S 3.9 2.5 0:10.44 gnome-terminal
> 1307 rlrevell 15 0 20828 11m 17m S 0.0 2.4 0:03.08 gnome-settings-
Gnome is no better. (Flamewar: I like ICEWM)
The only thing more bloated is the X server itself when it runs with the
proprietary NV GL core:
USER PID MEM% VSZ RSZ STAT START TIME COMMAND
root 5220 7.8 417872 20220 SL 08:37 0:03 X -noliste[...]
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
>> Hmm probably some bloat-detection tools would be helpful,
>> like "show me source_lines/object_size ratios of fonctions in
>> this ELF object file". Those with low ratio are suspects of
>> excessive inlining etc.
Hm, I've got a (very simple) line determining utility,
http://linux01.org:2222/f/UHXT/bin/sourcefuncsize
maybe someone can pipe it together with ls -l or whatever.
>The problem with apps of this sort is the multiple layers of abstraction.
>
>Xlib, GLib, GTK, GNOME, Pango, XML, etc.
At least they know one thing: that thou should not stuff everything into one
.so but multiple ones (if it's a lot). That /may/ reduce the size-in-memory,
because not all .so's need to be loaded. OTOH, most apps load /all/ anyway.
Heh, there we go.
>Bloat is cause by feature creep at every layer, not just the app.
I sense Java and C# being the best example.
Z Smith wrote:
>Or join me in my effort to limit bloat. Why use an X server
>that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
>of code with very minimal kmallocing?
FBUI does not have 3d acceleration?
Ken Moffat wrote:
>>The point is that -Os is *much* less tested
>>than -O2 at the moment.
>Because people suck, and don't use it and hence test it.
I doubt even the -O2-only-people use gprof/gcov frequently. :(
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
El Sat, 30 Oct 2004 18:25:38 -0400 Lee Revell <[email protected]> escribi?:
> I ageww it's a hard problem. Right now there is massive pressure on
> Linux application developers to add features to catch up with MS and
> Apple. This inevitably leads to bloat, we all know that efficiency is
I don't think it's so bad (ie: it could be _worse_)
There's some work going on to fix some "bloat problems" too, for example
the x.org people are working in a sort of xlib complement/replacement (i
don't know its real purpose) xcb which should help latency and code
size. Composite itself is a nice way of avoiding that apps redraw their
windows all the time. KDE "speed" is better is much better than a year
ago, gnome 2.8 is also somewhat "faster" (compare nautilus in gnome 2.6
vs the one in 2.8). Openoffice 2.0 also will have some "performance
improvements" (see http://development.openoffice.org/releases/q-concept.html#4.1.3.Performance|outline
and http://development.openoffice.org/releases/q-concept.html#3.1.3.Performance|outline)
On Sul, 2004-10-31 at 01:09, Ken Moffat wrote:
> and the time to load it is irrelevant. Since then I've had an anecdotal
> report that -Os is known to cause problems with gnome. I s'pose people
> will say it serves me right for doing my initial testing on ppc which
> didn't have this problem ;) The point is that -Os is *much* less tested
> than -O2 at the moment.
I've seen no real problems - x86-32 or x86-64, and my gnumeric appears
happy. Could be that the Red Hat gcc 3.3 has the relevant fixes already
in it from upstream I guess.
On Sul, 2004-10-31 at 01:21, Z Smith wrote:
> Alan Cox wrote:
>
> > So if the desktop stuff is annoying you join gnome-love or whatever the
> > kde equivalent is 8)
>
> Or join me in my effort to limit bloat. Why use an X server
> that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
> of code with very minimal kmallocing?
My X server seems to be running at about 4Mbytes, plus the frame buffer
mappings which make it appear a lot larger. I wouldn't be suprised if
half the 4Mb was pixmap cache too, maybe more.
I've helped write tiny UI kits (take a look at nanogui for example) but
they don't have the flexibility of X.
Alan
Alan Cox wrote:
> My X server seems to be running at about 4Mbytes, plus the frame buffer
> mappings which make it appear a lot larger. I wouldn't be suprised if
> half the 4Mb was pixmap cache too, maybe more.
At first sight that sounds like a plausible explanation, however
the facts in my case suggest something else is going on:
My laptop's framebuffer is only 800x600x24bpp VESA, or 1406kB.
But look at what X is doing:
root 632 6.1 17.5 22024 16440 ? S 12:05 0:17 X :0
The more apps in use, the more memory is used, but at the moment
I've only got xterm, rxvt, thunderbird, xclock and xload. My wm is
blackbox which is using 5 megs.
Also, just curious but why would memory-mapped I/O be counted
in the memory usage anyway? Shouldn't there be a separate number
for framebuffer memory and the like?
> I've helped write tiny UI kits (take a look at nanogui for example) but
> they don't have the flexibility of X.
In my experience, most of the flexibility is not necessary for
97% of what I do, yet it evidently costs a lot in memory usage
and speed.
Zack
On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote:
> Tim Hockin wrote:
> >So you end up with the mindset of, for example, "if it's text it's XML".
> >You have to parse everything as XML, when simple parsers would be tons
> >faster and simpler and smaller.
>
> hehehe. One of the reasons why I like XML is that you don't have to
> keep cloning new parsers.
.... if you don't mind bloating your application:
% ls -l /usr/lib/libxml2.a
4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a
- Ted
Theodore Ts'o wrote:
> On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote:
>
>>Tim Hockin wrote:
>>
>>>So you end up with the mindset of, for example, "if it's text it's XML".
>>>You have to parse everything as XML, when simple parsers would be tons
>>>faster and simpler and smaller.
>>
>>hehehe. One of the reasons why I like XML is that you don't have to
>>keep cloning new parsers.
>
>
> .... if you don't mind bloating your application:
>
> % ls -l /usr/lib/libxml2.a
> 4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a
GLib's is a lot smaller :)
Jeff
Diego Calleja wrote:
> I don't think it's so bad (ie: it could be _worse_)
But not everyone can tolerate today's level of bloat.
Imagine a small charity in a rural town in Bolivia or
Colorado. They have no budget for computers and no one
is offering donations. A local person put Linux on their 200 MHz
system after Windows crashed and the Windows CD couldn't
be found, but he can't put KDE or Gnome on it as well because
that would bring it to a crawl. The only way to make the
computer usable is to install an old distribution of Linux
from 1998 which has Netscape 4 but no office app. Eventually
they will give up on the computer and just throw it out,
because they can't wait forever for programmers to write
non-bloated software to make good use of their system.
The machine ends up at a landfill where it leeches chemicals
into the local water supply.
Zack
Jan Engelhardt wrote:
> FBUI does not have 3d acceleration?
The problem is 3d non-acceleration i.e. VESA and VGA
would still have to be supported. I'm no 3d expert but
I think there must be some software-based 3d function
would require using floating point, which isn't allowed
in the kernel.
Also, might not software 3d open the kernel up to
patent issues?
Zachary Smith
Linux 2.6.9 dies if I try to start x on my radeon 9200 SE pci card.
The screen goes black, and there is no response from the keyboard.
Sysrq doesn't work, I have to use the reset button.
Running X with the same configuration is fine with linux 2.6.8.1.
There is also a matrox G550 AGP card in the machine, and I have compiled
3D drivers for both cards.
Helge Hafting
>.... if you don't mind bloating your application:
>
>% ls -l /usr/lib/libxml2.a
>4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a
Whoa. Bet its creator compiled with -g -O2 rather than -g0 -O2. ANd with
-static instead of with <dynamic>. Yay look at this:
22:06 io:~ # l /usr/lib/libxml2.so -L
#SUSE# -rwxr-xr-x 1 root root 1145089 Apr 6 2004 /usr/lib/libxml2.so
4x smaller!
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
>> FBUI does not have 3d acceleration?
>
>The problem is 3d non-acceleration i.e. VESA and VGA
>would still have to be supported. I'm no 3d expert but
>I think there must be some software-based 3d function
>would require using floating point, which isn't allowed
>in the kernel.
>
>Also, might not software 3d open the kernel up to
>patent issues?
Whatever you do, 3D at the software level is slow, even with a fast comp.
See MESA.
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
Jan Engelhardt wrote:
>>Also, might not software 3d open the kernel up to
>>patent issues?
>
> Whatever you do, 3D at the software level is slow, even with a fast comp.
> See MESA.
Well it might be nice to add support for hardware 3-D, once 2-D
is mature. In fact I imagine it could be very convenient for
some people.
ZS
Hi.
I'd like, by this mail, to defend Linus Torvalds, despite
I don't know him personally.
I don't know him personally as I don't know that way yourself.
Anyway, I trust him much more than you and SCO together.
You ask why? He is doing something for the others, not
just for himself like you do (or at least you take special
care to look like you're doing so).
The world is not merely about money.
You wrote to Linus:
> Then rather than be reasonable and honorable about it,
> and say something like, " I have not verified that
> associated intellectual property with this submission
> nor have I received a release of claims from the
> contributor. I have been informed that several
> companies have conflicting claims regarding ownership
> and I have removed the code from the Linux Kernel and
> asked these vendors to maintain it as separate patches
> until these claims are resolved.", you keep right on
> sending it out, hosting it on your servers, all the
> while Linux Community members make statements that
> even if the code was someone else's "it's ours now
> because it was GPL'd".
How _you_ can say to anyone else what he/she should do?
Even if it was like you have imaginated, there are
thousands of Linux developers. Why are you putting
on Linus?!
Thousands of developers, from which everyone is responsible
for _himself_. They are all the same. They are people.
Born here, on this planet. Taught day by day how to
live here, how to survive, how to enjoy life.
Do you at least get my idea? Did you get idea of the
other defending mails from the other people which you
recieved (either as a part of mailing-list discussion
or personal)? The difference is, we try to look on things
like you say we should, you don't even try to look on
it the way we do.
> This flies in the face of every precept of contract law
> and intellectual property law in the United States.
Maybe I should not talk instead of Linus, but I can say at least
for myself and many others I know personally: We disagree
not only with copyright laws, but also with state, global
economics, your view of ``mature, adult, responsible
position'' and we try to live our lives the way we think
is the best.
> I don't think SCO has to apologize to you if you are not even willing to
> take a mature, adult, responsible position regarding intellectual
What IS ``a mature, adult, ... position''? You mean ``position which
_we_[SCO] would like you[Linus] to have?
> property, and even try to work with these people. You owe them an apology
> for running an IP laundry mat, cleverly disguised as a "freedom for all"
> open source effort.
Disguising is when somebody is killing people and saying he's
making them free.
> This is not good leadership or responsible stewardship of the
> IP of others. No one can trust you if this is how you are
> going to operate, or trust that your effort is free from
> contamination from others.
You don't understand what's so essential for us: The power does
not come from the top. Linus is not any ``leader'' or at least
not in the meaning you used that word in.
By the way, in the part I haven't quoted here, you are blustering
to Linus Torvalds. That's not nice technique and if you think
that while you have great success with it between some other
people, it'd be not so easy in __this__* multicultural, decentralized,
free software community.
* You cannot count us, you cannot point your finger at ``us''
and if you do so, you're alredy lacking those who don't know
yet they're part of ``us''. Although we are decentralized,
we are able to help each other.
With no regard
Jan Sarenik
PS(for lkml people):
This message was sent also to lkml list in hope it will
be somehow useful and with no intention to be listed on
``LKML-best'' and really no intention to say something
good about SCO or Jeff V. Merkey.
Good luck and don't worry!
Z Smith wrote:
> But not everyone can tolerate today's level of bloat.
>
> Imagine a small charity in a rural town in Bolivia or
> Colorado. They have no budget for computers and no one
> is offering donations.
Well, let me jump into this thread. I don't live in Bolivia or Colorado,
but I do live in Brazil.
The fastest computer that I have at my disposal is this one with a Duron
600MHz processor. My father uses a Pentium MMX 200MHz with 64MB of RAM.
Unfortunately, for financial reasons, I don't see we upgrading our
computers too soo.
It is nice to read Alan Cox saying that the Gnome team can make Gnome
use less memory in the future. I'm anxiously looking forward to that. In
the mean time, I will be using fluxbox and hoping that other parts of
the system (libraries etc) don't grow too fast for my computers.
I know plenty of people in the same situation that I am. Given the
choice of purchasing a book for my education or upgrading my computer, I
guess that I should spend money on the former.
And the same is true for many of my relatives and friends.
Rog?rio Brito.
--
Learn to quote e-mails decently at:
http://pub.tsn.dk/how-to-quote.php
http://learn.to/quote
http://www.xs4all.nl/~sbpoley/toppost.htm
Rog?rio Brito wrote:
> Z Smith wrote:
> The fastest computer that I have at my disposal is this one with a Duron
> 600MHz processor. My father uses a Pentium MMX 200MHz with 64MB of RAM.
> Unfortunately, for financial reasons, I don't see we upgrading our
> computers too soo.
It seems that as time goes by, more and more people are
coming to be financially limited. In some cases the cause
is clearly the IMF / World Bank / WTO triad.
Some casual reading:
http://www.gregpalast.com/printerfriendly.cfm?artid=96
Zack
On Fri, 29 Oct 2004, Linus Torvalds wrote:
>
>
> On Fri, 29 Oct 2004, linux-os wrote:
>>
>> Linus, there is no way in hell that you are going to move
>> a value from memory into a register (pop ecx) faster than
>> you are going to do anything to the stack-pointer or
>> any other register.
>
> Sorry, but you're wrong.
I am not wrong.
I don't understand anything about your theoretical CPU
with the magic stack engine. Anything I can get my
hands on functions exactly as I described and exactly
as would be expected. We work with real hardware here
and I have to test it as part of my job.
And, FYI, I spend all my working time trying to get the
last iota of performance out of ix86 CPUS. Since I can
only read publicly available documentation, I have
to test code in actual operation.
The attached file shows that the Intel Pentium 4 runs
exactly as I described. Further, there is no difference in
the CPU clocks used when adding a constant to the stack-
pointer or using LEA.
It also shows that poping stack-data into the same register
twice, as you suggested, takes the same time as using a
different register.
Timer overhead = 88 CPU clocks
push 3, pop 3 = 12 CPU clocks
push 3, pop 2 = 12 CPU clocks
push 3, pop 1 = 12 CPU clocks
push 3, pop none using ADD = 8 CPU clocks
push 3, pop none using LEA = 8 CPU clocks
push 3, pop into same register = 12 CPU clocks
The code uses a separate assembly-language file so that
the 'C' compiler can't optimize-away what I am measuring.
It also saves and uses the shortest number of CPU cycles
so the code doesn't have to execute with the interrupts
OFF to get a stable reading.
>
> Learn about modern CPU's some day, and realize that cached accesses are
> fast, and pipeline stalls are relatively much more expensive.
>
That's what I do, and that's what I teach.
> Now, if it was uncached, you'd have a point.
>
> Also think about why
>
> call xxx
> jmp yy
>
> is often much faster than
>
> push $yy
> jmp xxx
>
> and other small interesting facts about how CPU's actually work these
> days.
>
> Linus
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Sun, 31 Oct 2004, linux-os wrote:
>
> The attached file shows that the Intel Pentium 4 runs exactly as I
> described. Further, there is no difference in the CPU clocks used when
> adding a constant to the stack- pointer or using LEA.
Goodie. You found _one_ CPU that you think matters. On ethat doesn't even
have the hardware that I've described. And you ignore all the other
evidence.
Good for you.
Linus
On Sul, 2004-10-31 at 20:18, Z Smith wrote:
> My laptop's framebuffer is only 800x600x24bpp VESA, or 1406kB.
> But look at what X is doing:
X has the frame buffer mapped as reported by VESA sizing not the
minimal for the mode. (Think about RandR and you'll see why)
> root 632 6.1 17.5 22024 16440 ? S 12:05 0:17 X :0
>
> The more apps in use, the more memory is used, but at the moment
> I've only got xterm, rxvt, thunderbird, xclock and xload. My wm is
> blackbox which is using 5 megs.
Mostly shared with the other apps, you did remember to divide each page
by the number of users ?
> Also, just curious but why would memory-mapped I/O be counted
> in the memory usage anyway? Shouldn't there be a separate number
> for framebuffer memory and the like?
Actually there is probably not enough information in /proc to do the
maths on it. The kernel itself has a clear idea which vma's are not
backed by ram in the usual sense as they are marked VM_IO.
> > I've helped write tiny UI kits (take a look at nanogui for example) but
> > they don't have the flexibility of X.
>
> In my experience, most of the flexibility is not necessary for
> 97% of what I do, yet it evidently costs a lot in memory usage
> and speed.
So my X server is 1Mb larger because I can run networked apps and play
bzflag. Suits me as a tradeoff - I'm not saying it always is the right
decision - nanogui works well in restricted environments like video
recorders for example.
On Sul, 2004-10-31 at 20:15, Theodore Ts'o wrote:
> .... if you don't mind bloating your application:
>
> % ls -l /usr/lib/libxml2.a
> 4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a
Except that
1. The file size has nothing to do with the binary size as it is full of
symbols and maybe debug
2. Most of the pages of libxml2.so don't get paged in by a typical
application
3. If you have existing apps using it then its cost to you is nearly
zero because its already loaded.
libxml2 is a very complete validating all singing all dancing XML
parser. There are small non-validating parsers without every conceivable
glue interface that come down to about 10K.
On Sul, 2004-10-31 at 21:13, Jan Engelhardt wrote:
> Whatever you do, 3D at the software level is slow, even with a fast comp.
> See MESA.
If you are willing to lose a few bits of OpenGL you can do 3D pretty
fast in software for gaming. Take a look at stuff like TinyGL
>> Whatever you do, 3D at the software level is slow, even with a fast comp.
>> See MESA.
>
>If you are willing to lose a few bits of OpenGL you can do 3D pretty
>fast in software for gaming. Take a look at stuff like TinyGL
Ok, you're right. But to be honest, it does not need to be GL. Just look at
UnrealTournament (runs fine on a PII W98 w/233MHz, in software mode!)
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
On Monday 01 November 2004 13:27, Alan Cox wrote:
> 2. Most of the pages of libxml2.so don't get paged in by a typical
> application
This assumes that 'needed' functions are close together.
This can be easily not the case, so you end up using only
a fraction of fetched page's content.
Also this argument tend to defend library growth.
"It's mostly unused, don't worry". What if that
is not true? How to compare RAM footprint
of new versus old lib in this case?
Just believe that it didn't get worse?
This can't be checked easily:
even -static compile can fail to help.
glibc produce nearly 400kb executable for
int main() { return 0; }
because init code uses printf on error paths and
that pulls i18n in. How many kilobytes is really
runs - who knows...
--
vda
El Sun, 31 Oct 2004 12:53:21 -0800 Z Smith <[email protected]> escribi?:
> But not everyone can tolerate today's level of bloat.
Sadly it's true, but in the other hand I haven't seen something like gnome/kde
which don't eats lots of resources (mac os x and XP are not better, beos was
better they say), which makes me think that building a desktop environment
without eating lots of resources is not easy. Well, and your projct is also
bloat in some ways...it's small and all that but putting a graphics system
inside the kernel is one of the best definitions of "bloat" you can find...
Hi,
First, why use a .a file to specify code bloat? I don't see why you want
the object files... ie:
ar tv /usr/lib/libxml2.a
rw-rw-r-- 0/0 76336 Oct 29 04:34 2004 SAX.o
rw-rw-r-- 0/0 83156 Oct 29 04:34 2004 entities.o
rw-rw-r-- 0/0 90704 Oct 29 04:34 2004 encoding.o
rw-rw-r-- 0/0 84272 Oct 29 04:34 2004 error.o
rw-rw-r-- 0/0 90620 Oct 29 04:34 2004 parserInternals.o
...
It can gladly sit there for all i care esp since it's installed by the
-dev package.
-rw-r--r-- 1 root root 4312792 Oct 29 04:34 /usr/lib/libxml2.a
But when a app wants to load it you'll load a much smaller portion which
is: 987632 bytes.
As for X, check this out:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2886 root 15 0 416m 152m 283m S 1.7 15.1 309:31.75 XFree86
And yes, that might look bad, but consider agp memory, memory on the
card etc etc, then thats the figures we'd get. (and perhaps i should
actually shut down some apps as well =))
Btw, the most annoyingly large .a file i have ever found was libc.a in a
version of mdk, it included the whole libc build directory, post build,
weighing something along the lines of 24 mb.
Oh, and, you can never get rid of X, who will want something less
flexible when they have had something like this. You'll get back to the
same complexity sooner or later. I have to say that i much prefer
freedesktop's approach.
I'm not subbed so, you know what to do.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
On Monday 01 November 2004 08:48, Diego Calleja wrote:
> Sadly it's true, but in the other hand I haven't seen something like
> gnome/kde which don't eats lots of resources (mac os x and XP are not
> better, beos was better they say)
Part of the problem with KDE is the QT library underneath it all. QT 4 is
supposed to be leaner and faster. The KDE folks seem to be trying pretty
hard to reduce bloat whenever possible. But when you have software that's
expected to have the kitchen sink, it's especially challenging to reduce the
footprint while keeping all of the functionality.
I use openbox on my laptop. It's nothing near KDE in terms of functionality,
but it also runs reasonably snappy on a Pentium 266, so I can't complain too
much.
So far I'm pretty glad that the linux kernel developers have resisted putting
graphics calls and routines into the kernel. It slows things down a bit, but
I'd like to think you guys have learned from MS's mistakes. IMO one of the
biggest mistakes they ever made was to pollute the NT kernel with the
graphics subsystem. That said, FBUI looks like an interesting add-on
project.
Enough of my off topic ranting...
--Russell
--
Russell Miller - [email protected] - Le Mars, IA
Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs.
http://www.duskglow.com - 712-546-5886
On Sun, 2004-10-31 at 07:49 +0100, Jan Engelhardt wrote:
> Z Smith wrote:
> >Or join me in my effort to limit bloat. Why use an X server
> >that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
> >of code with very minimal kmallocing?
>
> FBUI does not have 3d acceleration?
Um I don't think chucking X is the answer. The problem is that it's
embarassingly slow compared to any modern GUI. If the display were as
snappy as WinXP I don't care if it's 200MB. On my desktop I constantly
see windows redrawing every freaking widget in situations where XP would
just blit from an offscreen buffer or something.
Anyway please keep replies off LKML and on the Xorg list...
Lee
Lee Revell wrote:
> On Sun, 2004-10-31 at 07:49 +0100, Jan Engelhardt wrote:
>
>>Z Smith wrote:
>>
>>>Or join me in my effort to limit bloat. Why use an X server
>>>that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
>>>of code with very minimal kmallocing?
>>
>>FBUI does not have 3d acceleration?
>
>
> Um I don't think chucking X is the answer. The problem is that it's
> embarassingly slow compared to any modern GUI. If the display were as
> snappy as WinXP I don't care if it's 200MB. On my desktop I constantly
> see windows redrawing every freaking widget in situations where XP would
> just blit from an offscreen buffer or something.
>
> Anyway please keep replies off LKML and on the Xorg list...
Actually, please keep replies off the Xorg list as well.
Thanks,
Kristian
On Sun, 31 Oct 2004, linux-os wrote:
> Timer overhead = 88 CPU clocks
> push 3, pop 3 = 12 CPU clocks
> push 3, pop 2 = 12 CPU clocks
> push 3, pop 1 = 12 CPU clocks
> push 3, pop none using ADD = 8 CPU clocks
> push 3, pop none using LEA = 8 CPU clocks
> push 3, pop into same register = 12 CPU clocks
your microbenchmark makes assumptions about rdtsc which haven't been valid
since the days of the 486. rdtsc has serializing aspects and overhead
that you can't just eliminate by running it in a tight loop and
subtracting out that "overhead".
you have to run your inner loops at least a few thousand of times between
rdtsc invocations and divide it out to find out the average cost in order
to eliminate the problems associated with rdtsc.
-dean
On Mon, 1 Nov 2004, dean gaudet wrote:
> On Mon, 1 Nov 2004, linux-os wrote:
>
>> On Mon, 1 Nov 2004, dean gaudet wrote:
>>
>>> On Sun, 31 Oct 2004, linux-os wrote:
>>>
>>>> Timer overhead = 88 CPU clocks
>>>> push 3, pop 3 = 12 CPU clocks
>>>> push 3, pop 2 = 12 CPU clocks
>>>> push 3, pop 1 = 12 CPU clocks
>>>> push 3, pop none using ADD = 8 CPU clocks
>>>> push 3, pop none using LEA = 8 CPU clocks
>>>> push 3, pop into same register = 12 CPU clocks
>>>
>>> your microbenchmark makes assumptions about rdtsc which haven't been valid
>>> since the days of the 486. rdtsc has serializing aspects and overhead that
>>> you can't just eliminate by running it in a tight loop and subtracting out
>>> that "overhead".
>>>
>>
>> Wrong.
>
> if you were correct then i should be able to measure 1 cycle differences
> in sequences such as the following:
[SNIPPED...]
Who said? The resolution isn't even specified. Experimental
results with several different processors seem to show that
the resolution is about 4 cycles.
Script started on Mon 01 Nov 2004 04:48:04 PM EST
# ./tester
Timer overhead = 88 CPU clocks
1 nop = 4 CPU clocks
2 nops = 4 CPU clocks
3 nops = 4 CPU clocks
4 nops = 8 CPU clocks
5 nops = 8 CPU clocks
6 nops = 8 CPU clocks
7 nops = 8 CPU clocks
8 nops = 12 CPU clocks
# exit
Script done on Mon 01 Nov 2004 04:48:34 PM EST
Assembly :
nop8: nop
nop7: nop
nop6: nop
nop5: nop
nop4: nop
nop3: nop
nop2: nop
nop1: nop
ret
.global nop1
.global nop2
.global nop3
.global nop4
.global nop5
.global nop6
.global nop7
.global nop8
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Mon, 1 Nov 2004, Linus Torvalds wrote:
>
>
> On Mon, 1 Nov 2004, linux-os wrote:
>>
>> You just don't get it. I, too, can make a so-called bench-mark
>> that will "prove" something that's so incredibly invalid that
>> it shouldn't even deserve an answer.
>
> *Plonk*
>
> You've just shown that not only do you ignore well-educated people who
> tell you why pipelines can have trouble with "lea", you also ignore hard
> numbers.
>
No. You've just shown that you like to argue. I recall that you
recently, like within the past 24 hours, supplied a patch that
got rid of the time-consuming stack operations in your semaphore
code. Remember, you changed it to pass parameters in registers.
Why would you bother if stack operations are free? The fact is
that you know that even a single extra memory access (i.e., a
stack operation) is costly. You just don't want to admit that
(remember the original premise if this discussion) popping
into an unused register to level the stack, is NOT better than
adding to the stack-pointer or, as another learned engineer
advised, using LEA instead.
I simply wrote some code that showed that poping registers used
more CPU cycles than adding to the stack-pointer, and using
LEA instead of the ADD showed no difference. Of course I
was immediately overwhelmed by responses that the benchmark
was invalid, presumably because it wasn't written by somebody
else.
> Your total focus on a cached memory access as being somehow more expensive
> than anything else going in the CPU pipeline is sad.
>
It's not a total focus. It's just necessary emphasis. Any work
done by your computer, ultimately comes from and goes to memory.
Some is memory-mapped hardware "memory" some is simply RAM.
Managing those memory accesses is very important when it comes
to maximizing the work that your computer can do in a limited
period of time. Wasting memory-access time is something one
should not do if at all possible.
> But hey, I've run out of ways to show you wrong. If you believe the world
> is flat, that's your problem.
>
> Linus
>
No, the world is crooked, not flat.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Mon, 1 Nov 2004, linux-os wrote:
>
> No. You've just shown that you like to argue. I recall that you
> recently, like within the past 24 hours, supplied a patch that
> got rid of the time-consuming stack operations in your semaphore
> code. Remember, you changed it to pass parameters in registers.
... because that fixed a _bug_.
> Why would you bother if stack operations are free?
I didn't say that instructions are free. I just tried (unsuccessfully) to
tell you that "lea" is not free either, and that "lea" has some serious
problems on several setups, ranging from old cpu's (AGI stalls) to new
CPU's (stack engine stalls). And that "pop" is often faster.
And you have been arguing against it despite the fact that I ended up
writing a small test-program to show that it's true. It's a _stupid_
test-program, but the fact is, you only need a single test-case to prove
some theory wrong.
Your theory that "lea" is somehow always cheaper than "pop" is wrong.
> It's not a total focus. It's just necessary emphasis. Any work
> done by your computer, ultimately comes from and goes to memory.
Not so.
A lot of work is done in cache. Any access that doesn't change the state
of the cache is a no-op as far as the memory bus is concerned. Ie a store
to a cacheline that is already dirty is just a cache access, as is a load
from a cacheline that is already loaded.
This is especially true on x86 CPU's, where the lack of registers means
that the core has been highly optimized for doing cached operations.
Remember: a CPU is not some kind of abstract entity - it's a very
practical piece of engineering that has been highly optimized for certain
usage patterns.
And the fact is, "lea" on %esp is not a common usage pattern. Which is
why, in practice, you will find CPU's that end up not optimizing for it.
While "pop"+"pop" is a _very_ common pattern, and why existing CPU's
do them efficiently.
Linus
On Llu, 2004-11-01 at 13:40, Denis Vlasenko wrote:
> This assumes that 'needed' functions are close together.
> This can be easily not the case, so you end up using only
> a fraction of fetched page's content.
And gprof will help you sort that out, along with -ffunction-sections
you can do pretty fine grained tidying
On Mon, 1 Nov 2004, Linus Torvalds wrote:
>
>
> On Mon, 1 Nov 2004, linux-os wrote:
>>
>> Wrong.
>>
>> (1) The '486 didn't have the rdtsc instruction.
>> (2) There are no 'serializing' or other black-magic aspects of
>> using the internal cycle-counter. That's exactly how you you
>> can benchmark the execution time of accessible code sequences.
>
> Sorry, but you shouldn't argue with people who know more than you do. I
> know Dean, and he analyzes things for work, and does know what he is
> doing.
>
> "rdtsc" _does_ partly serialize things, and it's not even architecturally
> defined, so you'll find that it serializes things in different ways on
> different CPU's. You can't just do
>
> rdtsc
> ...
> rdtsc
>
> and expect the stuff in between the rdtsc's to be timed exactly: some of
> it will overlap with the rdtsc's, some of it won't.
>
> On Intel, if I recall correctly, rdtsc is totally serializing, so you're
> testing not just the instructions between the rdtsc's, but the length of
> the pipeline, and the time it takes for stuff around it to calm down.
> Which is why two rdtsc's in sequence will show quite a lot of overhead on
> a P4 (something like 80 cycles).
>
> So you really want to do more operations in between the rdtsc's.
>
> Try the appended program. On a P4, the two sequnces are the same for me
> (92 cycles, 80 cycles overhead), while on a Pentium M, the sequence of two
> popl's (57 cycles) is faster than the sequence of "lea+popl" (59 cycles)
> and the overhead is 47 cycles.
>
> So can you _please_ just admit that you were wrong? On a P4, the pop/pop
> is the same cost as lea/pop, and on a Pentium M the pop/pop is faster,
> according to this test. Your contention that "pop" has to be slower than
> "lea" is WRONG.
>
> Linus
>
> ----
> #define PUSHEBX "pushl %%ebx\n\t"
> #define PUSHECX "pushl %%ecx\n\t"
> #define POPECX "popl %%ecx\n\t"
> #define POPEBX "popl %%ebx\n\t"
>
> #ifdef TEST_LEA
>
> #undef POPECX
> #define POPECX "leal 4(%%esp),%%esp\n\t"
>
> #endif
>
> #ifdef TEST_OVERHEAD
>
> #undef PUSHEBX
> #undef PUSHECX
> #undef POPEBX
> #undef POPECX
>
> #define PUSHEBX
> #define PUSHECX
> #define POPEBX
> #define POPECX
>
> #endif
>
> int main(void)
> {
> unsigned long start;
> unsigned long long end;
>
> asm volatile(
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> PUSHEBX
> PUSHECX
> "rdtsc\n\t"
> POPECX
> POPEBX
> POPECX
> POPEBX
> POPECX
> POPEBX
> POPECX
> POPEBX
> POPECX
> POPEBX
> POPECX
> POPEBX
> POPECX
> POPEBX
> POPECX
> POPEBX
> "movl %%eax,%%esi\n\t"
> "rdtsc"
> :"=A" (end), "=S" (start));
> printf("%ld cycles\n", (long) end-start);
> }
>
You just don't get it. I, too, can make a so-called bench-mark
that will "prove" something that's so incredibly invalid that
it shouldn't even deserve an answer. However, because you
are supposed to know what you are doing, I will give you
an answer.
It is totally impossible to perform useful work with memory,
i.e., poping the value of something from memory into a register,
without incurring the cost of that memory access. It doesn't
matter if the memory is in cache or if it needs to be read
using the memory controller. Time is time and it never runs
backwards. I spend most of my days with hardware logic analyzers
looking at the memory accesses so I damn-well know what I
am taking about. That memory-access takes a time-slot that
something else can't use. You never get it back. It is gone
forever. This is very important to understand. If you don't
understand this, you can fall into the "black-magic" trap.
Modern CPUs make it easy for so-called software engineers to
perceive so-called facts that are not, in fact, true. Because
it is possible for the CPU to perform memory-access independent
of instruction sequence (so-called parallel operations), it is
possible to make bench-marks that prove nothing, but seem to
show that a read from memory is free. It can never be free. It
will eventually show up. It was just deferred. Of course, if
your computer is just going to run that single bench-mark, then
return to a prompt, you can readily become victum of a very
common error because there is now plenty of time available to
just spin (or wait for an interrupt).
So, if you really want to make things fast, you keep your
memory accesses to the absolute minimum. Poping something
from the stack is the antithesis of what you want to do.
It's really amusing. Software development has devolved
into some black magic where logic, mathematics, and
physical testing no longer thrive.
Instead, we must listen to those who profess to know
about this magic because of some innate enlightenment
imparted to those favored few who are able to perceive
the trueness of their intellectual perception without
regard for contrary physical observations.
It's wonderful to not be bothered by tests, measurements,
documentation, or other facts.
Wake up and don't be dragged into the black-magic trap.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Mon, 1 Nov 2004, linux-os wrote:
>
> Wrong.
>
> (1) The '486 didn't have the rdtsc instruction.
> (2) There are no 'serializing' or other black-magic aspects of
> using the internal cycle-counter. That's exactly how you you
> can benchmark the execution time of accessible code sequences.
Sorry, but you shouldn't argue with people who know more than you do. I
know Dean, and he analyzes things for work, and does know what he is
doing.
"rdtsc" _does_ partly serialize things, and it's not even architecturally
defined, so you'll find that it serializes things in different ways on
different CPU's. You can't just do
rdtsc
...
rdtsc
and expect the stuff in between the rdtsc's to be timed exactly: some of
it will overlap with the rdtsc's, some of it won't.
On Intel, if I recall correctly, rdtsc is totally serializing, so you're
testing not just the instructions between the rdtsc's, but the length of
the pipeline, and the time it takes for stuff around it to calm down.
Which is why two rdtsc's in sequence will show quite a lot of overhead on
a P4 (something like 80 cycles).
So you really want to do more operations in between the rdtsc's.
Try the appended program. On a P4, the two sequnces are the same for me
(92 cycles, 80 cycles overhead), while on a Pentium M, the sequence of two
popl's (57 cycles) is faster than the sequence of "lea+popl" (59 cycles)
and the overhead is 47 cycles.
So can you _please_ just admit that you were wrong? On a P4, the pop/pop
is the same cost as lea/pop, and on a Pentium M the pop/pop is faster,
according to this test. Your contention that "pop" has to be slower than
"lea" is WRONG.
Linus
----
#define PUSHEBX "pushl %%ebx\n\t"
#define PUSHECX "pushl %%ecx\n\t"
#define POPECX "popl %%ecx\n\t"
#define POPEBX "popl %%ebx\n\t"
#ifdef TEST_LEA
#undef POPECX
#define POPECX "leal 4(%%esp),%%esp\n\t"
#endif
#ifdef TEST_OVERHEAD
#undef PUSHEBX
#undef PUSHECX
#undef POPEBX
#undef POPECX
#define PUSHEBX
#define PUSHECX
#define POPEBX
#define POPECX
#endif
int main(void)
{
unsigned long start;
unsigned long long end;
asm volatile(
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
PUSHEBX
PUSHECX
"rdtsc\n\t"
POPECX
POPEBX
POPECX
POPEBX
POPECX
POPEBX
POPECX
POPEBX
POPECX
POPEBX
POPECX
POPEBX
POPECX
POPEBX
POPECX
POPEBX
"movl %%eax,%%esi\n\t"
"rdtsc"
:"=A" (end), "=S" (start));
printf("%ld cycles\n", (long) end-start);
}
On Mon, 1 Nov 2004, linux-os wrote:
> On Mon, 1 Nov 2004, dean gaudet wrote:
>
> > On Sun, 31 Oct 2004, linux-os wrote:
> >
> > > Timer overhead = 88 CPU clocks
> > > push 3, pop 3 = 12 CPU clocks
> > > push 3, pop 2 = 12 CPU clocks
> > > push 3, pop 1 = 12 CPU clocks
> > > push 3, pop none using ADD = 8 CPU clocks
> > > push 3, pop none using LEA = 8 CPU clocks
> > > push 3, pop into same register = 12 CPU clocks
> >
> > your microbenchmark makes assumptions about rdtsc which haven't been valid
> > since the days of the 486. rdtsc has serializing aspects and overhead that
> > you can't just eliminate by running it in a tight loop and subtracting out
> > that "overhead".
> >
>
> Wrong.
if you were correct then i should be able to measure 1 cycle differences
in sequences such as the following:
rdtsc
mov %eax,%edi
shr $1,%ecx
rdtsc
rdtsc
mov %eax,%edi
shr $1,%ecx
shr $1,%ecx
rdtsc
...
rdtsc
mov %eax,%edi
shr $1,%ecx
shr $1,%ecx
shr $1,%ecx
shr $1,%ecx
shr $1,%ecx
shr $1,%ecx
shr $1,%ecx
shr $1,%ecx
rdtsc
yet the attached program demonstrates that such measurements are
inaccurate. the results should be a sequence of numbers increasing
by 1 each time.
p4 model 2: 80 80 84 84 84 84 84 84
p4 model 3: 120 120 120 120 120 120 120 128
p-m model 9: 47 46 47 48 49 50 56 57
k8: 5 5 5 5 5 5 5 5
-dean
% gcc -O -o rdtsc-rounding rdtsc-rounding.c
rdtsc-rounding.c:
#include <stdio.h>
#include <stdint.h>
#define template(n) \
static uint32_t foo##n(void) \
{ \
uint32_t start, done, trash1, trash2; \
\
__asm volatile( \
"\n rdtsc" \
"\n mov %%eax,%0" \
x##n("\n shr $1,%1") \
"\n rdtsc" \
: "=&r" (start), "=&r" (trash1), "=&a" (done), "=&d" (trash2) \
); \
return done - start; \
}
#define x1(x) x
#define x2(x) x x
#define x3(x) x x x
#define x4(x) x2(x) x2(x)
#define x5(x) x4(x) x
#define x6(x) x3(x2(x))
#define x7(x) x6(x) x
#define x8(x) x4(x2(x))
template(1)
template(2)
template(3)
template(4)
template(5)
template(6)
template(7)
template(8)
static uint32_t (*fn[9])(void) = {
0, foo1, foo2, foo3, foo4, foo5, foo6, foo7, foo8
};
static uint32_t bench(uint32_t (*f)(void))
{
uint32_t best;
unsigned i;
best = ~0;
for (i = 0; i < 100000; ++i) {
uint32_t cur = f();
if (cur < best) {
best = cur;
}
}
return best;
}
int main(int argc, char **argv)
{
unsigned i;
for (i = 1; i < sizeof(fn)/sizeof(fn[0]); ++i) {
printf("%u ", bench(fn[i]));
}
printf("\n");
return 0;
}
On Mon, 1 Nov 2004, Linus Torvalds wrote:
>
> So can you _please_ just admit that you were wrong? On a P4, the pop/pop
> is the same cost as lea/pop, and on a Pentium M the pop/pop is faster,
> according to this test. Your contention that "pop" has to be slower than
> "lea" is WRONG.
Btw, I'd like to emphasize "this test". Modern OoO CPU's are complex
animals. They have pipeline quirks etc that just means that things depend
on alignment, on code around it, and on register usage patterns of the
instructions that you test _and_ the instructions around those
instructions. So take any proof with a pinch of salt, because there are
bound to be other circumstances where factors around the code just change
the assumptions.
In short, any time you're looking at single cycle timings, you should be
very aware of the fact that your measurements are suspect. The best way to
avoid most of the problem is to never try to measure single cycles.
Measure performance on a program, not on a single instruction.
Linus
On Mon, 1 Nov 2004, dean gaudet wrote:
> On Sun, 31 Oct 2004, linux-os wrote:
>
>> Timer overhead = 88 CPU clocks
>> push 3, pop 3 = 12 CPU clocks
>> push 3, pop 2 = 12 CPU clocks
>> push 3, pop 1 = 12 CPU clocks
>> push 3, pop none using ADD = 8 CPU clocks
>> push 3, pop none using LEA = 8 CPU clocks
>> push 3, pop into same register = 12 CPU clocks
>
> your microbenchmark makes assumptions about rdtsc which haven't been valid
> since the days of the 486. rdtsc has serializing aspects and overhead that
> you can't just eliminate by running it in a tight loop and subtracting out
> that "overhead".
>
Wrong.
(1) The '486 didn't have the rdtsc instruction.
(2) There are no 'serializing' or other black-magic aspects of
using the internal cycle-counter. That's exactly how you you
can benchmark the execution time of accessible code sequences.
> you have to run your inner loops at least a few thousand of times between
> rdtsc invocations and divide it out to find out the average cost in order to
> eliminate the problems associated with rdtsc.
>
> -dean
>
You never average the cycle-time. The cycle-time is absolute.
You need to remove the affect of interrupts when you measure
performance so you need to sample a few times and save the
lowest number. That's the number obtained during the testing interval,
was not interrupted.
The provided code allows you to experiment. You can set the
TRIES count to 1. You will find that the results are noisy if
you are connected to an active network. Good results can be
obtained with it set to 4 if your computer is not being blasted
with lots of broadcast packets from M$ servers.
>
Of course you are not really interested in learning anything
about this are you?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Mon, 1 Nov 2004, linux-os wrote:
>
> You just don't get it. I, too, can make a so-called bench-mark
> that will "prove" something that's so incredibly invalid that
> it shouldn't even deserve an answer.
*Plonk*
You've just shown that not only do you ignore well-educated people who
tell you why pipelines can have trouble with "lea", you also ignore hard
numbers.
Your total focus on a cached memory access as being somehow more expensive
than anything else going in the CPU pipeline is sad.
But hey, I've run out of ways to show you wrong. If you believe the world
is flat, that's your problem.
Linus
Linus Torvalds wrote:
> On Intel, if I recall correctly, rdtsc is totally serializing, so you're
> testing not just the instructions between the rdtsc's, but the length of
> the pipeline, and the time it takes for stuff around it to calm down.
Actually, the Intel docs say that rdtsc is not serializing (specifically for the
P6 series, but linked off the P4 section of the site) and their sample
performance measuring code for the P4 shows it using a serializing instruction
before the call to rdtsc.
Chris
Linus,
The patch you provided patched without any rejects. However,
the system won't boot. It will not even get to
"Uncompressing Linux". After the GRUB loader sign-on,
the interrupts just remain disabled (no caps-lock or num-lock
change on the keyboard).
I patched Linux-2.6.9. Could you please review your patch?
I will await the possibility of a simple typo that I can
fix by hand before reverting.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.8 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Tue, 2 Nov 2004, linux-os wrote:
>
> The patch you provided patched without any rejects. However,
> the system won't boot.
Yes, there was a incorrect change to the "asmlinkage" definition that I
had played with before deciding to make just the semaphores be reg-arg,
and that change made it into my original patch by mistake. I sent out a
second message asking people to remove that part of the patch some time
later, but..
> I patched Linux-2.6.9. Could you please review your patch?
> I will await the possibility of a simple typo that I can
> fix by hand before reverting.
Just change the incorrect "3" in <asm-i386/linkage.h> (or whatever, this
is from memory):
#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(3)))
back to a "0". Asmlinkage still uses stack-based parameter passing, which
I'd love to fix eventually (we've had bugs in that area too), but it is
just too much pain to do right now.
Linus
On Tue, 2 Nov 2004, Linus Torvalds wrote:
>
> Just change the incorrect "3" in <asm-i386/linkage.h> (or whatever, this
> is from memory) back to a "0"
.. or just use the current -bk snapshot, actually. I may not have x86 as
my main desktop, but it's not like I had a really hard time finding one
(like the laptop laying there right on top of the desk ;), so the fixed
version got checked in already.
Linus
On Tue, 2 Nov 2004, Linus Torvalds wrote:
>
>
> On Tue, 2 Nov 2004, Linus Torvalds wrote:
>>
>> Just change the incorrect "3" in <asm-i386/linkage.h> (or whatever, this
>> is from memory) back to a "0"
>
> .. or just use the current -bk snapshot, actually. I may not have x86 as
> my main desktop, but it's not like I had a really hard time finding one
> (like the laptop laying there right on top of the desk ;), so the fixed
> version got checked in already.
>
> Linus
Okay. I got linux-2.6.9 back up.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
linux-os <[email protected]> said:
[...]
> Instead, we must listen to those who profess to know
> about this magic because of some innate enlightenment
> imparted to those favored few who are able to perceive
> the trueness of their intellectual perception without
> regard for contrary physical observations.
Right. Just go and tell that to somebody who actually designed one of the
competing CPU's inards. And who probably learnt nothing whatsowever on the
ones it was mimiking in the process.
> It's wonderful to not be bothered by tests, measurements,
> documentation, or other facts.
How true.
--
Dr. Horst H. von Brand User #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
linux-os wrote:
> You just don't get it. I, too, can make a so-called bench-mark
> that will "prove" something that's so incredibly invalid that
> it shouldn't even deserve an answer. However, because you
> are supposed to know what you are doing, I will give you
> an answer.
>
> It is totally impossible to perform useful work with memory,
> i.e., poping the value of something from memory into a register,
> without incurring the cost of that memory access. It doesn't
> matter if the memory is in cache or if it needs to be read
> using the memory controller. Time is time and it never runs
> backwards. I spend most of my days with hardware logic analyzers
> looking at the memory accesses so I damn-well know what I
> am taking about. That memory-access takes a time-slot that
> something else can't use. You never get it back. It is gone
> forever. This is very important to understand. If you don't
> understand this, you can fall into the "black-magic" trap.
>
> Modern CPUs make it easy for so-called software engineers to
> perceive so-called facts that are not, in fact, true. Because
> it is possible for the CPU to perform memory-access independent
> of instruction sequence (so-called parallel operations), it is
> possible to make bench-marks that prove nothing, but seem to
> show that a read from memory is free. It can never be free. It
> will eventually show up. It was just deferred. Of course, if
> your computer is just going to run that single bench-mark, then
> return to a prompt, you can readily become victum of a very
> common error because there is now plenty of time available to
> just spin (or wait for an interrupt).
>
> So, if you really want to make things fast, you keep your
> memory accesses to the absolute minimum. Poping something
> from the stack is the antithesis of what you want to do.
>
> It's really amusing. Software development has devolved
> into some black magic where logic, mathematics, and
> physical testing no longer thrive.
>
> Instead, we must listen to those who profess to know
> about this magic because of some innate enlightenment
> imparted to those favored few who are able to perceive
> the trueness of their intellectual perception without
> regard for contrary physical observations.
>
> It's wonderful to not be bothered by tests, measurements,
> documentation, or other facts.
>
> Wake up and don't be dragged into the black-magic trap.
The election is over, we can adopt a civil non-confrontational tone
again... Linus is not always right, but like most people he responds
better to "let me give you additional information" than "I know more
than you, take my word for it."
In this case, I think Dick does have a point on memory to cache use. It
appears from what little stuff I have here that with HT cache access is
serialized, and that memory access, even to L1 cache, might under some
circumstances be delayed. I won't guess if you would ever see that in
practice.
Getting information out of noisy measurements is not easy, and while
Dick is probably right that the lowest time is the "real" time, if the
average is lower doing something else, isn't that what we want?
My response test reports low, high, average, median, and 90th percentile
values, and depending on whether you want the best average, best
typical, or worst case avoidance you might find any of them useful. Oh,
and S.D. of the data to hint on how much you trust the results. I don't
think any of the test programs produce the definitive result, and I see
that results change depending on the CPU.
I think there are a lot of things more deserving this level of
consideration.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me