Re: [PATCH] cdrom_sysctl_info fix
On Fri, Jun 15 2007, dave young wrote: > Hi, > >Better to use the email address in the MAINTAINERS file than > >the one in the driver source file. > > Really? I searched the list, found axboe use the address > [EMAIL PROTECTED], same as what andrew said. does the MAINTAINERS > file be updated? Hey, no point in CC'ing me twice! [EMAIL PROTECTED] works just fine as well. -- Jens Axboe - 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
On Thursday 14 June 2007 23:19:24 Alexandre Oliva wrote: > On Jun 14, 2007, Florin Malita <[EMAIL PROTECTED]> wrote: > > On 06/14/2007 05:39 PM, Alexandre Oliva wrote: > >> Back when GPLv2 was written, the right to run was never considered an > >> issue. It was taken for granted, because copyright didn't control > >> that in the US (it does in Brazil), and nobody had thought of > >> technical measures to stop people from running modified copies of > >> software. At least nobody involved in GPLv2, AFAIK. > >> > >> The landscape has changed, and GPLv3 is meant to defend this > >> freedom that was taken for granted. > > > > Then you agree that GPLv2 does not protect your freedom (taken for > > granted) to run a modified copy on any particular device, or am I > > misreading? > > IANAL, but AFAICT it doesn't. Still, encoded in the spirit (that > refers to free software, bringing in the free software definition), is > the notion of protecting users' freedoms, among them the freeom #0, to > run the software for any purpose. And where in GPLv2 is "Freedom #0"? As a simple matter of fact, the *only* activities covered by the GPLv2 are "copying, distributing and modifying". It says so in the license itself. > That's why I believe it's in the spirit of the license to defend this > freedom. > > And that's why lawyers in Brazil believe that, even though the GPL > does not affirm the right to run the software, it fits the bill, > because, under the light of the preamble, the free software > definition, and the US copyright law, it should be interpreted as an > intent to grant permission to run the software. Then they have made a bad decision. While it can be argued that "the right to run the software" is guaranteed, the truth is that the license is very clear about what it covers. That's *DIRECTLY* in section 0 of the license. If someone has interpreted it to cover something besides what it explicitly states then it has been badly interpreted. In case you don't remember, GPLv2, section 2, paragraph 2: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." In other words, the license cannot be sanely interpreted to cover *execution* of the program. Yes, it says that the *license* doesn't restrict you from running the program, but that *DOESN'T* matter, because the opening sentence says: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope." QED: The intent of the license is clear and it is to guarantee those three stated rights. DRH > > Hence, Tivo is not really *modifying* the copies it distributes with > > the device - they're *installing* brand new copies instead. They > > also choose not to offer everybody the same privilege :-| > > Got it. That's bad. :-( -- 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: w1_therm_read_bin: suspicious usage of flush_signals()
On Thu, Jun 14, 2007 at 10:10:07PM -0700, Roland McGrath ([EMAIL PROTECTED])
wrote:
> > Well, it can be uninterruptible sleep, but why?
> > It is not allowed to return to userspace until transaction is completed,
> > so having uninterruptible sleep will result in exactly same lost of
> > signals.
>
> Delay, not loss.
Yep, you are right. I missed that state checks are performed after
signal was queued.
I've chcked other usage of signals in w1 and they are only related to
the control thread and unloading time when signals are used only to
indicate that another check must be performed.
This patch resolves the issue with reading from temperature sensor.
Thanks for pointing to that issue.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 732db47..1a6937d 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -191,11 +191,7 @@ static ssize_t w1_therm_read_bin(struct kobject *kobj,
char *buf, loff_t off, si
w1_write_8(dev, W1_CONVERT_TEMP);
- while (tm) {
- tm = msleep_interruptible(tm);
- if (signal_pending(current))
- flush_signals(current);
- }
+ msleep(tm);
if (!w1_reset_select_slave(sl)) {
Signed-
--
Evgeniy Polyakov
-
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
On Friday 15 June 2007 00:14:49 Alexandre Oliva wrote:
> On Jun 15, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Fri, 15 Jun 2007, Alexandre Oliva wrote:
> >> case 2'': tivo provides source, end user tries to improve it, realizes
> >> the hardware won't let him use the result of his efforts, and gives up
> >
> > So you're blaming Tivo for the fact that your end user was a lazy bum and
> > wanted to take advantage of somebody elses hard work without permission?
>
> -ENONSEQUITUR
>
> > Quite frankly, I know who the bad guy in that scenario is, and it ain't
> > Tivo. It's your lazy bum, that thought he would just take what Tivo did,
> > sign the contract, and then not follow it. And just because the box
> > _contained_ some piece of free software, that lazy bum suddenly has all
> > those rights?
>
> Yes, because the software license that TiVo signed up for says that
> TiVo must pass on certain rights and not impose any further
> restrictions.
They don't add any restrictions that don't already exist. As stated in section
0 of the GPLv2 the scope of the license is "copying, distributing and
modification".
> And all that because TiVo wanted to use kernel and userland that were
> readily available, and at no cost other than respecting others'
> freedoms, while at that?
>
> Who's the lazy bum, again?
Still the same one that Linus pointed out. No amount of faulty logic can
change that.
> > And you seem to argue that it's perfectly fine to ignore the people who
> > design hardware and the services around them,
>
> Just like they seem to think it's perfectly fine to ignore a number of
> people who design and maintain the software they decided to use in
> their hardware.
Huh? They have complied with the terms - and, IMHO, the spirit - of the
license under which that software was released.
> > Guys, you should be ashamed of calling yourself "free software" people.
> >
> > You sound more like the RIAA/MPAA ("we own all the rights! We _own_ your
> > sorry asses for even listening to our music") and a bunch of whiners that
> > think that just because you have touched a piece of hardware you
> > automatically can do anythign you want to it, and nobody elses rights
> > matter in the least!
> >
> > Guys, in fighting for "your rights", you should look a bit at *other*
> > peoples rights too. Including the rights of hw manufacturers, and the
> > service providers. Because this is all an eco-system, where in order to
> > actually succeed, you need to make _everybody_ succeed.
>
> Good. How about thinking of the users, the customers of your dear
> friends too? The ones who might be contributing much more to your
> project.
If they are *CONTRIBUTING* then they are not just simple users anymore.
> Then look how what you said in the paragraph before about RIAA/MPAA
> applies to what TiVO is doing to the software, and realize that you're
> accusing us of doing what the party you support does.
>
> I'm not trying to impose anything. I'm not pushing anything. I'm
> defending the GPLv3 from accusations that it's departing from the GPL
> spirit, and I'm trying to find out in what way Tivoization promotes
> the goals you perceive as good for Linux, that make GPLv2
> advantageous. So far, you haven't given any single reason about this.
> You talked about tit-for-tat, you said anti-Tivoization in GPLv3 was
> bad, but you don't connect the dots. Forgive if I get the impression
> that you're just fooling yourself, and misguiding a *lot* of people
> out there in the process.
And failing. You say that the intent and spirit of the GPLv2 is clear if you
read it. I read it and I feel its pretty clear that the only things that the
GPLv2 sought to protect are *EXACTLY* "copying, distribution and
modification".
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: 2.6.22-rc[23]: blinking capslock led, stuck keys?
On Wednesday 13 June 2007 10:09, Indan Zupancic wrote:
> On Wed, June 13, 2007 10:18, Pavel Machek wrote:
> >> Well, as I said before, I've the "stuck key"/repeated output too (as well
> >> as a warping PS/2 mouse), but no blinking led problem, so I believe the
> >> two things are totally unrelated.
> >
> > Well, after turning off CONFIG_BLINK, my problems went away, and with
> > a fast-blink done from userspace, I can make them way worse. They
> > _are_ related here.
>
> I missed you saying that before, so to me it looked like everyone just
> assumed that.
>
> So, just for fun, I tried running:
>
> while true; do setleds +num; setleds -num; done
>
> and it totally locked up my keyboard. Even SysRq didn't work.
Yeah, it does the same on my other laptop (newer HP as opposed
to an old Dell).
> On the
> bright side, the numlock LED was indeed blinking. Though running the
> same with a sleep 0.1 added doesn't produce any problems. So maybe
> my problem is indeed a bit related to this after all, somehow. Anyone
> any ideas how to debug this problem?
>
Does the patch below help?
--
Dmitry
Input: atkbd - throttle LED switching
On some boxes keyboard controllers are too slow to withstand
continuous flow of requests to turn keyboard LEDs on and off
and start losing some keypresses or even all of them.
Delay executing of LED switching request if we had another one
withing 50 ms thus easing load on the controller.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/keyboard/atkbd.c | 40 ++--
1 files changed, 26 insertions(+), 14 deletions(-)
Index: work/drivers/input/keyboard/atkbd.c
===
--- work.orig/drivers/input/keyboard/atkbd.c
+++ work/drivers/input/keyboard/atkbd.c
@@ -219,7 +219,8 @@ struct atkbd {
unsigned long time;
unsigned long err_count;
- struct work_struct event_work;
+ struct delayed_work event_work;
+ unsigned long event_jiffies;
struct mutex event_mutex;
unsigned long event_mask;
};
@@ -565,7 +566,7 @@ static int atkbd_set_leds(struct atkbd *
static void atkbd_event_work(struct work_struct *work)
{
- struct atkbd *atkbd = container_of(work, struct atkbd, event_work);
+ struct atkbd *atkbd = container_of(work, struct atkbd, event_work.work);
mutex_lock(>event_mutex);
@@ -579,12 +580,30 @@ static void atkbd_event_work(struct work
}
/*
+ * Schedule switch for execution. We need to throttle requests,
+ * otherwise keyboard may become unresponsive.
+ */
+static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
+{
+ unsigned long delay = msecs_to_jiffies(50);
+
+ if (time_after(jiffies, atkbd->event_jiffies + delay))
+ delay = 0;
+
+ atkbd->event_jiffies = jiffies;
+ set_bit(event_bit, >event_mask);
+ wmb();
+ schedule_delayed_work(>event_work, delay);
+}
+
+/*
* Event callback from the input module. Events that change the state of
* the hardware are processed here. If action can not be performed in
* interrupt context it is offloaded to atkbd_event_work.
*/
-static int atkbd_event(struct input_dev *dev, unsigned int type, unsigned int
code, int value)
+static int atkbd_event(struct input_dev *dev,
+ unsigned int type, unsigned int code, int value)
{
struct atkbd *atkbd = input_get_drvdata(dev);
@@ -594,19 +613,12 @@ static int atkbd_event(struct input_dev
switch (type) {
case EV_LED:
- set_bit(ATKBD_LED_EVENT_BIT, >event_mask);
- wmb();
- schedule_work(>event_work);
+ atkbd_schedule_event_work(atkbd, ATKBD_LED_EVENT_BIT);
return 0;
case EV_REP:
-
- if (!atkbd->softrepeat) {
- set_bit(ATKBD_REP_EVENT_BIT,
>event_mask);
- wmb();
- schedule_work(>event_work);
- }
-
+ if (!atkbd->softrepeat)
+ atkbd_schedule_event_work(atkbd,
ATKBD_REP_EVENT_BIT);
return 0;
}
@@ -940,7 +952,7 @@ static int atkbd_connect(struct serio *s
atkbd->dev = dev;
ps2_init(>ps2dev, serio);
- INIT_WORK(>event_work, atkbd_event_work);
+ INIT_DELAYED_WORK(>event_work, atkbd_event_work);
mutex_init(>event_mutex);
switch (serio->id.type) {
-
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
On Jun 15, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > #define Dell CFG_FAVOURITE_VENDOR > A Dell desktop machine is a piece of hardware. The manufacturer has the > source code (hypothetically) to the BIOS. The BIOS is required for the > machine to boot and run Linux. > Riddle me this (especially Alexandre, I'm just latching on to Ingo's > post because it has the right hook to grab) - are Dell required to give > out the source to the bios to enable people to have the same rights Dell > engineers do to modify the behaviour of the system? What is the license for the bios? Does it say anything about 'no further restrictions on the freedoms to modify and share the software'? Does it include any mechanisms to stop people from booting modified versions of the Linux that ships with the machine? -- 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
On Thursday 14 June 2007 23:54:31 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 22:21:59 Alexandre Oliva wrote: > >> Consider egg yolk and egg shells. > >> > >> I produce egg yolk. I give it to you under terms that say "if you > >> pass this on, you must do so in such a way that doesn't stop anyone > >> from eating it" > >> > >> You produce egg shells. You carefully construct your shell around the > >> egg yolk and some white you got from a liberal third party. > >> > >> Then you sell the egg shells, with white and yolk inside, under > >> contracts that specify "the shell must be kept intact, it can't be > >> broken or otherwise perforated". > >> > >> Are you or are you not disrespecting the terms that apply to the yolk? > > > > Bad analogy. > > It's just a very simple case in which an enclosure is being used to > disrespect the terms of something enclosed in it. > > It's meant to show that the argument that "it's a software license, it > can't affect the hardware" is nonsense. > > It's not meant to show whether TiVO is right or wrong. This would > depend on agreement that the GPL requirements are similar to the > requirements of the egg yolk manufacturer. > > >> > by your argument, the user has some "right to modify the > >> > software", on that piece of hardware it bought which had free > >> > software on it, correct? > >> > >> Yes. This means the hardware distributor who put the software in > >> there must not place roadblocks that impede the user to get where she > >> wants with the software, not that the vendor must offer the user a > >> sport car to take her there. > > > > Okay. That means that if I ship Linux on a ROM chip I have to > > somehow make it so that the person purchasing the chip can modify > > the copy of Linux installed on the chip *if* I want to follow both > > the spirit and the letter of the GPLv2. > > I thought we'd already cleared up the issue about ROMs, and why > they're different. Do I have to quote it again? Must I allude to > "passing on the rights" every time I mention "imposing further > restrictions"? :-( I wasn't referring to anything that had already been "cleared up". I was applying the logic of the statement of yours I quoted. The "cleared up" things all were in reference to the GPLv3 - my example was in reference to the "spirit" of the GPLv2 that you were stating. By simple extension of the logic you provided I came to the conclusion stated above. The fact that you've claimed I'm wrong shows how flawed your logic is. 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
On Thursday 14 June 2007 23:04:37 Michael Poole wrote: > Daniel Hazelton writes: > > On Thursday 14 June 2007 22:13:13 Michael Poole wrote: > >> The fundamental reason for this is that neither the executable code > >> nor the digital signature serves the desired function alone. The user > >> received a copy of the executable for a particular purpose: to run the > >> program on a particular platform. With DRM signatures, only the > >> combination of program and signature will perform that function, and > >> separating the two based on strictly read legal definitions is risky. > > > > I agree. > > > >> The question of whether DRM signatures are covered by the license must > >> be resolved before one can determine whether Tivo gave "*EXACTLY*" the > >> same rights to object-code recipients as Tivo received. GPLv2 is > >> worded such that the answer to this does not depend on whether one is > >> in file A and the other in file B, or whether one is on hard drive C > >> and the other is in flash device D, as long as they are delivered as > >> part of one unit; it *might* matter if, say, one is received on > >> physical media and the other is downloaded on demand. > > > > I have read the GPLv2 at least three times since it was pointed out that > > I had forgotten part of it. At no point can I find a point where Tivo > > broke the GPLv2 requirement that they give the recipients of the object > > code the same rights they received when they acquired a copy of the > > object or source code. > > I am trying to reconcile your responses to those two paragraphs. > > If the DRM signature and program executable are coupled such that they > are not useful when separated, the implication to me is that they form > one work that is based on the original Program. This is beyond the > GPL's permission for "mere aggregation". > > If they are one work, and the original Program was licensed under the > GPLv2, the combined work must also be licensed under the terms of the > GPLv2. > > The input files required to generate a DRM-valid digital signature are > part the preferred form for modifying that work. > > If those bits are not distributed along with the rest of the GPL'ed > work, the distributor is either not giving the same rights to the end > user, not distributing the source code for the work, or both. Which > is it? Following your logic it would be a "failure to distribute the source code for a work". However, since the signing is an automated process it cannot generate a "new" work - at least, not under the laws of the US - so the signature itself cannot have a copyright at all. DRH PS: This is the exact same reason that the GPL cannot apply to a Bison generated parser in the US. The "input" file that causes Bison to generate the output can have a copyright, but not the output - no matter what RMS or anyone else wants, and no matter what the GPL says about it. > > Michael Poole -- 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
On Thu, Jun 14, 2007 at 08:20:19PM -0300, Alexandre Oliva wrote: > > So, you see, your statement above, about wanting to be able to use > other people's improvements, cannot be taken without qualification. No. Linus and other Linux kernels might *want* to take other people's improvements, but thanks to Richard Stallman's choices for GPLv3, they can *not* legally take other people's improvements without violating the GPLv3 license. That's not their fault, it's the fault of people who wrote the GPLv3 license, promulgated the GPLv3 license, and who is attempting to convince everyone that the GPLv3 license is the only valid license for Right Thinking FSF automatons to use. There are plenty of things that I might *want* to do, that I am legally prohibited from doing. that doesn't change the fact that I might want to do it. The fact that GPLv3 is incompatible with GPLv2 is a tragedy, in the Greek sense. - 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/
[RFT] i8042 - trust PNP more on i386
Hi,
Historically we did not trust PNP data on i386 because of all the
issues with data put into BIOS by BIOS writers. However there are
bunch of boxes that get really unhappy if we try to poke AUX port
when they don't have mouse attached and BIOS disabled AUX port when
booting. Our keyboard/mouse probels leave keyboard dead.
So the idea is teh following - if we find properly described keyboard
device in PNP tables and all the resources are specified correctly but
mouse device is not there we assume that BIOS can be trusted and don't
create AUX port.
I would appreciate if yo ugive this patch a spin.
--
Dmitry
Input: i8042 - give more trust PNP data on i386
On some boxes that don't have PS/2 mice connected at startup BIOS
completely disables AUX port and attempts to access it result in
hosed keyboard. Historically we do not trust ACPI/PNP data on
i386 and try to poke AUX port even if we did not find an active
PNP node for it. However in cases when BIOS writers got KBD port
properly described we can assume that they did the right thing
for AUX port as well.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/serio/i8042-x86ia64io.h | 36 +++---
1 files changed, 29 insertions(+), 7 deletions(-)
Index: work/drivers/input/serio/i8042-x86ia64io.h
===
--- work.orig/drivers/input/serio/i8042-x86ia64io.h
+++ work/drivers/input/serio/i8042-x86ia64io.h
@@ -355,6 +355,7 @@ static void i8042_pnp_exit(void)
static int __init i8042_pnp_init(void)
{
char kbd_irq_str[4] = { 0 }, aux_irq_str[4] = { 0 };
+ int pnp_data_busted = 0;
int err;
if (i8042_nopnp) {
@@ -402,27 +403,48 @@ static int __init i8042_pnp_init(void)
#endif
if (((i8042_pnp_data_reg & ~0xf) == (i8042_data_reg & ~0xf) &&
- i8042_pnp_data_reg != i8042_data_reg) || !i8042_pnp_data_reg) {
- printk(KERN_WARNING "PNP: PS/2 controller has invalid data port
%#x; using default %#x\n",
+ i8042_pnp_data_reg != i8042_data_reg) ||
+ !i8042_pnp_data_reg) {
+ printk(KERN_WARNING
+ "PNP: PS/2 controller has invalid data port %#x; "
+ "using default %#x\n",
i8042_pnp_data_reg, i8042_data_reg);
i8042_pnp_data_reg = i8042_data_reg;
+ pnp_data_busted = 1;
}
if (((i8042_pnp_command_reg & ~0xf) == (i8042_command_reg & ~0xf) &&
- i8042_pnp_command_reg != i8042_command_reg) ||
!i8042_pnp_command_reg) {
- printk(KERN_WARNING "PNP: PS/2 controller has invalid command
port %#x; using default %#x\n",
+ i8042_pnp_command_reg != i8042_command_reg) ||
+ !i8042_pnp_command_reg) {
+ printk(KERN_WARNING
+ "PNP: PS/2 controller has invalid command port %#x; "
+ "using default %#x\n",
i8042_pnp_command_reg, i8042_command_reg);
i8042_pnp_command_reg = i8042_command_reg;
+ pnp_data_busted = 1;
}
if (!i8042_nokbd && !i8042_pnp_kbd_irq) {
- printk(KERN_WARNING "PNP: PS/2 controller doesn't have KBD irq;
using default %d\n", i8042_kbd_irq);
+ printk(KERN_WARNING
+ "PNP: PS/2 controller doesn't have KBD irq; "
+ "using default %d\n", i8042_kbd_irq);
i8042_pnp_kbd_irq = i8042_kbd_irq;
+ pnp_data_busted = 1;
}
if (!i8042_noaux && !i8042_pnp_aux_irq) {
- printk(KERN_WARNING "PNP: PS/2 controller doesn't have AUX irq;
using default %d\n", i8042_aux_irq);
- i8042_pnp_aux_irq = i8042_aux_irq;
+ if (!pnp_data_busted && i8042_pnp_kbd_irq) {
+ printk(KERN_WARNING
+ "PNP: PS/2 appears to have AUX port disabled, "
+ "if this is incorrect please boot with "
+ "i8042.nopnp\n");
+ i8042_noaux = 1;
+ } else {
+ printk(KERN_WARNING
+ "PNP: PS/2 controller doesn't have AUX irq; "
+ "using default %d\n", i8042_aux_irq);
+ i8042_pnp_aux_irq = i8042_aux_irq;
+ }
}
i8042_data_reg = i8042_pnp_data_reg;
-
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
On Thursday 14 June 2007 23:39:50 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > You're making an artificial distinction based on whether the > > *SOFTWARE* has a certain license or not. > > What matters to me is that, when the GPL says you can't impose further > restrictions, then you can't, no matter how convoluted your argument > is Convoluted? Not in the least. Every example I have given has been an example of the application of your logic. If my examples are convoluted, then, QED, so is your logic. > >> That's exactly what makes for the difference between the spirit and > >> the precise legal terms, and why GPLv3 is fixing these divergences. > > > > And the reason behind this is all "ethics and morals". > > There was never any attempt to hide that this was what the Free > Software movement was about, and that the GPL was about defending > these freedoms. > > Sure, it has other advantages. But the goal has always been the same, > and it's not going to change. I'm not trying to change that. My point in making that statement is to prove that the FSF is doing exactly what the Spanish Inquisition did, what every "Communist Revolution" has done and what Hitler did. Saying "My ethics and morals are better than everyone else, so I'm going to force everyone else to have my morals and ethics". That the FSF isn't doing this through force of arms or threat of violence just shows how sophisticated people have really become in the sixty years that have passed since Hitler - they now use threat of legal action. > > If the intent of a law (or license) is to do A but it doesn't say > > that, then how is the intent to be known? Your answer: Ask the > > author. > > No, you interpret based on what the author wrote then. Really? Well I must say I'm surprised at the sudden change of heart. I have several mails here in which you have either said "You ask the author" or that line has been quoted. > You read the preamble, and any other rationales associated with the > license or law. I don't know how it's elsewhere, but in Brazil every > law has a rationale, and that's often used to guide its interpretation > in courts, even though the rationale is not part of the law. Show me where in the preamble that this issue of "it must run on any given piece of hardware" or even less generally, "it must run on the hardware it came on" is even *hinted* at. You wont find it. Nor will you find any mention of anything of the sort in the publicly available writings of RMS. But let me go re-read the GPLv2 preamble again and see if it even hints at this issue... oh, wait, I read it earlier and didn't see anything that hinted at this. So I can safely conclude that no lawyer or judge would find it when interpreting the license. QED: The Tivo clause of GPLv3 causes it to break spirit with the GPLv2. (And, by the way, if the FSF decided to release a GPLv4 that had an active section that said "You must turn over all copyright rights to a work released under this license to the FSF" it wouldn't "break spirit" with the GPL (v2 or v3). Why? Because *both* contain the following paragraph: "We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." By your logic it is the *intent* of the FSF to hold copyright on all software released under the GPL *and* only give the rights detailed in the license to other people - including the person who has placed the work under the GPL. Can you see the problem with your logic ? > > If the author realizes what he wrote was not enough, or it got > misinterpreted, author his text, and then whoever feels like it and is > entitled to adopts the revised version. > > > In the GPLv2=>v3 case, all that needed revision was the legalese. The > preamble has barely changed. This is a strong indication that the > spirit remains the same, is it not? If "tivoization" was against the spirit, then all that would have been needed was one extra clause clearly explaining that. Instead there are more than 6 extra sections in the GPLv3. If "DRM" was against the license then an extra section clearly explaining that could have been added. (in the DRM case I actually understand the reasoning and agree with it.) > > Unless the intent is clearly spelled out at the time the law (or > > license) is written, or is available in other writings by the author > > of the law/license from the same time period as the law/license then > > it is impossible. > > Is there anything not clear about freedom #0, in the free software > definition, alluded to by the preamble that talks about free software > in very similar terms? 0. ... Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered
Re: coding style
Willy Tarreau wrote: On Thu, Jun 14, 2007 at 10:48:36PM +0400, Cyrill Gorcunov wrote: Hi to all, a simple question the answer to witch I didn't find in CodingStyle. Look for a code snip: err = foo(arg_a, arg_b, arg_c, arg_d); the second line contains 'd' arg aligned with tabs only but it could be rewritten with more elegant style (by adding a few spaces) like this err = foo(arg_a, arg_b, arg_c, arg_d); so which one is preferred for the kernel? There is no "preferred", just one good and one bad :-) Ideally, you should use tabs only for indentation, and spaces only for alignment. Keep in mind that there are people using different tab sizes and that your tabs should not make it harder for them to read your code. In your example above, you should use tabs from left up to "err", then spaces to go from "err" to "arg_d". However, we know that some editors such as emacs are stupid in this regard, because they fill with tabs then complete with spaces, so it's not always easy. the current "checkpatch.pl" script rejects this notion and requires that you use tabs whenever you can (you can still align code within the length of one tab). Since in the example part (2) above there are 9 spaces needed to go from err to arg_d, it complains if you had used 9 spaces here. It only allows you to use tabs + n spaces (where n < 8) I personally prefer spaces, but the checkpatch.pl script does not agree, much to my dismay :( Auke - 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: w1_therm_read_bin: suspicious usage of flush_signals()
> Well, it can be uninterruptible sleep, but why? > It is not allowed to return to userspace until transaction is completed, > so having uninterruptible sleep will result in exactly same lost of > signals. Delay, not loss. - 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
On Fri, Jun 15, 2007 at 01:14:49AM -0300, Alexandre Oliva wrote: > I'm not trying to impose anything. I'm not pushing anything. I'm > defending the GPLv3 from accusations that it's departing from the GPL > spirit, and I'm trying to find out in what way Tivoization promotes > the goals you perceive as good for Linux, that make GPLv2 > advantageous. So far, you haven't given any single reason about this. > You talked about tit-for-tat, you said anti-Tivoization in GPLv3 was > bad, but you don't connect the dots. Forgive if I get the impression > that you're just fooling yourself, and misguiding a *lot* of people > out there in the process. Give. Me. A. Break. Section 6 is inherently broken. It tries to gerrymander the "bad" cases and ends up with a huge mess. Definition of user device is arbitrary and reeks with discrimination against the field of use. Trying to be more explicit about installation instructions walks straight into a minefield: * is it enough to give some installation methods? If so, should they be as cheap as the rest? As efficient as the rest in some sense? Representative in some sense? The same as what manufacturer ever uses? * if all installation methods should be given, where does one stop? Should one describe unsupported ones? All of them? Is that a violation of license to omit some? How does one prove that omission hadn't been malicious violation in face of complaint? Trying to be explicit enough to get a rope on the TiVo neck ends up with not just clumsy rules; it opens a can of worms worse than what we have in matching part of v2. It looks like trying to be tight enough to be sure to catch the cases FSF doesn't like and trying to avoid getting the stuff that really shouldn't be caught. And looks like these requirements conflict. So in the end you get an ugliness that satisfies neither those who think that TiVo case is not a problem nor those who agree that it is a problem and consider v2 sufficient in that area. And BTW, you've been told just that about an hour before you've sent that mail. I don't mind repeating that on l-k, but please don't pretend to be unaware of the problems in that area. I've no idea which problems Linus has with that turd, but there's certainly enough in there. - 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] Support for controlling leds on xbox 360 pad.
On Friday 15 June 2007 00:15, Dmitry Torokhov wrote:
> How about the patch below instead?
>
And one more time without warnings...
--
Dmitry
Subject: Input: xpad - add support for leds on xbox 360 pad
From: Jan Kratochvil <[EMAIL PROTECTED]>
Input: xpad - add support for leds on xbox 360 pad
Export LEDs on Xbox360 pad via led subsystem as a single device in
/sys/class/leds/xpad[0-9]+.
Xbox360 pad has four leds, which form a circle. Unfortunately the leds
can't be controlled independently and can only display a predefined
set of patterns (for example one is turned on wile others are off or
a rotating pattern - 1-2-3-4). To activate a pattern one needs to send
a specific command to the device (see http://www.free60.org/wiki/Gamepad).
Led subsystem allows us to set brightness, but there is nothing like
brightness on this device. So brightness is actually interpreted as
the command (only values between 0 and 14 are accepted).
Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]>
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/joystick/Kconfig |7 +
drivers/input/joystick/xpad.c | 190 +++--
2 files changed, 155 insertions(+), 42 deletions(-)
Index: work/drivers/input/joystick/Kconfig
===
--- work.orig/drivers/input/joystick/Kconfig
+++ work/drivers/input/joystick/Kconfig
@@ -275,4 +275,11 @@ config JOYSTICK_XPAD_FF
---help---
Say Y here if you want to take advantage of xbox 360 rumble features.
+config JOYSTICK_XPAD_LEDS
+ bool "LED Support for Xbox360 controller 'BigX' LED"
+ depends on LEDS_CLASS && JOYSTICK_XPAD
+ ---help---
+ This option enables support for the LED which surrounds the Big X on
+ XBox 360 controller.
+
endif
Index: work/drivers/input/joystick/xpad.c
===
--- work.orig/drivers/input/joystick/xpad.c
+++ work/drivers/input/joystick/xpad.c
@@ -191,13 +191,18 @@ struct usb_xpad {
unsigned char *idata; /* input data */
dma_addr_t idata_dma;
-#ifdef CONFIG_JOYSTICK_XPAD_FF
+#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
struct urb *irq_out;/* urb for interrupt out report */
unsigned char *odata; /* output data */
dma_addr_t odata_dma;
+ struct mutex odata_mutex;
+#endif
+
+#if defined(CONFIG_JOYSTICK_XPAD_LEDS)
+ struct xpad_led *led;
#endif
- char phys[65]; /* physical device path */
+ char phys[64]; /* physical device path */
int dpad_mapping; /* map d-pad to buttons or to axes */
int xtype; /* type of xbox device */
@@ -349,7 +354,7 @@ exit:
__FUNCTION__, retval);
}
-#ifdef CONFIG_JOYSTICK_XPAD_FF
+#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
static void xpad_irq_out(struct urb *urb)
{
int retval;
@@ -376,29 +381,7 @@ exit:
__FUNCTION__, retval);
}
-static int xpad_play_effect(struct input_dev *dev, void *data,
- struct ff_effect *effect)
-{
- struct usb_xpad *xpad = input_get_drvdata(dev);
-
- if (effect->type == FF_RUMBLE) {
- __u16 strong = effect->u.rumble.strong_magnitude;
- __u16 weak = effect->u.rumble.weak_magnitude;
- xpad->odata[0] = 0x00;
- xpad->odata[1] = 0x08;
- xpad->odata[2] = 0x00;
- xpad->odata[3] = strong / 256;
- xpad->odata[4] = weak / 256;
- xpad->odata[5] = 0x00;
- xpad->odata[6] = 0x00;
- xpad->odata[7] = 0x00;
- usb_submit_urb(xpad->irq_out, GFP_KERNEL);
- }
-
- return 0;
-}
-
-static int xpad_init_ff(struct usb_interface *intf, struct usb_xpad *xpad)
+static int xpad_init_output(struct usb_interface *intf, struct usb_xpad *xpad)
{
struct usb_endpoint_descriptor *ep_irq_out;
int error = -ENOMEM;
@@ -411,6 +394,8 @@ static int xpad_init_ff(struct usb_inter
if (!xpad->odata)
goto fail1;
+ mutex_init(>odata_mutex);
+
xpad->irq_out = usb_alloc_urb(0, GFP_KERNEL);
if (!xpad->irq_out)
goto fail2;
@@ -423,25 +408,19 @@ static int xpad_init_ff(struct usb_inter
xpad->irq_out->transfer_dma = xpad->odata_dma;
xpad->irq_out->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
- input_set_capability(xpad->dev, EV_FF, FF_RUMBLE);
-
- error = input_ff_create_memless(xpad->dev, NULL, xpad_play_effect);
- if (error)
- goto fail2;
-
return 0;
fail2:usb_buffer_free(xpad->udev, XPAD_PKT_LEN, xpad->odata,
xpad->odata_dma);
fail1:return error;
}
-static void xpad_stop_ff(struct usb_xpad *xpad)
Re: coding style
On Thu, Jun 14, 2007 at 10:48:36PM +0400, Cyrill Gorcunov wrote: > > Hi to all, > > a simple question the answer to witch I didn't find in CodingStyle. > Look for a code snip: > > err = foo(arg_a, arg_b, arg_c, > arg_d); > > the second line contains 'd' arg aligned with tabs only > but it could be rewritten with more elegant style (by adding > a few spaces) like this > > err = foo(arg_a, arg_b, arg_c, > arg_d); > > so which one is preferred for the kernel? There is no "preferred", just one good and one bad :-) Ideally, you should use tabs only for indentation, and spaces only for alignment. Keep in mind that there are people using different tab sizes and that your tabs should not make it harder for them to read your code. In your example above, you should use tabs from left up to "err", then spaces to go from "err" to "arg_d". However, we know that some editors such as emacs are stupid in this regard, because they fill with tabs then complete with spaces, so it's not always easy. 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 2/2] readahead: sanify file_ra_state names
On Thu, 2007-06-14 at 14:21 +0800, Fengguang Wu wrote: > plain text document attachment (readahead-rename.patch) > Rename some file_ra_state variables and remove some accessors. > > It results in much simpler code. > Kudos to Rusty! > > Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]> Needless to say, I'm now very satisfied with the new readahead code. That's not to say there won't be corner cases where the old code did better, but given the replacement's simplicity and Fengguang's positive benchmark results I really like it. Thanks for Fengguang for coding and pushing this! Rusty. - 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
On Thursday 14 June 2007 23:22:48 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > Faulty logic. The hardware doesn't *restrict* you from *MODIFYING* > > any fscking thing. > > Ok, lemme try again: > > case 2'': tivo provides source, end user tries to improve it, realizes > the hardware won't let him use the result of his efforts, and gives up And there is nothing in the license that says that this has to be done. Claiming that it is a requirement because of the "spirit" of the license or that such was the "intent" of the license does not make it any less legal than it is. And, as I've taken the time to explain to you, lacking any clear statement, written at the exact same time as the license, a statement of intent or spirit cannot have any real legal weight when the text of a license is finally decided upon. The reason, in case you missed the mail in which I gave it, is that the author *cannot*, no matter the belief anyone may have in their honesty or the oaths they may swear, be trusted to have *not* changed his/her mind as to the intent and/or spirit of the license at any time after the license goes into use. DRH > > On Thursday 14 June 2007 18:45:07 Alexandre Oliva wrote: > >> Where's the payback, or the payforward? > >> > >> And then, tit-for-tat is about equivalent retaliation, an eye for an > >> eye. Where's the retaliation here? > >> > >> If GPLv2 were tit-for-tat, if someone invents artifices to prevent the > >> user from making the changes the user wants on the software, wouldn't > >> it be "equivalent retaliation" to prevent the perpetrator from making > >> the changes it wants on the software? -- 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: w1_therm_read_bin: suspicious usage of flush_signals()
On Thu, Jun 14, 2007 at 09:24:39PM +0400, Oleg Nesterov ([EMAIL PROTECTED])
wrote:
> drivers/w1/slaves/w1_therm.c:w1_therm_read_bin()
>
> while (tm) {
> tm = msleep_interruptible(tm);
> if (signal_pending(current))
> flush_signals(current);
> }
>
> current is user-space task, yes?
>
> this looks just wrong, could you please explain?
Hi Oleg.
Well, it can be uninterruptible sleep, but why?
It is not allowed to return to userspace until transaction is completed,
so having uninterruptible sleep will result in exactly same lost of
signals.
> Oleg.
--
Evgeniy Polyakov
-
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
On Thu, 14 Jun 2007, Michael Poole wrote: > > If the signature is one that serves to indicate origin, to detect > tampering, or the other things you mentioned, the program's binary is > useful when separated from the signature. My objection arises when a > functionally equivalent binary -- including advertised functions such > as "runs on platform XYZ" -- cannot be produced from the distributed > source code. Ahh. Ok, that's a totally different issue, and is one where I heartily agree with you. I would actually *love* for the GPL (any version) to have a "guarantee of authenticity", where if you distribute a binary, there has to be some documented way to get *exactly* that binary out of the source code that got distributed. Of course, SHA1's can be used to verify that, although, quite frankly, I'd expect that a simple "cmp" would be the more straightforward approach. So the "verification" can be used both to lock down a particular binary _and_ to authenticate that the binary really came from the source code it was claimed to come from. Of course, in practice, it's actually really nasty to do that verification. Many compilers actually do things like insert date-stamps in the object files etc. So it's probably not all that practical. 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
[EMAIL PROTECTED] writes: > On Fri, 15 Jun 2007, Alexandre Oliva wrote: > >> Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 >> >> On Jun 14, 2007, Bill Nottingham <[EMAIL PROTECTED]> wrote: >> >>> OK. Let's take this to the simple and logical conclusion. A signed >>> filesystem image containing both GPL and non-GPL code. From your >>> point A, this is a derived work. >> >> I claim the signature is derived from the GPLed bits, yes. Whether >> that's a derived work, in the legal sense, I'm not qualified to say. > > it's also derived from the non-GPLed bits as well. > > so if it were a derived work in a legal sense (nessasary for your > argument to have any legal meaning) then it's now illegal to make and > distribute a checksum of a CD that contains software with incompatible > licenses. It is not necessary for the end item to be a derived work in order for the GPL to apply. A literal copy is not a derived work; a translation is not a derived work; an executable version of a program is not a derived work of its source code; and so forth. What is necessary is that the "work based on the [GPLed] Program" be more than a mere aggregation of the GPLed component(s) with non-GPLed components. The fact that part of the work-as-a-whole is a descriptor of the GPLed part does not mean all descriptions the GPLed part are governed by the GPL. The critical factor is that the GPLed part will not function properly without the DRM signature. Michael Poole - 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] Support for controlling leds on xbox 360 pad.
Hi Jan,
On Sunday 03 June 2007 14:02, Jan Kratochvil wrote:
> +Â Â Â list_for_each_entry(pos_led, _led_list, node) {
> +Â Â Â if (pos_led->id == i)
> +Â Â Â i++;
> +Â Â Â else
> +Â Â Â break;
> +Â Â Â }
I don't like this list business, it requires locking and frankly
is not needed.
> +
> +Â Â Â if (i > 99)
> +Â Â Â goto fail1;
... and this limitation as well.
How about the patch below instead?
--
Dmitry
Subject: Input: xpad - add support for leds on xbox 360 pad
From: Jan Kratochvil <[EMAIL PROTECTED]>
Input: xpad - add support for leds on xbox 360 pad
Export LEDs on Xbox360 pad via led subsystem as a single device in
/sys/class/leds/xpad[0-9]+.
Xbox360 pad has four leds, which form a circle. Unfortunately the leds
can't be controlled independently and can only display a predefined
set of patterns (for example one is turned on wile others are off or
a rotating pattern - 1-2-3-4). To activate a pattern one needs to send
a specific command to the device (see http://www.free60.org/wiki/Gamepad).
Led subsystem allows us to set brightness, but there is nothing like
brightness on this device. So brightness is actually interpreted as
the command (only values between 0 and 14 are accepted).
Signed-off-by: Jan Kratochvil <[EMAIL PROTECTED]>
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/joystick/Kconfig |7 +
drivers/input/joystick/xpad.c | 190 +++--
2 files changed, 155 insertions(+), 42 deletions(-)
Index: work/drivers/input/joystick/Kconfig
===
--- work.orig/drivers/input/joystick/Kconfig
+++ work/drivers/input/joystick/Kconfig
@@ -275,4 +275,11 @@ config JOYSTICK_XPAD_FF
---help---
Say Y here if you want to take advantage of xbox 360 rumble features.
+config JOYSTICK_XPAD_LEDS
+ bool "LED Support for Xbox360 controller 'BigX' LED"
+ depends on LEDS_CLASS && JOYSTICK_XPAD
+ ---help---
+ This option enables support for the LED which surrounds the Big X on
+ XBox 360 controller.
+
endif
Index: work/drivers/input/joystick/xpad.c
===
--- work.orig/drivers/input/joystick/xpad.c
+++ work/drivers/input/joystick/xpad.c
@@ -191,13 +191,18 @@ struct usb_xpad {
unsigned char *idata; /* input data */
dma_addr_t idata_dma;
-#ifdef CONFIG_JOYSTICK_XPAD_FF
+#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
struct urb *irq_out;/* urb for interrupt out report */
unsigned char *odata; /* output data */
dma_addr_t odata_dma;
+ struct mutex odata_mutex;
+#endif
+
+#if defined(CONFIG_JOYSTICK_XPAD_LEDS)
+ struct xpad_led *led;
#endif
- char phys[65]; /* physical device path */
+ char phys[64]; /* physical device path */
int dpad_mapping; /* map d-pad to buttons or to axes */
int xtype; /* type of xbox device */
@@ -349,7 +354,7 @@ exit:
__FUNCTION__, retval);
}
-#ifdef CONFIG_JOYSTICK_XPAD_FF
+#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
static void xpad_irq_out(struct urb *urb)
{
int retval;
@@ -376,29 +381,7 @@ exit:
__FUNCTION__, retval);
}
-static int xpad_play_effect(struct input_dev *dev, void *data,
- struct ff_effect *effect)
-{
- struct usb_xpad *xpad = input_get_drvdata(dev);
-
- if (effect->type == FF_RUMBLE) {
- __u16 strong = effect->u.rumble.strong_magnitude;
- __u16 weak = effect->u.rumble.weak_magnitude;
- xpad->odata[0] = 0x00;
- xpad->odata[1] = 0x08;
- xpad->odata[2] = 0x00;
- xpad->odata[3] = strong / 256;
- xpad->odata[4] = weak / 256;
- xpad->odata[5] = 0x00;
- xpad->odata[6] = 0x00;
- xpad->odata[7] = 0x00;
- usb_submit_urb(xpad->irq_out, GFP_KERNEL);
- }
-
- return 0;
-}
-
-static int xpad_init_ff(struct usb_interface *intf, struct usb_xpad *xpad)
+static int xpad_init_output(struct usb_interface *intf, struct usb_xpad *xpad)
{
struct usb_endpoint_descriptor *ep_irq_out;
int error = -ENOMEM;
@@ -411,6 +394,8 @@ static int xpad_init_ff(struct usb_inter
if (!xpad->odata)
goto fail1;
+ mutex_init(>odata_mutex);
+
xpad->irq_out = usb_alloc_urb(0, GFP_KERNEL);
if (!xpad->irq_out)
goto fail2;
@@ -423,25 +408,19 @@ static int xpad_init_ff(struct usb_inter
xpad->irq_out->transfer_dma = xpad->odata_dma;
xpad->irq_out->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
- input_set_capability(xpad->dev,
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 15, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jun 2007, Alexandre Oliva wrote:
>>
>> case 2'': tivo provides source, end user tries to improve it, realizes
>> the hardware won't let him use the result of his efforts, and gives up
> So you're blaming Tivo for the fact that your end user was a lazy bum and
> wanted to take advantage of somebody elses hard work without permission?
-ENONSEQUITUR
> Quite frankly, I know who the bad guy in that scenario is, and it ain't
> Tivo. It's your lazy bum, that thought he would just take what Tivo did,
> sign the contract, and then not follow it. And just because the box
> _contained_ some piece of free software, that lazy bum suddenly has all
> those rights?
Yes, because the software license that TiVo signed up for says that
TiVo must pass on certain rights and not impose any further
restrictions.
And all that because TiVo wanted to use kernel and userland that were
readily available, and at no cost other than respecting others'
freedoms, while at that?
Who's the lazy bum, again?
> And you seem to argue that it's perfectly fine to ignore the people who
> design hardware and the services around them,
Just like they seem to think it's perfectly fine to ignore a number of
people who design and maintain the software they decided to use in
their hardware.
> Guys, you should be ashamed of calling yourself "free software" people.
> You sound more like the RIAA/MPAA ("we own all the rights! We _own_ your
> sorry asses for even listening to our music") and a bunch of whiners that
> think that just because you have touched a piece of hardware you
> automatically can do anythign you want to it, and nobody elses rights
> matter in the least!
> Guys, in fighting for "your rights", you should look a bit at *other*
> peoples rights too. Including the rights of hw manufacturers, and the
> service providers. Because this is all an eco-system, where in order to
> actually succeed, you need to make _everybody_ succeed.
Good. How about thinking of the users, the customers of your dear
friends too? The ones who might be contributing much more to your
project.
Then look how what you said in the paragraph before about RIAA/MPAA
applies to what TiVO is doing to the software, and realize that you're
accusing us of doing what the party you support does.
I'm not trying to impose anything. I'm not pushing anything. I'm
defending the GPLv3 from accusations that it's departing from the GPL
spirit, and I'm trying to find out in what way Tivoization promotes
the goals you perceive as good for Linux, that make GPLv2
advantageous. So far, you haven't given any single reason about this.
You talked about tit-for-tat, you said anti-Tivoization in GPLv3 was
bad, but you don't connect the dots. Forgive if I get the impression
that you're just fooling yourself, and misguiding a *lot* of people
out there in the process.
--
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
On Fri, Jun 15, 2007 at 01:50:04AM +0200, Ingo Molnar wrote: > the GPL applies to software. It is a software license. > > the Tivo box is a piece of hardware. > > a disk is put into it with software copied to it already: a bootloader, > a Linux kernel plus a handful of applications. The free software bits > are available for download. #define Dell CFG_FAVOURITE_VENDOR A Dell desktop machine is a piece of hardware. The manufacturer has the source code (hypothetically) to the BIOS. The BIOS is required for the machine to boot and run Linux. Riddle me this (especially Alexandre, I'm just latching on to Ingo's post because it has the right hook to grab) - are Dell required to give out the source to the bios to enable people to have the same rights Dell engineers do to modify the behaviour of the system? 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
On Fri, 15 Jun 2007, Alexandre Oliva wrote: Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 On Jun 14, 2007, Bill Nottingham <[EMAIL PROTECTED]> wrote: OK. Let's take this to the simple and logical conclusion. A signed filesystem image containing both GPL and non-GPL code. From your point A, this is a derived work. I claim the signature is derived from the GPLed bits, yes. Whether that's a derived work, in the legal sense, I'm not qualified to say. it's also derived from the non-GPLed bits as well. so if it were a derived work in a legal sense (nessasary for your argument to have any legal meaning) then it's now illegal to make and distribute a checksum of a CD that contains software with incompatible licenses. And I claim that, in the case of TiVO, it is not only a functional piece of the system that's derived from GPLed code and missing the corresponding sources, but also it's being used to impose restrictions on the exercise of the freedoms that the GPL is designed to protect. And these conditions are what make it a bad thing, and that deviate, if not from the legal conditions, at least from the spirit of the license. you keep claiming this, but other people claim you are wrong. what good do your claims do (why are your claims about what's in the spirit of the license and what's not any more valid than anyone else's?) 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
On Jun 15, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Fri, 15 Jun 2007, Alexandre Oliva wrote: >> >> Yes. They'd have to give up the ability to update the software, or >> pass it on to the user. If they can't do the latter, they could still >> do the former. How bad would this be for them, do you know? > In other words, you advocate license for technical programs that causes > people to make bad technical choices? I do place ethical issues over technical ones, if that's what you're asking. And then, why should the vendor have any say on the software that runs on the hardware I purchased from them, after the purchase? Heck, I'd feel *safer* if I knew they couldn't modify the code in my box without my permission. Do you support WGA or the Sony Rootkit? How is this any different? But if they want to keep the ability to change the software in my box, I want that for myself as well. If for no other reason, in case they mess things up. -- 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: limits on raid
On Thursday June 14, [EMAIL PROTECTED] wrote: > On Fri, 15 Jun 2007, Neil Brown wrote: > > > On Thursday June 14, [EMAIL PROTECTED] wrote: > >> what is the limit for the number of devices that can be in a single array? > >> > >> I'm trying to build a 45x750G array and want to experiment with the > >> different configurations. I'm trying to start with raid6, but mdadm is > >> complaining about an invalid number of drives > >> > >> David Lang > > > > "man mdadm" search for "limits". (forgive typos). > > thanks. > > why does it still default to the old format after so many new versions? > (by the way, the documetnation said 28 devices, but I couldn't get it to > accept more then 27) Dunno - maybe I can't count... > > it's now churning away 'rebuilding' the brand new array. > > a few questions/thoughts. > > why does it need to do a rebuild when makeing a new array? couldn't it > just zero all the drives instead? (or better still just record most of the > space as 'unused' and initialize it as it starts useing it?) Yes, it could zero all the drives first. But that would take the same length of time (unless p/q generation was very very slow), and you wouldn't be able to start writing data until it had finished. You can "dd" /dev/zero onto all drives and then create the array with --assume-clean if you want to. You could even write a shell script to do it for you. Yes, you could record which space is used vs unused, but I really don't think the complexity is worth it. > > while I consider zfs to be ~80% hype, one advantage it could have (but I > don't know if it has) is that since the filesystem an raid are integrated > into one layer they can optimize the case where files are being written > onto unallocated space and instead of reading blocks from disk to > calculate the parity they could just put zeros in the unallocated space, > potentially speeding up the system by reducing the amount of disk I/O. Certainly. But the raid doesn't need to be tightly integrated into the filesystem to achieve this. The filesystem need only know the geometry of the RAID and when it comes to write, it tries to write full stripes at a time. If that means writing some extra blocks full of zeros, it can try to do that. This would require a little bit better communication between filesystem and raid, but not much. If anyone has a filesystem that they want to be able to talk to raid better, they need only ask... > is there any way that linux would be able to do this sort of thing? or is > it impossible due to the layering preventing the nessasary knowledge from > being in the right place? Linux can do anything we want it to. Interfaces can be changed. All it takes is a fairly well defined requirement, and the will to make it happen (and some technical expertise, and lots of time and coffee?). 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Thursday 14 June 2007 22:21:59 Alexandre Oliva wrote: >> Consider egg yolk and egg shells. >> I produce egg yolk. I give it to you under terms that say "if you >> pass this on, you must do so in such a way that doesn't stop anyone >> from eating it" >> You produce egg shells. You carefully construct your shell around the >> egg yolk and some white you got from a liberal third party. >> Then you sell the egg shells, with white and yolk inside, under >> contracts that specify "the shell must be kept intact, it can't be >> broken or otherwise perforated". >> Are you or are you not disrespecting the terms that apply to the yolk? > Bad analogy. It's just a very simple case in which an enclosure is being used to disrespect the terms of something enclosed in it. It's meant to show that the argument that "it's a software license, it can't affect the hardware" is nonsense. It's not meant to show whether TiVO is right or wrong. This would depend on agreement that the GPL requirements are similar to the requirements of the egg yolk manufacturer. >> > by your argument, the user has some "right to modify the >> > software", on that piece of hardware it bought which had free >> > software on it, correct? >> Yes. This means the hardware distributor who put the software in >> there must not place roadblocks that impede the user to get where she >> wants with the software, not that the vendor must offer the user a >> sport car to take her there. > Okay. That means that if I ship Linux on a ROM chip I have to > somehow make it so that the person purchasing the chip can modify > the copy of Linux installed on the chip *if* I want to follow both > the spirit and the letter of the GPLv2. I thought we'd already cleared up the issue about ROMs, and why they're different. Do I have to quote it again? Must I allude to "passing on the rights" every time I mention "imposing further restrictions"? :-( -- 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
On Jun 15, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Thu, 14 Jun 2007, Michael Poole wrote: >> >> If the DRM signature and program executable are coupled such that they >> are not useful when separated, the implication to me is that they form >> one work that is based on the original Program. This is beyond the >> GPL's permission for "mere aggregation". > So you want to make things like a 160-bit SHA1 hash of a binary be a > "derived work" of that software? How about the combination of the software binary with the hash? Considering that the hash is a functional part of the software, as in, if you take that out, it no longer works? > If that were to seriously be an FSF argument, Remember: I don't speak for the FSF, and I don't speak for FSFLA, just like I don't speak for Red Hat. Just like you shouldn't redirect your qualms with the FSF to me, you shouldn't direct your qualms with me to the FSF. That would be very wrong. -- 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
On Fri, 15 Jun 2007, Alexandre Oliva wrote:
>
> case 2'': tivo provides source, end user tries to improve it, realizes
> the hardware won't let him use the result of his efforts, and gives up
So you're blaming Tivo for the fact that your end user was a lazy bum and
wanted to take advantage of somebody elses hard work without permission?
Quite frankly, I know who the bad guy in that scenario is, and it ain't
Tivo. It's your lazy bum, that thought he would just take what Tivo did,
sign the contract, and then not follow it. And just because the box
_contained_ some piece of free software, that lazy bum suddenly has all
those rights? Never mind all the *other* effort that went into bringing
that box to market?
You do realize that Tivo makes all their money on the service, don't you?
The actual hardware they basically give away at cost, exactly to get the
service contracts. Not exactly a very unusual strategy in the high-tech
world, is it?
You know what? I respect the pro-FSF opinions less and less, the more you
guys argue for it. Michael Poole seems to argue that things like fair use
shouldn't exist, and even the cryptographic _signatures_ of the programs
should be under total control of the copyright owner.
And you seem to argue that it's perfectly fine to ignore the people who
design hardware and the services around them, and once you have that piece
of hardware in your grubby hands you can do anythign you want to it, and
_their_ rights and the contracts you signed don't matter at all.
Guys, you should be ashamed of calling yourself "free software" people.
You sound more like the RIAA/MPAA ("we own all the rights! We _own_ your
sorry asses for even listening to our music") and a bunch of whiners that
think that just because you have touched a piece of hardware you
automatically can do anythign you want to it, and nobody elses rights
matter in the least!
Guys, in fighting for "your rights", you should look a bit at *other*
peoples rights too. Including the rights of hw manufacturers, and the
service providers. Because this is all an eco-system, where in order to
actually succeed, you need to make _everybody_ succeed.
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
On Jun 14, 2007, Bill Nottingham <[EMAIL PROTECTED]> wrote: > OK. Let's take this to the simple and logical conclusion. A signed > filesystem image containing both GPL and non-GPL code. From your > point A, this is a derived work. I claim the signature is derived from the GPLed bits, yes. Whether that's a derived work, in the legal sense, I'm not qualified to say. And I claim that, in the case of TiVO, it is not only a functional piece of the system that's derived from GPLed code and missing the corresponding sources, but also it's being used to impose restrictions on the exercise of the freedoms that the GPL is designed to protect. And these conditions are what make it a bad thing, and that deviate, if not from the legal conditions, at least from the spirit of the license. -- 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: [patch] sched: accurate user accounting
malc wrote: > On Thu, 14 Jun 2007, Ingo Molnar wrote: > >> >> * malc <[EMAIL PROTECTED]> wrote: >> the alternating balancing might be due to an uneven number of tasks perhaps? If you have 3 tasks on 2 cores then there's no other solution to achieve even performance of each task but to rotate them amongst the cores. >>> >>> One task, one thread. I have also tried to watch fairly demanding >>> video (Elephants Dream in 1920x1080/MPEG4) with mplayer, and CFS moves >>> the only task between cores almost every second. >> >> hm, mplayer is not running alone when it does video playback: Xorg is >> also pretty active. Furthermore, the task you are using to monitor >> mplayer counts too. The Core2Duo has a shared L2 cache between cores, so >> it is pretty cheap to move tasks between the cores. >> > > Well just to be sure i reran the test with `-vo null' (and fwiw i tried > few completely different output drivers) the behavior is the same. I'm > not running Core2Duo but X2, but guess that does not really matter here. > > As for the task that monitors, i've written it myself (there are two > monitoring methods, one(the accurate) does not depend on contets of > `/proc/stat' at all), so it can be cheaply (for me) changed in any > way one wants. Sources are available at the same place where screenshot > was found. > well, precise/finegrained accounting patches have been available for years, the thing with CFS is that there we get them 'for free', because CFS needs those metrics for its own logic. That's why this information is much closer to reality now. But note: right now what is affected by the changes in the CFS patches is /proc/PID/stat (i.e. the per-task information that 'top' and 'ps' displays, _not_ /proc/stat) - but more accurate /proc/stat could certainly come later on too. >>> >>> Aha. I see, it's just that integral load for hog is vastly improved >>> compared to vanilla 2.6.21 [...] >> >> hm, which ones are improved? Could this be due to some other property of >> CFS? If your app relies on /proc/stat then there's no extra precision in >> those cpustat values yet. > > This is what it looked like before: > http://www.boblycat.org/~malc/apc/load-x2-hog.png > > Now integral load matches the one obtained via the "accurate" method. > However the report for individual cores are of by around 20% percent. > I think I missed some of the context, is the accounting of individual tasks or cpustat values off by 20%? I'll try and reproduce this problem. Could you provide more details on the APC tool that you are using -- I do not understand the orange and yellow lines, do they represent system and user time? NOTE: There is some inconsistency in the values reported by /usr/bin/time (getrusage) and values reported in /proc or through delay accounting. > Though i'm not quite sure what you mean by "which ones are improved". > >> i've Cc:-ed Balbir Singh and Dmitry Adamushko who are the main authors >> of the current precise accounting code in CFS. Maybe i missed some >> detail :-) > > Oh, the famous "With enough eyeballs, all bugs are shallow." in action. > -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - 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: limits on raid
On Fri, 15 Jun 2007, Neil Brown wrote: On Thursday June 14, [EMAIL PROTECTED] wrote: what is the limit for the number of devices that can be in a single array? I'm trying to build a 45x750G array and want to experiment with the different configurations. I'm trying to start with raid6, but mdadm is complaining about an invalid number of drives David Lang "man mdadm" search for "limits". (forgive typos). thanks. why does it still default to the old format after so many new versions? (by the way, the documetnation said 28 devices, but I couldn't get it to accept more then 27) it's now churning away 'rebuilding' the brand new array. a few questions/thoughts. why does it need to do a rebuild when makeing a new array? couldn't it just zero all the drives instead? (or better still just record most of the space as 'unused' and initialize it as it starts useing it?) while I consider zfs to be ~80% hype, one advantage it could have (but I don't know if it has) is that since the filesystem an raid are integrated into one layer they can optimize the case where files are being written onto unallocated space and instead of reading blocks from disk to calculate the parity they could just put zeros in the unallocated space, potentially speeding up the system by reducing the amount of disk I/O. .this wouldn't work if the filesystem is crowded, but a lot of large arrays are used for storing large files (i.e. sequential writes of large amounts of data) and it would seem that this could be a substantial win in these cases. is there any way that linux would be able to do this sort of thing? or is it impossible due to the layering preventing the nessasary knowledge from being in the right place? 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
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > You're making an artificial distinction based on whether the > *SOFTWARE* has a certain license or not. What matters to me is that, when the GPL says you can't impose further restrictions, then you can't, no matter how convoluted your argument is >> That's exactly what makes for the difference between the spirit and >> the precise legal terms, and why GPLv3 is fixing these divergences. > And the reason behind this is all "ethics and morals". There was never any attempt to hide that this was what the Free Software movement was about, and that the GPL was about defending these freedoms. Sure, it has other advantages. But the goal has always been the same, and it's not going to change. > If the intent of a law (or license) is to do A but it doesn't say > that, then how is the intent to be known? Your answer: Ask the > author. No, you interpret based on what the author wrote then. You read the preamble, and any other rationales associated with the license or law. I don't know how it's elsewhere, but in Brazil every law has a rationale, and that's often used to guide its interpretation in courts, even though the rationale is not part of the law. If the author realizes what he wrote was not enough, or it got misinterpreted, author his text, and then whoever feels like it and is entitled to adopts the revised version. In the GPLv2=>v3 case, all that needed revision was the legalese. The preamble has barely changed. This is a strong indication that the spirit remains the same, is it not? > Unless the intent is clearly spelled out at the time the law (or > license) is written, or is available in other writings by the author > of the law/license from the same time period as the law/license then > it is impossible. Is there anything not clear about freedom #0, in the free software definition, alluded to by the preamble that talks about free software in very similar terms? -- 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
On Fri, 15 Jun 2007, Alexandre Oliva wrote: > > Yes. They'd have to give up the ability to update the software, or > pass it on to the user. If they can't do the latter, they could still > do the former. How bad would this be for them, do you know? In other words, you advocate license for technical programs that causes people to make bad technical choices? Yeah, that's real smart. That's a sign of true intellect, isn't it? Wrong. 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
Linus Torvalds writes: > On Thu, 14 Jun 2007, Michael Poole wrote: >> >> If the DRM signature and program executable are coupled such that they >> are not useful when separated, the implication to me is that they form >> one work that is based on the original Program. This is beyond the >> GPL's permission for "mere aggregation". > > So you want to make things like a 160-bit SHA1 hash of a binary be a > "derived work" of that software? No. That is why I specified "not useful when separated". I also intentionally avoided the phrase "derived work": the legal definition of derived work is based on entirely different factors. If the signature is one that serves to indicate origin, to detect tampering, or the other things you mentioned, the program's binary is useful when separated from the signature. My objection arises when a functionally equivalent binary -- including advertised functions such as "runs on platform XYZ" -- cannot be produced from the distributed source code. Michael Poole - 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
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > Faulty logic. The hardware doesn't *restrict* you from *MODIFYING* > any fscking thing. Ok, lemme try again: case 2'': tivo provides source, end user tries to improve it, realizes the hardware won't let him use the result of his efforts, and gives up > On Thursday 14 June 2007 18:45:07 Alexandre Oliva wrote: >> Where's the payback, or the payforward? >> >> And then, tit-for-tat is about equivalent retaliation, an eye for an >> eye. Where's the retaliation here? >> >> If GPLv2 were tit-for-tat, if someone invents artifices to prevent the >> user from making the changes the user wants on the software, wouldn't >> it be "equivalent retaliation" to prevent the perpetrator from making >> the changes it wants on the software? -- 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
On Thu, 14 Jun 2007, Michael Poole wrote: > > If the DRM signature and program executable are coupled such that they > are not useful when separated, the implication to me is that they form > one work that is based on the original Program. This is beyond the > GPL's permission for "mere aggregation". So you want to make things like a 160-bit SHA1 hash of a binary be a "derived work" of that software? Trust me, you *really* don't want to go there. It's an insane legal standpoint, and if you were right, we'd be in a *world* of trouble. Think about something as simple as security software that creates filesystem checksums for verifying the integrity of the filesystem, and protects against tampering. Do you *really* want to claim that the SHA1 checksum of your "oracle" binary is owned by Oracle, and you need to have a special license to copy that checksum around and verify it? Do you *really* want to claim that the RIAA owns the CDDB checksums (well, I guess "feedb", these days) of the CD's that get uploaded for music databases? Do you realize that in your INSANE world, there is no notion of "fair use", and you just tried to extend the notion of copyright so far that you turned your utopia into a total distopia. In other words, anybody who claims that copyright in a program extends to the cryptographic hash of the binary, and at the same time makes a "free software" kind of argument is so damn clueless that it's not even funny. You're arguing for "freedom" by using logic that is the very *antithesis* of freedom. That's just incredibly stupid and incredibly short-sighted. If that were to seriously be an FSF argument, then I would officially lump the FSF as a *much*worse* danger to the free world than the RIAA and the MPAA combined! I seriously doubt you really thought your idea through! Because it goes beyond 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
On Jun 14, 2007, Florin Malita <[EMAIL PROTECTED]> wrote: > On 06/14/2007 05:39 PM, Alexandre Oliva wrote: >> Back when GPLv2 was written, the right to run was never considered an >> issue. It was taken for granted, because copyright didn't control >> that in the US (it does in Brazil), and nobody had thought of >> technical measures to stop people from running modified copies of >> software. At least nobody involved in GPLv2, AFAIK. >> The landscape has changed, and GPLv3 is meant to defend this >> freedom that was taken for granted. > Then you agree that GPLv2 does not protect your freedom (taken for > granted) to run a modified copy on any particular device, or am I > misreading? IANAL, but AFAICT it doesn't. Still, encoded in the spirit (that refers to free software, bringing in the free software definition), is the notion of protecting users' freedoms, among them the freeom #0, to run the software for any purpose. That's why I believe it's in the spirit of the license to defend this freedom. And that's why lawyers in Brazil believe that, even though the GPL does not affirm the right to run the software, it fits the bill, because, under the light of the preamble, the free software definition, and the US copyright law, it should be interpreted as an intent to grant permission to run the software. > Hence, Tivo is not really *modifying* the copies it distributes with > the device - they're *installing* brand new copies instead. They > also choose not to offer everybody the same privilege :-| Got it. That's bad. :-( -- 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
On Thursday 14 June 2007 05:32:47 Bernd Paysan wrote: > On Thursday 14 June 2007 03:24, Adrian Bunk wrote: > > 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. > > And if Tivo did sell their crap in Germany, I bet, Harald had brought them > down years ago (as he did in the "tivoized" Siemens router case). But Tivo > doesn't (they started in the UK, and stopped doing so right after Harald > unlocked that Siemens router ;-), and in the US, courts may think > different. Or they rely that there simply is no Harald Welte in the US, who > goes after the violators. On http://www.busybox.net the March 26, 2006 entry reads: > 27 March 2006 -- Software Freedom Law Center representing BusyBox and > uClibc One issue Erik Andersen wanted to resolve when handing off BusyBox > maintainership to Rob Landley was license enforcement. BusyBox and uClibc's > existing license enforcement efforts (pro-bono representation by Erik's > father's law firm, and the Hall of Shame), haven't scaled to match the > popularity of the projects. So we put our heads together and did the > obvious thing: ask Pamela Jones of Groklaw for suggestions. She referred us > to the fine folks at softwarefreedom.org. > > As a result, we're pleased to > announce that the Software Freedom Law Center has agreed to represent > BusyBox and uClibc. We join a number of other free and open source software > projects (such as X.org, Wine, and Plone in being represented by a fairly > cool bunch of lawyers, which is not a phrase you get to use every day. See also the September 29, 2006 entry where we set up an email address to forward license violation reports directly to them so we wouldn't have to deal with any of it. I'd say this "hasn't cost me a dime", but I believe I'm on my third stamp. (I also note that I'm not busybox maintainer anymore and Erik isn't uclibc maintainer anymore either, but since it's our copyrights they're basing the enforcement actions on, they still bounce an email off us every few months.) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Thu, 14 Jun 2007, Alexandre Oliva wrote: >> >> It's disappointing that I took so much of everyone's time without >> achieving any of my goals. > What do you expect, when you tried to entertain a legal picture of the > GPLv2 that even the FSF counsel doesn't believe in? I don't think I made significant legal arguments. My points were about the spirit of the license. That's not legal at all. That's moral and ethical background. Your aggressive response directed at the FSF came as quite a surprise to me, given the way I got into this conversation. > I will state one more time: I think that what Tivo did was and is: > (a) perfectly legal wrt the GPLv2 I respectfully disagree, and I know I'm not alone in this assessment. I know other kernel developers agree with it. And they're as entitled to claim failure to comply with the license as you are. > (and I have shown multiple times why > your arguments don't hold logical water You countered one of the various arguments I have, and you failed at that. It was another, quite different argument, that got me to realize it didn't work legally. But this says nothing about compliance with the spirit of the license. > (b) not just legally right, but perfectly morally right too I guess we'll have to agree to disagree on this one. > (c) the only reasonable thing many companies *can* do in the face > of laws and regulations and entities like the RIAA/MPAA. No, TiVO could just throw the key away. Why doesn't it? > and you should admit that the fact that the FSF counsel says that it > couldn't sue Tivo in the US, it means that while my standpoint may not be > the _only_ possible one, I'm certainly not "confused" about (a) above. I don't think I've ever claimed you were confused about (a). I said we disagreed. That's quite different. You were confused between the legalese and the spirit. > The (b) and (c) points are not "legal" points, they are about the fact > that quite often, morality and practicality are independent of legality, > and you should never see law as being the *only* thing that matters. Aah, now we're getting somewhere! > Dammit, if I cannot say that I think what they did was fine, who can? If you and all other Linux copyright holders agreed about it, sure. Just like you could all grant it an additional permission, just so that they feel safe about it. > Now, we both agree that GPLv3 would change the situation wrt Tivo, don't > we? Yes. They'd have to give up the ability to update the software, or pass it on to the user. If they can't do the latter, they could still do the former. How bad would this be for them, do you know? > And yet you claim that you cannot understand why I (and others) would > consider the GPLv3 to be a "worse" license. That's because when you talk about why GPLv2 is better, you always talked about virtues that are just as present in v3, and that AFAICT would in fact by increased by v3. > .. but I guess you'll ignore that argument, the way you ignored all the > other ones too, and continue to blame your lack of understanding on me > being "confused" about the issue. I'm sorry if I come off that way. But we really look at this issue from very different perspectives, and it's difficult for me to try to see it your way. Please cut me some slack here. I'm trying hard, but there is so much noise and so many hard feelings that seeing what the real issues are is not that easy. Thanks for your understanding, -- 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: limits on raid
On Thursday June 14, [EMAIL PROTECTED] wrote: > what is the limit for the number of devices that can be in a single array? > > I'm trying to build a 45x750G array and want to experiment with the > different configurations. I'm trying to start with raid6, but mdadm is > complaining about an invalid number of drives > > David Lang "man mdadm" search for "limits". (forgive typos). 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > On Thursday 14 June 2007 22:13:13 Michael Poole wrote: > >> The fundamental reason for this is that neither the executable code >> nor the digital signature serves the desired function alone. The user >> received a copy of the executable for a particular purpose: to run the >> program on a particular platform. With DRM signatures, only the >> combination of program and signature will perform that function, and >> separating the two based on strictly read legal definitions is risky. > > I agree. > >> The question of whether DRM signatures are covered by the license must >> be resolved before one can determine whether Tivo gave "*EXACTLY*" the >> same rights to object-code recipients as Tivo received. GPLv2 is >> worded such that the answer to this does not depend on whether one is >> in file A and the other in file B, or whether one is on hard drive C >> and the other is in flash device D, as long as they are delivered as >> part of one unit; it *might* matter if, say, one is received on >> physical media and the other is downloaded on demand. > > I have read the GPLv2 at least three times since it was pointed out that I > had > forgotten part of it. At no point can I find a point where Tivo broke the > GPLv2 requirement that they give the recipients of the object code the same > rights they received when they acquired a copy of the object or source code. I am trying to reconcile your responses to those two paragraphs. If the DRM signature and program executable are coupled such that they are not useful when separated, the implication to me is that they form one work that is based on the original Program. This is beyond the GPL's permission for "mere aggregation". If they are one work, and the original Program was licensed under the GPLv2, the combined work must also be licensed under the terms of the GPLv2. The input files required to generate a DRM-valid digital signature are part the preferred form for modifying that work. If those bits are not distributed along with the rest of the GPL'ed work, the distributor is either not giving the same rights to the end user, not distributing the source code for the work, or both. Which is it? Michael Poole - 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: mm: Fix memory/cpu hotplug section mismatch and oops.
On Thu, Jun 14, 2007 at 06:32:32PM +0900, Yasunori Goto wrote: > Thanks. I tested compile with cpu/memory hotplug off/on. > It was OK. > > Acked-by: Yasunori Goto <[EMAIL PROTECTED]> > It would be nice to have this 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/
limits on raid
what is the limit for the number of devices that can be in a single array? I'm trying to build a 45x750G array and want to experiment with the different configurations. I'm trying to start with raid6, but mdadm is complaining about an invalid number of drives 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: [TOMOYO 1/9] Allow use of namespace_sem from LSM module.
> Looks whitespace-damaged to me. > Pavel Oops, I sent patches with "Content-type: format=flowed" header. I think your mail client converted tabs into spaces. The orignal patches themselves are not whitespace-damaged. http://kb.mozillazine.org/Plain_text_e-mail_(Thunderbird) Kentaro Takeda - 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
On Thursday 14 June 2007 22:21:59 Alexandre Oliva wrote: > On Jun 14, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > the GPLv2 license says no such thing, and you seem to be mighty confused > > about how software licenses work. > > > > the GPL applies to software. It is a software license. > > > > the Tivo box is a piece of hardware. > > > > a disk is put into it with software copied to it already: a bootloader, > > a Linux kernel plus a handful of applications. The free software bits > > are available for download. > > > > the Tivo box is another (copyrighted) work, a piece of hardware. > > > > so how can, in your opinion, the hardware that Tivo produces, "take > > away" some right that the user has to the GPL-ed software? > > Consider egg yolk and egg shells. > > I produce egg yolk. I give it to you under terms that say "if you > pass this on, you must do so in such a way that doesn't stop anyone > from eating it" > > > You produce egg shells. You carefully construct your shell around the > egg yolk and some white you got from a liberal third party. > > > Then you sell the egg shells, with white and yolk inside, under > contracts that specify "the shell must be kept intact, it can't be > broken or otherwise perforated". > > > Are you or are you not disrespecting the terms that apply to the yolk? Bad analogy. I've already provided all the proof needed to prove that, while "tivoization" may be against the "intent" or "spirit" of the GPLv2 it is not in violation of it. > > by your argument, the user has some "right to modify the software", on > > that piece of hardware it bought which had free software on it, correct? > > Yes. This means the hardware distributor who put the software in > there must not place roadblocks that impede the user to get where she > wants with the software, not that the vendor must offer the user a > sport car to take her there. Okay. That means that if I ship Linux on a ROM chip I have to somehow make it so that the person purchasing the chip can modify the copy of Linux installed on the chip *if* I want to follow both the spirit and the letter of the GPLv2. And no claiming that I'm missing the point - I'm drawing a logical conclusion from your statement above. > The goal is not to burden the vendor. The goal is to stop the vendor > from artificially burdening the user. I have no objection to this. What I object to is the manner in which it is being done. However, I must admit that, at this point, I do not know of a better method to achieve this goal. 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
On Jun 14, 2007, Rob Landley <[EMAIL PROTECTED]> wrote: > On Thursday 14 June 2007 19:20:19 Alexandre Oliva wrote: >> I understand this very well. You'd have to get the kernel upgraded to >> GPLv3 in order to accept the contribution. > Why do you keep saying "upgraded" to GPLv3? Just because it has a higher version number. Honest, no other reason was implied. I'm seriously not trying to push v3 here. I got into this to try to dispell myths and get a better grasp of the situation. > Bumping a version number is not in indicator of quality, Agreed. Still, some people talk about upgrading from XP to Vista (ok, no numbers here, but you get the idea), just like they talk about upgrading from linux 2.4 to 2.6. > So far, you haven't brought up a single reason to use v3 Sure, that was not my goal. I wasn't even trying. Would you like me to? > You've just tried to argue that it isn't WORSE than the existing > license. Good, it's nice when people get the idea of what I'm trying to accomplish. I feared this had been lost in the noise. -- 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
On Thursday 14 June 2007 22:13:13 Michael Poole wrote: > Daniel Hazelton writes: > > What rights did they give to "downstream" recipients of the "object code" > > version? *EXACTLY* those they received from the GPLv2. > > Doing the e-mail equivalent of yelling about this will not change the Sorry, I wasn't trying to "yell" - just provide a note that at that point I would be providing verbal stress. > fact that people who think Tivo did something wrong -- legally and/or > morally -- consider DRM locks on a piece of software to be part of the > "work based on the Program" that is governed by the GPL. All I've done is get a little annoyed that, despite evidence that it isn't legally wrong - at least under the laws I am most familiar with - people continue repeat that it is. I can't argue that it isn't "morally" wrong. While it may not be against my morals, it could be against those of another person. It has never been my intent to try and convince people that their morals are wrong. > The fundamental reason for this is that neither the executable code > nor the digital signature serves the desired function alone. The user > received a copy of the executable for a particular purpose: to run the > program on a particular platform. With DRM signatures, only the > combination of program and signature will perform that function, and > separating the two based on strictly read legal definitions is risky. I agree. > The question of whether DRM signatures are covered by the license must > be resolved before one can determine whether Tivo gave "*EXACTLY*" the > same rights to object-code recipients as Tivo received. GPLv2 is > worded such that the answer to this does not depend on whether one is > in file A and the other in file B, or whether one is on hard drive C > and the other is in flash device D, as long as they are delivered as > part of one unit; it *might* matter if, say, one is received on > physical media and the other is downloaded on demand. I have read the GPLv2 at least three times since it was pointed out that I had forgotten part of it. At no point can I find a point where Tivo broke the GPLv2 requirement that they give the recipients of the object code the same rights they received when they acquired a copy of the object or source code. > (Linus likes to say that FSF counsel thinks that Tivo did not violate > GPLv2. I suspect the actual situation is that FSF counsel believes > that there is no case law on point, and that it could go either way, > making it improper to publicly claim that Tivo violated any copyright. > Until a court rules on a close-enough case, the question of whether > GPLv2 covers DRM signatures remains open. In the mean time, it makes > more sense for the FSF to issue a new license that squarely addresses > this -- such as the GPLv3 -- and persuade as many developers as > possible that using it is the best way to protect free software.) In examining the GPLv2 and the situation from a strictly factual basis I can believe Linus' statement fully. The facts are as I stated them in a previous mail. DRH > Michael Poole -- 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
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Thursday 14 June 2007 17:27:27 Alexandre Oliva wrote: >> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: >> > >> > And the companies that produce devices that come with Linux and/or >> > other GPL'd software installed and place limits such that only >> > people that have purchased that hardware have access to the >> > "modified" source running on the device are following the letter, >> > and the spirit, of the GPL. >> >> WAIT, WAIT, THAT'S... :-) >> >> > Before you start yelling I'm wrong, think about it this way: they >> > make the source available to the people that they've given binary >> > versions to, and there is nothing stopping one of those people from >> > making the source available to the rest of the world. >> >> The *only* in your sentence betrayed you. >> >> If they place the limits such that nobody else can access the sources, >> they're in violation of the license. > Nope. There is *NO* requirement *ANYWHERE* in the GPL, no matter the version, > that says you have to *DISTRIBUTE* the source to *ANYONE* except those that > you have given a binary to. Go read the licenses. I agree. I even said so. But the *only* gave me the impression that you were talking about magic, or any other sufficiently advanced technology ;-), that would enable the recipients to get the source code, but not usefully pass it on. > That is *EXACTLY* what a number of companies have done - Acer (yes, > the laptop company) has done that. They sell laptops running Linux, > but unless you have purchased one of them you can't download the > sources (or even replacement binaries) for the version of linux they > put on their machines. (From Acer, that is) That's the sort of stuff that breaks the tit-for-tat premise. GPL indeed is not concerned about tit-for-tat. It's concerned about respect for the 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 http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
Hello. James Morris wrote: > 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, adding "allow" statement without understanding what the statement means is dangerous. But regarding TOMOYO Linux, "allow" statement that needs to be added to grant requested access is quite easy for human to understand. This helps administrator understand what will be allowed before allowing it. For example, if "allow foo_t bin_t:execute" (sorry, I don't know proper SELinux's policy syntax) statement is shown to an administrator, he/she has to understand what programs belongs to bin_t before adding this statement, for some files may be exposed (if /bin/cat is bin_t) or some files may be deleted (if /bin/rm is bin_t). But if "allow execute /bin/cat" statement is shown to an administrator, he/she can easily understand what will happen because only programs that are accessible via the pathname /bin/cat can be executed. People assumes and expects that /bin/cat is a program that prints the content of files, /usr/share/doc is a directory for shared documents, /tmp is a directory for temporaly files and so on. I know you worry about symlinks, chroots, bind mounts and private namespaces. TOMOYO Linux solves all symlinks and traverses up to namespace's root so that /bin/cat is exactly /bin/cat and nothing else (e.g. /tmp/cat or /var/chroot/bin/cat, where /tmp/cat is a malicious program). TOMOYO Linux restricts mount related operations to make sure /bin is not a bind mount of /tmp and /bin/cat is not an alias of /tmp/cat . TOMOYO Linux restricts modification of /bin/cat by not giving processes write permission to /bin/cat unless needed. TOMOYO Linux's way is respect pathnames and try to keep meaning of pathnames unchanged as hard as possible so that the system can provide files which poeple assumes and expects. I know respecting pathnames will crash if the systems need complicated namespace manipuration like shared subtree or overlay mounts. For such systems, the only choice is label based access control. But I think many systems don't need complicated namespace manipuration. For such systems, both label based and pathname based access control are possible choice. > 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. If there were only "disabled" and "enforcing" modes, per-domain enforcing mode would not be useful. The development of TOMOYO Linux's policy starts from scratch and builds up step by step for all domains. If I use "enforcing mode but allows everything" approach, it becomes impossible to develop policy using "learning" and "permissive" modes where some of domains are already in enforcing mode but the rests are not yet. At least, per-domain enforcing mode is useful for TOMOYO Linux. Thanks. - 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 ([EMAIL PROTECTED]) said: > > Wait, a signed filesystem image that happens to contain GPL code > > is now a derived work? Under what sort of interpretation does *that* > > occur? > > Is the signature not derived from the bits in the GPLed component, as > much as it is derived from the key? > > Isn't the signature is a functional portion of the image, i.e., if I > take it out from the system, it won't work any more? > > > (This pretty much throws the 'aggregation' premise in GPLv2 completely > > out.) > > Not really. It could take some explicit distinguishing between > functional and non-functional signatures, but that's about it. OK. Let's take this to the simple and logical conclusion. A signed filesystem image containing both GPL and non-GPL code. From your point A, this is a derived work. Let's read the license... 2. b) You must cause any work that ... is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. ... But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. and yet later: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Pick one. They can't both be valid. Moreover, this interpretation means that Red Hat (and pretty much any other Linux distributor) should close up shop, as that's what we've been doing for years. Bill - 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: raid5: coding style cleanup / refactor
On 6/14/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: When you are ready for wider testing, if you have a patch against a released kernel it makes testing easy, characteristics are pretty well known already. Thanks I went ahead and put a separate snapshot up on SourceForge: http://downloads.sourceforge.net/xscaleiop/md-accel-2.6.22-rc4-20070614.patch [ It's actually based on current git but should apply cleanly to 2.6.22-rc4. ] If you are so inclined the most up-to-date version is available via git. git pull git://lost.foo-projects.org/~dwillia2/git/iop md-accel-linus It should perform identically to vanilla 2.6.22-rc4 MD. -- bill davidsen <[EMAIL PROTECTED]> Regards, 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: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Thu, 14 Jun 2007, Andrew Morton wrote: > > The metadata needs to refer to 1/16th of the earlier pages that need to be > > tracked. metadata is shrunk significantly. > > Only if the filesystems are altered to use larger blocksizes and if the > operator then chooses to use that feature. Then they suck for small-sized > (and even medium-sized) files. Nope. File systems already support that. The changes to XFS and ext2 are basically just doing the cleanups that we are discussing here plus some changes to set_blocksize. > So you're still talking about corner cases: specialised applications which > require careful setup and administrator intervention. > > What can we do to optimise the common case? The common filesystem will be able to support large block sizes easily. Most filesystems already run on 16k and 64k page size platforms and do just fine. All the work is already done. Just the VM needs to give them support for lager page sizes on smaller page size platforms. This is optimizing the common case. > The alleged fsck benefit is also unrelated to variable PAGE_CACHE_SIZE. > It's a feature of larger (unweildy?) blocksize, and xfs already has that > working (doesn't it?) It has a hack with severe limitations like we have done in many other components of the kernel. These hacks can be removed if the large blocksize support is merged. XFS still has the problem that the block layer without page cache support for higher pages cannot easily deal with large contiguous pages. > There may be some benefits to some future version of ext4. I have already run ext4 with 64k blocksize on x86_64 with 4k. It has been done for years with 64k page size on IA64 and powerpc and there is no fs issue with running it on 4k platforms with the large blocksize patchset. The filesystems work reliably. The core linux code is the issue that we need to solve and this is the beginning of doing so. - 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
On Thursday 14 June 2007 21:43:07 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 14:35:29 Alexandre Oliva wrote: > > > > > >> > So let's look at that "section 6" that you talk about, and quote the > >> > relevant parts, will we: > >> > > >> > You may not impose any further restrictions on the recipients' > >> > exercise of the rights granted herein. > >> > > >> > and then let's look at Red Hat sending me a CD-ROM or a DVD. > >> > > >> > Now, Red Hat clearly *did* "further restrict" my rights as it pertains > >> > TO THAT COPY ON THE CD-ROM! I cannot change it! Waa waa waa! I'll sue > >> > your sorry ass off! > >> > >> Red Hat is not stopping you from making changes. The media is, and > >> that's not something Red Hat can control. > > > > TiVO isn't stopping you from making changes - the *media* is. > > TiVO made it so, that's the difference. > > I'll give you that it's not so much about making changes per se, or > even installing them, as it is about running the modified versions for > any purpose. Artificial distinction on your part. > >> Compare this with the TiVO. TiVO *designs* the thing such that it can > >> still make changes, but customers can't. > >> > >> That's the difference. > > > > No, it isn't. Look at any motherboard. The Bios on the last three or four > > motherboards I've purchased check for a digital signature on the Bios > > updates. The motherboard manufacturer can make changes, but the customer > > can't. Is there any difference? Nope. > > Is the BIOS code under the GPL? By your reasoning it doesn't even matter. I own the hardware, I should be able to change the BIOS to *any* chunk of code I want. Do you see the fallacy here? You're making an artificial distinction based on whether the *SOFTWARE* has a certain license or not. > > The fact is that claiming it was "the spirit" doesn't matter at all > > - this isn't philosophy you're arguing, its *LAW*, and in law, if it > > isn't clearly spelled out, it doesn't exist. > > That's exactly what makes for the difference between the spirit and > the precise legal terms, and why GPLv3 is fixing these divergences. And the reason behind this is all "ethics and morals". In other words, you are forcing those "ethics and morals" on others and hiding it by giving it a different name. Wasn't it Shakespear who said: "What is in a name? A Rose by any other name would smell as sweet" > > And where does it say that you even have the right to run the "work based > > on the Program", or even a self-compiled copy of the "verbatim copy of > > the code" on any given piece of hardware? > > It doesn't. The license can't demand the software, or modified > versions thereof, to run. The only thing it can demand is that > licensees don't impose restrictions on others' abilities to do so. No, it doesn't. There is no requirement in the license in question that makes a persons ability to run the program on any given piece of hardware. What it does say is you can't stop someone from *TRYING* to do that. > >> > But by "the software", the license is not talking about a particular > >> > *copy* of the software, it's talking about the software IN THE > >> > ABSTRACT. > >> > >> Please read it again. > > > > Done. > > 2. You may modify your copy or copies of the Program or any portion > of it > > > If this has been the "intent and spirit" of the license from the > > beginning, it should be there somewhere. > > I think you're missing what 'spirit' means. It's guidance, it's not > the legal terms. And it's precisely because the implementation (the > legal terms) failed to meet that design (the spirit, encoded in the > preamble) that the license needs patching. If the intent of a law (or license) is to do A but it doesn't say that, then how is the intent to be known? Your answer: Ask the author. Question: how can we be absolutely certain that the authors intent *hasn't* changed since the law (or license) was written? *ONLY* answer: It is impossible. Conclusion: Unless the intent is clearly spelled out at the time the law (or license) is written, or is available in other writings by the author of the law/license from the same time period as the law/license then it is impossible. Question: How do you know what the "spirit" of a license is? Your Answer: Ask the author. Question: How do we know that the Author hasn't changed their mind about the "spirit" of the license since it was written? *ONLY* Answer: See the answer to the parallel question about "intent". Now that I've knocked down your "Intent" and "Spirit" straw-men you have no way to argue that the GPLv3 is written with the same "spirit" as the 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
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote: > Alexandre Oliva <[EMAIL PROTECTED]> writes: >> On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: >>> On Thu, 14 Jun 2007, Alexandre Oliva wrote: Hmm... So, if someone takes one of the many GPLv2+ contributions and makes improvements under GPLv3+, you're going to make an effort to accept them, rather than rejecting them because they're under the GPLv3? >>> You *cannot* make GPLv3-only contributions to the kernel. >> I can make improvements to GPLv2+ files under GPLv3 (or rather will, >> after GPLv3 is published). > You can do that, but you won't be able to distribute those changes along > with the rest of the kernel. I know. Neither will Linus. But he says he chose GPLv2 such that he could, and the v2 is better than v3 in this regard. What's wrong with this picture? -- 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
On Jun 14, 2007, Bill Nottingham <[EMAIL PROTECTED]> wrote: > Alexandre Oliva ([EMAIL PROTECTED]) said: >> And since the specific implementation involves creating a derived work >> of the GPLed kernel (the signature, or the signed image, or what have >> you) > Wait, a signed filesystem image that happens to contain GPL code > is now a derived work? Under what sort of interpretation does *that* > occur? Is the signature not derived from the bits in the GPLed component, as much as it is derived from the key? Isn't the signature is a functional portion of the image, i.e., if I take it out from the system, it won't work any more? > (This pretty much throws the 'aggregation' premise in GPLv2 completely > out.) Not really. It could take some explicit distinguishing between functional and non-functional signatures, but that's about it. GPLv3 chose a different path to make this clarification. -- 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: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Thu, 14 Jun 2007 19:04:27 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > Of course there is. The seeks are reduced since there are an factor > > > of 16 less metadata blocks. fsck does not read files. It just reads > > > metadata structures. And the larger contiguous areas the faster. > > > > Some metadata is contiguous: inode tables, some directories (if they got > > lucky), bitmap tables. But fsck surely reads them in a single swoop > > anyway, so there's no gain there. > > The metadata needs to refer to 1/16th of the earlier pages that need to be > tracked. metadata is shrunk significantly. Only if the filesystems are altered to use larger blocksizes and if the operator then chooses to use that feature. Then they suck for small-sized (and even medium-sized) files. So you're still talking about corner cases: specialised applications which require careful setup and administrator intervention. What can we do to optimise the common case? > > Other metadata (indirect blocks) are 100% discontiguous, and reading those > > with a 64k IO into 64k of memory is completely dumb. > > The effect of a larger page size is that the filesystem will > place more meta data into a single page instead of spreading it out. > Reading a mass of meta data with a 64k read is an intelligent choice to > make in particular if there is a large series of such reads. Again: requires larger blocksize: specialised, uninteresting for what will remain the common case: 4k blocksize. The alleged fsck benefit is also unrelated to variable PAGE_CACHE_SIZE. It's a feature of larger (unweildy?) blocksize, and xfs already has that working (doesn't it?) There may be some benefits to some future version of ext4. - 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
On Jun 14, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote: > the GPLv2 license says no such thing, and you seem to be mighty confused > about how software licenses work. > the GPL applies to software. It is a software license. > the Tivo box is a piece of hardware. > a disk is put into it with software copied to it already: a bootloader, > a Linux kernel plus a handful of applications. The free software bits > are available for download. > the Tivo box is another (copyrighted) work, a piece of hardware. > so how can, in your opinion, the hardware that Tivo produces, "take > away" some right that the user has to the GPL-ed software? Consider egg yolk and egg shells. I produce egg yolk. I give it to you under terms that say "if you pass this on, you must do so in such a way that doesn't stop anyone from eating it" You produce egg shells. You carefully construct your shell around the egg yolk and some white you got from a liberal third party. Then you sell the egg shells, with white and yolk inside, under contracts that specify "the shell must be kept intact, it can't be broken or otherwise perforated". Are you or are you not disrespecting the terms that apply to the yolk? > by your argument, the user has some "right to modify the software", on > that piece of hardware it bought which had free software on it, correct? Yes. This means the hardware distributor who put the software in there must not place roadblocks that impede the user to get where she wants with the software, not that the vendor must offer the user a sport car to take her there. The goal is not to burden the vendor. The goal is to stop the vendor from artificially burdening the user. -- 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
On Thu, 14 Jun 2007, Alexandre Oliva wrote: > > It's disappointing that I took so much of everyone's time without > achieving any of my goals. What do you expect, when you tried to entertain a legal picture of the GPLv2 that even the FSF counsel doesn't believe in? I will state one more time: I think that what Tivo did was and is: (a) perfectly legal wrt the GPLv2 (and I have shown multiple times why your arguments don't hold logical water - if you actually followed them yourself, you wouldn't be using a redhat.com email address!) (b) not just legally right, but perfectly morally right too (it wasn't some underhanded "trick" thing - it was following the spirit _and_ the letter of the law) (c) the only reasonable thing many companies *can* do in the face of laws and regulations and entities like the RIAA/MPAA. and you should admit that the fact that the FSF counsel says that it couldn't sue Tivo in the US, it means that while my standpoint may not be the _only_ possible one, I'm certainly not "confused" about (a) above. The (b) and (c) points are not "legal" points, they are about the fact that quite often, morality and practicality are independent of legality, and you should never see law as being the *only* thing that matters. So the reason I bring them up is that it wasn't just "legally ok", they also had good *reasons* for doing it, and there was no hanky-panky about it! In fact, I consider Tivo one of the good guys, because they were one of the few people that had things like the GPLv2 actually printed out and clearly stated IN THE MAIN PAPER MANUAL. In the very first version of their box. Without anybody twisting any arms at all. IOW, Tivo really did everything right. I personally think that they were even classy about it. And that's my opinion. THINK about that for a moment. THINK about the fact that I am the original copyright holder in the main software project they used, and that I state that as neither having ever gotten paid _or_ owning any stock what-so-ever in Tivo. Dammit, if I cannot say that I think what they did was fine, who can? So pause there for a moment, and really *think* about the above. Stop seeing Tivo as "the devil". [ Wait a few seconds here, thinking! ] Now, we both agree that GPLv3 would change the situation wrt Tivo, don't we? [ Wait a few more seconds here, thinking about what that means, taking the above into consideration ] ..so given that I think that what Tivo did is *fine*, the GPLv3 "solution" is not a solution at all, is it? Quite the reverse. It's a unnecessary restriction that doesn't actually solve anything at all, it just adds problems of its own. And yet you claim that you cannot understand why I (and others) would consider the GPLv3 to be a "worse" license. It is *obviously* worse to anybody who thought that "Tivoization" wasn't a problem in the first place! .. but I guess you'll ignore that argument, the way you ignored all the other ones too, and continue to blame your lack of understanding on me being "confused" about the issue. 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 writes: > What rights did they give to "downstream" recipients of the "object code" > version? *EXACTLY* those they received from the GPLv2. Doing the e-mail equivalent of yelling about this will not change the fact that people who think Tivo did something wrong -- legally and/or morally -- consider DRM locks on a piece of software to be part of the "work based on the Program" that is governed by the GPL. The fundamental reason for this is that neither the executable code nor the digital signature serves the desired function alone. The user received a copy of the executable for a particular purpose: to run the program on a particular platform. With DRM signatures, only the combination of program and signature will perform that function, and separating the two based on strictly read legal definitions is risky. The question of whether DRM signatures are covered by the license must be resolved before one can determine whether Tivo gave "*EXACTLY*" the same rights to object-code recipients as Tivo received. GPLv2 is worded such that the answer to this does not depend on whether one is in file A and the other in file B, or whether one is on hard drive C and the other is in flash device D, as long as they are delivered as part of one unit; it *might* matter if, say, one is received on physical media and the other is downloaded on demand. (Linus likes to say that FSF counsel thinks that Tivo did not violate GPLv2. I suspect the actual situation is that FSF counsel believes that there is no case law on point, and that it could go either way, making it improper to publicly claim that Tivo violated any copyright. Until a court rules on a close-enough case, the question of whether GPLv2 covers DRM signatures remains open. In the mean time, it makes more sense for the FSF to issue a new license that squarely addresses this -- such as the GPLv3 -- and persuade as many developers as possible that using it is the best way to protect free software.) Michael Poole - 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
On Jun 14, 2007, Rob Landley <[EMAIL PROTECTED]> wrote: > On Thursday 14 June 2007 13:46:40 Alexandre Oliva wrote: >> Well, then, ok: do all that loader and hardware signature-checking >> dancing, sign the image, store it in the machine, and throw the >> signing key away. This should be good for the highly-regulated areas >> you're talking about. And then, since you can no longer modify the >> program, you don't have to let the user do that any more. Problem >> solved. > A) Does that actually satisfy the terms of GPLv3? I think so: this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product > If so, can't they just wait until they get sued and destroy the keys > then? I don't think this woulnd't satisfy the above. -- 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: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Thu, 14 Jun 2007, Andrew Morton wrote: > There will be files which should use 64k but which instead end up using 4k. > > There will be files which should use 4k but which instead end up using 64k. > > Because determining which size to use requires either operator intervention > or kernel heuristics, both of which will be highly unreliable. > > It's better to just make 4k pages go faster. Initially its quite easy to have a filesystem for your 4k files (basically the distro you are running) and an archive for video / audio etc files that has 64k size for data. In the future filesystem may support sizes set per directory. Basically if things get to slow you can pull the lever. > > Magical? There is nothing magical about doing transfers in the size that > > is supported by a device. That is good sense. > > By magical heuristics I'm referring to the (required) tricks and guesses > which the kernel will need to deploy to be able to guess which page-size it > should use for each file. > > Because without such heuristics, none of this new stuff which you're > proposing would ever get used by 90% of apps on 90% of machines. In the patchset V3 one f.e. simply formats a volume by specifying the desired blocksize. If one gets into trouble with fsck and other slowdown associated with large file I/O then they are going to be quite fast to format a partition with larger blocksize. Its a know technology in many Unixes. The approach essentially gives one freedom to choose a page size. This is a tradeoff between desired speed, expected file sizes, filesystem behavior and acceptable fragmentation overhead. If we do this approach then I think we will see the mkfs.XXX tools to automatically make intelligent choices on which page size to use. They are all stuck at 4k at the moment. > > Of course there is. The seeks are reduced since there are an factor > > of 16 less metadata blocks. fsck does not read files. It just reads > > metadata structures. And the larger contiguous areas the faster. > > Some metadata is contiguous: inode tables, some directories (if they got > lucky), bitmap tables. But fsck surely reads them in a single swoop > anyway, so there's no gain there. The metadata needs to refer to 1/16th of the earlier pages that need to be tracked. metadata is shrunk significantly. > Other metadata (indirect blocks) are 100% discontiguous, and reading those > with a 64k IO into 64k of memory is completely dumb. The effect of a larger page size is that the filesystem will place more meta data into a single page instead of spreading it out. Reading a mass of meta data with a 64k read is an intelligent choice to make in particular if there is a large series of such reads. - 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 6/7] PM: Remove power_state.event checks from suspend core code
On Fri, 15 Jun 2007, Rafael J. Wysocki wrote: > On Thursday, 14 June 2007 16:21, David Brownell wrote: > > On Wednesday 13 June 2007, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > The suspend routines should be called for every device during a system > > > sleep > > > transition, regardless of the device's state, so that drivers can regard > > > these > > > method calls as notifications that the system is about to go to sleep, > > > rather > > > than as directives to put their devices into the 'off' state. > > > > Did you audit all the drivers to make sure this won't break things? > > Like for example through inappropriate pci_save_state() calls? > > I did, but not very carefully. > > > I'd really expect this patch would break things... > > Well, in that case I'll have a closer look at them. It might not be all that bad. One would expect problems to occur only in cases where devices were already suspended at the time of a system sleep transition. Since relatively few drivers currently implement runtime PM -- and those that do are likely to be more careful about not blindly making state changes -- there might not be too much trouble. Alan Stern - 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 for 2.6.22-rc4 - resend] kbuild: fix sh64 section mismatch problems
On Thu, Jun 14, 2007 at 06:53:40PM -0700, Linus Torvalds wrote: > On Fri, 15 Jun 2007, Paul Mundt wrote: > > > > > > > > Please pull this single patch from: > > > > > > > > git://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fix.git > > > > > > And another re-request. > > I get irritated when people send me multiple requests with bogus URL's. > > At least get the URL right. > > Linus Oops, that should be: master.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild-fix.git - 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
On Thursday 14 June 2007 15:49:13 Daniel Hazelton wrote: > > I'm not saying it legally clear the other way round, my statement was > > an answer to Daniel's emails claiming it was clear what such companies > > do was legal. > > I'm sorry if I gave anyone that impression. My point was that it would be > pointless to argue the case in the US because here it really is, > usually , "buy the best justice for the money". Or do what BusyBox and uClibc did (on the advice of Pamela Jones of Groklaw) and sign up with the the Software Freedom Law Center so they can enforce your copyrights for you. Didn't cost us a dime, and they were ok with GPLv2 without the "or later" clause... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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
On Thursday 14 June 2007 18:45:07 Alexandre Oliva wrote: > On Jun 14, 2007, "Chris Friesen" <[EMAIL PROTECTED]> wrote: > > Alexandre Oliva wrote: > >> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >>> *AND* the GPL has never been about making the source available to > >>> everyone - just to those that get the binaries. > >> > >> Exactly. Not even to the upstream distributor. That's where Linus' > >> theory of tit-for-tat falls apart. > > > > Nope. > > > > case 1: Upstream provides source, tivo modifies and distributes it > > (to their customers). > > > > case 2: tivo provides source, end user modifies and distributes it > > (possibly to their customers, maybe to friends, possibly even to > > upstream). > > > > See? Tit for tat. > > case 2': tivo provides source, end user tries to improve it, realizes > the hardware won't let him and gives up Faulty logic. The hardware doesn't *restrict* you from *MODIFYING* any fscking thing. DRH > > Where's the payback, or the payforward? > > And then, tit-for-tat is about equivalent retaliation, an eye for an > eye. Where's the retaliation here? > > If GPLv2 were tit-for-tat, if someone invents artifices to prevent the > user from making the changes the user wants on the software, wouldn't > it be "equivalent retaliation" to prevent the perpetrator from making > the changes it wants on the software? -- 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
On Thursday 14 June 2007 18:35:01 Alexandre Oliva wrote: > On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > I want to be able to use other peoples improvements. If they release > > improved versions of the software I started, I want to be able to merge > > those improvements if I want to. > > Hmm... So, if someone takes one of the many GPLv2+ contributions and > makes improvements under GPLv3+, you're going to make an effort to > accept them, rather than rejecting them because they're under the > GPLv3? Doesn't matter at all. GPLv3 requires that any project incorporating GPLv3 code be licensed under the GPLv3. Linus is, as he has shown, intelligent enough to know this. The *second* he actually accepted GPLv3 code into the kernel it would either be "change the license or start getting lawsuits for breach of the terms of the GPLv3". > > Your *IDIOTIC* suggestion is explicitly against the whole POINT! By > > saying that I shouldn't accept contributions like that, you just > > INVALIDATED the whole point of the license in the first place! > > I understand. I assumed you had some trust that people would abide by > your wish to permit TiVOization, and that authors of modifications > were entitled to make "whatever restrictions they wanted" on their > code. > > Pardon me if I think your position is at least somewhat incoherent. > Can you help me make sense of it? You are making a distinction between "part" and "whole". When separate from the kernel the code can have whatever restrictions the creator pleases. If he has said "I want this in the "official" Linux Kernel" (ie: I want this in Linus' Linux Kernel source tree) then the creator of the code has stated a willingness to abide by Linus' decision about the whole work. It's a moot point, though. The Linux Kernel is licensed under GPLv2, which means that *all* code in it has to be under the same license *and* that no code in it can have any restrictions *NOT* in the 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: [git pull for 2.6.22-rc4 - resend] kbuild: fix sh64 section mismatch problems
On Fri, 15 Jun 2007, Paul Mundt wrote: > > > > > > Please pull this single patch from: > > > git://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fix.git > > > > And another re-request. I get irritated when people send me multiple requests with bogus URL's. At least get the URL right. 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
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > It's an addiction. I'm not proud. I guess this makes it two of us :-( > They were basically forced to add lockdown by the content vendors. They can do that. They will still be able to do that with v3. All they have to do is to throw away the keys that enable themselves to modify the code further. > For example, I'd rather have some GPLv2'd DVD player software that does > *not* come with a de-css key libdvdread and libdvdcss are separate packages. > So the GPLv3 actually _hinders_ people who might otherwise help the > community from helping, by making the license so strict that those people > (who are nice people, but have their options limited by stupid laws and > regulations) cannot use the GPLv3. Just like v2 hinders their many customers. Are you so sure v2 is better in this regard? -- 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
On 06/14/2007 05:39 PM, Alexandre Oliva wrote: On Jun 14, 2007, Florin Malita <[EMAIL PROTECTED]> wrote: No, it's not: replacing does not create derivative work. Modification does. Thanks. Good point. This convinces me that this doesn't work as a legal argument under copyright. I still stand by my understanding that this restriction violates the spirit of the license. But since this elusive "spirit" is subject to everybody's interpretation of the preamble, you must surely admit that it remains just a matter of opinion ;) It seems pretty obvious that the only right Tivo is withholding is the right to install new versions on the device Actually, no. They withhold the right to run versions that they don't authorize themselves. On that particular piece of hw, yes. But who's granted you the right to *run* your modified copy *there* in the first place? GPLv2 explicitly steers clear of anything "other than copying, distribution and modification". Back when GPLv2 was written, the right to run was never considered an issue. It was taken for granted, because copyright didn't control that in the US (it does in Brazil), and nobody had thought of technical measures to stop people from running modified copies of software. At least nobody involved in GPLv2, AFAIK. The landscape has changed, and GPLv3 is meant to defend this freedom that was taken for granted. Then you agree that GPLv2 does not protect your freedom (taken for granted) to run a modified copy on any particular device, or am I misreading? What do you think you do when you save a modified source file in your editor? Don't skip the part where the in-memory version started as an exact copy of the original being replaced. Notice the difference? ;) Sorry, I really don't follow. Both versions of the kernel binary also started from a common source ancestor. Were you trying to make a distinction on these grounds? Exactly: they have a common ancestor, they are both derived from it. But there's no ancestry relationship *between* them (unlike your edited file example) so you cannot argue that one is a modification of the other. Hence, Tivo is not really *modifying* the copies it distributes with the device - they're *installing* brand new copies instead. They also choose not to offer everybody the same privilege :-| Does this go against the intent of the GPLv2 authors? Probably. Does it go against the letter of GPLv2? Apparently not. Does it go against your/some people's interpretation of the GPL "spirit"? Obviously. Does it go against everybody's interpretation? Obviously not. --- fm - 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
On Thursday 14 June 2007 19:18:12 Carlo Wood wrote: > On Thu, Jun 14, 2007 at 01:09:46PM -0700, Linus Torvalds wrote: > > I'm the original author, and I selected the GPLv2 for Linux. > > [...] > > > I'm not going to bother discussing this any more. You don't seem to > > respect my right to choose the license for my own code. > > This is the main reason I dislike GPLwhatever: there is no notion > of "orginal author". You might have written 99% of the code, that > doesn't matter. You have no rights whatsoever once you release > something under the GPL (no more than ANYOne else). You mean if the original author gets hit by a bus and their estate gets sold to SCO they can't revoke our rights to the code? How is this a down side? And you do have more rights than anyone else: as the copyright holder you can issue other licenses, and you have standing to sue to enforce the code. (If nobody else has a copyright on the code, they don't have standing to sue to enforce the license terms.) (Right now, nobody EXCEPT the FSF has the right to sue somebody to enforce the license terms on something like gcc. Do you find that a comforting thought?) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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 for 2.6.22-rc4 - resend] kbuild: fix sh64 section mismatch problems
On Wed, Jun 13, 2007 at 08:15:07AM +0200, Sam Ravnborg wrote: > Resend of the below pull request. > > Sam > > On Mon, Jun 11, 2007 at 09:55:52PM +0200, Sam Ravnborg wrote: > > Hi Linus. > > > > Please apply following 2 liners fix. > > It will fix a lot of false section mismatch warnings on sh64 and > > Paul asked to have in included before the relase hit the street. > > > > Please pull this single patch from: > > git://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fix.git > > And another re-request. - 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
On Thursday 14 June 2007 18:24:55 David Woodhouse wrote: > On Wed, 2007-06-13 at 21:29 -0400, Daniel Hazelton wrote: > > 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") > > Who cares about whether the module is a derivative work? That's only > relevant when you distribute the module as a separate work. When you > ship a combined work including both the kernel and the module in > question, it's a _whole_ lot easier to interpret the GPL. Agreed. I said I wasn't going to argue about it because there *ARE* distinctions that the law makes and the GPL ignores. You can't have it both ways. If the module is distributed *with* the kernel *SOURCE* then it doesn't matter if it's a derivative work or not, because it becomes covered by the kernels license. If it's distributed with the kernel *binaries* then it is covered by its own license. In that case the only reason you'd have a right to the source is if the module is considered a "derivative work". 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
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Thursday 14 June 2007 14:35:29 Alexandre Oliva wrote: > >> > So let's look at that "section 6" that you talk about, and quote the >> > relevant parts, will we: >> > >> >You may not impose any further restrictions on the recipients' >> >exercise of the rights granted herein. >> > >> > and then let's look at Red Hat sending me a CD-ROM or a DVD. >> > >> > Now, Red Hat clearly *did* "further restrict" my rights as it pertains TO >> > THAT COPY ON THE CD-ROM! I cannot change it! Waa waa waa! I'll sue your >> > sorry ass off! >> >> Red Hat is not stopping you from making changes. The media is, and >> that's not something Red Hat can control. > TiVO isn't stopping you from making changes - the *media* is. TiVO made it so, that's the difference. I'll give you that it's not so much about making changes per se, or even installing them, as it is about running the modified versions for any purpose. >> Compare this with the TiVO. TiVO *designs* the thing such that it can >> still make changes, but customers can't. >> That's the difference. > No, it isn't. Look at any motherboard. The Bios on the last three or four > motherboards I've purchased check for a digital signature on the Bios > updates. The motherboard manufacturer can make changes, but the customer > can't. Is there any difference? Nope. Is the BIOS code under the GPL? > The fact is that claiming it was "the spirit" doesn't matter at all > - this isn't philosophy you're arguing, its *LAW*, and in law, if it > isn't clearly spelled out, it doesn't exist. That's exactly what makes for the difference between the spirit and the precise legal terms, and why GPLv3 is fixing these divergences. > And where does it say that you even have the right to run the "work based on > the Program", or even a self-compiled copy of the "verbatim copy of the code" > on any given piece of hardware? It doesn't. The license can't demand the software, or modified versions thereof, to run. The only thing it can demand is that licensees don't impose restrictions on others' abilities to do so. >> > But by "the software", the license is not talking about a particular >> > *copy* of the software, it's talking about the software IN THE ABSTRACT. >> >> Please read it again. > Done. 2. You may modify your copy or copies of the Program or any portion of it > If this has been the "intent and spirit" of the license from the > beginning, it should be there somewhere. I think you're missing what 'spirit' means. It's guidance, it's not the legal terms. And it's precisely because the implementation (the legal terms) failed to meet that design (the spirit, encoded in the preamble) that the license needs patching. -- 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: [PATCH] cdrom_sysctl_info fix
dave young wrote: Hi, Better to use the email address in the MAINTAINERS file than the one in the driver source file. Really? I searched the list, found axboe use the address [EMAIL PROTECTED], same as what andrew said. does the MAINTAINERS file be updated? Could be, but that's up to Jens. -- ~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 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Thu, 14 Jun 2007 17:45:43 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Thu, 14 Jun 2007, Andrew Morton wrote: > > > > I do not think that the 100% users will do kernel compiles all day like > > > we do. We likely would prefer 4k page size for our small text files. > > > > There are many, many applications which use small files. > > There is no problem with them using 4k page size concurrently to a higher > page size for other files. There will be files which should use 64k but which instead end up using 4k. There will be files which should use 4k but which instead end up using 64k. Because determining which size to use requires either operator intervention or kernel heuristics, both of which will be highly unreliable. It's better to just make 4k pages go faster. > > > I never understood the point of that exercise. If you have variable page > > > size then the 64k page size can be used specific to files that benefit > > > from it. Typically usage scenarios are video audio streaming I/O, large > > > picture files, large documents with embedded images. These are the major > > > usage scenarioes today and we suck the. Our DVD/CD subsystems are > > > currently not capable of directly reading from these devices into the > > > page > > > cache since they do not do I/O in 4k chunks. > > > > So with sufficient magical kernel heuristics or operator intervention, some > > people will gain some benefit from 64k pagesize. Most people with most > > workloads will remain where they are: shoving zillions of physically > > discontiguous pages into fixed-size sg lists. > > Magical? There is nothing magical about doing transfers in the size that > is supported by a device. That is good sense. By magical heuristics I'm referring to the (required) tricks and guesses which the kernel will need to deploy to be able to guess which page-size it should use for each file. Because without such heuristics, none of this new stuff which you're proposing would ever get used by 90% of apps on 90% of machines. > > > Every 64k block contains more information and the number of pages managed > > > is reduced by a factor of 16. Less seeks , less tlb pressure , less > > > reads, > > > more cpu cache and cpu cache prefetch friendly behavior. > > > > argh. Everything you say is just wrong. A fsck involves zillions of > > discontiguous small reads. It is largely seek-bound, so there is no > > benefit to be had here. Your proposed change will introduce regressions by > > causing larger amounts of physical reading and large amounts of memory > > consumption. > > Of course there is. The seeks are reduced since there are an factor > of 16 less metadata blocks. fsck does not read files. It just reads > metadata structures. And the larger contiguous areas the faster. Some metadata is contiguous: inode tables, some directories (if they got lucky), bitmap tables. But fsck surely reads them in a single swoop anyway, so there's no gain there. Other metadata (indirect blocks) are 100% discontiguous, and reading those with a 64k IO into 64k of memory is completely dumb. And yes, I'm referring to the 90% case again. The one we want to optimise for. - 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
On Thursday 14 June 2007 17:39:32 Alexandre Oliva wrote: > > And since the specific implementation involves creating a derived work > of the GPLed kernel (the signature, or the signed image, or what have > you) and refraining from providing the corresponding sources to that > derived work (the key and the signature "build scripts"), I still > think this specific case is a violation of the letter of the GPLv2, > even if the FSF doesn't take this position. Not entirely correct. If TiVO is making a change to the binary to include the signature, then it *could* be considered a derivative work. If the signature is stored in another place - say a bit of Flash or a separate file on the disc - then there is no way for it to be considered a derivative work. (Under US law, IIRC and I I've interpreted it (and the related cases) properly then the change would have to be to the source of the program for it to be considered a "derivative". But, as you say often and I should make clear myself, IANAL) > > > It seems pretty obvious that the only right Tivo is withholding is the > > right to install new versions on the device > > Actually, no. They withhold the right to run versions that they don't > authorize themselves. And this is relevant to a software license in which way? In particular how is this relevant to the GPL, which has always *only* guaranteed access to the source if you have access to the binary, the right to distribute your own versions and the right to modify the code. Since the "right to run code" was never guaranteed it *cannot* be a violation. It might be in conflict with what RMS intended when he wrote the first version of the GPL and in conflict with the intent of the people that contributed to GPLv2 but that doesn't matter. However, I will not use (or recommend) the GPLv3 in its current form because I feel it makes unnecessary restrictions. The fact that you have to "allow additional rights" to make it equal to the GPLv2 makes a functional (and spiritual) difference to me. (Why? Because I'm opposed to "In order to protect freedom X we have to restrict freedom Y. Its happening in the US *RIGHT* *NOW* and I have been doing what I can to fight that. Now the same faulty logic is being applied by the FSF with GPLv3) > Back when GPLv2 was written, the right to run was never considered an > issue. It was taken for granted, because copyright didn't control > that in the US (it does in Brazil), and nobody had thought of > technical measures to stop people from running modified copies of > software. At least nobody involved in GPLv2, AFAIK. Why isn't it in the US? Because the binary form of a program does not and cannot have a separate copyright than the source code. Since it is the *SOURCE* that is actually copyright (mechanical translation cannot create a new work, only a new form of an already copyrighted work) guaranteeing the "right to run" is pointless. And you are wrong about that "Nobody thought of it" thing - what you mean is that "Nobody that had a hand in drafting and ratifying the GPLv2 thought of it". The "NSA Guidelines for Trusted Systems" (aka "The Orange Book") talks about methods of preventing the execution of code. What you and the rest of the FSF is doing in response to "tivoization" is saying "we don't care if it wasn't designed to do X, we want to be able to make it do that anyway *AND* the manufacturer has to help us do it". There is no legal way for you to make that demand of a hardware manufacturer. Instead you've gone with the only legal recourse - saying "If you want to use my copyrighted work under license X, you have to do Y". I have no problem with that, and if the FSF wants that, it's fine by me. But, as I said, I could care less where and/or if something I release under the GPL is used. This makes the GPLv2 perfect for me. > The landscape has changed, and GPLv3 is meant to defend this freedom > that was taken for granted. > > > they never do (and really never could) "modify" the physical copy on > > your device (which is your main argument). > > Qualifying it as the main argument is a bit of an exaggeration. I > have a number of different arguments. The one about incomplete > sources is the most solid IMHO. Yes, it is. But your argument about the TiVO is "they can modify the copy on it but I can't". Hence it is your main argument. And remember, replace != modify. > >> What do you think you do when you save a modified source file in your > >> editor? > > > > Don't skip the part where the in-memory version started as an exact > > copy of the original being replaced. Notice the difference? ;) > > Sorry, I really don't follow. Both versions of the kernel binary also > started from a common source ancestor. Were you trying to make a > distinction on these grounds? No. He was making a distinction that I have seen made a number of times. That is, a copy of a copyright work in a computers RAM is a *distinct* copy, separate
Re: [-mm patch] make fs/buffer.c:cont_expand_zero() static
Hi Adrian,
Thanks for doing these, but can we hold them off for now?
Thanks,
Nick
On Fri, Jun 15, 2007 at 12:15:45AM +0200, Adrian Bunk wrote:
> cont_expand_zero() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.22-rc4-mm2/fs/buffer.c.old 2007-06-14 01:51:08.0
> +0200
> +++ linux-2.6.22-rc4-mm2/fs/buffer.c 2007-06-14 01:51:42.0 +0200
> @@ -2181,8 +2181,8 @@
> return err;
> }
>
> -int cont_expand_zero(struct file *file, struct address_space *mapping,
> - loff_t pos, loff_t *bytes)
> +static int cont_expand_zero(struct file *file, struct address_space *mapping,
> + loff_t pos, loff_t *bytes)
> {
> struct inode *inode = mapping->host;
> unsigned blocksize = 1 << inode->i_blkbits;
-
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: [-mm patch] fs/reiserfs/: cleanups
On Fri, Jun 15, 2007 at 12:16:28AM +0200, Adrian Bunk wrote:
> This patch contains the following cleanups:
> - remove the following no longer used functions:
> - bitmap.c: reiserfs_claim_blocks_to_be_allocated()
> - bitmap.c: reiserfs_release_claimed_blocks()
> - bitmap.c: reiserfs_can_fit_pages()
> - make the following functions static:
> - inode.c: restart_transaction()
> - journal.c: reiserfs_async_progress_wait()
If Vladimir acks this one then it's obviously fine by me.
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> fs/reiserfs/bitmap.c| 57
> fs/reiserfs/inode.c |4 +-
> fs/reiserfs/journal.c |3 +
> include/linux/reiserfs_fs.h |7
> 4 files changed, 4 insertions(+), 67 deletions(-)
>
> --- linux-2.6.22-rc4-mm2/include/linux/reiserfs_fs.h.old 2007-06-14
> 02:08:17.0 +0200
> +++ linux-2.6.22-rc4-mm2/include/linux/reiserfs_fs.h 2007-06-14
> 02:11:20.0 +0200
> @@ -1701,8 +1701,6 @@
> return th->t_blocks_allocated - th->t_blocks_logged;
> }
>
> -int reiserfs_async_progress_wait(struct super_block *s);
> -
> struct reiserfs_transaction_handle *reiserfs_persistent_transaction(struct
> super_block
> *,
> @@ -1857,8 +1855,6 @@
> #define GET_BLOCK_NO_IMUX 8 /* i_mutex is not held, don't
> preallocate */
> #define GET_BLOCK_NO_DANGLE 16 /* don't leave any transactions running
> */
>
> -int restart_transaction(struct reiserfs_transaction_handle *th,
> - struct inode *inode, struct treepath *path);
> void reiserfs_read_locked_inode(struct inode *inode,
> struct reiserfs_iget_args *args);
> int reiserfs_find_actor(struct inode *inode, void *p);
> @@ -2135,9 +2131,6 @@
> struct inode *inode);
> void reiserfs_discard_all_prealloc(struct reiserfs_transaction_handle *th);
> #endif
> -void reiserfs_claim_blocks_to_be_allocated(struct super_block *sb, int
> blocks);
> -void reiserfs_release_claimed_blocks(struct super_block *sb, int blocks);
> -int reiserfs_can_fit_pages(struct super_block *sb);
>
> /* hashes.c */
> __u32 keyed_hash(const signed char *msg, int len);
> --- linux-2.6.22-rc4-mm2/fs/reiserfs/bitmap.c.old 2007-06-14
> 02:08:45.0 +0200
> +++ linux-2.6.22-rc4-mm2/fs/reiserfs/bitmap.c 2007-06-14 02:09:59.0
> +0200
> @@ -1201,63 +1201,6 @@
> return ret;
> }
>
> -/* These 2 functions are here to provide blocks reservation to the rest of
> kernel */
> -/* Reserve @blocks amount of blocks in fs pointed by @sb. Caller must make
> sure
> - there are actually this much blocks on the FS available */
> -void reiserfs_claim_blocks_to_be_allocated(struct super_block *sb, /*
> super block of
> -
> filesystem where
> -
> blocks should be
> -
> reserved */
> -int blocks /* How much to reserve
> */
> -)
> -{
> -
> - /* Fast case, if reservation is zero - exit immediately. */
> - if (!blocks)
> - return;
> -
> - spin_lock(_SB(sb)->bitmap_lock);
> - REISERFS_SB(sb)->reserved_blocks += blocks;
> - spin_unlock(_SB(sb)->bitmap_lock);
> -}
> -
> -/* Unreserve @blocks amount of blocks in fs pointed by @sb */
> -void reiserfs_release_claimed_blocks(struct super_block *sb, /* super block
> of
> -filesystem
> where
> -blocks
> should be
> -reserved */
> - int blocks /* How much to unreserve */
> -)
> -{
> -
> - /* Fast case, if unreservation is zero - exit immediately. */
> - if (!blocks)
> - return;
> -
> - spin_lock(_SB(sb)->bitmap_lock);
> - REISERFS_SB(sb)->reserved_blocks -= blocks;
> - spin_unlock(_SB(sb)->bitmap_lock);
> - RFALSE(REISERFS_SB(sb)->reserved_blocks < 0,
> -"amount of blocks reserved became zero?");
> -}
> -
> -/* This function estimates how much pages we will be able to write to FS
> - used for reiserfs_file_write() purposes for now. */
> -int reiserfs_can_fit_pages(struct super_block *sb/* superblock of
> filesystem
> -to estimate space */
> )
> -{
> - int space;
> -
> - spin_lock(_SB(sb)->bitmap_lock);
> - space =
> - (SB_FREE_BLOCKS(sb) -
> - REISERFS_SB(sb)->reserved_blocks) >> (PAGE_CACHE_SHIFT -
> -
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 14, 2007, Rob Landley <[EMAIL PROTECTED]> wrote: > Now the FSF is coming along and being Darth Vader: "I am altering > the bargain. Pray I don't alter it any further." 1) it can't possibly do that. the Linux license is something that only the Linux developers can decide. 2) I don't know how the FSF is approaching the Linux developers, but what I've been personally trying to do in this infinite thread was mainly to set the record straight that v3 did not change the spirit of the license, like some have claimed. 3) Another thing I've tried to do was to try to figure out why Linux developers seem to consider v2 better than v3 for their own goals. I must admit I failed. The presented reasons don't seem to distinguish v2 from v3 to me, or rather make v3 sound better. It's disappointing that I took so much of everyone's time without achieving any of my goals. I hope it was at least useful or enlightening to some. I'll now try to step out of the discussion, but I guess I'm just as addicted to flames. I don't see that it's getting anywhere, and I don't particularly enjoy the name calling. And then, I was politely invited to go away... -- 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
On Thu, Jun 14, 2007 at 09:20:35PM -0400, Rob Landley wrote: > Why do you keep saying "upgraded" to GPLv3? How is it an improvement to move > from a small, simple, elegant, and tested implementation to something that's > more complicated, less elegant, less coherent, totally untested, and full of > numerous special cases? Ahhh, but so much more entreprisy. I never had realized before that the DailyWTF applied to licenses too. OG. - 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: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig wrote: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. TOMOYO Linux is a pathname-based MAC, that is true. But what that patch aimed for was sharing the idea of having Linux kernel to keep "process invocation history" information for each process. In that sense, TOMOYO Linux is just a sample implementation. Please take a look at the following message: http://lkml.org/lkml/2007/6/13/58 Best regards, 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: [TOMOYO 0/9] TOMOYO Linux security module.
Uh, can we get some docs? Like how this is better than selinux, what it does, how is it configured...? Pavel That message and its children were meant to be put under the bellow message. Sorry for the confusion. http://lkml.org/lkml/2007/6/13/58 Kentaro Takeda - 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 <[EMAIL PROTECTED]> wrote: > > the GPLv2 license says no such thing, and you seem to be mighty > > confused about how software licenses work. > > There is no such thing as a software licence. It is a copyright > licence. a "software license" is a common shortcut for "copyright license for copies of software works". It's a commonly used phrase. In fact it is used by the FSF itself too: http://www.fsf.org/licensing/essays/free-sw.html "To decide whether a specific software license qualifies as a free software license, we judge it based on these criteria to determine whether it fits their spirit as well as the precise words." > > the GPL applies to software. It is a software license. > > You can GPL a new graphical logo you painted on your toilet seat, you > can GPL hardware designs. It might not be a good licence for either > but it is a valid licence. yeah - the GPL can be applied to most types of works recognized by copyright law. > > the Tivo box is a piece of hardware. > > A Tivo box is a collection of literary works protected by copyright, > designs protected by design patents and copyright, names and logos > protected by trademarks, functionalities protected by patents and many > more things. These are the things that restrict what I may do with it > and how I may treat it. The collection of bits of metal and sand > aren't really of relevance in terms of licencing. If you are into technicalities then you fail to achieve that "rigorous base" by a wide margin. The Tivo box is not "a collection of literary works", it is a piece of matter, that also happens to contain fixated copies of literary (and other) works. The Tivo box is just one copy of those works - it is not "a collection of literary works". (Only if there was just a single Tivo box on the planet then could that box itself be meaningfully called a collection of works - a single and unique "master copy" of a work can be called the work itself.) and that distinction, although fine, is very important. Look at GPLv2 section 0: " 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. " the work is not the copy! The work is a more 'abstract' entity. The word "copyright" comes straight from that: the right to create specific copies of the work. And that's another reason why it's nonsensical to suggest that somehow the GPLv2 gives us the right to influence the hardware environment that the copy of the kernel got fixated into. We dont. ( unless that hardware environment too is a copy of a GPL-ed work or it is a copy of a work that is a modification of or derives from a GPL-ed work - but in the Tivo case it isnt. It's a collection of copies of works and derivation does not "jump" from the harddisk to the hardware. ) More down the technicalities road: the Tivo box also contains many items that are not copies of works protected by copyright: common types of screws that are not original forms of expression that are creative enough enough to gain copyright protection. Or numbers painted on various places. Or computer-originated random output. Copies of works that have entered the public domain and thus are not under the scope of copyright protection. Neither is the Tivo box "collection of functionalities protected by patents", if then it is an embodiment of a method and apparatus, which invention is under patent protection (there are other types of patents as well), or which invention might not be under patent protection but have a patent application pending. (which might or might not issue at the end of the patent application process.) > > a disk is put into it with software copied to it already: a bootloader, > > a Linux kernel plus a handful of applications. The free software bits > > are available for download. > > Except the keys - which may nor may not be required depending upon how a > court (not a mailing list) interprets the phrases > > "The source code for a work means the preferred form of the work for > making modifications to it" i think it is clear what is intended with this section: that for example using automatic tools to strip out comments and obfuscating the source code does not fly, because what matters is the _form of the software_ the developer usually makes his modifications under. So this in essence defines the scope of the actual source code that must be made available so that it works on a general purpose computer, not the specific hardware environment under which the developer operates. so i believe it is a ... fairly creative bending of the wording of this section to attempt to extend it to the hardware environment. You dont get my ssh keys either [*] that i use on my test-boxes, and those test boxes are very much part of the preferred way for me to
Re: raid1 with nbd member hangs MD on SLES10 and RHEL5
On 6/14/07, Paul Clements <[EMAIL PROTECTED]> wrote: Mike Snitzer wrote: > On 6/14/07, Paul Clements <[EMAIL PROTECTED]> wrote: >> Mike Snitzer wrote: >> >> > Here are the steps to reproduce reliably on SLES10 SP1: >> > 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 >> >> That's working as designed. NBD works over TCP. You're going to have to >> wait for TCP to time out before an error occurs. Until then I/O will >> hang. > > With kernel.org 2.6.15.7 (uni-processor) I've not seen NBD hang in the > kernel like I am with RHEL5 and SLES10. This hang (tcp timeout) is > indefinite oh RHEL5 and ~5min on SLES10. > > Should/can I be playing with TCP timeout values? Why was this not a > concern with kernel.org 2.6.15.7; I was able to "feel" the nbd > connection break immediately; no MD superblock update hangs, no > longwinded (or indefinite) TCP timeout. I don't know. I've never seen nbd immediately start returning I/O errors. Perhaps something was different about the configuration? If the other other machine rebooted quickly, for instance, you'd get a connection reset, which would kill the nbd connection. OK, I'll retest the 2.6.15.7 setup. As for SLES10 and RHEL5, I've been leaving the remote server powered off. As such I'm at the full mercy of the TCP timeout. It is odd that RHEL5 has been hanging indefinitely but I'll dig deeper on that once I come to terms with how kernel.org and SLES10 behaves. I'll update with my findings for completeness. Thanks for your insight! Mike - 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
On Jun 14, 2007, Bongani Hlope <[EMAIL PROTECTED]> wrote: > On Thursday 14 June 2007 21:32:08 Alexandre Oliva wrote: >> On Jun 14, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote: >> > They let you have the code and make changes to it, >> >> Not to the software installed in the device. > So now you want access to all the software that is installed in > their device? What's under the GPL. > If you buy one of Google's Search Appliance, are you expecting to > allow you to make changes to the software that is installed on that > device? Arguably, if I purchased the device, I ought to be entitled to make changes to it, yes. But that's a distraction I'd rather not get into ATM. > They then make the all the changes to the Linux Kernel available to > their end users under the same terms that they got from the Linux > kernel developers. > What freedom did they take away? They prevent the user from installing and running modified versions of the program on the box, while they can still do it themselves on the same box. I guess I must have repeated this at least a dozen times in this thread, so I'll just refrain from repeating this point from now on. -- 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
On Thursday 14 June 2007 19:20:19 Alexandre Oliva wrote: > > But not within the confines of the Linux kernel. Within the Linux kernel, > > the GPLv2 rules - and "GPLv2+" becomes just "GPLv2", since the GPLv3 is > > not compatible with v2. > > I understand this very well. You'd have to get the kernel upgraded to > GPLv3 in order to accept the contribution. Why do you keep saying "upgraded" to GPLv3? How is it an improvement to move from a small, simple, elegant, and tested implementation to something that's more complicated, less elegant, less coherent, totally untested, and full of numerous special cases? Bumping a version number is not in indicator of quality, and spending over twice as much text to express the same legal principles is not an improvement. So far, you haven't brought up a single reason to use v3 except for a higher version number. (Not that I'm asking you to.) You've just tried to argue that it isn't WORSE than the existing license. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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 wrote: On 6/14/07, Paul Clements <[EMAIL PROTECTED]> wrote: Mike Snitzer wrote: > Here are the steps to reproduce reliably on SLES10 SP1: > 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 That's working as designed. NBD works over TCP. You're going to have to wait for TCP to time out before an error occurs. Until then I/O will hang. With kernel.org 2.6.15.7 (uni-processor) I've not seen NBD hang in the kernel like I am with RHEL5 and SLES10. This hang (tcp timeout) is indefinite oh RHEL5 and ~5min on SLES10. Should/can I be playing with TCP timeout values? Why was this not a concern with kernel.org 2.6.15.7; I was able to "feel" the nbd connection break immediately; no MD superblock update hangs, no longwinded (or indefinite) TCP timeout. I don't know. I've never seen nbd immediately start returning I/O errors. Perhaps something was different about the configuration? If the other other machine rebooted quickly, for instance, you'd get a connection reset, which would kill the nbd connection. -- Paul - 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
On 6/14/07, Paul Clements <[EMAIL PROTECTED]> wrote: Mike Snitzer wrote: > Here are the steps to reproduce reliably on SLES10 SP1: > 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 That's working as designed. NBD works over TCP. You're going to have to wait for TCP to time out before an error occurs. Until then I/O will hang. With kernel.org 2.6.15.7 (uni-processor) I've not seen NBD hang in the kernel like I am with RHEL5 and SLES10. This hang (tcp timeout) is indefinite oh RHEL5 and ~5min on SLES10. Should/can I be playing with TCP timeout values? Why was this not a concern with kernel.org 2.6.15.7; I was able to "feel" the nbd connection break immediately; no MD superblock update hangs, no longwinded (or indefinite) TCP timeout. regards, Mike - 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 wrote: Here are the steps to reproduce reliably on SLES10 SP1: 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 That's working as designed. NBD works over TCP. You're going to have to wait for TCP to time out before an error occurs. Until then I/O will hang. -- Paul - 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/
What do the errors Invalid Phase Change and SYNC Offset Error mean
I have an LSI Logic card attached to a RAID. The RAID occasionally reports SCSI bus resets,although that might be unrelated because I have other units of this RAID with the same complaint, but then this just recently was reported by the card: Jun 14 19:19:51 [kernel] [86189.359115] mptbase: ioc0: LogInfo(0x110b): F/W: Invalid Phase Change which repeated many times and then Jun 14 19:19:53 [kernel] [86191.654386] mptbase: ioc0: LogInfo(0x1104): F/W: SYNC Offset Error which repeated many times There is also some white crud on the card surface, pictured here: http://www.fluxsoft.com/images/lsicrud.jpg Any comments on what might be going on? -- Maurice Volaski, [EMAIL PROTECTED] Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University - 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
On 6/14/07, Paul Clements <[EMAIL PROTECTED]> wrote: Bill Davidsen wrote: > Second, AFAIK nbd hasn't working in a while. I haven't tried it in ages, > but was told it wouldn't work with smp and I kind of lost interest. If > Neil thinks it should work in 2.6.21 or later I'll test it, since I have > a machine which wants a fresh install soon, and is both backed up and > available. Please stop this. nbd is working perfectly fine, AFAIK. I use it every day, and so do 100s of our customers. What exactly is it that not's working? If there's a problem, please send the bug report. Paul, This thread details what I've experienced using MD (raid1) with 2 devices; one being a local scsi device and the other is an NBD device. I've yet to put effort to pinpointing the problem in a kernel.org kernel; however both SLES10 and RHEL5 kernels appear to be hanging in either 1) nbd or 2) the socket layer. Here are the steps to reproduce reliably on SLES10 SP1: 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 To be clear, the MD superblock update hangs indefinitely on RHEL5. But with SLES10 it eventually succeeds after ~5min (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. If you look back in this thread you'll see traces for md0_raid1 for both SLES10 and RHEL5. I hope to try to reproduce this issue on kernel.org 2.6.16.46 (the basis for SLES10). If I can I'll then git bisect back to try to pinpoint the regression; I obviously need to verify that 2.6.16 works in this situation on SMP. Mike - 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 wrote: 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)... What do you mean, nbd should _feel_ an NBD_DISCONNECT ? NBD_DISCONNECT is a manual process, not an automatic one. -- Paul - 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
On Thursday 14 June 2007 17:27:27 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > > > And the companies that produce devices that come with Linux and/or > > other GPL'd software installed and place limits such that only > > people that have purchased that hardware have access to the > > "modified" source running on the device are following the letter, > > and the spirit, of the GPL. > > WAIT, WAIT, THAT'S... :-) > > > Before you start yelling I'm wrong, think about it this way: they > > make the source available to the people that they've given binary > > versions to, and there is nothing stopping one of those people from > > making the source available to the rest of the world. > > The *only* in your sentence betrayed you. > > If they place the limits such that nobody else can access the sources, > they're in violation of the license. Nope. There is *NO* requirement *ANYWHERE* in the GPL, no matter the version, that says you have to *DISTRIBUTE* the source to *ANYONE* except those that you have given a binary to. Go read the licenses. > > If they merely refrain from distributing the sources to others, but > still enable the recipients to do so, this is not a violation of the > license. Exactly what I said. "only the people that have purchased the hardware have access to the modified sources" That is *EXACTLY* what a number of companies have done - Acer (yes, the laptop company) has done that. They sell laptops running Linux, but unless you have purchased one of them you can't download the sources (or even replacement binaries) for the version of linux they put on their machines. (From Acer, that is) However, as I also said, there is nothing stopping one of those people from making those "modified sources" available to the rest of the world. (I have yet to find someone that has done that with the Acer specific stuff, but...) > But then IANAL. > > > *AND* the GPL has never been about making the source available to > > everyone - just to those that get the binaries. > > Exactly. Not even to the upstream distributor. That's where Linus' > theory of tit-for-tat falls apart. Yes, it does. However, the practicality is that there is nothing *stopping* the person upstream from getting a copy of the source and incorporating the modifications they contain in a new version. 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
On Thursday 14 June 2007 17:19:51 Alexandre Oliva wrote: > On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > With GPLv2 and prior there was a simple guarantee that every > > "Licensee" had exactly the same rights. With GPLv3 you are forcing > > your ethics and morals on people - and isn't this exactly what the > > Roman Catholic church did during the Spanish Inquisition? > > I fail to see the distinction you're making between GPLv2 and GPLv3. > AFAICT, with GPLv3, there still is a simple guarantee that every > licensee has exactly the same rights. > > Sure, GPLv3 follows the spirit of the GPLs more strictly than GPLv2 > possibly could. How is that "forcing ethics and morals" any more than > GPLv2 was? Because GPLv2 doesn't enforce limitations on the hardware a GPL'd work can be put on. It doesn't make artificial distinctions between "Commercial", "Industrial" and "User". What it does is *ATTEMPT* to ensure that nobody receiving a copy of a GPL'd work has the same rights as any other person that gets a copy. GPLv3 gives people *additional* rights beyond those. In the "TiVO" case it forces somebody releasing a HW platform to grant *additional* rights if they are going to use software covered by the GPLv3. The reason for forcing the giving of those additional rights is "the FSF and GPLv3 committees think that what TiVO did is 'morally and ethically' wrong, so were are enforcing our morals and ethics". Note that these are the rights that TiVO got from the GPLv2: 1) The ability to make copies of Linux 2) The ability to modify Linux 3) The ability to distribute Linux *NOTE* that those are the rights *GUARANTEED* by the GPL - despite what anyone *WISHES* it to say, or what the "Intent" or "Spirit" of the license may be, those are the only guaranteed rights. In shipping their devices with an "object code" version of Linux on them they exercised their right to perform such a distribution, granted under section 3 of the GPLv2. They made modifications to the Linux so it functioned properly on their devices, as allowed by the GPL. They have made numerous copies of Linux, as allowed by the GPL. And, as required by the GPLv2, they made the source code form of their changes available. In fact, they went beyond the requirements of the GPL (which only requires you make the source available to people you have given an "object code" version to) in making it fully available to the public *AND* in contributing those changes back to Linux. What rights did they give to "downstream" recipients of the "object code" version? *EXACTLY* those they received from the GPLv2. What rights do they have as creators of a *PROPRIETARY* hardware platform: 1) The right to restrict what programs it will run 2) The right to update it as they choose, even if it makes it incompatible with earlier versions Does the GPL *require* them to give up those rights? Version 3 does, but not any earlier version. Why does version 3 do this? Because one or more of the people behind its design and language feel that executing a piece of software on any given hardware platform automatically entitles them to all rights to the hardware that the creator of the hardware has. > > Ah, but I never said I had a GPLv1 program. > > I thought you had a copy of Linux and, per what you'd said before, > there was GPLv1 code in it. I was just trying to make it easy for > you. > > > If GPLv1 is still valid and available I should be able to find a > > copy of it *RIGHT* *NOW* to license a new project if I want to use > > GPLv1 as its license. > > http://www.gnu.org/copyleft/copying-1.0.html Ah, see, I didn't even know it was still there. I hadn't seen it in a complete form anywhere. > >> > And because its a device that connects to their network - and TiVO > >> > isn't a telecommunications company - they have the right to upgrade > >> > and configure the software inside however they want. (In the US at > >> > least) > >> > >> But do they have the right to not pass this right on, under the GPL? > > > > Yes, they do. It isn't a right they have as "copyright holders" - in > > fact, it isn't a part of their rights under the copyright at all. It's a > > part of their rights as the owners of the network. > > How about the "no further restrictions" bit? As applies to the software. The rights that the GPL has (historically) granted are what I stated above. TiVO, and companies like them, are *NOT* imposing any restrictions on rights granted under GPLv2 and prior. Remember, because I'm getting tired of repeating myself: replace != modify > > Never claimed it was less obscure, just that you've usually got a > > board-room filled with middle-aged men that might have problems agreeing > > that it is a clear-cut case. > > > > Yes, but the fact that it would cost money to get the suit dropped is a > > problem. > > Again, how are these arguments against GPLv3? They apply equally to > any other license, including GPLv2. Granted. But GPLv2
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thu, Jun 14, 2007 at 05:25:19PM -0400, Dmitry Torokhov wrote: > On 6/14/07, Dave Neuer <[EMAIL PROTECTED]> wrote: >> On 6/14/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote: >> > Nothing prevents you from taking tivos kernel >> > changes and building your own hardware to run that code on, and as such >> > the spirit of the GPL v2 seems fulfilled. >> >> Oh, come on: you're not serious, right? Something indeed prevents me >> -- the fact that I'm not a hardware manufacturer, I don't have fabs, >> outsource vendors to provide me w/ designs, ASICs, etc. Nor to I have >> the money to pay one-off prices for various components if they're even >> available in batches that small. >> > > So your objection here is that one needs additional resources to do > excersise their rights. Well, what about spending time and money to > get education to be able to do programming work? Being able to > understand C and hardware, etc is also an additional restriction > imposed on an average person. Do you advocate that every copy of GPL > program should be accompanied with an engineer who would explain how > it all works? Yes please. Can she be spunky as well? ta. - 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
On Thu, Jun 14, 2007 at 10:14:21AM -0400, Robin Getz wrote: > - gambling devices - which must have their software certified by various > government agencies - to make sure that the odds are known, and there are no > backdoors, and consumers don't get screwed - the manufacture can not allow > non-certified software to be loaded on it. If these are in a hotel - where > various people live - is that considered "incorporation into a dwelling"? > > Not wanting to start a debate about the morality of being involved in the > gambling industry - (if the statically challenged are giving the government > money to keep my taxes down, I am mostly OK with it) - but I'm not "happy" > thinking that someone can ledgistate restrictions on embedded OS choice, just > because it must be verified by a third party. Why not go really controversial and dive straight in with "voting machines". There's a whole 'nother can of worms. 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: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Thu, 14 Jun 2007, Andrew Morton wrote: > > I do not think that the 100% users will do kernel compiles all day like > > we do. We likely would prefer 4k page size for our small text files. > > There are many, many applications which use small files. There is no problem with them using 4k page size concurrently to a higher page size for other files. > > I never understood the point of that exercise. If you have variable page > > size then the 64k page size can be used specific to files that benefit > > from it. Typically usage scenarios are video audio streaming I/O, large > > picture files, large documents with embedded images. These are the major > > usage scenarioes today and we suck the. Our DVD/CD subsystems are > > currently not capable of directly reading from these devices into the page > > cache since they do not do I/O in 4k chunks. > > So with sufficient magical kernel heuristics or operator intervention, some > people will gain some benefit from 64k pagesize. Most people with most > workloads will remain where they are: shoving zillions of physically > discontiguous pages into fixed-size sg lists. Magical? There is nothing magical about doing transfers in the size that is supported by a device. That is good sense. > > Every 64k block contains more information and the number of pages managed > > is reduced by a factor of 16. Less seeks , less tlb pressure , less reads, > > more cpu cache and cpu cache prefetch friendly behavior. > > argh. Everything you say is just wrong. A fsck involves zillions of > discontiguous small reads. It is largely seek-bound, so there is no > benefit to be had here. Your proposed change will introduce regressions by > causing larger amounts of physical reading and large amounts of memory > consumption. Of course there is. The seeks are reduced since there are an factor of 16 less metadata blocks. fsck does not read files. It just reads metadata structures. And the larger contiguous areas the faster. - 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
On Thursday 14 June 2007 18:24:42 David Schwartz wrote: > I don't know who you are talking to or what you are talking about. I > haven't seen anybody doing what you claim in this thread or anywhere else > and I certainly am not. I'm asking what is the _point_ of the discussion? Linux, the project, is available under GPLv2 only. It is not available under GPLv3, and its maintainers (both Linus, his lieutenants, and numerous other contributors) have expressed an explicit desire NOT to license it as such. So what are the people talking about GPLv3 trying to accomplish? Are they: A) Trying to unanimously change the mind of Linus, his lieutentants, and all the other contributors who have spoken up in favor of GPLv2 only, so that future versions of Linux grew a new license? (Doesn't matter if this new license is GPlv3, MPL, or BSD. It's a new license Linux is not currently distributed under. Bits of Linux are separately distributed under other licenses such as BSD, but Linux is not and won't be any time soon.) B) Proposing the creation of a fork of Linux which identifies and replaces all the code that can't be licensed under GPLv3? C) Moving to another codebase (Solaris? The Hurd) and trying to identify Linux code that can be ported to that other OS under another license? D) Blowing smoke to no actual purpose? Right now, it's looking like D. Is there an E that I'm not seeing? Rob - 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/
