Linux v2.6.9...
Linus Torvalds
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thomas Zehetbauer
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 tho...@hostmaster.org for key
Programmer: A biological machine designed to convert caffeine into code.
Eric W. Biederman
> 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
John Cherry
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
che...@osdl.org
503-626-2455x29
Open Source Development Labs
Matthew Dharm
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
--
Matthew Dharm Home: mdhar...@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
Jeff V. Merkey
>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
Russell King
> 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
Kurt Wall
>
> 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.
Andre Hedrick
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
Rik van Riel
> 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
Jeff V. Merkey
>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 V. Merkey
>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
Ross Biro
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.
Richard B. Johnson
> 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.
Jeff V. Merkey
>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)
Jeff V. Merkey
>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
David Johnson
>
> 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.
Jeff V. Merkey
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
Diego Calleja
> 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?
Jeff V. Merkey
>El Tue, 19 Oct 2004 13:05:34 -0600 "Jeff V. Merkey" <jme...@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
Jeff V. Merkey
> 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
Jeff V. Merkey
>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
Thomas Gleixner
> 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
Dax Kelson
> 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
Matt Mackall
> 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.
Jeff V. Merkey
>>
>>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
Pekka Pietikainen
> 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.
Paul Fulghum
> 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
pau...@microgate.com
Ramón Rey Vicente
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 rrey...@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-----
Jeff V. Merkey
>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
Jim Nelson
<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>
Scott Robert Ladd
> 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
Buddy Lucas
> 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
Bernd Petrovitsch
> <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
Richard B. Johnson
> 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.
Bastiaan Spandaw
> >>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
Ryan Anderson
> 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
Lee Revell
> 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
Lee Revell
> 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.
Matt Mackall
> 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.
John Alvord
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
Bernd Petrovitsch
[...]
> 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
-
Jens Axboe
> 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
Richard B. Johnson
> 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.
Horst von Brand
> 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
Martin Waitz
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
Bill Davidsen
> 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 <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Bill Davidsen
> 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 <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Geert Uytterhoeven
> 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.
>
> (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 -- ge...@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
John Cherry
> 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
> > che...@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 majo...@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
che...@osdl.org
503-626-2455x29
Open Source Development Labs
vi...@parcelfarce.linux.theplanet.co.uk
> 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...
Eric Bambach
> 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
----------------------------------------
Russell Miller
> 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 - rmi...@duskglow.com - Le Mars, IA
Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs.
http://www.duskglow.com - 712-546-5886
Hua Zhong
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
Adam Heath
> 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.
Linus Torvalds
On Wed, 20 Oct 2004 vi...@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
Eric Bambach
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.
Jeff Garzik
>
> On Wed, 20 Oct 2004 vi...@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)
vi...@parcelfarce.linux.theplanet.co.uk
> 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)...
Jeff Garzik
> On Wed, Oct 20, 2004 at 08:29:59PM -0400, Jeff Garzik wrote:
>
>>
>>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)
>
>
> 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
vi...@parcelfarce.linux.theplanet.co.uk
> >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.
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...
Jeff Garzik
> 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
Paul
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
s...@pobox.com
machine is an older pIIx2 @400 running Gentoo
.config is attached
Dave Jones
> 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
vi...@parcelfarce.linux.theplanet.co.uk
> vi...@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?
Bill Davidsen
> On Tue, 2004-10-19 at 22:09, Jeff V. Merkey wrote:
>
>
>>>>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.
>
>
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 <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Jeff Garzik
> On Wed, Oct 20, 2004 at 10:37:10PM -0400, Jeff Garzik wrote:
>
>>vi...@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
Horst von Brand
> 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.
> >
> 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
Alan Cox
> permanently unresponsive. (this burst of 'noise', seems to happen
> periodicly, and is a repetition of this:
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
Russell King
> 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
Paul Fulghum
> 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
pau...@microgate.com
Paul Fulghum
> 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
Alan Cox
> 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.
Paul Fulghum
> 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
pau...@microgate.com
Paul Fulghum
> 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
pau...@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,
Kelledin
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?"
John Cherry
> 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
> > che...@osdl.org
> > 503-626-2455x29
> > Open Source Development Labs
Jeff V. Merkey
>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
Jeff V. Merkey
>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.
Erik Andersen
> 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--
vi...@parcelfarce.linux.theplanet.co.uk
> These are x86-based stats, yes? I'm sure other arches will likely tease
> out more...
>
> Those should be straightforward one-line changes, I think... perhaps a job
> for more automated scripting?
>
> 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).
Jesper Juhl
> Linus Torvalds <torv...@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
Bernd Petrovitsch
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
Ingo Molnar
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 <jme...@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
David Weinehall
[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 <t...@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 (/
Jeff V. Merkey
>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
Al Viro
> 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...
Jeff V. Merkey
>On Fri, Oct 22, 2004 at 10:15:00AM -0600, Jeff V. Merkey wrote:
>
>
>>This was written by Novell's stooge Judge Schoefield. It's total
>>fiction. Don't worry, it will get cleared up soon.
>>
>>More bugs to find ....
>>
>>
>
>Out of curiosity, which bugs are you using? Never heard of hallucinogenic
>insects to be found in Utah...
>
>
>
Al,
This is a high traffic list. I am refering to the bugs in my code and
occasionally the ones I find in Linux
that for some reason get challenged everytime I post, then get fixed in
subsequent patches. :-)
So I am sticking to bugs from now on. On the GPL buyout, when stuff gets
released publically,
it will be clear this was an an attempt to help you guys and shut down
the SCO/Canopy/Novell
legal ranglings. I just want to develop code and have fun. Time to get
back to that.
At least the bugs get fixed. There is a hallucinogenic toad (Bufus
Coloradus) the colorado river toad that lives
about 4 hours drive from here, and it secretes 5-DMT when you lick it's
back. Some indian showed this to california hippies
and now the toads are endamgered. It's the closest thing to a
hallucingenic bug I can think of. It's a felony to
possess these toads now in the US (Freeze - drop that toad - your honor,
upon approaching the vehicle I heard
a strange croaking noise coming from the trunk, upon inspection, I found
these -- colorado river toads).
Jeff
Jeff V. Merkey
Jeff V. Merkey
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.
Grahame White
> 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
Buddy Lucas
> 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
Richard B. Johnson
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.
Thomas Gleixner
> Jeff V. Merkey wrote:
> ...
> 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
brian wheeler
list comes from) as would many others, I suspect.
Brian Wheeler
bdwh...@indiana.edu
---------------------
Jeff V. Merkey wrote:
are theirs. They stated we can ship Linux with fear of being sued if we
comply with their Linux Certification Program.
-
Jeff V. Merkey
>I'd like to see the list (as well as knowing which kernel version the
>list comes from) as would many others, I suspect.
>
>Brian Wheeler
>bdwh...@indiana.edu
>
>
>
>
>
I'll post the entire listing with line numbers of the files SCO
[alleges] were taken from UNIX by IBM and others.
Jeff
Jon Masters
> I'll post the entire listing with line numbers of the files SCO
> [alleges] were taken from UNIX by IBM and others.
Jeff,
Could you please digitally sign this mail that you are planning to
send or otherwise provide notorisation that confirms you definately
mean this?
I'd love for you to accept liability for this so we can pass all SCO
enquiries on to you.
Jon.
Tonnerre
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
Jeff V. Merkey
>Jeff,
>
>Could you please digitally sign this mail that you are planning to
>send or otherwise provide notorisation that confirms you definately
>mean this?
>
>I'd love for you to accept liability for this so we can pass all SCO
>enquiries on to you.
>
>Jon.
>
>
>
Yes. I can do even better.
I met with Darl McBride this afternoon regarding the GrokSmear postings
(First time I've ever met him) at SCO's
request -- they invited me over and were trying to put out some sort of
release to correct GrokSmear's attacks.
He gave me the first list, and I am waiting on the second with all the
details. I don't think he likes Linux much but he said he
supported disclosing the whole thing and he said he wanted "his stuff"
out of the Linux tree. I am waiting on Chris Sonntag
and Blake to get me the "approved" listing. I will have it probably
Monday. I'll post it then. Darl gave me the prelimiary
listing but we need to post the final. I'll upload the listing to
ftp.kernel.org://pub/linux/kernel/people/jmerkey
and everyone can look it over. This would be good since it will give
folks the ability to
challenge/correct/remove/modify whatever and get SCO off Linux's back.
Darl seemed like a nice enough sort, but he doesn't care much for Linux
or IBM and he's pretty harsh
on IBM. We argued for 30 minutes about SMP support in Linux and I think
he will just let this one go since
I pointed out that Novell had disclosed the Unixware SMP stuff at
Brainshare and he cannot claim
it as trade secrete any longer. He would not budge on RCU, NUMA, JFS, or
XFS however, and he
also said any IBM employee who contributed SMP code in his opinion may
have misappropriated it
and he would claim any contribution from any IBM employee in Linux.
I will post to kernel.org the complete listing.
Jeff
Jeff V. Merkey
> Jon Masters wrote:
>
>> I'd love for you to accept liability for this so we can pass all SCO
>> enquiries on to you.
>>
>> Jon.
>>
>
Jon and LKML,
Also, I will contact Allan Sullivan who represents IBM in the litigation
and let them know I would be happy to
handle this an an advocate of the Linux Community. Alan Sullivan worked
for me on the TRG/Novell lawsuit
and I know him. I will be more than happy to challenge any claims Linux
folks think are bogus from SCO.
Since I am an expert in IP misappropriation (having wormed and squirmed
my way through it for years) I think I could cut
through at lot of SCO's FUD (And you guys FUD as well). I could very
easily get rid of most of thier claims provide
you guys will take out of the kernel:
XFS, JFS, NUMA for certain. You can maintain them as patches for the
time being and let the vendors
who put them in deal with SCO on what belongs to whom.
I think their SMP claims are very weak at present. Novell has stated
publically you can use their patents. I also
consent to Linux using any patents in my name for SMP in Linux IAW
Novell's offer. Any IBM contributed
code should probably be removed and reimplemented by someone else, then
SCO has no claims on it.
I have no idea what you should do about RCU. On this one, wait for the
posting from SCO, then remove the code
and reimplement it cleanroom. The loss of XFS, JFS, and NUMA is not
critical, and people can always get patches.
If you guys do this, then SCO won't be able to interfere with Redhat or
any Linux companies except the ones they
are suing. Darl showed me the undisclosed IP agreements between Novell
and SCO that are not public, and Novell
**IS** going to lose their Copyright case -- the agreements say they
sold them to SCO -- period, and for some
reason Novell failed to make copies of the documents which is why they
don't have them.