All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux v2.6.9...
@ 2004-10-18 22:45 Linus Torvalds
  2004-10-18 23:27 ` Thomas Zehetbauer
                   ` (5 more replies)
  0 siblings, 6 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-18 22:45 UTC (permalink / raw)
  To: Kernel Mailing List


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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9...
  2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
@ 2004-10-18 23:27 ` Thomas Zehetbauer
  2004-10-19  2:54 ` Eric W. Biederman
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 243+ messages in thread
From: Thomas Zehetbauer @ 2004-10-18 23:27 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

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 thomasz@hostmaster.org for key

Programmer: A biological machine designed to convert caffeine into code.




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9...
  2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
  2004-10-18 23:27 ` Thomas Zehetbauer
@ 2004-10-19  2:54 ` Eric W. Biederman
  2004-10-19 16:55   ` Jesper Juhl
  2004-10-19 14:36 ` Linux v2.6.9... (compile stats) John Cherry
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 243+ messages in thread
From: Eric W. Biederman @ 2004-10-19  2:54 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

Linus Torvalds <torvalds@osdl.org> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
  2004-10-18 23:27 ` Thomas Zehetbauer
  2004-10-19  2:54 ` Eric W. Biederman
@ 2004-10-19 14:36 ` John Cherry
  2004-10-19 16:18   ` Matthew Dharm
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 243+ messages in thread
From: John Cherry @ 2004-10-19 14:36 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

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
cherry@osdl.org
503-626-2455x29
Open Source Development Labs


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-19 14:36 ` Linux v2.6.9... (compile stats) John Cherry
@ 2004-10-19 16:18   ` Matthew Dharm
  2004-10-19 16:49     ` viro
                       ` (2 more replies)
  0 siblings, 3 replies; 243+ messages in thread
From: Matthew Dharm @ 2004-10-19 16:18 UTC (permalink / raw)
  To: John Cherry; +Cc: Linus Torvalds, Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 4702 bytes --]

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
> cherry@osdl.org
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
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 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-19 16:18   ` Matthew Dharm
@ 2004-10-19 16:49     ` viro
  2004-10-19 21:37     ` John Cherry
  2004-10-20 22:11     ` John Cherry
  2 siblings, 0 replies; 243+ messages in thread
From: viro @ 2004-10-19 16:49 UTC (permalink / raw)
  To: John Cherry, Linus Torvalds, Kernel Mailing List

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).

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9...
  2004-10-19  2:54 ` Eric W. Biederman
@ 2004-10-19 16:55   ` Jesper Juhl
  0 siblings, 0 replies; 243+ messages in thread
From: Jesper Juhl @ 2004-10-19 16:55 UTC (permalink / raw)
  To: ebiederm; +Cc: Linus Torvalds, Kernel Mailing List

On Tue, 18 Oct 2004 ebiederm@xmission.com wrote:

> Linus Torvalds <torvalds@osdl.org> 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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
                   ` (2 preceding siblings ...)
  2004-10-19 14:36 ` Linux v2.6.9... (compile stats) John Cherry
@ 2004-10-19 17:38 ` Jeff V. Merkey
  2004-10-19 19:13   ` Russell King
                     ` (13 more replies)
  2004-10-21  2:41 ` Linux v2.6.9 (Strange tty problem?) Paul
  2004-10-31 21:11 ` Linux v2.6.9 dies when starting X on radeon 9200 SE PCI Helge Hafting
  5 siblings, 14 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 17:38 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:13   ` Russell King
@ 2004-10-19 19:04     ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:04 UTC (permalink / raw)
  To: Russell King; +Cc: Linus Torvalds, Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:30   ` Rik van Riel
@ 2004-10-19 19:05     ` Jeff V. Merkey
  2004-10-19 20:14       ` Diego Calleja
  2004-10-19 20:05     ` Richard B. Johnson
  1 sibling, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:05 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:28   ` Andre Hedrick
@ 2004-10-19 19:10     ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:10 UTC (permalink / raw)
  To: Andre Hedrick; +Cc: Linus Torvalds, Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:24   ` Kurt Wall
@ 2004-10-19 19:12     ` Jeff V. Merkey
  2004-10-19 20:01     ` Richard B. Johnson
  1 sibling, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:12 UTC (permalink / raw)
  To: Kurt Wall; +Cc: Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
@ 2004-10-19 19:13   ` Russell King
  2004-10-19 19:04     ` Jeff V. Merkey
  2004-10-19 19:24   ` Kurt Wall
                     ` (12 subsequent siblings)
  13 siblings, 1 reply; 243+ messages in thread
From: Russell King @ 2004-10-19 19:13 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
  2004-10-19 19:13   ` Russell King
@ 2004-10-19 19:24   ` Kurt Wall
  2004-10-19 19:12     ` Jeff V. Merkey
  2004-10-19 20:01     ` Richard B. Johnson
  2004-10-19 19:28   ` Andre Hedrick
                     ` (11 subsequent siblings)
  13 siblings, 2 replies; 243+ messages in thread
From: Kurt Wall @ 2004-10-19 19:24 UTC (permalink / raw)
  To: Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:55   ` viro
@ 2004-10-19 19:25     ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:25 UTC (permalink / raw)
  To: viro; +Cc: Kernel Mailing List

viro@parcelfarce.linux.theplanet.co.uk 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)



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
  2004-10-19 19:13   ` Russell King
  2004-10-19 19:24   ` Kurt Wall
@ 2004-10-19 19:28   ` Andre Hedrick
  2004-10-19 19:10     ` Jeff V. Merkey
  2004-10-19 19:30   ` Rik van Riel
                     ` (10 subsequent siblings)
  13 siblings, 1 reply; 243+ messages in thread
From: Andre Hedrick @ 2004-10-19 19:28 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List


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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (2 preceding siblings ...)
  2004-10-19 19:28   ` Andre Hedrick
@ 2004-10-19 19:30   ` Rik van Riel
  2004-10-19 19:05     ` Jeff V. Merkey
  2004-10-19 20:05     ` Richard B. Johnson
  2004-10-19 19:45   ` Ross Biro
                     ` (9 subsequent siblings)
  13 siblings, 2 replies; 243+ messages in thread
From: Rik van Riel @ 2004-10-19 19:30 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:45   ` Ross Biro
@ 2004-10-19 19:36     ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:36 UTC (permalink / raw)
  To: Ross Biro; +Cc: Kernel Mailing List

Ross Biro wrote:

>Jeff V. Merkey <jmerkey@drdos.com>
>
>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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:05     ` Richard B. Johnson
@ 2004-10-19 19:38       ` Jeff V. Merkey
  2004-10-19 20:30         ` Thomas Gleixner
  0 siblings, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:38 UTC (permalink / raw)
  To: root; +Cc: Rik van Riel, Kernel Mailing List

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





^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:14       ` Diego Calleja
@ 2004-10-19 19:41         ` Jeff V. Merkey
  2004-10-20  8:27           ` Bernd Petrovitsch
  2004-10-19 19:47         ` Jeff V. Merkey
  1 sibling, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:41 UTC (permalink / raw)
  To: Diego Calleja; +Cc: riel, linux-kernel

Diego Calleja wrote:

>El Tue, 19 Oct 2004 13:05:34 -0600 "Jeff V. Merkey" <jmerkey@drdos.com> 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




^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (3 preceding siblings ...)
  2004-10-19 19:30   ` Rik van Riel
@ 2004-10-19 19:45   ` Ross Biro
  2004-10-19 19:36     ` Jeff V. Merkey
  2004-10-19 19:54   ` David Johnson
                     ` (8 subsequent siblings)
  13 siblings, 1 reply; 243+ messages in thread
From: Ross Biro @ 2004-10-19 19:45 UTC (permalink / raw)
  To: Kernel Mailing List

Jeff V. Merkey <jmerkey@drdos.com>

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:14       ` Diego Calleja
  2004-10-19 19:41         ` Jeff V. Merkey
@ 2004-10-19 19:47         ` Jeff V. Merkey
  1 sibling, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 19:47 UTC (permalink / raw)
  To: Diego Calleja; +Cc: riel, linux-kernel

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (4 preceding siblings ...)
  2004-10-19 19:45   ` Ross Biro
@ 2004-10-19 19:54   ` David Johnson
  2004-10-19 19:55   ` viro
                     ` (7 subsequent siblings)
  13 siblings, 0 replies; 243+ messages in thread
From: David Johnson @ 2004-10-19 19:54 UTC (permalink / raw)
  To: linux-kernel

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.


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (5 preceding siblings ...)
  2004-10-19 19:54   ` David Johnson
@ 2004-10-19 19:55   ` viro
  2004-10-19 19:25     ` Jeff V. Merkey
  2004-10-19 20:38   ` Dax Kelson
                     ` (6 subsequent siblings)
  13 siblings, 1 reply; 243+ messages in thread
From: viro @ 2004-10-19 19:55 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:24   ` Kurt Wall
  2004-10-19 19:12     ` Jeff V. Merkey
@ 2004-10-19 20:01     ` Richard B. Johnson
  2004-10-19 20:39       ` Matt Mackall
  1 sibling, 1 reply; 243+ messages in thread
From: Richard B. Johnson @ 2004-10-19 20:01 UTC (permalink / raw)
  To: Kurt Wall; +Cc: Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:30   ` Rik van Riel
  2004-10-19 19:05     ` Jeff V. Merkey
@ 2004-10-19 20:05     ` Richard B. Johnson
  2004-10-19 19:38       ` Jeff V. Merkey
  1 sibling, 1 reply; 243+ messages in thread
From: Richard B. Johnson @ 2004-10-19 20:05 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Jeff V. Merkey, Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:38   ` Dax Kelson
@ 2004-10-19 20:09     ` Jeff V. Merkey
  2004-10-19 22:16       ` Jim Nelson
                         ` (7 more replies)
  2004-10-20 19:46     ` Bill Davidsen
  1 sibling, 8 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 20:09 UTC (permalink / raw)
  To: Dax Kelson; +Cc: Linus Torvalds, Kernel Mailing List

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




^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:05     ` Jeff V. Merkey
@ 2004-10-19 20:14       ` Diego Calleja
  2004-10-19 19:41         ` Jeff V. Merkey
  2004-10-19 19:47         ` Jeff V. Merkey
  0 siblings, 2 replies; 243+ messages in thread
From: Diego Calleja @ 2004-10-19 20:14 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: riel, linux-kernel

El Tue, 19 Oct 2004 13:05:34 -0600 "Jeff V. Merkey" <jmerkey@drdos.com> 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?

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:30         ` Thomas Gleixner
@ 2004-10-19 20:15           ` Jeff V. Merkey
  2004-10-22 23:22           ` Tonnerre
  1 sibling, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 20:15 UTC (permalink / raw)
  To: tglx; +Cc: root, Rik van Riel, Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 21:02   ` Pekka Pietikainen
@ 2004-10-19 20:27     ` Jeff V. Merkey
  2004-10-22  6:54       ` Erik Andersen
  2004-10-19 21:17     ` Paul Fulghum
  2004-10-20 20:41     ` Geert Uytterhoeven
  2 siblings, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-19 20:27 UTC (permalink / raw)
  To: Pekka Pietikainen; +Cc: Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:38       ` Jeff V. Merkey
@ 2004-10-19 20:30         ` Thomas Gleixner
  2004-10-19 20:15           ` Jeff V. Merkey
  2004-10-22 23:22           ` Tonnerre
  0 siblings, 2 replies; 243+ messages in thread
From: Thomas Gleixner @ 2004-10-19 20:30 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: root, Rik van Riel, Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (6 preceding siblings ...)
  2004-10-19 19:55   ` viro
@ 2004-10-19 20:38   ` Dax Kelson
  2004-10-19 20:09     ` Jeff V. Merkey
  2004-10-20 19:46     ` Bill Davidsen
  2004-10-19 21:02   ` Pekka Pietikainen
                     ` (5 subsequent siblings)
  13 siblings, 2 replies; 243+ messages in thread
From: Dax Kelson @ 2004-10-19 20:38 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:01     ` Richard B. Johnson
@ 2004-10-19 20:39       ` Matt Mackall
  2004-10-20  0:06         ` Richard B. Johnson
  0 siblings, 1 reply; 243+ messages in thread
From: Matt Mackall @ 2004-10-19 20:39 UTC (permalink / raw)
  To: Richard B. Johnson; +Cc: Kurt Wall, Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (7 preceding siblings ...)
  2004-10-19 20:38   ` Dax Kelson
@ 2004-10-19 21:02   ` Pekka Pietikainen
  2004-10-19 20:27     ` Jeff V. Merkey
                       ` (2 more replies)
  2004-10-19 21:26   ` Ramón Rey Vicente
                     ` (4 subsequent siblings)
  13 siblings, 3 replies; 243+ messages in thread
From: Pekka Pietikainen @ 2004-10-19 21:02 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 21:02   ` Pekka Pietikainen
  2004-10-19 20:27     ` Jeff V. Merkey
@ 2004-10-19 21:17     ` Paul Fulghum
  2004-10-20 20:41     ` Geert Uytterhoeven
  2 siblings, 0 replies; 243+ messages in thread
From: Paul Fulghum @ 2004-10-19 21:17 UTC (permalink / raw)
  To: Pekka Pietikainen; +Cc: Jeff V. Merkey, Kernel Mailing List

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
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (8 preceding siblings ...)
  2004-10-19 21:02   ` Pekka Pietikainen
@ 2004-10-19 21:26   ` Ramón Rey Vicente
  2004-10-19 22:52   ` Buddy Lucas
                     ` (3 subsequent siblings)
  13 siblings, 0 replies; 243+ messages in thread
From: Ramón Rey Vicente @ 2004-10-19 21:26 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

-----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 rreylinux@jabber.org - 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-----

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-19 16:18   ` Matthew Dharm
  2004-10-19 16:49     ` viro
@ 2004-10-19 21:37     ` John Cherry
  2004-10-20 22:11     ` John Cherry
  2 siblings, 0 replies; 243+ messages in thread
From: John Cherry @ 2004-10-19 21:37 UTC (permalink / raw)
  To: Matthew Dharm; +Cc: Linus Torvalds, Kernel Mailing List

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
> > cherry@osdl.org
> > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
@ 2004-10-19 22:16       ` Jim Nelson
  2004-10-19 22:57         ` Bernd Petrovitsch
  2004-10-19 22:27       ` Scott Robert Ladd
                         ` (6 subsequent siblings)
  7 siblings, 1 reply; 243+ messages in thread
From: Jim Nelson @ 2004-10-19 22:16 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Dax Kelson, Kernel Mailing List

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>

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
  2004-10-19 22:16       ` Jim Nelson
@ 2004-10-19 22:27       ` Scott Robert Ladd
  2004-10-20 19:41         ` Bill Davidsen
  2004-10-20  1:15       ` Horst von Brand
                         ` (5 subsequent siblings)
  7 siblings, 1 reply; 243+ messages in thread
From: Scott Robert Ladd @ 2004-10-19 22:27 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (9 preceding siblings ...)
  2004-10-19 21:26   ` Ramón Rey Vicente
@ 2004-10-19 22:52   ` Buddy Lucas
  2004-10-20 23:43   ` Eric Bambach
                     ` (2 subsequent siblings)
  13 siblings, 0 replies; 243+ messages in thread
From: Buddy Lucas @ 2004-10-19 22:52 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

On Tue, 19 Oct 2004 11:38:03 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 22:16       ` Jim Nelson
@ 2004-10-19 22:57         ` Bernd Petrovitsch
  0 siblings, 0 replies; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-10-19 22:57 UTC (permalink / raw)
  To: Jim Nelson; +Cc: Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:39       ` Matt Mackall
@ 2004-10-20  0:06         ` Richard B. Johnson
  2004-10-20  5:21           ` Matt Mackall
  0 siblings, 1 reply; 243+ messages in thread
From: Richard B. Johnson @ 2004-10-20  0:06 UTC (permalink / raw)
  To: Matt Mackall; +Cc: Kurt Wall, Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
  2004-10-19 22:16       ` Jim Nelson
  2004-10-19 22:27       ` Scott Robert Ladd
@ 2004-10-20  1:15       ` Horst von Brand
  2004-10-20  1:16       ` Bastiaan Spandaw
                         ` (4 subsequent siblings)
  7 siblings, 0 replies; 243+ messages in thread
From: Horst von Brand @ 2004-10-20  1:15 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Dax Kelson, Linus Torvalds, Kernel Mailing List

"Jeff V. Merkey" <jmerkey@drdos.com> said:
> 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.

> No.  They seem to have some factual concrete evidence IP covered under
> Employee agreements was used and subsequently converted into Linux,

If they have this, why don't they show the evidence? It has been more than
a year and a half, and no shred of anything even remotely resembling
evidence has shown up. To me, this says clearly that there is none (I for
one would not go around spending a few millions of dollars a month just for
fun, if I could stop the bleeding by just showing what I will have to show
anyway later on).

>                                                                     and
> they are very confident of this.

That is for sure. But they have nothing more than that confidence.

>                                   From a cursory viewpoint, it looks
> valid.

Look closer.

>         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.

That is complete madness.

>                                    It's low impact for Linux and the
> other vendors.

Right. SMP, NUMA, filesystems are "low impact".

> XFS, JFS and NUMA are easy ones.

If you don't use them, that is.

> 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.

Linux (Linus et al) has done more than a good-faith effort to remove any
infringing code: They have repeatedly asked for details on what is
illegally in the kernel (and why), to remove it ASAP. No answer worthy of
that name. Likewise, the kernel code has been compared to SysV and other
variants (by people with access to the relevant sources), and nothing fishy
has shown up to here AFAIK.

> 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.

AFAIU, RCU is patented (now IBM holds it). It is certainly not in the
public domain.

> Dump the FS's and NUMA guys.  Then you are nearly there for being 
> squeaky clean.

Better just dump it all. Or start off a *BSD variant, where there is _no_
SCOX complications, and no need to shell out a few hundred millions to get
the relevant rights (yes, that is what they are worth; the 50K offer is
completely ridiculous). Note that just a few people declining your offer
makes it moot, and I know for a fact that many here on LKML will pass such
an offer.

Why don't you go trolling elsewhere?
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
                         ` (2 preceding siblings ...)
  2004-10-20  1:15       ` Horst von Brand
@ 2004-10-20  1:16       ` Bastiaan Spandaw
  2004-10-20 19:35         ` Bill Davidsen
  2004-10-20  3:45       ` Ryan Anderson
                         ` (3 subsequent siblings)
  7 siblings, 1 reply; 243+ messages in thread
From: Bastiaan Spandaw @ 2004-10-20  1:16 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
                         ` (3 preceding siblings ...)
  2004-10-20  1:16       ` Bastiaan Spandaw
@ 2004-10-20  3:45       ` Ryan Anderson
  2004-10-20  4:18         ` Lee Revell
  2004-10-21 23:59       ` Kelledin
                         ` (2 subsequent siblings)
  7 siblings, 1 reply; 243+ messages in thread
From: Ryan Anderson @ 2004-10-20  3:45 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Dax Kelson, Linus Torvalds, Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  3:45       ` Ryan Anderson
@ 2004-10-20  4:18         ` Lee Revell
  2004-10-20  4:41           ` Lee Revell
                             ` (2 more replies)
  0 siblings, 3 replies; 243+ messages in thread
From: Lee Revell @ 2004-10-20  4:18 UTC (permalink / raw)
  To: Ryan Anderson
  Cc: Jeff V. Merkey, Dax Kelson, Linus Torvalds, Kernel Mailing List

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 


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  4:18         ` Lee Revell
@ 2004-10-20  4:41           ` Lee Revell
  2004-10-20 11:49             ` Richard B. Johnson
  2004-10-20  5:58           ` Linux v2.6.9 and GPL Buyout John Alvord
  2004-10-20 14:42           ` Martin Waitz
  2 siblings, 1 reply; 243+ messages in thread
From: Lee Revell @ 2004-10-20  4:41 UTC (permalink / raw)
  To: Ryan Anderson
  Cc: Jeff V. Merkey, Dax Kelson, Linus Torvalds, Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  0:06         ` Richard B. Johnson
@ 2004-10-20  5:21           ` Matt Mackall
  0 siblings, 0 replies; 243+ messages in thread
From: Matt Mackall @ 2004-10-20  5:21 UTC (permalink / raw)
  To: Richard B. Johnson; +Cc: Kurt Wall, Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  4:18         ` Lee Revell
  2004-10-20  4:41           ` Lee Revell
@ 2004-10-20  5:58           ` John Alvord
  2004-10-20 14:42           ` Martin Waitz
  2 siblings, 0 replies; 243+ messages in thread
From: John Alvord @ 2004-10-20  5:58 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ryan Anderson, Jeff V. Merkey, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

On Wed, 20 Oct 2004 00:18:25 -0400, Lee Revell <rlrevell@joe-job.com>
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 19:41         ` Jeff V. Merkey
@ 2004-10-20  8:27           ` Bernd Petrovitsch
  2004-10-20  8:45             ` Jens Axboe
  0 siblings, 1 reply; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-10-20  8:27 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  8:27           ` Bernd Petrovitsch
@ 2004-10-20  8:45             ` Jens Axboe
  0 siblings, 0 replies; 243+ messages in thread
From: Jens Axboe @ 2004-10-20  8:45 UTC (permalink / raw)
  To: Bernd Petrovitsch; +Cc: Jeff V. Merkey, linux-kernel

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  4:41           ` Lee Revell
@ 2004-10-20 11:49             ` Richard B. Johnson
  2004-10-29 12:12               ` Semaphore assembly-code bug linux-os
  0 siblings, 1 reply; 243+ messages in thread
From: Richard B. Johnson @ 2004-10-20 11:49 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ryan Anderson, Jeff V. Merkey, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  4:18         ` Lee Revell
  2004-10-20  4:41           ` Lee Revell
  2004-10-20  5:58           ` Linux v2.6.9 and GPL Buyout John Alvord
@ 2004-10-20 14:42           ` Martin Waitz
  2 siblings, 0 replies; 243+ messages in thread
From: Martin Waitz @ 2004-10-20 14:42 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ryan Anderson, Jeff V. Merkey, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20  1:16       ` Bastiaan Spandaw
@ 2004-10-20 19:35         ` Bill Davidsen
  0 siblings, 0 replies; 243+ messages in thread
From: Bill Davidsen @ 2004-10-20 19:35 UTC (permalink / raw)
  To: linux-kernel

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 <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 22:27       ` Scott Robert Ladd
@ 2004-10-20 19:41         ` Bill Davidsen
  0 siblings, 0 replies; 243+ messages in thread
From: Bill Davidsen @ 2004-10-20 19:41 UTC (permalink / raw)
  To: linux-kernel

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 <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:38   ` Dax Kelson
  2004-10-19 20:09     ` Jeff V. Merkey
@ 2004-10-20 19:46     ` Bill Davidsen
  1 sibling, 0 replies; 243+ messages in thread
From: Bill Davidsen @ 2004-10-20 19:46 UTC (permalink / raw)
  To: linux-kernel

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 <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 21:02   ` Pekka Pietikainen
  2004-10-19 20:27     ` Jeff V. Merkey
  2004-10-19 21:17     ` Paul Fulghum
@ 2004-10-20 20:41     ` Geert Uytterhoeven
  2004-10-23 13:43       ` James Bruce
  2 siblings, 1 reply; 243+ messages in thread
From: Geert Uytterhoeven @ 2004-10-20 20:41 UTC (permalink / raw)
  To: Pekka Pietikainen; +Cc: Jeff V. Merkey, Kernel Mailing List

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 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-19 16:18   ` Matthew Dharm
  2004-10-19 16:49     ` viro
  2004-10-19 21:37     ` John Cherry
@ 2004-10-20 22:11     ` John Cherry
  2004-10-20 22:41       ` viro
  2004-10-20 22:50       ` Dave Jones
  2 siblings, 2 replies; 243+ messages in thread
From: John Cherry @ 2004-10-20 22:11 UTC (permalink / raw)
  To: Matthew Dharm; +Cc: Linus Torvalds, Kernel Mailing List

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
> > cherry@osdl.org
> > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
-- 
John Cherry
cherry@osdl.org
503-626-2455x29
Open Source Development Labs


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-20 22:11     ` John Cherry
@ 2004-10-20 22:41       ` viro
  2004-10-21  0:12         ` Linus Torvalds
  2004-10-20 22:50       ` Dave Jones
  1 sibling, 1 reply; 243+ messages in thread
From: viro @ 2004-10-20 22:41 UTC (permalink / raw)
  To: John Cherry; +Cc: Matthew Dharm, Linus Torvalds, Kernel Mailing List

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...

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-20 22:11     ` John Cherry
  2004-10-20 22:41       ` viro
@ 2004-10-20 22:50       ` Dave Jones
  1 sibling, 0 replies; 243+ messages in thread
From: Dave Jones @ 2004-10-20 22:50 UTC (permalink / raw)
  To: John Cherry; +Cc: Matthew Dharm, Linus Torvalds, Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (10 preceding siblings ...)
  2004-10-19 22:52   ` Buddy Lucas
@ 2004-10-20 23:43   ` Eric Bambach
  2004-10-20 23:48     ` Eric Bambach
                       ` (2 more replies)
  2004-10-22  8:48   ` Ingo Molnar
  2004-10-23  0:14   ` Jon Masters
  13 siblings, 3 replies; 243+ messages in thread
From: Eric Bambach @ 2004-10-20 23:43 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

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 

----------------------------------------

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20 23:43   ` Eric Bambach
@ 2004-10-20 23:48     ` Eric Bambach
  2004-10-20 23:59     ` Hua Zhong
  2004-10-21  0:13     ` Russell Miller
  2 siblings, 0 replies; 243+ messages in thread
From: Eric Bambach @ 2004-10-20 23:48 UTC (permalink / raw)
  To: Kernel Mailing List

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 

----------------------------------------

^ permalink raw reply	[flat|nested] 243+ messages in thread

* RE: Linux v2.6.9 and GPL Buyout
  2004-10-20 23:43   ` Eric Bambach
  2004-10-20 23:48     ` Eric Bambach
@ 2004-10-20 23:59     ` Hua Zhong
  2004-10-21  0:13     ` Russell Miller
  2 siblings, 0 replies; 243+ messages in thread
From: Hua Zhong @ 2004-10-20 23:59 UTC (permalink / raw)
  To: eric, 'Jeff V. Merkey'
  Cc: 'Linus Torvalds', 'Kernel Mailing List'

>	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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-20 22:41       ` viro
@ 2004-10-21  0:12         ` Linus Torvalds
  2004-10-21  0:29           ` Jeff Garzik
  0 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-10-21  0:12 UTC (permalink / raw)
  To: Al Viro, Jeff Garzik; +Cc: John Cherry, Matthew Dharm, Kernel Mailing List



On Wed, 20 Oct 2004 viro@parcelfarce.linux.theplanet.co.uk 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20 23:43   ` Eric Bambach
  2004-10-20 23:48     ` Eric Bambach
  2004-10-20 23:59     ` Hua Zhong
@ 2004-10-21  0:13     ` Russell Miller
  2004-10-21  0:18       ` Adam Heath
  2004-10-21 10:16       ` Horst von Brand
  2 siblings, 2 replies; 243+ messages in thread
From: Russell Miller @ 2004-10-21  0:13 UTC (permalink / raw)
  To: linux-kernel

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 - rmiller@duskglow.com - Le Mars, IA
Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs.
http://www.duskglow.com - 712-546-5886

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-21  0:13     ` Russell Miller
@ 2004-10-21  0:18       ` Adam Heath
  2004-10-21 10:16       ` Horst von Brand
  1 sibling, 0 replies; 243+ messages in thread
From: Adam Heath @ 2004-10-21  0:18 UTC (permalink / raw)
  Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  0:12         ` Linus Torvalds
@ 2004-10-21  0:29           ` Jeff Garzik
  2004-10-21  0:44             ` viro
  2004-10-21  1:55             ` viro
  0 siblings, 2 replies; 243+ messages in thread
From: Jeff Garzik @ 2004-10-21  0:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Al Viro, John Cherry, Matthew Dharm, Kernel Mailing List, linux-ide

Linus Torvalds wrote:
> 
> On Wed, 20 Oct 2004 viro@parcelfarce.linux.theplanet.co.uk 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)



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  0:29           ` Jeff Garzik
@ 2004-10-21  0:44             ` viro
  2004-10-21  1:55             ` viro
  1 sibling, 0 replies; 243+ messages in thread
From: viro @ 2004-10-21  0:44 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

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)...

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  0:29           ` Jeff Garzik
  2004-10-21  0:44             ` viro
@ 2004-10-21  1:55             ` viro
  2004-10-21  1:59               ` Jeff Garzik
  1 sibling, 1 reply; 243+ messages in thread
From: viro @ 2004-10-21  1:55 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

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?

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  1:55             ` viro
@ 2004-10-21  1:59               ` Jeff Garzik
  2004-10-21  2:24                 ` viro
  0 siblings, 1 reply; 243+ messages in thread
From: Jeff Garzik @ 2004-10-21  1:59 UTC (permalink / raw)
  To: viro
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

viro@parcelfarce.linux.theplanet.co.uk 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  1:59               ` Jeff Garzik
@ 2004-10-21  2:24                 ` viro
  2004-10-21  2:37                   ` Jeff Garzik
  0 siblings, 1 reply; 243+ messages in thread
From: viro @ 2004-10-21  2:24 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

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...

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  2:24                 ` viro
@ 2004-10-21  2:37                   ` Jeff Garzik
  2004-10-21  4:35                     ` viro
  0 siblings, 1 reply; 243+ messages in thread
From: Jeff Garzik @ 2004-10-21  2:37 UTC (permalink / raw)
  To: viro
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

viro@parcelfarce.linux.theplanet.co.uk 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
                   ` (3 preceding siblings ...)
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
@ 2004-10-21  2:41 ` Paul
  2004-10-21  9:07   ` Alan Cox
  2004-10-31 21:11 ` Linux v2.6.9 dies when starting X on radeon 9200 SE PCI Helge Hafting
  5 siblings, 1 reply; 243+ messages in thread
From: Paul @ 2004-10-21  2:41 UTC (permalink / raw)
  To: Kernel Mailing List; +Cc: Linus Torvalds

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1519 bytes --]

	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
set@pobox.com

machine is an older pIIx2 @400 running Gentoo
.config is attached


[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 31163 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9
# Tue Oct 19 23:53:34 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMII=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set
# CONFIG_PM_DEBUG is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_NAMES is not set
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=m
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
CONFIG_MD_RAID1=y
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_RAID6 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_IP_ROUTE_FWMARK is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
# CONFIG_IP_NF_MATCH_IPRANGE is not set
# CONFIG_IP_NF_MATCH_MAC is not set
# CONFIG_IP_NF_MATCH_PKTTYPE is not set
# CONFIG_IP_NF_MATCH_MARK is not set
# CONFIG_IP_NF_MATCH_MULTIPORT is not set
# CONFIG_IP_NF_MATCH_TOS is not set
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
# CONFIG_IP_NF_MATCH_AH_ESP is not set
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_TCPMSS is not set
# CONFIG_IP_NF_MATCH_HELPER is not set
CONFIG_IP_NF_MATCH_STATE=y
# CONFIG_IP_NF_MATCH_CONNTRACK is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
# CONFIG_IP_NF_TARGET_TCPMSS is not set
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_NAT_FTP=y
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_RED is not set
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_TCINDEX is not set
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_ACT is not set
# CONFIG_NET_CLS_POLICE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
CONFIG_EL3=y
# CONFIG_3C515 is not set
CONFIG_VORTEX=y
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=y
# CONFIG_ULTRA is not set
# CONFIG_SMC9194 is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=y
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=960
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=y
# CONFIG_SERIO_RAW is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=y
CONFIG_I2C_AMD8111=y
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
CONFIG_I2C_ISA=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_LM75=y
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
# CONFIG_SND_SEQUENCER_OSS is not set
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=y
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_RW_DETECT=y
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
# CONFIG_XFS_POSIX_ACL is not set
CONFIG_MINIX_FS=m
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
# CONFIG_SCHEDSTATS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  2:37                   ` Jeff Garzik
@ 2004-10-21  4:35                     ` viro
  2004-10-21  8:57                       ` Jeff Garzik
  0 siblings, 1 reply; 243+ messages in thread
From: viro @ 2004-10-21  4:35 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

On Wed, Oct 20, 2004 at 10:37:10PM -0400, Jeff Garzik wrote:
> viro@parcelfarce.linux.theplanet.co.uk 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?



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9... (compile stats)
  2004-10-21  4:35                     ` viro
@ 2004-10-21  8:57                       ` Jeff Garzik
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff Garzik @ 2004-10-21  8:57 UTC (permalink / raw)
  To: viro
  Cc: Linus Torvalds, John Cherry, Matthew Dharm, Kernel Mailing List,
	linux-ide

viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Oct 20, 2004 at 10:37:10PM -0400, Jeff Garzik wrote:
> 
>>viro@parcelfarce.linux.theplanet.co.uk 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21  2:41 ` Linux v2.6.9 (Strange tty problem?) Paul
@ 2004-10-21  9:07   ` Alan Cox
  2004-10-21 12:39     ` Russell King
                       ` (2 more replies)
  0 siblings, 3 replies; 243+ messages in thread
From: Alan Cox @ 2004-10-21  9:07 UTC (permalink / raw)
  To: Paul; +Cc: Linux Kernel Mailing List, Linus Torvalds

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


> 

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-21  0:13     ` Russell Miller
  2004-10-21  0:18       ` Adam Heath
@ 2004-10-21 10:16       ` Horst von Brand
  1 sibling, 0 replies; 243+ messages in thread
From: Horst von Brand @ 2004-10-21 10:16 UTC (permalink / raw)
  To: Russell Miller; +Cc: linux-kernel

Russell Miller <rmiller@duskglow.com> said:
> 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. :)

I've got a few lines of my own too, and I won't release except under GPL
either.
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21  9:07   ` Alan Cox
@ 2004-10-21 12:39     ` Russell King
  2004-10-21 13:20     ` Paul Fulghum
  2004-10-21 18:12     ` Paul Fulghum
  2 siblings, 0 replies; 243+ messages in thread
From: Russell King @ 2004-10-21 12:39 UTC (permalink / raw)
  To: Alan Cox; +Cc: Paul, Linux Kernel Mailing List, Linus Torvalds

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21  9:07   ` Alan Cox
  2004-10-21 12:39     ` Russell King
@ 2004-10-21 13:20     ` Paul Fulghum
  2004-10-21 15:37       ` Alan Cox
  2004-10-21 15:47       ` Paul Fulghum
  2004-10-21 18:12     ` Paul Fulghum
  2 siblings, 2 replies; 243+ messages in thread
From: Paul Fulghum @ 2004-10-21 13:20 UTC (permalink / raw)
  To: Alan Cox; +Cc: Paul, Linux Kernel Mailing List, Linus Torvalds

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
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21 13:20     ` Paul Fulghum
@ 2004-10-21 15:37       ` Alan Cox
  2004-10-21 17:00         ` Paul Fulghum
  2004-10-21 15:47       ` Paul Fulghum
  1 sibling, 1 reply; 243+ messages in thread
From: Alan Cox @ 2004-10-21 15:37 UTC (permalink / raw)
  To: Paul Fulghum; +Cc: Paul, Linux Kernel Mailing List, Linus Torvalds

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.


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21 13:20     ` Paul Fulghum
  2004-10-21 15:37       ` Alan Cox
@ 2004-10-21 15:47       ` Paul Fulghum
  1 sibling, 0 replies; 243+ messages in thread
From: Paul Fulghum @ 2004-10-21 15:47 UTC (permalink / raw)
  To: Alan Cox; +Cc: Paul, Linux Kernel Mailing List, Linus Torvalds

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
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21 15:37       ` Alan Cox
@ 2004-10-21 17:00         ` Paul Fulghum
  0 siblings, 0 replies; 243+ messages in thread
From: Paul Fulghum @ 2004-10-21 17:00 UTC (permalink / raw)
  To: Alan Cox; +Cc: Paul, Linux Kernel Mailing List, Linus Torvalds

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
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 (Strange tty problem?)
  2004-10-21  9:07   ` Alan Cox
  2004-10-21 12:39     ` Russell King
  2004-10-21 13:20     ` Paul Fulghum
@ 2004-10-21 18:12     ` Paul Fulghum
  2 siblings, 0 replies; 243+ messages in thread
From: Paul Fulghum @ 2004-10-21 18:12 UTC (permalink / raw)
  To: Alan Cox; +Cc: Paul, Linux Kernel Mailing List, Linus Torvalds

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
paulkf@microgate.com

--- 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,



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
                         ` (4 preceding siblings ...)
  2004-10-20  3:45       ` Ryan Anderson
@ 2004-10-21 23:59       ` Kelledin
  2004-10-22  8:46       ` Bernd Petrovitsch
  2004-10-22  9:07       ` David Weinehall
  7 siblings, 0 replies; 243+ messages in thread
From: Kelledin @ 2004-10-21 23:59 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

[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?"

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:27     ` Jeff V. Merkey
@ 2004-10-22  6:54       ` Erik Andersen
  2004-10-22 16:12         ` Jeff V. Merkey
  0 siblings, 1 reply; 243+ messages in thread
From: Erik Andersen @ 2004-10-22  6:54 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Pekka Pietikainen, Kernel Mailing List

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--

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
                         ` (5 preceding siblings ...)
  2004-10-21 23:59       ` Kelledin
@ 2004-10-22  8:46       ` Bernd Petrovitsch
  2004-10-22  9:07       ` David Weinehall
  7 siblings, 0 replies; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-10-22  8:46 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

[ 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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (11 preceding siblings ...)
  2004-10-20 23:43   ` Eric Bambach
@ 2004-10-22  8:48   ` Ingo Molnar
  2004-10-22 16:15     ` Jeff V. Merkey
  2004-10-23  0:14   ` Jon Masters
  13 siblings, 1 reply; 243+ messages in thread
From: Ingo Molnar @ 2004-10-22  8:48 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List


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 <jmerkey@drdos.com> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:09     ` Jeff V. Merkey
                         ` (6 preceding siblings ...)
  2004-10-22  8:46       ` Bernd Petrovitsch
@ 2004-10-22  9:07       ` David Weinehall
  2004-10-22 16:15         ` Jeff V. Merkey
  7 siblings, 1 reply; 243+ messages in thread
From: David Weinehall @ 2004-10-22  9:07 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Dax Kelson, Linus Torvalds, Kernel Mailing List

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 <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22  6:54       ` Erik Andersen
@ 2004-10-22 16:12         ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 16:12 UTC (permalink / raw)
  To: andersen; +Cc: Pekka Pietikainen, Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22  9:07       ` David Weinehall
@ 2004-10-22 16:15         ` Jeff V. Merkey
  2004-10-22 17:52           ` Al Viro
                             ` (2 more replies)
  0 siblings, 3 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 16:15 UTC (permalink / raw)
  To: David Weinehall; +Cc: Dax Kelson, Linus Torvalds, Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22  8:48   ` Ingo Molnar
@ 2004-10-22 16:15     ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 16:15 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Linus Torvalds, Kernel Mailing List

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 <jmerkey@drdos.com> 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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Ingo,

Bite me.

:-)

Jeff

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 17:52           ` Al Viro
@ 2004-10-22 17:22             ` Jeff V. Merkey
  2004-10-22 19:37               ` Jeff V. Merkey
  0 siblings, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 17:22 UTC (permalink / raw)
  To: Al Viro; +Cc: David Weinehall, Dax Kelson, Linus Torvalds, Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 16:15         ` Jeff V. Merkey
@ 2004-10-22 17:52           ` Al Viro
  2004-10-22 17:22             ` Jeff V. Merkey
  2004-10-24 11:00           ` Matthias Andree
  2004-10-24 14:13           ` Kai Henningsen
  2 siblings, 1 reply; 243+ messages in thread
From: Al Viro @ 2004-10-22 17:52 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: David Weinehall, Dax Kelson, Linus Torvalds, Kernel Mailing List

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...

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 17:22             ` Jeff V. Merkey
@ 2004-10-22 19:37               ` Jeff V. Merkey
  2004-10-22 20:46                 ` Grahame White
                                   ` (6 more replies)
  0 siblings, 7 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 19:37 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: Al Viro, David Weinehall, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

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.



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
@ 2004-10-22 20:46                 ` Grahame White
  2004-10-22 20:58                 ` Buddy Lucas
                                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 243+ messages in thread
From: Grahame White @ 2004-10-22 20:46 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: Al Viro, David Weinehall, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
  2004-10-22 20:46                 ` Grahame White
@ 2004-10-22 20:58                 ` Buddy Lucas
  2004-10-22 21:00                 ` Richard B. Johnson
                                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 243+ messages in thread
From: Buddy Lucas @ 2004-10-22 20:58 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: Al Viro, David Weinehall, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

On Fri, 22 Oct 2004 13:37:28 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
  2004-10-22 20:46                 ` Grahame White
  2004-10-22 20:58                 ` Buddy Lucas
@ 2004-10-22 21:00                 ` Richard B. Johnson
  2004-10-22 21:03                 ` Thomas Gleixner
                                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 243+ messages in thread
From: Richard B. Johnson @ 2004-10-22 21:00 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: Al Viro, David Weinehall, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
                                   ` (2 preceding siblings ...)
  2004-10-22 21:00                 ` Richard B. Johnson
@ 2004-10-22 21:03                 ` Thomas Gleixner
  2004-10-23 12:33                 ` Bernd Petrovitsch
                                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2004-10-22 21:03 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Al Viro, David Weinehall, Dax Kelson, Linus Torvalds, LKML

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 20:30         ` Thomas Gleixner
  2004-10-19 20:15           ` Jeff V. Merkey
@ 2004-10-22 23:22           ` Tonnerre
  1 sibling, 0 replies; 243+ messages in thread
From: Tonnerre @ 2004-10-22 23:22 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Jeff V. Merkey, root, Rik van Riel, Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  0:14   ` Jon Masters
@ 2004-10-22 23:46     ` Jeff V. Merkey
  2004-10-23  0:57       ` Jon Masters
  2004-10-23  0:38     ` Lee Revell
  1 sibling, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 23:46 UTC (permalink / raw)
  To: jonathan; +Cc: Linus Torvalds, Kernel Mailing List

Jon Masters wrote:

>On Tue, 19 Oct 2004 11:38:03 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  0:38     ` Lee Revell
@ 2004-10-23  0:07       ` Jeff V. Merkey
  2004-10-23  1:06         ` Lee Revell
  0 siblings, 1 reply; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-23  0:07 UTC (permalink / raw)
  To: Lee Revell; +Cc: jonathan, Linus Torvalds, Kernel Mailing List

Lee Revell wrote:

>Merkey is a troll.  QED.
>
>Lee
>
>  
>

Not! 

Jeff


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
                     ` (12 preceding siblings ...)
  2004-10-22  8:48   ` Ingo Molnar
@ 2004-10-23  0:14   ` Jon Masters
  2004-10-22 23:46     ` Jeff V. Merkey
  2004-10-23  0:38     ` Lee Revell
  13 siblings, 2 replies; 243+ messages in thread
From: Jon Masters @ 2004-10-23  0:14 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

On Tue, 19 Oct 2004 11:38:03 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  0:14   ` Jon Masters
  2004-10-22 23:46     ` Jeff V. Merkey
@ 2004-10-23  0:38     ` Lee Revell
  2004-10-23  0:07       ` Jeff V. Merkey
  1 sibling, 1 reply; 243+ messages in thread
From: Lee Revell @ 2004-10-23  0:38 UTC (permalink / raw)
  To: jonathan; +Cc: Jeff V. Merkey, Linus Torvalds, Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 23:46     ` Jeff V. Merkey
@ 2004-10-23  0:57       ` Jon Masters
  2004-10-23  4:42         ` Jeff V. Merkey
  0 siblings, 1 reply; 243+ messages in thread
From: Jon Masters @ 2004-10-23  0:57 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List

On Fri, 22 Oct 2004 17:46:54 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  0:07       ` Jeff V. Merkey
@ 2004-10-23  1:06         ` Lee Revell
  0 siblings, 0 replies; 243+ messages in thread
From: Lee Revell @ 2004-10-23  1:06 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: jonathan, Linus Torvalds, Kernel Mailing List, Robert Love

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  0:57       ` Jon Masters
@ 2004-10-23  4:42         ` Jeff V. Merkey
  2004-10-23  6:32           ` Nick Piggin
                             ` (3 more replies)
  0 siblings, 4 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-23  4:42 UTC (permalink / raw)
  To: jonathan; +Cc: Linus Torvalds, Kernel Mailing List, bstowell, jcn


>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:

bstowell@sco.com
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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  4:42         ` Jeff V. Merkey
@ 2004-10-23  6:32           ` Nick Piggin
       [not found]             ` <20041023064538.GA7866@galt.devicelogics.com>
  2004-10-23 10:11           ` Gene Heskett
                             ` (2 subsequent siblings)
  3 siblings, 1 reply; 243+ messages in thread
From: Nick Piggin @ 2004-10-23  6:32 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: jonathan, Linus Torvalds, Kernel Mailing List, bstowell, jcn

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? :)

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
       [not found]             ` <20041023064538.GA7866@galt.devicelogics.com>
@ 2004-10-23  7:20               ` Jeff V. Merkey
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-23  7:20 UTC (permalink / raw)
  To: jmerkey
  Cc: Nick Piggin, jonathan, Linus Torvalds, Kernel Mailing List,
	bstowell, jcn

jmerkey@galt.devicelogics.com wrote:

>On Sat, Oct 23, 2004 at 04:32:54PM +1000, Nick Piggin wrote:
>  
>
>>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? :)
>>    
>>
>
>Yeah.  The new list will be at www.gadugi.org (means working together
>in Cherokee) at the Cherokee Nation tribal complex in Tahlequah
>Oklahoma.  Don't worry, I'll post bugs I find and interesting
>patches from time to time.  The stuff I write that's worth lots 
>of $$$ however, I will put here.  There's some new open source 
>development starting there in about a month.
>
>Come join us.  We are sovereign in the US and SCO, Novell, IBM 
>and anyone else's legal crap goes nowhere.  You have to go to 
>the Congress of the United States and find a treaty to litigate 
>or get them to pass an act before someone can even sue us.  
>if SCO want to sue us for IP infringement in the US, good luck,
>and our agreements with other companies like IBM and others
>canot be attacked in court -- they have sovereign immunity.
>
>Want to move development there and use our license....
>
>Think about it.  Someone needs to thrw Darl McBride a bone,
>he's getting that hungry look in his eyes again .....  Nick
>you are invited to Cherokee Nation to hang out and so are all
>your Linux friends.
>
>:-)
>
>Jeff
>
>
>
>  
>


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  4:42         ` Jeff V. Merkey
  2004-10-23  6:32           ` Nick Piggin
@ 2004-10-23 10:11           ` Gene Heskett
  2004-10-23 16:28           ` Linus Torvalds
  2004-10-24  2:11           ` Buddy Lucas
  3 siblings, 0 replies; 243+ messages in thread
From: Gene Heskett @ 2004-10-23 10:11 UTC (permalink / raw)
  To: linux-kernel; +Cc: Jeff V. Merkey, jonathan, Linus Torvalds, bstowell, jcn

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:
>
>bstowell@sco.com
>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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
                                   ` (3 preceding siblings ...)
  2004-10-22 21:03                 ` Thomas Gleixner
@ 2004-10-23 12:33                 ` Bernd Petrovitsch
  2004-10-24 14:15                 ` Kai Henningsen
  2004-10-27  1:45                 ` Horst von Brand
  6 siblings, 0 replies; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-10-23 12:33 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

[ 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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-20 20:41     ` Geert Uytterhoeven
@ 2004-10-23 13:43       ` James Bruce
  0 siblings, 0 replies; 243+ messages in thread
From: James Bruce @ 2004-10-23 13:43 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Pekka Pietikainen, Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  4:42         ` Jeff V. Merkey
  2004-10-23  6:32           ` Nick Piggin
  2004-10-23 10:11           ` Gene Heskett
@ 2004-10-23 16:28           ` Linus Torvalds
  2004-10-24  2:48             ` Jesper Juhl
  2004-10-24  5:11             ` Jeff V. Merkey
  2004-10-24  2:11           ` Buddy Lucas
  3 siblings, 2 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-23 16:28 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: jonathan, Kernel Mailing List, bstowell, jcn



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23  4:42         ` Jeff V. Merkey
                             ` (2 preceding siblings ...)
  2004-10-23 16:28           ` Linus Torvalds
@ 2004-10-24  2:11           ` Buddy Lucas
  3 siblings, 0 replies; 243+ messages in thread
From: Buddy Lucas @ 2004-10-24  2:11 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: jonathan, Kernel Mailing List, bstowell, jcn

[ Removed Linus from the Cc list. ]

On Fri, 22 Oct 2004 22:42:30 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23 16:28           ` Linus Torvalds
@ 2004-10-24  2:48             ` Jesper Juhl
  2004-10-24  5:11             ` Jeff V. Merkey
  1 sibling, 0 replies; 243+ messages in thread
From: Jesper Juhl @ 2004-10-24  2:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Jeff V. Merkey, jonathan, Kernel Mailing List, bstowell, jcn

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*.



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-23 16:28           ` Linus Torvalds
  2004-10-24  2:48             ` Jesper Juhl
@ 2004-10-24  5:11             ` Jeff V. Merkey
  2004-10-24 11:14               ` Jon Masters
                                 ` (4 more replies)
  1 sibling, 5 replies; 243+ messages in thread
From: Jeff V. Merkey @ 2004-10-24  5:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List, bstowell

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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 16:15         ` Jeff V. Merkey
  2004-10-22 17:52           ` Al Viro
@ 2004-10-24 11:00           ` Matthias Andree
  2004-10-24 14:13           ` Kai Henningsen
  2 siblings, 0 replies; 243+ messages in thread
From: Matthias Andree @ 2004-10-24 11:00 UTC (permalink / raw)
  To: Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-24  5:11             ` Jeff V. Merkey
@ 2004-10-24 11:14               ` Jon Masters
  2004-10-24 11:50               ` Jim Nelson
                                 ` (3 subsequent siblings)
  4 siblings, 0 replies; 243+ messages in thread
From: Jon Masters @ 2004-10-24 11:14 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List, bstowell

On Sat, 23 Oct 2004 23:11:25 -0600, Jeff V. Merkey <jmerkey@drdos.com> 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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-24  5:11             ` Jeff V. Merkey
  2004-10-24 11:14               ` Jon Masters
@ 2004-10-24 11:50               ` Jim Nelson
  2004-10-24 15:35               ` Ingo Molnar
                                 ` (2 subsequent siblings)
  4 siblings, 0 replies; 243+ messages in thread
From: Jim Nelson @ 2004-10-24 11:50 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

<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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 16:15         ` Jeff V. Merkey
  2004-10-22 17:52           ` Al Viro
  2004-10-24 11:00           ` Matthias Andree
@ 2004-10-24 14:13           ` Kai Henningsen
  2004-10-25 18:44             ` Bill Davidsen
  2 siblings, 1 reply; 243+ messages in thread
From: Kai Henningsen @ 2004-10-24 14:13 UTC (permalink / raw)
  To: linux-kernel

jmerkey@drdos.com (Jeff V. Merkey)  wrote on 22.10.04 in <41793204.9090208@drdos.com>:

> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
                                   ` (4 preceding siblings ...)
  2004-10-23 12:33                 ` Bernd Petrovitsch
@ 2004-10-24 14:15                 ` Kai Henningsen
  2004-10-27  1:45                 ` Horst von Brand
  6 siblings, 0 replies; 243+ messages in thread
From: Kai Henningsen @ 2004-10-24 14:15 UTC (permalink / raw)
  To: linux-kernel

jmerkey@drdos.com (Jeff V. Merkey)  wrote on 22.10.04 in <41796178.7010006@drdos.com>:

> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-24  5:11             ` Jeff V. Merkey
  2004-10-24 11:14               ` Jon Masters
  2004-10-24 11:50               ` Jim Nelson
@ 2004-10-24 15:35               ` Ingo Molnar
  2004-10-24 15:53               ` Bernd Petrovitsch
  2004-10-31 23:14               ` Jan 'JaSan' Sarenik
  4 siblings, 0 replies; 243+ messages in thread
From: Ingo Molnar @ 2004-10-24 15:35 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Linus Torvalds, Kernel Mailing List, bstowell


* Jeff V. Merkey <jmerkey@drdos.com> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-24  5:11             ` Jeff V. Merkey
                                 ` (2 preceding siblings ...)
  2004-10-24 15:35               ` Ingo Molnar
@ 2004-10-24 15:53               ` Bernd Petrovitsch
  2004-10-31 23:14               ` Jan 'JaSan' Sarenik
  4 siblings, 0 replies; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-10-24 15:53 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: Kernel Mailing List

[ 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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-24 14:13           ` Kai Henningsen
@ 2004-10-25 18:44             ` Bill Davidsen
  0 siblings, 0 replies; 243+ messages in thread
From: Bill Davidsen @ 2004-10-25 18:44 UTC (permalink / raw)
  To: Kai Henningsen; +Cc: linux-kernel

Kai Henningsen wrote:
> jmerkey@drdos.com (Jeff V. Merkey)  wrote on 22.10.04 in <41793204.9090208@drdos.com>:
> 
> 
>>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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-22 19:37               ` Jeff V. Merkey
                                   ` (5 preceding siblings ...)
  2004-10-24 14:15                 ` Kai Henningsen
@ 2004-10-27  1:45                 ` Horst von Brand
  6 siblings, 0 replies; 243+ messages in thread
From: Horst von Brand @ 2004-10-27  1:45 UTC (permalink / raw)
  To: Jeff V. Merkey
  Cc: Al Viro, David Weinehall, Dax Kelson, Linus Torvalds,
	Kernel Mailing List

"Jeff V. Merkey" <jmerkey@drdos.com> said:
> 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.

It is extremely weird that they send this to you, but are totally unable to
show same to the judge and IBM. Did they also send over the exact basis for
the claims on each of the pieces of code by any chance?

SCOX has ownership interest only over some snippets of code they explicitly
contributed to Linux under GPL while they called themselves Caldera.
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Semaphore assembly-code bug
  2004-10-20 11:49             ` Richard B. Johnson
@ 2004-10-29 12:12               ` linux-os
  2004-10-29 14:46                 ` Linus Torvalds
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-10-29 12:12 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List


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 <Aleksey_Gorelov@Phoenix.com>.

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 12:12               ` Semaphore assembly-code bug linux-os
@ 2004-10-29 14:46                 ` Linus Torvalds
  2004-10-29 15:11                   ` Andi Kleen
                                     ` (4 more replies)
  0 siblings, 5 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 14:46 UTC (permalink / raw)
  To: linux-os
  Cc: Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka



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 <Aleksey_Gorelov@Phoenix.com>.
> 
> 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.
> 

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 14:46                 ` Linus Torvalds
@ 2004-10-29 15:11                   ` Andi Kleen
  2004-10-29 18:18                     ` Linus Torvalds
  2004-10-29 16:06                   ` Andreas Steinmetz
                                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 243+ messages in thread
From: Andi Kleen @ 2004-10-29 15:11 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andrew Morton,
	Jan Hubicka

> 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


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 14:46                 ` Linus Torvalds
  2004-10-29 15:11                   ` Andi Kleen
@ 2004-10-29 16:06                   ` Andreas Steinmetz
  2004-10-29 17:08                     ` linux-os
  2004-10-29 17:22                   ` linux-os
                                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 243+ messages in thread
From: Andreas Steinmetz @ 2004-10-29 16:06 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

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 robotrap@domdv.de

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 16:06                   ` Andreas Steinmetz
@ 2004-10-29 17:08                     ` linux-os
  2004-10-29 18:06                       ` Linus Torvalds
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-10-29 17:08 UTC (permalink / raw)
  To: Andreas Steinmetz
  Cc: Linus Torvalds, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka

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 robotrap@domdv.de
>

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 14:46                 ` Linus Torvalds
  2004-10-29 15:11                   ` Andi Kleen
  2004-10-29 16:06                   ` Andreas Steinmetz
@ 2004-10-29 17:22                   ` linux-os
  2004-10-29 17:55                     ` Richard Henderson
  2004-10-29 19:20                     ` Linus Torvalds
  2004-10-29 17:57                   ` Richard Henderson
  2004-10-29 18:37                   ` Gabriel Paubert
  4 siblings, 2 replies; 243+ messages in thread
From: linux-os @ 2004-10-29 17:22 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 17:22                   ` linux-os
@ 2004-10-29 17:55                     ` Richard Henderson
  2004-10-29 18:17                       ` linux-os
  2004-10-29 19:20                     ` Linus Torvalds
  1 sibling, 1 reply; 243+ messages in thread
From: Richard Henderson @ 2004-10-29 17:55 UTC (permalink / raw)
  To: linux-os
  Cc: Linus Torvalds, Kernel Mailing List, Andi Kleen, Andrew Morton,
	Jan Hubicka

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~

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 14:46                 ` Linus Torvalds
                                     ` (2 preceding siblings ...)
  2004-10-29 17:22                   ` linux-os
@ 2004-10-29 17:57                   ` Richard Henderson
  2004-10-29 18:37                   ` Gabriel Paubert
  4 siblings, 0 replies; 243+ messages in thread
From: Richard Henderson @ 2004-10-29 17:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Kernel Mailing List, Andi Kleen, Andrew Morton, Jan Hubicka

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~

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 17:08                     ` linux-os
@ 2004-10-29 18:06                       ` Linus Torvalds
  2004-10-29 18:39                         ` linux-os
                                           ` (2 more replies)
  0 siblings, 3 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 18:06 UTC (permalink / raw)
  To: linux-os
  Cc: Andreas Steinmetz, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 17:55                     ` Richard Henderson
@ 2004-10-29 18:17                       ` linux-os
  2004-10-29 18:42                         ` Linus Torvalds
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-10-29 18:17 UTC (permalink / raw)
  To: Richard Henderson
  Cc: Linus Torvalds, Kernel Mailing List, Andi Kleen, Andrew Morton,
	Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 15:11                   ` Andi Kleen
@ 2004-10-29 18:18                     ` Linus Torvalds
  2004-10-29 18:35                       ` Richard Henderson
  0 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 18:18 UTC (permalink / raw)
  To: Andi Kleen
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andrew Morton,
	Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:18                     ` Linus Torvalds
@ 2004-10-29 18:35                       ` Richard Henderson
  0 siblings, 0 replies; 243+ messages in thread
From: Richard Henderson @ 2004-10-29 18:35 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andi Kleen, linux-os, Kernel Mailing List, Andrew Morton, Jan Hubicka

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~

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 14:46                 ` Linus Torvalds
                                     ` (3 preceding siblings ...)
  2004-10-29 17:57                   ` Richard Henderson
@ 2004-10-29 18:37                   ` Gabriel Paubert
  4 siblings, 0 replies; 243+ messages in thread
From: Gabriel Paubert @ 2004-10-29 18:37 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

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.


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:06                       ` Linus Torvalds
@ 2004-10-29 18:39                         ` linux-os
  2004-10-29 19:12                           ` Linus Torvalds
  2004-10-29 18:58                         ` Andreas Steinmetz
  2004-10-29 23:37                         ` dean gaudet
  2 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-10-29 18:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andreas Steinmetz, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:17                       ` linux-os
@ 2004-10-29 18:42                         ` Linus Torvalds
  2004-10-29 18:54                           ` Linus Torvalds
  2004-10-30  3:35                           ` Jeff Garzik
  0 siblings, 2 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 18:42 UTC (permalink / raw)
  To: linux-os
  Cc: Richard Henderson, Kernel Mailing List, Andi Kleen,
	Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:42                         ` Linus Torvalds
@ 2004-10-29 18:54                           ` Linus Torvalds
  2004-10-30  3:35                           ` Jeff Garzik
  1 sibling, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 18:54 UTC (permalink / raw)
  To: linux-os
  Cc: Richard Henderson, Kernel Mailing List, Andi Kleen,
	Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:06                       ` Linus Torvalds
  2004-10-29 18:39                         ` linux-os
@ 2004-10-29 18:58                         ` Andreas Steinmetz
  2004-10-29 19:15                           ` Linus Torvalds
  2004-10-29 23:37                         ` dean gaudet
  2 siblings, 1 reply; 243+ messages in thread
From: Andreas Steinmetz @ 2004-10-29 18:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

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 robotrap@domdv.de

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:39                         ` linux-os
@ 2004-10-29 19:12                           ` Linus Torvalds
  2004-11-01  1:31                             ` linux-os
  0 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 19:12 UTC (permalink / raw)
  To: linux-os
  Cc: Andreas Steinmetz, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:58                         ` Andreas Steinmetz
@ 2004-10-29 19:15                           ` Linus Torvalds
  2004-10-29 19:40                             ` Andreas Steinmetz
  0 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 19:15 UTC (permalink / raw)
  To: Andreas Steinmetz
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 17:22                   ` linux-os
  2004-10-29 17:55                     ` Richard Henderson
@ 2004-10-29 19:20                     ` Linus Torvalds
  2004-10-29 19:26                       ` Linus Torvalds
  2004-10-29 21:03                       ` Linus Torvalds
  1 sibling, 2 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 19:20 UTC (permalink / raw)
  To: linux-os
  Cc: Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka



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"

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:20                     ` Linus Torvalds
@ 2004-10-29 19:26                       ` Linus Torvalds
  2004-10-29 21:03                       ` Linus Torvalds
  1 sibling, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 19:26 UTC (permalink / raw)
  To: linux-os
  Cc: Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:15                           ` Linus Torvalds
@ 2004-10-29 19:40                             ` Andreas Steinmetz
  2004-10-29 19:56                               ` Linus Torvalds
  2004-10-29 23:50                               ` dean gaudet
  0 siblings, 2 replies; 243+ messages in thread
From: Andreas Steinmetz @ 2004-10-29 19:40 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

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 robotrap@domdv.de

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:40                             ` Andreas Steinmetz
@ 2004-10-29 19:56                               ` Linus Torvalds
  2004-10-29 22:07                                 ` Jeff Garzik
  2004-10-29 23:50                               ` dean gaudet
  1 sibling, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 19:56 UTC (permalink / raw)
  To: Andreas Steinmetz
  Cc: linux-os, Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:20                     ` Linus Torvalds
  2004-10-29 19:26                       ` Linus Torvalds
@ 2004-10-29 21:03                       ` Linus Torvalds
  1 sibling, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-29 21:03 UTC (permalink / raw)
  To: linux-os
  Cc: Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:56                               ` Linus Torvalds
@ 2004-10-29 22:07                                 ` Jeff Garzik
  0 siblings, 0 replies; 243+ messages in thread
From: Jeff Garzik @ 2004-10-29 22:07 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andreas Steinmetz, linux-os, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:06                       ` Linus Torvalds
  2004-10-29 18:39                         ` linux-os
  2004-10-29 18:58                         ` Andreas Steinmetz
@ 2004-10-29 23:37                         ` dean gaudet
  2 siblings, 0 replies; 243+ messages in thread
From: dean gaudet @ 2004-10-29 23:37 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:40                             ` Andreas Steinmetz
  2004-10-29 19:56                               ` Linus Torvalds
@ 2004-10-29 23:50                               ` dean gaudet
  2004-10-30  0:15                                 ` Linus Torvalds
  1 sibling, 1 reply; 243+ messages in thread
From: dean gaudet @ 2004-10-29 23:50 UTC (permalink / raw)
  To: Andreas Steinmetz
  Cc: Linus Torvalds, linux-os, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 23:50                               ` dean gaudet
@ 2004-10-30  0:15                                 ` Linus Torvalds
  0 siblings, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-10-30  0:15 UTC (permalink / raw)
  To: dean gaudet
  Cc: Andreas Steinmetz, linux-os, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 18:42                         ` Linus Torvalds
  2004-10-29 18:54                           ` Linus Torvalds
@ 2004-10-30  3:35                           ` Jeff Garzik
  1 sibling, 0 replies; 243+ messages in thread
From: Jeff Garzik @ 2004-10-30  3:35 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, Richard Henderson, Kernel Mailing List, Andi Kleen,
	Andrew Morton, Jan Hubicka

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



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 dies when starting X on radeon 9200 SE PCI
  2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
                   ` (4 preceding siblings ...)
  2004-10-21  2:41 ` Linux v2.6.9 (Strange tty problem?) Paul
@ 2004-10-31 21:11 ` Helge Hafting
  5 siblings, 0 replies; 243+ messages in thread
From: Helge Hafting @ 2004-10-31 21:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux v2.6.9 and GPL Buyout
  2004-10-24  5:11             ` Jeff V. Merkey
                                 ` (3 preceding siblings ...)
  2004-10-24 15:53               ` Bernd Petrovitsch
@ 2004-10-31 23:14               ` Jan 'JaSan' Sarenik
  4 siblings, 0 replies; 243+ messages in thread
From: Jan 'JaSan' Sarenik @ 2004-10-31 23:14 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: linux-kernel

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!

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-10-29 19:12                           ` Linus Torvalds
@ 2004-11-01  1:31                             ` linux-os
  2004-11-01  5:49                               ` Linus Torvalds
  2004-11-01 20:23                               ` dean gaudet
  0 siblings, 2 replies; 243+ messages in thread
From: linux-os @ 2004-11-01  1:31 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andreas Steinmetz, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2280 bytes --]

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.

[-- Attachment #2: Type: APPLICATION/x-gzip, Size: 6806 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01  1:31                             ` linux-os
@ 2004-11-01  5:49                               ` Linus Torvalds
  2004-11-01 20:23                               ` dean gaudet
  1 sibling, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-11-01  5:49 UTC (permalink / raw)
  To: linux-os
  Cc: Andreas Steinmetz, Kernel Mailing List, Richard Henderson,
	Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01  1:31                             ` linux-os
  2004-11-01  5:49                               ` Linus Torvalds
@ 2004-11-01 20:23                               ` dean gaudet
  2004-11-01 20:52                                 ` linux-os
  1 sibling, 1 reply; 243+ messages in thread
From: dean gaudet @ 2004-11-01 20:23 UTC (permalink / raw)
  To: linux-os
  Cc: Linus Torvalds, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

[-- Attachment #1: Type: TEXT/PLAIN, Size: 757 bytes --]

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

[-- Attachment #2: Type: APPLICATION/X-GZIP, Size: 6806 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 20:23                               ` dean gaudet
@ 2004-11-01 20:52                                 ` linux-os
  2004-11-01 21:23                                   ` dean gaudet
  2004-11-01 21:40                                   ` Linus Torvalds
  0 siblings, 2 replies; 243+ messages in thread
From: linux-os @ 2004-11-01 20:52 UTC (permalink / raw)
  To: dean gaudet
  Cc: Linus Torvalds, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 20:52                                 ` linux-os
@ 2004-11-01 21:23                                   ` dean gaudet
  2004-11-01 22:22                                     ` linux-os
  2004-11-01 21:40                                   ` Linus Torvalds
  1 sibling, 1 reply; 243+ messages in thread
From: dean gaudet @ 2004-11-01 21:23 UTC (permalink / raw)
  To: linux-os
  Cc: Linus Torvalds, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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;
}

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 20:52                                 ` linux-os
  2004-11-01 21:23                                   ` dean gaudet
@ 2004-11-01 21:40                                   ` Linus Torvalds
  2004-11-01 21:46                                     ` Linus Torvalds
                                                       ` (2 more replies)
  1 sibling, 3 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-11-01 21:40 UTC (permalink / raw)
  To: linux-os
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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);
}


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 21:40                                   ` Linus Torvalds
@ 2004-11-01 21:46                                     ` Linus Torvalds
  2004-11-02 15:02                                       ` linux-os
  2004-11-01 22:16                                     ` linux-os
  2004-11-02  6:37                                     ` Chris Friesen
  2 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-11-01 21:46 UTC (permalink / raw)
  To: linux-os
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 21:40                                   ` Linus Torvalds
  2004-11-01 21:46                                     ` Linus Torvalds
@ 2004-11-01 22:16                                     ` linux-os
  2004-11-01 22:26                                       ` Linus Torvalds
                                                         ` (2 more replies)
  2004-11-02  6:37                                     ` Chris Friesen
  2 siblings, 3 replies; 243+ messages in thread
From: linux-os @ 2004-11-01 22:16 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 21:23                                   ` dean gaudet
@ 2004-11-01 22:22                                     ` linux-os
  0 siblings, 0 replies; 243+ messages in thread
From: linux-os @ 2004-11-01 22:22 UTC (permalink / raw)
  To: dean gaudet
  Cc: Linus Torvalds, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 22:16                                     ` linux-os
@ 2004-11-01 22:26                                       ` Linus Torvalds
  2004-11-01 23:14                                         ` linux-os
  2004-11-03  1:52                                       ` Horst von Brand
  2004-11-03 21:24                                       ` Bill Davidsen
  2 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-11-01 22:26 UTC (permalink / raw)
  To: linux-os
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 22:26                                       ` Linus Torvalds
@ 2004-11-01 23:14                                         ` linux-os
  2004-11-01 23:42                                           ` Linus Torvalds
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-11-01 23:14 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 23:14                                         ` linux-os
@ 2004-11-01 23:42                                           ` Linus Torvalds
  0 siblings, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2004-11-01 23:42 UTC (permalink / raw)
  To: linux-os
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 21:40                                   ` Linus Torvalds
  2004-11-01 21:46                                     ` Linus Torvalds
  2004-11-01 22:16                                     ` linux-os
@ 2004-11-02  6:37                                     ` Chris Friesen
  2 siblings, 0 replies; 243+ messages in thread
From: Chris Friesen @ 2004-11-02  6:37 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-os, dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 21:46                                     ` Linus Torvalds
@ 2004-11-02 15:02                                       ` linux-os
  2004-11-02 16:02                                         ` Linus Torvalds
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-11-02 15:02 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka


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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-02 15:02                                       ` linux-os
@ 2004-11-02 16:02                                         ` Linus Torvalds
  2004-11-02 16:06                                           ` Linus Torvalds
  0 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-11-02 16:02 UTC (permalink / raw)
  To: linux-os
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-02 16:02                                         ` Linus Torvalds
@ 2004-11-02 16:06                                           ` Linus Torvalds
  2004-11-02 16:51                                             ` linux-os
  0 siblings, 1 reply; 243+ messages in thread
From: Linus Torvalds @ 2004-11-02 16:06 UTC (permalink / raw)
  To: linux-os
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka



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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-02 16:06                                           ` Linus Torvalds
@ 2004-11-02 16:51                                             ` linux-os
  0 siblings, 0 replies; 243+ messages in thread
From: linux-os @ 2004-11-02 16:51 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: dean gaudet, Andreas Steinmetz, Kernel Mailing List,
	Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 22:16                                     ` linux-os
  2004-11-01 22:26                                       ` Linus Torvalds
@ 2004-11-03  1:52                                       ` Horst von Brand
  2004-11-03 21:24                                       ` Bill Davidsen
  2 siblings, 0 replies; 243+ messages in thread
From: Horst von Brand @ 2004-11-03  1:52 UTC (permalink / raw)
  To: linux-os
  Cc: Linus Torvalds, dean gaudet, Andreas Steinmetz,
	Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

linux-os <linux-os@chaos.analogic.com> 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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Semaphore assembly-code bug
  2004-11-01 22:16                                     ` linux-os
  2004-11-01 22:26                                       ` Linus Torvalds
  2004-11-03  1:52                                       ` Horst von Brand
@ 2004-11-03 21:24                                       ` Bill Davidsen
  2 siblings, 0 replies; 243+ messages in thread
From: Bill Davidsen @ 2004-11-03 21:24 UTC (permalink / raw)
  To: linux-os
  Cc: Linus Torvalds, dean gaudet, Andreas Steinmetz,
	Kernel Mailing List, Richard Henderson, Andi Kleen,
	Andrew Morton, Jan Hubicka

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Linux-2.6.9 won't allow a write to a NTFS file-system.
@ 2004-11-04 16:01 linux-os
  2004-11-04 16:48 ` Giuseppe Bilotta
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-11-04 16:01 UTC (permalink / raw)
  To: Linux kernel


Hello anybody maintaining NTFS,

I can't write to a NTFS file-system.

/proc/mounts shows it's mounted RW:
/dev/sdd1 /mnt ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1 0 0

.config shows RW support.

CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

Errno is 1 (Operation not permitted), even though root.


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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 16:01 Linux-2.6.9 won't allow a write to a NTFS file-system linux-os
@ 2004-11-04 16:48 ` Giuseppe Bilotta
  2004-11-04 17:09   ` linux-os
  0 siblings, 1 reply; 243+ messages in thread
From: Giuseppe Bilotta @ 2004-11-04 16:48 UTC (permalink / raw)
  To: linux-kernel

linux-os wrote:
> 
> Hello anybody maintaining NTFS,
> 
> I can't write to a NTFS file-system.
> 
> /proc/mounts shows it's mounted RW:
> /dev/sdd1 /mnt ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1 0 0
> 
> .config shows RW support.
> 
> CONFIG_NTFS_FS=m
> # CONFIG_NTFS_DEBUG is not set
> CONFIG_NTFS_RW=y
> 
> Errno is 1 (Operation not permitted), even though root.

What are trying to write? AFAIK, the (new) NTFS module only 
allows one kind of writing: overwriting an existing file, as 
long as its size doesn't change.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 16:48 ` Giuseppe Bilotta
@ 2004-11-04 17:09   ` linux-os
  2004-11-04 17:40     ` Giuseppe Bilotta
                       ` (3 more replies)
  0 siblings, 4 replies; 243+ messages in thread
From: linux-os @ 2004-11-04 17:09 UTC (permalink / raw)
  To: Giuseppe Bilotta; +Cc: linux-kernel

On Thu, 4 Nov 2004, Giuseppe Bilotta wrote:

> linux-os wrote:
>>
>> Hello anybody maintaining NTFS,
>>
>> I can't write to a NTFS file-system.
>>
>> /proc/mounts shows it's mounted RW:
>> /dev/sdd1 /mnt ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1 0 0
>>
>> .config shows RW support.
>>
>> CONFIG_NTFS_FS=m
>> # CONFIG_NTFS_DEBUG is not set
>> CONFIG_NTFS_RW=y
>>
>> Errno is 1 (Operation not permitted), even though root.
>
> What are trying to write? AFAIK, the (new) NTFS module only
> allows one kind of writing: overwriting an existing file, as
> long as its size doesn't change.
>
> -- 
> Giuseppe "Oblomov" Bilotta
>

Huh? Are we talking about the same thing? I'm talking about
the NTFS that Windows/NT and later versions puts on its
file-systems. I use an USB external disk with my M$ Laptop
and I have always been able to transfer data to/from
my machines using that drive. Now I can't. The drive it
writable under M$, but I can't even delete anything
(no permission for root) under Linux.

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 17:09   ` linux-os
@ 2004-11-04 17:40     ` Giuseppe Bilotta
  2004-11-04 17:46     ` Mathieu Segaud
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 243+ messages in thread
From: Giuseppe Bilotta @ 2004-11-04 17:40 UTC (permalink / raw)
  To: linux-kernel

linux-os wrote:
> On Thu, 4 Nov 2004, Giuseppe Bilotta wrote:
> 
> > linux-os wrote:
> >>
> >> Hello anybody maintaining NTFS,
> >>
> >> I can't write to a NTFS file-system.
> >>
> >> /proc/mounts shows it's mounted RW:
> >> /dev/sdd1 /mnt ntfs rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1 0 0
> >>
> >> .config shows RW support.
> >>
> >> CONFIG_NTFS_FS=m
> >> # CONFIG_NTFS_DEBUG is not set
> >> CONFIG_NTFS_RW=y
> >>
> >> Errno is 1 (Operation not permitted), even though root.
> >
> > What are trying to write? AFAIK, the (new) NTFS module only
> > allows one kind of writing: overwriting an existing file, as
> > long as its size doesn't change.
> 
> Huh? Are we talking about the same thing? I'm talking about
> the NTFS that Windows/NT and later versions puts on its
> file-systems.

So am I.

> I use an USB external disk with my M$ Laptop
> and I have always been able to transfer data to/from
> my machines using that drive. Now I can't. The drive it
> writable under M$, but I can't even delete anything
> (no permission for root) under Linux.

http://linux-ntfs.sourceforge.net/info/ntfs.html#3.2

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 17:09   ` linux-os
  2004-11-04 17:40     ` Giuseppe Bilotta
@ 2004-11-04 17:46     ` Mathieu Segaud
  2004-11-04 22:17     ` Anton Altaparmakov
  2004-11-05  1:46     ` Horst von Brand
  3 siblings, 0 replies; 243+ messages in thread
From: Mathieu Segaud @ 2004-11-04 17:46 UTC (permalink / raw)
  To: linux-os; +Cc: Giuseppe Bilotta, linux-kernel

linux-os <linux-os@chaos.analogic.com> disait dernièrement que :

> On Thu, 4 Nov 2004, Giuseppe Bilotta wrote:
>

> Huh? Are we talking about the same thing?

yes

> I'm talking about
> the NTFS that Windows/NT and later versions puts on its
> file-systems. I use an USB external disk with my M$ Laptop
> and I have always been able to transfer data to/from
> my machines using that drive. Now I can't. The drive it
> writable under M$, but I can't even delete anything
> (no permission for root) under Linux.

Taken from kernel help in *config:
"The only supported operation is overwriting existing files, without changing
the file length. No file or directory creation, deletion or renaming is
possible..."

Best,

Mathieu

-- 
<WeirdArms> erikm: bugger alan cox on a chip, I want alan cox in a book ;)

	- Adam Wiggins on #kernelnewbies


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 17:09   ` linux-os
  2004-11-04 17:40     ` Giuseppe Bilotta
  2004-11-04 17:46     ` Mathieu Segaud
@ 2004-11-04 22:17     ` Anton Altaparmakov
  2004-11-04 22:18       ` Anton Altaparmakov
  2004-11-04 22:38       ` linux-os
  2004-11-05  1:46     ` Horst von Brand
  3 siblings, 2 replies; 243+ messages in thread
From: Anton Altaparmakov @ 2004-11-04 22:17 UTC (permalink / raw)
  To: linux-os; +Cc: Giuseppe Bilotta, linux-kernel

On Thu, 4 Nov 2004, linux-os wrote:
> On Thu, 4 Nov 2004, Giuseppe Bilotta wrote:
> > linux-os wrote:
> > > 
> > > Hello anybody maintaining NTFS,
> > > 
> > > I can't write to a NTFS file-system.
> > > 
> > > /proc/mounts shows it's mounted RW:
> > > /dev/sdd1 /mnt ntfs
> > > rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1
> > > 0 0
> > > 
> > > .config shows RW support.
> > > 
> > > CONFIG_NTFS_FS=m
> > > # CONFIG_NTFS_DEBUG is not set
> > > CONFIG_NTFS_RW=y
> > > 
> > > Errno is 1 (Operation not permitted), even though root.
> > 
> > What are trying to write? AFAIK, the (new) NTFS module only
> > allows one kind of writing: overwriting an existing file, as
> > long as its size doesn't change.
> 
> Huh? Are we talking about the same thing? I'm talking about
> the NTFS that Windows/NT and later versions puts on its
> file-systems. I use an USB external disk with my M$ Laptop
> and I have always been able to transfer data to/from
> my machines using that drive. Now I can't. The drive it
> writable under M$, but I can't even delete anything
> (no permission for root) under Linux.

You must have had it formatted as VFAT in the past.  There is now way you 
were writing to an NTFS drive from Linux (unless you were using Captive 
NTFS or one of the commercially available drivers).

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 22:17     ` Anton Altaparmakov
@ 2004-11-04 22:18       ` Anton Altaparmakov
  2004-11-04 22:38       ` linux-os
  1 sibling, 0 replies; 243+ messages in thread
From: Anton Altaparmakov @ 2004-11-04 22:18 UTC (permalink / raw)
  To: linux-os; +Cc: Giuseppe Bilotta, linux-kernel

On Thu, 4 Nov 2004, Anton Altaparmakov wrote:

> On Thu, 4 Nov 2004, linux-os wrote:
> > On Thu, 4 Nov 2004, Giuseppe Bilotta wrote:
> > > linux-os wrote:
> > > > 
> > > > Hello anybody maintaining NTFS,
> > > > 
> > > > I can't write to a NTFS file-system.
> > > > 
> > > > /proc/mounts shows it's mounted RW:
> > > > /dev/sdd1 /mnt ntfs
> > > > rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1
> > > > 0 0
> > > > 
> > > > .config shows RW support.
> > > > 
> > > > CONFIG_NTFS_FS=m
> > > > # CONFIG_NTFS_DEBUG is not set
> > > > CONFIG_NTFS_RW=y
> > > > 
> > > > Errno is 1 (Operation not permitted), even though root.
> > > 
> > > What are trying to write? AFAIK, the (new) NTFS module only
> > > allows one kind of writing: overwriting an existing file, as
> > > long as its size doesn't change.
> > 
> > Huh? Are we talking about the same thing? I'm talking about
> > the NTFS that Windows/NT and later versions puts on its
> > file-systems. I use an USB external disk with my M$ Laptop
> > and I have always been able to transfer data to/from
> > my machines using that drive. Now I can't. The drive it
> > writable under M$, but I can't even delete anything
> > (no permission for root) under Linux.
> 
> You must have had it formatted as VFAT in the past.  There is now way you 

s/now/no/

> were writing to an NTFS drive from Linux (unless you were using Captive 
> NTFS or one of the commercially available drivers).
> 
> Best regards,
> 
> 	Anton
> 

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 22:17     ` Anton Altaparmakov
  2004-11-04 22:18       ` Anton Altaparmakov
@ 2004-11-04 22:38       ` linux-os
  2004-11-05 14:43         ` Rahul Karnik
  1 sibling, 1 reply; 243+ messages in thread
From: linux-os @ 2004-11-04 22:38 UTC (permalink / raw)
  To: Anton Altaparmakov; +Cc: Giuseppe Bilotta, Linux kernel

On Thu, 4 Nov 2004, Anton Altaparmakov wrote:

> On Thu, 4 Nov 2004, linux-os wrote:
>> On Thu, 4 Nov 2004, Giuseppe Bilotta wrote:
>>> linux-os wrote:
>>>>
>>>> Hello anybody maintaining NTFS,
>>>>
>>>> I can't write to a NTFS file-system.
>>>>
>>>> /proc/mounts shows it's mounted RW:
>>>> /dev/sdd1 /mnt ntfs
>>>> rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1
>>>> 0 0
>>>>
>>>> .config shows RW support.
>>>>
>>>> CONFIG_NTFS_FS=m
>>>> # CONFIG_NTFS_DEBUG is not set
>>>> CONFIG_NTFS_RW=y
>>>>
>>>> Errno is 1 (Operation not permitted), even though root.
>>>
>>> What are trying to write? AFAIK, the (new) NTFS module only
>>> allows one kind of writing: overwriting an existing file, as
>>> long as its size doesn't change.
>>
>> Huh? Are we talking about the same thing? I'm talking about
>> the NTFS that Windows/NT and later versions puts on its
>> file-systems. I use an USB external disk with my M$ Laptop
>> and I have always been able to transfer data to/from
>> my machines using that drive. Now I can't. The drive it
>> writable under M$, but I can't even delete anything
>> (no permission for root) under Linux.
>
> You must have had it formatted as VFAT in the past.  There is now way you
> were writing to an NTFS drive from Linux (unless you were using Captive
> NTFS or one of the commercially available drivers).
>
> Best regards,
>
> 	Anton

I thought maybe that was so, so I tried to format it as a
FAT-32 drive and W$ complained that it was too large. So
I thought, I would just partition it, but I never partitioned
it to two logical drives before before so I don't know
what's changed (it's W/2000). Right now, I am partitioning
it to two slices and formatting it with FAT-32.

I've been using this since linux had USB and Firewire
controllers. I really don't know what has changed.

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 17:09   ` linux-os
                       ` (2 preceding siblings ...)
  2004-11-04 22:17     ` Anton Altaparmakov
@ 2004-11-05  1:46     ` Horst von Brand
  2004-11-05 12:41       ` linux-os
  3 siblings, 1 reply; 243+ messages in thread
From: Horst von Brand @ 2004-11-05  1:46 UTC (permalink / raw)
  To: linux-os; +Cc: Giuseppe Bilotta, linux-kernel

linux-os <linux-os@chaos.analogic.com> said:

[...]

> Huh? Are we talking about the same thing? I'm talking about
> the NTFS that Windows/NT and later versions puts on its
> file-systems. I use an USB external disk with my M$ Laptop
> and I have always been able to transfer data to/from
> my machines using that drive. Now I can't. The drive it
> writable under M$, but I can't even delete anything
> (no permission for root) under Linux.

Looks like you reformated from the original VFAT (== Win9x) to NTFS.
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-05  1:46     ` Horst von Brand
@ 2004-11-05 12:41       ` linux-os
  0 siblings, 0 replies; 243+ messages in thread
From: linux-os @ 2004-11-05 12:41 UTC (permalink / raw)
  To: Horst von Brand; +Cc: Giuseppe Bilotta, Linux kernel

On Thu, 4 Nov 2004, Horst von Brand wrote:

> linux-os <linux-os@chaos.analogic.com> said:
>
> [...]
>
>> Huh? Are we talking about the same thing? I'm talking about
>> the NTFS that Windows/NT and later versions puts on its
>> file-systems. I use an USB external disk with my M$ Laptop
>> and I have always been able to transfer data to/from
>> my machines using that drive. Now I can't. The drive it
>> writable under M$, but I can't even delete anything
>> (no permission for root) under Linux.
>
> Looks like you reformated from the original VFAT (== Win9x) to NTFS.
> -- 
> 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
>

The plot thickens. My 2.4.x system had the ntfs.sys adapter module.
I just re-partitioned and re-formatted the drive to FAT-32.

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: Linux-2.6.9 won't allow a write to a NTFS file-system.
  2004-11-04 22:38       ` linux-os
@ 2004-11-05 14:43         ` Rahul Karnik
  0 siblings, 0 replies; 243+ messages in thread
From: Rahul Karnik @ 2004-11-05 14:43 UTC (permalink / raw)
  To: linux-os; +Cc: Anton Altaparmakov, Giuseppe Bilotta, Linux kernel

On Thu, 4 Nov 2004 17:38:53 -0500 (EST), linux-os
<linux-os@chaos.analogic.com> wrote:
> I thought maybe that was so, so I tried to format it as a
> FAT-32 drive and W$ complained that it was too large. So
> I thought, I would just partition it, but I never partitioned
> it to two logical drives before before so I don't know
> what's changed (it's W/2000). Right now, I am partitioning
> it to two slices and formatting it with FAT-32.

Note that mkfs.vfat will format up to the maximum size allowed by the
FAT32 spec, rather than the 32 GB limit imposed by Windows. I am using
a 120 GB VFAT partition to share data between Windows and Linux.

Thanks,
Rahul

^ permalink raw reply	[flat|nested] 243+ messages in thread

* What if?
@ 2004-12-02  0:04 Imanpreet Singh Arora
  2004-12-02  4:40 ` Theodore Ts'o
                   ` (3 more replies)
  0 siblings, 4 replies; 243+ messages in thread
From: Imanpreet Singh Arora @ 2004-12-02  0:04 UTC (permalink / raw)
  To: lkml - Kernel Mailing List


Hi All,
   
    Firstly I have read the FAQ. So though FAQ answers my question, it 
does so only partially.


    "What if Linux were to be implemented in C++?"


    I realize most of the unhappiness lies with C++ compilers being 
slow. Also the fact that a lot of Hackers around here are a lot more 
familiar with C, rather than C++. However other than that what are the  
_implementation_  issues that you hackers might need to consider if it 
were to be implemented in C++. My question is regarding how will kernel 
deal with C++ doing too much behind the back, Calling constructors, 
templates exceptions and other. What are the possible issues of such an 
approach while writing device drivers?  What sort of modifications do 
you reckon might be needed if such a move were to be made?




-- 
Imanpreet Singh Arora

Even if you are on the right track you are going to get runover if you just sit there.
	-- Will Rogers


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  0:04 What if? Imanpreet Singh Arora
@ 2004-12-02  4:40 ` Theodore Ts'o
  2004-12-02  6:39   ` Norbert van Nobelen
                     ` (2 more replies)
  2004-12-02 10:25 ` Jan Engelhardt
                   ` (2 subsequent siblings)
  3 siblings, 3 replies; 243+ messages in thread
From: Theodore Ts'o @ 2004-12-02  4:40 UTC (permalink / raw)
  To: Imanpreet Singh Arora; +Cc: lkml - Kernel Mailing List

On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> 
>    I realize most of the unhappiness lies with C++ compilers being 
> slow. Also the fact that a lot of Hackers around here are a lot more 
> familiar with C, rather than C++. However other than that what are the  
> _implementation_  issues that you hackers might need to consider if it 
> were to be implemented in C++. 

The suckitude of C++ compilers is only part of the issues.

> My question is regarding how will kernel 
> deal with C++ doing too much behind the back, Calling constructors, 
> templates exceptions and other. What are the possible issues of such an 
> approach while writing device drivers?  What sort of modifications do 
> you reckon might be needed if such a move were to be made?

The way the kernel will deal with C++ language being a complete
disaster (where something as simple as "a = b + c + d +e" could
involve a dozen or more memory allocations, implicit type conversions,
and overloaded operators) is to not use it.  Think about the words of
wisdom from the movie Wargames: "The only way to win is not to play
the game".

					- Ted

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  4:40 ` Theodore Ts'o
@ 2004-12-02  6:39   ` Norbert van Nobelen
  2004-12-02  8:24   ` James Bruce
  2004-12-02  8:33   ` J.A. Magallon
  2 siblings, 0 replies; 243+ messages in thread
From: Norbert van Nobelen @ 2004-12-02  6:39 UTC (permalink / raw)
  To: lkml - Kernel Mailing List

On Thursday 02 December 2004 05:40, Theodore Ts'o wrote:
> On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> >    I realize most of the unhappiness lies with C++ compilers being
> > slow. Also the fact that a lot of Hackers around here are a lot more
> > familiar with C, rather than C++. However other than that what are the
> > _implementation_  issues that you hackers might need to consider if it
> > were to be implemented in C++.
>
> The suckitude of C++ compilers is only part of the issues.
>
> > My question is regarding how will kernel
> > deal with C++ doing too much behind the back, Calling constructors,
> > templates exceptions and other. What are the possible issues of such an
> > approach while writing device drivers?  What sort of modifications do
> > you reckon might be needed if such a move were to be made?
>
> The way the kernel will deal with C++ language being a complete
> disaster (where something as simple as "a = b + c + d +e" could
> involve a dozen or more memory allocations, implicit type conversions,
> and overloaded operators) is to not use it.  Think about the words of
> wisdom from the movie Wargames: "The only way to win is not to play
> the game".

Let us do it all in assembler. Real optimization for every CPU.

BTW, that sparks a question: 
Did anybody already do a benchmark to see what happens if you address an AMD 
cpu not with x86 instructions but with it's native code, so to circumvent the 
internal translation in the CPU?


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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  4:40 ` Theodore Ts'o
  2004-12-02  6:39   ` Norbert van Nobelen
@ 2004-12-02  8:24   ` James Bruce
  2004-12-02 20:25     ` Theodore Ts'o
  2004-12-02  8:33   ` J.A. Magallon
  2 siblings, 1 reply; 243+ messages in thread
From: James Bruce @ 2004-12-02  8:24 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: Imanpreet Singh Arora, lkml - Kernel Mailing List

Theodore Ts'o wrote:

>The way the kernel will deal with C++ language being a complete
>disaster (where something as simple as "a = b + c + d +e" could
>involve a dozen or more memory allocations, implicit type conversions,
>and overloaded operators) is to not use it.  Think about the words of
>wisdom from the movie Wargames: "The only way to win is not to play
>the game".
>

I think this oft-repeated argument is a strawman, since C++ and C are 
identical on primitive types, and for non-primitive types, C can't use 
operators anyway.  So translating some C++ thing like your example where 
[a,...,e] are all "struct foo", we would have a C function called 
"bar(a,b,c,d,e)".  Well, guess what, without looking at its definition, 
it could be doing all sorts of things too.  In C++ you look at the 
struct definition and the C++ standard, in C you look at the function.  
How is that so different?  In C, functions are arbitrary but operators 
are not.  In C++, both are arbitrary.  Considering that Linux wraps 
almost everything into function calls, there would be little difference 
in the end.

That's not to say I think C++ is a good idea for the kernel; It isn't.  
C++ is more complex in the sense it requires more analysis to figure out 
what the CPU is really doing, thus it does entail a higher cost.  It's 
not that bad for an expert, and in a large part it depends on how many 
of the advanced features you use; Don't use them and your code is 
practically the same as in C.  So it really boils down to what you 
*gain* compared to that extra analysis cost.  For a kernel, there is 
really not much gain.  "Some cost vs. little gain" implies "not worthwhile".

For example, filesystems would probably be more cleanly implemented as 
classes with virtual functions, but as the kernel code shows, with a 
little extra effort you can achieve the same thing with structs of 
function pointers in plain C.  Extra effort is easy to come by when you 
have thousands of contributors, so there's no real difference.  The case 
is similar with many other C++ features.

The C language was developed for writing the original Unix kernel and 
utilities, and not suprisingly it has all the features you need for 
that.  C++ was developed for improved development of user applications, 
mostly through more effective reuse of code.  So again, not suprisingly, 
applications are what it is best at.  Let's also try not to mix up "use 
the right tool for the right job" with "use the best tool for my normal 
job for all problems".  Many people who espouse one language above all 
others need to look outside of their own usual problem area.

 - Jim Bruce


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  4:40 ` Theodore Ts'o
  2004-12-02  6:39   ` Norbert van Nobelen
  2004-12-02  8:24   ` James Bruce
@ 2004-12-02  8:33   ` J.A. Magallon
  2004-12-02 10:46     ` Bernd Petrovitsch
  2 siblings, 1 reply; 243+ messages in thread
From: J.A. Magallon @ 2004-12-02  8:33 UTC (permalink / raw)
  To: linux-kernel


On 2004.12.02, Theodore Ts'o wrote:
> On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> > 
> >    I realize most of the unhappiness lies with C++ compilers being 
> > slow. Also the fact that a lot of Hackers around here are a lot more 
> > familiar with C, rather than C++. However other than that what are the  
> > _implementation_  issues that you hackers might need to consider if it 
> > were to be implemented in C++. 
> 
> The suckitude of C++ compilers is only part of the issues.
> 
> > My question is regarding how will kernel 
> > deal with C++ doing too much behind the back, Calling constructors, 
> > templates exceptions and other. What are the possible issues of such an 
> > approach while writing device drivers?  What sort of modifications do 
> > you reckon might be needed if such a move were to be made?
> 
> The way the kernel will deal with C++ language being a complete
> disaster (where something as simple as "a = b + c + d +e" could
> involve a dozen or more memory allocations, implicit type conversions,
> and overloaded operators) is to not use it.  Think about the words of
> wisdom from the movie Wargames: "The only way to win is not to play
> the game".
> 

Don't ge silly. I have written C++ code to deal with SSE operations
on vectors, and there you really need to control the assembler produced,
and with the correct const and & on correct places the code is as
efficient as C. Or more. You can control everything. No more temporal
objects, no more copies, but still the type checking. I can send you,
for example, the code for a Vector class (no __asm in it),
and the assembler that g++ spits for a thing like a = b+c.
You would do not better in handcoded asm.

It is as all things, you need to know it deeply to use it well.
There are a ton of myths around C++.

For the kernel, you don't need exceptions nor iostreams, so don't use
the C++ runtime library.

Constructor/destuctor is needed, and also virtual single inheritance.
And those two things are already being done by hand with function
pointers inside structs in the kernel. The cost of (single and multiple)
inheritance in C++ is also just an indexed jump, the difference is that
in the pseudo object oriented things done in the kernel you have to
always initializa the funtions pointers, and C++ will do it for you.
How many bugs have you seen because somebody wrote a bad
.method = the wrong_func in an initializer ?

The kernel is full of things like
if (__builtin_constant_pointer(xxxx) and others to check if an argument
is constant and optimize some path, and in C++ you could write
class T {
	T& f();
	const T& f() const;
}
and the compiler will do it at compile time also.

In short, with C++ you can generate code as efficient as C or asm.
You just have to know how.

But C++ is not supported in the kernel. I can live with it.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-rc2-jam4 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #2



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  0:04 What if? Imanpreet Singh Arora
  2004-12-02  4:40 ` Theodore Ts'o
@ 2004-12-02 10:25 ` Jan Engelhardt
  2004-12-05  0:23   ` Horst von Brand
  2004-12-02 10:53 ` Bernd Petrovitsch
  2004-12-11  8:52 ` Gábor Lénárt
  3 siblings, 1 reply; 243+ messages in thread
From: Jan Engelhardt @ 2004-12-02 10:25 UTC (permalink / raw)
  To: Imanpreet Singh Arora; +Cc: lkml - Kernel Mailing List

>    Firstly I have read the FAQ. So though FAQ answers my question, it
>does so only partially.
>
>    "What if Linux were to be implemented in C++?"

To quota Alan Cox (IIRC): "Been there, done that, threw it out".



Jan Engelhardt
-- 
ENOSPC

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  8:33   ` J.A. Magallon
@ 2004-12-02 10:46     ` Bernd Petrovitsch
  2004-12-02 10:56       ` Pawel Sikora
  2004-12-13 15:23       ` H. Peter Anvin
  0 siblings, 2 replies; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-12-02 10:46 UTC (permalink / raw)
  To: linux-kernel

On Thu, 2004-12-02 at 08:33 +0000, J.A. Magallon wrote:
[...]
> Constructor/destuctor is needed, and also virtual single inheritance.
> And those two things are already being done by hand with function
> pointers inside structs in the kernel. The cost of (single and multiple)
> inheritance in C++ is also just an indexed jump, the difference is that
> in the pseudo object oriented things done in the kernel you have to

If software is object-oriented is a question of design, not the
implementation language. So it is neither necessary nor sufficient to
use a (so called) "object-oriented language" to get (or not get)
OO-software.

> always initializa the funtions pointers, and C++ will do it for you.
> How many bugs have you seen because somebody wrote a bad
> .method = the wrong_func in an initializer ?

You like putting the "read" function into the place of the "open"
function in a struct file_operations?
If you name your functions meaningful, you probably see it at the time
you write the code.
And if you do not see it during coding, you probably will see it on the
very first test run.
So the effect is at most moving initialization code and logic from a
the .c in a .h file?!

The unanswered question is: What does it actually buy?

Exceptions, STL, and most of the fancy features are not usable and must
be thrown out (you even have to forbid them and look after it).
The holds - more or less - for operator overloading (except in very few
cases).
So the usual C++-(and OO-) marketing propaganda does not help since most
features (including all standard run-time libs) are either not usable or
forbidden.
Yes, you get probably stricter type checking - most of this is in C also
doable.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  0:04 What if? Imanpreet Singh Arora
  2004-12-02  4:40 ` Theodore Ts'o
  2004-12-02 10:25 ` Jan Engelhardt
@ 2004-12-02 10:53 ` Bernd Petrovitsch
  2004-12-11  8:52 ` Gábor Lénárt
  3 siblings, 0 replies; 243+ messages in thread
From: Bernd Petrovitsch @ 2004-12-02 10:53 UTC (permalink / raw)
  To: Imanpreet Singh Arora; +Cc: lkml - Kernel Mailing List

On Thu, 2004-12-02 at 05:34 +0530, Imanpreet Singh Arora wrote:
>   Firstly I have read the FAQ. So though FAQ answers my question, it 
> does so only partially.
>
>     "What if Linux were to be implemented in C++?"

BTW some years ago, there were people who actually worked on compiling
the existing Linux kernel with g++. So probably you want to start with
such a project to get a feeling ....

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02 10:46     ` Bernd Petrovitsch
@ 2004-12-02 10:56       ` Pawel Sikora
  2004-12-13 15:23       ` H. Peter Anvin
  1 sibling, 0 replies; 243+ messages in thread
From: Pawel Sikora @ 2004-12-02 10:56 UTC (permalink / raw)
  To: Bernd Petrovitsch; +Cc: linux-kernel

On Thu, 2 Dec 2004, Bernd Petrovitsch wrote:

> Exceptions, STL, and most of the fancy features are not usable and must
> be thrown out (you even have to forbid them and look after it).
> The holds - more or less - for operator overloading (except in very few
> cases).
> So the usual C++-(and OO-) marketing propaganda does not help since most
> features (including all standard run-time libs) are either not usable or
> forbidden.
> Yes, you get probably stricter type checking - most of this is in C also
> doable.

The first step was done.

http://netlab.ru.is/exception/KernelExceptions.pdf
http://netlab.ru.is/exception/LinuxCXX.shtml

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  8:24   ` James Bruce
@ 2004-12-02 20:25     ` Theodore Ts'o
  2004-12-03  2:23       ` David Schwartz
  0 siblings, 1 reply; 243+ messages in thread
From: Theodore Ts'o @ 2004-12-02 20:25 UTC (permalink / raw)
  To: James Bruce, J.A. Magallon; +Cc: lkml - Kernel Mailing List

On Thu, Dec 02, 2004 at 03:24:32AM -0500, James Bruce wrote:
> 
> I think this oft-repeated argument is a strawman, since C++ and C are 
> identical on primitive types, and for non-primitive types, C can't use 
> operators anyway.

While that may be true, the problem is that you don't know off the top
of your head whether something like:

	a = b + c + d + e;

involves primitive types or not just by inspection.  So it could be
something that takes no time at all, or a monstrosity which takes a
dozen or more memory allocations, and where it requires a Ph.D. in
understanding obfuscated code to figure out which overloaded operators
and which type coercions had actually taken place.  And remember, this
is a language where you can even override the comma (',') operator.
You think you know what a piece of code will do just by looking at it?
Think again!

This is perhaps one of the reasons why no one has bothered to make a
C++ analogue of the Obfuscated C Programming Contest.  There simply is
no challenge involved.  I have seen propietary codebases written in
C++, where said codebase was the crown jewel of the company, and while
the original C code was understandable, when it was re-written in C++,
it was completely unmaintainable and impossible to understand what was
going on.  I was reduced to placing printf's all over the place just
to figure out the flow of control.  

(Out of respect to the company involved, I won't name names, but it
was a filesystem-related product, and I was adding ext2 support to the
codebase at the time.  While on paper it may have made sense to use
C++ classes to represent different filesystem drivers, the
implementation was a complete and mitigated disaster, IMHO.  And this
is not the only C++ project I have seen where it would have been much
easier to understand the darned thing if it had been written in C
instead.)

On Thu, Dec 02, 2004 at 08:33:44AM +0000, J.A. Magallon wrote:
> Don't ge silly. I have written C++ code to deal with SSE operations
> on vectors, and there you really need to control the assembler produced,
> and with the correct const and & on correct places the code is as
> efficient as C. Or more. You can control everything.....
>
> It is as all things, you need to know it deeply to use it well.
> There are a ton of myths around C++.

If you know how to use a table saw deeply and well, you can use it
safely even with all of the safeties disabled and the blade guard
removed.  There are even a few cases where you have to do this.
However, I wouldn't recommend it for most people since it is far too
likely they will lose a finger or a hand....

That's the problem with C++; it is far too easy to misuse.  And with a
project as big as the Linux Kernel, and with as many contributors as
the Linux Kernel, at the end of the day, it's all about damage
control.  If we depend on peer review to understand whether or not a
patch is busted, it is rather important that something as simple as 

	a = b + c;

does what we think it does, and not something else because someone has
overloaded the '+' operator.  Or God help us, as I have mentioned
earlier, the comma operator.

> In short, with C++ you can generate code as efficient as C or asm.
> You just have to know how.

You can juggle running chain saws if you know how, too.  But I think I
would rather leave that to the Flying Karamazov Brothers.

							- Ted

^ permalink raw reply	[flat|nested] 243+ messages in thread

* RE: What if?
  2004-12-02 20:25     ` Theodore Ts'o
@ 2004-12-03  2:23       ` David Schwartz
  0 siblings, 0 replies; 243+ messages in thread
From: David Schwartz @ 2004-12-03  2:23 UTC (permalink / raw)
  To: James Bruce, J.A. Magallon; +Cc: lkml - Kernel Mailing List


> While that may be true, the problem is that you don't know off the top
> of your head whether something like:
>
> 	a = b + c + d + e;
>
> involves primitive types or not just by inspection.  So it could be
> something that takes no time at all, or a monstrosity which takes a
> dozen or more memory allocations, and where it requires a Ph.D. in
> understanding obfuscated code to figure out which overloaded operators
> and which type coercions had actually taken place.  And remember, this
> is a language where you can even override the comma (',') operator.
> You think you know what a piece of code will do just by looking at it?
> Think again!

	You can write bad code in any language.

> That's the problem with C++; it is far too easy to misuse.  And with a
> project as big as the Linux Kernel, and with as many contributors as
> the Linux Kernel, at the end of the day, it's all about damage
> control.  If we depend on peer review to understand whether or not a
> patch is busted, it is rather important that something as simple as
>
> 	a = b + c;
>
> does what we think it does, and not something else because someone has
> overloaded the '+' operator.  Or God help us, as I have mentioned
> earlier, the comma operator.

	The UNIX way is to allow people to shoot themselves in the foot.
Overloading the comma operator is shooting yourself in the foot. If being
allowed to overload it is bad, then being allowed to do anything harmful is
bad.

> > In short, with C++ you can generate code as efficient as C or asm.
> > You just have to know how.
>
> You can juggle running chain saws if you know how, too.  But I think I
> would rather leave that to the Flying Karamazov Brothers.

	I know all the reasons why writing a kernel in C++ is bad, and I largely
agree with them. However, this argument I don't find convincing.

	The part of it that's correct is just this: with C++, it can be harder to
tell exactly what a line of code does under the hood. For user-space code,
the vast majority of the time, that's great, it saves you from having to do
a whole lot of work. However, for kernel code, the vast majority of the
time, you must understand exactly what's going on under the hood.

	DS



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02 10:25 ` Jan Engelhardt
@ 2004-12-05  0:23   ` Horst von Brand
  2004-12-05  6:21     ` Kyle Moffett
  0 siblings, 1 reply; 243+ messages in thread
From: Horst von Brand @ 2004-12-05  0:23 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Imanpreet Singh Arora, lkml - Kernel Mailing List

Jan Engelhardt <jengelh@linux01.gwdg.de> said:
> Imanpreet Singh Arora <imanpreet@gmail.com> said:
> >    Firstly I have read the FAQ. So though FAQ answers my question, it
> >does so only partially.
> >
> >    "What if Linux were to be implemented in C++?"

> To quota Alan Cox (IIRC): "Been there, done that, threw it out".

Not really. There was support to compile Linux using g++ for a C compiler
some time back (because of better (at the time) type checking), the result
was horrible (mainly due to compiler bugs, IIRC). The gain wasn't near
worth the pain.

Rewriting Linux in C++ means fundamental redesign(s); as mentioned, the VFS
would become a class, as would the driver interfaces, and much more. The
object model inside Linux is sufficiently different from C++'s that it
would be a _huge_ job. And pointless, you'd just get Linux as it stands
today, and loose many current developers (due to unfamiliarity with C++).
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-05  0:23   ` Horst von Brand
@ 2004-12-05  6:21     ` Kyle Moffett
  2004-12-05 22:43       ` Horst von Brand
  0 siblings, 1 reply; 243+ messages in thread
From: Kyle Moffett @ 2004-12-05  6:21 UTC (permalink / raw)
  To: Horst von Brand
  Cc: Imanpreet Singh Arora, lkml - Kernel Mailing List, Jan Engelhardt

On Dec 04, 2004, at 19:23, Horst von Brand wrote:
> ... And pointless, you'd just get Linux as it stands
> today, and loose many current developers (due to unfamiliarity with 
> C++).

Personally, the reason _I_ hate C++ is that I got tired of having to 
learn the obtuse
combinations of symbols and excess keywords necessary to bludgeon my
favorite refcount and memory management systems into the C++ objects.  
It just
wasn't worth the effort when I could write equivalent, better, and 
easier to read
code in C.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-05  6:21     ` Kyle Moffett
@ 2004-12-05 22:43       ` Horst von Brand
  2004-12-06 17:27         ` linux-os
  0 siblings, 1 reply; 243+ messages in thread
From: Horst von Brand @ 2004-12-05 22:43 UTC (permalink / raw)
  To: Kyle Moffett
  Cc: Horst von Brand, Imanpreet Singh Arora,
	lkml - Kernel Mailing List, Jan Engelhardt

Kyle Moffett <mrmacman_g4@mac.com> said:
> On Dec 04, 2004, at 19:23, Horst von Brand wrote:
> > ... And pointless, you'd just get Linux as it stands
> > today, and loose many current developers (due to unfamiliarity with 
> > C++).

> Personally, the reason _I_ hate C++ is that I got tired of having to
> learn the obtuse combinations of symbols and excess keywords necessary to
> bludgeon my favorite refcount and memory management systems into the C++
> objects.  It just wasn't worth the effort when I could write equivalent,
> better, and easier to read code in C.

C++ is sufficiently not C that for such it is probably best to just
redesign the systems. Well done it is probably more elegant than C, but to
get there is a _lot_ of work.
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-05 22:43       ` Horst von Brand
@ 2004-12-06 17:27         ` linux-os
  2004-12-06 18:52           ` Horst von Brand
  0 siblings, 1 reply; 243+ messages in thread
From: linux-os @ 2004-12-06 17:27 UTC (permalink / raw)
  To: Horst von Brand
  Cc: Kyle Moffett, Imanpreet Singh Arora, lkml - Kernel Mailing List,
	Jan Engelhardt

On Sun, 5 Dec 2004, Horst von Brand wrote:

> Kyle Moffett <mrmacman_g4@mac.com> said:
>> On Dec 04, 2004, at 19:23, Horst von Brand wrote:
>>> ... And pointless, you'd just get Linux as it stands
>>> today, and loose many current developers (due to unfamiliarity with
>>> C++).
>
>> Personally, the reason _I_ hate C++ is that I got tired of having to
>> learn the obtuse combinations of symbols and excess keywords necessary to
>> bludgeon my favorite refcount and memory management systems into the C++
>> objects.  It just wasn't worth the effort when I could write equivalent,
>> better, and easier to read code in C.
>
> C++ is sufficiently not C that for such it is probably best to just
> redesign the systems. Well done it is probably more elegant than C, but to
> get there is a _lot_ of work.
> -- 
> 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

There is another problem. The kernel requires a procedural language
to communicate with hardware. Interface with hardware is all about
the step-by-step methods necessary to make hardware run. C++ tries
to isolate one from the actual methods involved. That's what it
was designed for.

One would need to use "extensions" just to get text to the screen.
'C' being an "smart" assembler, is nearly ideal for kernel
development.

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.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-06 17:27         ` linux-os
@ 2004-12-06 18:52           ` Horst von Brand
  0 siblings, 0 replies; 243+ messages in thread
From: Horst von Brand @ 2004-12-06 18:52 UTC (permalink / raw)
  To: linux-os
  Cc: Horst von Brand, Kyle Moffett, Imanpreet Singh Arora,
	lkml - Kernel Mailing List, Jan Engelhardt

linux-os <linux-os@chaos.analogic.com> said:
> On Sun, 5 Dec 2004, Horst von Brand wrote:

[...]

> > C++ is sufficiently not C that for such it is probably best to just
> > redesign the systems. Well done it is probably more elegant than C, but to
> > get there is a _lot_ of work.

> There is another problem. The kernel requires a procedural language
> to communicate with hardware. Interface with hardware is all about
> the step-by-step methods necessary to make hardware run. C++ tries
> to isolate one from the actual methods involved. That's what it
> was designed for.

If you want isolation. The actual methods (I'm assuming function members)
are written in procedural style if you want to.

> One would need to use "extensions" just to get text to the screen.  'C'
> being an "smart" assembler, is nearly ideal for kernel development.

And C++ is supposed to be an OO extension to C, designed to give a
(knowledgeable) programmer exactly the same low-level control as C when
needed (knowlegdeable, tasteful programmer is requisite).
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02  0:04 What if? Imanpreet Singh Arora
                   ` (2 preceding siblings ...)
  2004-12-02 10:53 ` Bernd Petrovitsch
@ 2004-12-11  8:52 ` Gábor Lénárt
  3 siblings, 0 replies; 243+ messages in thread
From: Gábor Lénárt @ 2004-12-11  8:52 UTC (permalink / raw)
  To: Imanpreet Singh Arora; +Cc: lkml - Kernel Mailing List

On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> familiar with C, rather than C++. However other than that what are the  
> _implementation_  issues that you hackers might need to consider if it 
> were to be implemented in C++. My question is regarding how will kernel 

It's a quite simple question: why would it better to implement kernel
in C++? To CHANGE something, you should always consider the advantages
and disadvantages. I think it's NO advantages to implement kernel in C++
over to do it in C. So then why is it useful?

- Gábor (larta'H)

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-02 10:46     ` Bernd Petrovitsch
  2004-12-02 10:56       ` Pawel Sikora
@ 2004-12-13 15:23       ` H. Peter Anvin
  2004-12-13 21:08         ` J.A. Magallon
  1 sibling, 1 reply; 243+ messages in thread
From: H. Peter Anvin @ 2004-12-13 15:23 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <1101984361.28965.10.camel@tara.firmix.at>
By author:    Bernd Petrovitsch <bernd@firmix.at>
In newsgroup: linux.dev.kernel
> 
> The unanswered question is: What does it actually buy?
> 

Type-safe linkage, mainly.  That actually would be a nice thing.

	-hpa

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-13 15:23       ` H. Peter Anvin
@ 2004-12-13 21:08         ` J.A. Magallon
  2004-12-16  0:57           ` Alan Cox
  0 siblings, 1 reply; 243+ messages in thread
From: J.A. Magallon @ 2004-12-13 21:08 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]


On 2004.12.13, H. Peter Anvin wrote:
> Followup to:  <1101984361.28965.10.camel@tara.firmix.at>
> By author:    Bernd Petrovitsch <bernd@firmix.at>
> In newsgroup: linux.dev.kernel
> > 
> > The unanswered question is: What does it actually buy?
> > 
> 
> Type-safe linkage, mainly.  That actually would be a nice thing.
> 

And let the compiler do all what now is done by hand wrt driver methods,
inheritance, specialized methods and so on, with a 1000% increase in security
because compiler does not forget to do thinks, like we do ;)

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-rc2-jam4 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-1mdk)) #4


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-13 21:08         ` J.A. Magallon
@ 2004-12-16  0:57           ` Alan Cox
  2004-12-16  2:44             ` H. Peter Anvin
  0 siblings, 1 reply; 243+ messages in thread
From: Alan Cox @ 2004-12-16  0:57 UTC (permalink / raw)
  To: J.A. Magallon; +Cc: H. Peter Anvin, Linux Kernel Mailing List

On Llu, 2004-12-13 at 21:08, J.A. Magallon wrote:
> > Type-safe linkage, mainly.  That actually would be a nice thing.
> > 
> 
> And let the compiler do all what now is done by hand wrt driver methods,
> inheritance, specialized methods and so on, with a 1000% increase in security
> because compiler does not forget to do thinks, like we do ;)

This is not a C++ thing per se however. A future gcc could do type safe
linkage of C programs instead of C++.


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16  0:57           ` Alan Cox
@ 2004-12-16  2:44             ` H. Peter Anvin
  2004-12-16 13:23               ` Alan Cox
  0 siblings, 1 reply; 243+ messages in thread
From: H. Peter Anvin @ 2004-12-16  2:44 UTC (permalink / raw)
  To: Alan Cox; +Cc: J.A. Magallon, Linux Kernel Mailing List

Alan Cox wrote:
> On Llu, 2004-12-13 at 21:08, J.A. Magallon wrote:
> 
>>>Type-safe linkage, mainly.  That actually would be a nice thing.
>>>
>>And let the compiler do all what now is done by hand wrt driver methods,
>>inheritance, specialized methods and so on, with a 1000% increase in security
>>because compiler does not forget to do thinks, like we do ;)
> 
> This is not a C++ thing per se however. A future gcc could do type safe
> linkage of C programs instead of C++.

Yes, but there is also no really big deal compiling C code with a C++ 
compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.

There is a huge difference between "C compiled with a C++ compiler" and 
the "go crazy with keeping the programmer in the dark" concept proposed 
by Mr. Magallon.

	-hpa

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16  2:44             ` H. Peter Anvin
@ 2004-12-16 13:23               ` Alan Cox
  2004-12-16 15:23                 ` Geert Uytterhoeven
  2004-12-16 20:37                 ` H. Peter Anvin
  0 siblings, 2 replies; 243+ messages in thread
From: Alan Cox @ 2004-12-16 13:23 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: J.A. Magallon, Linux Kernel Mailing List

On Iau, 2004-12-16 at 02:44, H. Peter Anvin wrote:
> Yes, but there is also no really big deal compiling C code with a C++ 
> compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.

g++ is still much slower. We don't know how many bugs it would show up
in the compiler and tools either, especially on embedded platforms.
Finally the current kernel won't go through a C++ compiler because we
use variables like "new" quite often.


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16 13:23               ` Alan Cox
@ 2004-12-16 15:23                 ` Geert Uytterhoeven
  2004-12-16 20:37                 ` H. Peter Anvin
  1 sibling, 0 replies; 243+ messages in thread
From: Geert Uytterhoeven @ 2004-12-16 15:23 UTC (permalink / raw)
  To: Alan Cox; +Cc: H. Peter Anvin, J.A. Magallon, Linux Kernel Mailing List

On Thu, 16 Dec 2004, Alan Cox wrote:
> On Iau, 2004-12-16 at 02:44, H. Peter Anvin wrote:
> > Yes, but there is also no really big deal compiling C code with a C++ 
> > compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.
> 
> g++ is still much slower. We don't know how many bugs it would show up
> in the compiler and tools either, especially on embedded platforms.

Interesting to find out, anyway (for the g++-developers :-)

> Finally the current kernel won't go through a C++ compiler because we
> use variables like "new" quite often.

Not something that can't be worked around using a simple #define...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16 13:23               ` Alan Cox
  2004-12-16 15:23                 ` Geert Uytterhoeven
@ 2004-12-16 20:37                 ` H. Peter Anvin
  2004-12-16 20:52                   ` Jan Engelhardt
  1 sibling, 1 reply; 243+ messages in thread
From: H. Peter Anvin @ 2004-12-16 20:37 UTC (permalink / raw)
  To: Alan Cox; +Cc: J.A. Magallon, Linux Kernel Mailing List

Alan Cox wrote:
> On Iau, 2004-12-16 at 02:44, H. Peter Anvin wrote:
> 
>>Yes, but there is also no really big deal compiling C code with a C++ 
>>compiler.  Yes, it was a disaster in 0.99.14, but that was 10 years ago.
> 
> 
> g++ is still much slower. We don't know how many bugs it would show up
> in the compiler and tools either, especially on embedded platforms.
> Finally the current kernel won't go through a C++ compiler because we
> use variables like "new" quite often.

-Dnew=_New, problem solved.

I'm not in any way advocating compiling with g++ exclusively, but it 
would be nice to be *able to* for bugchecking.  It would be an 
interesting experiment, of nothing else.  I suspect it'd require some 
minor code tweaks and turn up a small handful of bugs right off the bat.

	-hpa


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16 20:37                 ` H. Peter Anvin
@ 2004-12-16 20:52                   ` Jan Engelhardt
  2004-12-16 20:56                     ` H. Peter Anvin
  0 siblings, 1 reply; 243+ messages in thread
From: Jan Engelhardt @ 2004-12-16 20:52 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Alan Cox, J.A. Magallon, Linux Kernel Mailing List

>> g++ is still much slower. We don't know how many bugs it would show up
>> in the compiler and tools either, especially on embedded platforms.
>> Finally the current kernel won't go through a C++ compiler because we
>> use variables like "new" quite often.
>
> -Dnew=_New, problem solved.

It's not that easy. Just when you expect it least, a few tiny sourcecode bits 
already use new (in the C++ sense) and whoops:
	int *b = _New int[4];
(self-explanatory)





Jan Engelhardt
-- 
ENOSPC

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16 20:52                   ` Jan Engelhardt
@ 2004-12-16 20:56                     ` H. Peter Anvin
  2004-12-16 21:08                       ` Jan Engelhardt
  0 siblings, 1 reply; 243+ messages in thread
From: H. Peter Anvin @ 2004-12-16 20:56 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Alan Cox, J.A. Magallon, Linux Kernel Mailing List

Jan Engelhardt wrote:
>>>g++ is still much slower. We don't know how many bugs it would show up
>>>in the compiler and tools either, especially on embedded platforms.
>>>Finally the current kernel won't go through a C++ compiler because we
>>>use variables like "new" quite often.
>>
>>-Dnew=_New, problem solved.
> 
> 
> It's not that easy. Just when you expect it least, a few tiny sourcecode bits 
> already use new (in the C++ sense) and whoops:
> 	int *b = _New int[4];
> (self-explanatory)
> 

Unlikely, since we'd already have caught it, but either way -- hat's a 
bug too.  There shouldn't be any C++ code in the kernel, period.

	-hpa


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: What if?
  2004-12-16 20:56                     ` H. Peter Anvin
@ 2004-12-16 21:08                       ` Jan Engelhardt
  0 siblings, 0 replies; 243+ messages in thread
From: Jan Engelhardt @ 2004-12-16 21:08 UTC (permalink / raw)
  Cc: Linux Kernel Mailing List

> There shouldn't be any C++ code in the kernel, period.

Don't tell _me_ that. (I'm staying pure with C here.)



Jan Engelhardt
-- 
ENOSPC

^ permalink raw reply	[flat|nested] 243+ messages in thread

* [Coverity] Untrusted user data in kernel
@ 2004-12-17  1:33 Bryan Fulton
  2004-12-17  5:15   ` James Morris
  2005-01-05 12:04 ` Marcelo Tosatti
  0 siblings, 2 replies; 243+ messages in thread
From: Bryan Fulton @ 2004-12-17  1:33 UTC (permalink / raw)
  To: linux-kernel

Hi, recently we ran a security checker over linux and discovered some 
flaws in the Linux 2.6.9 kernel. I've inserted into this post a few
examples of what we found.  These functions copy in user data
(copy_from_user) and use it as an array index, loop bound or memory
function argument without proper bounds checking.  

This posting just involves bugs in /fs, /net and /drivers/net. There
will be more postings for similar flaws in the drivers, as well as
network exploitable bugs and bugs in system calls.  

Some can be viewed as minor as they might involve directly passing an
unsigned tainted scalar to kmalloc. I was under the impression that
kmalloc has an implicit bounds check as it returns null if attempting to
allocate >64kb (or at least it used to). Can someone confirm/disconfirm
that? 

Suggestions for other security properties to check are welcome.  We
appreciate your feedback as a method to improve and expand our
security checkers.

Thanks,
.:Bryan Fulton and Ted Unangst of Coverity, Inc.

Quick location summary:

/fs/coda/pioctl.c::coda_pioctl
/fs/xfs/linux-2.6/xfs_ioctl.c::xfs_attrmulti_by_handle
/net/ipv6/netfilter/ip6_tables.c::do_replace
/net/bridge/br_ioctl.c::old_deviceless
/net/rose/rose_route.c::rose_rt_ioctl
/drivers/net/wan/sdla.c::sdla_xfer

/////////////////////////////////////////////////////
// 1:  /fs/coda/pioctl.c::coda_pioctl              //
/////////////////////////////////////////////////////
- tainted scalars (signed shorts) data->vi.in_size and data->vi.out_size
are used to copy memory from and to user space
- neither are properly upper/lower bounds checked (in_size only
upper-bound checked, out_size only lower-bound checked)

Call to function "copy_from_user" TAINTS argument "data"

61    if (copy_from_user(&data, (void __user *)user_data, sizeof(data)))
{
62        return -EINVAL;
63    }
64             

...

TAINTED variable "(data).vi" was passed to a tainted sink.

90    error = venus_pioctl(inode->i_sb, &(cnp->c_fid), cmd, &data);
91      
92    path_release(&nd);
93    return error;
94 }
95      
96      


inside linux-2.6.9/fs/coda/upcall.c::venus_pioctl

Checked upper bounds of signed scalar "((data)->vi).in_size" 
                                 by "((data)->vi).in_size > 8192"

553    if (data->vi.in_size > VC_MAXDATASIZE) {
554        error = -EINVAL;
555        goto exit;
556    }
557

...

Assigned TAINTED variable "((data)->vi).in_size" to variable
"((inp)->coda_ioctl).len"

568    inp->coda_ioctl.len = data->vi.in_size;

...

TAINTED variable "((data)->vi).in_size" passed to tainted data sink
"copy_from_user"

572    if ( copy_from_user((char*)inp + (long)inp->coda_ioctl.data,
573                         data->vi.in, data->vi.in_size) ) {
574            error = -EINVAL;
575            goto exit;
576    }

... 

Checked lower bounds of signed scalar "((data)->vi).out_size" by 
                            "((outp)->coda_ioctl).len >
((data)->vi).out_size"

588             if (outp->coda_ioctl.len > data->vi.out_size) {
589                     error = -EINVAL;
590             } else {

TAINTED variable "((data)->vi).out_size" passed to tainted data sink
"copy_to_user"

591                     if (copy_to_user(data->vi.out, 
592                                      (char *)outp +
(long)outp->coda_ioctl.data, 
593                                      data->vi.out_size)) {
594                             error = -EFAULT;
595                             goto exit;
596                     }



////////////////////////////////////////////////////////////////////
// 2:  /fs/xfs/linux-2.6/xfs_ioctl.c::xfs_attrmulti_by_handle     //
////////////////////////////////////////////////////////////////////

- tainted unsigned scalar am_hreq.opcount multiplied and passed to
kmalloc (512) and copy_from_user (518), and used as a loop bounds (524)
- this is fairly minor as there is a capable() call before the
copy_from_user in xfs_vget_fsop_handlereq

Call to function "xfs_vget_fsop_handlereq" TAINTS argument "am_hreq"

504    error = xfs_vget_fsop_handlereq(mp, parinode, CAP_SYS_ADMIN, arg,
505                                   
sizeof(xfs_fsop_attrmulti_handlereq_t),
506                                    (xfs_fsop_handlereq_t *)&am_hreq,
507                                    &vp, &inode);
508    if (error)
509           return -error;
510     

Assign TAINTED variable "((am_hreq).opcount * 24)" to variable "size"

511    size = am_hreq.opcount * sizeof(attr_multiop_t);

TAINTED variable "size" was passed to a tainted sink.

512    ops = (xfs_attr_multiop_t *)kmalloc(size, GFP_KERNEL);

...

TAINTED variable "size" was passed to a tainted sink.

518    if (copy_from_user(ops, am_hreq.ops, size)) {
519           kfree(ops);
520           VN_RELE(vp);
521           return -XFS_ERROR(EFAULT);
522    }
523 

TAINTED variable "(am_hreq).opcount" used as a loop boundary

524    for (i = 0; i < am_hreq.opcount; i++) {



////////////////////////////////////////////////////////
// 3:   /net/ipv6/netfilter/ip6_tables.c::do_replace  //
////////////////////////////////////////////////////////
 
- tainted unsigned scalar tmp.num_counters multiplied and passed to
vmalloc (1161) and memset (1166) which could overflow or be too large

Call to function "copy_from_user" TAINTS argument "tmp"

1143            if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
1144                    return -EFAULT;

...

TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
sink.

1161            counters = vmalloc(tmp.num_counters * sizeof(struct
ip6t_counters));
1162            if (!counters) {
1163                    ret = -ENOMEM;
1164                    goto free_newinfo;
1165            }

TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
sink.

1166            memset(counters, 0, tmp.num_counters * sizeof(struct
ip6t_counters));



//////////////////////////////////////////////////
// 4:  /net/bridge/br_ioctl.c::old_deviceless   //
//////////////////////////////////////////////////

- tainted unsigned scalar args[2] multiplied and passed to kmalloc (327)
and memset (331) which could overflow
- same scalar then used as a boundary to array index to the alloc'd
memory (inside get_bridge_ifindices)

Call to function "copy_from_user" TAINTS argument "args"

315             if (copy_from_user(args, uarg, sizeof(args)))
316                     return -EFAULT;
317     
317     
318             switch (args[0]) {
319 

...

TAINTED variable "(args[2] * 4)" was passed to a tainted sink.

327                     indices = kmalloc(args[2]*sizeof(int),
GFP_KERNEL);

...

TAINTED variable "(args[2] * 4)" was passed to a tainted sink.

331                     memset(indices, 0, args[2]*sizeof(int));
332                     args[2] = get_bridge_ifindices(indices,
args[2]);
333     

inside /net/bridge/br_ioctl.c::get_bridge_ifindices

24      static int get_bridge_ifindices(int *indices, int num)
25      {
26              struct net_device *dev;
27              int i = 0;
28      
29              for (dev = dev_base; dev && i < num; dev = dev->next) {
30                      if (dev->priv_flags & IFF_EBRIDGE) 
31                              indices[i++] = dev->ifindex;
32              }
33      
34              return i;
35      }



////////////////////////////////////////////////// 
// 5:   /net/rose/rose_route.c::rose_rt_ioctl   //
//////////////////////////////////////////////////

- tainted scalar (unsigned char) rose_route->ndigis used as a loop
boundary (122) for indexing into rose_neigh->digipeat->calls[] of
8 structs

Call to function "copy_from_user" TAINTS argument "rose_route"

720                     if (copy_from_user(&rose_route, arg,
sizeof(struct
rose_route_struct)))
721                             return -EFAULT;

...mem.len

TAINTED variable "(rose_route).ndigis" was passed to a tainted sink.
[model]

731                     err = rose_add_node(&rose_route, dev);

inside /net/rose/rose_route.c::rose_add_node

112                     if (rose_route->ndigis != 0) {
...

Tainted variable "(rose_route)->ndigis" used as a loop boundary

122                             for (i = 0; i < rose_route->ndigis; i++)
{
123                                     rose_neigh->digipeat->calls[i]    =
124                                             rose_route->digipeaters[i];
125                                     rose_neigh->digipeat->repeated[i] = 0;
126                             }



//////////////////////////////////////////////
// 6:   /drivers/net/wan/sdla.c::sdla_xfer  //
//////////////////////////////////////////////

- tainted signed scalar mem.len passed to kmalloc and memset (1206 and
1211, or 1220 and 1223). Possibly minor because of kmalloc's
implicit size check

Call to function "copy_from_user" TAINTS argument "mem"

1201            if(copy_from_user(&mem, info, sizeof(mem)))

...

TAINTED variable "(mem).len" was passed to a tainted sink.

1206                    temp = kmalloc(mem.len, GFP_KERNEL);

...

TAINTED variable "(mem).len" was passed to a tainted sink.

1209                    memset(temp, 0, mem.len);
1210                    sdla_read(dev, mem.addr, temp, mem.len);

TAINTED variable "(mem).len" was passed to a tainted sink.

1211                    if(copy_to_user(mem.data, temp, mem.len))

...

TAINTED variable "(mem).len" was passed to a tainted sink.

1220                    temp = kmalloc(mem.len, GFP_KERNEL);
1221                    if (!temp)
1222                            return(-ENOMEM);

TAINTED variable "(mem).len" was passed to a tainted sink.

1223                    if(copy_from_user(temp, mem.data, mem.len))
1224                    {


-- 
Bryan J Fulton
Coverity, Inc.

Email: bryan@coverity.com



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  1:33 [Coverity] Untrusted user data in kernel Bryan Fulton
@ 2004-12-17  5:15   ` James Morris
  2005-01-05 12:04 ` Marcelo Tosatti
  1 sibling, 0 replies; 243+ messages in thread
From: James Morris @ 2004-12-17  5:15 UTC (permalink / raw)
  To: Bryan Fulton; +Cc: linux-kernel, netdev, netfilter-devel

This at least needs CAP_NET_ADMIN.


On Thu, 16 Dec 2004, Bryan Fulton wrote:
> ////////////////////////////////////////////////////////
> // 3:   /net/ipv6/netfilter/ip6_tables.c::do_replace  //
> ////////////////////////////////////////////////////////
>  
> - tainted unsigned scalar tmp.num_counters multiplied and passed to
> vmalloc (1161) and memset (1166) which could overflow or be too large
> 
> Call to function "copy_from_user" TAINTS argument "tmp"
> 
> 1143            if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
> 1144                    return -EFAULT;
> 
> ...
> 
> TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
> sink.
> 
> 1161            counters = vmalloc(tmp.num_counters * sizeof(struct
> ip6t_counters));
> 1162            if (!counters) {
> 1163                    ret = -ENOMEM;
> 1164                    goto free_newinfo;
> 1165            }
> 
> TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
> sink.
> 
> 1166            memset(counters, 0, tmp.num_counters * sizeof(struct
> ip6t_counters));
> 

-- 
James Morris
<jmorris@redhat.com>




^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
@ 2004-12-17  5:15   ` James Morris
  0 siblings, 0 replies; 243+ messages in thread
From: James Morris @ 2004-12-17  5:15 UTC (permalink / raw)
  To: Bryan Fulton; +Cc: netdev, netfilter-devel, linux-kernel

This at least needs CAP_NET_ADMIN.


On Thu, 16 Dec 2004, Bryan Fulton wrote:
> ////////////////////////////////////////////////////////
> // 3:   /net/ipv6/netfilter/ip6_tables.c::do_replace  //
> ////////////////////////////////////////////////////////
>  
> - tainted unsigned scalar tmp.num_counters multiplied and passed to
> vmalloc (1161) and memset (1166) which could overflow or be too large
> 
> Call to function "copy_from_user" TAINTS argument "tmp"
> 
> 1143            if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
> 1144                    return -EFAULT;
> 
> ...
> 
> TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
> sink.
> 
> 1161            counters = vmalloc(tmp.num_counters * sizeof(struct
> ip6t_counters));
> 1162            if (!counters) {
> 1163                    ret = -ENOMEM;
> 1164                    goto free_newinfo;
> 1165            }
> 
> TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
> sink.
> 
> 1166            memset(counters, 0, tmp.num_counters * sizeof(struct
> ip6t_counters));
> 

-- 
James Morris
<jmorris@redhat.com>

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  5:15   ` James Morris
  (?)
@ 2004-12-17  5:25   ` Patrick McHardy
  2004-12-17  6:45       ` James Morris
  -1 siblings, 1 reply; 243+ messages in thread
From: Patrick McHardy @ 2004-12-17  5:25 UTC (permalink / raw)
  To: James Morris; +Cc: Bryan Fulton, netdev, netfilter-devel, linux-kernel

James Morris wrote:

>This at least needs CAP_NET_ADMIN.
>
It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
replace iptables rules :)

Regards
Patrick

>
>On Thu, 16 Dec 2004, Bryan Fulton wrote:
>  
>
>>////////////////////////////////////////////////////////
>>// 3:   /net/ipv6/netfilter/ip6_tables.c::do_replace  //
>>////////////////////////////////////////////////////////
>> 
>>- tainted unsigned scalar tmp.num_counters multiplied and passed to
>>vmalloc (1161) and memset (1166) which could overflow or be too large
>>
>>Call to function "copy_from_user" TAINTS argument "tmp"
>>
>>1143            if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
>>1144                    return -EFAULT;
>>
>>...
>>
>>TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
>>sink.
>>
>>1161            counters = vmalloc(tmp.num_counters * sizeof(struct
>>ip6t_counters));
>>1162            if (!counters) {
>>1163                    ret = -ENOMEM;
>>1164                    goto free_newinfo;
>>1165            }
>>
>>TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
>>sink.
>>
>>1166            memset(counters, 0, tmp.num_counters * sizeof(struct
>>ip6t_counters));
>>
>>    
>>
>
>  
>


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  5:25   ` Patrick McHardy
@ 2004-12-17  6:45       ` James Morris
  0 siblings, 0 replies; 243+ messages in thread
From: James Morris @ 2004-12-17  6:45 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Bryan Fulton, netdev, netfilter-devel, linux-kernel

On Fri, 17 Dec 2004, Patrick McHardy wrote:

> James Morris wrote:
> 
> >This at least needs CAP_NET_ADMIN.
> >
> It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
> replace iptables rules :)

That's what I meant, you need the capability to do anything bad :-)


- James
-- 
James Morris
<jmorris@redhat.com>



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
@ 2004-12-17  6:45       ` James Morris
  0 siblings, 0 replies; 243+ messages in thread
From: James Morris @ 2004-12-17  6:45 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Bryan Fulton, netdev, netfilter-devel, linux-kernel

On Fri, 17 Dec 2004, Patrick McHardy wrote:

> James Morris wrote:
> 
> >This at least needs CAP_NET_ADMIN.
> >
> It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
> replace iptables rules :)

That's what I meant, you need the capability to do anything bad :-)


- James
-- 
James Morris
<jmorris@redhat.com>

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  6:45       ` James Morris
  (?)
@ 2004-12-17 13:18       ` Tomas Carnecky
  2004-12-17 19:16           ` David S. Miller
  -1 siblings, 1 reply; 243+ messages in thread
From: Tomas Carnecky @ 2004-12-17 13:18 UTC (permalink / raw)
  To: James Morris
  Cc: Patrick McHardy, Bryan Fulton, netdev, netfilter-devel, linux-kernel

James Morris wrote:
> That's what I meant, you need the capability to do anything bad :-)
> 

But.. even if you have the 'permission' to do bad things, it shouldn't 
be possible.

It's a bug, and only because you can't exploit it if you haven't the 
right capabilities doesn't make the bug disappear.

IMHO such things (passing values between user/kernel space) should 
always be checked.

tom

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  5:15   ` James Morris
  (?)
  (?)
@ 2004-12-17 15:10   ` Pavel Machek
  2004-12-17 15:38     ` James Morris
  -1 siblings, 1 reply; 243+ messages in thread
From: Pavel Machek @ 2004-12-17 15:10 UTC (permalink / raw)
  To: James Morris; +Cc: Bryan Fulton, linux-kernel, netdev, netfilter-devel

Hi!

> This at least needs CAP_NET_ADMIN.

Hmm, but that means that CAP_NET_ADMIN implies all other capabilities,
unless you fix this.

								Pavel

> > TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
> > sink.
> > 
> > 1161            counters = vmalloc(tmp.num_counters * sizeof(struct
> > ip6t_counters));
> > 1162            if (!counters) {
> > 1163                    ret = -ENOMEM;
> > 1164                    goto free_newinfo;
> > 1165            }
> > 
> > TAINTED variable "((tmp).num_counters * 16)" was passed to a tainted
> > sink.
> > 
> > 1166            memset(counters, 0, tmp.num_counters * sizeof(struct
> > ip6t_counters));


-- 
Boycott Kodak -- for their patent abuse against Java.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 15:10   ` Pavel Machek
@ 2004-12-17 15:38     ` James Morris
  0 siblings, 0 replies; 243+ messages in thread
From: James Morris @ 2004-12-17 15:38 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Bryan Fulton, linux-kernel, netdev, netfilter-devel

On Fri, 17 Dec 2004, Pavel Machek wrote:

> Hi!
> 
> > This at least needs CAP_NET_ADMIN.
> 
> Hmm, but that means that CAP_NET_ADMIN implies all other capabilities,
> unless you fix this.

I'm not saying it doesn't need to be fixed, but that it is not exploitable 
by unprivileged users.


- James
-- 
James Morris
<jmorris@redhat.com>



^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  6:45       ` James Morris
  (?)
  (?)
@ 2004-12-17 15:47       ` Bill Davidsen
  2004-12-17 16:11         ` linux-os
  -1 siblings, 1 reply; 243+ messages in thread
From: Bill Davidsen @ 2004-12-17 15:47 UTC (permalink / raw)
  To: James Morris
  Cc: Patrick McHardy, Bryan Fulton, netdev, netfilter-devel, linux-kernel

James Morris wrote:
> On Fri, 17 Dec 2004, Patrick McHardy wrote:
> 
> 
>>James Morris wrote:
>>
>>
>>>This at least needs CAP_NET_ADMIN.
>>>
>>
>>It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
>>replace iptables rules :)
> 
> 
> That's what I meant, you need the capability to do anything bad :-)

Are you saying that processes with capability don't make mistakes? This 
isn't a bug related to untrusted users doing privileged operations, it's 
a case of using unchecked user data.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 15:47       ` Bill Davidsen
@ 2004-12-17 16:11         ` linux-os
  2004-12-17 16:31           ` Oliver Neukum
                             ` (3 more replies)
  0 siblings, 4 replies; 243+ messages in thread
From: linux-os @ 2004-12-17 16:11 UTC (permalink / raw)
  To: Bill Davidsen
  Cc: James Morris, Patrick McHardy, Bryan Fulton, netdev,
	netfilter-devel, linux-kernel

On Fri, 17 Dec 2004, Bill Davidsen wrote:

> James Morris wrote:
>> On Fri, 17 Dec 2004, Patrick McHardy wrote:
>> 
>> 
>>> James Morris wrote:
>>> 
>>> 
>>>> This at least needs CAP_NET_ADMIN.
>>>> 
>>> 
>>> It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
>>> replace iptables rules :)
>> 
>> 
>> That's what I meant, you need the capability to do anything bad :-)
>
> Are you saying that processes with capability don't make mistakes? This isn't 
> a bug related to untrusted users doing privileged operations, it's a case of 
> using unchecked user data.
>

But isn't there always the possibility of "unchecked user data"?
I can, as root, do `cp /dev/zero /dev/mem` and have the most
spectacular crask you've evet seen. I can even make my file-
systems unrecoverable.



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 Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 16:11         ` linux-os
@ 2004-12-17 16:31           ` Oliver Neukum
  2004-12-17 18:37           ` Bill Davidsen
                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 243+ messages in thread
From: Oliver Neukum @ 2004-12-17 16:31 UTC (permalink / raw)
  To: linux-os
  Cc: Bill Davidsen, James Morris, Patrick McHardy, Bryan Fulton,
	netdev, netfilter-devel, linux-kernel


> > Are you saying that processes with capability don't make mistakes? This isn't 
> > a bug related to untrusted users doing privileged operations, it's a case of 
> > using unchecked user data.
> >
> 
> But isn't there always the possibility of "unchecked user data"?
> I can, as root, do `cp /dev/zero /dev/mem` and have the most
> spectacular crask you've evet seen. I can even make my file-
> systems unrecoverable.

Only if you have the capability for raw hardware access.
The same is true for the firmware interface. What other subsystems might
be dangerous?

	Regards
		Oliver

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 16:11         ` linux-os
  2004-12-17 16:31           ` Oliver Neukum
@ 2004-12-17 18:37           ` Bill Davidsen
  2004-12-17 19:18           ` Tomas Carnecky
  2004-12-18  1:42           ` Horst von Brand
  3 siblings, 0 replies; 243+ messages in thread
From: Bill Davidsen @ 2004-12-17 18:37 UTC (permalink / raw)
  To: linux-os
  Cc: James Morris, Patrick McHardy, Bryan Fulton, netdev,
	netfilter-devel, linux-kernel

linux-os wrote:
> On Fri, 17 Dec 2004, Bill Davidsen wrote:
> 
>> James Morris wrote:
>>
>>> On Fri, 17 Dec 2004, Patrick McHardy wrote:
>>>
>>>
>>>> James Morris wrote:
>>>>
>>>>
>>>>> This at least needs CAP_NET_ADMIN.
>>>>>
>>>>
>>>> It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
>>>> replace iptables rules :)
>>>
>>>
>>>
>>> That's what I meant, you need the capability to do anything bad :-)
>>
>>
>> Are you saying that processes with capability don't make mistakes? 
>> This isn't a bug related to untrusted users doing privileged 
>> operations, it's a case of using unchecked user data.
>>
> 
> But isn't there always the possibility of "unchecked user data"?
> I can, as root, do `cp /dev/zero /dev/mem` and have the most
> spectacular crask you've evet seen. I can even make my file-
> systems unrecoverable.

But that's not the type of thing you would do by accident. The kernel 
can't protect against deliberate abuse by trusted users, nor should it. 
But the type of problem caused by an application program bug can, and I 
believe should, be caught.

The difference between "oops" and "take that!"

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 13:18       ` Tomas Carnecky
@ 2004-12-17 19:16           ` David S. Miller
  0 siblings, 0 replies; 243+ messages in thread
From: David S. Miller @ 2004-12-17 19:16 UTC (permalink / raw)
  To: Tomas Carnecky
  Cc: jmorris, kaber, bryan, netdev, netfilter-devel, linux-kernel

On Fri, 17 Dec 2004 14:18:52 +0100
Tomas Carnecky <tom@dbservice.com> wrote:

> IMHO such things (passing values between user/kernel space) should 
> always be checked.

As per Patrick's posting, which James was responding to, it is
checked at the level above this function.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
@ 2004-12-17 19:16           ` David S. Miller
  0 siblings, 0 replies; 243+ messages in thread
From: David S. Miller @ 2004-12-17 19:16 UTC (permalink / raw)
  To: Tomas Carnecky
  Cc: bryan, jmorris, netdev, netfilter-devel, linux-kernel, kaber

On Fri, 17 Dec 2004 14:18:52 +0100
Tomas Carnecky <tom@dbservice.com> wrote:

> IMHO such things (passing values between user/kernel space) should 
> always be checked.

As per Patrick's posting, which James was responding to, it is
checked at the level above this function.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 16:11         ` linux-os
  2004-12-17 16:31           ` Oliver Neukum
  2004-12-17 18:37           ` Bill Davidsen
@ 2004-12-17 19:18           ` Tomas Carnecky
  2004-12-17 19:30             ` Oliver Neukum
  2004-12-18  1:42           ` Horst von Brand
  3 siblings, 1 reply; 243+ messages in thread
From: Tomas Carnecky @ 2004-12-17 19:18 UTC (permalink / raw)
  To: linux-os
  Cc: Bill Davidsen, James Morris, Patrick McHardy, Bryan Fulton,
	netdev, netfilter-devel, linux-kernel

linux-os wrote:
> On Fri, 17 Dec 2004, Bill Davidsen wrote:
> 
>> James Morris wrote:
>>
>>> On Fri, 17 Dec 2004, Patrick McHardy wrote:
 >>>
>>> That's what I meant, you need the capability to do anything bad :-)
>>
>>
>> Are you saying that processes with capability don't make mistakes? 
>> This isn't a bug related to untrusted users doing privileged 
>> operations, it's a case of using unchecked user data.
>>
> 
> But isn't there always the possibility of "unchecked user data"?
> I can, as root, do `cp /dev/zero /dev/mem` and have the most
> spectacular crask you've evet seen. I can even make my file-
> systems unrecoverable.
> 

But the difference between you example (cp /dev/zero /dev/mem) and 
passing unchecked data to the kernel is... you _can_ check the data and 
do something about it if you discover that the data is not valid/within 
a range/whatever even if the user has full permissions.
No same person would do a 'cp /dev/zero /dev/mem', but passing bad data 
is more likely to happen, badly written userspace configuration tools etc.

tom

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 19:18           ` Tomas Carnecky
@ 2004-12-17 19:30             ` Oliver Neukum
  2004-12-17 19:39               ` Tomas Carnecky
  0 siblings, 1 reply; 243+ messages in thread
From: Oliver Neukum @ 2004-12-17 19:30 UTC (permalink / raw)
  To: Tomas Carnecky
  Cc: linux-os, Bill Davidsen, James Morris, Patrick McHardy,
	Bryan Fulton, netdev, netfilter-devel, linux-kernel


> But the difference between you example (cp /dev/zero /dev/mem) and 
> passing unchecked data to the kernel is... you _can_ check the data and 

This is the difference:
static int open_port(struct inode * inode, struct file * filp)
{
	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
}
(from mem.c)

	Regards
		Oliver

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 19:34           ` Tomas Carnecky
@ 2004-12-17 19:30               ` David S. Miller
  0 siblings, 0 replies; 243+ messages in thread
From: David S. Miller @ 2004-12-17 19:30 UTC (permalink / raw)
  To: Tomas Carnecky
  Cc: jmorris, kaber, bryan, netdev, netfilter-devel, linux-kernel

On Fri, 17 Dec 2004 20:34:55 +0100
Tomas Carnecky <tom@dbservice.com> wrote:

>  > It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
>  > replace iptables rules :)
> For me it seems that only CAP_NET_ADMIN is checked and not the data.

If that's the case then I agree with you Tomas.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
@ 2004-12-17 19:30               ` David S. Miller
  0 siblings, 0 replies; 243+ messages in thread
From: David S. Miller @ 2004-12-17 19:30 UTC (permalink / raw)
  To: Tomas Carnecky
  Cc: bryan, jmorris, netdev, netfilter-devel, linux-kernel, kaber

On Fri, 17 Dec 2004 20:34:55 +0100
Tomas Carnecky <tom@dbservice.com> wrote:

>  > It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
>  > replace iptables rules :)
> For me it seems that only CAP_NET_ADMIN is checked and not the data.

If that's the case then I agree with you Tomas.

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 19:16           ` David S. Miller
  (?)
@ 2004-12-17 19:34           ` Tomas Carnecky
  2004-12-17 19:30               ` David S. Miller
  -1 siblings, 1 reply; 243+ messages in thread
From: Tomas Carnecky @ 2004-12-17 19:34 UTC (permalink / raw)
  To: David S. Miller
  Cc: jmorris, kaber, bryan, netdev, netfilter-devel, linux-kernel

David S. Miller wrote:
> On Fri, 17 Dec 2004 14:18:52 +0100
> Tomas Carnecky <tom@dbservice.com> wrote:
> 
> 
>>IMHO such things (passing values between user/kernel space) should 
>>always be checked.
> 
> 
> As per Patrick's posting, which James was responding to, it is
> checked at the level above this function.

Is only the capability checked or also the data passed to the kernel?
It's not clear from Patricks reply:
 > It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
 > replace iptables rules :)
For me it seems that only CAP_NET_ADMIN is checked and not the data.

tom

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 19:30             ` Oliver Neukum
@ 2004-12-17 19:39               ` Tomas Carnecky
  0 siblings, 0 replies; 243+ messages in thread
From: Tomas Carnecky @ 2004-12-17 19:39 UTC (permalink / raw)
  To: Oliver Neukum
  Cc: linux-os, Bill Davidsen, James Morris, Patrick McHardy,
	Bryan Fulton, netdev, netfilter-devel, linux-kernel

Oliver Neukum wrote:
>>But the difference between you example (cp /dev/zero /dev/mem) and 
>>passing unchecked data to the kernel is... you _can_ check the data and 
> 
> 
> This is the difference:
> static int open_port(struct inode * inode, struct file * filp)
> {
> 	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
> }
> (from mem.c)
> 

OK, but my point was, whenever you can check the 'contents' of the data 
passed to the kernel, do it. You can't check if the data someone writes 
to /dev/mem is valid or not, but you can check for out-of-range/etc. 
data in ioctl & friends.

tom


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17 16:11         ` linux-os
                             ` (2 preceding siblings ...)
  2004-12-17 19:18           ` Tomas Carnecky
@ 2004-12-18  1:42           ` Horst von Brand
  3 siblings, 0 replies; 243+ messages in thread
From: Horst von Brand @ 2004-12-18  1:42 UTC (permalink / raw)
  To: linux-os
  Cc: Bill Davidsen, James Morris, Patrick McHardy, Bryan Fulton,
	netdev, netfilter-devel, linux-kernel

linux-os <linux-os@chaos.analogic.com> said:
> On Fri, 17 Dec 2004, Bill Davidsen wrote:

[...]

> > Are you saying that processes with capability don't make mistakes? This
> > isn't a bug related to untrusted users doing privileged operations,
> > it's a case of using unchecked user data.

> But isn't there always the possibility of "unchecked user data"?

Yes. But it should be kept to a minimum.

> I can, as root, do `cp /dev/zero /dev/mem` and have the most
> spectacular crask you've evet seen. I can even make my file-
> systems unrecoverable.

Right. And you can get rid of /dev/mem if you don't want to screw yourself
this way (which is well-known). The problem at hand is _not_ in this same
league.
-- 
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

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2004-12-17  1:33 [Coverity] Untrusted user data in kernel Bryan Fulton
  2004-12-17  5:15   ` James Morris
@ 2005-01-05 12:04 ` Marcelo Tosatti
  2005-01-05 15:09   ` Jan Harkes
                     ` (4 more replies)
  1 sibling, 5 replies; 243+ messages in thread
From: Marcelo Tosatti @ 2005-01-05 12:04 UTC (permalink / raw)
  To: Bryan Fulton
  Cc: linux-kernel, jaharkes, Alan Cox, Andrew Morton, acme, davem,
	kas, nathans

[-- Attachment #1: Type: text/plain, Size: 6556 bytes --]


Hi Bryan,

First of all, thanks very much for this effort.

Davem: Please check the networking ones, there are several.

On Thu, Dec 16, 2004 at 05:33:32PM -0800, Bryan Fulton wrote:
> Hi, recently we ran a security checker over linux and discovered some 
> flaws in the Linux 2.6.9 kernel. I've inserted into this post a few
> examples of what we found.  These functions copy in user data
> (copy_from_user) and use it as an array index, loop bound or memory
> function argument without proper bounds checking.  
> 
> This posting just involves bugs in /fs, /net and /drivers/net. There
> will be more postings for similar flaws in the drivers, as well as
> network exploitable bugs and bugs in system calls.  

We're anxious to see those.

> Some can be viewed as minor as they might involve directly passing an
> unsigned tainted scalar to kmalloc. I was under the impression that
> kmalloc has an implicit bounds check as it returns null if attempting to
> allocate >64kb (or at least it used to). Can someone confirm/disconfirm
> that? 

On v2.6 the kmalloc limit is 128k for most machines.

!CONFIG_MMU allows up to 1Mb and CONFIG_LARGE_ALLOCS allows up to 32Mb, so better
not rely on kmalloc checking. ;)

> Suggestions for other security properties to check are welcome.  We
> appreciate your feedback as a method to improve and expand our
> security checkers.

Please run the checker on v2.4.29-pre3.

Would be really nice if you could do it periodically say on each new kernel release (v2.6
and v2.4) or a monthly basis.

> Thanks,
> .:Bryan Fulton and Ted Unangst of Coverity, Inc.
> 
> Quick location summary:
> 
> /fs/coda/pioctl.c::coda_pioctl
> /fs/xfs/linux-2.6/xfs_ioctl.c::xfs_attrmulti_by_handle
> /net/ipv6/netfilter/ip6_tables.c::do_replace
> /net/bridge/br_ioctl.c::old_deviceless
> /net/rose/rose_route.c::rose_rt_ioctl
> /drivers/net/wan/sdla.c::sdla_xfer
> 
> /////////////////////////////////////////////////////
> // 1:  /fs/coda/pioctl.c::coda_pioctl              //
> /////////////////////////////////////////////////////
> - tainted scalars (signed shorts) data->vi.in_size and data->vi.out_size
> are used to copy memory from and to user space
> - neither are properly upper/lower bounds checked (in_size only
> upper-bound checked, out_size only lower-bound checked)

<snip>

> TAINTED variable "((data)->vi).in_size" passed to tainted data sink
> "copy_from_user"
> 
> 572    if ( copy_from_user((char*)inp + (long)inp->coda_ioctl.data,
> 573                         data->vi.in, data->vi.in_size) ) {
> 574            error = -EINVAL;
> 575            goto exit;
> 576    }
> 
> ... 
> 
> Checked lower bounds of signed scalar "((data)->vi).out_size" by 
>                             "((outp)->coda_ioctl).len >
> ((data)->vi).out_size"
> 
> 588             if (outp->coda_ioctl.len > data->vi.out_size) {
> 589                     error = -EINVAL;
> 590             } else {
> 
> TAINTED variable "((data)->vi).out_size" passed to tainted data sink
> "copy_to_user"
> 
> 591                     if (copy_to_user(data->vi.out, 
> 592                                      (char *)outp +
> (long)outp->coda_ioctl.data, 
> 593                                      data->vi.out_size)) {
> 594                             error = -EFAULT;
> 595                             goto exit;
> 596                     }


Correct, fix for both v2.4 and v2.6 attached. Adds bound checking:

Jan Harkes, please check correctness so we can apply it.

--- linux-2.6.10-rc3/fs/coda/upcall.c.orig	2005-01-05 10:30:24.575445152 -0200
+++ linux-2.6.10-rc3/fs/coda/upcall.c	2005-01-05 10:30:26.623133856 -0200
@@ -550,10 +550,15 @@
 	UPARG(CODA_IOCTL);
 
         /* build packet for Venus */
-        if (data->vi.in_size > VC_MAXDATASIZE) {
+        if (data->vi.in_size > VC_MAXDATASIZE || data->vi.in_size < 0) {
 		error = -EINVAL;
 		goto exit;
-        }
+        } 
+
+	if (data->vi.out_size > VC_MAXDATASIZE || data->vi.out_size < 0) {
+		error = -EINVAL;
+		goto exit;
+	}
 
         inp->coda_ioctl.VFid = *fid;
     
> ////////////////////////////////////////////////////////////////////
> // 2:  /fs/xfs/linux-2.6/xfs_ioctl.c::xfs_attrmulti_by_handle     //
> ////////////////////////////////////////////////////////////////////

XFS people, can you take care of this one please. Not a security threat,
protected under ADMIN caps.

> ////////////////////////////////////////////////////////
> // 3:   /net/ipv6/netfilter/ip6_tables.c::do_replace  //
> ////////////////////////////////////////////////////////

This one lacks bound checking as people discussed, but is not
a security threat since region is protected under NET_ADMIN caps.

> //////////////////////////////////////////////////
> // 4:  /net/bridge/br_ioctl.c::old_deviceless   //
> //////////////////////////////////////////////////

Lacks bound checking but is not a security threat since region 
is protectedunder NET_ADMIN caps.

Something similar to this should do it. Not sure if "65535" is a
sane value, though.

--- br_ioctl.c.orig     2005-01-05 11:02:28.301994264 -0200
+++ br_ioctl.c  2005-01-05 11:02:30.552652112 -0200
@@ -324,6 +324,9 @@
                int *indices;
                int ret = 0;
 
+               if (args[2] > 65535)
+                       return -EFAULT;
+
                indices = kmalloc(args[2]*sizeof(int), GFP_KERNEL);
                if (indices == NULL)
                        return -ENOMEM;

> ////////////////////////////////////////////////// 
> // 5:   /net/rose/rose_route.c::rose_rt_ioctl   //
> //////////////////////////////////////////////////

Not a security threat because requires NET_ADMIN caps. 

Alan, Arnaldo, proper bound checking is required nevertheless. 
Can you take a look at this please?

> //////////////////////////////////////////////
> // 6:   /drivers/net/wan/sdla.c::sdla_xfer  //
> //////////////////////////////////////////////
> 
> - tainted signed scalar mem.len passed to kmalloc and memset (1206 and
> 1211, or 1220 and 1223). Possibly minor because of kmalloc's
> implicit size check

Protected by NET_ADMIN caps, but definately needs some bound checking.

Jan, I think SDLA_MAX_DATA is the correct bound to check for here, can 
you confirm please?

--- linux-2.4.28.orig/drivers/net/wan/sdla.c	2004-12-31 15:21:16.000000000 -0200
+++ linux-2.4.28/drivers/net/wan/sdla.c	2005-01-05 11:23:15.089453760 -0200
@@ -1195,6 +1195,9 @@
 
 	if(copy_from_user(&mem, info, sizeof(mem)))
 		return -EFAULT;
+
+	if (mem.len > SDLA_MAX_DATA || mem.len < 0)
+		return -EFAULT;
 		
 	if (read)
 	{	

[-- Attachment #2: 24_coda.patch --]
[-- Type: text/plain, Size: 622 bytes --]

--- linux-2.4.28/fs/coda/upcall.c.orig	2005-01-05 10:33:55.427390784 -0200
+++ linux-2.4.28/fs/coda/upcall.c	2005-01-05 10:33:58.739887208 -0200
@@ -538,11 +538,16 @@
 	UPARG(CODA_IOCTL);
 
         /* build packet for Venus */
-        if (data->vi.in_size > VC_MAXDATASIZE) {
+        if (data->vi.in_size > VC_MAXDATASIZE || data->vi.in_size < 0) {
 		error = -EINVAL;
 		goto exit;
         }
 
+	if (data->vi.out_size > VC_MAXDATASIZE || data->vi.out_size < 0) {
+		error = -EINVAL;
+		goto exit;
+	}
+
         inp->coda_ioctl.VFid = *fid;
     
         /* the cmd field was mutated by increasing its size field to

[-- Attachment #3: 26_coda.patch --]
[-- Type: text/plain, Size: 572 bytes --]

--- linux-2.6.10-rc3/fs/coda/upcall.c.orig	2005-01-05 10:30:24.575445152 -0200
+++ linux-2.6.10-rc3/fs/coda/upcall.c	2005-01-05 10:30:26.623133856 -0200
@@ -550,10 +550,15 @@
 	UPARG(CODA_IOCTL);
 
         /* build packet for Venus */
-        if (data->vi.in_size > VC_MAXDATASIZE) {
+        if (data->vi.in_size > VC_MAXDATASIZE || data->vi.in_size < 0) {
 		error = -EINVAL;
 		goto exit;
-        }
+        } 
+
+	if (data->vi.out_size > VC_MAXDATASIZE || data->vi.out_size < 0) {
+		error = -EINVAL;
+		goto exit;
+	}
 
         inp->coda_ioctl.VFid = *fid;
     

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2005-01-05 12:04 ` Marcelo Tosatti
@ 2005-01-05 15:09   ` Jan Harkes
  2005-01-05 23:17   ` Nathan Scott
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 243+ messages in thread
From: Jan Harkes @ 2005-01-05 15:09 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: Bryan Fulton, linux-kernel, Andrew Morton

On Wed, Jan 05, 2005 at 10:04:23AM -0200, Marcelo Tosatti wrote:
> On Thu, Dec 16, 2004 at 05:33:32PM -0800, Bryan Fulton wrote:
> Correct, fix for both v2.4 and v2.6 attached. Adds bound checking:
> 
> Jan Harkes, please check correctness so we can apply it.

I was looking at this and actually think that both in_size and out_size
should just be changed to unsigned short instead of signed short (the
values should never be negative, period).

That fixes the bounds checking on the in_size, but the out_size one is
still questionable. I'm not even sure the code is actually testing the
right thing there.

> --- linux-2.6.10-rc3/fs/coda/upcall.c.orig	2005-01-05 10:30:24.575445152 -0200
> +++ linux-2.6.10-rc3/fs/coda/upcall.c	2005-01-05 10:30:26.623133856 -0200
> @@ -550,10 +550,15 @@
>  	UPARG(CODA_IOCTL);
>  
>          /* build packet for Venus */
> -        if (data->vi.in_size > VC_MAXDATASIZE) {
> +        if (data->vi.in_size > VC_MAXDATASIZE || data->vi.in_size < 0) {
>  		error = -EINVAL;
>  		goto exit;
> -        }
> +        } 

This part would work, but changing to the variable to unsigned short
in include/linux/coda.h works just as well.

> +	if (data->vi.out_size > VC_MAXDATASIZE || data->vi.out_size < 0) {
> +		error = -EINVAL;
> +		goto exit;
> +	}

We might be overwriting out_size when making the upcall to venus, so
checking out_size here probably doesn't help all that much. I'm still
looking at what exactly is going on with that. I should have a patch by
the end of the week.

Jan


^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2005-01-05 12:04 ` Marcelo Tosatti
  2005-01-05 15:09   ` Jan Harkes
@ 2005-01-05 23:17   ` Nathan Scott
       [not found]   ` <20050105161653.GF13455@fi.muni.cz>
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 243+ messages in thread
From: Nathan Scott @ 2005-01-05 23:17 UTC (permalink / raw)
  To: Marcelo Tosatti
  Cc: Bryan Fulton, linux-kernel, jaharkes, Alan Cox, Andrew Morton,
	acme, davem, kas

On Wed, Jan 05, 2005 at 10:04:23AM -0200, Marcelo Tosatti wrote:
> > ////////////////////////////////////////////////////////////////////
> > // 2:  /fs/xfs/linux-2.6/xfs_ioctl.c::xfs_attrmulti_by_handle     //
> > ////////////////////////////////////////////////////////////////////
> 
> XFS people, can you take care of this one please. Not a security threat,
> protected under ADMIN caps.

Fixed in our local tree coupla weeks ago, it'll be in the next update.

cheers.

-- 
Nathan

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
       [not found]     ` <20050105140549.GA14622@logos.cnet>
@ 2005-01-06  9:18       ` Jan Kasprzak
  2005-01-06 14:48         ` Paulo Marques
  2005-01-06 16:29         ` Alan Cox
  0 siblings, 2 replies; 243+ messages in thread
From: Jan Kasprzak @ 2005-01-06  9:18 UTC (permalink / raw)
  To: Marcelo Tosatti
  Cc: linux-kernel, jaharkes, Alan Cox, Andrew Morton, acme, davem,
	kas, nathans

: //////////////////////////////////////////////
: // 6:   /drivers/net/wan/sdla.c::sdla_xfer  //
: //////////////////////////////////////////////
: 
	I am not a maintainer of sdla driver, but being Cc'd with this
mail, I'll try to look at it.

: - tainted signed scalar mem.len passed to kmalloc and memset (1206 and
: 1211, or 1220 and 1223). Possibly minor because of kmalloc's
: implicit size check

	Yes. The value mem.len is passed to kmalloc and the code immediately
returns -ENOMEM when kmalloc fails.

: Protected by NET_ADMIN caps, but definately needs some bound checking.
:
	Depends on whether the kmalloc's internal checks are
sufficient or not.

: Jan, I think SDLA_MAX_DATA is the correct bound to check for here, can
: you confirm please?
: 
	I cannot because I don't know or even have this hardware.
However: looking at the definitions in include/linux/sdla.h and the
code itself it looks like SDLA_READMEM, SDLA_WRITEMEM, and SDLA_CLEAR
ioctls are for reading/writing/clearing the card memory itself (maybe
for debugging purposes or downloading a firmware or what). So no,
SDLA_MAX_DATA is probably not a correct limit there.

	The SDLA_CLEAR ioctl (the sdla_clear(dev) function) tries
to clear exactly 65536 bytes (hardcoded at sdla.c:sdla_clear() line 140).
So the mem.len should be <= 65536 bytes, and even mem.addr + mem.len
should be <= 65536 bytes.

	So I propose the following patch (maybe the constant 65536 should
be defined in sdla.h and used both in sdla_xfer() and sdla_clear()):

Signed-off-by: Jan "Yenya" Kasprzak <kas@fi.muni.cz>

--- linux-2.4.28/drivers/net/wan/sdla.c.orig	2002-11-29 00:53:14.000000000 +0100
+++ linux-2.4.28/drivers/net/wan/sdla.c	2005-01-06 10:14:21.115490248 +0100
@@ -1195,6 +1195,10 @@
 
 	if(copy_from_user(&mem, info, sizeof(mem)))
 		return -EFAULT;
+
+	if (mem.len <= 0 || mem.addr < 0 || mem.len > 65536 || mem.addr > 65535
+		|| mem.addr + mem.len > 65536)
+		return -EFAULT;
 		
 	if (read)
 	{	


-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while.      --Rob Pike <

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2005-01-06  9:18       ` Jan Kasprzak
@ 2005-01-06 14:48         ` Paulo Marques
  2005-01-06 16:29         ` Alan Cox
  1 sibling, 0 replies; 243+ messages in thread
From: Paulo Marques @ 2005-01-06 14:48 UTC (permalink / raw)
  To: Jan Kasprzak
  Cc: Marcelo Tosatti, linux-kernel, jaharkes, Alan Cox, Andrew Morton,
	acme, davem, nathans

Jan Kasprzak wrote:
> [...]
> +	if (mem.len <= 0 || mem.addr < 0 || mem.len > 65536 || mem.addr > 65535
> +		|| mem.addr + mem.len > 65536)
> +		return -EFAULT;

Just an extremely small nitpick. The conditions

mem.len > 65536 || mem.addr > 65535

aren't needed, because if one of them is true, then

mem.addr + mem.len > 65536

must be true also, since we've already asserted that len>0 and addr>=0.

This would be even simpler if len and addr were unsigned as they should 
be, but that's probably not your fault :(

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

^ permalink raw reply	[flat|nested] 243+ messages in thread

* Re: [Coverity] Untrusted user data in kernel
  2005-01-06  9:18       ` Jan Kasprzak
  2005-01-06 14:48         ` Paulo Marques
@ 2005-01-06 16:29         ` Alan Cox
  1 sibling, 0 replies; 243+ messages in thread
From: Alan Cox @ 2005-01-06 16:29 UTC (permalink / raw)
  To: Jan Kasprzak
  Cc: Marcelo Tosatti, Linux Kernel Mailing List, jaharkes,
	Andrew Morton, acme, davem, nathans


> 	The SDLA_CLEAR ioctl (the sdla_clear(dev) function) tries
> to clear exactly 65536 bytes (hardcoded at sdla.c:sdla_clear() line 140).
> So the mem.len should be <= 65536 bytes, and even mem.addr + mem.len
> should be <= 65536 bytes.
> 
> 	So I propose the following patch (maybe the constant 65536 should
> be defined in sdla.h and used both in sdla_xfer() and sdla_clear()):

I'd propose they are set to CAP_SYS_RAWIO for those specific
debugging/firmware load operations. They allow access to that level
potentially anyway. That solves the problem cleanly.


^ permalink raw reply	[flat|nested] 243+ messages in thread

* [PATCH 2.4.29-pre3-bk4] fs/coda Re: [Coverity] Untrusted user data in kernel
  2005-01-05 12:04 ` Marcelo Tosatti
                     ` (2 preceding siblings ...)
       [not found]   ` <20050105161653.GF13455@fi.muni.cz>
@ 2005-01-07 21:49   ` Jan Harkes
  2005-01-07 21:54   ` [PATCH 2.6.10-mm2] " Jan Harkes
  4 siblings, 0 replies; 243+ messages in thread
From: Jan Harkes @ 2005-01-07 21:49 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: Bryan Fulton, linux-kernel, jaharkes


This patch adds bounds checking for tainted scalars.
(reported by Brian Fulton and Ted Unangst, Coverity Inc.)

Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>

Index: linux-2.4.29-pre3-bk4/include/linux/coda.h
===================================================================
--- linux-2.4.29-pre3-bk4.orig/include/linux/coda.h	2005-01-06 15:37:01.576583328 -0500
+++ linux-2.4.29-pre3-bk4/include/linux/coda.h	2005-01-06 09:12:40.000000000 -0500
@@ -767,8 +767,8 @@
 #define PIOCPARM_MASK 0x0000ffff
 struct ViceIoctl {
         caddr_t in, out;        /* Data to be transferred in, or out */
-        short in_size;          /* Size of input buffer <= 2K */
-        short out_size;         /* Maximum size of output buffer, <= 2K */
+        u_short in_size;        /* Size of input buffer <= 2K */
+        u_short out_size;       /* Maximum size of output buffer, <= 2K */
 };
 
 struct PioctlData {
Index: linux-2.4.29-pre3-bk4/fs/coda/upcall.c
===================================================================
--- linux-2.4.29-pre3-bk4.orig/fs/coda/upcall.c	2005-01-06 15:37:01.609578312 -0500
+++ linux-2.4.29-pre3-bk4/fs/coda/upcall.c	2005-01-06 15:36:24.849166744 -0500
@@ -543,6 +543,11 @@
 		goto exit;
         }
 
+        if (data->vi.out_size > VC_MAXDATASIZE) {
+		error = -EINVAL;
+		goto exit;
+	}
+
         inp->coda_ioctl.VFid = *fid;
     
         /* the cmd field was mutated by increasing its size field to
@@ -571,26 +576,30 @@
 		       error, coda_f2s(fid));
 		goto exit; 
 	}
-        
-	/* Copy out the OUT buffer. */
+
+	if (outsize < (long)outp->coda_ioctl.data + outp->coda_ioctl.len) {
+                CDEBUG(D_FILE, "reply size %d < reply len %ld\n", outsize,
+		       (long)outp->coda_ioctl.data + outp->coda_ioctl.len);
+		error = -EINVAL;
+		goto exit;
+	}
+
         if (outp->coda_ioctl.len > data->vi.out_size) {
-                CDEBUG(D_FILE, "return len %d <= request len %d\n",
-                      outp->coda_ioctl.len, 
-                      data->vi.out_size);
+                CDEBUG(D_FILE, "return len %d > request len %d\n",
+		       outp->coda_ioctl.len, data->vi.out_size);
 		error = -EINVAL;
-        } else {
-		error = verify_area(VERIFY_WRITE, data->vi.out, 
-                                    data->vi.out_size);
-		if ( error ) goto exit;
-
-		if (copy_to_user(data->vi.out, 
-				 (char *)outp + (long)outp->coda_ioctl.data, 
-				 data->vi.out_size)) {
-			error = -EINVAL;
-			goto exit;
-		}
+		goto exit;
         }
 
+	/* Copy out the OUT buffer. */
+	error = verify_area(VERIFY_WRITE, data->vi.out, outp->coda_ioctl.len);
+	if ( error ) goto exit;
+
+	if (copy_to_user(data->vi.out, 
+			 (char *)outp + (long)outp->coda_ioctl.data, 
+			 outp->coda_ioctl.len)) {
+	    error = -EINVAL;
+	}
  exit:
 	CODA_FREE(inp, insize);
 	return error;

^ permalink raw reply	[flat|nested] 243+ messages in thread

* [PATCH 2.6.10-mm2] fs/coda Re: [Coverity] Untrusted user data in kernel
  2005-01-05 12:04 ` Marcelo Tosatti
                     ` (3 preceding siblings ...)
  2005-01-07 21:49   ` [PATCH 2.4.29-pre3-bk4] fs/coda " Jan Harkes
@ 2005-01-07 21:54   ` Jan Harkes
  4 siblings, 0 replies; 243+ messages in thread
From: Jan Harkes @ 2005-01-07 21:54 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Bryan Fulton, linux-kernel, jaharkes


This patch adds bounds checks for tainted scalars
(reported by Brian Fulton and Ted Unangst, Coverity Inc.).

Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>

Index: linux-2.6.10-mm2/include/linux/coda.h
===================================================================
--- linux-2.6.10-mm2.orig/include/linux/coda.h	2005-01-07 16:36:03.000000000 -0500
+++ linux-2.6.10-mm2/include/linux/coda.h	2005-01-07 16:42:20.000000000 -0500
@@ -761,8 +761,8 @@
 struct ViceIoctl {
         void __user *in;        /* Data to be transferred in */
         void __user *out;       /* Data to be transferred out */
-        short in_size;          /* Size of input buffer <= 2K */
-        short out_size;         /* Maximum size of output buffer, <= 2K */
+        u_short in_size;        /* Size of input buffer <= 2K */
+        u_short out_size;       /* Maximum size of output buffer, <= 2K */
 };
 
 struct PioctlData {
Index: linux-2.6.10-mm2/fs/coda/upcall.c
===================================================================
--- linux-2.6.10-mm2.orig/fs/coda/upcall.c	2005-01-07 16:36:03.000000000 -0500
+++ linux-2.6.10-mm2/fs/coda/upcall.c	2005-01-07 16:53:03.074276720 -0500
@@ -555,6 +555,11 @@
 		goto exit;
         }
 
+        if (data->vi.out_size > VC_MAXDATASIZE) {
+		error = -EINVAL;
+		goto exit;
+	}
+
         inp->coda_ioctl.VFid = *fid;
     
         /* the cmd field was mutated by increasing its size field to
@@ -583,19 +588,26 @@
 		       error, coda_f2s(fid));
 		goto exit; 
 	}
+
+	if (outsize < (long)outp->coda_ioctl.data + outp->coda_ioctl.len) {
+		error = -EINVAL;
+		goto exit;
+	}
         
 	/* Copy out the OUT buffer. */
         if (outp->coda_ioctl.len > data->vi.out_size) {
 		error = -EINVAL;
-        } else {
-		if (copy_to_user(data->vi.out, 
-				 (char *)outp + (long)outp->coda_ioctl.data, 
-				 data->vi.out_size)) {
-			error = -EFAULT;
-			goto exit;
-		}
+		goto exit;
         }
 
+	/* Copy out the OUT buffer. */
+	if (copy_to_user(data->vi.out, 
+			 (char *)outp + (long)outp->coda_ioctl.data, 
+			 outp->coda_ioctl.len)) {
+		error = -EFAULT;
+		goto exit;
+	}
+
  exit:
 	CODA_FREE(inp, insize);
 	return error;

^ permalink raw reply	[flat|nested] 243+ messages in thread

* What if?
@ 2011-04-18 18:34 Shannon Lavenia
  0 siblings, 0 replies; 243+ messages in thread
From: Shannon Lavenia @ 2011-04-18 18:34 UTC (permalink / raw)
  To: netdev

Hi,

I hope you had a great weekend. John and I
spent the time playing with our daughter...
hard to believe she's 6 months old already.

Watching her grow made me realize that
time really does go by fast.

It's almost Easter already and a quarter
of the year has just flown by.

Which made me think: Will 2011 be
"just another year", or will it be
EXTRAORDINARY.

This year is turning out fantastic for us and
I sincerely hope it is for you too. We're taking
every step possible towards our goal:

"To help 100 people achieve their financial
and personal goals".

We made a decision a few months ago
to really focus on helping more people
achieve success...to help people
realize the freedom that we enjoy
working for ourselves.

We're doing it with http://www.UprofitPro.com

I mean, let's face it, with all the
fear mongering going on in the news
right now, it's easy for you and I to think
that it's hopeless.

But, it really isn't. Yes, there is a huge
transfer of wealth happening right now.
That doesn't mean you have to lay down
and be on the wrong side of the transfer.

You CAN win and win BIG right now
just by knowing a few key steps to take
that will make a HUGE difference.

We started UprofitPro to give you
access to:

1. Success coaching from 7 figure
earners and our exclusive alliance
of mentors including The Home Business
Diva Robin Firestone, Michael Hamburger -
Executive Vice President of Marketing at
WMI, Neal Peterson - World Renowned
Motivational Speaker and more.

That means you'll get motivated and
inspired whether you want to be or not...
on a daily basis.

Keeping your energy up is key to
success.

2. A very simple, yet powerful, way to
generate an on-going residual income
stream without ever mentioning it to
your friends, family or neighbors.

We actually do most of the marketing
for you...it's that simple.

3. And, if you're already building
a home based business, a way to
generate the highest quality, highest
converting leads known to man.

I know that sounds a bit "hypey", but
it's true. We'll show you how to get the
same quality of leads that top marketers
get and how to make money generating
leads instead of paying for them.

How serious are we about helping people?

John and I usually charge upwards of $500.00
for a 45 minute session of coaching.

Seriously.

But, we're giving you full access to the
UprofitPro coaching and wealth building
system for only $1.00.

You have nothing to lose and everything
to gain.

If, after a week you say "not for me", we'll
give you your buck back and wish you all the
best.

But, we know you won't. Noone has yet. Because
everything we've got in store for you will simply
blow you away.

So, give yourself a great boost today
and a huge step towards running first through
that ribbon at the finish line by joining us
at http://www.uprofitpro.com.

You'll be grateful you did.

With you in success!
Shannon Lavenia
Co-founder, Uprofitpro.com
+1(323) 834-9274

PS: If you have any questions, feel free to
give us ring. You'll get instant access to
all the member resources, training and coaching
videos.






^ permalink raw reply	[flat|nested] 243+ messages in thread

end of thread, other threads:[~2011-04-18 21:04 UTC | newest]

Thread overview: 243+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-02  0:04 What if? Imanpreet Singh Arora
2004-12-02  4:40 ` Theodore Ts'o
2004-12-02  6:39   ` Norbert van Nobelen
2004-12-02  8:24   ` James Bruce
2004-12-02 20:25     ` Theodore Ts'o
2004-12-03  2:23       ` David Schwartz
2004-12-02  8:33   ` J.A. Magallon
2004-12-02 10:46     ` Bernd Petrovitsch
2004-12-02 10:56       ` Pawel Sikora
2004-12-13 15:23       ` H. Peter Anvin
2004-12-13 21:08         ` J.A. Magallon
2004-12-16  0:57           ` Alan Cox
2004-12-16  2:44             ` H. Peter Anvin
2004-12-16 13:23               ` Alan Cox
2004-12-16 15:23                 ` Geert Uytterhoeven
2004-12-16 20:37                 ` H. Peter Anvin
2004-12-16 20:52                   ` Jan Engelhardt
2004-12-16 20:56                     ` H. Peter Anvin
2004-12-16 21:08                       ` Jan Engelhardt
2004-12-02 10:25 ` Jan Engelhardt
2004-12-05  0:23   ` Horst von Brand
2004-12-05  6:21     ` Kyle Moffett
2004-12-05 22:43       ` Horst von Brand
2004-12-06 17:27         ` linux-os
2004-12-06 18:52           ` Horst von Brand
2004-12-02 10:53 ` Bernd Petrovitsch
2004-12-11  8:52 ` Gábor Lénárt
  -- strict thread matches above, loose matches on Subject: below --
2011-04-18 18:34 Shannon Lavenia
2004-12-17  1:33 [Coverity] Untrusted user data in kernel Bryan Fulton
2004-12-17  5:15 ` James Morris
2004-12-17  5:15   ` James Morris
2004-12-17  5:25   ` Patrick McHardy
2004-12-17  6:45     ` James Morris
2004-12-17  6:45       ` James Morris
2004-12-17 13:18       ` Tomas Carnecky
2004-12-17 19:16         ` David S. Miller
2004-12-17 19:16           ` David S. Miller
2004-12-17 19:34           ` Tomas Carnecky
2004-12-17 19:30             ` David S. Miller
2004-12-17 19:30               ` David S. Miller
2004-12-17 15:47       ` Bill Davidsen
2004-12-17 16:11         ` linux-os
2004-12-17 16:31           ` Oliver Neukum
2004-12-17 18:37           ` Bill Davidsen
2004-12-17 19:18           ` Tomas Carnecky
2004-12-17 19:30             ` Oliver Neukum
2004-12-17 19:39               ` Tomas Carnecky
2004-12-18  1:42           ` Horst von Brand
2004-12-17 15:10   ` Pavel Machek
2004-12-17 15:38     ` James Morris
2005-01-05 12:04 ` Marcelo Tosatti
2005-01-05 15:09   ` Jan Harkes
2005-01-05 23:17   ` Nathan Scott
     [not found]   ` <20050105161653.GF13455@fi.muni.cz>
     [not found]     ` <20050105140549.GA14622@logos.cnet>
2005-01-06  9:18       ` Jan Kasprzak
2005-01-06 14:48         ` Paulo Marques
2005-01-06 16:29         ` Alan Cox
2005-01-07 21:49   ` [PATCH 2.4.29-pre3-bk4] fs/coda " Jan Harkes
2005-01-07 21:54   ` [PATCH 2.6.10-mm2] " Jan Harkes
2004-11-04 16:01 Linux-2.6.9 won't allow a write to a NTFS file-system linux-os
2004-11-04 16:48 ` Giuseppe Bilotta
2004-11-04 17:09   ` linux-os
2004-11-04 17:40     ` Giuseppe Bilotta
2004-11-04 17:46     ` Mathieu Segaud
2004-11-04 22:17     ` Anton Altaparmakov
2004-11-04 22:18       ` Anton Altaparmakov
2004-11-04 22:38       ` linux-os
2004-11-05 14:43         ` Rahul Karnik
2004-11-05  1:46     ` Horst von Brand
2004-11-05 12:41       ` linux-os
2004-10-18 22:45 Linux v2.6.9 Linus Torvalds
2004-10-18 23:27 ` Thomas Zehetbauer
2004-10-19  2:54 ` Eric W. Biederman
2004-10-19 16:55   ` Jesper Juhl
2004-10-19 14:36 ` Linux v2.6.9... (compile stats) John Cherry
2004-10-19 16:18   ` Matthew Dharm
2004-10-19 16:49     ` viro
2004-10-19 21:37     ` John Cherry
2004-10-20 22:11     ` John Cherry
2004-10-20 22:41       ` viro
2004-10-21  0:12         ` Linus Torvalds
2004-10-21  0:29           ` Jeff Garzik
2004-10-21  0:44             ` viro
2004-10-21  1:55             ` viro
2004-10-21  1:59               ` Jeff Garzik
2004-10-21  2:24                 ` viro
2004-10-21  2:37                   ` Jeff Garzik
2004-10-21  4:35                     ` viro
2004-10-21  8:57                       ` Jeff Garzik
2004-10-20 22:50       ` Dave Jones
2004-10-19 17:38 ` Linux v2.6.9 and GPL Buyout Jeff V. Merkey
2004-10-19 19:13   ` Russell King
2004-10-19 19:04     ` Jeff V. Merkey
2004-10-19 19:24   ` Kurt Wall
2004-10-19 19:12     ` Jeff V. Merkey
2004-10-19 20:01     ` Richard B. Johnson
2004-10-19 20:39       ` Matt Mackall
2004-10-20  0:06         ` Richard B. Johnson
2004-10-20  5:21           ` Matt Mackall
2004-10-19 19:28   ` Andre Hedrick
2004-10-19 19:10     ` Jeff V. Merkey
2004-10-19 19:30   ` Rik van Riel
2004-10-19 19:05     ` Jeff V. Merkey
2004-10-19 20:14       ` Diego Calleja
2004-10-19 19:41         ` Jeff V. Merkey
2004-10-20  8:27           ` Bernd Petrovitsch
2004-10-20  8:45             ` Jens Axboe
2004-10-19 19:47         ` Jeff V. Merkey
2004-10-19 20:05     ` Richard B. Johnson
2004-10-19 19:38       ` Jeff V. Merkey
2004-10-19 20:30         ` Thomas Gleixner
2004-10-19 20:15           ` Jeff V. Merkey
2004-10-22 23:22           ` Tonnerre
2004-10-19 19:45   ` Ross Biro
2004-10-19 19:36     ` Jeff V. Merkey
2004-10-19 19:54   ` David Johnson
2004-10-19 19:55   ` viro
2004-10-19 19:25     ` Jeff V. Merkey
2004-10-19 20:38   ` Dax Kelson
2004-10-19 20:09     ` Jeff V. Merkey
2004-10-19 22:16       ` Jim Nelson
2004-10-19 22:57         ` Bernd Petrovitsch
2004-10-19 22:27       ` Scott Robert Ladd
2004-10-20 19:41         ` Bill Davidsen
2004-10-20  1:15       ` Horst von Brand
2004-10-20  1:16       ` Bastiaan Spandaw
2004-10-20 19:35         ` Bill Davidsen
2004-10-20  3:45       ` Ryan Anderson
2004-10-20  4:18         ` Lee Revell
2004-10-20  4:41           ` Lee Revell
2004-10-20 11:49             ` Richard B. Johnson
2004-10-29 12:12               ` Semaphore assembly-code bug linux-os
2004-10-29 14:46                 ` Linus Torvalds
2004-10-29 15:11                   ` Andi Kleen
2004-10-29 18:18                     ` Linus Torvalds
2004-10-29 18:35                       ` Richard Henderson
2004-10-29 16:06                   ` Andreas Steinmetz
2004-10-29 17:08                     ` linux-os
2004-10-29 18:06                       ` Linus Torvalds
2004-10-29 18:39                         ` linux-os
2004-10-29 19:12                           ` Linus Torvalds
2004-11-01  1:31                             ` linux-os
2004-11-01  5:49                               ` Linus Torvalds
2004-11-01 20:23                               ` dean gaudet
2004-11-01 20:52                                 ` linux-os
2004-11-01 21:23                                   ` dean gaudet
2004-11-01 22:22                                     ` linux-os
2004-11-01 21:40                                   ` Linus Torvalds
2004-11-01 21:46                                     ` Linus Torvalds
2004-11-02 15:02                                       ` linux-os
2004-11-02 16:02                                         ` Linus Torvalds
2004-11-02 16:06                                           ` Linus Torvalds
2004-11-02 16:51                                             ` linux-os
2004-11-01 22:16                                     ` linux-os
2004-11-01 22:26                                       ` Linus Torvalds
2004-11-01 23:14                                         ` linux-os
2004-11-01 23:42                                           ` Linus Torvalds
2004-11-03  1:52                                       ` Horst von Brand
2004-11-03 21:24                                       ` Bill Davidsen
2004-11-02  6:37                                     ` Chris Friesen
2004-10-29 18:58                         ` Andreas Steinmetz
2004-10-29 19:15                           ` Linus Torvalds
2004-10-29 19:40                             ` Andreas Steinmetz
2004-10-29 19:56                               ` Linus Torvalds
2004-10-29 22:07                                 ` Jeff Garzik
2004-10-29 23:50                               ` dean gaudet
2004-10-30  0:15                                 ` Linus Torvalds
2004-10-29 23:37                         ` dean gaudet
2004-10-29 17:22                   ` linux-os
2004-10-29 17:55                     ` Richard Henderson
2004-10-29 18:17                       ` linux-os
2004-10-29 18:42                         ` Linus Torvalds
2004-10-29 18:54                           ` Linus Torvalds
2004-10-30  3:35                           ` Jeff Garzik
2004-10-29 19:20                     ` Linus Torvalds
2004-10-29 19:26                       ` Linus Torvalds
2004-10-29 21:03                       ` Linus Torvalds
2004-10-29 17:57                   ` Richard Henderson
2004-10-29 18:37                   ` Gabriel Paubert
2004-10-20  5:58           ` Linux v2.6.9 and GPL Buyout John Alvord
2004-10-20 14:42           ` Martin Waitz
2004-10-21 23:59       ` Kelledin
2004-10-22  8:46       ` Bernd Petrovitsch
2004-10-22  9:07       ` David Weinehall
2004-10-22 16:15         ` Jeff V. Merkey
2004-10-22 17:52           ` Al Viro
2004-10-22 17:22             ` Jeff V. Merkey
2004-10-22 19:37               ` Jeff V. Merkey
2004-10-22 20:46                 ` Grahame White
2004-10-22 20:58                 ` Buddy Lucas
2004-10-22 21:00                 ` Richard B. Johnson
2004-10-22 21:03                 ` Thomas Gleixner
2004-10-23 12:33                 ` Bernd Petrovitsch
2004-10-24 14:15                 ` Kai Henningsen
2004-10-27  1:45                 ` Horst von Brand
2004-10-24 11:00           ` Matthias Andree
2004-10-24 14:13           ` Kai Henningsen
2004-10-25 18:44             ` Bill Davidsen
2004-10-20 19:46     ` Bill Davidsen
2004-10-19 21:02   ` Pekka Pietikainen
2004-10-19 20:27     ` Jeff V. Merkey
2004-10-22  6:54       ` Erik Andersen
2004-10-22 16:12         ` Jeff V. Merkey
2004-10-19 21:17     ` Paul Fulghum
2004-10-20 20:41     ` Geert Uytterhoeven
2004-10-23 13:43       ` James Bruce
2004-10-19 21:26   ` Ramón Rey Vicente
2004-10-19 22:52   ` Buddy Lucas
2004-10-20 23:43   ` Eric Bambach
2004-10-20 23:48     ` Eric Bambach
2004-10-20 23:59     ` Hua Zhong
2004-10-21  0:13     ` Russell Miller
2004-10-21  0:18       ` Adam Heath
2004-10-21 10:16       ` Horst von Brand
2004-10-22  8:48   ` Ingo Molnar
2004-10-22 16:15     ` Jeff V. Merkey
2004-10-23  0:14   ` Jon Masters
2004-10-22 23:46     ` Jeff V. Merkey
2004-10-23  0:57       ` Jon Masters
2004-10-23  4:42         ` Jeff V. Merkey
2004-10-23  6:32           ` Nick Piggin
     [not found]             ` <20041023064538.GA7866@galt.devicelogics.com>
2004-10-23  7:20               ` Jeff V. Merkey
2004-10-23 10:11           ` Gene Heskett
2004-10-23 16:28           ` Linus Torvalds
2004-10-24  2:48             ` Jesper Juhl
2004-10-24  5:11             ` Jeff V. Merkey
2004-10-24 11:14               ` Jon Masters
2004-10-24 11:50               ` Jim Nelson
2004-10-24 15:35               ` Ingo Molnar
2004-10-24 15:53               ` Bernd Petrovitsch
2004-10-31 23:14               ` Jan 'JaSan' Sarenik
2004-10-24  2:11           ` Buddy Lucas
2004-10-23  0:38     ` Lee Revell
2004-10-23  0:07       ` Jeff V. Merkey
2004-10-23  1:06         ` Lee Revell
2004-10-21  2:41 ` Linux v2.6.9 (Strange tty problem?) Paul
2004-10-21  9:07   ` Alan Cox
2004-10-21 12:39     ` Russell King
2004-10-21 13:20     ` Paul Fulghum
2004-10-21 15:37       ` Alan Cox
2004-10-21 17:00         ` Paul Fulghum
2004-10-21 15:47       ` Paul Fulghum
2004-10-21 18:12     ` Paul Fulghum
2004-10-31 21:11 ` Linux v2.6.9 dies when starting X on radeon 9200 SE PCI Helge Hafting

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.