Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> I've never had a reason to want to change the way any device like a TiVO 
> works. So I can't comment on this.

Have you never wanted to improve any aspect of the software in your
cell phone?  In your TV, VCR, DVD player, anything?  In the microwave
oven, maybe?

> On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote:
>> In 95% of the desktop computers, you can't make changes to the OS that
>> runs on it.  Whom is this good for?

> Faulty logic. I have yet to find a computer that I couldn't change the OS on. 

I was not talking about installing another OS, I was talking about
making changes to the OS.  As in, improving one particular driver,
avoiding a blue screen, stuff like that.

> Or do you mean "transferring the recorded copies off the TiVO 
> and on to a different medium"?

Sure.  Such that I can watch shows while wasting time in public
transportation, in an airplane, whatever.

> DRM, I do agree, gets in the way of "Fair Use".

And the fact that TiVO can be, and has been modified remotely to add
restrictions on what users could do, means nothing you do with it is
safe.  You, and everything you've recorded with the TiVO, are at the
mercy of this one company.

> So you're not concerned that you're potentially pushing companies
> that would otherwise be major consumers of GPL'd software away? That
> doesn't make sense to me.

What would their consuming GPL software buy us, if they won't respect
users' freedoms, which is the very reason behind the GPL?

Heck, if they don't want to play by the rules, that's up to them.  But
then they shouldn't use the software at all.

Yeah, I wish they'd rather play by the rules, but if they don't want
to, too bad, for us and for them.

> Why should I repeat Linus' explanation of the ways that GPLv3 violates the 
> spirit of GPLv2?

Don't worry about parrotting here, he hasn't provided that explanation
yet ;-)  Please give it a try.

BTW, what license is Linux licensed under?  It's GPLv2 plus userland
exception, right?  (There's some additional module exception, right?)

> And why shouldn't I pose it as a matter of "Personal Taste"? The
> biggest and most powerful voice in the FSF says "I don't like
> Tivoization" and "I don't like DRM" and when the GPLv3 appears it
> has language that makes those violations of the license.

Have you ever wondered *why* he doesn't like them?

Could it possibly be because they harm the goal of his life, which is
to enable people to live their digital lives in freedom?

> Just like people have started using "GNU/Linux" or "GNU+Linux" to
> refer to Linux

No, no, you got it wrong.  Linux is the kernel.  GNU was the
nearly-complete operating system it fit in.  GNU+Linux is a complete
operating system.

And you don't have to believe me, believe Linus, the initial author of
Linux:

http://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01

  Although linux is a complete kernel

  Sadly, a kernel by itself gets you nowhere. To get a working system
  you need a shell, compilers, a library etc. These are separate parts
  and may be under a stricter (or even looser) copyright. Most of the
  tools used with linux are GNU software and are under the GNU
  copyleft.

> A "TiVO" is not, and has never been, a "General Purpose
> Computational Device".

Err...  Last I looked it was a bunch of general-purpose components,
packaged in a way that made it not look like a general-purpose
computer.  Who gets to decide?  And with what motivations?

> Exactly. And I don't see anything about a TiVO (or any device that, like a 
> TiVO, requires binaries that run on it to be digitally signed) that stops you 
> from exercising the "freedoms" guaranteed by the GPL.

  2. You may modify your copy or copies of the Program or any portion
  of it

>> > if you upload a modified linux kernel to your wireless router that
>> > gives it a 2000 foot range, you've just broken the law

>> At which point, you get punished by the law system.

> But the GPLv2 gives companies a chance to protect themselves from legal 
> actions by people that are sure to follow.

So does the GPLv3.  It might be a bit narrower, to cut on other kinds
of abuses, but all constraints I'm aware of that are mandated by law
can still be achieved.  The point is to forbid disrespecting users'
freedoms to modify the software.  Configuration parameters for the
hardware, needed to comply with regulations, can be easily taken care
of without disrespecting users' freedoms.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

Re: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.

[Kumar Gala]

Some silicons of Freescale processor are the same RapidIO controller,
such as mpc8540/mpc8560 are the same (v0.0), mpc8548/mpc8641 are the
same (v1.0). For v1.0 RapidIO controller, should we use mpc8548 or
mpc8641? Those will make people confused.


Not at all.  On an 8641 it could be

compatible = "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";

which states "this is the 8641 thing and it is compatible
to the 8548 thing".  Perfectly clear.


The concern is this isn't just compatible = "..8641.." "..8548.." but  
something like:


"..8641.." "..8641d.." "..8548.." "..8548e.." "..8543.." "..8543e.."  
"..8572.." "..8572e.." "..8567.." "..8567e.." "..8568.." "..8568e.."



Using IP Block Revision is a
clear choice.


I don't think so.  For one thing, it describes a version of
a cell design, not a version of an actual device.  For another
thing, if I hear "8641" I know what you're talking about (sort
of, anyway), but I draw a blank stare if you say "v1.0".  I'm
sure I'm not the only one.  Concrete names are good.


While I agree concrete names are good, we put these 'blocks' in so  
many devices that using the device to match on is pointless.


I'm all for making up a name like 'Grande', 'Del', 'Janeiro'.  This  
is effective what we did with gianfar.  The name gets picked up  
pretty quickly by people.


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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Theodore Tso]

On Thu, Jun 14, 2007 at 12:00:17AM -0400, [EMAIL PROTECTED] wrote:
> Incidentally, this same logic is what drives the average successful patent
> troll lawsuit - the sued company will buy a license for $25K, just because
> they know that fighting the lawsuit will cost $100K and up.

You're off by a factor of 10-50.  The usual estimates I've heard from
people who ought to know is the minimum ante for fighting a patent
lawsuit is $1 million to $5 million.  Lawyer time and expert witness
time to give the judge a granduate education in the technologies
involved is *expensive* (since the judge may be really smart, but most
judges have no engineering background to speak of, so you have to
explain the technologies involved in terms that make sense to someone
with an honors education with a Bachelor of Arts degree).

Basically, in the US, you get the best justice money can buy.  :-)

- Ted

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Michael Gerdau]

> In Germany, not America. I should have qualified my statement to make it 
> clear 
> I mean "In America". Sorry about the confusion.

You shouldn't say "America" when you mean the "US".

Best wishes,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 GPG-keys available on request or at public keyserver


signature.asc
Description: This is a digitally signed message part.

[patch] uml: better bugs

[Nick Piggin]

Get UML to use the generic bug support rather than arch specific one.

If I insert an artificial bug right before loading init, I get this:

 Kernel panic - not syncing: Kernel mode signal 4

 EIP: 0023:[<0819d501>] CPU: 0 Not tainted ESP: 002b:f7fd4fbc EFLAGS: 0246
Not tainted
EAX:  EBX: 7870 ECX: 0013 EDX: 7870
ESI: 786d EDI: 0011 EBP: f7fd4fd8 DS: 002b ES: 002b
08273bec:  [<0806e814>] show_regs+0x104/0x106
08273c08:  [<08058927>] panic_exit+0x2c/0x4b
08273c18:  [<08080ee7>] notifier_call_chain+0x32/0x5b
08273c38:  [<08080fbd>] __atomic_notifier_call_chain+0x30/0x32
08273c54:  [<08080fee>] atomic_notifier_call_chain+0x2f/0x31
08273c70:  [<08073b88>] panic+0x75/0x131
08273c94:  [<080586c7>] relay_signal+0x87/0x95
08273cb0:  [<0806b9ee>] sig_handler_common_skas+0x9e/0x120
08273cd8:  [<08067738>] sig_handler+0x28/0x4f
08273cec:  [<0806792e>] handle_signal+0x53/0x89
08273d0c:  [<08069f60>] hard_handler+0x18/0x28
08273d1c:  [] transitions+0xf7d598b8/0xfff0


With this patch in place, this is how it looks:

 BUG: failure at init/main.c:779/init_post()!
 Kernel panic - not syncing: BUG!

 EIP: 0023:[<081a65d1>] CPU: 0 Not tainted ESP: 002b:f7f0dfbc EFLAGS: 0246
Not tainted
EAX:  EBX: 69db ECX: 0013 EDX: 69db
ESI: 69d8 EDI: 0011 EBP: f7f0dfd8 DS: 002b ES: 002b
098efedc:  [<0806e9a4>] show_regs+0x104/0x106
098efef8:  [<080589c7>] panic_exit+0x2c/0x4b
098eff08:  [<080818d7>] notifier_call_chain+0x32/0x5b
098eff28:  [<080819ad>] __atomic_notifier_call_chain+0x30/0x32
098eff44:  [<080819de>] atomic_notifier_call_chain+0x2f/0x31
098eff60:  [<08073f28>] panic+0x75/0x131
098eff84:  [<080541d5>] init_post+0xcd/0xe8
098eff9c:  [<08048ad4>] kernel_init+0x8e/0x9a
098effb4:  [<08066dee>] run_kernel_thread+0x41/0x53
098effe0:  [<08058e75>] new_thread_handler+0x62/0x8b
098efffc:  [] 0xa55a5a5a


Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/include/asm-um/bug.h
===
--- linux-2.6.orig/include/asm-um/bug.h 2007-06-04 22:24:19.0 +1000
+++ linux-2.6/include/asm-um/bug.h  2007-06-04 22:24:24.0 +1000
@@ -1,6 +1,6 @@
 #ifndef __UM_BUG_H
 #define __UM_BUG_H
 
-#include 
+#include 
 
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Dmitry Torokhov]

On Wednesday 13 June 2007 21:59, Alexandre Oliva wrote:
> > It *DOES* *NOT* say "All rights that you have". It says "All rights
> > that are granted you by this license".
> 
> I suggest you to reboot into memtest ;-)  The preamble of GPLv2 says:
> 
>   For example, if you distribute copies of such a program, whether
>   gratis or for a fee, you must give the recipients
>   all the rights that you have.
>   

So if I am a sole author of a program and I chose to distribute it under
GPL then all recepients will get _all_ my rights, including right to
re-license the program under BSD or a proprietory license? Yeah, riiight...

Thankfully it is just preamble and not the actual license text.
 
-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ext2 on flash memory

[Ph. Marek]

On Donnerstag, 14. Juni 2007, DervishD wrote:
> Your message is very peculiar... because I already have a similar
> thing working on my system ;))) I tried FSVS and I didn't like it fully
> (don't ask me why, I don't even remember, that was a time ago), so I
> wrote my own system.
Well, if you ever remember (or do a new try), please tell me (or the mailing 
lists) your suggestions/ideas.


> Instead of a complex solution, I opted for a simple (but ad-hoc)
> solution, writing a pre-commit-hook in Perl and a couple of files to
> store the metadata. Very simple but I have all my system configuration
> files (and other files that I want to have versioned) under SVN.
But you'd still need to manually restore the permissions, don't you?
And I think you don't take devices ...
BTW, "fsvs status" is much faster than "svn status" ... sometimes faster than 
find (on cold caches).

> Thanks for your suggestion anyway, because I think that the concept
> (having versioned system files) is interesting and very useful :))
I think so too.


Thank you for your answer!


Regards,

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Michael Gerdau]

> > As a PS to the GPL3 comment here is the basic difference
> > 
> > ROM -   I can't modify the code on the device
> > The creator can't modify the code further on the device
> > 
> > Tivo-   I can't modify the code on the device
> > The owner can modify the code
> > 
> > One is an implicit limitation of the hardware (just like I can't run
> > openoffice on a 4MB PC even though the license gives me the right to
> > try), the other is an artificial restriction.
> > 
> > One case is witholding freedom in the GPL sense by one party while
> > keeping it themselves, the other is a limitation of the system
> > inevitably imposed on everyone.
> 
> I've been following this discussion and I find this interesting.
> Consider these two cases:
> 
> 1.) I ship the device back to the manufacturer, they replace the ROM,
> and ship it back to me.
> 
> 2.) I ship the device back to the manufacturer, they load new code
> into it, and ship it back to me.
> 
> How do these two differ?  Or is it now just a question of the ROM
> being in a socket?  I can't see how the technicalities of how the
> hardware is constructed can change the legality of the software.

At first glance I think a construct where the manufacturer is obliged
to load _MY_ modified software in a timely fashion and at a reasonable
price into the device would fit my understanding of the GPL's spirit
though this leaves room for the definition of timely...

Best,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 GPG-keys available on request or at public keyserver


signature.asc
Description: This is a digitally signed message part.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Oleg Verych wrote:
> Thus, text mode on modern hardware isn't useable that much, only with
> Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
> But it's only option to unfortunately sucking X11, even with memory
> bandwidth, you are talking about.

That's another reason to use the framebuffer console on laptops.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Al Viro]

On Thu, Jun 14, 2007 at 06:44:25AM +0200, Michael Gerdau wrote:
> > able to run you modifications on the same hardware?
 
> Come on! The whole idea of software is to have it run on some HW.
   
> Why would I want to change it in the first place if I can't run it ?


See the difference?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22-rc4-git5 reiserfs: null ptr deref.

[Randy Dunlap]

On Thu, 14 Jun 2007 03:40:56 +0300 Vladimir V. Saveliev wrote:

> Hello
> 
> Randy Dunlap wrote:
> > while running fsx-linux on x86_64 system:
> > 
> thanks, I will take a look.
> 
> Is it reproducible? If yes, would you please try on some earlier kernel?

I ran the test 8 more times, but had no more failures.

I should tell you that the fs parameters in this test were:

blocksize=2048 and mount options: data=journal,notail


> > [ 2213.064351] ReiserFS: sdb1: found reiserfs format "3.6" with standard 
> > journal
> > [ 2213.071516] ReiserFS: sdb1: using journaled data mode
> > [ 2213.083124] ReiserFS: sdb1: journal params: device sdb1, size 8192, 
> > journal first block 34, max trans len 512, max batch 450, max commit age 
> > 30, max trans age 30
> > [ 2213.098843] ReiserFS: sdb1: checking transaction log (sdb1)
> > [ 2213.362156] ReiserFS: sdb1: Using r5 hash to sort names
> > [ 2228.264867] Unable to handle kernel NULL pointer dereference at 
> >  RIP:
> > [ 2228.270363]  [] :reiserfs:do_journal_end+0x5de/0xced
> > [ 2228.279370] PGD 114991067 PUD 105050067 PMD 0
> > [ 2228.283865] Oops:  [1] SMP
> > [ 2228.287044] CPU 0
> > [ 2228.289078] Modules linked in: reiserfs loop
> > [ 2228.293401] Pid: 5280, comm: fsx-linux Not tainted 2.6.22-rc4-git5 #1
> > [ 2228.299834] RIP: 0010:[]  [] 
> > :reiserfs:do_journal_end+0x5de/0xced
> > [ 2228.309076] RSP: 0018:810106c6da48  EFLAGS: 00010286
> > [ 2228.314385] RAX:  RBX: c200102cdf10 RCX: 
> > 81011c861800
> > [ 2228.321512] RDX: 0020 RSI:  RDI: 
> > c20010292220
> > [ 2228.328639] RBP: 810106c6db18 R08: 0002 R09: 
> > 
> > [ 2228.335767] R10: c200102cdf10 R11: 0048 R12: 
> > c200102cbc78
> > [ 2228.342895] R13: c200102cdf10 R14: c20010282000 R15: 
> > 81011e5fe800
> > [ 2228.350024] FS:  2b02d6aa7ae0() GS:80721000() 
> > knlGS:
> > [ 2228.358102] CS:  0010 DS:  ES:  CR0: 8005003b
> > [ 2228.363844] CR2:  CR3: 00010b6ea000 CR4: 
> > 06e0
> > [ 2228.370972] Process fsx-linux (pid: 5280, threadinfo 810106c6c000, 
> > task 81011db7c040)
> > [ 2228.379483] Stack:  8101143ae200 000a9c2c 810106c6da68 
> > 0001
> > [ 2228.387565]  810106c6db38 0020 81011c861800 
> > 81011c5fd000
> > [ 2228.395039]  81010dc7c2d0 0001  
> > 810114b383c0
> > [ 2228.402313] Call Trace:
> > [ 2228.404963]  [] autoremove_wake_function+0x0/0x38
> > [ 2228.411236]  [] :reiserfs:do_journal_end+0xcb9/0xced
> > [ 2228.417766]  [] 
> > :reiserfs:do_journal_begin_r+0x260/0x335
> > [ 2228.424643]  [] :reiserfs:journal_begin+0xb8/0xf6
> > [ 2228.430913]  [] 
> > :reiserfs:reiserfs_do_truncate+0x418/0x4be
> > [ 2228.437961]  [] 
> > :reiserfs:reiserfs_truncate_file+0x1a4/0x2b6
> > [ 2228.445183]  [] 
> > :reiserfs:reiserfs_vfs_truncate_file+0xe/0x10
> > [ 2228.452492]  [] vmtruncate+0xaf/0xd0
> > [ 2228.457632]  [] inode_setattr+0x2b/0x125
> > [ 2228.463120]  [] :reiserfs:reiserfs_setattr+0x191/0x1bf
> > [ 2228.469818]  [] __down_write_nested+0x3d/0xa1
> > [ 2228.475730]  [] notify_change+0x129/0x23a
> > [ 2228.481300]  [] do_truncate+0x63/0x81
> > [ 2228.486521]  [] sys_ftruncate+0xea/0x107
> > [ 2228.492003]  [] system_call+0x7e/0x83
> > [ 2228.497223]
> > [ 2228.498721]
> > [ 2228.498722] Code: 8b 00 66 85 c0 0f 89 97 01 00 00 4c 89 ff 44 89 85 48 
> > ff ff
> > [ 2228.507806] RIP  [] 
> > :reiserfs:do_journal_end+0x5de/0xced
> > [ 2228.514700]  RSP 
> > [ 2228.518190] CR2: 
> > [ 2228.521841] Kernel panic - not syncing: Fatal exception
> > [ 2228.527080] Rebooting in 30 seconds..

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> User B buys the router and modifies the kernel so it drives the WiFi to an 
> output power twice that which it is licensed to carry.
> FCC finds out and prosecutes User B for violating the regulations.

Ok so far.

> FCC then pulls the small companies license until they change their
> hardware so the driver can't push it to transmit at a higher power
> level and levies a fine.

I'd say this is unfair, but if it can happen, then maybe the small
company could have been more careful about the regulations.  There are
various ways to prevent these changes that don't involve imposing
restrictions of modification on any software in the device, all the
way from hardware-constrained output power to hardware-verified
authorized configuration parameters.

> Growing the base of installed GPL covered software,

When this doesn't bring freedom to people, when people can't actually
enjoy the freedoms that the software is supposed to provide, I don't
see why this would be a good thing.  What's the merit in being able to
claim "vendor X chose my Free Software and locked it down such that
users don't get the freedoms I meant for them, and I'm happy about it?"

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Forrest <[EMAIL PROTECTED]> wrote:

> 1.) I ship the device back to the manufacturer, they replace the ROM,
> and ship it back to me.

> 2.) I ship the device back to the manufacturer, they load new code
> into it, and ship it back to me.

> How do these two differ?  Or is it now just a question of the ROM
> being in a socket?  I can't see how the technicalities of how the
> hardware is constructed can change the legality of the software.

I don't see that they differ.  If the software can be replaced, the
manufacturer ought to tell you how to do it.  It doesn't have to do it
for you, it doesn't have to give you the hardware tools needed to do
it, but if you're not able to start from the source code and the
information provided by the manufacturer and get to a modified version
of the software on the device, while the manufacturer could do it,
then the manufacturer is locking you in, and therefore you're not
free.  This is a clear violation of the spirit of the license, even if
the legalese might make room for some such misbehavior.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 14, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:

> Tivo gets sick of the endless flamewars on lkml, signs a copy
> of QNX, pushes it out to the hardware.  No more Linux on Tivo.

What do we lose?

Do we actually get any benefit whatsoever from TiVO's choice of Linux
as the kernel for its device?

Do TiVO customers lose anything from the change from one non-Free
software to another?  (the Linux binary, as shipped in the TiVO, has
become non-Free)

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Michael Gerdau]

> > > The fact is, Tivo didn't take those rights away from you, yet the FSF
> > > says that what Tivo did was "against the spirit". That's *bullshit*.
> >
> > Oh, good, let's take this one.
> >
> >   if you distribute copies of such a program, [...]
> >   you must give the recipients all the rights that you have
> >
> > So, TiVo includes a copy of Linux in its DVR.
> >
> 
> And they give you the same right that they had, which is obtain free software 
> that you can modify and redistribute. There's nothing in there that says they 
> should give you the tools they used after they received the software, which 
> is what you seem to be looking for.

IANAL so I won't comment on the legal aspects of TiVo's doing.

However it definitely is against _MY_ understanding of the spirit
of the GPL. At least to me that's quite obvious. I'm sure you all
know the story of the printer driver RMS couldn't fix that reportedly
made him start the whole FSF business.

Looking at what TiVo did I realize glaring similarities.


I'm in no way related with the FSF. I hereby state I'm not parroting
anyone's else position but have come to this conclusion solely on
my own.


> > TiVo retains the right to modify that copy of Linux as it sees fit.
> >
> > It doesn't give the recipients the same right.
> 
> It does, can't you modify their kernel source? Where does it say you should 
> be 
> able to run you modifications on the same hardware?

Come on! The whole idea of software is to have it run on some HW.
Why would I want to change it in the first place if I can't run it ?

If what they did is actually allowed by the wording of the legal phrases
of the GPLv2 then that IMO is a loophole w/r to the spirit (as I understand)
it and IMO should be plugged.

> The only fear that I have with the whole Tivo saga, is that companies like 
> Dell can use the same thing to say: "Our hardware will only run Company's X 
> distribution of Linux". 

Would not such a restriction voilate the spirit of the GPL ?

Anyway, my simplistic view is:
Once it is under the GPL I could change it and actually make the
changes work as I see fit.

That's what I think my freedom as of the GPL is about.

Now all that needs to be done is make sure the legal phrases are such
that they convince the judges they actually mean this in court too.

Best wishes,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 GPG-keys available on request or at public keyserver


signature.asc
Description: This is a digitally signed message part.

Re: DRI/AGP on AMD64 based machine

[Dave Airlie]

On 6/14/07, Carlo Wood <[EMAIL PROTECTED]> wrote:

On Thu, Jun 14, 2007 at 11:17:50AM +1000, Dave Airlie wrote:
> How do you have a 965G in an amd64 box? does not compute.

Why not?  It's the ASUS P5B Deluxe motherboard with an
Intel P965/ICH8R chipset. The cpu is a QX6700 2.66 GHz,
that's an Intel Core 2 Quad Extreme.

amd64 is just the architecture, not the brand. It's an
all intel machine, if that's what you mean.



x86-64 is an architecture, amd64 is used by some people however in
your case agp-amd64 is not what you wanted, you have a problem with
intel-agp.c then.. which is different than what started this thread..

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

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Oleg Verych]

* From: "H. Peter Anvin"
* Date: Tue, 01 May 2007 14:52:53 -0700
>
> Linus Torvalds wrote:
>> 
>> And yes, I'm literally talking about the *text* modes. Not all of us want 
>> to have fbcon built in - I prefer my text-mode lean and mean and fast as 
>> hell, and if I want a frame buffer, I'll take X11, thank you very much.
>> 
>
> I use framebuffer console pretty much for one purpose -- it sucks less
> memory bandwidth when you're stuck with a UMA configuration.  Text modes
> require random access to the font buffer, which means it hogs the DRAM
> pretty badly, unless the chipset designer decided to burn an 8K SRAM,
> which is still a pretty pricey hunk of chip real estate.

When i first booted new Intel dualcore PC with

04:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 
Silent]

back in November i discovered, that graphic/BIOS and normal text mode
aren't working right from power-on. I.e. it is with snow and random
switch on/off behavior, unless you do some reset button pushing.

Even after that is OK, shiny new 19" LCD from Sony with black screen and
glass in front of it in 80x25 mode shows contents in kind of unfocused
form. Yes it's because discrete pixels are not matching this legacy
resolution; standard graphic mode is so clear-cut, that i even can't
focus on it myself ;).

Thus, text mode on modern hardware isn't useable that much, only with
Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
But it's only option to unfortunately sucking X11, even with memory
bandwidth, you are talking about.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Willy Tarreau]

On Wed, Jun 13, 2007 at 03:06:51PM -0700, Linus Torvalds wrote:
> And I actually am of the very firm opinion that a world with gray areas 
> (and purple, and pink, and green) is a hell of a lot better than one where 
> everything is black-and-white.

agreed, because you cannot imagine at the beginning all fair uses of your
project. It's a good thing that people can use it, thinking "hey, it's not
explicitly allowed but I think I can defend my case".

> Only lawyers want a black-and-white world.

not really. They would lose their job. They need a gray world to get
customers, but they want to decide what half is black and what half
is white in front of the judge depending on their customer's needs.

> Indeed. And it's _fine_ to even be in it "just to make a quick buck". We 
> do want all kinds of input. I think the community is much healthier having 
> lots of different reasons for people wanting to be involved, rather than 
> concentrating on just some specific reason.
> 
> For some it's the technology. For some it's the license. For some it's 
> just a thing to pass boredom. Others like to learn. Whatever. It's all 
> good!

And I think that for many people (including myself), it's all of these in
this order :
  - something to learn (when you're at school)
  - something to pass boredom (when you're at school too)
  - the technology (when you're working on designing new products)
  - the license (when you finally try to put your products on the market)

Regards,
Willy

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

Re: [PATCH] Fix race condition about network device name allocation

[Jay Vosburgh]

The following patch (based on a patch from Stephen Hemminger
<[EMAIL PROTECTED]>) removes use after free conditions in
the unregister path for the bonding master.  Without this patch, an
operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
would trigger a NULL pointer dereference in sysfs.  I was not able to
induce the failure with the non-sysfs code path, but for consistency I
updated that code as well.

I also did some testing of the bonding /proc file being open
while the bond is being deleted, and didn't see any problems there.

Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 223517d..6287ffb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4345,8 +4345,8 @@ static void bond_free_all(void)
bond_mc_list_destroy(bond);
/* Release the bonded slaves */
bond_release_all(bond_dev);
-   unregister_netdevice(bond_dev);
bond_deinit(bond_dev);
+   unregister_netdevice(bond_dev);
}
 
 #ifdef CONFIG_PROC_FS
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index a122baa..60cccf2 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -164,9 +164,9 @@ static ssize_t bonding_store_bonds(struct class *cls, const 
char *buffer, size_t
printk(KERN_INFO DRV_NAME
": %s is being deleted...\n",
bond->dev->name);
-   unregister_netdevice(bond->dev);
bond_deinit(bond->dev);
bond_destroy_sysfs_entry(bond);
+   unregister_netdevice(bond->dev);
rtnl_unlock();
goto out;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DRI/AGP on AMD64 based machine

[Carlo Wood]

On Thu, Jun 14, 2007 at 11:17:50AM +1000, Dave Airlie wrote:
> How do you have a 965G in an amd64 box? does not compute.

Why not?  It's the ASUS P5B Deluxe motherboard with an
Intel P965/ICH8R chipset. The cpu is a QX6700 2.66 GHz,
that's an Intel Core 2 Quad Extreme.

amd64 is just the architecture, not the brand. It's an
all intel machine, if that's what you mean.

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

l-k-digest downtime + bounces

[Matt Domsch]

lists.us.dell.com hosts digest forms of lkml: linux-kernel-digest and
linux-kernel-daily-digest.  In the process of moving lists.us.dell.com
new hardware and a new OS, some messages sent to lkml this evening may
have bounced or been dropped by the digester.  This would only affect
those people subscribed to one of the digest forms of the list.

I apologize for the inconvenience.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm 4/7] PM: Remove suspend and resume support from struct device_type

[Dmitry Torokhov]

On Wednesday 13 June 2007 18:20, Kay Sievers wrote:
> Dmitry, you added this recently, is this used in any code you plan to
> merge soon?
>

Yes, I will need it to implement input device resume (mainly to restore LED
state and repeat rate for keyboards).
 
-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Bron Gondwana]

On Thu, Jun 14, 2007 at 02:52:48AM +0100, Alan Cox wrote:
> > What if TiVo had put the kernel in a burned-in ROM (not flash, or on a
> > flash ROM with no provision for reprogramming it)?  Would that also
> > violate the "spirit" of the GPL?  Must any device that wishes to include
> > GPL code include additional hardware to support replacing that code
> > (even if that hardware is otherwise superfluous)?
> 
> As a PS to the GPL3 comment here is the basic difference
> 
> ROM   -   I can't modify the code on the device
>   The creator can't modify the code further on the device
> 
> Tivo  -   I can't modify the code on the device
>   The owner can modify the code 

Tivo gets sick of the endless flamewars on lkml, signs a copy
of QNX, pushes it out to the hardware.  No more Linux on Tivo.

You also can't replace that but Tivo can.  As I see it the two
are completely orthagonal:

a) Can anyone but the manufacturer upload new software into a
   a device without taking extreme measures (soldering a new
   public-key-containing-chip onto the board)

b) Is the software currently installed on a device licenced under
   a rule which requires the distributor to also distribute source
   code upon request.

Now I think it would reasonable to ask that the source code be able
to be built by [same compiler, same flags, same ...] to produce an
identical binary to the one running on the device so you can confirm
that it's exactly the same code.  That's separate from being able to
upload a changed binary.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Valdis . Kletnieks]

On Thu, 14 Jun 2007 04:56:40 +0200, Adrian Bunk said:

> Reality check:
> 
> Harald convinced companies that they have to provide the private keys 
> required to run the Linux kernel they ship on their hardware.

No, the *real* reality check:

The operative words here are "convinced companies" - as opposed to "convinced
a judge to rule that private keys are required to be disclosed". (I just
checked around on gpl-violations.org, and I don't see any news items that say
they actually generated citable case law on the topic of keys...)

Harald convinced companies that it was easier/cheaper/faster to provide the
private keys than to continue in a long legal battle with an uncertain outcome.
If the company estimates the total loss due to keys being released is US$100K,
but the costs of taking it to court are estimated at US$200K, it's obviously
a win (lesser loss, actually) for the company to just fold.

Incidentally, this same logic is what drives the average successful patent
troll lawsuit - the sued company will buy a license for $25K, just because
they know that fighting the lawsuit will cost $100K and up.




pgpSVHgM8qvvb.pgp
Description: PGP signature

Re: cannot set IP for ethernet

[David Miller]

From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 14 Jun 2007 13:53:41 +1000

> Actually in his case it's because 2.6.22-rc4-git2 doesn't have the
> following changeset.

It's on the way, it just hasn't been picked up yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cannot set IP for ethernet

[Herbert Xu]

On Tue, Jun 12, 2007 at 04:06:25PM +0200, Patrick McHardy wrote:
> Oliver Neukum wrote:
> > with 2.6.22-rc4-git2 I am getting errors when setting IP for ethernet
> > interfaces:
> > 
> > ioctl(4, SIOCSIFADDR, 0x7fff94931600)   = -1 ENOBUFS (No buffer space 
> > available)
> > 
> > The error is independant of the interface. It happens to all interfaces.
> > There's nothing in the syslog.
> > 
> > valisk:/home/oliver # uname -a
> > Linux valisk 2.6.22-rc4-git2-default #3 SMP Tue Jun 12 13:27:54 CEST 2007 
> > x86_64 x86_64 x86_64 GNU/Linux
> 
> This can happen if the initial inetdev allocation when the netdevice is
> registered fails. I think it would make sense to try to allocate again
> when adding addresses in that case, otherwise there is no way of
> recovery other than unregistering and registering the device again.

Actually in his case it's because 2.6.22-rc4-git2 doesn't have the
following changeset.

Let me have a think about your approach too.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
commit 6363097cc4d182f93788131b5d8f72aa91d950a0
Author: Herbert Xu <[EMAIL PROTECTED]>
Date:   Thu Jun 7 18:35:38 2007 -0700

[IPV4]: Do not remove idev when addresses are cleared

Now that we create idev before addresses are added, it no longer makes
sense to remove them when addresses are all deleted.

Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

6363097cc4d182f93788131b5d8f72aa91d950a0
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index fa97b96..abf6352 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -327,12 +327,8 @@ static void __inet_del_ifa(struct in_device *in_dev, 
struct in_ifaddr **ifap,
}
 
}
-   if (destroy) {
+   if (destroy)
inet_free_ifa(ifa1);
-
-   if (!in_dev->ifa_list)
-   inetdev_destroy(in_dev);
-   }
 }
 
 static void inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 22:56:40 Adrian Bunk wrote:
> On Wed, Jun 13, 2007 at 10:43:14PM -0400, Daniel Hazelton wrote:
> > On Wednesday 13 June 2007 22:08:27 Adrian Bunk wrote:
> > > On Wed, Jun 13, 2007 at 09:40:13PM -0400, Daniel Hazelton wrote:
> > > > On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote:
> >
> >...
> >
> > > > > Either private keys required to run the kernel on the hardware are
> > > > > always considered part of "the complete source code" or they are
> > > > > never part of it.
> > > >
> > > > No. It all depends on the use-case. If the hardware is designed for
> > > > the user to install their own, custom versions of the code on then
> > > > the signing keys are part of the source as defined by the GPLv2.
> > > >
> > > > If, OTOH, the hardware was never meant for the end-user to install
> > > > custom versions of the software on, then while the signing keys are
> > > > still *technically* part of the source, in practice they are not.
> > > > Why? Because in most of those cases the end-user isn't granted the
> > > > right to install and run custom binaries on the hardware. If the
> > > > manufacturer provided the signing keys they'd be facilitating the
> > > > commission of a crime. (call it "Breach of Contract")
> > > >...
> > >
> > > Repetition doesn't let wrong things become true.
> > >
> > > Where does the GPLv2 talk about the distinction you are trying to make
> > > based on distributor intentions?
> > >
> > > We are talking about the GPLv2 licence text, not about what you would
> > > personally prefer.
> >
> > The GPLv2 doesn't have to cover this distinction to make it a reality.
> > This distinction is *EXACTLY* the type of distinction a lawyer will make
> > when arguing the point.
> >...
>
> Reality check:
>
> Harald convinced companies that they have to provide the private keys
> required to run the Linux kernel they ship on their hardware.

In Germany, not America. I should have qualified my statement to make it clear 
I mean "In America". Sorry about the confusion.

DRH

>
> cu
> Adrian



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 22:38:05 Alexandre Oliva wrote:
> On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote:
> >
> > Exactly. They don't. What TiVO prevents is using that modified version on
> > their hardware. And they have that right, because the Hardware *ISN'T*
> > covered by the GPL.
>
> Indeed, TiVO has this legal right.  But then they must not use
> software under the GPLv3 in it.  And, arguably, they must not use
> software under the GPLv2 either.

Yes. It can be argued. But I cannot find *ANYTHING* in the GPLv2 that stops 
anyone from doing that, unless you add extra meaning to one specific clause. 
(And I am willing to admit that *MOST* people do give it that extra meaning)

> > In the case of 99% of the hardware targeted by the clause of the GPLv3
> > you elucidate on, the "ability to install modified versions of the
> > software" was *NOT* intended for that use, nor was it intended for
> > *ANYONE* *EXCEPT* trained service personell to have *ACCESS* to that
> > functionality. Arguing otherwise is just idiotic - I have never found a
> > piece of "high tech" hardware (like a TiVO) that was designed for the
> > end-user to modify. (yes, installing a new version of the linux kernel is
> > "modifying" the system)
>
> It's about time for a change for better, wouldn't you think?

I've never had a reason to want to change the way any device like a TiVO 
works. So I can't comment on this.

> In 95% of the desktop computers, you can't make changes to the OS that
> runs on it.  Whom is this good for?

Faulty logic. I have yet to find a computer that I couldn't change the OS on. 
I have run Linux on 3 different Mac's, every x86 machine I've ever owned and 
even had it running on my Palm. Whats more is that I have *never* heard of a 
person that knows what they are doing not being able to change the OS on a 
desktop computer.

> > And? They distribute the kernel source - as they recieved it - in
> > compliance with the GPL.
>
> This makes it seem like you think that passing on the source code is
> enough to comply with the GPL.  Check your assumptions.  It's not.

Hrm. Strange, but thats what most companies think. Hell, it even says that you 
have to do just that in the GPL. If you're talking about the fact that it can 
be argued that they are "distributing" Linux by selling their boxes and its a 
modified version then I'll agree with you. 

> >> to prohibit people from removing locks that stop them from doing
> >> things they're legally entitled to do
> >
> > What "Legally Entitled" things?
>
> Time shifting of any shows, creating copies of shows for personal use,
> letting others do so.  Think fair use, and how TiVO software and DRM
> in general gets in the way.

I thought that time shifting and creating personal copies was what the TiVO 
did already. Or do you mean "transferring the recorded copies off the TiVO 
and on to a different medium"? If that is what you mean by "Creating Copies" 
then, IIRC, you're wrong. DRM, I do agree, gets in the way of "Fair Use".

> > And... You do realize that almost every difference between the GPLv2
> > and the GPLv3 is going to cause a hell of a lot of problems?
>
> For those who are not willing to abide by the spirit of the license,
> yes.  Does it look like I'm concerned about them?  If they're willing
> to look for and maybe even find holes in the license to disrespect
> users' freedoms, why should I worry about the problems that plugging
> these holes is going to cause them?  If they'd taken the spirit of the
> GPL for what it is, instead of looking for loopholes, this improved
> wording wouldn't be causing them any problems whatsoever.

Okay. So you're not concerned that you're potentially pushing companies that 
would otherwise be major consumers of GPL'd software away? That doesn't make 
sense to me.

> > The fact that the GPLv3 is designed to prevent things that RMS
> > *PERSONALLY* finds distasteful - DRM and the like - is a big
> > turn-off for a *LOT* of people.
>
> This is a pretty sad accusation.  2/3s of the Free Software packages
> use the GPL with its existing spirit, and you still haven't shown that
> any changes proposed in GPLv3 fail to abide by the same spirit.  That
> some (many?) people misunderstood or disregarded the spirit is an
> unfortunate fact, but trying to pose the patching that's going into
> GPLv3 as if it was a matter of personal taste, rather than improved
> compliance with the spirit, is unfair and uncalled for.

Why should I repeat Linus' explanation of the ways that GPLv3 violates the 
spirit of GPLv2?

And why shouldn't I pose it as a matter of "Personal Taste"? The biggest and 
most powerful voice in the FSF says "I don't like Tivoization" and "I don't 
like DRM" and when the GPLv3 appears it has language that makes those 
violations of the license. Just like people have started using "GNU/Linux" 
or "GNU+Linux" to refer to Linux - a big voice spoke and 

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Valdis . Kletnieks]

On Wed, 13 Jun 2007 23:40:47 -0300, Alexandre Oliva said:
> On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> 
> > (and, in the case of a TiVO, the signing 
> > keys are part of the installation, not the running or building.
> 
> Is installation not a precondition for running?

If a company sells you hardware that includes a ROM that contains GPL'ed
software, are they in violation of the GPL if they don't include a ROM burner
in the hardware?  Or are ROM burners like compilers, where you have to supply
your own?



pgp2LK3ARvgiY.pgp
Description: PGP signature

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Linus Torvalds]

On Thu, 14 Jun 2007, Adrian Bunk wrote:
> 
> "For an executable work, complete source code means all the source code 
> for all modules it contains, plus any associated interface definition 
> files, plus the scripts used to control compilation and installation of 
> the executable."
> 
> The question is whether this includes private keys.

No. That's the question as the FSF would like to frame it.

But the real fact is that it *not* the right question.

You can install Linux on a Tivo all you like. Take out the harddisk, 
install your own version of Linux on it, and put it back in. That's pretty 
much how Tivo installs Linux on the things too, afaik, although they don't 
need to take the disk out (since they just assemble it).

No magic needed. In fact, no keys needed.

Now, maybe the hardware/firmware knows to expect a certain SHA1 on that 
disk, that's a different issue. Tivo could even tell you exactly what the 
SHA1 they are checking is. Maybe they have a list of SHA1's, and maybe 
they have a way to upgrade THEIR OWN FIRMWARE with new SHA1's, and they 
could still tell you all of them, and be very open.

And you could actually replace their copy of Linux with another one. It 
would have to have the same SHA1 to actually start _running_, but that's 
the hardware's choice. 

See? No private keys needed. No magic install scripts. It really _is_ that 
easy.

Of course, using private keys, and signing the image with them is possibly 
a technically more flexible/easier/more obvious way to do it, but in the 
end, do you really want to argue technical details?

But I think the whole thing is totally misguided, because the fact is, the 
GPLv2 doesn't talk about "in place" or "on the same hardware". 

So take another example: I obviously distribute code that is copyrighted 
by others under the GPLv2. Do I follow the GPLv2? I sure as hell do! But 
do I give you the same rights as I have to modify the copy on 
master.kernel.org as I have? I sure as hell DO NOT!

So by the idiotic logic of "modifying in place", I'm violating the GPLv2 
every time I'm makign a release - because I make Linux available, but I 
don't actually give people the "same rights" to that particular copy that 
I have! Oh horrors of horrors! You need to make a _copy_ of the thing I 
distribute, and then you have the same rights I have to that _copy_, but 
you never had the same rights to the thing I actually distributed!

And here's a big clue for people: anybody who thinks that I'm violating 
the GPLv2 by not giving out my private SSH key to master.kernel.org is a 
f*cking moron! You have the right to modify *copies* of the kernel I 
distribute, but you cannot actually modify the _actual_ entity that I made 
available!

See any parallels here? Any parallel to a CD-ROM distribution, or a Tivo 
distribution? The rights that the GPLv2 gives to "the software", is to 
something much bigger than "the particular copy of the software". 

Can people really not see the difference between "the software" and "a 
particular encoded copy of the software"? 

I'm sorry, but people who cannot see that difference are just stupid.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 22:04:04 Alexandre Oliva wrote:
> On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > Still doesn't explain why you have argued that the GPLv3 doesn't
> > attempt to cover hardware and then provide proof that it does.
>
> It doesn't cover hardware, in the same way that it doesn't cover
> patents, and it doesn't cover pro-DRM laws.  It merely arranges, as
> best as we've managed a copyright license to do, that they can't be
> used as excuses (or tools) to disrespect the freedoms that the GPL
> demands all licensees to respect for other users.

Consider this scenario:
Small company A is manufacturing a new WiFi router.
They decide to have it run HURD as the OS.
In complying with the GPLv3 they supply the signing keys and everything else 
needed to install a new kernel on the hardware.
User B buys the router and modifies the kernel so it drives the WiFi to an 
output power twice that which it is licensed to carry.
FCC finds out and prosecutes User B for violating the regulations.
FCC then pulls the small companies license until they change their hardware so 
the driver can't push it to transmit at a higher power level and levies a 
fine.
Small company A loses the money paid on the fine, has to recall all the 
devices that can be modified (through software) to break the law at a massive 
cost *AND* has to redesign their hardware. The total cost drives the company 
into bankruptcy.

Small companies C,D and E, in order to avoid the fate of small company A, 
purchases a license for proprietary OS "F" to drive their new hardware.

Net loss: A lot of the users and publicity that "Free Software" used to get, 
because GPLv3 contains language that opens the companies to lawsuits that 
they wouldn't otherwise face.

Which is better: Growing the base of installed GPL covered software, 
or "ethics and morals" that demand the language that has been added to the 
GPLv3 ? Personally I'd like to see proprietary software driven into a very 
small "niche" market or entirely out of existence. However much I want this 
to happen, I cannot be anything *BUT* scared of the GPLv3 simply because I 
see it creating massive problems - and all because of a *small* portion of 
the new language it contains. It has taken almost 15 years for "Free 
Software" to make a dent in the market, and, IMHO, a lot of that is both 
Linux and the "holes" in GPLv2.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[david]

since the latest draft of the GPLv3 now discriminates against some uses 
(industrial vs commercial I think are the terms used) does it even qualify 
as a Open Source lincense anymore by the OSI terms?


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Adrian Bunk]

On Wed, Jun 13, 2007 at 10:43:14PM -0400, Daniel Hazelton wrote:
> On Wednesday 13 June 2007 22:08:27 Adrian Bunk wrote:
> > On Wed, Jun 13, 2007 at 09:40:13PM -0400, Daniel Hazelton wrote:
> > > On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote:
>...
> > > > Either private keys required to run the kernel on the hardware are
> > > > always considered part of "the complete source code" or they are never
> > > > part of it.
> > >
> > > No. It all depends on the use-case. If the hardware is designed for the
> > > user to install their own, custom versions of the code on then the
> > > signing keys are part of the source as defined by the GPLv2.
> > >
> > > If, OTOH, the hardware was never meant for the end-user to install custom
> > > versions of the software on, then while the signing keys are still
> > > *technically* part of the source, in practice they are not. Why? Because
> > > in most of those cases the end-user isn't granted the right to install
> > > and run custom binaries on the hardware. If the manufacturer provided the
> > > signing keys they'd be facilitating the commission of a crime. (call it
> > > "Breach of Contract")
> > >...
> >
> > Repetition doesn't let wrong things become true.
> >
> > Where does the GPLv2 talk about the distinction you are trying to make
> > based on distributor intentions?
> >
> > We are talking about the GPLv2 licence text, not about what you would
> > personally prefer.
> 
> The GPLv2 doesn't have to cover this distinction to make it a reality. This 
> distinction is *EXACTLY* the type of distinction a lawyer will make when 
> arguing the point.
>...

Reality check:

Harald convinced companies that they have to provide the private keys 
required to run the Linux kernel they ship on their hardware.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [GIT PULL] Blackfin updates for 2.6.22-rc4

[Jeff Garzik]

Bryan Wu wrote:

Hi Linus:

Sorry for word-wrapping in previous git pull request email.
 
please pull from:


  master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git master


You should run your patch through scripts/checkpatch.pl before 
pushing... there are several notables in there like tons of trailing 
whitespace, use of spaces rather than tabs, lack of whitespace inside 
expressions, etc.


The "line over 80 chars" warning can get a bit obnoxious, if you are 
barely over the limit, but the other warnings are pretty reasonable.



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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Linus Torvalds]

On Wed, 13 Jun 2007, Alexandre Oliva wrote:
> 
> So, TiVo includes a copy of Linux in its DVR.  

Stop right there.

You seem to make the mistake to think that software is something physical.

> TiVo retains the right to modify that copy of Linux as it sees fit.

No. If you were logical (which you are not), you would admit that 
 (a) physical property is very different from intellectual property (the 
 FSF seems to admit that when it suits their needs, not otherwise)
 (b) They never modified "a copy" of Linux - they simply replaced it with
 "another copy" of Linux. The only thing that actually got *modified* 
 was their hardware!

The first copy didn't "morph" into a second copy. There was no "physical" 
software that was molded.  They do need to follow the GPLv2, since clearly 
they _do_ distribute Linux, but you have all the same rights as they do 
with regard to the *software*. 

The fact that they maintained some control of the *hardware* (and some 
software they wrote too) they designed is _their_ choice.

What Tivo did and do, is to distribute hardware that can *contain* a copy 
of Linux (or just about anything else, for that matter - again, there's 
a difference between physical and intellectual property).

And their hardware (and firmware) will run some integrity checks on 
*whatever* copies of software they have.  This is all totally outside 
Linux itself.

Btw, according to your _insane_ notion of "a copy" of software, you can 
never distribute GPL'd software on a CD-ROM, since you've taken away the 
right of people to modify that CD-ROM by burning and fixating it. So 
according to your (obvously incorrect) reading of the GPLv2, every time 
Red Hat sends anybody a CD-ROM, they have restricted peoples right to 
modify the software on that CD-ROM bymaking it write-only.

See? Your reading of the license doesn't _work_. Mine does. What I say is 
that when you distribute software, you don't distribute "a copy" of 
software, you distribute the _information_ about the software, so that 
others can take it and modify it. And notice? My reading of the license 
must be the correct one, since my reading actually makes sense, unlike 
yours.

And yes, when Tivo distributes Linux, they give everybody else all the 
same rights they have - with respect to Linux! No, not with respect to 
their hardware, but that's a totally different thing, and if you cannot 
wrap your mind around the difference between "the software that is on a 
CD" and the "piece of plastic that is the CD", and see that when you 
replace "CD" with any other medium, the equation doesn't change, I don't 
know what to say.

> It doesn't give the recipients the same right.
> 
> Oops.
> 
> Sounds like a violation of the spirit to me.

Only if you extend the license to the *hardware*. Oops. Which it never did 
before. 

In other words, you basically try to change the rules. The GPLv2 clearly 
states that it's about software, not hardware. All the language you quoted 
talks about software.

In other words, the only way to argue that I'm wrong is to try to twist 
the meanings of the words, and say that words only mean one specific thing 
that _you_ claim are their meaning.

And I'm saying you act like Humpty Dumpty when you do. You can argue that 
way all you like, but your argument is nonsensical. It's akin to the 
argument that "God is perfect. Perfect implies existence. Therefore God 
exists".

That kind of argument only works if you *define* the words to suit your 
argument. But it's a logical fallacy.

And I'm saying that the GPLv2 can mroe straightforwardly be read the way I 
read it - to talk about software, and to realize that software is not "a 
copy", it's a more abstract thing. You get Linux when you buy a Tivo (or 
preferably - don't buy it, since you don't like it), and that means that 
they have to give you access to and control over the SOFTWARE. But nowhere 
in the GPL (in the preamble or anywhere else) does it talk about giving 
you control over the HARDWARE, and the only way you can twist the GPLv2 to 
say that is by trying to re-define what the words mean.

And then you call *me* confused? After you yourself admitted that the FSF 
actually agrees with me, and that what Tivo did was not a license 
violation?

Trust me, I'm not the confused person here.

I'm perfectly fine with other people wanting to extend the license to 
cover the hardware, but I am *not* perfectly fine with people then trying 
to claim I'm confused just because I don't agree with them.

Face it: the GPLv3 is a _new_ license. Making funamentally _different_ and 
_new_ restrictions that do not exist in the GPLv2, and do not exist in the 
preamble. Any language attempts to make it appear otherwise are just 
sophistry.

And btw, just to make it clear: as far as I'm concerned, you can read the 
preamble and the word "freedom" and "rigths" _your_ way. I'm not objecting 
to that at all. If you read it so that you think it's wrong to distribute 
GPL'd 

Re: [RFC/PATCH] Documentation of kernel messages

[Valdis . Kletnieks]

On Wed, 13 Jun 2007 12:04:56 PDT, Joe Perches said:

> I believe it better to simply add __FILE__ & __LINE__ to the
> macro rather than some other externally specified unique
> identifier that adds developer overhead and easily gets stale.

There's been plenty of times I've wished for that.  Now if we just found a way
to do something sane for drivers/net/wireless/mac80211/iwlwifi/base.c ;)

Of course, I'm probably atypical - for me, kernel messages come in two forms,
the kind that are immediately obvious at first reading, and the kind that
you end up having to look at the code and wonder WTF? it was doing inside
that never-should-happen-on-this-hardware while loop in the first place... :)



pgpLeFrUK3lgA.pgp
Description: PGP signature

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> Either a device is distributed, like the common PC, that is designed
> for the user to change and update the software on, or, like the PS2
> it isn't designed for that.

Have you ever installed GNU/Linux on a PC "Designed for Microsoft Windows"?

How dare you? ;-)

> If, OTOH, the hardware was never meant for the end-user to install custom 
> versions of the software on, then while the signing keys are still 
> *technically* part of the source, in practice they are not. Why? Because in 
> most of those cases the end-user isn't granted the right to install and run 
> custom binaries on the hardware.

And distributing the GPLed software under this restriction is quite
likely copyright infringement.

> I know this. As I said, I doubt that anyone who tried this in
> America would have the success he has had.

On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote:

>> Are you an idiot, or do you just choose to ignore all proof that
>> doesn't fit your preconceived beliefs?

;-) :-P :-D

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Forrest]

On Thu, Jun 14, 2007 at 02:52:48AM +0100, Alan Cox wrote:
> 
> As a PS to the GPL3 comment here is the basic difference
> 
> ROM   -   I can't modify the code on the device
>   The creator can't modify the code further on the device
> 
> Tivo  -   I can't modify the code on the device
>   The owner can modify the code
> 
> One is an implicit limitation of the hardware (just like I can't run
> openoffice on a 4MB PC even though the license gives me the right to
> try), the other is an artificial restriction.
> 
> One case is witholding freedom in the GPL sense by one party while
> keeping it themselves, the other is a limitation of the system
> inevitably imposed on everyone.

I've been following this discussion and I find this interesting.
Consider these two cases:

1.) I ship the device back to the manufacturer, they replace the ROM,
and ship it back to me.

2.) I ship the device back to the manufacturer, they load new code
into it, and ship it back to me.

How do these two differ?  Or is it now just a question of the ROM
being in a socket?  I can't see how the technicalities of how the
hardware is constructed can change the legality of the software.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Chris Adams <[EMAIL PROTECTED]> wrote:

> Once upon a time, Alexandre Oliva  <[EMAIL PROTECTED]> said:
>> if you distribute copies of such a program, [...]
>> you must give the recipients all the rights that you have

>> So, TiVo includes a copy of Linux in its DVR.  

>> TiVo retains the right to modify that copy of Linux as it sees fit.

>> It doesn't give the recipients the same right.

> Sure it does; you received a program (the kernel) and you can modify it.

If I take the software I received, build it and install it on the same
hardware, it won't run.  Something is missing in the source code I
received, I guess..

If I make changes to the source code, build it, and install it on that
same computer, it won't run.  How is that being able to modify *that*
copy of the program?

If TiVo makes the same changes, builds tehm, and installs it on my
computer, it will run just fine.  How are they passing on the right
they had to me?

> You also received hardware; they don't support modification of that.

They don't have to support them.  They don't have to help me if it
breaks.  But if they can do it and I can't, they're failing to comply
with the spirit of the GPL.

> Nowhere in the license does it say they have to, because the license
> only covers the program.

They can't distribute the program while imposing restrictions on
modification not present in the software license itself.

> Or are you claiming that putting software on hardware makes the result a
> derivative work?  I think it falls under the "mere aggregation" clause.

I tend to agree, in this particular case, but IANAL.  I don't rule out
derivative works in future attempts to find loopholes in the GPL.

> What if TiVo had put the kernel in a burned-in ROM

Then they wouldn't have the ability to change it any more, so there
wouldn't be such a right to pass on to the users.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 22:08:27 Adrian Bunk wrote:
> On Wed, Jun 13, 2007 at 09:40:13PM -0400, Daniel Hazelton wrote:
> > On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote:
> > > On Wed, Jun 13, 2007 at 09:01:28PM -0400, Daniel Hazelton wrote:
> > > > On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote:
> > > > > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote:
> > > > > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> > > > > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]>
> >
> > wrote:
> > > > > > > > On Wed, 13 Jun 2007, Alan Cox wrote:
> > > > > > > >> > find offensive, so I don't choose to use it. It's
> > > > > > > >> > offensive because Tivo never did anything wrong, and the
> > > > > > > >> > FSF even acknowledged that. The fact
> > > > > > > >>
> > > > > > > >> Not all of us agree with this for the benefit of future
> > > > > > > >> legal interpretation.
> > > > > > > >
> > > > > > > > Well, even the FSF lawyers did,
> > > > > > >
> > > > > > > Or rather they didn't think an attempt to enforce that in the
> > > > > > > US would prevail (or so I'm told).  That's not saying what TiVo
> > > > > > > did was right, and that's not saying that what TiVo did was
> > > > > > > permitted by the license. Only courts of law can do that.
> > > > > >
> > > > > > Wrong! Anyone with half a brain can make the distinction. What
> > > > > > TiVO did is entirely legal - they fully complied with the GPLv2.
> > > > > > Note that what they *DON'T* allow people to do is run whatever
> > > > > > version of whatever software they want on their hardware. They
> > > > > > have that right - its the "Free Software Foundation" and the GPL
> > > > > > - regardless of version - is a *SOFTWARE* license. ...
> > > > >
> > > > > The GPLv2 says:
> > > > >
> > > > > "For an executable work, complete source code means all the source
> > > > > code for all modules it contains, plus any associated interface
> > > > > definition files, plus the scripts used to control compilation and
> > > > > installation of the executable."
> > > > >
> > > > > The question is whether this includes private keys.
> > > > > Different people have different opinions regarding this issue.
> > > > >
> > > > > If "the complete source code" includes private keys, the GPLv2
> > > > > requires them to give any costumer the private keys.
> > > > >
> > > > > Fact is that Harald Welte did in several cases successfully
> > > > > convince vendors that private keys are part of the source code if
> > > > > they are required for running the compiled binary on some hardware.
> > > >
> > > > If the hardware was designed for the end-user to change the software
> > > > running on it - including running software that it was never meant to
> > > > run (ie: a complete webserver on cell phone) - then yes, the signing
> > > > keys are a part of the source, as the software running on the device
> > > > is designed to be updated by the user using the provided system.
> > > >
> > > > If, on the other hand, the only "software updates" the user is
> > > > expected to perform are the installation of newer versions of the
> > > > existing code for "Security" or "Bug Fix" reasons then the signing
> > > > keys aren't part of the source.
> > >
> > > Are you an idiot, or do you just choose to ignore all proof that
> > > doesn't fit your preconceived beliefs?
> >
> > Nope. Merely stating a distinction. Either a device is distributed, like
> > the common PC, that is designed for the user to change and update the
> > software on, or, like the PS2 it isn't designed for that. If I find a way
> > to update my PS2 to run Linux and find that it doesn't want to start the
> > "Linux Firmware" because I'm lacking a signing key...
> >
> > In the case of a device that internally runs Linux (or any other GPL'd
> > software) and wasn't designed for the end-user to change the software
> > running on it then the signing keys aren't part of the source. OTOH, if I
> > sell a PC running Linux that requires the kernel be signed then the
> > signing keys *are* part of the source, since a PC is designed for the
> > end-user to change the software running on it.
> >
> > BTW, nice use of irony with that line. Makes me regret letting my fingers
> > get ahead of my brain.
> >
> > > The GPL doesn't give someone distributing the software the choice of
> > > how much to limit the freedom of the user.
> >
> > Never claimed it did. I just wasn't as specific as I should have been
> > when giving my examples.
> >
> > > Either private keys required to run the kernel on the hardware are
> > > always considered part of "the complete source code" or they are never
> > > part of it.
> >
> > No. It all depends on the use-case. If the hardware is designed for the
> > user to install their own, custom versions of the code on then the
> > signing keys are part of the source as defined by the GPLv2.
> >
> > If, OTOH, the hardware was never meant for the end-user to install custom
> > 

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> (and, in the case of a TiVO, the signing 
> keys are part of the installation, not the running or building.

Is installation not a precondition for running?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote:

> Exactly. They don't. What TiVO prevents is using that modified version on 
> their hardware. And they have that right, because the Hardware *ISN'T* 
> covered by the GPL.

Indeed, TiVO has this legal right.  But then they must not use
software under the GPLv3 in it.  And, arguably, they must not use
software under the GPLv2 either.

> In the case of 99% of the hardware targeted by the clause of the GPLv3 you 
> elucidate on, the "ability to install modified versions of the software" was 
> *NOT* intended for that use, nor was it intended for *ANYONE* *EXCEPT* 
> trained service personell to have *ACCESS* to that functionality. Arguing 
> otherwise is just idiotic - I have never found a piece of "high tech" 
> hardware (like a TiVO) that was designed for the end-user to modify. (yes, 
> installing a new version of the linux kernel is "modifying" the system)

It's about time for a change for better, wouldn't you think?

In 95% of the desktop computers, you can't make changes to the OS that
runs on it.  Whom is this good for?

> And? They distribute the kernel source - as they recieved it - in
> compliance with the GPL.

This makes it seem like you think that passing on the source code is
enough to comply with the GPL.  Check your assumptions.  It's not.

>> to prohibit people from removing locks that stop them from doing
>> things they're legally entitled to do

> What "Legally Entitled" things?

Time shifting of any shows, creating copies of shows for personal use,
letting others do so.  Think fair use, and how TiVO software and DRM
in general gets in the way.

> And... You do realize that almost every difference between the GPLv2
> and the GPLv3 is going to cause a hell of a lot of problems?

For those who are not willing to abide by the spirit of the license,
yes.  Does it look like I'm concerned about them?  If they're willing
to look for and maybe even find holes in the license to disrespect
users' freedoms, why should I worry about the problems that plugging
these holes is going to cause them?  If they'd taken the spirit of the
GPL for what it is, instead of looking for loopholes, this improved
wording wouldn't be causing them any problems whatsoever.

> The fact that the GPLv3 is designed to prevent things that RMS
> *PERSONALLY* finds distasteful - DRM and the like - is a big
> turn-off for a *LOT* of people.

This is a pretty sad accusation.  2/3s of the Free Software packages
use the GPL with its existing spirit, and you still haven't shown that
any changes proposed in GPLv3 fail to abide by the same spirit.  That
some (many?) people misunderstood or disregarded the spirit is an
unfortunate fact, but trying to pose the patching that's going into
GPLv3 as if it was a matter of personal taste, rather than improved
compliance with the spirit, is unfair and uncalled for.

> (Personally I don't like *ANY* version of the GPL, because there are
> chunks I have problems with)

What are you doing lurking and spreading confusion in a list about a
project that chose to use it, then?

>> Do you expect Linux would have flourished if computers had locks that
>> stopped people from modifying Linux in them?

> But you aren't talking about a "computer" here. You're talking about
> a mass-market device that must comply with both US and International
> copyright law - and that's just a TiVO.

Oh, sorry.  I missed when the meaning of the word computer was
narrowed from "machine with a general-purpose microprocessor, memory
and other peripherals" to whatever you decide it is.

And then, the GPL doesn't talk about computers at all.  It's not about
the hardware, it's about the software, remember? ;-)

> if you upload a modified linux kernel to your wireless router that
> gives it a 2000 foot range, you've just broken the law

At which point, you get punished by the law system.

> *AND* violated the license on the hardware which states that you
> "won't modify it or the controlling software"

Err..  The hardware licensor who includes software under the GPL be
supposed to be a licensee of the software in order to have legal
permission to distribute it, at which point the following provision
kicks in:

  6. Each time you redistribute the Program (or any work based on the
  Program) [...] You may not impose any further restrictions on the
  recipients' exercise of the rights granted herein. [...]

And here's one of the rights granted herein that would be restricted
by this hardware license:

  2. You may modify your copy or copies of the Program or any portion
  of it, thus forming a work based on the Program,

So such a restriction in the hardware license seems to be failure to
comply with the GPL, which means the violator may lose the license.

> even things like the connectors used to upload the operating
> software at the factory that people now cannot have in a device that
> runs GPL(v3) covered 

Re: [GIT PULL] Blackfin updates for 2.6.22-rc4

[Paul Mundt]

On Thu, Jun 14, 2007 at 10:06:25AM +0800, Bryan Wu wrote:
>  107 files changed, 7034 insertions(+), 3557 deletions(-)

This has new platform support, new drivers, and so on. None of which is
suitable outside of -rc1-2. You are aware of this thing called the merge
window?

Try splitting out the critical bugfixes in to a different tree and have
that pulled for the next -rc, if you expect to get any of the fixes
merged for 2.6.22.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Linus Torvalds]

On Wed, 13 Jun 2007, Alexandre Oliva wrote:
> 
> Let me see if I got this right.  There was a section entitled
> "3. Digital Restrictions Management" in GPLv3dd1.  Are you saying
> that, when people complained about the DRM clause, they actually meant
> the provisions in "1. Source Code"

Yes. I said that multiple times. It was obvious. But people didn't listen.

It's now in Section 7, or whatever.

The section 3 never mattered.

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

[PATCH][BUG] Fix the graphic corruption issue on IA64 machines

[izumi]

Hi,

I encountered the graphic corruption issue on IA64 machines by the
following operations.

 0. enable VGA console(default setting). disable serial console setting.
 1. boot the system at run level 3 and login via text-mode console
(/dev/tty1)
as the root user.
 2. disable console blanking.
# setterm -blank 0
 3. start X.
 4. shutdown X.
 5. start X again.
 6. open the gnome-terminal and write someting to /dev/console.
# ls -l  > /dev/console

The cause of this problem may be VGA console driver's misunderstanding
mode(text/graphic).

I confirmed this problem is fixed by the attached patch, but I don't
know this is the correct fix.



VGA console driver can misunderstand the current mode(Text/Graphic) under
"disable console blanking" setting.

- start X
  -->  vt_ioctl()drivers/char/vt_ioctl.c
do_blank_screen(1) drivers/char/vt.c
   sw->con_blank(vc_cons[currcons].d, 1, 0)  drivers/char/vt.c
   vgacon_blank() drivers/video/console/vgacon.c
　vga_is_gfx = 1 /* enter Graphic mode */

- shutdown X
  -->   vt_ioctl()
  do_unblank_screen(1)drivers/char/vt.c
sw->con_blank(vc_cons[currcons].d, 0, leaving_gfx)
vgacon_blank()
　 vga_is_gfx = 0 /* leave Graphic mode */

When "disable console blank" is set (=> blankinterval=0),
"do_unblank_screen()" function
returns without changing "blank_state", and when "blank_state" is
"blank_off",
"do_blank_screen() function returns without invoking sw->con_blank()
function.
That's why VGA console driver can misunderstand the current mode.

---

Regards,
Taku Izumi

Fix the graphic corruption issue on IA64 machines.
VGA console driver can misunderstand the current mode(Text/Graphic) under 
"disable console blanking" setting. When "disable console blank" is set 
(blankinterval=0), "do_unblank_screen()" function returns without changing 
"blank_state", and when "blank_state" is "blank_off", "do_blank_screen() 
function returns without invoking sw->con_blank() function. That's why VGA 
console driver can misunderstand the current mode.

Signed-off-by: Nobuhiro Tachino <[EMAIL PROTECTED]>
Signed-off-by: Taku Izumi <[EMAIL PROTECTED]>
---
 drivers/char/vt.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)


Index: linux-2.6.21.5/drivers/char/vt.c

--- linux-2.6.21.5.org/drivers/char/vt.c2007-06-13 12:03:11.0 
+0900
+++ linux-2.6.21.5/drivers/char/vt.c2007-06-13 12:07:48.0 +0900
@@ -3419,12 +3419,12 @@ void do_unblank_screen(int leaving_gfx)
return;
}
vc = vc_cons[fg_console].d;
+   blank_state = blank_normal_wait;
if (vc->vc_mode != KD_TEXT)
return; /* but leave console_blanked != 0 */
 
if (blankinterval) {
mod_timer(_timer, jiffies + blankinterval);
-   blank_state = blank_normal_wait;
}
 
console_blanked = 0;

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Adrian Bunk]

On Thu, Jun 14, 2007 at 02:45:40AM +0100, Alan Cox wrote:
>...
> > > AFAIK there haven't been any court rulings on this issue, and it could
> > > even be that courts in different countries will decide differently.
> > 
> > Agreed.
> 
> That in theory shouldn't happen as the conventions on copyright are
> supposed to stop that mess occuring.

Is there any way how this would be resolved?

I can easily imagine that two courts, no matter whether they are in the 
same or different countries, would decide differently in grey areas like 
non-GPL modules or the GPLv2 and private keys.

If the two courts are in the same country there's usually a higher court 
above both that can resolve this. But what if let's say the highest 
court in the USA and the highest court in Germany would disagree on such 
a matter?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Satyam Sharma]

[ Gmail did horrible things to the original post by giving it a base64
content transfer encoding, so [EMAIL PROTECTED] dropped it. It's just
an off-topic digression, but I cared enough to resend anyway, fwiw. ]

On 6/14/07, Jörn Engel <[EMAIL PROTECTED]> wrote:

On Wed, 13 June 2007 14:33:07 -0700, Linus Torvalds wrote:
>
> The beauty of the GPLv2 is exactly that it's a "tit-for-tat" license, and
> you can use it without having to drink the kool-aid.

One could even add that "tit-for-tat" appears to be the best strategy
in game theory for continuous runs of the prisoners dilemma.


Tit-for-tat is the best *deterministic* strategy when playing
iterated prisoner's dilemma. But note that "deterministic" and
"rational" are not adjectives that go well with "humans", and
most real-world (social) situations are noisy environments --
miscommunication and misunderstandings are the usual noise.
A double-D noise perceived by any player would throw a
tit-for-tat-playing couple into a perennial spiral of D's, for example,
which is clearly not a Pareto-efficient solution for either.


At times I
wonder why game theory isn't taught in schools yet - it might shorten
discussions like these.


Yes, and no.

Yes - for teaching game theory (and its social relevance) in schools;
and add behavioral economics to this list :-)

No - it doesn't shorten discussions, however. And it shouldn't either.
Human / social situations are complex, Jörn; tit-for-tat can win
computer contests, for example, but it's not a behaviour one person
would find as entirely agreeable in another.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Adrian Bunk]

On Wed, Jun 13, 2007 at 09:40:13PM -0400, Daniel Hazelton wrote:
> On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote:
> > On Wed, Jun 13, 2007 at 09:01:28PM -0400, Daniel Hazelton wrote:
> > > On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote:
> > > > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote:
> > > > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> > > > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> 
> wrote:
> > > > > > > On Wed, 13 Jun 2007, Alan Cox wrote:
> > > > > > >> > find offensive, so I don't choose to use it. It's offensive
> > > > > > >> > because Tivo never did anything wrong, and the FSF even
> > > > > > >> > acknowledged that. The fact
> > > > > > >>
> > > > > > >> Not all of us agree with this for the benefit of future legal
> > > > > > >> interpretation.
> > > > > > >
> > > > > > > Well, even the FSF lawyers did,
> > > > > >
> > > > > > Or rather they didn't think an attempt to enforce that in the US
> > > > > > would prevail (or so I'm told).  That's not saying what TiVo did
> > > > > > was right, and that's not saying that what TiVo did was permitted
> > > > > > by the license. Only courts of law can do that.
> > > > >
> > > > > Wrong! Anyone with half a brain can make the distinction. What TiVO
> > > > > did is entirely legal - they fully complied with the GPLv2. Note that
> > > > > what they *DON'T* allow people to do is run whatever version of
> > > > > whatever software they want on their hardware. They have that right -
> > > > > its the "Free Software Foundation" and the GPL - regardless of
> > > > > version - is a *SOFTWARE* license. ...
> > > >
> > > > The GPLv2 says:
> > > >
> > > > "For an executable work, complete source code means all the source code
> > > > for all modules it contains, plus any associated interface definition
> > > > files, plus the scripts used to control compilation and installation of
> > > > the executable."
> > > >
> > > > The question is whether this includes private keys.
> > > > Different people have different opinions regarding this issue.
> > > >
> > > > If "the complete source code" includes private keys, the GPLv2 requires
> > > > them to give any costumer the private keys.
> > > >
> > > > Fact is that Harald Welte did in several cases successfully convince
> > > > vendors that private keys are part of the source code if they are
> > > > required for running the compiled binary on some hardware.
> > >
> > > If the hardware was designed for the end-user to change the software
> > > running on it - including running software that it was never meant to run
> > > (ie: a complete webserver on cell phone) - then yes, the signing keys are
> > > a part of the source, as the software running on the device is designed
> > > to be updated by the user using the provided system.
> > >
> > > If, on the other hand, the only "software updates" the user is expected
> > > to perform are the installation of newer versions of the existing code
> > > for "Security" or "Bug Fix" reasons then the signing keys aren't part of
> > > the source.
> >
> > Are you an idiot, or do you just choose to ignore all proof that doesn't
> > fit your preconceived beliefs?
> 
> Nope. Merely stating a distinction. Either a device is distributed, like the 
> common PC, that is designed for the user to change and update the software 
> on, or, like the PS2 it isn't designed for that. If I find a way to update my 
> PS2 to run Linux and find that it doesn't want to start the "Linux Firmware" 
> because I'm lacking a signing key...
> 
> In the case of a device that internally runs Linux (or any other GPL'd 
> software) and wasn't designed for the end-user to change the software running 
> on it then the signing keys aren't part of the source. OTOH, if I sell a PC 
> running Linux that requires the kernel be signed then the signing keys *are* 
> part of the source, since a PC is designed for the end-user to change the 
> software running on it.
> 
> BTW, nice use of irony with that line. Makes me regret letting my fingers get 
> ahead of my brain.
> 
> > The GPL doesn't give someone distributing the software the choice of how
> > much to limit the freedom of the user.
> 
> Never claimed it did. I just wasn't as specific as I should have been when 
> giving my examples.
> 
> > Either private keys required to run the kernel on the hardware are
> > always considered part of "the complete source code" or they are never
> > part of it.
> 
> No. It all depends on the use-case. If the hardware is designed for the user 
> to install their own, custom versions of the code on then the signing keys 
> are part of the source as defined by the GPLv2.
> 
> If, OTOH, the hardware was never meant for the end-user to install custom 
> versions of the software on, then while the signing keys are still 
> *technically* part of the source, in practice they are not. Why? Because in 
> most of those cases the end-user isn't granted the right to install and run 

Re: [PATCH] ia64: Scalability improvement of gettimeofday with jitter compensation

[Hidetoshi Seto]

Bob Picco wrote:

I will be pushing Peter Keilty's clocksource ia64 patches within the next
week or so.  At that time I'll ask for inclusion into -mm. Please see:
http://marc.info/?t=11788158551=1=2
You'll notice that the time interpolator is removed.


I see. Your patch will replace the time interpolator to clocksource.
This is a conversion of structure which contains data related to time.
There will be no drastic change on logic, right?

What I want to do is removing the cmpxchg loop.
Your patch pointed it out that there are 2 loops in fsys.S, outer loop
with lock.seq and inner loop with cmpxchg.

If your patch successfully removes cmpxchg from generic code, then my
patch will be ia64 specific and be compact like following.

Thanks,
H.Seto

---
 arch/ia64/kernel/fsys.S |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

Index: linux-2.6.21/arch/ia64/kernel/fsys.S
===
--- linux-2.6.21.orig/arch/ia64/kernel/fsys.S
+++ linux-2.6.21/arch/ia64/kernel/fsys.S
@@ -224,7 +224,7 @@
add r26 = IA64_CLKSRC_CYCLE_LAST_OFFSET,r20 // clksrc_cycle_last
cmp.ne p6, p0 = 0, r2   // Fallback if work is scheduled
 (p6)br.cond.spnt.many fsys_fallback_syscall
-   ;; // get lock.seq here new code, outer loop2!
+   ;;
 .time_redo:
ld4.acq r28 = [r20] // gtod_lock.sequence, Must be first in struct
ld8 r30 = [r21] // clocksource->mmio_ptr
@@ -242,8 +242,7 @@
ld4 r23 = [r23] // clocksource shift value
ld8 r24 = [r26] // get clksrc_cycle_last value
 (p9)   cmp.eq p13,p0 = 0,r30   // if mmio_ptr, clear p13 jitter control
-   ;; // old position for lock seq, new inner loop1!
-.cmpxchg_redo:
+   ;;
.pred.rel.mutex p8,p9
 (p8)   mov r2 = ar.itc // CPU_TIMER. 36 clocks latency!!!
 (p9)   ld8 r2 = [r30]  // readq(ti->address). Could also have latency 
issues..
@@ -261,20 +260,23 @@
 (p6)   sub r10 = r25,r24   // time we got was less than last_cycle
 (p7)   mov ar.ccv = r25// more than last_cycle. Prep for cmpxchg
;;
+(p7)   cmpxchg8.rel r3 = [r19],r2,ar.ccv
+   ;;
+(p7)   cmp.ne p7,p0 = r25,r3   // if cmpxchg not successful, neighbor updated 
last_cycle
+   ;;
+(p7)   sub r10 = r3,r24// use new last_cycle instead
+   ;;
and r10 = r10,r14   // Apply mask
;;
setf.sig f8 = r10
nop.i 123
;;
-(p7)   cmpxchg8.rel r3 = [r19],r2,ar.ccv
 EX(.fail_efault, probe.w.fault r31, 3) // This takes 5 cycles and we have 
spare time
xmpy.l f8 = f8,f7   // nsec_per_cyc*(counter-last_counter)
 (p15)  add r9 = r9,r17 // Add wall to monotonic.secs to result secs
;;
// End cmpxchg critical section loop1
 (p15)  ld8 r17 = [r22],-IA64_TIMESPEC_TV_NSEC_OFFSET
-(p7)   cmp.ne p7,p0 = r25,r3   // if cmpxchg not successful redo
-(p7)   br.cond.dpnt.few .cmpxchg_redo  // inner loop1
// simulate tbit.nz.or p7,p0 = r28,0
and r28 = ~1,r28// Make sequence even to force retry if odd
getf.sig r2 = f8
@@ -286,8 +288,8 @@
;;  // overloaded 3 bundles!
// End critical section.
add r8 = r8,r2  // Add xtime.nsecs
-   cmp4.ne.or p7,p0 = r28,r10
-(p7)   br.cond.dpnt.few .time_redo // sequence number changed, outer loop2
+   cmp4.ne p7,p0 = r28,r10
+(p7)   br.cond.dpnt.few .time_redo // sequence number changed ?
// Now r8=tv->tv_nsec and r9=tv->tv_sec
mov r10 = r0
movl r2 = 10

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

[GIT PULL] Blackfin updates for 2.6.22-rc4

[Bryan Wu]

Hi Linus:

Sorry for word-wrapping in previous git pull request email.
 
please pull from:

  master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git master

to receive the following updates:

Aubrey Li (2):
  Blackfin arch: DMA code minor naming convention fix
  Blackfin arch: try to split up functions like this into smaller units 
according to LKML review

Bernd Schmidt (1):
  Blackfin arch: defines and provides entry points for certain user space 
functions at fixed addresses

Bryan Wu (2):
  Blackfin arch: fixup Blackfin MAINTIANERS team member list
  Blackfin SPI driver: fix bug SPI DMA incomplete transmission

Jean-Christian de Rivaz (1):
  Blackfin SMC91X ethernet supporting driver: SMC91C111 LEDs are note 
drived in the kernel like in uboot

Michael Hennerich (3):
  Blackfin arch: As Mike pointed out range goes form m..MAX_BLACKFIN_GPIO -1
  Blackfin arch: add missing gpio.h header to fix compiling in some pm 
configurations
  Blackfin arch: fix bug can not wakeup from sleep via push buttons

Mike Frysinger (21):
  Blackfin arch: mark our memory init functions with __init so they get 
freed after init
  Blackfin arch: implement a basic /proc/sram file for L1 allocation 
visibility
  Blackfin arch: scrub old console defines
  Blackfin arch: update defconfigs
  Blackfin arch: unify differences between our diff head.S files -- no 
functional changes
  Blackfin arch: move more of our startup code to .init so it can be freed 
once we are up and running
  Blackfin arch: add proper ENDPROC()
  Blackfin arch: fix spelling typo in output
  Blackfin arch: add support for Alon Bar-Lev's dynamic kernel command-line
  Blackfin arch: need to rename function after moving to match new internal 
dma API
  Blackfin arch: new kernel config for BF548-EZKIT
  Blackfin arch: make sure we initialize our L1 Data B section properly 
based on the linked kernel
  Blackfin arch: redo our linker script a bit
  Blackfin arch: move HI/LO macros into blackfin.h and punt the rest of 
macros.h as it includes VDSP macros we never use
  Blackfin serial driver: hook up our UARTs STP bit with userspaces CMSPAR
  Blackfin serial driver: ignore framing and parity errors
  Blackfin serial driver: actually implement the break_ctl() function
  Blackfin serial driver: decouple PARODD and CMSPAR checking from PARENB
  Blackfin RTC drivers: update MAINTAINERS information
  Blackfin SPI driver: tweak spi cleanup function to match newer kernel 
changes
  Blackfin on-chip watchdog driver

Robin Getz (1):
  Blackfin arch: all symbols were offset by 4k, since we didn't have the 
__text label.

Roy Huang (4):
  Blackfin arch:  fix bug ad1836 fails to build properly for BF533-EZKIT
  Blackfin arch: Add header files for BF548
  Blackfin arch: initial supporting for BF548-EZKIT
  Blackfin serial driver: supporting BF548-EZKIT serial port

Simon Arlott (1):
  Blackfin arch: spelling fixes

 MAINTAINERS   |   86 +-
 arch/blackfin/Kconfig |   82 +-
 arch/blackfin/Makefile|2 +
 arch/blackfin/configs/BF533-EZKIT_defconfig   |  241 +++-
 arch/blackfin/configs/BF533-STAMP_defconfig   |   92 +-
 arch/blackfin/configs/BF537-STAMP_defconfig   |   98 +-
 arch/blackfin/configs/BF548-EZKIT_defconfig   | 1096 ++
 arch/blackfin/configs/BF561-EZKIT_defconfig   |  192 +++-
 arch/blackfin/configs/PNAV-10_defconfig   |  119 ++-
 arch/blackfin/kernel/Makefile |6 +-
 arch/blackfin/kernel/bfin_dma_5xx.c   |  211 +
 arch/blackfin/kernel/bfin_gpio.c  |7 +-
 arch/blackfin/kernel/entry.S  |5 +
 arch/blackfin/kernel/fixed_code.S |  132 +++
 arch/blackfin/kernel/irqchip.c|2 +-
 arch/blackfin/kernel/process.c|   65 ++
 arch/blackfin/kernel/setup.c  |  261 +++--
 arch/blackfin/kernel/traps.c  |2 +-
 arch/blackfin/kernel/vmlinux.lds.S|  166 +--
 arch/blackfin/lib/divsi3.S|3 +
 arch/blackfin/lib/ins.S   |4 +-
 arch/blackfin/lib/memchr.S|2 +-
 arch/blackfin/lib/memcmp.S|2 +-
 arch/blackfin/lib/memcpy.S|2 +
 arch/blackfin/lib/memmove.S   |2 +-
 arch/blackfin/lib/memset.S|2 +-
 arch/blackfin/lib/modsi3.S|2 +
 arch/blackfin/lib/outs.S  |3 +
 arch/blackfin/lib/smulsi3_highpart.S  |2 +
 arch/blackfin/lib/udivsi3.S   |2 +
 arch/blackfin/lib/umodsi3.S   |4 +
 

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> Still doesn't explain why you have argued that the GPLv3 doesn't
> attempt to cover hardware and then provide proof that it does.

It doesn't cover hardware, in the same way that it doesn't cover
patents, and it doesn't cover pro-DRM laws.  It merely arranges, as
best as we've managed a copyright license to do, that they can't be
used as excuses (or tools) to disrespect the freedoms that the GPL
demands all licensees to respect for other users.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: I815 suddenly unkown to agpgart?

[Wang Zhenyu]

On 2007.06.14 09:34:12 +, Wang Zhenyu wrote:
> 
> Dave, after rethinking about this, I think we mixed two cases 
> need to be fixed here. This is the patch for this, sorry for mess
> it up. Meelis, could you help to test by replace my last patch with this? 
> 

oop, for 945GME like case, we should stop scan if still no detection. 
Updated patch here. 

[AGPGART] intel_agp: fix device probe

This patch trys to fix device probe in two cases. First we should
correctly detect device if integrated graphics device is not enabled
or exists, like an add-in card is plugged. Second on some type of intel
GMCH, it might have multiple graphic chip models, like 945GME case, so
we should be sure the detect works through the whole table.

Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]>
---
 drivers/char/agp/intel-agp.c |   97 ++
 1 files changed, 51 insertions(+), 46 deletions(-)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index d383168..1a83b02 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -1810,68 +1810,69 @@ static int find_gmch(u16 device)
 static const struct intel_driver_description {
unsigned int chip_id;
unsigned int gmch_chip_id;
+   unsigned int multi_gmch_chip; /* if we have more gfx chip type on this 
HB. */
char *name;
const struct agp_bridge_driver *driver;
const struct agp_bridge_driver *gmch_driver;
 } intel_agp_chipsets[] = {
-   { PCI_DEVICE_ID_INTEL_82443LX_0, 0, "440LX", _generic_driver, 
NULL },
-   { PCI_DEVICE_ID_INTEL_82443BX_0, 0, "440BX", _generic_driver, 
NULL },
-   { PCI_DEVICE_ID_INTEL_82443GX_0, 0, "440GX", _generic_driver, 
NULL },
-   { PCI_DEVICE_ID_INTEL_82810_MC1, PCI_DEVICE_ID_INTEL_82810_IG1, "i810",
+   { PCI_DEVICE_ID_INTEL_82443LX_0, 0, 0, "440LX", _generic_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82443BX_0, 0, 0, "440BX", _generic_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82443GX_0, 0, 0, "440GX", _generic_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82810_MC1, PCI_DEVICE_ID_INTEL_82810_IG1, 0, 
"i810",
NULL, _810_driver },
-   { PCI_DEVICE_ID_INTEL_82810_MC3, PCI_DEVICE_ID_INTEL_82810_IG3, "i810",
+   { PCI_DEVICE_ID_INTEL_82810_MC3, PCI_DEVICE_ID_INTEL_82810_IG3, 0, 
"i810",
NULL, _810_driver },
-   { PCI_DEVICE_ID_INTEL_82810E_MC, PCI_DEVICE_ID_INTEL_82810E_IG, "i810",
+   { PCI_DEVICE_ID_INTEL_82810E_MC, PCI_DEVICE_ID_INTEL_82810E_IG, 0, 
"i810",
NULL, _810_driver },
-   { PCI_DEVICE_ID_INTEL_82815_MC, PCI_DEVICE_ID_INTEL_82815_CGC, "i815",
-   _810_driver, _815_driver },
-   { PCI_DEVICE_ID_INTEL_82820_HB, 0, "i820", _820_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82820_UP_HB, 0, "i820", _820_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82830_HB, PCI_DEVICE_ID_INTEL_82830_CGC, "830M",
+   { PCI_DEVICE_ID_INTEL_82815_MC, PCI_DEVICE_ID_INTEL_82815_CGC, 0, 
"i815",
+   _815_driver, _810_driver },
+   { PCI_DEVICE_ID_INTEL_82820_HB, 0, 0, "i820", _820_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82820_UP_HB, 0, 0, "i820", _820_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82830_HB, PCI_DEVICE_ID_INTEL_82830_CGC, 0, 
"830M",
_830mp_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82840_HB, 0, "i840", _840_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82845_HB, 0, "845G", _845_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82845G_HB, PCI_DEVICE_ID_INTEL_82845G_IG, "830M",
+   { PCI_DEVICE_ID_INTEL_82840_HB, 0, 0, "i840", _840_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82845_HB, 0, 0, "845G", _845_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82845G_HB, PCI_DEVICE_ID_INTEL_82845G_IG, 0, 
"830M",
_845_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82850_HB, 0, "i850", _850_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82855PM_HB, 0, "855PM", _845_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82855GM_HB, PCI_DEVICE_ID_INTEL_82855GM_IG, 
"855GM",
+   { PCI_DEVICE_ID_INTEL_82850_HB, 0, 0, "i850", _850_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82855PM_HB, 0, 0, "855PM", _845_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82855GM_HB, PCI_DEVICE_ID_INTEL_82855GM_IG, 0, 
"855GM",
_845_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82860_HB, 0, "i860", _860_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82865_HB, PCI_DEVICE_ID_INTEL_82865_IG, "865",
+   { PCI_DEVICE_ID_INTEL_82860_HB, 0, 0, "i860", _860_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82865_HB, PCI_DEVICE_ID_INTEL_82865_IG, 0, "865",
_845_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82875_HB, 0, "i875", _845_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82915G_HB, PCI_DEVICE_ID_INTEL_82915G_IG, "915G",
+   { PCI_DEVICE_ID_INTEL_82875_HB, 0, 0, "i875", _845_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82915G_HB, 

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> On Wednesday 13 June 2007 20:55:52 Alexandre Oliva wrote:
>> On Jun 13, 2007, Bongani Hlope <[EMAIL PROTECTED]> wrote:
>> > On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote:
>> >> if you distribute copies of such a program, [...]
>> >> you must give the recipients all the rights that you have

>> >> So, TiVo includes a copy of Linux in its DVR.

>> Can they modify the software in their device?

>> Do they pass this right on?

> But this *ISN'T* a right that the GPLv2 *REQUIRES* be passed on. 

You may be right.  The spirit says it should, but the legalese may
have missed the mark.  So GPLv3 makes it clear that it is.

>> It's about that copy of the kernel that ships in the device in object
>> code.  That's the one that TiVo customers ought to be entitled to
>> modify, if TiVo can modify it itself.

> The GPLv2 makes no real provision for *DIRECTLY* modifying object
> code.

Sure.  And that's not what I'm talking about.

What I'm talking about is being able to replace, upgrade, fix, tweak,
hack, and otherwise modify the program on the machine in the same way
that the vendor still can.

> What provisions the GPLv2 has apply to the source code.

This is too narrow a view of the GPLv2 provisions.

> And no, the end user *SHOULD* *NOT* be entitled to run whatever kernel they 
> like on a TiVO. It was designed with the "install new kernel" functionality 
> so that the TiVO corporation could update the kernel running on the hardware 
> when security problems came up, when bugs were fixed or even when the new 
> version gives better performance.

I.e., it was designed such that TiVo could modify the installed
kernel, but the user couldn't.  That's an outright violation of the
spirit of the GPL.

>> > Where does it say you should be able to run you modifications on the
>> > same hardware?

>> Where it says that you should pass on all the rights that you have.

>> While TiVo retains the ability to replace, upgrade, fix, break or make
>> any other change in the GPLed software in the device, it ought to pass
>> it on to its customers.

> It *DOES* *NOT* say "All rights that you have". It says "All rights
> that are granted you by this license".

I suggest you to reboot into memtest ;-)  The preamble of GPLv2 says:

  For example, if you distribute copies of such a program, whether
  gratis or for a fee, you must give the recipients
  all the rights that you have.
  
 
> If every piece of software released under the GPL had *ALL* rights
> passed on, then *ANYONE* could do the "I'm granting company X the
> right to use this software outside the GPL for $50,000USD."

The requirement above applies to licensees, not to the licensor.  The
licensor doesn't have to pass on all the rights s/he has, s/he only
decides to respect the licensee's freedoms, conditioned to the respect
of others' freedoms by means of passing on all rights the licensee has
over the software.

Arguably, one could use this argument to state that any authors of
derived works ought to pass on the right to choose the license for the
derived work under the GPL, but since (a) the above is not in the
legal terms, and (b) the downstream recipients would be bound by the
terms of the GPL anyway, and that requires the use of the GPL itself,
this would make no difference whatsoever.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2/2] 2.6.22-rc4: known regressions v3

[William Lee Irwin III]

On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote:
> The random seg faults on x86_64 is interesting as I have been getting 
> random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have 
> not yet tried to track it down. All I know at present is that it is not a 
> problem on 2.6.20.9.

Very interesting. Any hints as to how to test or how long to wait
before the illegal instructions happen?


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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alan Cox]

> What if TiVo had put the kernel in a burned-in ROM (not flash, or on a
> flash ROM with no provision for reprogramming it)?  Would that also
> violate the "spirit" of the GPL?  Must any device that wishes to include
> GPL code include additional hardware to support replacing that code
> (even if that hardware is otherwise superfluous)?

As a PS to the GPL3 comment here is the basic difference

ROM -   I can't modify the code on the device
The creator can't modify the code further on the device

Tivo-   I can't modify the code on the device
The owner can modify the code 

One is an implicit limitation of the hardware (just like I can't run
openoffice on a 4MB PC even though the license gives me the right to
try), the other is an artificial restriction.

One case is witholding freedom in the GPL sense by one party while
keeping it themselves, the other is a limitation of the system
inevitably imposed on everyone.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alan Cox]

> What if TiVo had put the kernel in a burned-in ROM (not flash, or on a
> flash ROM with no provision for reprogramming it)?  Would that also
> violate the "spirit" of the GPL?  Must any device that wishes to include
> GPL code include additional hardware to support replacing that code
> (even if that hardware is otherwise superfluous)?

This is an area the GPLv3 tries to clarify and for good reason. 

Of course these days in the US someone would probably sue arguing that a
ROM is protection scheme ;)

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alan Cox]

> I haven't looked into what Harald Welte did, but I'd be surprised if someone 
> tried following suit in America and had as much success.

One of the distinct advantages of German law over the US system (and to a
large extent the UK system its based upon) is that German law favours
justice over money.

> > AFAIK there haven't been any court rulings on this issue, and it could
> > even be that courts in different countries will decide differently.
> 
> Agreed.

That in theory shouldn't happen as the conventions on copyright are
supposed to stop that mess occuring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Chris Adams]

Once upon a time, Alexandre Oliva  <[EMAIL PROTECTED]> said:
>  if you distribute copies of such a program, [...]
>  you must give the recipients all the rights that you have
>
>So, TiVo includes a copy of Linux in its DVR.  
>
>TiVo retains the right to modify that copy of Linux as it sees fit.
>
>It doesn't give the recipients the same right.

Sure it does; you received a program (the kernel) and you can modify it.
You also received hardware; they don't support modification of that.
Nowhere in the license does it say they have to, because the license
only covers the program.

Or are you claiming that putting software on hardware makes the result a
derivative work?  I think it falls under the "mere aggregation" clause.

What if TiVo had put the kernel in a burned-in ROM (not flash, or on a
flash ROM with no provision for reprogramming it)?  Would that also
violate the "spirit" of the GPL?  Must any device that wishes to include
GPL code include additional hardware to support replacing that code
(even if that hardware is otherwise superfluous)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 21:24:01 Adrian Bunk wrote:
> On Wed, Jun 13, 2007 at 09:01:28PM -0400, Daniel Hazelton wrote:
> > On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote:
> > > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote:
> > > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> > > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> 
wrote:
> > > > > > On Wed, 13 Jun 2007, Alan Cox wrote:
> > > > > >> > find offensive, so I don't choose to use it. It's offensive
> > > > > >> > because Tivo never did anything wrong, and the FSF even
> > > > > >> > acknowledged that. The fact
> > > > > >>
> > > > > >> Not all of us agree with this for the benefit of future legal
> > > > > >> interpretation.
> > > > > >
> > > > > > Well, even the FSF lawyers did,
> > > > >
> > > > > Or rather they didn't think an attempt to enforce that in the US
> > > > > would prevail (or so I'm told).  That's not saying what TiVo did
> > > > > was right, and that's not saying that what TiVo did was permitted
> > > > > by the license. Only courts of law can do that.
> > > >
> > > > Wrong! Anyone with half a brain can make the distinction. What TiVO
> > > > did is entirely legal - they fully complied with the GPLv2. Note that
> > > > what they *DON'T* allow people to do is run whatever version of
> > > > whatever software they want on their hardware. They have that right -
> > > > its the "Free Software Foundation" and the GPL - regardless of
> > > > version - is a *SOFTWARE* license. ...
> > >
> > > The GPLv2 says:
> > >
> > > "For an executable work, complete source code means all the source code
> > > for all modules it contains, plus any associated interface definition
> > > files, plus the scripts used to control compilation and installation of
> > > the executable."
> > >
> > > The question is whether this includes private keys.
> > > Different people have different opinions regarding this issue.
> > >
> > > If "the complete source code" includes private keys, the GPLv2 requires
> > > them to give any costumer the private keys.
> > >
> > > Fact is that Harald Welte did in several cases successfully convince
> > > vendors that private keys are part of the source code if they are
> > > required for running the compiled binary on some hardware.
> >
> > If the hardware was designed for the end-user to change the software
> > running on it - including running software that it was never meant to run
> > (ie: a complete webserver on cell phone) - then yes, the signing keys are
> > a part of the source, as the software running on the device is designed
> > to be updated by the user using the provided system.
> >
> > If, on the other hand, the only "software updates" the user is expected
> > to perform are the installation of newer versions of the existing code
> > for "Security" or "Bug Fix" reasons then the signing keys aren't part of
> > the source.
>
> Are you an idiot, or do you just choose to ignore all proof that doesn't
> fit your preconceived beliefs?

Nope. Merely stating a distinction. Either a device is distributed, like the 
common PC, that is designed for the user to change and update the software 
on, or, like the PS2 it isn't designed for that. If I find a way to update my 
PS2 to run Linux and find that it doesn't want to start the "Linux Firmware" 
because I'm lacking a signing key...

In the case of a device that internally runs Linux (or any other GPL'd 
software) and wasn't designed for the end-user to change the software running 
on it then the signing keys aren't part of the source. OTOH, if I sell a PC 
running Linux that requires the kernel be signed then the signing keys *are* 
part of the source, since a PC is designed for the end-user to change the 
software running on it.

BTW, nice use of irony with that line. Makes me regret letting my fingers get 
ahead of my brain.

> The GPL doesn't give someone distributing the software the choice of how
> much to limit the freedom of the user.

Never claimed it did. I just wasn't as specific as I should have been when 
giving my examples.

> Either private keys required to run the kernel on the hardware are
> always considered part of "the complete source code" or they are never
> part of it.

No. It all depends on the use-case. If the hardware is designed for the user 
to install their own, custom versions of the code on then the signing keys 
are part of the source as defined by the GPLv2.

If, OTOH, the hardware was never meant for the end-user to install custom 
versions of the software on, then while the signing keys are still 
*technically* part of the source, in practice they are not. Why? Because in 
most of those cases the end-user isn't granted the right to install and run 
custom binaries on the hardware. If the manufacturer provided the signing 
keys they'd be facilitating the commission of a crime. (call it "Breach of 
Contract")

> > I haven't looked into what Harald Welte did, but I'd be surprised if
> > someone tried 

Re: [PATCH]: add parameter "struct bin_attribute *" in .read/.write methods for sysfs binary attributes

[Len Brown]

I've applied this to acpi-test with an Acked-by: gregkh -- as we need it
for the acpi table patch.

Greg, unless I hear from you, I'll assume that this is okay for 2.6.23.

thanks,
-Len
 
On Saturday 09 June 2007 01:57, Zhang Rui wrote:
> From: Zhang Rui <[EMAIL PROTECTED]>
> 
> Well, first of all, I don't want to change so many files either.
> 
> What I do:
> Adding a new parameter "struct bin_attribute *" in the
> .read/.write methods for the sysfs binary attributes.
> 
> In fact, only the four lines change in fs/sysfs/bin.c and
> include/linux/sysfs.h do the real work.
> But I have to update all the files that use binary attributes
> to make them compatible with the new .read and .write methods.
> I'm not sure if I missed any. :(
> 
> Why I do this:
> For a sysfs attribute, we can get a pointer pointing to the
> struct attribute in the .show/.store method,
> while we can't do this for the binary attributes.
> I don't know why this is different, but this does make it not
> so handy to use the binary attributes as the regular ones.
> So I think this patch is reasonable. :)
> 
> Who benefits from it:
> The patch that exposes ACPI tables in sysfs
> requires such an improvement.
> All the table binary attributes share the same .read method.
> Parameter "struct bin_attribute *" is used to get
> the table signature and instance number which are used to
> distinguish different ACPI table binary attributes.
> 
> Without this parameter, we need to offer different .read methods
> for different ACPI table binary attributes.
> This is impossible as there are various ACPI tables on different
> platforms, and we don't know what they are until they are loaded.
> 
> Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
> ---
>  Documentation/firmware_class/firmware_sample_firmware_class.c |2 
>  drivers/base/firmware_class.c |4 
>  drivers/firmware/dcdbas.c |   10 +-
>  drivers/firmware/dell_rbu.c   |   25 +++--
>  drivers/i2c/chips/eeprom.c|3 
>  drivers/i2c/chips/max6875.c   |5 -
>  drivers/pci/hotplug/acpiphp_ibm.c |6 -
>  drivers/pci/pci-sysfs.c   |   18 ++-
>  drivers/pcmcia/socket_sysfs.c |8 +
>  drivers/rapidio/rio-sysfs.c   |6 -
>  drivers/rtc/rtc-ds1553.c  |   10 +-
>  drivers/rtc/rtc-ds1742.c  |   10 +-
>  drivers/s390/cio/chp.c|   10 +-
>  drivers/scsi/arcmsr/arcmsr_attr.c |   15 +--
>  drivers/scsi/ipr.c|   18 ++-
>  drivers/scsi/libsas/sas_expander.c|   16 ++-
>  drivers/scsi/lpfc/lpfc_attr.c |   12 +-
>  drivers/scsi/qla2xxx/qla_attr.c   |   50 
> ++
>  drivers/spi/at25.c|6 -
>  drivers/video/aty/radeon_base.c   |8 +
>  drivers/w1/slaves/w1_ds2433.c |   10 +-
>  drivers/w1/slaves/w1_therm.c  |7 +
>  drivers/w1/w1.c   |   12 +-
>  drivers/zorro/zorro-sysfs.c   |5 -
>  fs/sysfs/bin.c|4 
>  include/linux/sysfs.h |6 -
>  net/bridge/br_sysfs_br.c  |5 -
>  27 files changed, 185 insertions(+), 106 deletions(-)
> 
> Index: 
> linux-2.6.22-rc4/Documentation/firmware_class/firmware_sample_firmware_class.c
> ===
> --- 
> linux-2.6.22-rc4.orig/Documentation/firmware_class/firmware_sample_firmware_class.c
>2004-01-03 06:33:28.0 +0800
> +++ 
> linux-2.6.22-rc4/Documentation/firmware_class/firmware_sample_firmware_class.c
> 2007-06-08 13:25:33.0 +0800
> @@ -78,6 +78,7 @@ static CLASS_DEVICE_ATTR(loading, 0644,
>firmware_loading_show, firmware_loading_store);
>  
>  static ssize_t firmware_data_read(struct kobject *kobj,
> +   struct bin_attribute *bin_attr,
> char *buffer, loff_t offset, size_t count)
>  {
>   struct class_device *class_dev = to_class_dev(kobj);
> @@ -88,6 +89,7 @@ static ssize_t firmware_data_read(struct
>   return count;
>  }
>  static ssize_t firmware_data_write(struct kobject *kobj,
> +struct bin_attribute *bin_attr,
>  char *buffer, loff_t offset, size_t count)
>  {
>   struct class_device *class_dev = 

Re: I815 suddenly unkown to agpgart?

[Wang Zhenyu]

On 2007.06.13 14:22:40 +, Dave Jones wrote:
> 
> Oops :)
> I'll merge this, and get it to Linus today.
> Don't forget to add a Signed-off-by: for future patches.
> 

Dave, after rethinking about this, I think we mixed two cases 
need to be fixed here. This is the patch for this, sorry for mess
it up. Meelis, could you help to test by replace my last patch with this? 

Thanks

---
[PATCH] [AGPGART] intel_agp: fix device probe

This patch trys to fix device probe in two cases. First we should
correctly detect device if integrated graphics device is not enabled
or exists, like an add-in card is plugged. Second on some type of intel
GMCH, it might have multiple graphic chip models, like 945GME case, so
we should be sure the detect works through the whole table.

Signed-off-by: Wang Zhenyu <[EMAIL PROTECTED]>
---
 drivers/char/agp/intel-agp.c |   97 ++
 1 files changed, 51 insertions(+), 46 deletions(-)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index d383168..bf5a602 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -1810,68 +1810,69 @@ static int find_gmch(u16 device)
 static const struct intel_driver_description {
unsigned int chip_id;
unsigned int gmch_chip_id;
+   unsigned int multi_gmch_chip;
char *name;
const struct agp_bridge_driver *driver;
const struct agp_bridge_driver *gmch_driver;
 } intel_agp_chipsets[] = {
-   { PCI_DEVICE_ID_INTEL_82443LX_0, 0, "440LX", _generic_driver, 
NULL },
-   { PCI_DEVICE_ID_INTEL_82443BX_0, 0, "440BX", _generic_driver, 
NULL },
-   { PCI_DEVICE_ID_INTEL_82443GX_0, 0, "440GX", _generic_driver, 
NULL },
-   { PCI_DEVICE_ID_INTEL_82810_MC1, PCI_DEVICE_ID_INTEL_82810_IG1, "i810",
+   { PCI_DEVICE_ID_INTEL_82443LX_0, 0, 0, "440LX", _generic_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82443BX_0, 0, 0, "440BX", _generic_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82443GX_0, 0, 0, "440GX", _generic_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82810_MC1, PCI_DEVICE_ID_INTEL_82810_IG1, 0, 
"i810",
NULL, _810_driver },
-   { PCI_DEVICE_ID_INTEL_82810_MC3, PCI_DEVICE_ID_INTEL_82810_IG3, "i810",
+   { PCI_DEVICE_ID_INTEL_82810_MC3, PCI_DEVICE_ID_INTEL_82810_IG3, 0, 
"i810",
NULL, _810_driver },
-   { PCI_DEVICE_ID_INTEL_82810E_MC, PCI_DEVICE_ID_INTEL_82810E_IG, "i810",
+   { PCI_DEVICE_ID_INTEL_82810E_MC, PCI_DEVICE_ID_INTEL_82810E_IG, 0, 
"i810",
NULL, _810_driver },
-   { PCI_DEVICE_ID_INTEL_82815_MC, PCI_DEVICE_ID_INTEL_82815_CGC, "i815",
-   _810_driver, _815_driver },
-   { PCI_DEVICE_ID_INTEL_82820_HB, 0, "i820", _820_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82820_UP_HB, 0, "i820", _820_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82830_HB, PCI_DEVICE_ID_INTEL_82830_CGC, "830M",
+   { PCI_DEVICE_ID_INTEL_82815_MC, PCI_DEVICE_ID_INTEL_82815_CGC, 0, 
"i815",
+   _815_driver, _810_driver },
+   { PCI_DEVICE_ID_INTEL_82820_HB, 0, 0, "i820", _820_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82820_UP_HB, 0, 0, "i820", _820_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82830_HB, PCI_DEVICE_ID_INTEL_82830_CGC, 0, 
"830M",
_830mp_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82840_HB, 0, "i840", _840_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82845_HB, 0, "845G", _845_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82845G_HB, PCI_DEVICE_ID_INTEL_82845G_IG, "830M",
+   { PCI_DEVICE_ID_INTEL_82840_HB, 0, 0, "i840", _840_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82845_HB, 0, 0, "845G", _845_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82845G_HB, PCI_DEVICE_ID_INTEL_82845G_IG, 0, 
"830M",
_845_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82850_HB, 0, "i850", _850_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82855PM_HB, 0, "855PM", _845_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82855GM_HB, PCI_DEVICE_ID_INTEL_82855GM_IG, 
"855GM",
+   { PCI_DEVICE_ID_INTEL_82850_HB, 0, 0, "i850", _850_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82855PM_HB, 0, 0, "855PM", _845_driver, 
NULL },
+   { PCI_DEVICE_ID_INTEL_82855GM_HB, PCI_DEVICE_ID_INTEL_82855GM_IG, 0, 
"855GM",
_845_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82860_HB, 0, "i860", _860_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82865_HB, PCI_DEVICE_ID_INTEL_82865_IG, "865",
+   { PCI_DEVICE_ID_INTEL_82860_HB, 0, 0, "i860", _860_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82865_HB, PCI_DEVICE_ID_INTEL_82865_IG, 0, "865",
_845_driver, _830_driver },
-   { PCI_DEVICE_ID_INTEL_82875_HB, 0, "i875", _845_driver, NULL },
-   { PCI_DEVICE_ID_INTEL_82915G_HB, PCI_DEVICE_ID_INTEL_82915G_IG, "915G",
+   { PCI_DEVICE_ID_INTEL_82875_HB, 0, 0, "i875", _845_driver, NULL },
+   { PCI_DEVICE_ID_INTEL_82915G_HB, PCI_DEVICE_ID_INTEL_82915G_IG, 

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 21:16:19 Alan Cox wrote:
> > > Only courts of law can do that.
> >
> > Wrong! Anyone with half a brain can make the distinction. What TiVO did
> > is
>
> Maybe half a brain can, but anyone with a whole brain can assure you its
> a bit more complex and you are wrong..
>
> > version of it that we provide on our hardware". Why is that legal?
> > Because TiVO produces the hardware and sells it to you with a certain
> > *LICENSE* -
>
> The keys required to make the code run with the hardware are part of the
> software. The license requires the software and relevant scripts etc are
> included. Thus there is a very good argument that the keys are part of
> the software.

Good argument, but I'll stand by my interpretation of the law, the GPL and the 
situation until there is solid proof that a signing-key is part of the source 
code. Doubly so because the language of the GPLv2 makes it clear that "all 
relevant scripts, etc" are only needed to build and run the "covered work" - 
not for proper installation of it. (and, in the case of a TiVO, the signing 
keys are part of the installation, not the running or building. Besides 
needing the proper signing key, the kernel in a TiVO is run the same as any 
other Linux kernel) 

> And since there is no court ruling to high enough level in the USA, UK or
> any other jurisdiction on that it remains a matter of opinion.
>
> Tivo may control the hardware but the authors control the software (via
> the GPL), and subject to the limits of what may be specified by a
> copyright license (as opposed to contract) can make such demands as they
> see fit about their software and anything derivative of it.

Agreed. However, AFAICT, TiVO meets the provisions of the GPLv2 - they make 
the source of the GPL'd part of their system available. (And I'm not going to 
get into arguments over whether kernel modules are "derivative works" or not, 
since those invariably end up with "They aren't, even though we think they 
should be")

> > because it does contain hardware covered under any number of patents.
> > That license grants you the right to use the patents - in this case
> > algorithms -
>
> You can't patent algorithms either

Then explain the patents on the MP3 algorithm, the LZW algorithm, etc... Those 
patents are real and while the LZW one may have lapsed, still relevant.

DRH 

> Alan



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Adrian Bunk]

On Wed, Jun 13, 2007 at 09:01:28PM -0400, Daniel Hazelton wrote:
> On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote:
> > On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote:
> > > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> > > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > > > On Wed, 13 Jun 2007, Alan Cox wrote:
> > > > >> > find offensive, so I don't choose to use it. It's offensive
> > > > >> > because Tivo never did anything wrong, and the FSF even
> > > > >> > acknowledged that. The fact
> > > > >>
> > > > >> Not all of us agree with this for the benefit of future legal
> > > > >> interpretation.
> > > > >
> > > > > Well, even the FSF lawyers did,
> > > >
> > > > Or rather they didn't think an attempt to enforce that in the US would
> > > > prevail (or so I'm told).  That's not saying what TiVo did was right,
> > > > and that's not saying that what TiVo did was permitted by the license.
> > > > Only courts of law can do that.
> > >
> > > Wrong! Anyone with half a brain can make the distinction. What TiVO did
> > > is entirely legal - they fully complied with the GPLv2. Note that what
> > > they *DON'T* allow people to do is run whatever version of whatever
> > > software they want on their hardware. They have that right - its the
> > > "Free Software Foundation" and the GPL - regardless of version - is a
> > > *SOFTWARE* license. ...
> >
> > The GPLv2 says:
> >
> > "For an executable work, complete source code means all the source code
> > for all modules it contains, plus any associated interface definition
> > files, plus the scripts used to control compilation and installation of
> > the executable."
> >
> > The question is whether this includes private keys.
> > Different people have different opinions regarding this issue.
> >
> > If "the complete source code" includes private keys, the GPLv2 requires
> > them to give any costumer the private keys.
> >
> > Fact is that Harald Welte did in several cases successfully convince
> > vendors that private keys are part of the source code if they are
> > required for running the compiled binary on some hardware.
> 
> If the hardware was designed for the end-user to change the software running 
> on it - including running software that it was never meant to run (ie: a 
> complete webserver on cell phone) - then yes, the signing keys are a part of 
> the source, as the software running on the device is designed to be updated 
> by the user using the provided system.
> 
> If, on the other hand, the only "software updates" the user is expected to 
> perform are the installation of newer versions of the existing code 
> for "Security" or "Bug Fix" reasons then the signing keys aren't part of the 
> source.

Are you an idiot, or do you just choose to ignore all proof that doesn't 
fit your preconceived beliefs?

The GPL doesn't give someone distributing the software the choice of how
much to limit the freedom of the user.

Either private keys required to run the kernel on the hardware are 
always considered part of "the complete source code" or they are never 
part of it.

> I haven't looked into what Harald Welte did, but I'd be surprised if someone 
> tried following suit in America and had as much success.
>...

Harald is in Germany, and he therefore takes legal action against people 
distributing products violating his copyright on the Linux kernel
in Germany at German courts based on German laws.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 21:04:42 Alexandre Oliva wrote:
> On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > Now stop parroting the FSF's worn and tired tripe.
>
> Are you playing Linus' sheeple and parroting his lines just to make a
> point, or are you like that all the time? ;-)

Nope. I'm just tired of giving proof after proof that you're wrong and having 
you restate the same tripe.

> > PS: Looking at your .sig I guess maybe you can't do that without getting
> > kicked out of the FSF-LA
>
> Don't worry, I'm not speaking even for FSFLA, and I'm entitled to my
> own opinion.

Certainly. I never said otherwise. What I stated and then *implied* was that 
you are repeating the same false logic over and over again trying to make 
people believe that it isn't borked and that that false logic is exactly the 
same crap I've seen from the FSF numerous times.

> I haven't consulted other FSFLA members about this.  This is all my
> own personal opinion.

Where I am examining the facts and drawing a logical conclusion. That it 
happens to form an opinion is secondary to the truth.

> It just so happens that I'm very closely involved in the process, I've
> spent a lot of time thinking about it, and I happen to share a similar
> moral and ethical background with others involved in the process, so I
> arrive at similar conclusions.

Okay. Still doesn't explain why you have argued that the GPLv3 doesn't attempt 
to cover hardware and then provide proof that it does. 

> And then, I influence the process myself, so it's not like some of the
> arguments I brought up here weren't taken into account while creating
> the GPLv3, and adopted by its other proponents.

This is no surprise - I had a feeling this was the truth. Not that it changes 
my opinion at all. As I've said, I have never liked the GPL at all, but v2 is 
the best that exists - even though I've put together custom licenses myself, 
none of them have had the number of lawyers look at them that the GPLv2 has 
had.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DRI/AGP on AMD64 based machine

[Dave Airlie]

On 6/14/07, Carlo Wood <[EMAIL PROTECTED]> wrote:

On Wed, Jun 13, 2007 at 12:29:25PM -0400, Dave Jones wrote:
> For the sake of AGP, we only use the on-CPU GART.
> The (nvidia) chipset one is ignored.
>
> If amd64-agp isn't working for you, attach your dmesg.
> (You can also confirm its working by running testgart[1])

Hi Dave, I have an amd64 box for which every kernel
after 2.6.18 hangs during boot, so I have no dmesg :(

I used git bisect to find out where the problem patch is,
and assuming bisect works (imho it jumped between versions
very weirdly: closing in on the last 6 revisions, it
jumped from 2.6.18 to 2.6.18-rc2 to 2.6.18-rc6), the problem
is a patch in intel-agp.c, where support for the intel 965G
is added (which I have).


How do you have a 965G in an amd64 box? does not compute.

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

Re: DRI/AGP on AMD64 based machine

[Carlo Wood]

On Wed, Jun 13, 2007 at 12:29:25PM -0400, Dave Jones wrote:
> For the sake of AGP, we only use the on-CPU GART.
> The (nvidia) chipset one is ignored.
> 
> If amd64-agp isn't working for you, attach your dmesg.
> (You can also confirm its working by running testgart[1])

Hi Dave, I have an amd64 box for which every kernel
after 2.6.18 hangs during boot, so I have no dmesg :(

I used git bisect to find out where the problem patch is,
and assuming bisect works (imho it jumped between versions
very weirdly: closing in on the last 6 revisions, it
jumped from 2.6.18 to 2.6.18-rc2 to 2.6.18-rc6), the problem
is a patch in intel-agp.c, where support for the intel 965G
is added (which I have).

I mailed the author of the patch, including the git Id
of that patch... but he didn't reply... and I didn't keep the
mail :/ So, I am afraid I can't give much details.

I'd still like to have it sorted out. If you give me the
green light (in the sense that you are willing to help
a kernel-newbie when needed) then I'll have another
attempt at getting more information.

-- 
Carlo Wood <[EMAIL PROTECTED]>

PS I believe it was you who committed the patch.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alan Cox]

> > Only courts of law can do that.
> 
> Wrong! Anyone with half a brain can make the distinction. What TiVO did is 

Maybe half a brain can, but anyone with a whole brain can assure you its
a bit more complex and you are wrong..

> version of it that we provide on our hardware". Why is that legal? Because 
> TiVO produces the hardware and sells it to you with a certain *LICENSE* - 

The keys required to make the code run with the hardware are part of the
software. The license requires the software and relevant scripts etc are
included. Thus there is a very good argument that the keys are part of
the software.

And since there is no court ruling to high enough level in the USA, UK or
any other jurisdiction on that it remains a matter of opinion.

Tivo may control the hardware but the authors control the software (via
the GPL), and subject to the limits of what may be specified by a
copyright license (as opposed to contract) can make such demands as they
see fit about their software and anything derivative of it.

> because it does contain hardware covered under any number of patents. That 
> license grants you the right to use the patents - in this case algorithms - 

You can't patent algorithms either

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 20:55:52 Alexandre Oliva wrote:
> On Jun 13, 2007, Bongani Hlope <[EMAIL PROTECTED]> wrote:
> > On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote:
> >> if you distribute copies of such a program, [...]
> >> you must give the recipients all the rights that you have
> >>
> >> So, TiVo includes a copy of Linux in its DVR.
> >
> > And they give you the same right that they had, which is obtain free
> > software that you can modify and redistribute. There's nothing in there
> > that says they should give you the tools they used after they received
> > the software, which is what you seem to be looking for.
>
> Can they modify the software in their device?
>
> Do they pass this right on?

But this *ISN'T* a right that the GPLv2 *REQUIRES* be passed on. 

> >> TiVo retains the right to modify that copy of Linux as it sees fit.
> >>
> >> It doesn't give the recipients the same right.
> >
> > It does, can't you modify their kernel source?
>
> It's not the kernel source.  That's not where the TiVo anti-tampering
> machinery blocks modifications.
>
> It's about that copy of the kernel that ships in the device in object
> code.  That's the one that TiVo customers ought to be entitled to
> modify, if TiVo can modify it itself.

The GPLv2 makes no real provision for *DIRECTLY* modifying object code. What 
provisions the GPLv2 has apply to the source code.

And no, the end user *SHOULD* *NOT* be entitled to run whatever kernel they 
like on a TiVO. It was designed with the "install new kernel" functionality 
so that the TiVO corporation could update the kernel running on the hardware 
when security problems came up, when bugs were fixed or even when the new 
version gives better performance.

> > Where does it say you should be able to run you modifications on the
> > same hardware?
>
> Where it says that you should pass on all the rights that you have.
>
> While TiVo retains the ability to replace, upgrade, fix, break or make
> any other change in the GPLed software in the device, it ought to pass
> it on to its customers.

It *DOES* *NOT* say "All rights that you have". It says "All rights that are 
granted you by this license". If every piece of software released under the 
GPL had *ALL* rights passed on, then *ANYONE* could do the "I'm granting 
company X the right to use this software outside the GPL for $50,000USD." 
instead of just the *creator* of the software.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> Now stop parroting the FSF's worn and tired tripe.

Are you playing Linus' sheeple and parroting his lines just to make a
point, or are you like that all the time? ;-)

> PS: Looking at your .sig I guess maybe you can't do that without getting 
> kicked out of the FSF-LA

Don't worry, I'm not speaking even for FSFLA, and I'm entitled to my
own opinion.

I haven't consulted other FSFLA members about this.  This is all my
own personal opinion.

It just so happens that I'm very closely involved in the process, I've
spent a lot of time thinking about it, and I happen to share a similar
moral and ethical background with others involved in the process, so I
arrive at similar conclusions.

And then, I influence the process myself, so it's not like some of the
arguments I brought up here weren't taken into account while creating
the GPLv3, and adopted by its other proponents.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 20:44:19 Adrian Bunk wrote:
> On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote:
> > On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> > > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > > On Wed, 13 Jun 2007, Alan Cox wrote:
> > > >> > find offensive, so I don't choose to use it. It's offensive
> > > >> > because Tivo never did anything wrong, and the FSF even
> > > >> > acknowledged that. The fact
> > > >>
> > > >> Not all of us agree with this for the benefit of future legal
> > > >> interpretation.
> > > >
> > > > Well, even the FSF lawyers did,
> > >
> > > Or rather they didn't think an attempt to enforce that in the US would
> > > prevail (or so I'm told).  That's not saying what TiVo did was right,
> > > and that's not saying that what TiVo did was permitted by the license.
> > > Only courts of law can do that.
> >
> > Wrong! Anyone with half a brain can make the distinction. What TiVO did
> > is entirely legal - they fully complied with the GPLv2. Note that what
> > they *DON'T* allow people to do is run whatever version of whatever
> > software they want on their hardware. They have that right - its the
> > "Free Software Foundation" and the GPL - regardless of version - is a
> > *SOFTWARE* license. ...
>
> The GPLv2 says:
>
> "For an executable work, complete source code means all the source code
> for all modules it contains, plus any associated interface definition
> files, plus the scripts used to control compilation and installation of
> the executable."
>
> The question is whether this includes private keys.
> Different people have different opinions regarding this issue.
>
> If "the complete source code" includes private keys, the GPLv2 requires
> them to give any costumer the private keys.
>
> Fact is that Harald Welte did in several cases successfully convince
> vendors that private keys are part of the source code if they are
> required for running the compiled binary on some hardware.

If the hardware was designed for the end-user to change the software running 
on it - including running software that it was never meant to run (ie: a 
complete webserver on cell phone) - then yes, the signing keys are a part of 
the source, as the software running on the device is designed to be updated 
by the user using the provided system.

If, on the other hand, the only "software updates" the user is expected to 
perform are the installation of newer versions of the existing code 
for "Security" or "Bug Fix" reasons then the signing keys aren't part of the 
source.

I haven't looked into what Harald Welte did, but I'd be surprised if someone 
tried following suit in America and had as much success.

>
> AFAIK there haven't been any court rulings on this issue, and it could
> even be that courts in different countries will decide differently.

Agreed.

DRH

>
> cu
> Adrian



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Neil Brown <[EMAIL PROTECTED]> wrote:

> Accusing people of arguing opinions that are not their own may well be
> appropriate. Accusing them of not be able to think is not.

I agree with the latter, but the former is seldom appropriate.  Any
accusation ought to be provable, and it's nearly impossible to prove
that an opinion held by someone is not his own.  People quite often
arrive at similar opinions independently.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Jörn Engel <[EMAIL PROTECTED]> wrote:

> On Wed, 13 June 2007 14:33:07 -0700, Linus Torvalds wrote:
>> 
>> The beauty of the GPLv2 is exactly that it's a "tit-for-tat" license, and 
>> you can use it without having to drink the kool-aid.

> One could even add that "tit-for-tat" appears to be the best strategy
> in game theory for continuous runs of the prisoners dilemma.

It is, indeed.

Now the remaining piece of the proof is to show that the GPLv2 is
tit-for-tat.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Bongani Hlope <[EMAIL PROTECTED]> wrote:

> On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote:

>> if you distribute copies of such a program, [...]
>> you must give the recipients all the rights that you have

>> So, TiVo includes a copy of Linux in its DVR.

> And they give you the same right that they had, which is obtain free software 
> that you can modify and redistribute. There's nothing in there that says they 
> should give you the tools they used after they received the software, which 
> is what you seem to be looking for.

Can they modify the software in their device?

Do they pass this right on?

>> TiVo retains the right to modify that copy of Linux as it sees fit.

>> It doesn't give the recipients the same right.

> It does, can't you modify their kernel source?

It's not the kernel source.  That's not where the TiVo anti-tampering
machinery blocks modifications.

It's about that copy of the kernel that ships in the device in object
code.  That's the one that TiVo customers ought to be entitled to
modify, if TiVo can modify it itself.

> Where does it say you should be able to run you modifications on the
> same hardware?

Where it says that you should pass on all the rights that you have.

While TiVo retains the ability to replace, upgrade, fix, break or make
any other change in the GPLed software in the device, it ought to pass
it on to its customers.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Adrian Bunk]

On Thu, Jun 14, 2007 at 02:15:53AM +0200, Bongani Hlope wrote:
> On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote:
> > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > The fact is, Tivo didn't take those rights away from you, yet the FSF
> > > says that what Tivo did was "against the spirit". That's *bullshit*.
> >
> > Oh, good, let's take this one.
> >
> >   if you distribute copies of such a program, [...]
> >   you must give the recipients all the rights that you have
> >
> > So, TiVo includes a copy of Linux in its DVR.
> 
> And they give you the same right that they had, which is obtain free software 
> that you can modify and redistribute. There's nothing in there that says they 
> should give you the tools they used after they received the software, which 
> is what you seem to be looking for.
>...

Wrong, the GPLv2 says:

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

The question is whether this includes private keys.
Different people have different opinions regarding this issue.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 20:14:47 Neil Brown wrote:
> On Wednesday June 13, [EMAIL PROTECTED] wrote:
> > 1: Sheeple (n): People that act like sheep - ie: they cannot think or
> > form opinions for themselves and always look to someone else for their
> > thoughts and parrot the opinions of some "trusted" figure.
>
> I recommend that you avoid definitions like this.  Using them simply
> makes you appear to have a very poor understanding of your fellow
> humans.
>
> "cannot" and "always" are absolutes that never apply (well, hardly
> ever).

In this case I gave a very hasty definition of the term, though it does fit 
very well. 

> In my experience, most people do think for themselves and do form
> opinions about areas where they have an interest/ability, and tend to
> follow trusted others in areas where they have less interest or
> ability.

Agreed. But those *aren't* "Sheeple".

> The problem that I think you see is particularly the "parrot the
> opinions" bit.  When a person tries to argue a case based largely on
> the opinion of someone else with little personal understanding, they
> are in very risky territory.   This is akin to 'fundamentalism' that
> you also mentioned in your post.
>
> Accusing people of arguing opinions that are not their own may well be
> appropriate. Accusing them of not be able to think is not.

I never accused any specific person of either. I was making an observation 
about the general nature of humanity as I've observed it. A better definition 
of "Sheeple" would be "Someone who continually parrots some "trusted" figures 
opinion even when presented with proof that that opinion is in error. They 
also, generally, do not "think deeply" on any topic."

And while I won't apologize to anyone that may have felt the "Sheeple" remark 
was directed at them, I will apologize for not taking more time to choose a 
better definition for the term originally.

DRH

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



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Adrian Bunk]

On Wed, Jun 13, 2007 at 07:46:15PM -0400, Daniel Hazelton wrote:
> On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > On Wed, 13 Jun 2007, Alan Cox wrote:
> > >> > find offensive, so I don't choose to use it. It's offensive because
> > >> > Tivo never did anything wrong, and the FSF even acknowledged that. The
> > >> > fact
> > >>
> > >> Not all of us agree with this for the benefit of future legal
> > >> interpretation.
> > >
> > > Well, even the FSF lawyers did,
> >
> > Or rather they didn't think an attempt to enforce that in the US would
> > prevail (or so I'm told).  That's not saying what TiVo did was right,
> > and that's not saying that what TiVo did was permitted by the license.
> > Only courts of law can do that.
> 
> Wrong! Anyone with half a brain can make the distinction. What TiVO did is 
> entirely legal - they fully complied with the GPLv2. Note that what they 
> *DON'T* allow people to do is run whatever version of whatever software they 
> want on their hardware. They have that right - its the "Free Software 
> Foundation" and the GPL - regardless of version - is a *SOFTWARE* license. 
>...

The GPLv2 says:

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

The question is whether this includes private keys.
Different people have different opinions regarding this issue.

If "the complete source code" includes private keys, the GPLv2 requires 
them to give any costumer the private keys.

Fact is that Harald Welte did in several cases successfully convince 
vendors that private keys are part of the source code if they are 
required for running the compiled binary on some hardware.

AFAIK there haven't been any court rulings on this issue, and it could 
even be that courts in different countries will decide differently.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 19:49:23 Alexandre Oliva wrote:

> > The fact is, Tivo didn't take those rights away from you, yet the FSF
> > says that what Tivo did was "against the spirit". That's *bullshit*.
>
> Oh, good, let's take this one.
>
>   if you distribute copies of such a program, [...]
>   you must give the recipients all the rights that you have
>
> So, TiVo includes a copy of Linux in its DVR.
>
> TiVo retains the right to modify that copy of Linux as it sees fit.
>
> It doesn't give the recipients the same right.
>
> Oops.
>
> Sounds like a violation of the spirit to me.
>
> Sounds like plugging this hole would retain the same spirit.

Are you an idiot, or do you just choose to ignore all proof that doesn't fit 
your preconceived beliefs? TiVO gives you every right to the Linux kernel 
that they recieved. What they don't give you the right to do is use modified 
versions on their *HARDWARE* - which they have *NEVER* given you any rights 
to, except for "normal use". (And no, it isn't legal to put those 200G hard 
drives in your TiVO no matter what you think) 

> > In other words, GPLv3 restricts rights that do not need to be restricted,
>
> That's correct.  They don't need to be restricted.  The whole idea of
> copyleft, implemented through the GPL, is not based on needs, but
> rather on the wish to defend the freedoms established in the preamble
> from those who would rather not respect them.
>
> Do you deny that TiVo prevents you (or at least a random customer)
> from modifying the copy of Linux that they ship in their DVR?

Exactly. They don't. What TiVO prevents is using that modified version on 
their hardware. And they have that right, because the Hardware *ISN'T* 
covered by the GPL.

Do you understand that, or do I need to break out the finger-puppets next ?

> Do you deny that they can still do it themselves?
>
> > Think of it this way: what if the GPLv3 had an addition saying "You can
> > not use this software to make a weapon".
>
> This would make GPLv3 a non-Free Software license.
>
> But the GPLv3 last call draft doesn't say anything along these lines.
>
> You can use the software as much as you like, even in DVRs, and even
> to implement DRM in them, as long as you respect the users' freedoms
> to change and share the software.  Per the GPLv3 (paraphrased), if it
> is possible to install modified versions of the covered program in the
> device, you must tell the recipient how to do it.  Otherwise, the
> freedom to modify the program is being too severely limited.

And this unnaturally restricts the freedom of hardware manufacturers. If they 
add a custom, internal connector so a repair shop can restore the hardware to 
its *FACTORY* state then it is "possible to install modified versions", 
provided the person doing it has the specialized hardware needed.

And this is what the FSF, RMS and yes, *YOU*, Alexandre, fail to realize - the 
GPL covers *ONLY* the software. It has *ZERO* legal standing when applied to 
hardware. Not even the most draconian of MS EULA's tries to apply itself to 
the hardware.

In the case of 99% of the hardware targeted by the clause of the GPLv3 you 
elucidate on, the "ability to install modified versions of the software" was 
*NOT* intended for that use, nor was it intended for *ANYONE* *EXCEPT* 
trained service personell to have *ACCESS* to that functionality. Arguing 
otherwise is just idiotic - I have never found a piece of "high tech" 
hardware (like a TiVO) that was designed for the end-user to modify. (yes, 
installing a new version of the linux kernel is "modifying" the system)

> And, in the particular case of TiVo, it's a case of distributing
> incomplete source code, of refraining from including functional
> portions of the source code.

And? They distribute the kernel source - as they recieved it - in compliance 
with the GPL. Their additions - whether they be "modules" or just the UI - do 
not, necessarily, fall under the GPL. (Yes, there have been discussions about 
whether a kernel module is a derived work, but most of the time those 
discussions ended "Legally they aren't, even though I feel they should be")

> > In other words, GPLv3 *restricts* peoples freedoms more than it
> > protects them.
>
> While you look at it from the point of view of TiVo, who wants to be
> free to prohibit people from modifying the workings of the device it
> sells while it can still modify it itself, and it does that in order
> to prohibit people from removing locks that stop them from doing
> things they're legally entitled to do, I see a lot more prohibitions
> than freedoms in what TiVo does.  I don't understand why you'd stand
> up for it.  Is it more important that a single company be allowed to
> impose prohibitions on others in order for its business model to work,
> than to maintain the spirit of hacking and sharing that enabled Free
> Software and Linux to flourish?

What "Legally Entitled" things?

And... You do realize that almost every difference 

Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6)

[David Chinner]

On Wed, Jun 13, 2007 at 12:16:36PM +0100, David Greaves wrote:
> Linus Torvalds wrote:
> >
> >On Fri, 8 Jun 2007, David Greaves wrote:
> >>positive: I can now get sysrq-t :)
> >
> >Ok, so color me confused,
> So what do you think that makes me 
> 
> >and maybe I have missed some of the emails or 
> >skimmed over them too fast (there's been too many of them ;),
> 
> You may have missed these 'tests' with rc4+Tejun's fix:
> * clean boot, unmounting the xfs fs : normal hibernate/resume
> * clean boot, remount ro xfs fs : normal hibernate/resume
> * clean boot, touch; sync; echo 1 > /proc/sys/vm/drop_caches: normal 
> hibernate/resume
> * clean boot, touch; sync; echo 2 > /proc/sys/vm/drop_caches: hang 
> hibernating
> * clean boot, touch; sync; echo 3 > /proc/sys/vm/drop_caches: hang 
> hibernating
> 
> Dave asked me to do them but hasn't responded yet.

Sorry 'bout that. Bit busy ATM.

What I was effectively looking for was whether it was data or metadata
that was causing the problems. From the above, it would appear that
dropping the page cache (echo 1 > drop caches) allows a successful
hibernate/resume. Next step would have been to isolate which cache
being dropped made the difference (e.g. a file or a bdev cache?).

However, it is clear from the back traces that there is something
unwell with md/sata code, so I don't think this needs to be tracked
any further from the filesystem perspective.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Bongani Hlope]

On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote:
> On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > The fact is, Tivo didn't take those rights away from you, yet the FSF
> > says that what Tivo did was "against the spirit". That's *bullshit*.
>
> Oh, good, let's take this one.
>
>   if you distribute copies of such a program, [...]
>   you must give the recipients all the rights that you have
>
> So, TiVo includes a copy of Linux in its DVR.
>

And they give you the same right that they had, which is obtain free software 
that you can modify and redistribute. There's nothing in there that says they 
should give you the tools they used after they received the software, which 
is what you seem to be looking for.

> TiVo retains the right to modify that copy of Linux as it sees fit.
>
> It doesn't give the recipients the same right.
>

It does, can't you modify their kernel source? Where does it say you should be 
able to run you modifications on the same hardware?

> Oops.
>
> Sounds like a violation of the spirit to me.
>
> Sounds like plugging this hole would retain the same spirit.

The only fear that I have with the whole Tivo saga, is that companies like 
Dell can use the same thing to say: "Our hardware will only run Company's X 
distribution of Linux". 

Do we just hope users won't buy those Dell machines, or do you modify your 
software license to force Dell to allow custom distributions to run on their 
machines? Then where do we draw the line of "Software Licenses".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Neil Brown]

On Wednesday June 13, [EMAIL PROTECTED] wrote:
> 1: Sheeple (n): People that act like sheep - ie: they cannot think or form 
> opinions for themselves and always look to someone else for their thoughts 
> and parrot the opinions of some "trusted" figure.

I recommend that you avoid definitions like this.  Using them simply
makes you appear to have a very poor understanding of your fellow
humans.

"cannot" and "always" are absolutes that never apply (well, hardly
ever).

In my experience, most people do think for themselves and do form
opinions about areas where they have an interest/ability, and tend to
follow trusted others in areas where they have less interest or
ability.

The problem that I think you see is particularly the "parrot the
opinions" bit.  When a person tries to argue a case based largely on
the opinion of someone else with little personal understanding, they
are in very risky territory.   This is akin to 'fundamentalism' that
you also mentioned in your post.

Accusing people of arguing opinions that are not their own may well be
appropriate. Accusing them of not be able to think is not.

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

Re: 2.6.22-rc4-git5 reiserfs: null ptr deref.

[Vladimir V. Saveliev]

Hello

Randy Dunlap wrote:
> while running fsx-linux on x86_64 system:
> 
thanks, I will take a look.

Is it reproducible? If yes, would you please try on some earlier kernel?

> [ 2213.064351] ReiserFS: sdb1: found reiserfs format "3.6" with standard 
> journal
> [ 2213.071516] ReiserFS: sdb1: using journaled data mode
> [ 2213.083124] ReiserFS: sdb1: journal params: device sdb1, size 8192, 
> journal first block 34, max trans len 512, max batch 450, max commit age 30, 
> max trans age 30
> [ 2213.098843] ReiserFS: sdb1: checking transaction log (sdb1)
> [ 2213.362156] ReiserFS: sdb1: Using r5 hash to sort names
> [ 2228.264867] Unable to handle kernel NULL pointer dereference at 
>  RIP:
> [ 2228.270363]  [] :reiserfs:do_journal_end+0x5de/0xced
> [ 2228.279370] PGD 114991067 PUD 105050067 PMD 0
> [ 2228.283865] Oops:  [1] SMP
> [ 2228.287044] CPU 0
> [ 2228.289078] Modules linked in: reiserfs loop
> [ 2228.293401] Pid: 5280, comm: fsx-linux Not tainted 2.6.22-rc4-git5 #1
> [ 2228.299834] RIP: 0010:[]  [] 
> :reiserfs:do_journal_end+0x5de/0xced
> [ 2228.309076] RSP: 0018:810106c6da48  EFLAGS: 00010286
> [ 2228.314385] RAX:  RBX: c200102cdf10 RCX: 
> 81011c861800
> [ 2228.321512] RDX: 0020 RSI:  RDI: 
> c20010292220
> [ 2228.328639] RBP: 810106c6db18 R08: 0002 R09: 
> 
> [ 2228.335767] R10: c200102cdf10 R11: 0048 R12: 
> c200102cbc78
> [ 2228.342895] R13: c200102cdf10 R14: c20010282000 R15: 
> 81011e5fe800
> [ 2228.350024] FS:  2b02d6aa7ae0() GS:80721000() 
> knlGS:
> [ 2228.358102] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 2228.363844] CR2:  CR3: 00010b6ea000 CR4: 
> 06e0
> [ 2228.370972] Process fsx-linux (pid: 5280, threadinfo 810106c6c000, 
> task 81011db7c040)
> [ 2228.379483] Stack:  8101143ae200 000a9c2c 810106c6da68 
> 0001
> [ 2228.387565]  810106c6db38 0020 81011c861800 
> 81011c5fd000
> [ 2228.395039]  81010dc7c2d0 0001  
> 810114b383c0
> [ 2228.402313] Call Trace:
> [ 2228.404963]  [] autoremove_wake_function+0x0/0x38
> [ 2228.411236]  [] :reiserfs:do_journal_end+0xcb9/0xced
> [ 2228.417766]  [] :reiserfs:do_journal_begin_r+0x260/0x335
> [ 2228.424643]  [] :reiserfs:journal_begin+0xb8/0xf6
> [ 2228.430913]  [] 
> :reiserfs:reiserfs_do_truncate+0x418/0x4be
> [ 2228.437961]  [] 
> :reiserfs:reiserfs_truncate_file+0x1a4/0x2b6
> [ 2228.445183]  [] 
> :reiserfs:reiserfs_vfs_truncate_file+0xe/0x10
> [ 2228.452492]  [] vmtruncate+0xaf/0xd0
> [ 2228.457632]  [] inode_setattr+0x2b/0x125
> [ 2228.463120]  [] :reiserfs:reiserfs_setattr+0x191/0x1bf
> [ 2228.469818]  [] __down_write_nested+0x3d/0xa1
> [ 2228.475730]  [] notify_change+0x129/0x23a
> [ 2228.481300]  [] do_truncate+0x63/0x81
> [ 2228.486521]  [] sys_ftruncate+0xea/0x107
> [ 2228.492003]  [] system_call+0x7e/0x83
> [ 2228.497223]
> [ 2228.498721]
> [ 2228.498722] Code: 8b 00 66 85 c0 0f 89 97 01 00 00 4c 89 ff 44 89 85 48 ff 
> ff
> [ 2228.507806] RIP  [] :reiserfs:do_journal_end+0x5de/0xced
> [ 2228.514700]  RSP 
> [ 2228.518190] CR2: 
> [ 2228.521841] Kernel panic - not syncing: Fatal exception
> [ 2228.527080] Rebooting in 30 seconds..
> 
> 
> 
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> -
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

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

Re: [BUG] ptraced process waiting on syscall may return kernel internal errnos

[Roland McGrath]

> btw, another interesting grep is to see how tweak TIF_SIGPENDING by
> hand ... there's some scary bits in the tty code too...

All I see there are the calls just added recently by Oleg, which are
correct and necessary to fix a bug.  Wrapping it in something less magical
might be nice.  It is the right thing to do in any place that is
introducing an -ERESTART* error code without having just checked signal_pending.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22-rc4-git5 reiserfs: null ptr deref.

[Randy Dunlap]

Vladimir V. Saveliev wrote:

Hello

Randy Dunlap wrote:

while running fsx-linux on x86_64 system:


thanks, I will take a look.

Is it reproducible? If yes, would you please try on some earlier kernel?


I haven't seen it in my almost-daily testing runs, but I'll try others
anyway.


[ 2213.064351] ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
[ 2213.071516] ReiserFS: sdb1: using journaled data mode
[ 2213.083124] ReiserFS: sdb1: journal params: device sdb1, size 8192, journal 
first block 34, max trans len 512, max batch 450, max commit age 30, max trans 
age 30
[ 2213.098843] ReiserFS: sdb1: checking transaction log (sdb1)
[ 2213.362156] ReiserFS: sdb1: Using r5 hash to sort names
[ 2228.264867] Unable to handle kernel NULL pointer dereference at 
 RIP:
[ 2228.270363]  [] :reiserfs:do_journal_end+0x5de/0xced
[ 2228.279370] PGD 114991067 PUD 105050067 PMD 0
[ 2228.283865] Oops:  [1] SMP
[ 2228.287044] CPU 0
[ 2228.289078] Modules linked in: reiserfs loop
[ 2228.293401] Pid: 5280, comm: fsx-linux Not tainted 2.6.22-rc4-git5 #1
[ 2228.299834] RIP: 0010:[]  [] 
:reiserfs:do_journal_end+0x5de/0xced
[ 2228.309076] RSP: 0018:810106c6da48  EFLAGS: 00010286
[ 2228.314385] RAX:  RBX: c200102cdf10 RCX: 81011c861800
[ 2228.321512] RDX: 0020 RSI:  RDI: c20010292220
[ 2228.328639] RBP: 810106c6db18 R08: 0002 R09: 
[ 2228.335767] R10: c200102cdf10 R11: 0048 R12: c200102cbc78
[ 2228.342895] R13: c200102cdf10 R14: c20010282000 R15: 81011e5fe800
[ 2228.350024] FS:  2b02d6aa7ae0() GS:80721000() 
knlGS:
[ 2228.358102] CS:  0010 DS:  ES:  CR0: 8005003b
[ 2228.363844] CR2:  CR3: 00010b6ea000 CR4: 06e0
[ 2228.370972] Process fsx-linux (pid: 5280, threadinfo 810106c6c000, task 
81011db7c040)
[ 2228.379483] Stack:  8101143ae200 000a9c2c 810106c6da68 
0001
[ 2228.387565]  810106c6db38 0020 81011c861800 
81011c5fd000
[ 2228.395039]  81010dc7c2d0 0001  
810114b383c0
[ 2228.402313] Call Trace:
[ 2228.404963]  [] autoremove_wake_function+0x0/0x38
[ 2228.411236]  [] :reiserfs:do_journal_end+0xcb9/0xced
[ 2228.417766]  [] :reiserfs:do_journal_begin_r+0x260/0x335
[ 2228.424643]  [] :reiserfs:journal_begin+0xb8/0xf6
[ 2228.430913]  [] :reiserfs:reiserfs_do_truncate+0x418/0x4be
[ 2228.437961]  [] 
:reiserfs:reiserfs_truncate_file+0x1a4/0x2b6
[ 2228.445183]  [] 
:reiserfs:reiserfs_vfs_truncate_file+0xe/0x10
[ 2228.452492]  [] vmtruncate+0xaf/0xd0
[ 2228.457632]  [] inode_setattr+0x2b/0x125
[ 2228.463120]  [] :reiserfs:reiserfs_setattr+0x191/0x1bf
[ 2228.469818]  [] __down_write_nested+0x3d/0xa1
[ 2228.475730]  [] notify_change+0x129/0x23a
[ 2228.481300]  [] do_truncate+0x63/0x81
[ 2228.486521]  [] sys_ftruncate+0xea/0x107
[ 2228.492003]  [] system_call+0x7e/0x83
[ 2228.497223]
[ 2228.498721]
[ 2228.498722] Code: 8b 00 66 85 c0 0f 89 97 01 00 00 4c 89 ff 44 89 85 48 ff ff
[ 2228.507806] RIP  [] :reiserfs:do_journal_end+0x5de/0xced
[ 2228.514700]  RSP 
[ 2228.518190] CR2: 
[ 2228.521841] Kernel panic - not syncing: Fatal exception
[ 2228.527080] Rebooting in 30 seconds..



--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RT] fix migrating softirq [cause of network hang]

[Steven Rostedt]

On Wed, 13 Jun 2007, Shane wrote:

> On 6/13/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > > I have applied this patch to 2.6.21.4-rt13 and I think it might have
> > > solved my bizarre nfs hangage issues that cropped up lately. Thanks
> > > for tracking that down it was driving me nutz!
> > >
> > > It has only been a few hours, but if you don't hear back from me in
> > > the next day or so then it's good to go IMVHO. :)
> > >
> >
> > Hi Shane,
> >
> > That's great to hear!  Well, if it does go well, could you post to LKML
> > and linux-rt mailing lists, as well as CC'ng Ingo. Good news like this
> > should be shared ;-)
> >
> > Heh, even if it doesn't go well, you can post to the above too.
>
> Heh, I spoke too soon. This patch doesn't seem to help my problem after all. 
> :/
>

Really?  Darn.

So it seemed to work? Just curious to why you thought it worked and but it
didn't?

-- Steve

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

Re: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc

[David Chinner]

On Tue, Jun 12, 2007 at 11:46:52AM +0530, Amit K. Arora wrote:
> Did you get time to write the above man page ? It will help to push
> further patches in time (eg. for FA_PREALLOCATE mode).

First pass is attached.

`nroff -man fallocate.2 | less` to view.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
.TH fallocate 2
.SH NAME
fallocate \- allocate or remove file space
.SH SYNOPSIS
.nf
.B #include 
.PP
.BI "int syscall(int, int fd, int mode, loff_t offset, loff_t len);
.Op
.SH DESCRIPTION
The
.BR fallocate
syscall allows a user to directly manipulate the allocated disk space
for the file referred to by
.I fd
for the byte range starting at
.IR offset
and continuing for
.IR len
bytes.
The
.I mode
parameter determines the operation to be performed on the given range.
Currently there are three modes:
.TP
.B FA_ALLOCATE
allocates and initialises to zero the disk space within the given range.
After a successful call, subsequent writes are guaranteed not to fail because
of lack of disk space.  If the size of the file is less than
IR offset + len ,
then the file is increased to this size; otherwise the file size is left
unchanged.
B FA_ALLOCATE
closely resembles
B posix_fallocate(3)
and is intended as a method of optimally implementing this function.
B FA_ALLOCATE
may allocate a larger range that was specified.
TP
B FA_PREALLOCATE
provides the same functionality as
B FA_ALLOCATE
except it does not ever change the file size. This allows allocation
of zero blocks beyond the end of file and is useful for optimising
append workloads.
TP
B FA_DEALLOCATE
removes the underlying disk space with the given range. The disk space
shall be removed regardless of it's contents so both allocated space
from
B FA_ALLOCATE
and
B FA_PREALLOCATE
as well as from
B write(3)
will be removed.
B FA_DEALLOCATE
shall never remove disk blocks outside the range specified.
B FA_DEALLOCATE
shall never change the file size. If changing the file size
is required when deallocating blocks from an offset to end
of file (or beyond end of file) is required,
B ftuncate64(3)
should be used.

SH "RETURN VALUE"
BR fallocate()
returns zero on success, or an error number on failure.
Note that
IR errno
is not set.
SH "ERRORS"
TP
B EBADF
I fd
is not a valid file descriptor, or is not opened for writing.
TP
B EFBIG
I offset+len
exceeds the maximum file size.
TP
B EINVAL
I offset
or
I len
was less than 0.
TP
B ENODEV
I fd
does not refer to a regular file or a directory.
TP
B ENOSPC
There is not enough space left on the device containing the file
referred to by
IR fd.
TP
B ESPIPE
I fd
refers to a pipe of file descriptor.
B ENOSYS
The filesystem underlying the file descriptor does not support this
operation.
SH AVAILABILITY
The
BR fallocate ()
system call is available since 2.6.XX
SH "SEE ALSO"
BR syscall (2),
BR posix_fadvise (3)
BR ftruncate (3)

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> On Wed, 13 Jun 2007, Alexandre Oliva wrote:
>> 
>> [...] Our General Public Licenses are designed to make sure that you have
>> the freedom to distribute copies of free software (and charge for
>> this service if you wish), that you receive source code or can get
>> it if you want it, that you can change the software or use pieces of
>> it in new free programs; and that you know you can do these things.
>> 
>> To protect your rights, we need to make restrictions that forbid
>> anyone to deny you these rights or to ask you to surrender the
>> rights.  These restrictions translate to certain responsibilities
>> for you if you distribute copies of the software, or if you modify
>> it.
>> 
>> [...] if you distribute copies of such a program, whether gratis or
>> for a fee, you must give the recipients all the rights that you have
>> 
>> 
>> Can anyone show me how any of the provisions of GPLv3 fails to meet
>> this spirit?

> What kind of logic is that? It sounds like "Can you prove that God doesn't 
> exist?"

By this reasoning, it sounds like you've been claiming that "God does
exist", even though you can't prove it.

It shouldn't be anywhere that difficult to show that the GPLv3 fails
to meet the spirit of the GPLs.  You just have to show a single
counter-example.  Since there are so many objections to the changes,
it shouldn't be that hard.  Can you at least try?

> The fact is, Tivo didn't take those rights away from you, yet the FSF says 
> that what Tivo did was "against the spirit". That's *bullshit*.

Oh, good, let's take this one.

  if you distribute copies of such a program, [...]
  you must give the recipients all the rights that you have

So, TiVo includes a copy of Linux in its DVR.  

TiVo retains the right to modify that copy of Linux as it sees fit.

It doesn't give the recipients the same right.

Oops.

Sounds like a violation of the spirit to me.

Sounds like plugging this hole would retain the same spirit.

> In other words, GPLv3 restricts rights that do not need to be restricted, 

That's correct.  They don't need to be restricted.  The whole idea of
copyleft, implemented through the GPL, is not based on needs, but
rather on the wish to defend the freedoms established in the preamble
from those who would rather not respect them.

Do you deny that TiVo prevents you (or at least a random customer)
from modifying the copy of Linux that they ship in their DVR?

Do you deny that they can still do it themselves?

> Think of it this way: what if the GPLv3 had an addition saying "You can 
> not use this software to make a weapon".

This would make GPLv3 a non-Free Software license.

But the GPLv3 last call draft doesn't say anything along these lines.

You can use the software as much as you like, even in DVRs, and even
to implement DRM in them, as long as you respect the users' freedoms
to change and share the software.  Per the GPLv3 (paraphrased), if it
is possible to install modified versions of the covered program in the
device, you must tell the recipient how to do it.  Otherwise, the
freedom to modify the program is being too severely limited.

And, in the particular case of TiVo, it's a case of distributing
incomplete source code, of refraining from including functional
portions of the source code.

> In other words, GPLv3 *restricts* peoples freedoms more than it
> protects them.

While you look at it from the point of view of TiVo, who wants to be
free to prohibit people from modifying the workings of the device it
sells while it can still modify it itself, and it does that in order
to prohibit people from removing locks that stop them from doing
things they're legally entitled to do, I see a lot more prohibitions
than freedoms in what TiVo does.  I don't understand why you'd stand
up for it.  Is it more important that a single company be allowed to
impose prohibitions on others in order for its business model to work,
than to maintain the spirit of hacking and sharing that enabled Free
Software and Linux to flourish?

Do you expect Linux would have flourished if computers had locks that
stopped people from modifying Linux in them?

> where I added the "that you can do so in place on your devices, even if 
> those devices weren't licensed under the GPL".

You're mistakenly focusing on the device.  As you say, the device is
not under the license.

What's under the license is the software in it.  And that license
spirit requires the distributor to pass on the right to modify the
software.

> I don't know if you've followed US politics very much over the last
> six years, but there's been a lot of "protecting our freedoms" going
> on. And it's been ugly. Maybe you could realize that sometimes
> "protecting your freedom" is *anything*but*!

Is this why you're overreacting?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 19:35:41 Jörn Engel wrote:
> On Wed, 13 June 2007 14:33:07 -0700, Linus Torvalds wrote:
> > The beauty of the GPLv2 is exactly that it's a "tit-for-tat" license, and
> > you can use it without having to drink the kool-aid.
>
> One could even add that "tit-for-tat" appears to be the best strategy
> in game theory for continuous runs of the prisoners dilemma.  At times I
> wonder why game theory isn't taught in schools yet - it might shorten
> discussions like these.
>
> Jörn

With the sheer amount of sheeple[1] in the world (and on this list), I doubt 
anything could make these discussions any shorter.

(While I hate thinking that sheeple are on this list, it is an unavoidable 
fact. (I had hoped I wouldn't find any sheeple here, as my favorite theory is 
that they are all "Fundamentalist Christians" like the "Creationist" fools))

DRH
1: Sheeple (n): People that act like sheep - ie: they cannot think or form 
opinions for themselves and always look to someone else for their thoughts 
and parrot the opinions of some "trusted" figure.

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Wednesday 13 June 2007 19:15:42 Alexandre Oliva wrote:
> On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Wed, 13 Jun 2007, Alan Cox wrote:
> >> > find offensive, so I don't choose to use it. It's offensive because
> >> > Tivo never did anything wrong, and the FSF even acknowledged that. The
> >> > fact
> >>
> >> Not all of us agree with this for the benefit of future legal
> >> interpretation.
> >
> > Well, even the FSF lawyers did,
>
> Or rather they didn't think an attempt to enforce that in the US would
> prevail (or so I'm told).  That's not saying what TiVo did was right,
> and that's not saying that what TiVo did was permitted by the license.
> Only courts of law can do that.

Wrong! Anyone with half a brain can make the distinction. What TiVO did is 
entirely legal - they fully complied with the GPLv2. Note that what they 
*DON'T* allow people to do is run whatever version of whatever software they 
want on their hardware. They have that right - its the "Free Software 
Foundation" and the GPL - regardless of version - is a *SOFTWARE* license. 
TiVO never stopped people from copying, modifying or distributing the code - 
what they did was say "The code is GPL'd, the hardware is restricted" - 
ie: "You can do what you want with the code, but you can only run compiled 
version of it that we provide on our hardware". Why is that legal? Because 
TiVO produces the hardware and sells it to you with a certain *LICENSE* - 
because it does contain hardware covered under any number of patents. That 
license grants you the right to use the patents - in this case algorithms - 
provided you comply with the terms of the license. (Just like the GPL gives 
you the right to copy, modify and distribute GPL'd code as long as you comply 
with its terms)

If you believe otherwise then you are sadly mistaken. Now stop parroting the 
FSF's worn and tired tripe.

DRH
PS: Looking at your .sig I guess maybe you can't do that without getting 
kicked out of the FSF-LA

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Jörn Engel]

On Wed, 13 June 2007 14:33:07 -0700, Linus Torvalds wrote:
> 
> The beauty of the GPLv2 is exactly that it's a "tit-for-tat" license, and 
> you can use it without having to drink the kool-aid.

One could even add that "tit-for-tat" appears to be the best strategy
in game theory for continuous runs of the prisoners dilemma.  At times I
wonder why game theory isn't taught in schools yet - it might shorten
discussions like these.

Jörn

-- 
All art is but imitation of nature.
-- Lucius Annaeus Seneca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm 0/7] PM: Remove unused and unnecessary features from suspend and resume core

[Pavel Machek]

Hi!

> The following series of patches removes some unused and unnecessary features
> from the suspend and resume core code.

Hmm, patches 1-4 are pretty much obvious cleanups, I guess they can go
in.

Patches 5+ change semantics of suspend/resume callbacks in subtle way,
I guess they need to stay in -mm for a while...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [patch 0/3] no MAX_ARG_PAGES -v2

[Luck, Tony]

> This patch-set aims at removing the current limit on argv+env space aka.
> MAX_ARG_PAGES.

Running with this patch shows that /bin/bash has some unpleasant
O(n^2) performance issues with long argument lists.  I made a
1Mbyte file full of pathnames, then timed the execution of:

$ /bin/echo `cat megabyte` | wc
$ /bin/echo `cat megabyte megabyte` | wc
   etc. ...

System time was pretty much linear as the arglist grew
(and only got up to 0.144 seconds at 5Mbytes).

But user time ~= real time (in seconds) looks like:

1 5.318
2 18.871
3 40.620
4 70.819
5 108.911

Above 5Mbytes, I started seeing problems.  The line/word/char
counts from "wc" started being "0 0 0".  Not sure if this is
a problem in "wc" dealing with a single line >5MBytes, or some
other problem (possibly I was exceeding the per-process stack
limit which is only 8MB on that machine).

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

Re: raid1 with nbd member hangs MD on SLES10 and RHEL5

[Mike Snitzer]

On 6/13/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:

On 6/13/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Neil Brown <[EMAIL PROTECTED]> wrote:
...
> > > > On 6/12/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> > > > > On Tuesday June 12, [EMAIL PROTECTED] wrote:
> > > > > >
> > > > > > I can provided more detailed information; please just ask.
> > > > > >
> > > > >
> > > > > A complete sysrq trace (all processes) might help.

Bringing this back to a wider audience.  I provided the full sysrq
trace of the RHEL5 kernel to Neil; in it we saw that md0_raid1 had the
following trace:

md0_raid1 D 810026183ce0  5368 31663 11  3822 29488 (L-TLB)
 810026183ce0 810031e9b5f8 0008 000a
 810037eef040 810037e17100 00043e64d2983c1f 4c7f
 810037eef210 00010001 00081c506640 
Call Trace:
 [] keventd_create_kthread+0x0/0x61
 [] md_super_wait+0xa8/0xbc
 [] autoremove_wake_function+0x0/0x2e
 [] md_update_sb+0x1dd/0x23a
 [] md_check_recovery+0x15f/0x449
 [] :raid1:raid1d+0x27/0xc1e
 [] thread_return+0x0/0xde
 [] __sched_text_start+0xc/0xa79
 [] keventd_create_kthread+0x0/0x61
 [] schedule_timeout+0x1e/0xad
 [] keventd_create_kthread+0x0/0x61
 [] md_thread+0xf8/0x10e
 [] autoremove_wake_function+0x0/0x2e
 [] md_thread+0x0/0x10e
 [] kthread+0xd4/0x109
 [] child_rip+0xa/0x11
 [] keventd_create_kthread+0x0/0x61
 [] kthread+0x0/0x109
 [] child_rip+0x0/0x11

To which Neil had the following to say:

> > md0_raid1 is holding the lock on the array and trying to write out the
> > superblocks for some reason, and the write isn't completing.
> > As it is holding the locks, mdadm and /proc/mdstat are hanging.

...


> We're using MD+NBD for disaster recovery (one local scsi device, one
> remote via nbd).  The nbd-server is not contributing to md0.  The
> nbd-server is connected to a remote machine that is running a raid1
> remotely

To take this further I've now collected a full sysrq trace of this
hang on a SLES10 SP1 RC5 2.6.16.46-0.12-smp kernel, the relevant
md0_raid1 trace is comparable to the RHEL5 trace from above:

md0_raid1 D 810001089780 0  8583 51  8952  8260 (L-TLB)
810812393ca8 0046 8107b7fbac00 000a
   81081f3c6a18 81081f3c67d0 8104ffe8f100 44819ddcd5e2
   eb8b 0007028009c7
Call Trace: {generic_make_request+501}
   {md_super_wait+168}
{autoremove_wake_function+0}
   {write_page+128} {md_update_sb+220}
   {md_check_recovery+361}
{:raid1:raid1d+38}
   {lock_timer_base+27}
{try_to_del_timer_sync+81}
   {del_timer_sync+12}
{schedule_timeout+146}
   {keventd_create_kthread+0}
{md_thread+248}
   {autoremove_wake_function+0}
{md_thread+0}
   {kthread+236} {child_rip+8}
   {keventd_create_kthread+0}
{kthread+0}
   {child_rip+0}

Taking a step back, here is what was done to reproduce on SLES10:
1) establish a raid1 mirror (md0) using one local member (sdc1) and
one remote member (nbd0)
2) power off the remote machine, whereby severing nbd0's connection
3) perform IO to the filesystem that is on the md0 device to enduce
the MD layer to mark the nbd device as "faulty"
4) cat /proc/mdstat hangs, sysrq trace was collected and showed the
above md0_raid1 trace.

To be clear, the MD superblock update hangs indefinitely on RHEL5.
But with SLES10 it eventually succeeds (and MD marks the nbd0 member
faulty); and the other tasks that were blocking waiting for the MD
lock (e.g. 'cat /proc/mdstat') then complete immediately.

It should be noted that this MD+NBD configuration has worked
flawlessly using a stock kernel.org 2.6.15.7 kernel (ontop of a
RHEL4U4 distro).  Steps have not been taken to try to reproduce  with
2.6.15.7 on SLES10; it may be useful to pursue but I'll defer to
others to suggest I do so.

2.6.15.7 does not have the SMP race fixes that were made in 2.6.16;
yet both SLES10 and RHEL5 kernels do:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4b2f0260c74324abca76ccaa42d426af163125e7

If not this specific NBD change, something appears to have changed
with how NBD behaves in the face of it's connection to the server
being lost.  Almost like the MD superblock update that would be
written to nbd0 is blocking within nbd or the network layer because of
a network timeout issue?


Just a quick update; it is really starting to look like there is
definitely an issue with the nbd kernel driver.  I booted the SLES10
2.6.16.46-0.12-smp kernel with maxcpus=1 to test the theory that the
nbd SMP fix that went into 2.6.16 was in some way causing this MD/NBD
hang.  But it _still_ occurs with the 4-step process I outlined above.

The nbd0 device _should_ feel an NBD_DISCONNECT because the nbd-server
is no longer running (the node it was running on was powered off)...
however the nbd-client is still connected to the kernel (meaning the
kernel didn't return an error 

Re: + fs-introduce-write_begin-write_end-and-perform_write-aops.patch added to -mm tree

[Nick Piggin]

On Wed, Jun 13, 2007 at 04:07:01PM -0700, Badari Pulavarty wrote:
> On Wed, 2007-06-13 at 13:43 +0200, Nick Piggin wrote:
> ..
> >  
> > > 5) ext3_write_end:
> > >   Before  write_begin/write_end patch set we have folowing locking
> > >   order:
> > >   stop_journal(handle);
> > >   unlock_page(page);
> > >   But now order is oposite:
> > >   unlock_page(page);
> > >   stop_journal(handle);
> > >   Can we got any race condition now? I'm not sure is it actual problem,
> > >   may be somebody cant describe this.
> > 
> > Can we just change it to the original order? That would seem to be
> > safest unless one of the ext3 devs explicitly acks it.
> 
> It would be nice to go back to original order, but its not that
> simple with current structure of the code. With Nick's patches
> unlock_page() happens in generic_write_end(). journal_stop() 
> needs to happen after generic_write_end(). :(

Well we could use block_write_end?

 
> Mingming, can you take a look at the current & proposed order ?
> I ran into bunch of races when I tried to change the order for
> ->writepages() support earlier :(

OK, it sounds like we probably want to revert to the original
order at least for this patchset. If the new order is proven
safe then that could be introduced later to simplify things...

Thanks,
Nick

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

Re: [BUG] ptraced process waiting on syscall may return kernel internal errnos

[Benjamin Herrenschmidt]

On Wed, 2007-06-13 at 16:01 -0700, Roland McGrath wrote:
> 
> > What about something like:
> > 
> >   do {
> >   rm_from_queue_full(, >pending);
> > - recalc_sigpending_and_wake(t);
> >   t = next_thread(t);
> >   } while (t != current);
> > + recalc_sigpending();
> 
> There is no need for the +, just the -.  The calling thread is the one
> where know there is certainly no perturbation of behavior due to leaving
> TIF_SIGPENDING set rather than clearing it.  It's just going to exit the
> syscall and deal with signal state properly on the way out either way.
> Doing recalc_sigpending is an unnecessary optimization of the corner case.

Fair enough. I'll cook a patch for that one when I'm at work.

> > So at the end of the day, easier to test it inside dequeue_signal().
> 
> Before completely revamping the whole set of entrypoints to be saner all
> around, yes.

btw, another interesting grep is to see how tweak TIF_SIGPENDING by
hand ... there's some scary bits in the tty code too...

Ben.


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

Re: [RFC] TOMOYO Linux

[Toshiharu Harada]

Morris, thank you for your comment.

2007/6/14, James Morris <[EMAIL PROTECTED]>:

On Thu, 14 Jun 2007, Toshiharu Harada wrote:

> TOMOYO Linux has a mode called "learning"
> in addition to "permissive" and "enforce". You can easily
> get the TOMOYO Linux policy with learning mode that
> SELinux does not have.

Blindly generating security policy through observation of the system is
potentially dangerous for many reasons.
See




When I saw Russell Coker and showed him a demonstration of
TOMOYO Linux, he told the same comment.
Also after tracing an AppAmor's long thread, I'm convinced of the
meaning of label base. That's why I don't think TOMOYO Linux as a
replace of SELinux. "Professional policy (or reference policy)"
makes sense to me.

However it may be safe for audition and profiling purpose.
Policy learning feature of TOMOYO Linux will help
understanding the behavior of Linux boxes.
That is my point.

I will double check the link you showed me. Thank you.
(It's wonderful to receive comments from you and Stephen!)


Note that while SELinux does also have a similar capability with the
audit2allow tool, it should be considered an expert tool, the output of
which needs to be understood before use (as noted in its man page).


Yes. But I remember Frank said "don't use it :-)" when he gave a
presentation in Japan.


> In addition, access control mode of
> TOMOYO Linux can be managed for every difference domain.

We have considered per-domain enforcing mode a couple of times in the
past, but figured that it could be implemented via policy alone (e.g. run
the task in a domain where all accesses are allowed and logged); and it
would also be of limited usefulness because of the aforementioned problems
with learning mode security policy.


I'll reply this part in later.

Thanks!
Toshiharu Harada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> On Wed, 13 Jun 2007, Alan Cox wrote:

>> > find offensive, so I don't choose to use it. It's offensive because Tivo 
>> > never did anything wrong, and the FSF even acknowledged that. The fact 

>> Not all of us agree with this for the benefit of future legal
>> interpretation.

> Well, even the FSF lawyers did,

Or rather they didn't think an attempt to enforce that in the US would
prevail (or so I'm told).  That's not saying what TiVo did was right,
and that's not saying that what TiVo did was permitted by the license.
Only courts of law can do that.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> On Wed, 13 Jun 2007, Alexandre Oliva wrote:
>> 
>> Look, there was room for misunderstandings in earlier drafts of the
>> license.  Based on the public comments, the wording was improved.  I'd
>> like to think the issues that arose from misunderstandings of the
>> earlier drafts are no longer an issue.  Is it not so?

> No. The anti-DRM language is still there, and no, it was never a 
> misunderstanding.

It was claimed that GPLv3 would forbid implementations of DRM.  That's
just plain false.  If you don't think so, please show what terms in
the latest draft prohibit DRM (as opposed to merely making it
ineffective, a necessary consequence of abiding by the spirit of all
GNU GPLs)

> It's offensive because Tivo never did anything wrong, and the FSF
> even acknowledged that.

Another misunderstanding.  The FSF never said TiVo didn't do anything
wrong.  It only said it didn't think there was a license violation.  I
personally disagree with that assessment, but IANAL.

Anyhow, deciding whether it's right or wrong is not the same as
deciding whether it's legal or illegal.  Law doesn't define what's
right or wrong.  That's what morals and ethics do.

> want to protect the integrity of that hardware.

> The kernel license covers the *kernel*.

When they choose to include a copy of the kernel in their hardware
that they can modify but others can't, they're failing to comply with
the spirit of the license.  For brevity, I won't repeat the quotes
from the GPLv2 preamble, that I just included in the message I sent to
Lennart Sorensen in this same thread.  Can you justify how you came to
the conclusion (if you did) that TiVo is abiding by the spirit of the
license?

>> Keeping on making false claims about the license drafts can be one of
>> two things: misunderstandings, out of ambiguity in the text or
>> preconceptions, or ill intentions.  I'd rather believe it's the
>> former.

> No, it was not the former.

Wow, I didn't see that coming.  Public admission of ill intentions?
;-) :-D :-P

> And I think the whole "the kernel developers misunderstand the
> license" crap that the FSF was saying (several times) was very
> trying to confuse the issue: the FSF knew damn well which part of
> the license was obnoxious, they just tried to confuse the issue by
> pointing to *another* part of the license.

Let me see if I got this right.  There was a section entitled
"3. Digital Restrictions Management" in GPLv3dd1.  Are you saying
that, when people complained about the DRM clause, they actually meant
the provisions in "1. Source Code", that established a requirement to
include the source code corresponding to functional signatures, namely
the signing keys, as part of the corresponding source code?

> And you're just parrotting their idiotic line.

Please watch your tone.  If you find offense at the allegedly
condescending tone in which the FSF says "misunderstanding", how do
you expect me and the FSF to take this?

It is also odd that you claim the right to be entitled to your own
opinion and reading about stuff, while denying myself the same right.
Please don't do that.  I have a mind of my own, and the fact that I
reach similar conclusions doesn't make me a parrot.  Even more so when
I actually have some influence on those conclusions.

>> Now, of course you can look at the licenses and decide that you never
>> agreed with the spirit of the GPL in the first place, and that GPLv2
>> models better your intentions than GPLv3.

> And this is again the same *disease*. You claim that I "misunderstood" the 
> "spirit of the GPL".

> Dammit, the GPL is a license. I understand it quite well. Probably better 
> than most. The fact that the FSF then noticed that there were *other* 
> things that they wanted to do, and that were *not* covered by the GPLv2, 
> does *not* mean that they can claim that others "misunderstood" the 
> license.

> I understood it perfectly fine, and it fit my needs. So tell me: who is 
> the more confused one: the one who chose the license fifteen years ago, 
> and realized what it means legally, and still stands behind it? I don't 
> think so.

You are definitely confused.  You're talking about the legal terms,
while I'm talking about the spirit.  The legal terms tried to reflect
the spirit as best as they could, but they left some holes.  Some
people found them and started exploiting them.

Sure, if you want to leave those holes unplugged in your code, that's
your decision.  I don't doubt that the GPLv2 legal terms fit the bill
for you.  I think GPLv3 would do even better in this regard.  But none
of this is about the spirit of the GPL.  Claiming GPLv3 changes the
spirit is totally missing the point of what the spirit amounts to.
The spirit is described in the preamble, it's not the legal terms.

> The beauty of the GPLv2 is exactly that it's a "tit-for-tat"
> license,

Ok, let's explore this argument.  In what sense is it tit-for-tat?
What is 

Re: [Processor] Hi-Temperature showed in trip points

[Robert Hancock]

Renato S. Yamane wrote:

Hi,
I have a laptop Toshiba M45-S355 (with Intel Pentium M Processor 750 - 
1.86GHz) and trip points show me hi-temperature (that is unsupported by 
this processor):


$ uname -a
Linux mandachuva 2.6.21.1 #1 PREEMPT Sun May 20 22:28:53 BRT 2007 i686 
GNU/Linux


$ cat /proc/acpi/thermal_zone/TZCL/trip_points
critical (S5):   105 C

MAX temperature suported by this processor is 100°C (I see this in Intel 
specifications), so I think that is not very good idea allow 
temperatures higher than 100°C.


That trip point comes from the BIOS.. likely complain to Toshiba, if 
anyone. Likely the CPU itself will start throttling or shut down well 
before that temperature is reached.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

2.6.22-rc4-git5 reiserfs: null ptr deref.

[Randy Dunlap]

while running fsx-linux on x86_64 system:

[ 2213.064351] ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
[ 2213.071516] ReiserFS: sdb1: using journaled data mode
[ 2213.083124] ReiserFS: sdb1: journal params: device sdb1, size 8192, journal 
first block 34, max trans len 512, max batch 450, max commit age 30, max trans 
age 30
[ 2213.098843] ReiserFS: sdb1: checking transaction log (sdb1)
[ 2213.362156] ReiserFS: sdb1: Using r5 hash to sort names
[ 2228.264867] Unable to handle kernel NULL pointer dereference at 
 RIP:
[ 2228.270363]  [] :reiserfs:do_journal_end+0x5de/0xced
[ 2228.279370] PGD 114991067 PUD 105050067 PMD 0
[ 2228.283865] Oops:  [1] SMP
[ 2228.287044] CPU 0
[ 2228.289078] Modules linked in: reiserfs loop
[ 2228.293401] Pid: 5280, comm: fsx-linux Not tainted 2.6.22-rc4-git5 #1
[ 2228.299834] RIP: 0010:[]  [] 
:reiserfs:do_journal_end+0x5de/0xced
[ 2228.309076] RSP: 0018:810106c6da48  EFLAGS: 00010286
[ 2228.314385] RAX:  RBX: c200102cdf10 RCX: 81011c861800
[ 2228.321512] RDX: 0020 RSI:  RDI: c20010292220
[ 2228.328639] RBP: 810106c6db18 R08: 0002 R09: 
[ 2228.335767] R10: c200102cdf10 R11: 0048 R12: c200102cbc78
[ 2228.342895] R13: c200102cdf10 R14: c20010282000 R15: 81011e5fe800
[ 2228.350024] FS:  2b02d6aa7ae0() GS:80721000() 
knlGS:
[ 2228.358102] CS:  0010 DS:  ES:  CR0: 8005003b
[ 2228.363844] CR2:  CR3: 00010b6ea000 CR4: 06e0
[ 2228.370972] Process fsx-linux (pid: 5280, threadinfo 810106c6c000, task 
81011db7c040)
[ 2228.379483] Stack:  8101143ae200 000a9c2c 810106c6da68 
0001
[ 2228.387565]  810106c6db38 0020 81011c861800 
81011c5fd000
[ 2228.395039]  81010dc7c2d0 0001  
810114b383c0
[ 2228.402313] Call Trace:
[ 2228.404963]  [] autoremove_wake_function+0x0/0x38
[ 2228.411236]  [] :reiserfs:do_journal_end+0xcb9/0xced
[ 2228.417766]  [] :reiserfs:do_journal_begin_r+0x260/0x335
[ 2228.424643]  [] :reiserfs:journal_begin+0xb8/0xf6
[ 2228.430913]  [] :reiserfs:reiserfs_do_truncate+0x418/0x4be
[ 2228.437961]  [] 
:reiserfs:reiserfs_truncate_file+0x1a4/0x2b6
[ 2228.445183]  [] 
:reiserfs:reiserfs_vfs_truncate_file+0xe/0x10
[ 2228.452492]  [] vmtruncate+0xaf/0xd0
[ 2228.457632]  [] inode_setattr+0x2b/0x125
[ 2228.463120]  [] :reiserfs:reiserfs_setattr+0x191/0x1bf
[ 2228.469818]  [] __down_write_nested+0x3d/0xa1
[ 2228.475730]  [] notify_change+0x129/0x23a
[ 2228.481300]  [] do_truncate+0x63/0x81
[ 2228.486521]  [] sys_ftruncate+0xea/0x107
[ 2228.492003]  [] system_call+0x7e/0x83
[ 2228.497223]
[ 2228.498721]
[ 2228.498722] Code: 8b 00 66 85 c0 0f 89 97 01 00 00 4c 89 ff 44 89 85 48 ff ff
[ 2228.507806] RIP  [] :reiserfs:do_journal_end+0x5de/0xced
[ 2228.514700]  RSP 
[ 2228.518190] CR2: 
[ 2228.521841] Kernel panic - not syncing: Fatal exception
[ 2228.527080] Rebooting in 30 seconds..



---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6)

[Rafael J. Wysocki]

On Thursday, 14 June 2007 00:12, Linus Torvalds wrote:
> 
> On Wed, 13 Jun 2007, David Greaves wrote:
> >
> > > I'm not seeing anything really obvious. The traces would probably look
> > > better if you enabled CONFIG_FRAME_POINTER, though. That should cut down 
> > > on
> > > some of the noise and make the traces a bit more readable.
> > 
> > I can do that...
> 
> Thanks. That makes a big difference to the readability of the traces.
> 
> That said, I'm so used to reading even the messy ones that this didn't 
> actually tell me anything new (it made it clear that the SCSI error 
> handler noise was just noise), but for people who aren't quite as used to 
> seeing crap backtraces, your new trace might hopefully put them on the 
> right track.
> 
> I threw out the parts that didn't look all that relevant, and left the
> ata_aux/md0_raid5/hibernate traces here for others to look at without all 
> the other noise. Those _seem_ to be the primary suspects in this saga.

Hmm, it looks like both hibernate and ata_aux are waiting for the same
completion.  I wonder who's supposed to complete it.

Greetings,
Rafael


> ---
> > ata_aux   D F7945000 0   122  2 (L-TLB)
> >c19f7ce0 0046 f7ea23b8 f7945000 c19f7ca0 c0121d67 c198d800 
> > f7ea23b8
> >c19f7cb0 c02261b7 f6af7964 f7ea23b8 c19f7cc0 c0293942 f7e865d0 
> > c1a026bc
> >c19f7cf0 03ae 2dae0756 0009 c19f7cf0 c19f7dc8 f6af7964 
> > c19f7cfc
> > Call Trace:
> >  [] wait_for_completion+0x64/0xa0
> >  [] blk_execute_rq+0x8d/0xb0
> >  [] scsi_execute+0xb8/0x110
> >  [] scsi_execute_req+0x68/0x90
> >  [] sd_spinup_disk+0x6d/0x400
> >  [] sd_revalidate_disk+0x6b/0x160
> >  [] sd_rescan+0x1f/0x30
> >  [] scsi_rescan_device+0x42/0x50
> >  [] ata_scsi_dev_rescan+0x60/0x70
> >  [] run_workqueue+0x4d/0xf0
> >  [] worker_thread+0xcd/0xf0
> >  [] kthread+0x67/0x70
> >  [] kernel_thread_helper+0x7/0x4c
> 
> > md0_raid5 D F7F4D000 0   836  2 (L-TLB)
> >f78a3da0 0046 f7f4d000 f7f4d000 f78a3da0 c01454b6 c048b0e0 
> > f6ba0ad0
> >f78a3d70 c0116be1 00010ad0 d5658227 f78a3d90 f7853000 f70c4ae0 
> > f7f5617c
> >f78a3de0 3440 1be4a921 0009 0246 f7853000 f78a3dc8 
> > f785313c
> > Call Trace:
> >  [] md_super_wait+0x77/0xc0
> >  [] write_sb_page+0x4f/0x80
> >  [] write_page+0x102/0x110
> >  [] bitmap_update_sb+0x89/0x90
> >  [] md_update_sb+0x123/0x2a0
> >  [] md_check_recovery+0x302/0x340
> >  [] raid5d+0x12/0xf0
> >  [] md_thread+0x56/0x110
> >  [] kthread+0x67/0x70
> >  [] kernel_thread_helper+0x7/0x4c
> 
> > hibernate D F7945000 0  3874   2622 (NOTLB)
> >f6723c60 0086 f7ea23b8 f7945000 f6723c20 c0121d67 c198d800 
> > f7ea23b8
> >f6723c30 c02261b7 28ccc170 0009 3a03  c19615d0 
> > f6ba0bdc
> >006e 0006a677 28ccc170 0009 f6723c70 f6723d48 f6af7804 
> > f6723c7c
> > Call Trace:
> >  [] wait_for_completion+0x64/0xa0
> >  [] blk_execute_rq+0x8d/0xb0
> >  [] scsi_execute+0xb8/0x110
> >  [] scsi_execute_req+0x68/0x90
> >  [] sd_start_stop_device+0x6f/0x120
> >  [] sd_resume+0x6a/0xa0
> >  [] scsi_bus_resume+0x69/0x80
> >  [] resume_device+0x132/0x190
> >  [] dpm_resume+0xbb/0xc0
> >  [] device_resume+0x1e/0x40
> >  [] hibernate+0x106/0x1a0
> >  [] state_store+0xc3/0xf0
> >  [] subsys_attr_store+0x3b/0x40
> >  [] flush_write_buffer+0x2e/0x40
> >  [] sysfs_write_file+0x61/0x70
> >  [] vfs_write+0x88/0x110
> >  [] sys_write+0x41/0x70
> >  [] syscall_call+0x7/0xb
> >  ===
> > 
> 
> 

-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/