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

[Alexandre Oliva]

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

> Actually you are in error here. You are saying "More home users == More 
> Developers" when the ratio of home users to developers isn't all that high. 
> (small set of facts: "Hacker" == "Developer" (in most cases, where the term, 
> as defined in the Jargon File, can actually be applied), "Home User" * 0.10 
> (ie: 10%) == "Developer" (approximately, and the correlation may be 
> lower). "TiVO" == "Developers" (note the plural - they do employ more than 
> one person for development))

As I wrote in another e-mail, why makes this proportion different for
the other conditions determined by the GPL?

I.e., what is it that makes this particular condition so allegedly
harmful for bringing in more developers and contributions, when
compared with the requirements on passing on source code, licensing
necessary patents, not suing other users over patent infringement in
the software, not invoking anti-circumvention laws, not entering
discriminatory agreements?

> So "TiVO", even though they are walking all over the freedoms you love, means 
> more *guaranteed* developers than the potential pool from the users of their 
> boxes. (the pool of potential developers among the millions of TiVO users is 
> actually miniscule, despite the size of the sample)

> However, you do make a good argument. But when you look at the statistics[1] 
> they don't hold water.

Err...  I have no idea of the actual user base of TiVo, but if it's
really in the millions, and your 10% figure above is right, this makes
for hundreds of thousands of hackers that could be scratching their
itches and improving Linux on TiVo boxes.

How many thousand employees does TiVo have working on Linux?

(I realize a full-time employee is a lot more than a Joe Random
Hacker, but still, I'm keeping a ratio of 100:1 to make up for that)

> PS: I've beaten the addiction!

Good for you!

-- 
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 4/6] ps3: Disk Storage Driver

[Christoph Hellwig]

On Fri, Jun 15, 2007 at 04:08:58PM -0700, David Miller wrote:
> That's not gonna work, it's a totally different model.
> 
> I have a predefined protocol over hypervisor provided "channels" and
> page flipping also done by the hypervisor for the bulk data transfer.
> For the client side I cannot change the hypervisor nor the server
> speaking on the other end.  And when I do write a server I do want
> it to be able to speak to all of the existing clients.
> 
> There's SCSI command pass through as well, as I keep mentioning as
> it's an important reason I don't want to go with any of the non-SCSI
> solutions (other than perhaps ATA) being suggested.

A SCSI pass through is of course perfectly fine.  If you have a separate
block passthrough that has additional magic a separate block driver is
the way to go because it actually is simpler than a scsi driver decoding
command blocks and translating them to deep magic.  The ps3 storage
drivers this thread discussed are a good example for that.  We now
have a very nice and simple disk, scsi and flash chardev driver each
that don't include abstractions layers and cruft.  Combine that with
their initial scsi layer driver that was full of internal dispatches
because each of these device types speaks a completely different command
set.
-
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 4/6] ps3: Disk Storage Driver

[Christoph Hellwig]

On Fri, Jun 15, 2007 at 02:19:17PM -0700, David Miller wrote:
> Another quirk I have to deal with is that under LDOMs you
> can export full disks and also just slices.  So I'll have
> to get down into the partition machinery to support that
> somehow.

What's the problem with that?  Partition machinery is perfectly
fine with just getting a raw disk without a partition table,
and it obviously doesn't care if the raw disk it sees is part
of a partition on the storage server.
-
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 5/6] ps3: ROM Storage Driver

[Christoph Hellwig]

Looks pretty nice.

Some more comments:

 - no need for the BLK_DEV_SR dependency, it should depend on SCSI
   instead (which might be implied by beeing in the scsi menu, don't
   remember that detail)
 - ps3rom_priv should probably be an inline
 - the cmd field in struct ps3rom_private should probably be renamed
   to curr_cmd or something along the line to make sure this is the
   current command we deal with and the driver can only deal with one
   command at a time.
 - The comment in ps3rom_queuecommand should explain why we prefer
   lv1_storage_{read,write} over just sending down the scsi cdb,
   not just that we prefer it.
 - I don't think you need to decode the 6 byte commands at all,
   ATAPI only has the 10 byte variants and you can tell the scsi
   layer not to ever send the 6 byte ones by setting the use_10_for_rw
   flag in ->slave_configure
 - same comment about the free_irq/request_irq pair as in the disk
   driver.
 - please use the new shost_priv helper in scsi-misc for accessing
   the hostdata file in struct Scsi_Host so that the ugly casts
   can go away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexandre Oliva]

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

> The GPLv2 is the one that allows more developers. 

> The GPLv2 is the one that is acceptable to more people. 

Based on my understanding that the anti-tivoization provisions are
*the* objectionable issue about GPLv3 for those of you who dislike
GPLv3, this is circular reasoning:

  anti-tivoization is bad
  => we reject licenses with it
  => there are fewer developers willing to develop with such licenses
  => anti-tivoization is bad



> Face it, the "open source" crowd is the *bigger* crowd.

I really don't know about that.  I can believe it may be so in LKML.

> I haven't really seen a single one. Last I did the statistic, I asked the 
> top ~25-30 kernel developers about their opinion. NOT A SINGLE ONE 
> preferred the GPLv3.

Wow, that's a really big sample among all Free Software and Open
Source developers out there.  And not even a little bit biased at
that.

> So I have actual *numbers* on my side. What do you have, except for a 
> history of not actually understanding my arguments?

Which is worse, not understanding or repeatedly snipping out and
addressing unrelated points?


Let's please try again.

I'll try to keep it simple, since you can't seem to be able to grasp
the entire argument, and keep disregarding essential parts, disputing
unrelated points and jumping to the conclusions that you've disputed
the point I was trying to make.

I'll present it in parts, as an attempt to stop you from making this
mistake, that I'm sure is not intentional.

The first part is in this e-mail.


Dispute this:

non-tivoized hardware => users can scratch their itches => more
contributions from these users

tivoized hardware => users can't scratch their itches => fewer
contributions from these users


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

Re: [patch 05/26] Slab allocators: Cleanup zeroing allocations

[Pekka Enberg]

On 6/19/2007, "Christoph Lameter" <[EMAIL PROTECTED]> wrote:
> IA64

[snip]

> Saved ~500 bytes in text size.
> 
> x86_64:

[snip]

> 200 bytes saved.

Looks good. Thanks Christoph.

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

Re: [patch 4/6] ps3: Disk Storage Driver

[Christoph Hellwig]

On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> 
> Add a Disk Storage Driver for the PS3:
>   - Implemented as a block device driver with a dynamic major
>   - Disk names (and partitions) are of the format ps3d%c(%u)
>   - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
> doesn't support scatter-gather

Looks good to me.  Only nitpicks are:

 - ps3disk_priv should probably be an inline function instead of a macro
 - ps3disk_open is not needed at all and should be removed completely.
 - please remove PS3DISK_MAJOR - and just pass 0 to register_blkdev.
   Passing 0 to get an unassigned dev_t range is the normal convention
   and giving it a suprising symbolic names makes reading the code a
   little harder.  
 - put_disk in ps3disk_remove should be done after you finished tearing
   down the device, not before
 - calling free_irq directly followed by request_irq in ps3disk_probe
   looks rather dumb.  I'd rather move the request_irq out of
   ps3stor_setup into the low-level driver.

-
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.20->2.6.21 - networking dies after random time

[Jarek Poplawski]

On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 13:08:49 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> 
> > On 16-06-2007 23:35, Marcin .lusarz wrote:
> > > hi
> > > after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
> > > strange problem - my _both_ network cards dies after random uptime -
> > > sometimes it's a few minutes, sometimes hours, sometimes it does not
> > > happen for a couple of days...
> > > today it happened for the first time without nvidia module and almost
> > > immediately after system start
> > > 
> > > here is the output of some commands which might help debug this:
...
> > It looks like skge driver enables different device than probbed.
> > Maybe you've something old/wrong about eth0/eth1 in /etc configs?
> 
> More likely it is just user level device renaming. Most distro's
> rename devices (if needed) using udev.

On the other hand it's interesting, why it's not always, and why
sometimes it took so long?

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

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

[Alexandre Oliva]

On Jun 18, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:

> Not really, Tivo could simply sell you a box without any installed
> software.

Yes.

> The actual software is mailed to you on a credit card sized
> ROM when you activate service.

If that's a separate transaction, then yes, I believe it would not be
convered under the terms of GPLv3, but IANAL.  There might be some
catch about intent, and also about contractual obligations in the
hardware sale to provide the software (coupons anyone? :-) or some
such.


But then, that you sell specialized devices with say only MIT-licensed
software shouldn't stop you from selling CD-ROMs with GPLed software,
even if those CD-ROMs could possibly run on that device.


The GPLv3 won't remove every way in which people who want/need to stop
the user from making changes to the software could accomplishing this
(ROM).  It will just make this a bit more inconvenient, such that
vendors that have the option respect users' freedoms, and those that
find it too inconvenient respect the wishes of users who don't want
their software turned non-free.

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

Re: v2.6.21.4-rt11

[Srivatsa Vaddagiri]

On Mon, Jun 18, 2007 at 08:46:03PM -0700, Christoph Lameter wrote:
> @@ -2493,17 +2493,18 @@ static void idle_balance(int this_cpu, s
>   unsigned long next_balance = jiffies + 60 *  HZ;
> 
>   for_each_domain(this_cpu, sd) {
> - if (sd->flags & SD_BALANCE_NEWIDLE) {
> + unsigned long interval;
> +

Do we need a :

if (!(sd->flags & SD_LOAD_BALANCE))
continue;

here?

Otherwise patch look good and fixes the problem Paul observed earlier.

> + if (sd->flags & SD_BALANCE_NEWIDLE)
>   /* If we've pulled tasks over stop searching: */
> - pulled_task = load_balance_newidle(this_cpu,
> - this_rq, sd);
> - if (time_after(next_balance,
> -   sd->last_balance + sd->balance_interval))
> - next_balance = sd->last_balance
> - + sd->balance_interval;
> - if (pulled_task)
> - break;
> - }
> + pulled_task = load_balance_newidle(this_cpu,this_rq, 
> sd);
> +
> + interval = msecs_to_jiffies(sd->balance_interval);


> + if (time_after(next_balance,
> +   sd->last_balance + interval))
> + next_balance = sd->last_balance + interval;
> + if (pulled_task)
> + break;
>   }
>   if (!pulled_task)
>   /*

-- 
Regards,
vatsa
-
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] relay-file-read-start-pos-fix.patch

[Tom Zanussi]

On Tue, 2007-06-19 at 12:43 +0900, Masami Hiramatsu wrote:
> Hi David and Tom,
> 
> David Wilder wrote:
> > This patch fixes a bug in the relay read interface causing the number
> > of consumed bytes to be set incorrectly. 
> 
> Thank you. Your patch fixes one of my concerns.
> However there is another bug I found.
> When I use relayfs with "overwrite" mode, read() still set incorrect
> number of consumed bytes.
> I tried to fix that. Please review it.

Hi,

Could you send more info on how to reproduce the problem you're seeing?
And does this patch fix it?

Thanks,

Tom


> 
> Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
> 
> ---
>  kernel/relay.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.22-rc4-mm2/kernel/relay.c
> ===
> --- linux-2.6.22-rc4-mm2.orig/kernel/relay.c  2007-06-13 20:22:02.0 
> +0900
> +++ linux-2.6.22-rc4-mm2/kernel/relay.c   2007-06-18 23:00:54.0 
> +0900
> @@ -812,7 +812,10 @@
>   }
> 
>   buf->bytes_consumed += bytes_consumed;
> - read_subbuf = read_pos / buf->chan->subbuf_size;
> + if (!read_pos)
> + read_subbuf = buf->subbufs_consumed;
> + else
> + read_subbuf = read_pos / buf->chan->subbuf_size;
>   if (buf->bytes_consumed + buf->padding[read_subbuf] == subbuf_size) {
>   if ((read_subbuf == buf->subbufs_produced % n_subbufs) &&
>   (buf->offset == subbuf_size))
> @@ -841,8 +844,9 @@
>   }
> 
>   if (unlikely(produced - consumed >= n_subbufs)) {
> - consumed = (produced / n_subbufs) * n_subbufs;
> + consumed = produced - n_subbufs + 1;
>   buf->subbufs_consumed = consumed;
> + buf->bytes_consumed = 0;
>   }
>   
>   produced = (produced % n_subbufs) * subbuf_size + buf->offset;
> 
> 
> 
> 


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

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

[Alexandre Oliva]

On Jun 18, 2007, "Kevin Bowling" <[EMAIL PROTECTED]> wrote:

> Legitimate laws and practices require that certain devices not be
> modified by end users.  Therefore TiVo fails and contributions
> cease.

I've never denied this possibility.

But how about all the other devices that are being tivoized that do
NOT require this?

Are people just blind to this possibility?  Or does it really not
exist, and I'm the first who ever though of it?

>> Yes.  This is one option that doesn't bring any benefits to anyone.
>> It maintains the status quo for users and the community, but it loses
>> the ability for the vendor to upgrade, fix or otherwise control the
>> users.  Bad for the vendor.

> And users.  Don't spin the facts.

How is it good that the vendor can downgrade the software behind the
user's back?

Oh, yeah, right, it could upgrade it too.

> You are advocating things which hurt the end user,

Actually, no.  I'm advocating for respect for users' freedoms.
Whoever choose not to do that gets slightly hurt in the process, as an
incentive for respecting users' freedoms.  And yes, when the users'
freedoms are not respected (the cases you mentioned), that's bad for
the user, no doubt.  And bad for the community as well.

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

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

[Alexandre Oliva]

On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Why is the fact that only the root user can load a kernel module not a
> further restriction?

Because the user (under whose control the computer is, be it person or
company) set up the root password herself?

>> > The GPL was never, until GPLv3, about who gets to make
>> > authorization decisions.

>> I can agree with that.  As long as the authorization decisions are not
>> used as means to deprive users' of the freedoms that must not be
>> restricted, they can be whatever the distributor fancies.

> Right, which is the freedom to modify the software. The freedom to get the
> source code. The freedom to use the source code however you want, absent
> legitimate authorization decisions to the contrary.

What makes them lawful, given the "no further restrictions"?

> However, "you can't load your modified sofware on *MY* hardware" is
> not a further restriction.

As long as you didn't hand me the hardware along with the software,
for me to become a user of the software on that hardware, I agree.

>> >> Tivoizers say "hey, you can still modify and run the software, just
>> >> not on *this* hardware".

>> Tivoization is treating the hardware that comes along with the
>> software as if it was different from others.  But it isn't.

> Of course it is. They have the authorization right on that hardware, and
> they don't have that right on my laptop.

Ok, I stand corrected.  They have that right.

However, since they distribute GPLed software along with the hardware,
such that I'd be a user of the software on that hardware, they should
not impose further restrictions on my freedoms that the GPL stands to
defend WRT the GPLed software.  So, they must not use their
authorization right to deny me, the user of the software, in the
hardware that they meant me to use the software, the freedom to adapt
the software for my own needs, and run it for any purpose.

> That would mean it doesn't permit the distribute to state "BTW, you can't
> install, modify or run this software on *OUR* computers that run our
> corporate network".

No, because the user is not becoming a user of the software on their
own computers.  Only in the computer that was shipped along with the
software.

> Don't you see how obviously absurd that is?

Yes, it would be, if it were so.

>> The "no further restrictions" applies equally to all computers.
>> It's not just because you have some control over some particular
>> hardware that you deliver along with the software that you're
>> entitled to use that to limit the user's freedoms.

> I agree. However, that doesn't mean that people who own or control
> particular pieces of hardware can't put authorization barriers that
> prevent you from running whatever software you want on thos pieces
> of hardware.

That's correct, as long as they didn't give me that hardware with
GPLed software in it.  The moment they do, I become recipient and user
of GPLed software in that computer, and they should relinquish their
power to impose restrictions on my exercise of the freedoms WRT that
software.  And there's no reason whatsoever to exclude restrictions
such as those implemented by means of authorization.

>> > Which is a massive departure from the previous GPL spirit which
>> > was about being able to use the software on *ANY* hardware you
>> > controlled, not some special pieces more than others.

>> It doesn't make the sold hardware special.  How come you think it
>> does?

> Because it becomes the only piece of hardware in the entire universe on
> which the GPL gives you the right to run the software. On every other piece
> of hardware, you must obtain that right from whoever owns the right to
> decide what software runs on that hardware.

I see.  Good point.  Agreed.  That hardware is indeed special.  Per
the GPL, it's the only one in which the distributor must NOT exercise
any restraints whatsoever on my exercise of the freedoms.

Which in turns makes it non-special, in that, from the point of both
the distributor and the user, it becomes just like any other random
piece of hardware: the distributor doesn't limit the freedoms the user
had, and the user isn't limited in enjoying the freedoms she had.

>> It's exactly the opposite.  It just says the distributor can't
>> make the hardware special, so as to restrain the users' freedoms that
>> are inseparable from the software.

> Don't you see that the rule that "this one thing cannot be special" makes
> that one thing special since everything else *can* be special.

It took me several attempts to understand what you meant.  Yes.  It's
special in that it can't be made special.  Poof, there goes the
universe ;-)

>> > Because that is not a right the vendor chooses to give to the user.

>> As in, the vendor can turn to the user and sue her for patent
>> infringement, after distributing GPLed software to her, just because
>> the use of the patent is not a right the vendor chooses to give to the
>> 

Re: 2.6.20->2.6.21 - networking dies after random time

[Jarek Poplawski]

On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 13:08:49 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> > It looks like skge driver enables different device than probbed.
> > Maybe you've something old/wrong about eth0/eth1 in /etc configs?
> 
> More likely it is just user level device renaming. Most distro's
> rename devices (if needed) using udev.

I hope you're right, and the problem is resolved already, but for
historical reasons I'd notice the original message with quite a lot
of configs is available on linux-kernel.

Regards,
Jarek P.

> 
> > You can also try with netdev= or pci= kernel parameters.
> 
> Bad idea. 
> 
> > If no result - resend it, please - maybe with some debugging on
> > (modinfo skge). BTW - netdev seems to be preferred for this.
> 
> What is the contents of /proc/interrupts

--->

> On 16-06-2007 23:35, Marcin .lusarz wrote:
...
> joi ~ # cat /proc/interrupts ; sleep 5; cat /proc/interrupts
>   CPU0
>  0: 891160   IO-APIC-edge  timer
>  1:   2218   IO-APIC-edge  i8042
>  8:  2   IO-APIC-edge  rtc
>  9:  1   IO-APIC-fasteoi   acpi
> 12:   9110   IO-APIC-edge  i8042
> 14:  0   IO-APIC-edge  libata
> 15:122   IO-APIC-edge  libata
> 17: 12   IO-APIC-fasteoi   eth1, eth0
> 18:  57275   IO-APIC-fasteoi   bttv0
> 20:  18810   IO-APIC-fasteoi   libata
> 21:  0   IO-APIC-fasteoi   ehci_hcd:usb1
> 22:  77945   IO-APIC-fasteoi   VIA8237
> NMI:  0
> LOC: 890924
> ERR:  0
>   CPU0
>  0: 896221   IO-APIC-edge  timer
>  1:   2219   IO-APIC-edge  i8042
>  8:  2   IO-APIC-edge  rtc
>  9:  1   IO-APIC-fasteoi   acpi
> 12:   9110   IO-APIC-edge  i8042
> 14:  0   IO-APIC-edge  libata
> 15:122   IO-APIC-edge  libata
> 17: 12   IO-APIC-fasteoi   eth1, eth0
> 18:  57654   IO-APIC-fasteoi   bttv0
> 20:  18813   IO-APIC-fasteoi   libata
> 21:  0   IO-APIC-fasteoi   ehci_hcd:usb1
> 22:  78421   IO-APIC-fasteoi   VIA8237
> NMI:  0
> LOC: 895984
> ERR:  0
> 
> joi ~ # cat /proc/ioports
> -001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-006f : keyboard
> 0070-0077 : rtc
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : :00:0f.1
>  0170-0177 : libata
> 01f0-01f7 : :00:0f.1
>  01f0-01f7 : libata
> 0290-0297 : pnp 00:09
> 02f8-02ff : serial
> 0376-0376 : :00:0f.1
>  0376-0376 : libata
> 03c0-03df : vesafb
> 03f6-03f6 : :00:0f.1
>  03f6-03f6 : libata
> 03f8-03ff : serial
> 0400-0407 : vt596_smbus
> 0680-06ff : pnp 00:09
> 0800-0803 : ACPI PM1a_EVT_BLK
> 0804-0805 : ACPI PM1a_CNT_BLK
> 0808-080b : ACPI PM_TMR
> 0810-0815 : ACPI CPU throttle
> 0820-0823 : ACPI GPE0_BLK
> 0cf8-0cff : PCI conf1
> 1000-10ff : :00:11.6
> a800-a8ff : :00:0a.0
>  a800-a8ff : skge
> b000-b01f : :00:0c.0
>  b000-b01f : ne2k-pci
> b400-b4ff : :00:0f.0
>  b400-b4ff : sata_via
> b800-b80f : :00:0f.0
>  b800-b80f : sata_via
> c000-c003 : :00:0f.0
>  c000-c003 : sata_via
> c400-c407 : :00:0f.0
>  c400-c407 : sata_via
> c800-c803 : :00:0f.0
>  c800-c803 : sata_via
> d000-d007 : :00:0f.0
>  d000-d007 : sata_via
> d400-d41f : :00:10.0
> d800-d81f : :00:10.1
> e000-e01f : :00:10.2
> e400-e41f : :00:10.3
> e800-e8ff : :00:11.5
>  e800-e8ff : VIA8237
> fc00-fc0f : :00:0f.1
>  fc00-fc0f : libata
> 
> joi ~ # cat /proc/iomem
> -0009fbff : System RAM
> 0009fc00-0009 : reserved
> 000c-000d : pnp 00:0e
> 000e4000-000f : reserved
> 0010-3ffa : System RAM
>  0020-0059ebc7 : Kernel code
>  0059ebc8-0077248f : Kernel data
> 3ffb-3ffb : ACPI Tables
> 3ffc-3ffe : ACPI Non-volatile Storage
> 3fff-3fff : reserved
> e800-ebff : :00:00.0
>  e800-ebff : aperture
> efe0-efe00fff : :00:0d.0
>  efe0-efe00fff : bttv0
> eff0-eff00fff : :00:0d.1
> f000-f9ff : PCI Bus #01
>  f000-f7ff : :01:00.0
>f000-f7ff : vesafb
> faa0-faa1 : :00:0a.0
> fab0-fab03fff : :00:0a.0
>  fab0-fab03fff : skge
> fac0-fac07fff : :00:0c.0
> fae0-fae000ff : :00:10.4
>  fae0-fae000ff : ehci_hcd
> faf0-fbff : PCI Bus #01
>  faf0-faf1 : :01:00.0
>  fb00-fbff : :01:00.0
> fec0-fec00fff : IOAPIC 0
>  fec0-fec00fff : pnp 00:0b
> fee0-fee00fff : Local APIC
> ff78- : reserved
> 
> joi ~ # cat /proc/sys/kernel/tainted
> 0
...
-
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/

[-RT] multiple streams have degraded performance

[Vernon Mauery]

In looking at the performance characteristics of my network I found that 
2.6.21.5-rt15 suffers from degraded thoughput with multiple threads.  The 
test that I did this with is simply invoking 1, 2, 4, and 8 instances of 
netperf at a time and measuring the total throughput.  I have two 4-way 
machines connected with 10GbE cards.  I tested several kernels (some older 
and some newer) and found that the only thing in common was that with -RT 
kernels the performance went down with concurrent streams.

While the test was showing the numbers for receiving as well as sending, the 
receiving numbers are not reliable because that machine was running a -RT 
kernel for these tests.

I was just wondering if anyone had seen this problem before or would have any 
idea on where to start hunting for the solution.

--Vernon

The key for this is 'default' was invoked like:
netperf -c -C -l 60 -H 10.2.2.4 -t UDP_STREAM -- -m 1472 -M 1472
and '1Msock' was invoked like:
netperf -c -C -l 60 -H 10.2.2.4 -t UDP_STREAM -- -m 1472 -M 1472 -s 1M -S 1M

2.6.21
==
default: 1 streams: Send at 2844.2 Mb/s, Receive at 2840.1 Mb/s
default: 2 streams: Send at 3927.9 Mb/s, Receive at 3603.9 Mb/s
default: 4 streams: Send at 4197.4 Mb/s, Receive at 3776.3 Mb/s
default: 8 streams: Send at 4223.9 Mb/s, Receive at 3848.9 Mb/s
1Msock: 1 streams: Send at 4232.3 Mb/s, Receive at 3914.4 Mb/s
1Msock: 2 streams: Send at 5428.8 Mb/s, Receive at 3853.2 Mb/s
1Msock: 4 streams: Send at 6202.1 Mb/s, Receive at 3774.8 Mb/s
1Msock: 8 streams: Send at 6225.1 Mb/s, Receive at 3754.7 Mb/s

2.6.21.5-rt15
===
default: 1 streams: Send at 3091.6 Mb/s, Receive at 3048.1 Mb/s
default: 2 streams: Send at 3768.8 Mb/s, Receive at 3714.2 Mb/s
default: 4 streams: Send at 1873.6 Mb/s, Receive at 1825.9 Mb/s
default: 8 streams: Send at 1806.5 Mb/s, Receive at 1792.7 Mb/s
1Msock: 1 streams: Send at 3680.4 Mb/s, Receive at 3255.6 Mb/s
1Msock: 2 streams: Send at 4129.8 Mb/s, Receive at 3991.5 Mb/s
1Msock: 4 streams: Send at 1862.1 Mb/s, Receive at 1787.1 Mb/s
1Msock: 8 streams: Send at 1790.2 Mb/s, Receive at 1556.8 Mb/s
-
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: SATA problems

[Nigel Kukard]

>  > 
>  >  > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>  >  > > 0x0001c807
>  >  > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>  >  > > 0x0001c807
>  > 
>  > Unrelated to the other error, but I've been meaning to ask for a while..
>  > If this is 'abnormal', why does every SATA box I've seen do it?
>
> *crickets*
>
> Should we check for this case explicitly, and not print this?
>
>   
After I get the above errors, my entire SATA bus crashes and I need to
hard reset the box ... not sure we can just ignore the errors?



signature.asc
Description: OpenPGP digital signature

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

[Tim Post]

On Mon, 2007-06-18 at 23:21 -0400, Daniel Drake wrote:
> Let's take a certain class of medical devices into account: ones that 
> are absolutely definitely for medical treatment, but are not life 
> threatening if they fail.
> 
> Say, a dental treatment device -- if the device produces a crown or 
> bridge that doesn't fit properly, the dentist says "nope" and throws it 
> away. No harm done.

I've done quite a bit of research, I'm not nearly done.

These regulations (from what I can tell) seemed to follow suit with the
National Electric Code (NEC) [latest] when dealing with mandatory
isolated ground devices and special cabling methods when it comes into a
device touching a patient. If that remains consistent, this won't be so
bad.

If the patient never comes in contact with it, its not regulated as much
and (from what I've seen) has no requirement for tamper proofing. I
point out again, I am not _nearly_ done with my research.

I think of nothing else, anyone with an interest should closely monitor
how these devices are being regulated by the FDA as more of them begin
to look like penguins.

I won't argue one way or another as to the presence of benevolent intent
in those laws-to-come, I'm simply pointing out the questionable
technical competency of those who will be writing them and their need
for guidance when doing so.


Best,
--Tim


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

Re: [BUG] long freezes on thinkpad t60

[Ravikiran G Thirumalai]

On Mon, Jun 18, 2007 at 01:20:55AM -0700, Andrew Morton wrote:
> On Mon, 18 Jun 2007 10:12:04 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 
> > >
> > Subject: [patch] x86: fix spin-loop starvation bug
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> > 
> > Miklos Szeredi reported very long pauses (several seconds, sometimes 
> > more) on his T60 (with a Core2Duo) which he managed to track down to 
> > wait_task_inactive()'s open-coded busy-loop. He observed that an 
> > interrupt on one core tries to acquire the runqueue-lock but does not 
> > succeed in doing so for a very long time - while wait_task_inactive() on 
> > the other core loops waiting for the first core to deschedule a task 
> > (which it wont do while spinning in an interrupt handler).
> > 
> > The problem is: both the spin_lock() code and the wait_task_inactive() 
> > loop uses cpu_relax()/rep_nop(), so in theory the CPU should have 
> > guaranteed MESI-fairness to the two cores - but that didnt happen: one 
> > of the cores was able to monopolize the cacheline that holds the 
> > runqueue lock, for extended periods of time.
> > 
> > This patch changes the spin-loop to assert an atomic op after every REP 
> > NOP instance - this will cause the CPU to express its "MESI interest" in 
> > that cacheline after every REP NOP.
> 
> Kiran, if you're still able to reproduce that zone->lru_lock starvation 
> problem,
> this would be a good one to try...

We tried this approach a week back (speak of co-incidences), and it did not
help the problem.  I'd changed calls to the zone->lru_lock spin_lock
to do spin_trylock in a while loop with cpu_relax instead.  It did not help,
This was on top of 2.6.17 kernels.  But the good news is 2.6.21, as
is does not have the starvation issue -- that is, zone->lru_lock does not
seem to get contended that much under the same workload.

However, this was not on the same hardware I reported zone->lru_lock
contention on (8 socket dual core opteron).  I don't have access to it 
anymore :(

Thanks,
Kiran
-
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] use __asm__ and __volatile__ in i386/arm/s390 byteorder.h

[Christoph Hellwig]

On Mon, Jun 18, 2007 at 09:00:09PM +0200, Sam Ravnborg wrote:
> Do you imply that if we see asm or __asm__ in user space headers we ougth
> to warn about it?
> Seems at least sensible to me but if we introduce such a check we should
> kill all offenders first - which Mike's patches seems to trigger for some 
> part.

Yes, we should kill the offenders first.  Some of Mike's patches are moving
nicely in that directions.  The biggest problem from my POV is byteawap.h
that gets dragged in in various places right now and needs to be sorted out.

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

Re: v2.6.21.4-rt11

[Thomas Gleixner]

Katsuya-San,

On Tue, 2007-06-19 at 01:14 +0900, Katsuya MATSUBARA wrote:
> > It lacks support for the generic timeofday and clock event layers, which
> > causes the compile breakage.
> 
>  I am working on Renesas SuperH platforms.
>  I faced the similar compile errors
>  because 2.6.21.X in SH does not support GENERIC_TIME yet.
>  I made a workaround patch. Is this correct?

Looks good.

Can you in future please use "diff -ur" to generate patches. That's the
usual format.

Thanks,

tglx


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

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

[Al Viro]

On Mon, Jun 18, 2007 at 08:46:44PM -0700, Linus Torvalds wrote:
 
> So I have actual *numbers* on my side. What do you have, except for a 
> history of not actually understanding my arguments?

Why do I suddenly have an image of Palin as Ximenez doing the answer?
-
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/

This is [Re:] How to improve the quality of the kernel[?].

[Oleg Verych]

[Dear Debbug developers, i wish your ideas will be useful.]

* From: Linus Torvalds
* Newsgroups: gmane.linux.kernel
* Date: Mon, 18 Jun 2007 17:09:37 -0700 (PDT)
>
> On Mon, 18 Jun 2007, Martin Bligh wrote:
>> 
>> Sorry to be a wet blanket, but I've seen those sort of things
>> before, and they just don't seem to work, especially in the
>> environment we're in with such a massive diversity of hardware.
>
> I do agree. It _sounds_ like a great idea to try to control the flow of 
> patches better,

There were some ideas, i will try to summarize:

* New Patches (or sets) need tracking, review, testing

  Zero (tracking) done by sending (To, or bcc) [RFC] patch to something
  like [EMAIL PROTECTED] (like BTS now). Notifications will
  be sent to intrested maintainers (if meta-information is ok) or testers
  (see below)

  First is mostly done by maintainers or interested individuals.
  Result is "Acked-by" and "Cc" entries in the next patch sent. Due to
  lack of tracking this things are done manually, are generally in
  trusted manner. But bad like <[EMAIL PROTECTED]>
  sometimes happens.

  When patch in sent to this PTS, your lovely
  checkpatch/check-whatever-crap-has-being-sent tools can be set up as
  gatekeepers, thus making impossible stupid errors with MIME coding,
  line wrapping, whatever style you've came up with now in checking
  sent crap.

* Tracking results of review (Acked-by).

  This can be mostly e-mail exchange with comments and agreements.
  "Acked-by" semantic may be implemented in form of contlol message to
  tracking system, and this system will generate e-mail confirmation
  to the patch author in form of
  "Acked-by: Developer's Name "

  Thus, next patch will have this entry. And if testing of this
  version ir regression happens, there's info about who is/was
  interested/involved.

* Testing.

  Mainly same for "Tested-by"
  (newly suggested by Stefan <[EMAIL PROTECTED]>)

|-*- Feature Needed -*-
  Addition, needed is hardware user tested have/had/used. Currently
  ``reportbug'' tool includes packed specific and system specific
  additions automaticly gathered and inserted to e-mail sent to BTS.
  (e.g. )

  Formats of that hardware profile(as system information in reportbug)
  . arch
  . chipset
  . hdd
  . vga
  ...
  in meaningful fields, and not just lspci -v[vv]. If additional info
  (-vvv) or something required, profile can be exteded.

  For kernel's sub-system information(as packed info):
  . subsystem/driver/kernel version (or similar)
  . maintainers must know what they need to see more here

|-*- back to patches -*-

  Last and not least tast cases, that everyone might came up with.

  All formats this can be agreed (or implemented and updated latter)
  and inserted automaticly.

* Commit.
  Id is recorded, patch archived. But any additions are welcome,
  regressions will pop up this patch again (reopen in BTS).

> but in the end, it needs to also be easy and painfree to the people
> involved, and also make sure that any added workflow doesn't require
> even *more* load and expertise on the already often overworked 
> maintainers..

Experienced BTS users and developers. Please, correct me if i'm wrong.
At least e-mail part of Debian's BTS and whole idea of it is *exactly*
what is needed. Bugzilla fans, you can still use you useless pet,
because Debian developers have done things, to track and e-mail states
of bugs: 

> In many cases, I think it tends to *sound* great to try to avoid 
> regressions in the first place - but it also sounds like one of those "I 
> wish the world didn't work the way it did" kind of things. A worthy goal, 
> but not necessarily one that is compatible with reality.

I wish perl hackers out there will join this yet-new effort. I know
there many of them out there, writing kilobytes of checkfile and
checkpatch (i've wrote in few lines of ``sed'').

BTS is written on perl, but any interoperability interface, like
stdin/stdout for python or shell hackers is worth of thinking about.

Please, see more and make useful follows ups: http://bugs.debian.org/

Please, do not (<[EMAIL PROTECTED]>)
""" I know you hate bugzilla ... but at least I can try to make that bit
of the process work better.
""" [here's you fancy checkbox...]

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: [RFC/PATCH] Documentation of kernel messages

[Gerrit Huizenga]

On Mon, 18 Jun 2007 17:13:19 PDT, Tim Bird wrote:
> Gerrit Huizenga wrote:
> > Further, yet another kernel config option could allow distros to output
> > the calculated MD5 sum to be printed, much like we do with timestamps
> > today.
> 
> > Comments?
> 
> Would the compiled-in text then also become replaceable?
> Or is the MD5 sum output expected to be in addition to
> the regular English message?
 
 The MD5 sum would be calculated at print time, no proposal in
 here to replace the in-kernel text.  And, I'm not sure that replacing
 it with an MD5 sum would every be significantly shorter, ergo
 I don't think this helps your problem.

 The methods of post-processing to "shrink" the kernel text here
 seem too ugly to ponder.  And I just pondered a few that made my
 head hurt (sort the MD5 sums, re-insert the number of the MD5 sum
 as an integer instead of the original text, and, beyond being gross,
 what do you do with the formatting info about the args?).

> If message replacement at compile-time is supported, this
> could allow for creating "short" versions of the messages,
> which could have a beneficial impact on kernel size.
> 
> Right now, it is possible to completely disable printks
> and re-claim about 100K of memory.  However, in some
> embedded configurations, even if you are space-constrained
> it's desirable to retain some of the printks, for in-field
> debugging.  Thus not very many embedded developers
> disable printks completely, even though the option has
> been supported for a while.  (That, and many aren't caught
> up to the kernel version where it was introduced (2.6.10) :-)

 Which ones matter?  Odds are you could use the KERNEL_LOGLEVEL or
 such to mark those, then compile out the rest.

> But compressed messages (shortened text through abbreviations,
> or just outputting the ID alone, etc.) could save SOME
> of the space, in trade for less readability.  Heck, just
> removing all vowels would probably save 10k, and not
> hurt readability that much.
 
 Ick.  Are you serious?  How about running them through a valley
 girl filter and then converting to high school text messaging?

> Finally, for testing, it's handy to also
> have automatic translation generators.
> At a former company I worked for, they had translators
> that would output:
>  * all messages shortened by 20%
>  * all messages lengthened by 20%
>  * every message converted to pig-latin

 Double yucko.

> These were mostly used for testing if the strings broke
> screen real-estate constraints (which don't apply to
> kernel messages).  But the automatic translators
> would sometimes catch messages with weird attributes.
 
  I don't think people are worried about the correctness of
  the messages and message formats - much of that can actually
  be detected by simple tools.  The goal here was to at least
  allow people that support operating systems and for whom
  English (and English collation sequences) is not a primary
  language do some initial system diagosis.

  I think compiling out the messages of something below some LOGLEVEL
  is a lot more practical.

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

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

[Linus Torvalds]

On Mon, 18 Jun 2007, Alexandre Oliva wrote:
>
> > "More Developers" (either "Free Software" or "Open Source") == "More 
> > Contributions"
> 
> No, seriously.  Linus is disputing the equation above, dismissing my
> various attempts to show it to him, whenever it appears in teh context
> of tivoization, apparently because it doesn't match his moral belief
> that tivoization ought to be permitted on his moral grounds.

No. Linus is not AT ALL disputing the equation above.

But you are too f*cking stupid to admit that I *accepted* the

 - "More developers" == "More contributions" == good

equation, but I was claiming that your *other* part was totally broken.

You try to claim that the GPLv3 causes "More developers", and that, my 
idiotic penpal, is just crazy talk that you made up. 

But since you cannot follow a logical argument, and cannot make one up 
on your own, you instead make up some *other* argument, and try (like 
above) to try to say that I made that claim.

The GPLv2 is the one that allows more developers. 

The GPLv2 is the one that is acceptable to more people. 

Face it, the "open source" crowd is the *bigger* crowd. The FSF crowd is 
vocal and opinionated, but it's largely made up of people who _talk_ more 
than they actually _code_. 

Hot air doesn't make the world go round. Real code does.

Look at the kernel developers who claim that the GPLv2 is better. Not just 
me. Then look at the people who actually GET THINGS DONE. 

There's a big overlap there.

Now, look at the people who try to sell the GPLv3 as the best thing since 
sliced bread. How many of those are people who actually get things *done*?

I haven't really seen a single one. Last I did the statistic, I asked the 
top ~25-30 kernel developers about their opinion. NOT A SINGLE ONE 
preferred the GPLv3.

So I have actual *numbers* on my side. What do you have, except for a 
history of not actually understanding my arguments?

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: [PATCH] relay-file-read-start-pos-fix.patch

[Masami Hiramatsu]

Hi David and Tom,

David Wilder wrote:
> This patch fixes a bug in the relay read interface causing the number
> of consumed bytes to be set incorrectly. 

Thank you. Your patch fixes one of my concerns.
However there is another bug I found.
When I use relayfs with "overwrite" mode, read() still set incorrect
number of consumed bytes.
I tried to fix that. Please review it.

Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>

---
 kernel/relay.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Index: linux-2.6.22-rc4-mm2/kernel/relay.c
===
--- linux-2.6.22-rc4-mm2.orig/kernel/relay.c2007-06-13 20:22:02.0 
+0900
+++ linux-2.6.22-rc4-mm2/kernel/relay.c 2007-06-18 23:00:54.0 +0900
@@ -812,7 +812,10 @@
}

buf->bytes_consumed += bytes_consumed;
-   read_subbuf = read_pos / buf->chan->subbuf_size;
+   if (!read_pos)
+   read_subbuf = buf->subbufs_consumed;
+   else
+   read_subbuf = read_pos / buf->chan->subbuf_size;
if (buf->bytes_consumed + buf->padding[read_subbuf] == subbuf_size) {
if ((read_subbuf == buf->subbufs_produced % n_subbufs) &&
(buf->offset == subbuf_size))
@@ -841,8 +844,9 @@
}

if (unlikely(produced - consumed >= n_subbufs)) {
-   consumed = (produced / n_subbufs) * n_subbufs;
+   consumed = produced - n_subbufs + 1;
buf->subbufs_consumed = consumed;
+   buf->bytes_consumed = 0;
}

produced = (produced % n_subbufs) * subbuf_size + buf->offset;



-
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: v2.6.21.4-rt11

[Christoph Lameter]

On Mon, 18 Jun 2007, Siddha, Suresh B wrote:

> > +   if (time_after(next_balance,
> > + sd->last_balance + sd->balance_interval))
> > +   next_balance = sd->last_balance
> > +   + sd->balance_interval;
> 
> don't we have to do, msecs_to_jiffies(sd->balance_interval)?

Well that is certainly a bug here. Is this better?

Scheduler: Fix next_interval determination in idle_balance().

The intervals of domains that do not have SD_BALANCE_NEWIDLE must
be considered for the calculation of the time of the next balance.
Otherwise we may defer rebalancing forever.

Siddha also spotted that the conversion of the balance interval
to jiffies is missing. Fix that to.

Signed-off-by: Christop Lameter <[EMAIL PROTECTED]>

Index: linux-2.6.22-rc4-mm2/kernel/sched.c
===
--- linux-2.6.22-rc4-mm2.orig/kernel/sched.c2007-06-18 20:41:46.0 
-0700
+++ linux-2.6.22-rc4-mm2/kernel/sched.c 2007-06-18 20:44:00.0 -0700
@@ -2493,17 +2493,18 @@ static void idle_balance(int this_cpu, s
unsigned long next_balance = jiffies + 60 *  HZ;
 
for_each_domain(this_cpu, sd) {
-   if (sd->flags & SD_BALANCE_NEWIDLE) {
+   unsigned long interval;
+
+   if (sd->flags & SD_BALANCE_NEWIDLE)
/* If we've pulled tasks over stop searching: */
-   pulled_task = load_balance_newidle(this_cpu,
-   this_rq, sd);
-   if (time_after(next_balance,
- sd->last_balance + sd->balance_interval))
-   next_balance = sd->last_balance
-   + sd->balance_interval;
-   if (pulled_task)
-   break;
-   }
+   pulled_task = load_balance_newidle(this_cpu,this_rq, 
sd);
+
+   interval = msecs_to_jiffies(sd->balance_interval);
+   if (time_after(next_balance,
+ sd->last_balance + interval))
+   next_balance = sd->last_balance + interval;
+   if (pulled_task)
+   break;
}
if (!pulled_task)
/*

-
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: mea culpa on the meaning of Tivoization

[Daniel Hazelton]

On Monday 18 June 2007 22:57:20 Alexandre Oliva wrote:
> On Jun 18, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Monday 18 June 2007 17:31:47 Alexandre Oliva wrote:
> >> And if you look at GPLv3dd1 or dd2 IIRC, that's how it started.  For
> >> some reason, the FSF turned it into the more lax (in some senses)
> >> installation information for user products in dd3.  Maybe they decided
> >> that the argument about the signature being effectively part of the
> >> executable, and therefore the key being effectively part of the source
> >> code, was less likely to be upheld in a court of law than this
> >> alternate phrasing.  All in all, the effect is the same AFAICT, and
> >> the spirit is being complied with.
> >
> > But the change has some massive problems.
>
> Such as?  Is the effect really any different?

I haven't looked at it, in depth, today but one of the problems I saw was the 
apparent loopholes in the text. No specifics, but I remember thinking "a 
lawyer would have a field day with this - dozens of ways they could sidestep 
these issues"

> > If dd1 or dd2 was clearly and concisely written such that the
> > conditions were not open to a different interpretation without
> > creative re-definition of words then changes would not be
> > needed. (I'm still working on the version I mentioned - give me a
> > bit, writing english in such a way that a lawyer can't twist it to
> > mean whatever they are paid to make it mean is difficult.)
>
> It's very difficult and, worse, it might turn out to be unenforceable.
> You'd have to count on signing keys being copyrightable, and they are
> unlikely to be, and on signatures being derived works of both, which
> is a tough call.  The whole idea resonates very well with the spirit
> of the license, but we need more than that, we need it to be very
> likely to work.  I suspect this is why the FSF has decided to take
> another route to achieve the same (AFAICT) effect.

Agreed. I'm still stuck trying to keep the language concise and understandable 
without delving into the descriptive flights of fancy I enjoy. (I write a lot 
more fiction than I do code, even though I started writing code a long time 
before I started on fiction)

> >> I don't see how this is different from refraining from accepting
> >> contributions under any other license, except that you can't use
> >> license incompatibility to reason it out as an impossibility you
> >> established for yourself in just the very same way.
> >
> > I think there was more to it than that, but the point doesn't
> > matter. If the license used on contributed code *isn't* completely
> > compatible with the license on the project it can't be used
> > anyway. (doesn't the GPLv3 cover situations like that?)
>
> I'm not sure what you're asking.  GPLv3 covers additional permissions,
> that are really no different from dual-licensing, so anyone can choose
> to drop them when combining with works (including their own) that
> don't offer such additional permissions.

What I was getting at, here, is that the GPLv3 isn't backwards compatible with 
GPLv2, because you aren't allowed to remove rights from the GPLv3. Remember, 
there are rights encoded in the GPLv3 that don't appear in v2. In fact, if 
you want to use GPLv3 code in a GPLv2 project you have to use GPLv3. For some 
projects, like the Linux Kernel, the upgrade is impossible to accomplish.

> >> My objection was mainly about the "forcing".  FSF's stance is about
> >> educating users as to the moral and ethical reasons, such that they
> >> reject non-Free Software, while at the same time providing software
> >> authors with means to stop others from hurting users, by depriving
> >> them of the freedoms they're morally entitled to have.
> >
> > Hrm... When I first hit the end of this massive sentence I was really
> > confused. Took about five minutes for me to remember that "morally
> > entitled" is based on the morals promoted by the FSF.
>
> Yes.  And the 'them' after the last comma refers to the users, not the
> authors (although they can be users too), in case it's not clear ;-)
>
> :-D

Yes. I almost replied "-ENOPARSE" because, when I first read it, I parsed it 
as "by depriving [the authors] of the freedoms they're morally entitled to 
have". When my brain finally rebooted after that bought of idiocy I was able 
to parse it properly.

DRH

> > Everyone that has been part of this discussion - my personal code of
> > morals will not let me get away without this: "Forgive me if, in the heat
> > of the moment, I offended any of you."
>
> FWIW, I never felt offended by you, but I second your request and
> extend it to all participants in the thread too, particularly to Ingo,
> to whom I remember having directed some harsh words.



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

[Daniel Drake]

Let's take a certain class of medical devices into account: ones that 
are absolutely definitely for medical treatment, but are not life 
threatening if they fail.


Say, a dental treatment device -- if the device produces a crown or 
bridge that doesn't fit properly, the dentist says "nope" and throws it 
away. No harm done.


Alexandre Oliva wrote:

There may be business models that require the ability to make changes.


I'd say that its sensible for the manufacturer to attempt to retain this 
ability in every case. You never know what's going to go wrong, so it's 
a plus to have this option so that you can roll out some types of fixes 
without going bankrupt.


Now, for medical devices, this is tricky stuff: medical devices require 
all sorts of certifications, so modifying your product after you have 
certified it has it's complications. However, despite all the 
regulations it's realistic to be able to do this, and it does happen. 
Hell, windows-based devices in this field download new antivirus 
definitions and run windows update every few days.



Then it's fair to enable the user to make changes as well, such that
they don't become dependent on the vendor


Now this is where the regulations get really heavy. If the user is 
offered the ability to modify the device, theres *no way* it would get 
certified. Your business is dead - you do not have a product you can 
sell. In such case, the license has completely excluded free software 
from the market and everyone is forced to use completely closed systems.



I realise that the latest GPLv3 draft would not pose restrictions here, 
as such devices would not be classified as consumer products. That said, 
talking purely in terms of business models and fairness: there ARE 
decent reasons for manufacturer lockdown in some industries.


Daniel
-
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: Versioning file system

[Kyle Moffett]

On Jun 18, 2007, at 17:24:23, Brad Boyer wrote:

On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
Pointless here means that _I_ don't see the point.  Maybe there  
are valid uses for extended attributes.  If there are, noone has  
explained them to me yet.


The users of extended attributes that I've dealt with are ACL  
support and SELinux. These both use extended attributes under the  
covers. It's just not immediately obvious if you aren't looking.


Yeah, extended attributes are typically used for exactly that:  
"attributes" like labels, permissions, encoding, cached file-type,  
DOS/Windows/Mac metadata, etc.  Sometimes people suggest sticking  
icons in there, but that's probably a bad idea.  At most stick an  
"icon label" attribute which refers to a file "/usr/share/icons/ 
by_attr/$ICON_LABEL.png".  If you're trying to put more than 256  
bytes of data in an extended attribute then you're probably doing  
something wrong.  They're very good for cached attributes (like file- 
type) where you don't care if the data is lost by "tar", and they're  
reasonable for security-related attributes where you don't want  
attribute-unaware programs trying to save and restore them (like  
SELinux labels).


Cheers,
Kyle Moffett

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

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

[Daniel Hazelton]

On Monday 18 June 2007 22:06:57 Alexandre Oliva wrote:
> On Jun 18, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Monday 18 June 2007 19:31:30 Alexandre Oliva wrote:
> >> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >>
> >> Actually, just think of how many times you've heard the argument "I
> >> can't give you the source code for this driver/firmware/etc under the
> >> GPLv2 because the law says so."
> >
> > Sorry to tell you this, but anyone that makes a modification to GPLv2
> > covered code and distributes that modification is bound by the license.
>
> Of course I know that.  I'm not the one making those arguments.
> And then, not all of those pieces of code are indeed moficiations of
> GPLv2-covered code, so your objection is off target.

I had a parsing error with your statement. My mind made the jump to "they are 
doing it with GPLv2 code" - meaculpa.

> >> > b) I think you're simply wrong in your math. I think more people
> >> > like the middle-ground and not-frothing-at-the-mouth spirit of "open
> >> > source" over the religious dogma of "free software".
> >>
> >> It looks like the math you're talking about is in no way related with
> >> anything I've argued about.  You seem to be thinking about the number
> >> of people who claim to be on the "free software" or "open source"
> >> sides, but I can't fathom in what way this is related with whether you
> >> get more or less contributions from users as a consequence of users'
> >> being permitted to tinker with the free software in their own devices.
> >
> > "More Developers" (either "Free Software" or "Open Source") == "More
> > Contributions"
> >
> > That equation is very simple to understand - claiming its wrong is
> > impossible.
>
> YES!  Thank you!  This is exactly the point I'm trying to make.
>
> Now can you please explain this to Linus in terms that his brain won't
> dismiss as "coming from a fundamentalist"?

No need. Linus already understands the equation, and also the secondary fact 
that most home users are not developers. However, companies like TiVO do 
employ developers. This is why the equation works.

> > Apparently because you can't admit that a good reason *IS* a good reason
> > when it conflicts with your belief that the FSF is correct.
>
> No, seriously.  Linus is disputing the equation above, dismissing my
> various attempts to show it to him, whenever it appears in teh context
> of tivoization, apparently because it doesn't match his moral belief
> that tivoization ought to be permitted on his moral grounds.

Actually you are in error here. You are saying "More home users == More 
Developers" when the ratio of home users to developers isn't all that high. 
(small set of facts: "Hacker" == "Developer" (in most cases, where the term, 
as defined in the Jargon File, can actually be applied), "Home User" * 0.10 
(ie: 10%) == "Developer" (approximately, and the correlation may be 
lower). "TiVO" == "Developers" (note the plural - they do employ more than 
one person for development))

So "TiVO", even though they are walking all over the freedoms you love, means 
more *guaranteed* developers than the potential pool from the users of their 
boxes. (the pool of potential developers among the millions of TiVO users is 
actually miniscule, despite the size of the sample)

However, you do make a good argument. But when you look at the statistics[1] 
they don't hold water.

> > PS: I know I've said I'm done with this conversation, but this is like a
> > bad habit. I just couldn't help myself.
>
> You've helped me a lot while at that.  Thanks!
>
> I hope this helps others fundamentalist anti-fundamentalists :-) see
> reason too.

I love that phrase!

But seriously, all I did was stop trying to give fully reasoned counters 
(complete with examples) and state the simple truth.

DRH
[1] "There are three types of lies - lies, damn lies and statistics" - 
Attribution uncertain (Benjamin Disraeli, Mark Twain and Alfred Marshal are 
all said to have issued this famous quotation)

PS: I've beaten the addiction! This post was to clarify some things that were 
either misunderstood or stood a chance of being twisted to mean something 
other than what I intended. (not that anyone did the latter)

-- 
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: Versioning file system

[Kyle Moffett]

On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
The question remains is where to implement versioning: directly in  
individual filesystems or in the vfs code so all filesystems can  
use it?


Or not in the kernel at all.  I've been doing versioning of the  
types I described for years with user space code and I don't  
remember feeling that I compromised in order not to involve the  
kernel.


Of course, if you want to do it with snapshots and COW, you'll have  
to ask where in the kernel to put that, but that's not a file  
versioning question; it's the larger snapshot question.


What I think would be particularly interesting in this domain is  
something similar in concept to GIT, except in a file-system:
  1) Redundancy is easy, you just ensure that you have at least "N"  
distributed copies of each object, where "N" is some function of the  
object itself.
  2) Network replication is easy, you look up objects based on the  
SHA-1 stored in the parent directory entry and cache them where  
needed (IE: make the "N" function above dynamic based on frequency of  
access on a given computer).
  3) Snapshots are easy and cheap; an RO snapshot is a tag and an RW  
snapshot is a branch.  These can be easily converted between.
  4) Compression is easy; you can compress objects based on any  
arbitrary configurable criteria and the filesystem will record  
whether or not an object is compressed.  You can also compress  
differently when archiving objects to secondary storage.
  5) Streaming fsck-like verification is easy; ensure the hash name  
field matches the actual hash of the object.
  6) Fsck is easy since rollback is trivial, you can always revert  
to an older tree to boot and start up services before attempting  
resurrection of lost objects and trees in the background.
  7) Multiple-drive or multiple-host storage pools are easy:  Think  
the git "alternates" file.
  8) Network filesystem load-balancing is easy; SHA-1s are  
essentially random so you can just assign SHA-1 prefixes to different  
systems for data storage and your data is automatically split up.



Other issues:

Q. How do you deal with block allocation?
A. Same way other filesystems deal with block allocation.  Reference- 
counting gets tricky, especially across a network, but it's easy to  
play it safe with simple cross-network refcount-journalling.  Since  
the _only_ thing that needs journalling is the refcounts and block- 
free data, you need at most a megabyte or two of journal.  If in  
doubt, it's easy to play it safe and keep an extra refcount around  
for an in-the-background consistency check later on.  When networked- 
gitfs systems crash, you just assume they still have all the  
refcounts they had at the moment they died, and compare notes when  
they start back up again.  If a node has a cached copy of data on its  
local disk then it can just nonatomically increment the refcount for  
that object in its own RAM (ordered with respect to disk-flushes, of  
course) and tell its peers at some point.  A node should probably  
cache most of its working set on local disk for efficiency; it's  
trivially verified against updates from other nodes and provides an  
easy way to keep refcounts for such data.  If a node increments the  
refcount on such data and dies before getting that info out to its  
peers, then when it starts up again its peers will just be told that  
it has a "new" node with insufficient replication and they will clone  
it out again properly.  For networked refcount-increments you can do  
one of 2 things: (1) Tell at least X many peers and wait for them to  
sync the update out to disk, or (2) Get the object from any peer (at  
least one of whom hopefully has it in RAM) and save it to local disk  
with an increased refcount.


Q. How do you actually delete things?
A. Just replace all the to-be-erased tree and commit objects before a  
specified point with "History erased" objects with their SHA-1's  
magically set to that of the erased objects.  If you want you may  
delete only the "tree" objects and leave the commits intact.  If you  
delete a whole linear segment of history then you can just use a  
single "History erased" commit object with its parent pointed to the  
object before the erased segment.  Probably needs some form of back- 
reference storage to make it efficient; not sure how expensive that  
would be.  This would allow making a bunch of snapshots and purging  
them logarithmically based on passage of time.  For instance, you  
might have snapshots of every 5 minutes for the last hour, every 30  
minutes for the last day, every 4 hours for the last week, every day  
for the last month, once per week for the last year, once per month  
for the last 5 years, and once per year beyond that.


That's pretty impressive data-recovery resolution, and it accounts  
for only 200 unique commits after it's been running for 10 years.


Q. How do you archive data?
A. Same as deleting, except 

Re: [RFC] Generic Trace Setup and Control (GTSC) kernel API (2/3)

[Martin Hunt]

On Mon, 2007-06-18 at 23:43 +0400, Alexey Dobriyan wrote:
> 
> Can we get another user to justify this generalizing?

Systemtap will be using this. Most users of the relay interface will
need to duplicate much of the functionality of GTSC so I expect others
will use it when it is available.



-
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: mea culpa on the meaning of Tivoization

[Alexandre Oliva]

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

> On Monday 18 June 2007 17:31:47 Alexandre Oliva wrote:
>> And if you look at GPLv3dd1 or dd2 IIRC, that's how it started.  For
>> some reason, the FSF turned it into the more lax (in some senses)
>> installation information for user products in dd3.  Maybe they decided
>> that the argument about the signature being effectively part of the
>> executable, and therefore the key being effectively part of the source
>> code, was less likely to be upheld in a court of law than this
>> alternate phrasing.  All in all, the effect is the same AFAICT, and
>> the spirit is being complied with.

> But the change has some massive problems.

Such as?  Is the effect really any different?

> If dd1 or dd2 was clearly and concisely written such that the
> conditions were not open to a different interpretation without
> creative re-definition of words then changes would not be
> needed. (I'm still working on the version I mentioned - give me a
> bit, writing english in such a way that a lawyer can't twist it to
> mean whatever they are paid to make it mean is difficult.)

It's very difficult and, worse, it might turn out to be unenforceable.
You'd have to count on signing keys being copyrightable, and they are
unlikely to be, and on signatures being derived works of both, which
is a tough call.  The whole idea resonates very well with the spirit
of the license, but we need more than that, we need it to be very
likely to work.  I suspect this is why the FSF has decided to take
another route to achieve the same (AFAICT) effect.

>> I don't see how this is different from refraining from accepting
>> contributions under any other license, except that you can't use
>> license incompatibility to reason it out as an impossibility you
>> established for yourself in just the very same way.

> I think there was more to it than that, but the point doesn't
> matter. If the license used on contributed code *isn't* completely
> compatible with the license on the project it can't be used
> anyway. (doesn't the GPLv3 cover situations like that?)

I'm not sure what you're asking.  GPLv3 covers additional permissions,
that are really no different from dual-licensing, so anyone can choose
to drop them when combining with works (including their own) that
don't offer such additional permissions.

>> My objection was mainly about the "forcing".  FSF's stance is about
>> educating users as to the moral and ethical reasons, such that they
>> reject non-Free Software, while at the same time providing software
>> authors with means to stop others from hurting users, by depriving
>> them of the freedoms they're morally entitled to have.

> Hrm... When I first hit the end of this massive sentence I was really 
> confused. Took about five minutes for me to remember that "morally entitled" 
> is based on the morals promoted by the FSF.

Yes.  And the 'them' after the last comma refers to the users, not the
authors (although they can be users too), in case it's not clear ;-)
:-D

> Everyone that has been part of this discussion - my personal code of morals 
> will not let me get away without this: "Forgive me if, in the heat of the 
> moment, I offended any of you."

FWIW, I never felt offended by you, but I second your request and
extend it to all participants in the thread too, particularly to Ingo,
to whom I remember having directed some harsh words.

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

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

[Michael Poole]

David Schwartz writes:

>> David Schwartz writes:
>
>> >> First, end users buy and use the hardware in question.  It does not
>> >> belong to Tivo, so the analogy to his laptop fails there.
>
>> > No, this is incorrect. They buy *some* of the rights to the
>> > hardware but not
>> > all of them. Specifically, they do not buy the right to choose
>> > what software
>> > runs on that hardware. That right is still owned by TiVo.
>
>> Do you have a reference to the contract establishing that cession of
>> rights from the buyer to Tivo?
>
> No, and I submit that this is at least arguably something wrong that TiVo is
> doing. Note that Microsoft does this too when you buy an Xbox. It has
> nothing to do with the GPL.

There is a significant difference between what is a legally recognized
right and what no one has litigated over.  I tend to not recognize the
latter as the former until I see specific backing for the idea that
the purported right has been recognized by law, a court, or all
involved parties.

>> To the extent that some contract
>> purports to restrict the user in ways contrary to the GPL, I suspect
>> Tivo might have a hard time defending it in court.
>
> I agree, however, this doesn't restrict the user in ways contrary to the
> GPL. The GPL does not say that you have to be allowed to modify the Linux
> running on some particular piece of hardware because that is a legitimate
> authorization decision. TiVo not letting you change the software is the same
> as me not letting you change the software on my laptop.

I disagree that the two are the same -- for the fundamental reason
that you have not distributed the software on your laptop to me.  Tivo
has distributed the software on Tivo DVRs to their customers.  The act
of distribution is governed by (in the case of Linux) copyright law
and the GPL.

>> > You can argue that TiVo is being dishonest, breaking the law,
>> > being immoral,
>> > or whatever in retaining this right or in failing to disclose that they
>> > retain it. But you cannot coherently deny that TiVo retains
>> > this right when
>> > they sell certain other rights to the hardware.
>
>> By the first sale doctrine, someone who buys an item has practically
>> unlimited rights to deal with it or dispose of it as the buyer wishes.
>
> This is solely a right against copyright claims. You would be correct if
> TiVo were going to sue you for violating some copyright they hold in the
> hardware or software if you modified the software.

Do you propose that Tivo would (or could) sue a customer for some
non-copyright tort if the customer were to run a Linux kernel that has
not been authorized by Tivo on a Tivo-manufactured DVR?  As far as I
can tell, the legal concerns in question are all copyright issues.

>> The only things that would restrict that are statute or a contract
>> entered as part of the sale -- most likely a EULA or other shrink-wrap
>> agreement.  Given that most such recognized agreements deal with
>> software or services rather than hardware, I am not sure a court would
>> recognize a hardware EULA as being binding.  (I suspect this is the
>> direction you were heading with the paragraph below.)
>
> Yep, but that has nothing whatsoever to do with the GPL. The exact same
> argument applies with the Xbox. It's about whether authorization to modify a
> device should or must come with buying that device.
>
> The GPL was never about allowing you to load modified software onto hardware
> where the legitimate creators/owners of that hardware say, "no, you may not
> modify the software running on this hardware".

True.  The GPL always about allowing someone to modify software that
they received from someone else.  Tivo's Linux kernel images qualify
both as softare that they distribute to others and software that is
loaded onto hardware that they created.  The concern at hand is not
about hardware that Tivo owns or software that Tivo never distributes
-- except where it is also source code for software that they *do*
distribute.

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: mea culpa on the meaning of Tivoization

[Alexandre Oliva]

On Jun 18, 2007, Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:

> Am Montag 18 Juni 2007 23:18 schrieb Alexandre Oliva:
>> On Jun 18, 2007, Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
>> 
>> >> Vendor would be entitled to the benefit of the doubt as to the
>> >> motivations in this case, so it would likely be unenforceable anyway.
>> 
>> > Right. If GPL v3 comes out, there'll probably be a new task for
>> > hardware development engineers: How to find excuses for hardware that
>> > prevents software modifications and how to conceal the true intent.
>> 
>> Yup.  And then GPLv4 will have to plug whatever holes they find to
>> disrespect users' freedoms.  That's how I expect the game to be
>> played.

> If you were right and it turned out that way, the whole GPL would
> become so ridiculous that it won't have any of its intended effects.

How so?  The intended effects are to protect users' freedoms, by
requiring them to be respected.  If we keep on plugging holes as they
appear, it will keep close to achieving its intended effects.  It's
earlier versions of the license that will get more and more distant
from it.

> As far as the kernel is concerned, I expect the game's played by
> simply keeping GPLv2. And I like it that way.

Just think about it...  What if, today, some law passed, or some court
decision came up, that rendered a significant defense provision of
GPLv2 or GPLv3 ineffective?

GPLv4 could plug that, and anyone using GPLvN+ would be able to switch
to it immediately.  This wouldn't revoke previous licenses, of course,
but further developments could be made under the newer license, and at
least those could still be defended, and, as time elapsed, earlier
versions of the software would become less and less relevant, to the
point that the holes in their license also become less and less
relevant, until copyright finally expires and they enter the public
domain.


The distrust for the FSF led to this very short-sighted decision of
painting the Linux community into a corner from which it is very
unlikely to be able to ever leave, no matter how badly it turns out to
be needed.  Let's just hope it never is, or that some influx of
long-sighted comes in and introduces mechanisms for the license of
Linux to be patched, should this ever be needed.  I'm not even talking
about GPLv2+, there are many other ways to accomplish this, that I've
already mentioned in another posting in another recent huge thread.

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

[PATCH RT] Don't call mcount from vsyscall_fn's

[Steven Rostedt]

This bit me in the butt.

I couldn't understand why my init app was segfaulting, with a kernel
address, but a user RIP and RSP.  Well, the RIP I think was bogus, but
the kernel address was always the start of "mcount".  Looking deeper, I
printed out what was in the RSP (even though it was a user stack).  It
ended up showing me that the calling address was from the VDSO area.
Looking even further, I found the offending culprit, which was
vread_hpet.

Looking at the assembly dump, I saw the vread_hpet was calling mcount,
but I could not see it in the code. Nor could I see it in hpet.i (-E
option of compiling).

Well, I guess Ingo is a magician when it comes to compiler tricks, and
has the mcount being called by "every!!" function, unless you add the
"notrace" option.

This patch adds the notrace to vsyscall_fn, so that we don't have user
land apps calling mcount and crashing!

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux-2.6-rt-test/include/asm-x86_64/vsyscall.h
===
--- linux-2.6-rt-test.orig/include/asm-x86_64/vsyscall.h
+++ linux-2.6-rt-test/include/asm-x86_64/vsyscall.h
@@ -22,7 +22,7 @@ enum vsyscall_num {
 /* Definitions for CONFIG_GENERIC_TIME definitions */
 #define __section_vsyscall_gtod_data __attribute__ \
((unused, __section__ (".vsyscall_gtod_data"),aligned(16)))
-#define __vsyscall_fn __attribute__ ((unused,__section__(".vsyscall_fn")))
+#define __vsyscall_fn __attribute__ ((unused,__section__(".vsyscall_fn"))) 
notrace
 
 #define VGETCPU_RDTSCP 1
 #define VGETCPU_LSL2


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

Is kdb package available for 2.6 Linux on PowerPC?

[gshan]

Hey Guys,

Recently, I need work on my TTY (console) driver so that it could 
support kdb. I didn't have much experiences on linux kdb. So my 
questions are:


1) 2.6 Linux for PowerPC could support kdb? where can I find the source 
code?


2) If 2.6 Linux for PowerPC doesn't support kdb, where could I get the 
package and integrated it to kernel?


Thanks in advance,
Gavin
-
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: GPLv3 dispute solution - new open source license?

[Alexandre Oliva]

On Jun 18, 2007, [EMAIL PROTECTED] wrote:

> On Mon, 18 Jun 2007, Joshua David Williams wrote:
>> On 6/18/07, Carlo Wood <[EMAIL PROTECTED]> wrote:
>> 
>>> Now, writing yet another license for the linux kernel is
>>> therefore NOT the solution - if you get my drift.
>> 
>> The new license could be written to be compatible with both versions of the
>> GPL.

> no it couldn't

It could.  Just not as part of the same work.  I.e., it wouldn't be
compatible in both directions, so it wouldn't make some of the most
vocal Linux developers in that other thread happy.

But you could achieve one-way compatibility in various ways:

GPLv2+, after GPLv3 is published, and before there's a GPLv4, is
pretty much it.

One could also come up with any license that permits use under the
terms of the GPLv2 or the GPLv3.

One could also dual-license under GPLv2 and GPLv3.

FWIW, IANAL.

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

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

[Alexandre Oliva]

On Jun 18, 2007, [EMAIL PROTECTED] wrote:

> On Tue, 19 Jun 2007, Johannes Stezenbach wrote:
>>> But since the software is good, and moving to another software
>>> would be costly in various dimentions, the vendor has an incentive
>>> to stick with the software they have.

> but if regulations or other contracts require tamper-resistant
> hardware they have no choices other then to fork the existing GPLv2
> versions or switch to alternate options for anything that switches to
> GPLv3

Where by "alternate options" I hope you mean non-copyleft or
tivoizable (copyleft by definition) software, or (newer versions of)
the same software they already use, but in ROM.  (I point this out
because people keep forgetting all the available options when they
claim to enumerate all available options ;-)

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

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

[Alexandre Oliva]

On Jun 18, 2007, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 18, 2007, Alexandre Oliva wrote:

>> People talk a lot about TiVo here, but do they the faintest idea of
>> how the conversations with TiVo are proceeding?  I thought so...

> Oh, if you know something we don't, could you please fill us in?

Honestly, I don't know either.  But I get an impression that there are
conversations underway.

> And who was it who coined the "Tivoization" term, thus putting
> TiVo into focus?

AFAIK TiVo invented the practice, did they not deserve the credit?

> Hm, you only talk about people who already use free software,
> but I tried to make you aware of the importance of
> _promoting_ free software, i.e. winning new people and
> companies for the free software idea.

Aah, I see.  Indeed, I'd missed that aspect.  Sorry about that.

My take on it is that bringing free loaders in doesn't help us much,
and bringing them in in a way that they don't learn the essential
aspects of the community will hurt the community in the long run.

So they must become aware that respecting others' freedoms is not only
the right thing to do, from a moral and ethical standpoint, but also
that this is precisely what enables our community to thrive, and to
enable everyone to get the best out of the software we cooperate to
develop.

> I think the majority of embedded devices still run proprietary
> RTOSes, and the majority of desktops still run Windows or Mac OS.
> Don't you want to change that?

Sure.  But getting those companies to adopt Free Software in a way
that turns it into non-Free Software doesn't change that in any way.

Of course we might get some additional contributions here and there,
but then more and more users would still be stuck, unable or limited
in the ways and incentives they have to participate in our community.
Permitting this is very short-sighted.  It might bring us apparent
advantages in the short run, but the more such disrespects there are,
the more there will be, and the fewer users will be able to become
developers.  In the end, this may kill the whole process, in a tragedy
of the commons.  In the article linked below, I argue this very point,
comparing how the demand for respecting users' freedoms is what keeps
the free-loaders away and makes the GPL the most cost-effective
license for software development, compared with permissive licenses
and non-Free licenses.  The very same arguments apply to a comparison
between a license that permits tivoization and one that doesn't,
because the latter is more likely to have more contributors to share
the load, and both equally reduce the likelihood of unmergeable forks.
http://www.lsd.ic.unicamp.br/~oliva/papers/free-software/BMind.pdf

> if you raise the entry barrier too high, they won't get started at
> all.

I acknowledge this argument, but I hear the same arguments against the
GPLv2, claiming the barrier is too high, and it's not from people who
believe that tivoization is already prohibited.

> They are aware of the trend towards Linux, but are afraid that the
> obligations of the GPL might be impractical for them.  Then they
> only have the choice to not use Linux, or to use "creative
> workarounds".

Or to respect users' freedoms, enabling/motivating those users to
become developers in our community.

> It's true that what these companies do might have little direct
> benefit for users buying their products, however the long term
> benefits of getting the people in these companies exposed to free
> software ideas, and in contact with the free software community, can
> only be positive

As long as they understand how the community works, be it from the
moral and ethical standpoint, be it from the pragmatic standpoint.  In
both cases, the end result is that they learn that, when they share
and cooperating, respecting users freedoms (enabling and providing
incentive for them to improve the software), everybody wins,
themselves included.

>> So you see, the picture of anti-tivozation is not as bleak as people
>> try to frame it.  In fact, it's not bleak at all.  If one out of 10,
>> maybe even 1 out of 100 vendors start respecting users' freedoms, when
>> faced with anti-tivoization provisions, the community will already win
>> big time, because each vendor is likely to have thousands of
>> customers, some of which will use the freedoms to serve the goals of
>> the community, in the very terms the community claims to care about.

> Does this multiplicator also apply to new companies
> which start using free software for their products?

Of course, even more so!  Then you win not only the contributions from
the user, but also from the company itself, which you didn't have
before.

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

Re: How to improve the quality of the kernel?

[Natalie Protasevich]

On 6/18/07, Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:

> -Message d'origine-
> De : Natalie Protasevich [mailto:[EMAIL PROTECTED]
> Envoyé : 18 juin 2007 18:56
>
> On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:
> > >> > So if you make changes to random-driver.c you can do `git-log
> > >> > random-driver.c|grep Tested-by" to find people who can test your
> > >> > changes for you.
> > >>
> > >> You would'nt even need to search in GIT.  Maybie even when ever a
> > >> patchset is being proposed a mail could be sent to appropriate
> > >> hardware/or feature pseudo-auto-generated mailing-list?
> > >>
> > >> On lkml I mostly try to follow patches/bugs associated with
> > >> hardware I use.  Why not try to automate the process and get more 
testers in?
> > >>
> > >
> > > I think this is an excellent point. One data point could be a field
> > > in bugzilla to input the hardware information. Simple query can
> > > select common hardware and platform. So far it's not working when
> > > hardware is just mentioned in the text part.
> >
> > if it's free text it'll be useless for search ... I suppose we could
> > do drop-downs for architecture at least? Not sure much beyond that
> > would work ... *possibly* the common drivers, but I don't think we'd
> > get enough coverage for it to be of use.
> >
> How about several buckets for model/BIOS version/chipset
> etc., at least optional, and some will be relevant some not
> for particular cases. But at least people will make an
> attempt to collect such data from their system, boards, etc.

How about an easy way to send multiple hardware profiles to your bugzilla user 
account simultaniously linked to an online pciutils database and/or an hardware 
list database similar to overclocking web sites and why not even with a link to 
the git repository when possible?

A some sort of really usefull "send your profile" of RHN that would link the driver 
with the discovered hardware and add you to appropriate mailing lists to test patches/help 
reproducing & solving problems/etc.

In the end plenty of statistics and hardware compatibility list could be made.  
For example, that would make my life easier knowing what level of compatibility 
Linux can offer for old HP9000 K-boxes that we still have running at the office 
and presumably get people to contact to get help?


This is definitely something that can be done (and should) - well,
especially having ability search by certain criteria - then all sorts
of statistics and databases can be created.
Everything that helps  to find a way to work on a patch and to test
easier should be done to make bug fixing easier and even possible.
Often times the most knowledgeable people are not able to make quick
fix just because there is no way to reproduce the case or get access
to HW.

--Natalie
-
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: v2.6.21.4-rt11

[Siddha, Suresh B]

On Mon, Jun 18, 2007 at 10:59:21AM -0700, Christoph Lameter wrote:
>   for_each_domain(this_cpu, sd) {
> - if (sd->flags & SD_BALANCE_NEWIDLE) {
> + if (sd->flags & SD_BALANCE_NEWIDLE)
>   /* If we've pulled tasks over stop searching: */
>   pulled_task = load_balance_newidle(this_cpu,
>   this_rq, sd);
> - if (time_after(next_balance,
> -   sd->last_balance + sd->balance_interval))
> - next_balance = sd->last_balance
> - + sd->balance_interval;
> - if (pulled_task)
> - break;
> - }
> + if (time_after(next_balance,
> +   sd->last_balance + sd->balance_interval))
> + next_balance = sd->last_balance
> + + sd->balance_interval;

don't we have to do, msecs_to_jiffies(sd->balance_interval)?

thanks,
suresh
> + if (pulled_task)
> + break;
>   }
>   if (!pulled_task)
>   /*
-
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: Questions on one PowerPC assembly instruction from hash_page

[gshan]

Mikael Pettersson wrote:

On Mon, 18 Jun 2007 16:33:22 +0800, gshan <[EMAIL PROTECTED]> wrote:
  
I can't understand the following instructions from 
arch/ppc/mm/hashtable.S::hash_page. If I got the right design, the 
following instruction is to get the PMD (Page Middle Descritor) because 
Linux for 32-bits PowerPC cut page table into 3 domains: root, PMD, PTE. 
The top bits (22 to 31 bit) is the index for PMD, and the next 10 bits 
(12 to 21 bit) is the index for PTE in the associative PMD. The 
remaining 12 bits (0 to 11 bit) indicated the page size (4KB). However, 
the following instruction polled [8-17] bits instead of [22-31] bits as 
expected. Anybody could give me answer?


r4 is the address that caused the DSI
r5 is the address of swapper_pg_dir if we are under kernel mode.

rlwimi r5,r4,12,20,29 /* insert top 10 bits of address */



POWER/PowerPC has an insanely broken bit numbering scheme, in
which the most significant bit has number 0 (or is it 1?),
and the least significant bit has number N-1 (or is it N?)
where N is number of bits in a word.

The fact that you refer to the top bits as 22-31 makes me
suspect that you haven't compensated for this quirk.

/Mikael
  
Mikael, Thanks a lot. I understood why the instruction is there. So the 
0-11 bits are used as address index for PMD. swapper_pg_dir is 4KB large 
and there are 1K PMDs inside swapper_pg_dir. So 10 bits (0-9 bits) are 
used as index for PMD, right?

-
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: v2.6.21.4-rt11

[Siddha, Suresh B]

On Tue, Jun 19, 2007 at 07:22:32AM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Jun 18, 2007 at 10:59:21AM -0700, Christoph Lameter wrote:
> > I think the check in idle_balance needs to be modified.
> > 
> > If the domain *does not* have SD_BALANCE_NEWIDLE set then
> > next_balance must still be set right. Does this patch fix it?
> 
> Is the ->next_balance calculation in idle_balance() necessary at all?
> rebalance_domains() would have programmed ->next_balance anyway, based
> on the nearest next_balance point of all (load-balance'able) domains.
> By repeating that calculation in idle_balance, are we covering any corner 
> case?

rebalance_domains() have programmed ->next_balance based on 'busy' state.
And now, as it is going to 'idle', this routine is recalculating
the next_balance based on 'idle' state.

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

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

[David Schwartz]

> This is a very limited reading of the GPL that leaves out one of its
> most important provisions: the bit about "no further restrictions".

Why is the fact that only the root user can load a kernel module not a
further restriction? Simple -- anyone who is bothered by that restriction
can remove it on any hardware for which they have the right to load modified
software. Anyone who does not have the right to load modified software on
some hardware simply does not have the right to change it.

Why is that not a "further restriction"? It means that I can't load kernel
modules on hardware that I don't have the right to load modified software
on.

> > The GPL was never, until GPLv3, about who gets to make
> > authorization decisions.

> I can agree with that.  As long as the authorization decisions are not
> used as means to deprive users' of the freedoms that must not be
> restricted, they can be whatever the distributor fancies.

Right, which is the freedom to modify the software. The freedom to get the
source code. The freedom to use the source code however you want, absent
legitimate authorization decisions to the contrary.

> > You are taking my claim out of contect. I am distinguishing
> > legal obstacles
> > from *authorization* obstacles, not technical obstacles.
>
> It doesn't matter how elaborate the excuse to disrespect the freedoms
> of the user is.  If there are further restrictions to them, then this
> violates the spirit, if not the letter, of the GPL.

I agree. However, "you can't load your modified sofware on *MY* hardware" is
not a further restriction. If it was, we get absurdities.

> >> Someone else's hardware is just a distraction.  You're not a user of
> >> software on someone else's hardware.  You have no rights over that.
>
> > You are. In the case of TiVo, the hardware (specifically the right
> > to decide what software runs on that hardware) is someone
> > else's. That is part of the bundle of rights that owning a piece of
> > hardware includes. That is a right you simply do not have with TiVo.

> Ah, ok, so I was sloppy above and you caught that.

> If someone else places hardware on your home for you to use, even if
> they still own it, then you can be a user of someone else's hardware.

Definitely.

> And at that point the GPL kicks in, because the software was
> distributed to you (even if the hardware wasn't sold), and with the
> distributed software come the freedoms, which, per the GPL, the
> distributor must not disrespect.

Absolutely.

> >> Tivoizers say "hey, you can still modify and run the software, just
> >> not on *this* hardware".

> Tivoization is treating the hardware that comes along with the
> software as if it was different from others.  But it isn't.

Of course it is. They have the authorization right on that hardware, and
they don't have that right on my laptop. For any piece of hardware, there
has to be someone who decides who can and can't choose what software runs on
that hardware.

> > Exactly. The GPL is about rights that apply to *all* hardware,
> > not some one
> > specific piece.

> Exactly!  Just like the GPL doesn't permit the distributor to state
> "BTW, you can't install or run this software on your mother's
> computer", it doesn't permit the distributor to state "BTW, you can't
> install or run this software on this computer I'm selling you".

That would mean it doesn't permit the distribute to state "BTW, you can't
install, modify or run this software on *OUR* computers that run our
corporate network". Don't you see how obviously absurd that is?

Someone has to be authorized to decide what software runs on some particular
piece of hardware. The GPL cannot mean that other people get to modify and
run software on that particular piece of hardware.

> The
> "no further restrictions" applies equally to all computers.  It's not
> just because you have some control over some particular hardware that
> you deliver along with the software that you're entitled to use that
> to limit the user's freedoms.

I agree. However, that doesn't mean that people who own or control
particular pieces of hardware can't put authorization barriers that prevent
you from running whatever software you want on thos pieces of hardware.

> > Which is a massive departure from the previous GPL spirit which
> > was about
> > being able to use the software on *ANY* hardware you
> > controlled, not some
> > special pieces more than others.

> It doesn't make the sold hardware special.  How come you think it
> does?

Because it becomes the only piece of hardware in the entire universe on
which the GPL gives you the right to run the software. On every other piece
of hardware, you must obtain that right from whoever owns the right to
decide what software runs on that hardware.

> It's exactly the opposite.  It just says the distributor can't
> make the hardware special, so as to restrain the users' freedoms that
> are inseparable from the software.

Don't you see that the rule that 

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

[David Schwartz]

> David Schwartz writes:

> >> First, end users buy and use the hardware in question.  It does not
> >> belong to Tivo, so the analogy to his laptop fails there.

> > No, this is incorrect. They buy *some* of the rights to the
> > hardware but not
> > all of them. Specifically, they do not buy the right to choose
> > what software
> > runs on that hardware. That right is still owned by TiVo.

> Do you have a reference to the contract establishing that cession of
> rights from the buyer to Tivo?

No, and I submit that this is at least arguably something wrong that TiVo is
doing. Note that Microsoft does this too when you buy an Xbox. It has
nothing to do with the GPL.

> To the extent that some contract
> purports to restrict the user in ways contrary to the GPL, I suspect
> Tivo might have a hard time defending it in court.

I agree, however, this doesn't restrict the user in ways contrary to the
GPL. The GPL does not say that you have to be allowed to modify the Linux
running on some particular piece of hardware because that is a legitimate
authorization decision. TiVo not letting you change the software is the same
as me not letting you change the software on my laptop.

> > You can argue that TiVo is being dishonest, breaking the law,
> > being immoral,
> > or whatever in retaining this right or in failing to disclose that they
> > retain it. But you cannot coherently deny that TiVo retains
> > this right when
> > they sell certain other rights to the hardware.

> By the first sale doctrine, someone who buys an item has practically
> unlimited rights to deal with it or dispose of it as the buyer wishes.

This is solely a right against copyright claims. You would be correct if
TiVo were going to sue you for violating some copyright they hold in the
hardware or software if you modified the software.

> The only things that would restrict that are statute or a contract
> entered as part of the sale -- most likely a EULA or other shrink-wrap
> agreement.  Given that most such recognized agreements deal with
> software or services rather than hardware, I am not sure a court would
> recognize a hardware EULA as being binding.  (I suspect this is the
> direction you were heading with the paragraph below.)

Yep, but that has nothing whatsoever to do with the GPL. The exact same
argument applies with the Xbox. It's about whether authorization to modify a
device should or must come with buying that device.

The GPL was never about allowing you to load modified software onto hardware
where the legitimate creators/owners of that hardware say, "no, you may not
modify the software running on this hardware".

DS


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

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

[Alexandre Oliva]

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

> On Monday 18 June 2007 19:31:30 Alexandre Oliva wrote:
>> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

>> Actually, just think of how many times you've heard the argument "I
>> can't give you the source code for this driver/firmware/etc under the
>> GPLv2 because the law says so."

> Sorry to tell you this, but anyone that makes a modification to GPLv2 covered 
> code and distributes that modification is bound by the license.

Of course I know that.  I'm not the one making those arguments.
And then, not all of those pieces of code are indeed moficiations of
GPLv2-covered code, so your objection is off target.

>> > b) I think you're simply wrong in your math. I think more people
>> > like the middle-ground and not-frothing-at-the-mouth spirit of "open
>> > source" over the religious dogma of "free software".
>> 
>> It looks like the math you're talking about is in no way related with
>> anything I've argued about.  You seem to be thinking about the number
>> of people who claim to be on the "free software" or "open source"
>> sides, but I can't fathom in what way this is related with whether you
>> get more or less contributions from users as a consequence of users'
>> being permitted to tinker with the free software in their own devices.

> "More Developers" (either "Free Software" or "Open Source") == "More 
> Contributions"

> That equation is very simple to understand - claiming its wrong is impossible.

YES!  Thank you!  This is exactly the point I'm trying to make.

Now can you please explain this to Linus in terms that his brain won't
dismiss as "coming from a fundamentalist"?

> Apparently because you can't admit that a good reason *IS* a good reason when 
> it conflicts with your belief that the FSF is correct.

No, seriously.  Linus is disputing the equation above, dismissing my
various attempts to show it to him, whenever it appears in teh context
of tivoization, apparently because it doesn't match his moral belief
that tivoization ought to be permitted on his moral grounds.

> PS: I know I've said I'm done with this conversation, but this is like a bad 
> habit. I just couldn't help myself.

You've helped me a lot while at that.  Thanks!

I hope this helps others fundamentalist anti-fundamentalists :-) see
reason too.

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

[David Schwartz]

> The box could even be sold by third party vendors, I think they may even
> have started off that way, my old Series 1 had a big Philips logo on it.
> So now we make sure that this hardware refuses to boot any unsigned
> code, but it wasn't shipped containing GPLv3 software, so it's license
> terms simply does not apply.
>
> The software is shipped on a ROM card which can no longer be modified by
> the manufacturer or any third party, so it would seem to comply with the
> GPLv3. I can even imagine that the hardware is really general purpose
> but the ROM is encrypted so that only the BIOS/bootloader can unlock it.
>
> So the GPLv3 seems to fall short on actually preventing tivoization. It
> just requires an extra layer of indirection, ship hardware seperately
> from software.
>
> Jan

If this flaw is still the latest GPLv3 drafts, it should be fixed. It's a
simple, technical error that can easily be rectified.

I don't have the latest draft handy, but my recollection is that it talks
about software that is "transferred along with" hardware. What it should say
is object code that contains activation logic for hardware.

That is, if I ship the Linux kernel (assuming for the moment the Linux
kernel was under GPLv3) with special activation logic to run on platforms X,
Y, and Z, then the source code should have to include how to make my changes
have that same special activation logic for those same platforms.

If the GPLv3 doesn't do that, it's broken.

Note that I'm not opining on whether this is a good thing or a bad thing.
But people who choose the GPLv3 because they want to prohibit tivoization of
their software should in fact get that prohibition.

DS


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

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

[Alexandre Oliva]

On Jun 18, 2007, Joshua David Williams <[EMAIL PROTECTED]> wrote:

> The Open Source Definition

... derived from the Debian Free Software Guidelines, engineered to
reflect the Free Software definition ...

> wrote:

>> 9. License Must Not Restrict Other Software

>> Yes, the GPL is conformant with this requirement. Software linked
>> with GPLed libraries only inherits the GPL if it forms a single work,
>> not any software with which they are merely distributed.

> The way I understand it, programs licensed under the GPLv3 are *not* open 
> source software. FSF is so caught up in their own agenda that they're 
> forgetting the whole point - the freedom of choice.

Err...  Excuse me?  Whole point for whom?

Free Software is not about freedom of choice.  That's an OSI slogan
for "if you like, you can shoot your own foot, regardless of whether
the shrapnel hurts people around you".
http://www.fsfla.org/?q=en/node/139#1

Free Software is about respect for the four freedoms.


I don't think the FSF is at all concerned whether GPLv3 complies with
the OSD.  They couldn't care less.  It was OSI that tried to create a
definition that matched exactly the meaning of the Free Software
definition under "more objective criteria".  We already know they
failed, since the Reciprocal Public License is accepted as an OSS
license, but it's a non-Free Software license.  There may be other
examples.


That said, since a number of people already understand the GPLv2
prohibits tivoization, your argument means that either the comment in
the OSD is wrong, and GPLv2 already fails to match the OSD, or that
GPLv3 complies with it in just the same way.

-- 
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/PATCH] Documentation of kernel messages

[Arjan van de Ven]

On Mon, 2007-06-18 at 15:53 +0200, holzheu wrote:
> On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> > On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > > Hi Gerrit,
> > > 
> > > The common thing of your and our approach is, that we need an ID to
> > > identify a message either by:
> > 
> > 
> > Maybe I am missing something big, but why is an ID needed?
> > The message IS the ID right? That's the only thing that is robust
> > against code moving about
> 
> Yes. As already discussed with Pavel, it is one option to use the format
> string of the message as message ID. The disadvantage compared to
> message IDs like hashes is, that format strings might be even less
> unique than hashes 

if the hash comes from the string in the first place I have a hard time
believing that.

> and it's probably less convenient for searching by
> operators.

I'm not convinced of that...

> 
> An operator has to issue either:
> 
> >> info lp.4711
> or
> >> info "lp0: on fire"

well surely the messages are caught by some userspace program,
right? (like syslog).. that can do the lookup and make it all
conveniently lookup-able and cross-referencable etc etc

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.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-mm 00/25] High resolution timer updates and x86_64 support - V2

[Arjan van de Ven]

On Mon, 2007-06-18 at 16:06 -0400, [EMAIL PROTECTED] wrote:
> On Sat, 16 Jun 2007 10:36:00 -, Thomas Gleixner said:
> > The following patch series contains:
> > 
> > - dyntick bugfixes for -mm (caused by the cpuidle changes in ACPI)
> > 
> > - updates and improvements to high resolution timer / dynticks 
> > 
> > - high resolution timer / dynticks support for x86_64
> 
> Am running with the 22-rc4-mm2-hrt4 patch on my Latitude D820.  Mostly seems
> to work, but for some reason the Intel 'powertop' util thinks it's 100% busy:
> 
>  PowerTOP version 1.7   (C) 2007 Intel Corporation
> 
> Cn  Avg residency (5s)  P-states (frequencies)
> C0 (cpu running)(100.0%)
> C10.0ms ( 0.0%) 2.00 Ghz 0.0%
> C20.0ms ( 0.0%) 1.67 Ghz 0.0%
> C30.0ms ( 0.0%) 1333 Mhz 0.0%
> 1000 Mhz   100.0%
> 
> In reality:


looks like something broke the /proc/acpi/processor/*/power file
data

can you check in that file to see if there is actual C-state time
accounting going on?
(it is in mainline, so if it's not then it's an -mm or -hrt bug)

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.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: How to improve the quality of the kernel?

[Fortier,Vincent [Montreal]]

> -Message d'origine-
> De : Natalie Protasevich [mailto:[EMAIL PROTECTED] 
> Envoyé : 18 juin 2007 18:56
> 
> On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:
> > >> > So if you make changes to random-driver.c you can do `git-log 
> > >> > random-driver.c|grep Tested-by" to find people who can test your 
> > >> > changes for you.
> > >>
> > >> You would'nt even need to search in GIT.  Maybie even when ever a 
> > >> patchset is being proposed a mail could be sent to appropriate 
> > >> hardware/or feature pseudo-auto-generated mailing-list?
> > >>
> > >> On lkml I mostly try to follow patches/bugs associated with 
> > >> hardware I use.  Why not try to automate the process and get more 
> > >> testers in?
> > >>
> > >
> > > I think this is an excellent point. One data point could be a field 
> > > in bugzilla to input the hardware information. Simple query can 
> > > select common hardware and platform. So far it's not working when 
> > > hardware is just mentioned in the text part.
> >
> > if it's free text it'll be useless for search ... I suppose we could 
> > do drop-downs for architecture at least? Not sure much beyond that 
> > would work ... *possibly* the common drivers, but I don't think we'd 
> > get enough coverage for it to be of use.
> >
> How about several buckets for model/BIOS version/chipset 
> etc., at least optional, and some will be relevant some not 
> for particular cases. But at least people will make an 
> attempt to collect such data from their system, boards, etc.

How about an easy way to send multiple hardware profiles to your bugzilla user 
account simultaniously linked to an online pciutils database and/or an hardware 
list database similar to overclocking web sites and why not even with a link to 
the git repository when possible?

A some sort of really usefull "send your profile" of RHN that would link the 
driver with the discovered hardware and add you to appropriate mailing lists to 
test patches/help reproducing & solving problems/etc.

In the end plenty of statistics and hardware compatibility list could be made.  
For example, that would make my life easier knowing what level of compatibility 
Linux can offer for old HP9000 K-boxes that we still have running at the office 
and presumably get people to contact to get help?

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

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

[Alexandre Oliva]

On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> > Any number of ways. For example, you probably don't connect the
>> > serial ports
>> > to a device I have access to.

>> But you're not the user of the software on my laptop.  I am.

> Even when I get web pages from your web server?

Yes.  I'm (hypothetically) running the web server such that it serves
web pages to you or anyone else.  You don't become user of a software
just because you establish a network session with it.  You clearly
need more than that.

That said, the precise threshold isn't clear.  For complex web
applications that run part on the client and part on the server, or
even almost entirely on the server, one can argue that a user is
indeed using the software even though it runs mostly on the server.
Some people call this kind of situation the ASP loophole in the GPL.
I'm not sure I want to disturb users of this list with the details
about this, but I'd be pleased to discuss this off the list.

>> The requirements as to "installation information" apply to conveying
>> the program along with a user product.

> In other words, the GPLv3 *compels* a critical authorization decision to
> follow the physical possession of the device. Do you see that, as far as the
> GPLv2 is concerned, this is from outer space?

Not really.  When a user receives a copy of the software, there's
distribution going on, and that's when the user can start having any
expectations of having her freedoms respected as to that software.

>> > How exactly does the GPLv3 specify who should and should not be able to
>> > change the software on a particular physical machine?

>> IANAL, but my understanding is that (paraphrasing), when you convey
>> the software along with a user product, you must permit the recipient
>> of the software to install and run modified versions of the software
>> in the user product as well.

> Which is totally alien to everything in the GPLv2, word and spirit. It never
> required any authorization decisions be made any particular way, nor even
> hinted that authorization decisions were within its scope.

It's the authorization decisions that are alien to GPLv2.  That's just
yet another form of denying users the freedoms that they ought to
receive along with the software.

> What does the spirit of the GPLv2 say about who is authorized to modify the
> software on some particular piece of hardware?

It doesn't.  Why should it have to?  Whether someone is authorized or
not is a direct consequence of the freedoms.  The moment the software
was distributed to you, you're entitled to the freedoms.  Imposing
restrictions on them is a violation of the spirit, if not the letter,
of the license.

>> What if the authority that controls the use of the hardware is
>> forbidding from restricting this possibility by law?  By contractual
>> provisions?  By a patent license?  By a copyright license?

> Those kinds of things are totally alien to the GPL, which was about getting
> the source code and being able to modify it and use it on any hardware for
> which you were authorized to do so.

This is a very limited reading of the GPL that leaves out one of its
most important provisions: the bit about "no further restrictions".

> The GPL was never, until GPLv3, about who gets to make
> authorization decisions.

I can agree with that.  As long as the authorization decisions are not
used as means to deprive users' of the freedoms that must not be
restricted, they can be whatever the distributor fancies.

> You are taking my claim out of contect. I am distinguishing legal obstacles
> from *authorization* obstacles, not technical obstacles.

It doesn't matter how elaborate the excuse to disrespect the freedoms
of the user is.  If there are further restrictions to them, then this
violates the spirit, if not the letter, of the GPL.

>> Someone else's hardware is just a distraction.  You're not a user of
>> software on someone else's hardware.  You have no rights over that.

> You are. In the case of TiVo, the hardware (specifically the right
> to decide what software runs on that hardware) is someone
> else's. That is part of the bundle of rights that owning a piece of
> hardware includes. That is a right you simply do not have with TiVo.

Ah, ok, so I was sloppy above and you caught that.

If someone else places hardware on your home for you to use, even if
they still own it, then you can be a user of someone else's hardware.
And at that point the GPL kicks in, because the software was
distributed to you (even if the hardware wasn't sold), and with the
distributed software come the freedoms, which, per the GPL, the
distributor must not disrespect.

>> > And I think they change it utterly by treating one piece of hardware
>> > different from others for GPL purposes.

>> No, it's tivoization that does this.

> How so?

Like this:

>> Tivoizers say "hey, you can still modify and run the software, just
>> not on *this* hardware".

Tivoization is treating the 

Re: v2.6.21.4-rt11

[Srivatsa Vaddagiri]

On Mon, Jun 18, 2007 at 10:59:21AM -0700, Christoph Lameter wrote:
> I think the check in idle_balance needs to be modified.
> 
> If the domain *does not* have SD_BALANCE_NEWIDLE set then
> next_balance must still be set right. Does this patch fix it?

Is the ->next_balance calculation in idle_balance() necessary at all?
rebalance_domains() would have programmed ->next_balance anyway, based
on the nearest next_balance point of all (load-balance'able) domains.
By repeating that calculation in idle_balance, are we covering any corner case?

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

[Jan Harkes]

On Mon, Jun 18, 2007 at 08:31:30PM -0300, Alexandre Oliva wrote:
> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > In the GPLv3 world, we have already discussed in this thread how you can 
> > follow the GPLv3 by making the TECHNICALLY INFERIOR choice of using a ROM 
> > instead of using a flash device.
> 
> Yes.  This is one option that doesn't bring any benefits to anyone.
> It maintains the status quo for users and the community, but it loses
> the ability for the vendor to upgrade, fix or otherwise control the
> users.  Bad for the vendor.

Not really, Tivo could simply sell you a box without any installed
software. The actual software is mailed to you on a credit card sized
ROM when you activate service. When they want to (or need to) update the
software they send out a new ROM card, maybe yearly as part of the
service subscription renewal.

The box could even be sold by third party vendors, I think they may even
have started off that way, my old Series 1 had a big Philips logo on it.
So now we make sure that this hardware refuses to boot any unsigned
code, but it wasn't shipped containing GPLv3 software, so it's license
terms simply does not apply.

The software is shipped on a ROM card which can no longer be modified by
the manufacturer or any third party, so it would seem to comply with the
GPLv3. I can even imagine that the hardware is really general purpose
but the ROM is encrypted so that only the BIOS/bootloader can unlock it.

So the GPLv3 seems to fall short on actually preventing tivoization. It
just requires an extra layer of indirection, ship hardware seperately
from software.

Jan

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

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

[Alexandre Oliva]

On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> First, end users buy and use the hardware in question.  It does not
>> belong to Tivo, so the analogy to his laptop fails there.

> No, this is incorrect. They buy *some* of the rights to the hardware but not
> all of them.

Wow, really?  I thought TiVo actually sold the computer.

Not that it would make a difference as far as GPLv3 is concerned.
It's still a user product, and it still contains GPLed software, and
TiVo distributes that software to other users.

> But you cannot coherently deny that TiVo retains this right when
> they sell certain other rights to the hardware.

Heh.  I mis-parsed "sell rights to the hardware".  How can the
hardware buy something?


Whatever rights TiVo wants to retain or keep from the user is of
little concern here, as long as this doesn't get in the way of the
user's exercise of the freedoms that the GPL stands to defend.  If it
wants to retain more rights than that, then it may have to refrain
from using GPLed software, or face the risk of a court finding it
couldn't have done that in the first place.

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

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

[Michael Poole]

David Schwartz writes:

>> First, end users buy and use the hardware in question.  It does not
>> belong to Tivo, so the analogy to his laptop fails there.
>
> No, this is incorrect. They buy *some* of the rights to the hardware but not
> all of them. Specifically, they do not buy the right to choose what software
> runs on that hardware. That right is still owned by TiVo.

Do you have a reference to the contract establishing that cession of
rights from the buyer to Tivo?  To the extent that some contract
purports to restrict the user in ways contrary to the GPL, I suspect
Tivo might have a hard time defending it in court.

> You can argue that TiVo is being dishonest, breaking the law, being immoral,
> or whatever in retaining this right or in failing to disclose that they
> retain it. But you cannot coherently deny that TiVo retains this right when
> they sell certain other rights to the hardware.

By the first sale doctrine, someone who buys an item has practically
unlimited rights to deal with it or dispose of it as the buyer wishes.
The only things that would restrict that are statute or a contract
entered as part of the sale -- most likely a EULA or other shrink-wrap
agreement.  Given that most such recognized agreements deal with
software or services rather than hardware, I am not sure a court would
recognize a hardware EULA as being binding.  (I suspect this is the
direction you were heading with the paragraph below.)

Michael Poole

> I do in fact argue that there are things that are wrong with TiVo doing
> this. But they are not GPL-related things. I would make these same arguments
> if the TiVo contained no GPL'd software and I in fact do make them about
> products like the Xbox.
>
> DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexandre Oliva]

On Jun 18, 2007, [EMAIL PROTECTED] wrote:

> Ok, next question, could you do the same thing if you used a CD
> instead of a ROM?

Yes, I believe the very same reasoning applies.

> what makes a blob delivered via a network inherently different from
> the same blob delivered via a plugin ROM or CD?

Err...  Nothing, really, except that delivery over the network doesn't
even have a physical support that you might wish you could possibly
modify but Mother Nature won't let you.

What could make a difference, as far as GPLv3 is concerned, is that
conveyance over the network might be considered more easily separate
from the transaction involving the user product than receiving the CD
or the ROM chip along with it.

But then, a lot of it would depend on the the precise contractual
terms surrounding the transference of the user product, on intent and
how that's interpreted by courts, and on how good a justice money can
buy ;-)

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

[Kevin Bowling]

On 6/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:



> I just want software back. I think it is *wrong* for me to ask for
> anything else. It's literally my personal "moral choice": I think the
> hardware manufacturers need to make their _own_ choices when it comes to
> _their_ designs.

>  - I think that *technical*quality* is more important than *quantity*.

This argument fails to make the point you're trying to make.


No, it has been countered many times and you are simply proving your ignorance.


  you trade the potential contributions of all those users for the
  contributions of tivoizers, apparently assuming that all tivoizers
  would simply move away from the community, taking their future
  contributions away from your community, rather than moving to a
  position in which you'd get not only the contributions from the
  company itself, but also from all their users

and you say "oh, I don't care about quantity, I care about quality",
as if this somehow related with the above.


Being strictly pragmatic - what makes you think TiVoland is some
fledgling grounds of /expert kernel developers/ that are otherwise
deprived of contributing, unless they can illegally modify their TiVo?

Under GPLv2, we have the kernel modifications and can include them in
our software.  If you don't agree with TiVo, purchase an open product.
Download their kernel source and use it on your open product.  Pure
consumerism and capitalism at work.

The GPLv3 is a solution in search of a problem.  Worse, it creates
problems outside the grasp of your understanding.


Just do the math.  Hypothetically, Linux goes GPLv3, without
permission to tivoize.  TiVo has to decide among:

- switching to another kernel, no further contributions from them

Bad for us, bad for users.

- sticking with old version, no further usable contributions from them

Bad for us, bad for users.

- switching to ROM, still the same contributions from TiVo

Bad for users.

- no more tivoization, contributions from TiVo and users


Bad for us, bad for users.  Legitimate laws and practices require that
certain devices not be modified by end users.  Therefore TiVo fails
and contributions cease.


So, you see, in no case do you get more contributors while at the same
time losing TiVo's quality contributions.


No.  Outside of this FSF {academic,religious} diatribe, in the real
world, things aren't as you see them.  The fact is that these people
can get the code and contribute.  It just won't run on TiVo.  So don't
buy TiVo but use the code.  Problem solved, free software in action.


> In the GPLv3 world, we have already discussed in this thread how you can
> follow the GPLv3 by making the TECHNICALLY INFERIOR choice of using a ROM
> instead of using a flash device.

Yes.  This is one option that doesn't bring any benefits to anyone.
It maintains the status quo for users and the community, but it loses
the ability for the vendor to upgrade, fix or otherwise control the
users.  Bad for the vendor.


And users.  Don't spin the facts.

You are advocating things which hurt the end user, which the "Spirit"
should seek to help.  The GPLv3 is here to stroke the FSF ego because
they don't like how somebody has legally found a way to use free
software in a way they don't agree with.  Sort of like dynamite being
used violently...
-
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: PCI userland access non-mmap APIs, kernel access to legacy space

[Benjamin Herrenschmidt]

> But adding read/write is fine with me.  In fact, having read/write hooks 
> for the memory backed resource files is also nice, since it makes 
> dealing with them on the command line a bit easier.

Plan is to use iomap so I get both IO and MMIO for (almost) free :-)

> > Also, while at it, I would like to introduce a pair of in-kernel
> > interfaces:
> 
> What's the other half of the pair?

Heh, indeed, there is none, I initially had a separate function for mem
and for io and at the last minute though "ugh, let's just use a struct
resource !" :-)

> Yeah, sounds like a good additional abstraction for that interface.  
> Should make porting it to other arches easier (I talked with kyle about 
> this last week, so maybe this'll give him motivation to do it for 
> parisc).

Ok, good. I'll do some code asap.

Ben.


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

Re: [RFC] [PATCH] selective signal ptracing

[Benjamin Herrenschmidt]

On Mon, 2007-06-18 at 08:15 -0500, Josh Boyer wrote:
> On 6/16/07, Roland McGrath <[EMAIL PROTECTED]> wrote:
> > > What are the issues with arch like ARM ?
> >
> > The interesting class ARM belongs to is machines that don't (or don't
> > always) have hardware support for single-step.  Maintaining the status quo
> > of how PTRACE_SINGLESTEP functions on these machines is different in
> > implementation under utrace than it is for machines that always use
> > hardware support.  That is the only special complication for ARM, and it is
> > not really very complicated.  Apparently the way I described the issue in
> > the past was easily misunderstood.
> 
> That isn't just ARM.  There are some embedded PowerPC chips that lack
> an easily usable hardware single step.  Just an FYI.

Note that we could use xmon infrastructure for that ... Paul has the
whole shebang done in there, including emulating branches etc...

Ben.


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

Re: How to improve the quality of the kernel?

[Martin Bligh]

> Maybe searching free text fields can then be implemented.  Then every
> message exchange in bugzilla can be used for extracting such info -
> questions about HW specifics are asked a lot, almost in every one.
> It's a shame we cant' use this information. I was once searching for
> "VIA" and got "zero bugs found", but in reality there are hundreds!
> Probably something that makes sense to bring up with bugzilla project?

That should work now ... seems to for me.

http://bugzilla.kernel.org/buglist.cgi?query_format=advanced_desc_type=allwordssubstr_desc=_desc_type=substring_desc=VIA_version_type=allwordssubstr_version=_status=NEW_status=REOPENED_status=ASSIGNED_status=RESOLVED_status=VERIFIED_status=REJECTED_status=DEFERRED_status=NEEDINFO_status=CLOSED_to1=1=substring=_to2=1=1=1=substring==include_id===Now==both=doit=Bug+Number=noop=noop= 



Produces a metric-buttload of results. Go to the advanced search option
and do "A Comment" contains the string "VIA". By default "Status" is
only set to do open bugs, which you might want to change to all types.


Yes it works great! Thanks... I'd say this should be really a default
search, because first search screen is misleading - it promises find
all for any "words" :)


OK, or at the very least we can fix the text at least to indicate it'll
only search summaries (and likely only of open bugs at that ...)

M.
-
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: How to improve the quality of the kernel?

[Natalie Protasevich]

On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:

> Sure, simplicity is a key - but most of reporters on bugs are pretty
> professional folks (or very well rounded amateurs :) We can try still
> why not? the worst that can happen will be empty fields.

mmm. added complexity and interface clutter for little or no benefit
is what I'm trying to avoid - they did that in the IBM bugzilla and
it turned into a big ugly unusable monster. You can call me either
"experienced" or "bitter" depending what mood you're in ;-)

Not sure I'd agree that most of the bug submitters are all that
professional, it's a very mixed bag.

> Maybe searching free text fields can then be implemented.  Then every
> message exchange in bugzilla can be used for extracting such info -
> questions about HW specifics are asked a lot, almost in every one.
> It's a shame we cant' use this information. I was once searching for
> "VIA" and got "zero bugs found", but in reality there are hundreds!
> Probably something that makes sense to bring up with bugzilla project?

That should work now ... seems to for me.

http://bugzilla.kernel.org/buglist.cgi?query_format=advanced_desc_type=allwordssubstr_desc=_desc_type=substring_desc=VIA_version_type=allwordssubstr_version=_status=NEW_status=REOPENED_status=ASSIGNED_status=RESOLVED_status=VERIFIED_status=REJECTED_status=DEFERRED_status=NEEDINFO_status=CLOSED_to1=1=substring=_to2=1=1=1=substring==include_id===Now==both=doit=Bug+Number=noop=noop=

Produces a metric-buttload of results. Go to the advanced search option
and do "A Comment" contains the string "VIA". By default "Status" is
only set to do open bugs, which you might want to change to all types.


Yes it works great! Thanks... I'd say this should be really a default
search, because first search screen is misleading - it promises find
all for any "words" :)



> However, I've been working with other bugzillas (have to admit they
> were mostly company/corporate), where this was a required field that
> didn't seem to cause difficulties. I am planning to do some more
> research and get some more ideas from other bugzillas. I suppose we
> can have them discussed and revised sometime.

Would be good, thanks. I tend to favour keeping things as simple as
possible though, we have very little control over our users, and they're
a very broad base. Making the barrier to entry for use as low as
possible is the design we've been pursuing.


Actually, as long as search above is possible - it is going to work.

I must say the new bugzilla interface is very nice in general, and
well designed and easy to use.

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

Question about a strange behavior of copy_to_user() in ioctl call

[News Letter]

Hi,

I need some help here to understand copy_to_user(). I encountered a
strange copy_to_user() behavior when working on CentOS from Redhat
(kernel version 2.6.9-22.ELsmp, x86_64 CPU).

For a kernel module, I wrote a ioctl call to allow user mode program
to get some kernel data information. When a user program called the
ioctl, most of the time the ioctl failed with EFAULT, failed at
copy_to_user(). It succeeded a few times after a lot of running.

Failed message indicated copy_to_user() returned 3840 (which is
exactly what is asked to copy, PAGE_SIZE-256). The printed value of
the user pointer were identical for successful ioctl calls and failed
ioctl calls. Some relevant details are at the end of this email. I
tried with calloc(PAGE_SIZE, 1), static buffer and automatic variable
on stack in user mode program. They gave the same result.

I appreciate any help.

Best,
Jasper

The ioctl call structure is defined as follows,

struct ioctl_get_info
{
  ... /* some other information */
  unsigned long user_pointer;
  unsigned user_buffer_len;
  unsigned returned_len;
  ... /* some other information */
};

Inside kernel module, a page is allocated with :

static unsigned char *test_page;

static init_test(void)
{
  test_page = __get_free_pages(GFP_KERNEL, 0);
  if (!test_page)
 /* some error handling */
}

static int test_ioctl(struct inode * inode, struct file * filp,
unsigned int cmd_in, unsigned long arg)
{
  struct ioctl_get_info igi;
  unsigned size;
  unsigned long remain;

 size = IOC_SIZE(cmd_in);
 if (size != sizeof(igi))
   

 ... /* some sanity checking */

 if (!access_ok(VERIFY_READ, (char *)arg, size))
 {
 printk(KERN_INFO "...");
 return -EFAULT;
  }

  if (copy_from_user(, (char *)arg, size) != 0)
  {
  printk(... ...)
  return -EFAULT;
  }

  if (!access_ok(VERIFY_WRITE, (char *)igi.user_pointer, igi.user_buffer_len))
  {
  printk(...);
  return -EFAULT;
  }

  size = PAGE_SIZE - 256;
  if (size > igi.user_buffer_len)
 size = igi.user_buffer_len;
  printk("igi.user_pointer %p size %u\n", igi.user_pointer, size);
  if ((remain = copy_to_user((char *)igi.user_pointer, page + 256, size)) != 0)
  {
 printk ("Failed to copy from user at %p remain %lu asked %u\n",
igi.user_pointer, remain, asked);
/* failed here */
 return -EFAULT;
  }
   igi.returned_len = size;

  /* copy other information */

  return 0;
}
-
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: Device hang when offlining a CPU due to IRQ misrouting

[Darrick J. Wong]

On Mon, Jun 18, 2007 at 04:54:34PM -0700, Siddha, Suresh B wrote:

> > 
> > [  256.298787] irq=4341 affinity=d
> > 
> 
> And just to make sure, at this point, your MSI irq 4341 affinity
> (/proc/irq/4341/smp_affinity) still points to '2'?

Actually, it's 0xD.  From the kernel's perspective the mask has been
updated (and I even stuck a printk into set_msi_irq_affinity to verify
that the writes are happening) but ... the hardware doesn't seem to
reflect this.  I also tried putting read_msi_msg right afterwards to
compare contents, though it complained about all the MSIs _except_ for
4341.  (Of course, I could just be way off on the effectiveness of
that.)

--D


signature.asc
Description: Digital signature

Re: How to improve the quality of the kernel?

[Martin Bligh]

Sure, simplicity is a key - but most of reporters on bugs are pretty
professional folks (or very well rounded amateurs :) We can try still
why not? the worst that can happen will be empty fields.


mmm. added complexity and interface clutter for little or no benefit
is what I'm trying to avoid - they did that in the IBM bugzilla and
it turned into a big ugly unusable monster. You can call me either
"experienced" or "bitter" depending what mood you're in ;-)

Not sure I'd agree that most of the bug submitters are all that
professional, it's a very mixed bag.


Maybe searching free text fields can then be implemented.  Then every
message exchange in bugzilla can be used for extracting such info -
questions about HW specifics are asked a lot, almost in every one.
It's a shame we cant' use this information. I was once searching for
"VIA" and got "zero bugs found", but in reality there are hundreds!
Probably something that makes sense to bring up with bugzilla project?


That should work now ... seems to for me.

http://bugzilla.kernel.org/buglist.cgi?query_format=advanced_desc_type=allwordssubstr_desc=_desc_type=substring_desc=VIA_version_type=allwordssubstr_version=_status=NEW_status=REOPENED_status=ASSIGNED_status=RESOLVED_status=VERIFIED_status=REJECTED_status=DEFERRED_status=NEEDINFO_status=CLOSED_to1=1=substring=_to2=1=1=1=substring==include_id===Now==both=doit=Bug+Number=noop=noop=

Produces a metric-buttload of results. Go to the advanced search option
and do "A Comment" contains the string "VIA". By default "Status" is
only set to do open bugs, which you might want to change to all types.


However, I've been working with other bugzillas (have to admit they
were mostly company/corporate), where this was a required field that
didn't seem to cause difficulties. I am planning to do some more
research and get some more ideas from other bugzillas. I suppose we
can have them discussed and revised sometime.


Would be good, thanks. I tend to favour keeping things as simple as
possible though, we have very little control over our users, and they're
a very broad base. Making the barrier to entry for use as low as
possible is the design we've been pursuing.

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

2.6.21.5-rt15: BUG: scheduling with irqs disabled

[Fernando Lopez-Lezcano]

Hi Ingo, I'm seeing this on 2.6.21.5-rt14 and 2.6.21.5-rt15, this
problem did not happen in 2.6.21.3-rt9 (last I checked on this
hardware). The computer is an athlon x2 and eth0 is "alias eth0 skge",
the BUGs trigger on network activity (but not a constant stream of
them)...

BUG: scheduling with irqs disabled: IRQ-20/0x/1246
caller is wait_for_completion+0x65/0x9b
 [] dump_trace+0x64/0x105
 [] show_trace_log_lvl+0x18/0x2c
 [] show_trace+0xf/0x11
 [] dump_stack+0x12/0x14
 [] schedule+0x86/0xfa
 [] wait_for_completion+0x65/0x9b
 [] set_cpus_allowed+0x71/0x8f
 [] do_softirq_from_hardirq+0xbd/0xda
 [] do_irqd+0x1ff/0x24d
 [] kthread+0xb0/0xd8
 [] kernel_thread_helper+0x7/0x10
 ===
[EMAIL PROTECTED] ~]# cat /proc/interrupts
   CPU0   CPU1
  0:251  1   IO-APIC-edge  timer
  1:  0  2   IO-APIC-edge  i8042
  6:  0  6   IO-APIC-edge  floppy
  7:  1  0   IO-APIC-edge  parport0
  8:  0  1   IO-APIC-edge  rtc
  9:  0  0   IO-APIC-fasteoi   acpi
 12:  0  4   IO-APIC-edge  i8042
 14:  0   3724   IO-APIC-edge  ide0
 16:   7591   5688   IO-APIC-fasteoi   ohci_hcd:usb1, libata
 17:  1238   IO-APIC-fasteoi   ohci_hcd:usb2, NVidia
CK8S
 18:  0  3   IO-APIC-fasteoi   ehci_hcd:usb3
 19:  0  0   IO-APIC-fasteoi   libata
 20:  0   3028   IO-APIC-fasteoi   eth0
 21:  0  2   IO-APIC-fasteoi   ohci1394, ICE1712
 22:  17253   5916   IO-APIC-fasteoi   [EMAIL PROTECTED]::01:00.0
NMI:  0  0
LOC:  32953  36858
ERR:  1
MIS:  0

-- Fernando


-
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: regression tracking (Re: Linux 2.6.21)

[Martin Bligh]

Linus Torvalds wrote:


On Thu, 14 Jun 2007, Oleg Verych wrote:

I'm seeing this long (198) thread and just have no idea how it has
ended (wiki? hand-mailing?).


I'm hoping it's not "ended".

IOW, I really don't think we _resolved_ anything, although the work that 
Adrian started is continuing through the wiki and other people trying to 
track regressions, and that was obviously something good.


But I don't think we really know where we want to take this thing in the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is open. 
It sure doesn't seem to exist right now ;)


I know you hate bugzilla ... but at least I can try to make that bit
of the process work better.

The new version just rolled out does have a simple "regression" checkbox
(and you can search on it), which will hopefully help people keep track
of the ones already in bugzilla more easily.

Thanks to Jon T, Dave J et al. for helping to figure out methods and
implement them.

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

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

[Bron Gondwana]

On Mon, Jun 18, 2007 at 01:03:40PM -0700, David Schwartz wrote:
> So you're arguing two sides of no argument at all.

Yeah, pretty much.  I take back my arguments in the previous
couple of my posts up this thread.  They don't actually hold
together!  Sorry for wasting your time correct me.

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: How to improve the quality of the kernel?

[Natalie Protasevich]

On 6/18/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:



On Mon, 18 Jun 2007, Martin Bligh wrote:
>
> Sorry to be a wet blanket, but I've seen those sort of things
> before, and they just don't seem to work, especially in the
> environment we're in with such a massive diversity of hardware.

I do agree. It _sounds_ like a great idea to try to control the flow of
patches better, but in the end, it needs to also be easy and painfree to
the people involved, and also make sure that any added workflow doesn't
require even *more* load and expertise on the already often overworked
maintainers..

In many cases, I think it tends to *sound* great to try to avoid
regressions in the first place - but it also sounds like one of those "I
wish the world didn't work the way it did" kind of things. A worthy goal,
but not necessarily one that is compatible with reality.

Linus



Sure, simplicity is a key - but most of reporters on bugs are pretty
professional folks (or very well rounded amateurs :) We can try still
why not? the worst that can happen will be empty fields.

Maybe searching free text fields can then be implemented.  Then every
message exchange in bugzilla can be used for extracting such info -
questions about HW specifics are asked a lot, almost in every one.
It's a shame we cant' use this information. I was once searching for
"VIA" and got "zero bugs found", but in reality there are hundreds!
Probably something that makes sense to bring up with bugzilla project?

However, I've been working with other bugzillas (have to admit they
were mostly company/corporate), where this was a required field that
didn't seem to cause difficulties. I am planning to do some more
research and get some more ideas from other bugzillas. I suppose we
can have them discussed and revised sometime.

--Natalie
-
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: How to improve the quality of the kernel?

[Linus Torvalds]

On Mon, 18 Jun 2007, Martin Bligh wrote:
> 
> Sorry to be a wet blanket, but I've seen those sort of things
> before, and they just don't seem to work, especially in the
> environment we're in with such a massive diversity of hardware.

I do agree. It _sounds_ like a great idea to try to control the flow of 
patches better, but in the end, it needs to also be easy and painfree to 
the people involved, and also make sure that any added workflow doesn't 
require even *more* load and expertise on the already often overworked 
maintainers..

In many cases, I think it tends to *sound* great to try to avoid 
regressions in the first place - but it also sounds like one of those "I 
wish the world didn't work the way it did" kind of things. A worthy goal, 
but not necessarily one that is compatible with reality.

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: Change in default vm_dirty_ratio

[Arjan van de Ven]

> Is it good to keep tons of dirty stuff around? Sure. It allows overwriting 
> (and thus avoiding doing the write in the first place), but it also allows 
> for a more aggressive IO scheduling, in that you have more writes that you 
> can schedule.


it also allows for an elevator that can merge more so that there are
less seeks...


so it's not all pure artificial ;(

I really don't like doing just-for-benchmark tuning ... but I wonder how
much real workloads this will get too (like installing or upgrading a
bunch of rpms)

As for the smoother IO thing.. there's already a kernel process that
writes this lot out after 5 seconds... so that ought to smooth some of
this out already I would hope.

(I'm not arguing this change is wrong, I'm just grinding my teeth on how
long updating rpms already takes... for no apparent reason)

-
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/PATCH] Documentation of kernel messages

[Tim Bird]

Gerrit Huizenga wrote:
> Further, yet another kernel config option could allow distros to output
> the calculated MD5 sum to be printed, much like we do with timestamps
> today.

> Comments?

Would the compiled-in text then also become replaceable?
Or is the MD5 sum output expected to be in addition to
the regular English message?

If message replacement at compile-time is supported, this
could allow for creating "short" versions of the messages,
which could have a beneficial impact on kernel size.

Right now, it is possible to completely disable printks
and re-claim about 100K of memory.  However, in some
embedded configurations, even if you are space-constrained
it's desirable to retain some of the printks, for in-field
debugging.  Thus not very many embedded developers
disable printks completely, even though the option has
been supported for a while.  (That, and many aren't caught
up to the kernel version where it was introduced (2.6.10) :-)

But compressed messages (shortened text through abbreviations,
or just outputting the ID alone, etc.) could save SOME
of the space, in trade for less readability.  Heck, just
removing all vowels would probably save 10k, and not
hurt readability that much.

Finally, for testing, it's handy to also
have automatic translation generators.
At a former company I worked for, they had translators
that would output:
 * all messages shortened by 20%
 * all messages lengthened by 20%
 * every message converted to pig-latin

These were mostly used for testing if the strings broke
screen real-estate constraints (which don't apply to
kernel messages).  But the automatic translators
would sometimes catch messages with weird attributes.

=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=

-
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: Versioning file system

[Brad Boyer]

On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
> Pointless here means that _I_ don't see the point.  Maybe there are
> valid uses for extended attributes.  If there are, noone has explained
> them to me yet.

The users of extended attributes that I've dealt with are ACL support
and SELinux. These both use extended attributes under the covers. It's
just not immediately obvious if you aren't looking.

Brad Boyer
[EMAIL PROTECTED]

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

Re: Change in default vm_dirty_ratio

[Linus Torvalds]

On Mon, 18 Jun 2007, Andrew Morton wrote:

> On Mon, 18 Jun 2007 14:14:30 -0700
> Tim Chen <[EMAIL PROTECTED]> wrote:
> 
> > Andrew,
> > 
> > The default vm_dirty_ratio changed from 40 to 10
> > for the 2.6.22-rc kernels in this patch:

Yup.

> > IOZone write drops by about 60% when test file size is 50 percent of
> > memory.  Rand-write drops by 90%. 
> 
> heh.
> 
> (Or is that an inappropriate reaction?)

I think it's probably appropriate.

I don't know what else to say.

For pure write testing, where writeback caching is good, you should 
probably run all benchmarks with vm_dirty_ratio set as high as possible. 
That's fairly obvious.

What's equally obvious is that for actual real-life use, such tuning is 
not a good idea, and setting the vm_dirty_ratio down causes a more 
pleasant user experience, thanks to smoother IO load behavoiur.

Is it good to keep tons of dirty stuff around? Sure. It allows overwriting 
(and thus avoiding doing the write in the first place), but it also allows 
for a more aggressive IO scheduling, in that you have more writes that you 
can schedule.

It does sound like IOZone just isn't a good benchmark. It doesn't actually 
measure disk throughput, it really measures how good the OS is at *not* 
doing the IO. And yes, in that case, set vm_dirty_ratio high to get better 
numbers.

I'd rather have the defaults at something that is "pleasant", and then 
make it easy for benchmarkers to put it at something "unpleasant, but 
gives better numbers". And it's not like it's all that hard to just do

echo 50 > /proc/sys/vm/dirty_ratio

in your /etc/rc.local or something, if you know you want this.

Maybe somebody can make a small graphical config app, and the distros 
could even skip it? Dunno. I *suspect* very few people actually end up 
caring.

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: How to improve the quality of the kernel?

[Martin Bligh]

Natalie Protasevich wrote:

On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote:

>> > So if you make changes to random-driver.c you can do `git-log
>> > random-driver.c|grep Tested-by" to find people who can test
>> > your changes for you.
>>
>> You would'nt even need to search in GIT.  Maybie even when ever a
>> patchset is being proposed a mail could be sent to appropriate
>> hardware/or feature pseudo-auto-generated mailing-list?
>>
>> On lkml I mostly try to follow patches/bugs associated with hardware I
>> use.  Why not try to automate the process and get more testers in?
>>
>
> I think this is an excellent point. One data point could be a field in
> bugzilla to input the hardware information. Simple query can select
> common hardware and platform. So far it's not working when hardware is
> just mentioned in the text part.

if it's free text it'll be useless for search ... I suppose we could
do drop-downs for architecture at least? Not sure much beyond that
would work ... *possibly* the common drivers, but I don't think
we'd get enough coverage for it to be of use.


How about several buckets for model/BIOS version/chipset etc., at
least optional, and some will be relevant some not for particular
cases. But at least people will make an attempt to collect such data
from their system, boards, etc.


Mmm. the problem is that either they're:

1. free text, in which case they're useless, as everyone types
mis-spelled random crud into them. However, free-text search
through the comment fields might work out.

2. Drop downs, in which case someone has to manage the lists
etc, they're horribly crowded with lots of options. trying to
do that for model/BIOS version/chipset would be a nightmare.

If they're mandatory, they're a pain in the butt, and often
irrelevant ... if they're optional, nobody will fill them in.
Either way, they clutter the interface ;-(

Sorry to be a wet blanket, but I've seen those sort of things
before, and they just don't seem to work, especially in the
environment we're in with such a massive diversity of hardware.

If we can come up with some very clear, tightly constrained
choices, that's a decent possibility. Nothing other than
kernel architecture (i386 / x86_64 / ia64) or whatever springs
to mind, but perhaps I'm being unimaginative.

Nothing complicated ever seems to work ... even the simple
stuff is difficult ;-(

M.
-
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: Device hang when offlining a CPU due to IRQ misrouting

[Siddha, Suresh B]

On Mon, Jun 18, 2007 at 03:38:20PM -0700, Darrick J. Wong wrote:
> On Thu, Jun 07, 2007 at 05:57:26PM -0700, Siddha, Suresh B wrote:
> 
> > As you have the failing system, you need to do more detective work and
> > help me out. Can you try this debug patch and send across the dmesg after 
> > the
> > bug happens and also can you try different compiler to see if something
> > changes..
> 
> Hrm, I just updated to -rc5.  Interrupts being handled by the IOAPIC
> don't suffer from this problem, but MSI interrupts are still affected.
> I added a few printks to the kernel to figure out what IRQ affinity
> masks were being passed around and saw this:
> 
> [  256.298773] Breaking affinity for irq 4341
> [  256.298774] irq=4341 affinity=2 mask=d
> 
> [  256.298787] irq=4341 affinity=d
> 

And just to make sure, at this point, your MSI irq 4341 affinity
(/proc/irq/4341/smp_affinity) still points to '2'?

> I'll keep digging, but at least it appears that the problem has been
> shrunk down to something the MSI code.

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

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

[Linus Torvalds]

On Mon, 18 Jun 2007, Alexandre Oliva wrote:
> 
> technically, it asks you to pass on (!= give back) access to the
> software (not to the hardware that contains it).

That "technically" is just another way of saying "if you look cross-eyed 
at it, and don't look too closely".

> No.  The reason, again, is the portion you snipped out.
> 
> Could you try again?

No.

Not worth my time. You have shown yourself unable to learn and understand. 

Just live with it. The GPLv2 is better for the kernel.

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: [PATCH] - Add IOAPIC NMI support on x86_64

[Andi Kleen]

John Keller <[EMAIL PROTECTED]> writes:

> Add support for IOAPIC NMI interrupts on x86_64.
> 
> Changes include the following:
> 
>   - Obtain the NMI IOAPIC info via an ACPI NMI SRC structure that is
> part of the MADT, and program the IOAPIC redirection register.
> The NMI SRC struct will contain the GSI of the NMI interrupt.
> 
>   - Setup irq_desc[] and irq_2_pin[] entries for the NMI interrupt irq,
> which will be used by the generic mask/unmask routines. This will
> allow a driver to enable/disable the NMI interrupt via
> enable/disable_irq().

What's the motivation for this patch? 

-Andi
-
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: Change in default vm_dirty_ratio

[Andrew Morton]

On Mon, 18 Jun 2007 14:14:30 -0700
Tim Chen <[EMAIL PROTECTED]> wrote:

> Andrew,
> 
> The default vm_dirty_ratio changed from 40 to 10
> for the 2.6.22-rc kernels in this patch:
>  
> http://git.kernel.org/?
> p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=07db59bd6b0f279c31044cba6787344f63be87ea;hp=de46c33745f5e2ad594c72f2cf5f490861b16ce1
> 
> IOZone write drops by about 60% when test file size is 50 percent of
> memory.  Rand-write drops by 90%. 

heh.

(Or is that an inappropriate reaction?)

> Is there a good reason for turning down the default dirty ratio?

It seems too large.  Memory sizes are going up faster than disk throughput
and it seems wrong to keep vast amounts of dirty data floating about in
memory like this.  It can cause long stalls while the system writes back
huge amounts of data and is generally ill-behaved.

> How will it help for most cases?  Intuitively, it seems like 
> a less aggressive writeback will have better performance.

I assume that iozone is either doing a lot of file overwrites or is
unlinking/truncating files shortly after having written them.

And some benchmarks are silly.  You have just demonstrated that IOZone
should have been called RAMZone

Some workloads will work more nicely with this change and others will be
hurt.  Where does the optimum lie?  Don't know.  Nowhere, really.



Frankly, I find it very depressing that the kernel defaults matter.  These
things are trivially tunable and you'd think that after all these years,
distro initscripts would be establishing the settings, based upon expected
workload, amount of memory, number and bandwidth of attached devices, etc.

Heck, there should even be userspace daemons which observe ongoing system
behaviour and which adaptively tune these things to the most appropriate
level.

But nope, nothing.

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

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

[Daniel Hazelton]

On Monday 18 June 2007 19:31:30 Alexandre Oliva wrote:
> On Jun 18, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:

>
> > With the GPLv2, you need to give your software modifications back, but
> > the
>  BZZT!
> > GPLv2 never *ever* makes any technical limitations on the end result.
>
> Actually, just think of how many times you've heard the argument "I
> can't give you the source code for this driver/firmware/etc under the
> GPLv2 because the law says so."

Sorry to tell you this, but anyone that makes a modification to GPLv2 covered 
code and distributes that modification is bound by the license. If a law 
makes following the license illegal, then they can't use any rights granted 
by the license. They are breaking the law by refusing to follow the license.


> > The GPLv2 requires that you give source code out.
>   BZZT ;-)
> > But if you want to make your hardware in a way that it only runs
> > signed versions, because of some reason like an FCC rule, or banking
> > rule, or just because you damn well want, the GPLv2 doesn't stop
> > that.
>
> And then, the user is stopped from making appropriate technical
> decisions.

You marked the "requires" as an error. Technically it is. Practically, 
however, it is rare for a modification to not fall under the "distribution" 
part of the license, making the "release the source" requirement active 
almost all the time.


> > b) I think you're simply wrong in your math. I think more people
> > like the middle-ground and not-frothing-at-the-mouth spirit of "open
> > source" over the religious dogma of "free software".
>
> It looks like the math you're talking about is in no way related with
> anything I've argued about.  You seem to be thinking about the number
> of people who claim to be on the "free software" or "open source"
> sides, but I can't fathom in what way this is related with whether you
> get more or less contributions from users as a consequence of users'
> being permitted to tinker with the free software in their own devices.

"More Developers" (either "Free Software" or "Open Source") == "More 
Contributions"

That equation is very simple to understand - claiming its wrong is impossible.

> > See? Those are three totally different reasons why I think the GPLv2 is
> > the right license for me, and for the kernel.
>
> Ok, the only one that stands is the moral reason.  

Apparently because you can't admit that a good reason *IS* a good reason when 
it conflicts with your belief that the FSF is correct. (The same as 
the "Science can't be right because it conflicts with the bible" I hear from 
all kinds of Xtians these days)

DRH
PS: I know I've said I'm done with this conversation, but this is like a bad 
habit. I just couldn't help myself.

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

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

[david]

On Tue, 19 Jun 2007, Johannes Stezenbach wrote:


On Mon, Jun 18, 2007, Alexandre Oliva wrote:


People talk a lot about TiVo here, but do they the faintest idea of
how the conversations with TiVo are proceeding?  I thought so...


Oh, if you know something we don't, could you please fill us in?
And who was it who coined the "Tivoization" term, thus putting
TiVo into focus?


what conversations are going on?

Tivo checked years ago and were told that what they were going to do was 
Ok. I don't know thatanyone is talking too Tivo about anything. they are 
just screaming about how evil Tivo is at every public opportunity.


David Lang

But since the software is good, and moving to another software would be 
costly in various dimentions, the vendor has an incentive to stick with 
the software they have.


but if regulations or other contracts require tamper-resistant hardware 
they have no choices other then to fork the existing GPLv2 versions or 
switch to alternate options for anything that switches to GPLv3


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: GIT Packages for Debian Etch

[Roland Dreier]

 > Is there some way you can feed that into Debian please? Why the go around 
 > through a separate repository? The maintainer of git-core is not actively 
 > maintaining the package?

No.  The current version of git in Debian is 1.5.2.1, a little out of
date from the current 1.5.2.2 but not too bad.  However, Debian Etch
was already released with an older version of git.  Debian
testing/Lenny (the next release, which is still being developed) does
not have the latest version of git yet because it is blocked waiting
for the next version of curl as well as a few other problems.

 - R.
-
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: Updated Btrfs project site online -git repo?

[Chris Mason]

On Mon, Jun 18, 2007 at 09:53:39PM +0200, Maria Domenica Bertolucci wrote:
> Would it be possible to have a git repo as well so as to keep in sync
> with all git kernel projects? It also helps standardize things.

Sorry, the repos will stay Mercurial based for now.  These are small
repos and not attached to the main kernel sources, it will be easy to
download (I promise).

-chris

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

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

[Alexandre Oliva]

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

> On Mon, 18 Jun 2007, Alexandre Oliva wrote:
>> 
>> 1. I asked you why GPLv2 is better, and you said it was because it
>> promoted giving back in kind.

> Where I explained that "in kind" was about *software*.

Yes, we'd already established that.

>> 2. I asked you what you didn't like about GPLv3, and you said it was
>> Tivoization.

> Right. The GPLv3 asks you to give back *money*.

> That's like the Microsoft license agreements. I don't like them either.

> Oh, and replace "money" with "access to hardware", to make that thing 
> technically correct.

technically, it asks you to pass on (!= give back) access to the
software (not to the hardware that contains it).

>> 3. Then I argued that, since Tivoization enables tivoizers to remove
>> some motivation for potential developers (= their customers)

> That's simply not my *reason* for doing "tit-for-tat".

No.  The reason, again, is the portion you snipped out.

Could you try again?

> I just want software back. I think it is *wrong* for me to ask for 
> anything else. It's literally my personal "moral choice": I think the 
> hardware manufacturers need to make their _own_ choices when it comes to 
> _their_ designs.

It's comforting to see that you're not the pure-pragmatics-no-morals
character that some people (yourself included) try to paint you as.
Thank you for this.  I can relate with that.  I can easily respect
that, as much as I think that (poor attempt at humor follows, no
offense really intended) standing up for the freedoms of the poor
hardware manufacturers against the evil software developers who want
to control the ways they can use to control their customers serves the
common good or even your own stated interests.

> But if you actually want to discuss "number of developers" and their 
> motications, I actually have another few arguments for you:

>  - I just personally think your math is bogus. I think more people think 
>like I do, than people think like you and the FSF does.

> But I don't even depend on that. Because:

>  - I think that *technical*quality* is more important than *quantity*.

This argument fails to make the point you're trying to make.  I wrote:

  you trade the potential contributions of all those users for the
  contributions of tivoizers, apparently assuming that all tivoizers
  would simply move away from the community, taking their future
  contributions away from your community, rather than moving to a
  position in which you'd get not only the contributions from the
  company itself, but also from all their users

and you say "oh, I don't care about quantity, I care about quality",
as if this somehow related with the above.

Just do the math.  Hypothetically, Linux goes GPLv3, without
permission to tivoize.  TiVo has to decide among:

- switching to another kernel, no further contributions from them

- sticking with old version, no further usable contributions from them

- switching to ROM, still the same contributions from TiVo

- no more tivoization, contributions from TiVo and users

So, you see, in no case do you get more contributors while at the same
time losing TiVo's quality contributions.

The argument is not about quality vs quantity, it's about getting
lots of additional contributions along with what's already in place,
VS ending up without some quality contributions you get today.

> With the GPLv2, you need to give your software modifications back, but the 
    BZZT!
> GPLv2 never *ever* makes any technical limitations on the end result.

Actually, just think of how many times you've heard the argument "I
can't give you the source code for this driver/firmware/etc under the
GPLv2 because the law says so."

> In the GPLv3 world, we have already discussed in this thread how you can 
> follow the GPLv3 by making the TECHNICALLY INFERIOR choice of using a ROM 
> instead of using a flash device.

Yes.  This is one option that doesn't bring any benefits to anyone.
It maintains the status quo for users and the community, but it loses
the ability for the vendor to upgrade, fix or otherwise control the
users.  Bad for the vendor.

As another option, the vendor can respect users' freedoms, and then
everybody wins big.  That's the option that anti-tivoization provides
economic incentive for vendors to take.  Sure, they may still prefer
the alternative above, or stick with an older version (which has its
costs), or move to different software (which also has its costs), but
it's unreasonable to claim that I'm advocating for vendors to move to
ROM.

I'm saying they have this option.  I'm advocating for them to respect
users' freedom.  And if that's incompatible with their business model,
well, so what?  GPLv2 and Free Software in general are incompatible
with a number of business models too, and who's complaining?  Heck,
even using slave work-forces was part of legitimate business models at
some point in time.

> The GPLv2 

Re: [1/2] 2.6.22-rc5: known regressions

[Malte Cornils]

Hello,

Am Montag, 18. Juni 2007 18:29 schrieb Greg KH:
> On Mon, Jun 18, 2007 at 01:02:42PM +0200, Malte Cornils wrote:
> > Hello,
> > > Subject: PCI setup hangs on Asus Notebook (nolapic helps)
> > > References : http://lkml.org/lkml/2007/6/14/161
> > > Submitter  : Malte Cornils <[EMAIL PROTECTED]>
> > > Status : unknown
> >
> > The original report was made on 2.6.22-rc3, I just checked and it still
> > happens on 2.6.22-rc5.
>
> Can you use 'git bisect' to track down the patch that causes this to
> fail?

I will do this, however, it will likely take me a day or two to find. I'll 
report back then.

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

[Johannes Stezenbach]

On Mon, Jun 18, 2007, Alexandre Oliva wrote:
> 
> People talk a lot about TiVo here, but do they the faintest idea of
> how the conversations with TiVo are proceeding?  I thought so...

Oh, if you know something we don't, could you please fill us in?
And who was it who coined the "Tivoization" term, thus putting
TiVo into focus?

> So, you see, when people who oppose anti-tivoization measure the
> outcome for the community, they only look at the second possibility,
> assuming the vendor would immediately switch to some other software.
> As if that was easy for the vendor, and as if the software sucked so
> much that the vendor was just looking for a reason to switch.
> 
> But since the software is good, and moving to another software would
> be costly in various dimentions, the vendor has an incentive to stick
> with the software they have.

Hm, you only talk about people who already use free software,
but I tried to make you aware of the importance of
_promoting_ free software, i.e. winning new people and
companies for the free software idea.

I think the majority of embedded devices still run proprietary
RTOSes, and the majority of desktops still run Windows or Mac OS.
Don't you want to change that?

There are dozens of proprietary RTOSes, and along with
them dozens of proprietary toolchains, development environments
and trace/debug tools. Companies which worked in this field
for decades have invested money to create proprietary software
on top of them, and to train their staff to use them. Those companies
won't switch to Linux lightly. And it won't be a singular event,
but a process. They might start low, and maybe (hopefully) might
become well-playing free software contributors. But if you raise
the entry barrier too high, they won't get started at all.

OK, I don't have experience talking to big companies, but
I have talked to people working for smaller ones. They are
aware of the trend towards Linux, but are afraid that the
obligations of the GPL might be impractical for them.
Then they only have the choice to not use Linux, or to use
"creative workarounds".

It's true that what these companies do might have little direct benefit
for users buying their products, however the long term benefits of
getting the people in these companies exposed to free software ideas,
and in contact with the free software community, can only be
positive -- I think it's more important to spread the general
idea of free software into as many minds as possible than to
ensure that few follow the pure spirit of the FSF free software
definition in every detail.

> So you see, the picture of anti-tivozation is not as bleak as people
> try to frame it.  In fact, it's not bleak at all.  If one out of 10,
> maybe even 1 out of 100 vendors start respecting users' freedoms, when
> faced with anti-tivoization provisions, the community will already win
> big time, because each vendor is likely to have thousands of
> customers, some of which will use the freedoms to serve the goals of
> the community, in the very terms the community claims to care about.

Does this multiplicator also apply to new companies
which start using free software for their products?

I think the FSF strategy is suboptimal. The Linux
strategy works better for promoting free software.

In the end I want my devices to be open and hackable, too,
and I'm sure it will take an effort to convince companies
to open up. But I'm not convinced that the GPLv3 is a
step in the right direction towards that goal.


Johannes
-
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: GPLv3 dispute solution - new open source license?

[alan]

On Tue, 19 Jun 2007, Alan Cox wrote:


If we can't adopt the GPLv3, it seems obvious to me that we need our own
solution.


Its called GPL v2.


Its not the Spirit of the GPLv3 I object to, its the hangover the next 
morning.


Why do I see this horse-shaped hole that people continue to want to hit 
with sticks?


--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
  - Alan Cox
-
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: GPLv3 dispute solution - new open source license?

[Alan Cox]

> If we can't adopt the GPLv3, it seems obvious to me that we need our own 
> solution.

Its called GPL v2.

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

Re: GIT Packages for Debian Etch

[Christoph Lameter]

On Mon, 18 Jun 2007, Thomas Glanzmann wrote:

> Hello,
> a friend of mine always builds the Debian Packages from unstable for
> Debian Etch. I have on all my machines the following line in
> /etc/apt/sources.list:
> 
> deb http://rmdir.de/~michael/git/ ./
> 
> apt-get update; apt-get dist-upgrade
> 
> and you're up2speed.
> 
> If you don't trust that packages it is very easy to build them yourself:

Is there some way you can feed that into Debian please? Why the go around 
through a separate repository? The maintainer of git-core is not actively 
maintaining the package?

-
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: Versioning file system

[Bron Gondwana]

On Mon, Jun 18, 2007 at 11:32:38AM -0400, Chris Mason wrote:
> On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
> > Too bad everyone is spending time on 10 similar-but-slightly-different
> > filesystems.  This will likely end up with a bunch of filesystems that
> > implement some easy subset of features, but will not get polished for
> > users or have a full set of features implemented (e.g. ACL, quota, fsck,
> > etc).  While I don't think there is a single answer to every question,
> > it does seem that the number of filesystem projects has climbed lately.
> > 
> > Maybe there should be a BOF at OLS to merge these filesystem projects
> > (btrfs, chunkfs, tilefs, logfs, etc) into a single project with multiple
> > people working on getting it solid, scalable (parallel readers/writers on
> > lots of CPUs), robust (checksums, failure localization), recoverable, etc.
> > I thought Val's FS summits were designed to get developers to collaborate,
> > but it seems everyone has gone back to their corners to work on their own
> > filesystem?
> 
> Unfortunately, I can't do OLS this year, but anyone who wants to talk on
> these things can drop me a line and we can setup phone calls or whatever
> for planning.  Adding polish to any FS is not a one man show, and so I know
> I'll need to get more people on board to really finish btrfs off.
> 
> One of my long term goals for btrfs is to figure out the features and
> layout people are most interested in for filesystems that don't have to
> be ext* backwards compatible.  I've got a pretty good start, but I'm
> sure parts of it will change if I can get a big enough developer base.

I have no filesystem programming experience, but I am certainly
interested, and I'm spending some time reading through the code that
you've written so far.  Oh, and running it - though I'm probably going
to want to fiddle with some smaller filesystems than my entire Maildir
set if I want to make any sense of the structure dumps!

That and of course if I get involved in development I can be sure that
my favourite workload (big Cyrus installs) is well optimized for!

Actually, my biggest interest is decent unlink performance, in
particular when you are unlinking multiple items in a directory or
even the entire directory plus everything in it.  I find that to be
an incredibly slow and IO hurting operation.  We run cyr_expire
(the process in Cyrus that actually deletes expunged messages) once
per week, and only one process at a time on a machine which might have
20 otherwise busy instances of Cyrus running - because the IO hit on
those data partitions is massive.  Load average more than doubles and
the log entries for commands which took longer than a second to return
increase massively.

And this is on a Sunday when there's barely any use compared to a
weekday.

So yeah, my main interest is making unlink (especially multiple unlinks
from the same directory) into a less extreme experience.

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

[Alan Cox]

> the software on your laptop is owned by people like Linus, Al Viro, David 
> M, Alan Cox, etc.

Not quite that simple. An easier way to think about this one is books.
You own the book but you don't own the right to reproduce the words
within. You can however boil the book, use it as bog roll or read it (not
in that order I suggest)

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

Change in default vm_dirty_ratio

[Tim Chen]

Andrew,

The default vm_dirty_ratio changed from 40 to 10
for the 2.6.22-rc kernels in this patch:
 
http://git.kernel.org/?
p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=07db59bd6b0f279c31044cba6787344f63be87ea;hp=de46c33745f5e2ad594c72f2cf5f490861b16ce1

IOZone write drops by about 60% when test file size is 50 percent of
memory.  Rand-write drops by 90%. 

Is there a good reason for turning down the default dirty ratio?
How will it help for most cases?  Intuitively, it seems like 
a less aggressive writeback will have better performance.

Thanks.

Tim
-
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: How to improve the quality of the kernel?

[Martin Bligh]

> So if you make changes to random-driver.c you can do `git-log
> random-driver.c|grep Tested-by" to find people who can test
> your changes for you.

You would'nt even need to search in GIT.  Maybie even when ever a
patchset is being proposed a mail could be sent to appropriate
hardware/or feature pseudo-auto-generated mailing-list?

On lkml I mostly try to follow patches/bugs associated with hardware I
use.  Why not try to automate the process and get more testers in?



I think this is an excellent point. One data point could be a field in
bugzilla to input the hardware information. Simple query can select
common hardware and platform. So far it's not working when hardware is
just mentioned in the text part.


if it's free text it'll be useless for search ... I suppose we could
do drop-downs for architecture at least? Not sure much beyond that
would work ... *possibly* the common drivers, but I don't think
we'd get enough coverage for it to be of use.

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

Re: [patch 1/3] Text Edit Lock - i386

[Andi Kleen]

On Tuesday 19 June 2007 00:52:25 Chuck Ebbert wrote:
> On 06/18/2007 05:58 PM, Mathieu Desnoyers wrote:
> > Interface to use for code patching : uses a mutex to insure mutual edit
> > exclusion and makes sure the page is writable.
> > 
> ... 
> > +/* Mutex protecting text section modification (dynamic code patching) */
> > +static DEFINE_MUTEX(text_mutex);
> > +
> 
> Probably should be a spinlock.
> 
> And it just occurred to me, how does smp_alternatives deal with this?
> Is it broken now when the text section is read-only?

The text section is only changed to ro very late,  alternative code
runs earlier.

But when you unplug all CPUs to go back to UP I suspect it may break.

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

Re: [patch 1/3] Text Edit Lock - i386

[Mathieu Desnoyers]

* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> On 06/18/2007 05:58 PM, Mathieu Desnoyers wrote:
> > Interface to use for code patching : uses a mutex to insure mutual edit
> > exclusion and makes sure the page is writable.
> > 
> ... 
> > +/* Mutex protecting text section modification (dynamic code patching) */
> > +static DEFINE_MUTEX(text_mutex);
> > +
> 
> Probably should be a spinlock.
> 
> And it just occurred to me, how does smp_alternatives deal with this?
> Is it broken now when the text section is read-only?

(note that the implementation I just posted is a proof of concept: I
just noticed that I need to keep track of wether or not I am called
before or after the mark_rodata is done, so the apply alternatives does
not crash at early boot because of the global_flush_tlb().)

A spinlock it will be then :)

SMP alternatives deals with this by simply disabling the whole
protection:

mark_rodata_ro():

#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
if (num_possible_cpus() <= 1)
#endif
{
change_page_attr(virt_to_page(start),
 size >> PAGE_SHIFT, PAGE_KERNEL_RX);
printk("Write protecting the kernel text: %luk\n", size >> 10);
}

So it's ok if no CPU can be hotplugged, since the CPUs are brought up
before the mark_rodata_ro is done, but not if HOTPLUG is selected.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Schwartz]

> First, end users buy and use the hardware in question.  It does not
> belong to Tivo, so the analogy to his laptop fails there.

No, this is incorrect. They buy *some* of the rights to the hardware but not
all of them. Specifically, they do not buy the right to choose what software
runs on that hardware. That right is still owned by TiVo.

You can argue that TiVo is being dishonest, breaking the law, being immoral,
or whatever in retaining this right or in failing to disclose that they
retain it. But you cannot coherently deny that TiVo retains this right when
they sell certain other rights to the hardware.

I do in fact argue that there are things that are wrong with TiVo doing
this. But they are not GPL-related things. I would make these same arguments
if the TiVo contained no GPL'd software and I in fact do make them about
products like the Xbox.

DS


-
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: Versioning file system

[alan]

On Mon, 18 Jun 2007, Jeremy Allison wrote:


Just because I now agree with you that streams are
a bad idea doesn't mean the pressure to support them
in some way in Samba has gone away :-).


Having dealt with Stream's support[1] in the past, I can assure you it is 
a bad idea.  ]:>


[1] http://www.stream.com/

--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
  - Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Schwartz]

> > But you're not the user of the software on my laptop.  I am.

> ahh, but by your own argument you aren't

Let's not confuse owner with user and let's not confuse ownership of
copyrights with ownership of particular copies.

> the software on your laptop is owned by people like Linus, Al Viro, David
> M, Alan Cox, etc.

No. The copyright to the software is owned by those people. But particular
copies of copyrighted items can be owned by other people.

> they have the right to put a license on that software that would require
> you to give them access to your hardware (after all, that's the argument
> that you are useing to justify requireing Tivo to give you access
> to their hardware)

That's right, they do have that right so long as they condition it on the
exercise of something I could not do without their permission. (Ignoring for
the moment the fact that the software is a derivative work of GPL'd
software.)

I'm not sure whether you think this disagrees with or refutes anything I've
said.

DS


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

[Linus Torvalds]

On Tue, 19 Jun 2007, Carlo Wood wrote:
> 
> Conclusion: the weird behaviour that you think was wrong is
> totally due to git 1.4.4.4.

Ok. I'll bounce a note to Junio just due to curiosity in case he goes 
"ahh, yeah, it was that known bug", but I'll otherwise ignore this.

Git-1.5.x is such a radically better version (not because it fixes this 
bug, but because we fixed a number of other issues, notably some very 
basic usability things), that I think any git users should really upgrade 
to a newer version.

IOW, there's simply no reason to stay on anything older (git has always 
been backwards compatible since very early on, so upgrading to a newer 
version of git won't break anything, although some of the new UI's might 
obviously cause you to do things differently).

> I'll redo the bisect with this new git.

Thanks,

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/