Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > It's full of kludges exactly because it tries to carve out a notion > that can only be determined on case-to-case basis and not by generic > definition. I agree it's a very difficult definition. I'm not sure I'm happy with the wording in place right now. But I very much like and agree with its purpose, and it is in line with the goal of respecting and defending users' freedoms, which is what the FSF cares mostly about, and must care about, because it's its official and public mission. > I don't _care_ whether it breaks spirit, etc. That's what I care about, and I've seen false claims that it does. Can you please acknowledge that it doesn't, such that I can feel I've fulfilled my goal of dispelling the myth that the GPLv3 changes the spirit of the GPL? > GPLv3, with your involvement in its development or not, sucks rocks, > thanks to what you call anti-tivoization section. Is it correct to say that you share Linus' opinion, that the only problem with the GPLv3 is the anti-tivoization provision? To make this more concrete, if there was a hypothetical GPLv2.9, consisting of GPLv3dd4 minus the "installation information" requirements for user products, (i) Would you consider it a better license than GPLv2? (ii) Better for Linux? (iii) Enough to go through the trouble of switching? I'd love answers to these 3 questions from others too. Just in case, I shall point out, one more time, that I'm speaking for myself, not for the FSF, not for FSFLA, not for Red Hat. The questions above are to satisfy my personal curiosity. I don't make any commitment whatsoever to take the answers up to the FSF, and I don't want to set any expectations as to whether they could or would make any difference, at this point, about the outcome of GPLv3. If you want your opinions to stand a chance to make a difference, the right place to provide them is gplv3.fsf.org/comments, and time is running short. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sunday 17 June 2007 01:09:01 Alexandre Oliva wrote: > On Jun 17, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Sat, 16 Jun 2007, Alexandre Oliva wrote: > >> I've already explained what the spirit of the GPL is. > > > > No. You've explained one thing only: that you cannot see that people > > don't *agree* on the "spirit". > > They don't have to. > > Just like nobody but you can tell why you chose the GPLv2, nobody but > RMS can tell why he wrote the GPL. And the intent behind writing the > GPL is what defines its spirit. "Charging for programs is an crime against humanity" > > Yes, people have brought out the argument that the GPLv3 actually > > even changes the spirit, > > And that's the point that I'm fighting here. It does not change the > spirit. It's still ensuring that Free Software remains Free: > respecting and defending the four freedoms defined in the Free > Software definition. See, you can't even keep the FSF's "Free Software Definition" and its inherent "religion" out of the discussion. Sure, the FSF can claim that the GPL is intended as a way to "defend" the "Four Freedoms" defined *BY* *THEM*, but unless alluded to in the license, the only bearing it can have, anywhere, is on the "intent" of the license, as seen by the FSF. And if the "ability to run a "covered work" on any piece of hardware" is "freedom 0" then binary distribution is in violation of the "spirit" - I can't run an x86 binary on a PPC. Isn't that a "designed in hardware restriction" that violates the "spirit" of the license ? > >> I've already explained that the anti-Tivoization provision is in line > >> with it. > > > > .. and we have already explained to you that it's irrelevant. > > It is relevant. It was the point that my participation was intended > to address. > > I guess it is just too hard to accept that an FSFer could not be > trying to force GPLv3 down your throat or some other such nonsense. > > > - The GPLv2 was ok with Tivo. > > There's disagreement about this, even among developers of the kernel > Linux, and you know it. > > I know you're always right and I pretend to respect that ;-), but why > do you think your opinion should prevail over theirs? Don't you > realize that they're as entitled as you are to enforce the license, > and in the way *they* (not you) perceive and meant to license their > code? > > And then again, this is not something I'm overly concerned about. I > probably don't have enough contributions to Linux for my take on it to > make any difference whatsoever. > > This is not the real issue at all. The real issue, that brought me > here and got you to name calling me and the FSFs, is that there were > false claims about the GPLv3 that I wanted to dispell, particularly > the point about its changing the spirit. The anti-tivoization > provisions are in the spirit of the GPL, and so much so that a number > of people perceive them as already covered by GPLv2. > > > - The GPLv3 tries to stop Tivo. > > A minor nit, but no, it doesn't. It tries to stop the practice of > tivoization on programs licensed under the GPLv3. > > TiVo has a number of choices, and so do other tivoizers, even if they > adopt software under the GPLv3. > > > What I care about is that the GPLv3 is a _worse_license_ than GPLv2, > > Even though anti-tivoization furthers the quid-pro-quo spirit that you > love about v2, and anti-tivoization is your only objection to v3? > That's what I don't understand. This is so obviously contradictory to > me that it's almost funny, and you've so far dodged my questions about > this and refrainied from commenting on this contradiction so much that > it looks like it's a blind spot in your mind. Not in the least. They still have to release their changes if they want to sell their devices. Or are you so blinded by your belief that the FSF and RMS can't be wrong that you can't understand that? > > I'd be stupid to select the worse of two licenses, wouldn't I? > > Yes. That's precisely why I don't understand your stance. Because I > expect you to be intelligent, but starting from your stated motivation > for choosing GPLv2, and from the consequences of the anti-tivoization > provisions, you'd satisfy your motivations better with v3. It is only *YOUR* opinion that the GPLv3 is the better license. As Linus has explained, he doesn't share your viewpoint. > Tivoization reduces the motivation for customers of tivoized devices > to improve the software. You end up with contributions from the > manufacturers alone, instead of from all the user community. No, it reduces their motivation to improve the software on *those* devices. If they like the software enough to actually download the source, they probably also liked it enough to install it on their computer *AND* will modify it to make it work better on their computer. > With explicit anti-tivoization provisions, you may very well lose > contributions from some tivoizers, but for those who change their >
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Sun, 17 Jun 2007, Alexandre Oliva wrote: >> >> They're based on the Free Software definition, that establishes the >> four freedoms that the GPL was designed to respect and defend. > The GPL is a software license, *independent* of that thing. One more time, I'm not talking about the license (the legal terms). I'm talking about its spirit. It's encoded in the preamble, that refers to "free software", which can't possibly be defended as meaning anything but what the FSF itself defined in the Free Software Definition. Is this some form of mental block that stops you from realizing that the spirit of the license is pretty much all I've been talking about here, and that I've already said that at least 20 times in this thread? Why do you insist in bringing the legal terms back into this discussion about the spirit of the license? What are you trying to accomplish, other than generating more confusion and pretending that you have a strong point? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Sunday 17 June 2007 00:19:49 Alexandre Oliva wrote: >> On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: >> > On Saturday 16 June 2007 21:54:56 Alexandre Oliva wrote: >> >> There may be laws that require certification or limitations on the >> >> user. Manufacturer giving up the ability to make modifications would >> >> address this, or *perhaps* arranging for user and manufacturer to each >> >> hold half of the key needed to run a modification (which might comply >> >> with the GPLv3dd4 terms, IANAL). >> > >> > It doesn't. The GPLv3 (dd4) makes that very clear. See the quote below. >> >> You left out the relevant bit: >> >> this requirement does not apply if neither you nor any third party >> retains the ability to install modified object code on the User >> Product (for example, the work has been installed in ROM). > Ah, but giving the user half the key doesn't mean they still don't have > access > to the entire key. QED: Giving people half the key won't cut it under the > GPLv3 (dd4) I meant really giving, rather than giving a copy, or giving the original and keeping a copy. You could make it require a pair of signatures, one from the vendor, that the vendor keeps, one from the user, that the vendor never sees, too. Like some bank PINs, it gets generated, used to generate some hash (the signature for the initial installation), printed in an envelope for you and stored in the package along with the machine. Or something like that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Saturday 16 June 2007 23:31:00 Alexandre Oliva wrote: >> On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: >> > But each of those arguments is based on a technicality. >> >> They're based on the Free Software definition, that establishes the >> four freedoms that the GPL was designed to respect and defend. > And what gives you or the FSF to define what "Free Software" is? What makes > the definition you are using is the correct one? Huh? Would you expect the *Free* *Software* Foundation to use the term *Free* *Software* present in the license it wrote to mean what? > But it doesn't matter. You're backpedalling, tossing up a smokescreen because > you've been caught working under a double-standard. Heh. That's hilarious. > Nope. As I've stated before it doesn't matter that you believe it. What > matters is that there is no single, definable "spirit" of the license. > The "spirit" is what each person who places their work under the license > believes it to be. You're mixing two separate issues. One thing is the intent behind the writing of the license. This is what the spirit of the license is. Another thing is how the copyright holder of a work perceived that license, and the motivations for his choice of that license. I don't think this has a name. Let's call this spirit of the licensing, for the sake of the argument. What I've been talking about is not the spirit of the licensing. I respect that, even when I don't agree with it. But when people claim the GPL is changing its spirit, they're accusing the FSF of changing the spirit of the license. And this hasn't happened. This is the point I'm standing for. Does this clarify the issue? >> I'm not trying to say why Linus and others chose the GPLv2. >> >> I'm not trying to determine what their motivations were. >> >> I'm not trying to force them to change to GPLv3. >> >> I'm not trying to convince them that tivozation is a bad thing. > But you have done this multiple times. You may not have been trying to, but > you were. You mean I've done all of the above multiple times? Show me? Odds of success for the last one are pretty high, because the discussion somehow sidetracked into that and I've probably been sloppy about it, but as for the other points, I very much doubt it you'll find me doing any of them. 100% sure you won't find anything about forcing anyone to change to GPLv3. I've just realized that "determine" above is ambiguous. I meant it as "decide", rather than "understand". I was definitely trying to understand their motivations, once the debate moved onto that front as well. >> I'm only trying to show that anti-tivozation is in line with the >> spirit of the GPL. > With *YOUR* view of what the spirit is. Why, sure. And given how close I am to the FSFs and how closely I understand the reasoning behind the GPL, do you really think my view does not match the intent of the FSF for the GPL? >> tivoization, which means to restrict a user's ability to adapt the >> software to their own needs and run it for any purpose, while the >> hardware manufacturer keeps this to itself, is against the spirit of >> the GPL. > The TiVO company didn't do that. They kept the ability to *REPLACE* > the version on the device that connects to their network to > themselves. You have access to the source code TiVO uses, complete > with their modifications... You can modify it in any way you choose > *AND* you can distribute the code yourself. Hell, you can even *RUN* > it for any purpose you want. How is this enough to adapt the software to my needs and run it for any purpose? How can you possibly claim they're not imposing restrictions on my abilities to adapt the software to my needs (freedom #1) and run the software for any purpose (freedom #0), if that's the whole point behind their technical measures? >> Is the connection with the TiVo network not through some other >> carrier too? > But your server doesn't run the internet. But it runs my home network, and you've connected to it. Now what? I'm sure I'm still missing something in your characterization of the situation about networks, but I'm not sure I care enough to pursue this point. Feel free to drop it, I don't think it's relevant for the discussion on whether GPLv3 changes the spirit of the GPL. >> > The TiVO service runs as a network - and a non-public one at that. They >> > own the network, they control what hardware and with what configurations >> > is allowed to connect. Whats more is that they have the right to actively >> > control that configuration. >> As long as this doesn't violate any other laws or agreements they've >> entered, that is. And this includes license agreements. > And if the license doesn't explicitly state something as being a > violation of its terms then it doesn't matter. Not quite. Copyright licenses are to be interpreted restrictively. Unless it states you
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, Jun 17, 2007 at 12:31:00AM -0300, Alexandre Oliva wrote: > I'm not trying to say why Linus and others chose the GPLv2. > > I'm not trying to determine what their motivations were. > > I'm not trying to force them to change to GPLv3. > > I'm not trying to convince them that tivozation is a bad thing. > > I'm only trying to show that anti-tivozation is in line with the > spirit of the GPL. ... and anti-tivoization section shows all symptoms of going in wrong direction, *whether* *tivo* *is* *good* *or* *not*. It's full of kludges exactly because it tries to carve out a notion that can only be determined on case-to-case basis and not by generic definition. And no, that's not a matter of bad wording in that section. I don't _care_ whether it breaks spirit, etc. - it's a fundamentally bad idea for completely independent reasons. Even if one thinks that tivo in particular ought to be sued into the ground at some point. Besides, it's fscking *pointless* for userland stuff. If you insist that e.g. glibc will infect by linking, you've just created a huge problem for any GPLv2 userland code, which will make all bad blood about kernel look trivial in comparison. If you do not, then you've lost all leverage anyway; kernel won't switch, libraries are OK, toolchain is obviously OK for building code with any license... what's left? The glorious /bin/cp? Sorry, it would work as usual, subject to open(2) not returning EACCES. Just as on any system. Just what is it going to prevent? Hell, they can slap selinux on the box, protect what they want to protect, use crypto-loop to prevent offline modifications of filesystem and hide the key in firmware. Either GPLv2 is sufficient in given case (and e.g. Alan decides to go after company in question), or you've at most created a moderate amount of work rewriting the checks they are doing into a different form (if that). Good job. In the meanwhile, you've got a load of ill-defined verbiage around installation instructions. I.e. a lovely fodder for potential abusers. Sod it. GPLv3, with your involvement in its development or not, sucks rocks, thanks to what you call anti-tivoization section. -- How many GPL spirits can dance on the end of a pin? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Sat, 16 Jun 2007, Alexandre Oliva wrote: >> >> I've already explained what the spirit of the GPL is. > No. You've explained one thing only: that you cannot see that people don't > *agree* on the "spirit". They don't have to. Just like nobody but you can tell why you chose the GPLv2, nobody but RMS can tell why he wrote the GPL. And the intent behind writing the GPL is what defines its spirit. > Yes, people have brought out the argument that the GPLv3 actually > even changes the spirit, And that's the point that I'm fighting here. It does not change the spirit. It's still ensuring that Free Software remains Free: respecting and defending the four freedoms defined in the Free Software definition. >> I've already explained that the anti-Tivoization provision is in line >> with it. > .. and we have already explained to you that it's irrelevant. It is relevant. It was the point that my participation was intended to address. I guess it is just too hard to accept that an FSFer could not be trying to force GPLv3 down your throat or some other such nonsense. > - The GPLv2 was ok with Tivo. There's disagreement about this, even among developers of the kernel Linux, and you know it. I know you're always right and I pretend to respect that ;-), but why do you think your opinion should prevail over theirs? Don't you realize that they're as entitled as you are to enforce the license, and in the way *they* (not you) perceive and meant to license their code? And then again, this is not something I'm overly concerned about. I probably don't have enough contributions to Linux for my take on it to make any difference whatsoever. This is not the real issue at all. The real issue, that brought me here and got you to name calling me and the FSFs, is that there were false claims about the GPLv3 that I wanted to dispell, particularly the point about its changing the spirit. The anti-tivoization provisions are in the spirit of the GPL, and so much so that a number of people perceive them as already covered by GPLv2. > - The GPLv3 tries to stop Tivo. A minor nit, but no, it doesn't. It tries to stop the practice of tivoization on programs licensed under the GPLv3. TiVo has a number of choices, and so do other tivoizers, even if they adopt software under the GPLv3. > What I care about is that the GPLv3 is a _worse_license_ than GPLv2, Even though anti-tivoization furthers the quid-pro-quo spirit that you love about v2, and anti-tivoization is your only objection to v3? That's what I don't understand. This is so obviously contradictory to me that it's almost funny, and you've so far dodged my questions about this and refrainied from commenting on this contradiction so much that it looks like it's a blind spot in your mind. > I'd be stupid to select the worse of two licenses, wouldn't I? Yes. That's precisely why I don't understand your stance. Because I expect you to be intelligent, but starting from your stated motivation for choosing GPLv2, and from the consequences of the anti-tivoization provisions, you'd satisfy your motivations better with v3. Tivoization reduces the motivation for customers of tivoized devices to improve the software. You end up with contributions from the manufacturers alone, instead of from all the user community. With explicit anti-tivoization provisions, you may very well lose contributions from some tivoizers, but for those who change their stance, you gain far more contributors. You don't need a lot of tivoizers to take the path of freedom for you to win big time in the bottom line that you posed as the only relevant one. You see why I don't understand your position? > They are also "anti-anything-else-that-might-want-to-lock-down-a- > specific-version-for-security-or-regulatory-reasons". It's not, this is false. "Lock down" is permitted. It just won't work if the business model depends on modifying stuff behind the user's back. But other cases of "lock down" are permitted: this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). > - Not everybody thinks like you or agrees with you. > - In particular, the original copyright author in the kernel does *not* >think like you, and *realized* that he doesn't really like the FSF >religious agenda years and years ago, and made sure that the FSF cannot >control the licensing of the Linux kernel. I hereby acknowledge, one more time, that I accept these facts. Since we're in such a good mood now, would you mind acknoledging some other simple facts, such that we can end this discussion? - the spirit of the GNU GPL, written by RMS in the FSF, is to keep Free Software Free, respecting and defending the freedoms of users of software licensed under the GPL It can serve other goals, and some
Re: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Sat, Jun 16, 2007 at 06:25:00PM -0700, Arjan van de Ven wrote: > > > You: conceptully-new add-on which benefits 0.25% of the user base, provided > > they select the right config options and filesystem. > > > > Me: simpler enhancement which benefits 100% of the user base (ie: includes > > 4k blocksize, 4k pagesize) and which also fixes your performance problem > > with that HBA. > > note that at least 2.6 is doing this "sort of", better than 2.4 at > least. (30% hitrate or something like that). Is it? Last I looked it had reverted to handing out reverse-contiguous pages. You can see this by running /proc/pid/pagemap through hexdump. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: libertas (private) ioctls vs. nl80211
On Thu, Jun 14, 2007 at 04:08:44PM -0400, John W. Linville wrote: > On Thu, Jun 14, 2007 at 12:56:18PM -0700, Andrew Morton wrote: > > On Thu, 14 Jun 2007 15:09:36 -0400 > > "John W. Linville" <[EMAIL PROTECTED]> wrote: > > > > > It does not make sense to me to rip this out purely for aesthetic > > > reasons. > > > > Aesthetics are good, but that's not the main issue. > > > > What is most worrying is that there appears to be a risk that these > > newly-added interfaces will later become obsoleted by another interface. > > This means that we'll need to maintain, test and support _both_ interfaces > > for a very long time. This is the sort of foot-shooting we should avoid. > > True enough. However, I hope you will agree that we should not > confuse foresight with speculation. > > At present there is no sign on the horizon of either any mac80211 > mesh code or any other full-MAC wireless driver supporting mesh. > Without either of those, it would seem imprudent to rush toward > a gneric configuration interface even if nl80211 was prepared to > sprout one. Making it generic may be premature optimization. But at the very least, we should deal with the three other problems Christoph has pointed out: subfunctions, pointer indirections, and 32on64 cleanliness. That last one may come back to bite you in a couple years' time, if not other people. It's a major pain in the ass. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/5] Use EXTRARW_DATA in architectures
* Sam Ravnborg ([EMAIL PROTECTED]) wrote: > Hi Mathieu. > > On Fri, Jun 15, 2007 at 04:30:00PM -0400, Mathieu Desnoyers wrote: > > EXTRARW_DATA adds a place to declare rw data that will not be mixed with the > > .data content; therefore limiting data cache pollution when data is put in > > the EXTRARW_DATA sections. > > I would suggest to embed this inside DATA_DATA in vmlinux.lds.h > That seems reasonsable to do instead of adding it right after DATA_DATA > for all archs. > Yes, it will be in my next release, > From your patch it looks like I originally missed out > powerpc + xtensa when introducing DATA_DATA - would be nice if > you could fix that. > > Sam Done. Thanks, 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/
[PATCH] Use DATA_DATA in xtensa
* Sam Ravnborg ([EMAIL PROTECTED]) wrote:
> From your patch it looks like I originally missed out
> powerpc + xtensa when introducing DATA_DATA - would be nice if
> you could fix that.
>
> Sam
Use DATA_DATA in xtensa
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
arch/xtensa/kernel/vmlinux.lds.S |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/xtensa/kernel/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/xtensa/kernel/vmlinux.lds.S 2007-06-16
22:20:09.0 -0400
+++ linux-2.6-lttng/arch/xtensa/kernel/vmlinux.lds.S2007-06-16
22:20:41.0 -0400
@@ -118,7 +118,8 @@
_fdata = .;
.data :
{
-*(.data) CONSTRUCTORS
+DATA_DATA
+CONSTRUCTORS
. = ALIGN(XCHAL_ICACHE_LINESIZE);
*(.data.cacheline_aligned)
}
--
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
On Sunday 17 June 2007 00:19:49 Alexandre Oliva wrote: > On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Saturday 16 June 2007 21:54:56 Alexandre Oliva wrote: > >> There may be laws that require certification or limitations on the > >> user. Manufacturer giving up the ability to make modifications would > >> address this, or *perhaps* arranging for user and manufacturer to each > >> hold half of the key needed to run a modification (which might comply > >> with the GPLv3dd4 terms, IANAL). > > > > It doesn't. The GPLv3 (dd4) makes that very clear. See the quote below. > > You left out the relevant bit: > > this requirement does not apply if neither you nor any third party > retains the ability to install modified object code on the User > Product (for example, the work has been installed in ROM). Ah, but giving the user half the key doesn't mean they still don't have access to the entire key. QED: Giving people half the key won't cut it under the GPLv3 (dd4) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Saturday 16 June 2007 21:54:56 Alexandre Oliva wrote: >> There may be laws that require certification or limitations on the >> user. Manufacturer giving up the ability to make modifications would >> address this, or *perhaps* arranging for user and manufacturer to each >> hold half of the key needed to run a modification (which might comply >> with the GPLv3dd4 terms, IANAL). > It doesn't. The GPLv3 (dd4) makes that very clear. See the quote below. You left out the relevant bit: this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). -- 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] Add missing DATA_DATA to powerpc
* Sam Ravnborg ([EMAIL PROTECTED]) wrote:
> From your patch it looks like I originally missed out
> powerpc + xtensa when introducing DATA_DATA - would be nice if
> you could fix that.
>
> Sam
Add missing DATA_DATA in powerpc
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--
arch/powerpc/kernel/vmlinux.lds.S |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/powerpc/kernel/vmlinux.lds.S 2007-06-16
22:17:53.0 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S 2007-06-16
22:18:32.0 -0400
@@ -173,7 +173,9 @@
}
#else
.data : {
- *(.data .data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
--
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
On Saturday 16 June 2007 23:31:00 Alexandre Oliva wrote: > On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > But each of those arguments is based on a technicality. > > They're based on the Free Software definition, that establishes the > four freedoms that the GPL was designed to respect and defend. And what gives you or the FSF to define what "Free Software" is? What makes the definition you are using is the correct one? But it doesn't matter. You're backpedalling, tossing up a smokescreen because you've been caught working under a double-standard. > Each version of the GPL may miss the mark. But this doesn't mean > that's not their spirit. > > > Do you know how many lawyers make a living because the "spirit" of a law > > has no legal weight? > > Yes. What's your point? That you were arguing a pitifully bad point. > All I'm trying to show is that the tivoization provision in GPLv3 is > not a departure from the spirit of the GPL. > > Is this so hard to understand? Nope. As I've stated before it doesn't matter that you believe it. What matters is that there is no single, definable "spirit" of the license. The "spirit" is what each person who places their work under the license believes it to be. > > I'm not trying to say why Linus and others chose the GPLv2. > > I'm not trying to determine what their motivations were. > > I'm not trying to force them to change to GPLv3. > > I'm not trying to convince them that tivozation is a bad thing. But you have done this multiple times. You may not have been trying to, but you were. > I'm only trying to show that anti-tivozation is in line with the > spirit of the GPL. With *YOUR* view of what the spirit is. > > tivoization, which means to restrict a user's ability to adapt the > software to their own needs and run it for any purpose, while the > hardware manufacturer keeps this to itself, is against the spirit of > the GPL. I'm a firm believer in letting people hang themselves, but this is a bit much. The TiVO company didn't do that. They kept the ability to *REPLACE* the version on the device that connects to their network to themselves. You have access to the source code TiVO uses, complete with their modifications... You can modify it in any way you choose *AND* you can distribute the code yourself. Hell, you can even *RUN* it for any purpose you want. What you can't do is replace the functional code on the device connected to their network. > Not whatever reasons the Linux developers had to release their code > under GPLv2. But the spirit that the authors of the GPL tried to > encode in it. > > Is this so difficult to accept? > > >> > That your right to configure a device ends at the point where it > >> > connects to a network? Well, unless you want to sacrifice *ALL* the > >> > stuff that makes a TiVO actually worth using, you *HAVE* to connect > >> > it to their network. > >> > >> So, if you visit www.fsfla.org, I 0w|\| your computer? > > > > Nope. Because I'm connecting the the *INTERNET*. > > Is the connection with the TiVo network not through some other > carrier too? But your server doesn't run the internet. TiVO may use phone lines to connect a device to their server (and this is an example - I don't know how TiVO devices actually connect) but the network being connected to has a single owner who can set such terms. I'll repeat, in full, my earlier examples of this: The first: I buy a cable modem. Until the second I connect the cable-line to it so I can get a connection to the internet I can configure it in whatever manner I please. The second the line is connected, even though I *OWN* the hardware, I lose all control over its configuration. The second: I buy a DSL modem. Until I want to actually connect to the internet it can have whatever settings I want it to have. The second I want to connect to the internet it has to be configured the way that the ISP wants. > > The TiVO service runs as a network - and a non-public one at that. They > > own the network, they control what hardware and with what configurations > > is allowed to connect. Whats more is that they have the right to actively > > control that configuration. > > As long as this doesn't violate any other laws or agreements they've > entered, that is. And this includes license agreements. And if the license doesn't explicitly state something as being a violation of its terms then it doesn't matter. > > You do realize, Alexandre, that you can't make me look stupid by > > just cutting out a part of a statement I've made and making silly > > comments about it. > > Didn't mean to, sorry if it seemed that way. I still don't quite > understand the distinction you're trying to make. > > > The funniest part of it is that you are claiming that the "spirit" > > of the GPL is to force each licensee to give up *MORE* rights than > > they are asked to. > > No, the GPL doesn't force anything. It can't. All it does is to > demand respect for
[PATCH] Use DATA_DATA in cris
* Sam Ravnborg ([EMAIL PROTECTED]) wrote:
> From your patch it looks like I originally missed out
> powerpc + xtensa when introducing DATA_DATA - would be nice if
> you could fix that.
>
Use DATA_DATA in CRIS
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
arch/cris/arch-v10/vmlinux.lds.S |2 +-
arch/cris/arch-v32/vmlinux.lds.S |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-lttng/arch/cris/arch-v10/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/cris/arch-v10/vmlinux.lds.S 2007-06-16
22:12:58.0 -0400
+++ linux-2.6-lttng/arch/cris/arch-v10/vmlinux.lds.S2007-06-16
22:13:28.0 -0400
@@ -44,7 +44,7 @@
___data_start = . ;
__Sdata = . ;
.data : { /* Data */
- *(.data)
+ DATA_DATA
}
__edata = . ; /* End of data section */
_edata = . ;
Index: linux-2.6-lttng/arch/cris/arch-v32/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/cris/arch-v32/vmlinux.lds.S 2007-06-16
22:13:03.0 -0400
+++ linux-2.6-lttng/arch/cris/arch-v32/vmlinux.lds.S2007-06-16
22:13:42.0 -0400
@@ -49,7 +49,7 @@
___data_start = . ;
__Sdata = . ;
.data : { /* Data */
- *(.data)
+ DATA_DATA
}
__edata = . ; /* End of data section. */
_edata = . ;
--
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
On Jun 16, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> On Jun 16, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> > No, this is completely and utterly wrong. By this logic, Linux >> > isn't free if >> > I can't run it on *YOUR* laptop. TiVo places restrictions on >> > *hardware*. The >> > hardware is not free. >> TiVo uses the hardware to stop the user from adapting the software to >> suit his/her needs. TiVo is imposing an artificial restriction on >> what you can do with the software you use. > Sure, and you use the hardware to stop me from modifying the Linux on your > laptop. Do I? How so? >> You don't use the software in my laptop. The laptop is not yours. >> You have no claims whatsoever about it. > Exactly. And I have no *GPL* claims to my laptop either. The GPL > doesn't talk about who owns what hardware and it would be insane for > it to do so. Even though the TiVo hardware is yours, you have no > more *GPL* claims to it than you do to someone else's laptop. The > GPL does not talk about who owns what hardware. This is absolutely correct. What it does is impose conditions for whoever wants to distribute the software. And GPLv3 makes it explicit that one such condition is to permit the user to install and run modified versions of the program in the hardware that ships with the program. A condition that is arguably already encoded in the "no further restrictions to the rights granted" by the license" and to the requirement for complete corresponding source code to accompany the binary. That you disagree with it doesn't make you right. But that it is within the spirit of the GPL defined by its authors (which is all I'm trying to show here), it is. > The GPL (at least through version 2) is about free access to source > code. Some think so, but this was GPLv1. v2 added stuff such as: if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program Do you realize that the patent is unrelated with the program, but nevertheless the copyright license establishes conditions about what kind of patent licenses you may accept in order for you to have permission to distribute the program. Why should restrictions through patents be unacceptable, but restrictions through hardware and software be acceptable. Both are means to disrespect users' freedoms. It is the duty of the FSF to defend these freedoms. It's its public mission. That's a publicly stated goal of the GPL, for anyone who cares to understand it, or miss it completely and then complain about changes in spirit. > They just do not include being able to use the source code on whatever > hardware you want because that hardware could be restricted for any number > of reasons. That's true. Per the license, it's only who distributes the hardware to you that shouldn't impose such restrictions. >> I see what you're getting at. This might be relevant. If I granted >> you remote access to my desktop, I probably wouldn't want to grant you >> permission to install and boot whatever kernel fancies you. >> The difference is that, when I grant you remote access to my desktop, >> I'm not distributing the software to you. But when TiVo places its >> DVR in your home, it is. > Assume the access includes the right to download copies of the software, in > that case, it is distribution. For GPL purposes, all that matters is whether > the software is distributed or not, and the rights must be the same > regardless of anything else. I'm inclined to agree. > The GPL doesn't care what your motivations are. If you can't fulfill > your GPL obligations, no matter how nice your intentions, you can't > distribute at all. That's right. But one of the obligations is to impose no further restrictions on the exercise of the rights. What is "imposing a restriction"? Installing the software in ROM isn't regarded as such, it's just a technical decision. Installing the software in modifiable non-volatile storage, but denying the user the ability to change it, is regarded as imposing a restriction. (note the "denying") It is a matter of intent. It's not because you only install say 32MB of RAM on the machine that you're denying the user the ability to run OOo on the machine. But if you ship the computer with plenty of memory, but somehow configure the hardware or the operating system so as to prevent the user from upgrading an OOo that shipped with it, while you can still install that upgrade, then you're actively placing limits on the user's freedom WRT to that software, and an anti-tivoization clause would then stop you from distributing the software under these conditions. >> > They just want the source code, and TiVo gives it to them. GPL was about >> > source code not being secret, to them and to many others. >>
And now for something _totally_ different: Linux v2.6.22-rc5
In a stunning turn of events, I've actually been able to make another -rc release despite all the discussion (*cough*flaming*cough*) about other issues, and we now have a brand-spanking-new Linux 2.6.22-rc5 release out there! As usual, you get *five* kernels for the price of one! You can get the tar-ball, the patches, or the git tree. And the tar-balls and patches come not just in the old gzipped format, you can have them bzip2'd too! So you have an incredible selection of kernels to choose from, fresh from the oven! By a happy turn of events, we have even succeeded in solving a number of annoying regressions! Special thanks go to Tejun Heo, who worked night and day, and finally reproduced and fixed the odd suspend/resume problems in the ATA layer that got introduced by some previous cleanups. But that's not all! We have other regressions fixed, and we have a bonus round of random architecture fixes, and an extra-bonus round of Blackfin updates. [ Ok, so I can't really call the Blackfin fixes for regressions, but let's face it, it's not like anybody is actually going to care. So doing the Blackfin merge at this point may not be strictly proper -rc policy, but hey, it's a new architecture. It certainly won't cause any more regressions, if only because there's not a whole lot to regress there. The same largely goes for the libertas wireless driver ;^/ ] On a more serious note, I have to admit that I'm a bit unhappy with the pure *volume* of changes this late in the game. I was really wanting to stop some of the merges, but while not all of it really fixed regressions, there really are a lot of bugfixes in there. Yeah, the *bulk* of the patch is things like PA-RISC, Blackfin and the libertas driver, but I really *really* wish people would also more obviously be working on the regression list. On that note - I doubly appreciate the people who *did* work on regressions. Thanks, guys, Linus --- Adam Litke (1): hugetlb: fix get_policy for stacked shared memory files Adrian Bunk (1): [RXRPC] net/rxrpc/ar-connection.c: fix NULL dereference Akinobu Mita (2): [CIFS] fix mempool destroy done in wrong order in cifs error path [NETFILTER]: nf_conntrack_amanda: fix textsearch_prepare() error check Alan Cox (3): MAINTAINERS: corrections libata-core/sff: Fix multiple assumptions about DMA libata: Correct abuse of language Alan Stern (2): USB: Fix up bogus bInterval values in endpoint descriptors OHCI: Fix machine check in ohci_hub_status_data Albert Lee (6): libata: print device model and firmware revision for ATAPI devices libata passthru: update protocol numbers libata passthru: support PIO multi commands libata passthru: map UDMA protocols libata passthru: always enforce correct DEV bit libata passthru: update cached device paramters Alexandr Andreev (1): parisc: sync compat getdents Alexey Dobriyan (3): parisc: make command_line[] static parisc: convert /proc/gsc/pcxl_dma to seq_file fuse: ->fs_flags fixlet Alexey Kuznetsov (1): pi-futex: fix exit races and locking problems Andrea Righi (1): [AVR32] ratelimit segfault reporting rate Andrew Morton (3): V4L/DVB (5699): Cinergyt2: fix file release handler document Acked-by: x86_64: oops_begin() fix Andrew Victor (3): [ARM] 4418/1: AT91: Number of programmable clocks differs [ARM] 4419/1: AT91: SAM9 USB clocks check for suspending [ARM] 4421/1: AT91: Value of _KEY fields. Andy Whitcroft (4): checkpatch.pl: should be executable update checkpatch.pl to version 0.03 update feature-removal-schedule.txt to include deprecated functions update checkpatch.pl to version 0.04 Antonino Daplas (3): [VIDEO] ffb: The pseudo_palette is only 16 elements long [VIDEO] sunxvr2500fb: Fix pseudo_palette array size [VIDEO] sunxvr500fb: Fix pseudo_palette array size Arnd Bergmann (2): [POWERPC] spufs: Refuse to load the module when not running on cell [POWERPC] Fix pci_setup_phb_io_dynamic for pci_iomap Atsushi Nemoto (5): [MIPS] Drop __ARCH_WANT_SYS_FADVISE64 [MIPS] Fix some system calls with long long arguments [MIPS] Fix warning by moving do_default_vi into CONFIG_CPU_MIPSR2_SRS [MIPS] Wire up utimensat, signalfd, timerfd, eventfd [MIPS] Fix IP27 build Aubrey Li (2): Blackfin arch: DMA code minor naming convention fix Blackfin arch: try to split up functions like this into smaller units according to LKML review Aurelien Jarno (1): [PARISC] Disable LWS debugging Avi Kivity (1): KVM: Prevent guest fpu state from leaking into the host Badari Pulavarty (1): Restore shmid as inode# to fix /proc/pid/maps ABI breakage Bartlomiej Zolnierkiewicz (4): serverworks: remove crappy code serverworks: fix CSB6 tuning logic it821x: RAID mode
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > But each of those arguments is based on a technicality. They're based on the Free Software definition, that establishes the four freedoms that the GPL was designed to respect and defend. Each version of the GPL may miss the mark. But this doesn't mean that's not their spirit. > Do you know how many lawyers make a living because the "spirit" of a law has > no legal weight? Yes. What's your point? All I'm trying to show is that the tivoization provision in GPLv3 is not a departure from the spirit of the GPL. Is this so hard to understand? I'm not trying to say why Linus and others chose the GPLv2. I'm not trying to determine what their motivations were. I'm not trying to force them to change to GPLv3. I'm not trying to convince them that tivozation is a bad thing. I'm only trying to show that anti-tivozation is in line with the spirit of the GPL. tivoization, which means to restrict a user's ability to adapt the software to their own needs and run it for any purpose, while the hardware manufacturer keeps this to itself, is against the spirit of the GPL. Not whatever reasons the Linux developers had to release their code under GPLv2. But the spirit that the authors of the GPL tried to encode in it. Is this so difficult to accept? >> > That your right to configure a device ends at the point where it >> > connects to a network? Well, unless you want to sacrifice *ALL* the >> > stuff that makes a TiVO actually worth using, you *HAVE* to connect >> > it to their network. >> So, if you visit www.fsfla.org, I 0w|\| your computer? > Nope. Because I'm connecting the the *INTERNET*. Is the connection with the TiVo network not through some other carrier too? > The TiVO service runs as a network - and a non-public one at that. They own > the network, they control what hardware and with what configurations is > allowed to connect. Whats more is that they have the right to actively > control that configuration. As long as this doesn't violate any other laws or agreements they've entered, that is. And this includes license agreements. > You do realize, Alexandre, that you can't make me look stupid by > just cutting out a part of a statement I've made and making silly > comments about it. Didn't mean to, sorry if it seemed that way. I still don't quite understand the distinction you're trying to make. > The funniest part of it is that you are claiming that the "spirit" > of the GPL is to force each licensee to give up *MORE* rights than > they are asked to. No, the GPL doesn't force anything. It can't. All it does is to demand respect for others' freedoms in case one decides to modify or distribute the software. It's only if you do modify or distribute the software that you must respect others' freedoms. And TiVo does distribute the software. But it doesn't respect the freedoms. It might as well stop distributing the software. > What they don't do is allow a > copy of the "covered work" to run on the hardware It's not just that. They actively stop you from being able to do so. They do this so as to prevent you from changing the behavior of the program that runs on that box. They disrespect the freedoms to adapt the program and to run it for any purpose. > By this logic I could release software under a license that says "if > you want to use this in a commercial product you have to send any > person who buys the product a copy of the complete technical > specifications - including any cryptographic keys - on request." And, guess what, you *can* do that. And it's up to the hardware manufacturer to decide whether they want to use distribute your software along with the hardware or not. Whether this would qualify as a Free Software license, and whether it would be in the spirit of the GPL, is a separate issue. -- 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] NFS: Make NFS root work again
On Sat, Jun 16, 2007 at 09:15:14AM -0700, Andrew Morton wrote: > On Thu, 07 Jun 2007 17:40:03 +0100 David Howells <[EMAIL PROTECTED]> wrote: > > Make NFS root work by creating a "/root" directory to satisfy the mount, > > otherwise the path lookup for the mount fails with ENOENT. > > > > Am still awaiting a proper description of this patch, please. > > What is not working, and how does this patch fix it? > > I am unaware of any open bug reports against NFS root. I've not had any problems with it during any of the -rc periods, for what it's worth. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, 16 Jun 2007, Alexandre Oliva wrote: > > I've already explained what the spirit of the GPL is. No. You've explained one thing only: that you cannot see that people don't *agree* on the "spirit". You think that there is only one "spirit", and that you own the code-book, and that your spirit is thus the only right one. This is where we started. The same way you seem to think that "freedom" has only the meaning *you* and the FSF give it, and that somehow the spirit of the GPL includes the "four freedoms" that aren't even _mentioned_ in it. THAT IS NOT TRUE. But equally importantly, it's not even *relevant*. Nobody is suing the FSF for contract violation for changing the spirit. Yes, people have brought out the argument that the GPLv3 actually even changes the spirit, and you don't seem to realize that people can have different opinions. You just repeat YOUR OWN OPINION about the spirit over and over again. But even if the spirit changes, so what? The GPL doesn't actually say "same in spirit". It says "similar in spirit", implying that the spirit is "similar". In other words, your arguments are wholly irrelevant. > I've already explained that the anti-Tivoization provision is in line > with it. .. and we have already explained to you that it's irrelevant. So let's get back to the *real* issue: - The GPLv2 was ok with Tivo. I really tried to explain to you *why* that was, but by now, I can't be bothered any more. Even if you cannot understand it, just accept it. And if you have a hard time accepting it, just accept the fact that the FSF thinks Tivo cannot be sued, which is just another way of saying "they didn't actually break the license". - *I* think Tivo is fine. Other people think Tivo is fine. Other people have told you they think what Tivo did is fine. Some people have even said that they don't like Tivo, but that they don't think the license should stop Tivo. - The GPLv3 tries to stop Tivo. Instead of mumbling about your spirit and feelings (I need to be a whole lot more drunk before I start caring), how about you look at those three statements, and then admit that you see why the people in bullet#2 think that GPLv2 is a better license than GPLv3 I don't *care* how you mangle the "spirit of the GPLv2", because that was never the issue. What I care about is that the GPLv3 is a _worse_license_ than GPLv2, and that I'd be stupid to select the worse of two licenses, wouldn't I? So just stop *whining* about this. The GPLv3 is the worse license, for anybody who thinks that what Tivo did should not be against the license. It really is that simple. And again: you don't even have to *like* Tivo to realize that the license itself shouldn't try to spell out some anti-Tivo measures. As I've _also_ tried to explain, the anti-Tivo measures are actually more than just "anti Tivo". They are also "anti-anything-else-that-might-want-to-lock-down-a- specific-version-for-security-or-regulatory-reasons". But in the end, it really hinges on a very simple concept: - Not everybody thinks like you or agrees with you. - In particular, the original copyright author in the kernel does *not* think like you, and *realized* that he doesn't really like the FSF religious agenda years and years ago, and made sure that the FSF cannot control the licensing of the Linux kernel. If you don't accept those two simple *facts*, I don't know what's wrong with you. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 21:54:56 Alexandre Oliva wrote: > On Jun 16, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > > I obviously wasn't clear enough. The only way to come into complience > > with GPL3dd4 is to reduce your ability to fix things or grant everyone > > else the ability to mess with things. This severely restricts you from > > doing _anything_ in certain problem spaces due to local laws on the > > topic, even if you're an otherwise good actor who is making worthwhile > > source code contributions to the rest of the community. > > I don't know any law that requires tivoization. > > There may be laws that require certification or limitations on the > user. Manufacturer giving up the ability to make modifications would > address this, or *perhaps* arranging for user and manufacturer to each > hold half of the key needed to run a modification (which might comply > with the GPLv3dd4 terms, IANAL). It doesn't. The GPLv3 (dd4) makes that very clear. See the quote below. "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. DRH > There may be business models that require the ability to make changes. > Then it's fair to enable the user to make changes as well, such that > they don't become dependent on the vendor, or even have their > 1st-generation TiVo boxes left out in the cold for a while when the US > changes the DST rules again ;-) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 21:49:56 Alexandre Oliva wrote: > On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > On Saturday 16 June 2007 15:27:37 Alexandre Oliva wrote: > >> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > >> > I don't see how TiVO has done this. They have placed no restrictions > >> > on *modification* at all. What they have done is placed a restriction > >> > on *REPLACEMENT* of the program. > >> > >> Technicality. In order for the software to remain free (which is what > >> the GPL is all about), the user must not be stopped from adapting the > >> software to suit his needs and running it for any purpose. TiVo > >> places restrictions on it. It's really this simple. > > > > Your arguments are all based on technicalities, so why are you > > complaining when I do the same? > > My arguments are based on the intent behind the license, its spirit. But each of those arguments is based on a technicality. By your reasoning I could kill everybody living in the middle east to stop the wars there and not be wrong - after all, you say "But I'm using those technicalities to show the letter and spirit of the license" - ie: "The ends justify the means". > You keep falling back to legal technicalities, that have zero to do > with the interpretation of the intent. > > That's why. > > > http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law Do you know how many lawyers make a living because the "spirit" of a law has no legal weight? > > As it stands there is *NOTHING* that singular distinction makes all the > > difference in the world. What you are arguing - based on your *BELIEF* > > that such *REPLACEMENT* is a modification. > > Maybe modification is not the best word, because it carries a lot of > legal background from copyright law. > > How about adaptation. From freedom #1, freedom to study the software > and adapt it to your needs. Do you see how tivoization imposes an > artificial restriction to this freedom? Nothing stopping people from doing that with the GPL'd software running on a TiVO. > > If you want I'll go dig out the exact place where RMS said that he > > didn't care about hardware. > > This is still true. This is not about the hardware. This is about > the software, and how the user is stopped from adapting it to her own > needs, while the vendor saves this prerogative to itself. > > > That your right to configure a device ends at the point where it > > connects to a network? Well, unless you want to sacrifice *ALL* the > > stuff that makes a TiVO actually worth using, you *HAVE* to connect > > it to their network. > > So, if you visit www.fsfla.org, I 0w|\| your computer? > > If you join a bit torrent, I can replace the operating system on your > computer? > > Sorry, I don't buy that. You're leaving something out of this > picture, and that's probably quite important. Nope. Because I'm connecting the the *INTERNET*. The internet is not owned by any one person or "legal entity" - therefore there is nobody that can demand a certain configuration. Note that I also made it a point to mention that it only applies to certain classes of networks - in the US there are laws that remove the "complete control over configuration" from telecommunications companies. But get a cable-modem in the US and your ISP has the right to configure it in *ANY* way they choose. The TiVO service runs as a network - and a non-public one at that. They own the network, they control what hardware and with what configurations is allowed to connect. Whats more is that they have the right to actively control that configuration. You do realize, Alexandre, that you can't make me look stupid by just cutting out a part of a statement I've made and making silly comments about it. If you are going to quote something I've said, make sure you quote the *ENTIRE* effective part and not just the bit you think will make you look smart. All it does is make you look like an ass. > >> If these are not restrictions on the freedoms that the GPL is designed > >> to protect to ensure that Free Software remains Free for all its > >> users, I don't know what is. > > > > "Free as in beer" is the phrasing used, I believe. > > Huh? Are you implying that the Free Software foundation wrote this > meaning "zero cost"? Nope. I was making sure that you understood your own propaganda. "Free as in beer" - if I get a free beer I'm getting the beer, not the glass. If you aren't intelligent enough to understand what I'm saying: I get the software and *ALL* rights to it that everyone *BUT* the licensor has under the GPL. What you are doing is saying "It is what is said, but not what is meant." The funniest part of it is that you are claiming that the "spirit" of the GPL is to force each licensee to give up *MORE* rights than they are asked to. In other words... TiVO is a licensee of the kernel - they received certain rights through the GPL that they are required to pass along to
Re: 2.6.22-rc4 not compiling on the SH4/Dreamcast
On Sat, Jun 16, 2007 at 09:24:11PM +0100, Adrian McMenamin wrote: > This is a patched 2.6.21.5 - which might be an issue. But this is what I > get: > > LD .tmp_vmlinux1 > arch/sh/kernel/built-in.o: In function `restore_all': > arch/sh/kernel/cpu/sh4/../sh3/entry.S:(.text+0x50cc): undefined > reference to `in_nmi' > make: *** [.tmp_vmlinux1] Error 1 > Fixed in current git. You can either toss an ifdef around the label or simply enable KGDB if you wish to work around it in the interim, or barring that, wait for -rc5. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> On Jun 16, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > > No, this is completely and utterly wrong. By this logic, Linux > > isn't free if > > I can't run it on *YOUR* laptop. TiVo places restrictions on > > *hardware*. The > > hardware is not free. > TiVo uses the hardware to stop the user from adapting the software to > suit his/her needs. TiVo is imposing an artificial restriction on > what you can do with the software you use. Sure, and you use the hardware to stop me from modifying the Linux on your laptop. You are imposing an artificial restriction on what I can do with Linux. If the restriction is in the source code of the program, I can remove it. If it's not, it's outside the scope of the GPL. > You don't use the software in my laptop. The laptop is not yours. > You have no claims whatsoever about it. Exactly. And I have no *GPL* claims to my laptop either. The GPL doesn't talk about who owns what hardware and it would be insane for it to do so. Even though the TiVo hardware is yours, you have no more *GPL* claims to it than you do to someone else's laptop. The GPL does not talk about who owns what hardware. The GPL (at least through version 2) is about free access to source code. > The GPL is not about letting you do whatever you want. It's about > ensuring every licensees respect others' freedoms, rather than > imposing artificial additional restrictions on the exercise of the > freedoms. Right, and those freedoms include getting the source code if you get the object code. They include being able to import the source code into other projects with compatible licenses. They include being able to modify the source code however you like. They just do not include being able to use the source code on whatever hardware you want because that hardware could be restricted for any number of reasons. One of them could be that it's not yours. Another of them could be that the platform itself has restrictions. > >> If these are not restrictions on the freedoms that the GPL is designed > >> to protect to ensure that Free Software remains Free for all its > >> users, I don't know what is. > > So why is it not a restriction on this freedom that I can't > > modify the copy > > of Linux running on *your* desktop? > If I gave, rented or sold the desktop to you, then I should respect > your freedom to do so. You are missing the point. Whether the laptop is mine or yours has no bearing on the GPL terms. The GPL terms are about what you get when the object code is distributed to you. To read into the GPL that you get certain rights if you own hardware that runs GPL code and not if you rent such hardware is just getting crazy. It's simply making arbitrary things up so you get the results you want in the cases you care about and don't have to deal with the crazy results you get in other cases you don't care about. It makes no logical sense and is purely ad hoc. > I have no obligation to grant you access to my desktop. If you're not > a user of this computer or of the software installed in it. Right, and TiVo has no GPL obligation to grant you access to their hardware platform, even if you own a physical implementation of it. > > If it helps you to understand the situation better, think of TiVo as > > not really selling you the hardware. > I see what you're getting at. This might be relevant. If I granted > you remote access to my desktop, I probably wouldn't want to grant you > permission to install and boot whatever kernel fancies you. > The difference is that, when I grant you remote access to my desktop, > I'm not distributing the software to you. But when TiVo places its > DVR in your home, it is. Assume the access includes the right to download copies of the software, in that case, it is distribution. For GPL purposes, all that matters is whether the software is distributed or not, and the rights must be the same regardless of anything else. > And then, again, there's the issue of motivation, the intent. Why am > I not granting you permission to reboot my computer into a different > kernel? Would you think my motivations are similar to TiVo's? That > I'm doing this for the purpose of denying you the freedom to adapt the > software to your own needs? That's all lovely stuff, but it has nothing to do with anything. The GPL doesn't care what your motivations are. If you can't fulfill your GPL obligations, no matter how nice your intentions, you can't distribute at all. > > They just want the source code, and TiVo gives it to them. GPL was about > > source code not being secret, to them and to many others. > They chose the GPL because it worked this way for them. But this is > not what the GPL is *all* about. And GPLv3 shows the difference. That's what it was about to many people, including Linus. It was about getting source code. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: b44: high ping times with wireless-dev
On Sunday 17 June 2007 02:42:18 Maximilian Engelhardt wrote: > I did build a kernel without the three mentioned above but the problem is > still the same. I also did remove everything but eth0 on interrupt 10 so the > only device using that interrupt is eth0 and then the card completely stopped > working. _That_ is interesting... Maybe the IRQ isn't correctly wired up on the backplane and it doesn't generate IRQs at all (so it only worked, because other devices on the same IRQ line triggered the line). I'll take a look at that code. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > See, that's the problem I have with your arguments. "Same freedom for > everyone" is a political slogan. It is not a reasoned thought. Well, this is what got us GPLv2. And the same reasoning is getting us GPLv3, and it does get hardware manufacturers to think twice instead of tivoizing hardware. They can decide between respecting users' freedoms and encouraging a community of developers around its product, or they can decide that not letting users change the software is more important or necessary, and give up the ability to install modifications without user approval. If half of the vendors go each way, we'll get far more contributions in the end, so we're better off. This is why I think the argument that anti-tivoization won't get us more "giving back in kind" is irrational and contradictory. > "Tivo should install ROMs so they don't have more rights than users" TiVo doesn't have to install ROMs. It can use the same technical measures it uses today, then throw away the keys. Or give the user half of the signing key, or some such. How bad would this be for them? -- 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/
[ANNOUNCE] GIT 1.5.2.2
The latest maintenance release GIT 1.5.2.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.2.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
GIT v1.5.2.2 Release Notes
==
Fixes since v1.5.2.1
* Usability fix
- git-gui is shipped with its updated blame interface. It is
rumored that the older one was not just unusable but was
active health hazard, but this one is actually pretty.
Please see for yourself.
* Bugfixes
- "git checkout fubar" was utterly confused when there is a
branch fubar and a tag fubar at the same time. It correctly
checks out the branch fubar now.
- "git clone /path/foo" to clone a local /path/foo.git
repository left an incorrect configuration.
- "git send-email" correctly unquotes RFC 2047 quoted names in
the patch-email before using their values.
- We did not accept number of seconds since epoch older than
year 2000 as a valid timestamp. We now interpret positive
integers more than 8 digits as such, which allows us to
express timestamps more recent than March 1973.
- git-cvsimport did not work when you have GIT_DIR to point
your repository at a nonstandard location.
- Some systems (notably, Solaris) lack hstrerror() to make
h_errno human readable; prepare a replacement
implementation.
- .gitignore file listed git-core.spec but what we generate is
git.spec, and nobody noticed for a long time.
- "git-merge-recursive" does not try to run file level merge
on binary files.
- "git-branch --track" did not create tracking configuration
correctly when the branch name had slash in it.
- The email address of the user specified with user.email
configuration was overriden by EMAIL environment variable.
- The tree parser did not warn about tree entries with
nonsense file modes, and assumed they must be blobs.
- "git log -z" without any other request to generate diff still
invoked the diff machinery, wasting cycles.
* Documentation
- Many updates to fix stale or missing documentation.
- Although our documentation was primarily meant to be formatted
with AsciiDoc7, formatting with AsciiDoc8 is supported better.
Changes since v1.5.2.1 are as follows:
Alex Riesen (3):
Make the installation target of git-gui a little less chatty
Fix clone to setup the origin if its name ends with .git
Add a local implementation of hstrerror for the system which do not have
it
Gerrit Pape (1):
Fix typo in remote branch example in git user manual
J. Bruce Fields (4):
user-manual: quick-start updates
user-manual: add a missing section ID
Documentation: user-manual todo
tutorial: use "project history" instead of "changelog" in header
Jakub Narebski (1):
Generated spec file to be ignored is named git.spec and not git-core.spec
Johannes Schindelin (2):
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
Johannes Sixt (1):
Accept dates before 2000/01/01 when specified as seconds since the epoch
Junio C Hamano (6):
checkout: do not get confused with ambiguous tag/branch names
$EMAIL is a last resort fallback, as it's system-wide.
git-branch --track: fix tracking branch computation.
Avoid diff cost on "git log -z"
Documentation: adjust to AsciiDoc 8
GIT 1.5.2.2
Kristian H淡gsberg (1):
Unquote From line from patch before comparing with given from address.
Luiz Fernando N. Capitulino (1):
git-cherry: Document 'limit' command-line option
Matthijs Melchior (1):
New selection indication and softer colors
Michael Milligan (1):
git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
Sam Vilain (2):
fix documentation of unpack-objects -n
Don't assume tree entries that are not dirs are blobs
Shawn O. Pearce (47):
git-gui: Allow creating a branch when none exists
git-gui: Allow as few as 0 lines of diff context
git-gui: Don't quit when we destroy a child widget
git-gui: Attach font_ui to all spinbox widgets
git-gui: Verify Tcl/Tk is new enough for our needs
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Add a 4 digit commit abbreviation to the blame viewer
git-gui: Cleanup blame::new widget initialization
git-gui: Remove empty blank line at end of blame
git-gui: Improve the coloring in blame viewer
git-gui: Simplify consecutive lines that come from the same commit
git-gui: Use arror cursor in blame viewer file data
git-gui: Display tooltips in blame viewer
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > I obviously wasn't clear enough. The only way to come into complience > with GPL3dd4 is to reduce your ability to fix things or grant everyone > else the ability to mess with things. This severely restricts you from > doing _anything_ in certain problem spaces due to local laws on the > topic, even if you're an otherwise good actor who is making worthwhile > source code contributions to the rest of the community. I don't know any law that requires tivoization. There may be laws that require certification or limitations on the user. Manufacturer giving up the ability to make modifications would address this, or *perhaps* arranging for user and manufacturer to each hold half of the key needed to run a modification (which might comply with the GPLv3dd4 terms, IANAL). There may be business models that require the ability to make changes. Then it's fair to enable the user to make changes as well, such that they don't become dependent on the vendor, or even have their 1st-generation TiVo boxes left out in the cold for a while when the US changes the DST rules again ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > On Saturday 16 June 2007 15:27:37 Alexandre Oliva wrote: >> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: >> > I don't see how TiVO has done this. They have placed no restrictions on >> > *modification* at all. What they have done is placed a restriction on >> > *REPLACEMENT* of the program. >> >> Technicality. In order for the software to remain free (which is what >> the GPL is all about), the user must not be stopped from adapting the >> software to suit his needs and running it for any purpose. TiVo >> places restrictions on it. It's really this simple. > Your arguments are all based on technicalities, so why are you complaining > when I do the same? My arguments are based on the intent behind the license, its spirit. You keep falling back to legal technicalities, that have zero to do with the interpretation of the intent. That's why. http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law > As it stands there is *NOTHING* that singular distinction makes all the > difference in the world. What you are arguing - based on your *BELIEF* that > such *REPLACEMENT* is a modification. Maybe modification is not the best word, because it carries a lot of legal background from copyright law. How about adaptation. From freedom #1, freedom to study the software and adapt it to your needs. Do you see how tivoization imposes an artificial restriction to this freedom? > If you want I'll go dig out the exact place where RMS said that he > didn't care about hardware. This is still true. This is not about the hardware. This is about the software, and how the user is stopped from adapting it to her own needs, while the vendor saves this prerogative to itself. > That your right to configure a device ends at the point where it > connects to a network? Well, unless you want to sacrifice *ALL* the > stuff that makes a TiVO actually worth using, you *HAVE* to connect > it to their network. So, if you visit www.fsfla.org, I 0w|\| your computer? If you join a bit torrent, I can replace the operating system on your computer? Sorry, I don't buy that. You're leaving something out of this picture, and that's probably quite important. >> If these are not restrictions on the freedoms that the GPL is designed >> to protect to ensure that Free Software remains Free for all its >> users, I don't know what is. > "Free as in beer" is the phrasing used, I believe. Huh? Are you implying that the Free Software foundation wrote this meaning "zero cost"? > If you have such a respect for peoples freedoms - and I don't doubt > that you actually believe you do - then why are you stripping > freedoms from people? Because they're disrespecting others' freedoms. Freedoms aren't absolute. One's freedom ends where another's freedom starts. Tivoization exceeds the hardware manufacturer's freedoms and disrespects users' freedoms and disrespect some author's ethical intent. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: limits on raid
On Sat, 16 Jun 2007, Wakko Warner wrote: > When I've had an unclean shutdown on one of my systems (10x 50gb raid5) it's > always slowed the system down when booting up. Quite significantly I must > say. I wait until I can login and change the rebuild max speed to slow it > down while I'm using it. But that is another thing. i use an external write-intent bitmap on a raid1 to avoid this... you could use internal bitmap but that slows down i/o too much for my tastes. i also use an external xfs journal for the same reason. 2 disk raid1 for root/journal/bitmap, N disk raid5 for bulk storage. no spindles in common. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: limits on raid
On Sat, 16 Jun 2007, David Greaves wrote: > Neil Brown wrote: > > On Friday June 15, [EMAIL PROTECTED] wrote: > > > > > As I understand the way > > > raid works, when you write a block to the array, it will have to read all > > > the other blocks in the stripe and recalculate the parity and write it > > > out. > > > > Your understanding is incomplete. > > Does this help? > [for future reference so you can paste a url and save the typing for code :) ] > > http://linux-raid.osdl.org/index.php/Initial_Array_Creation i fixed a typo and added one more note which i think is quite fair: It is also safe to use --assume-clean if you are performing performance measurements of different raid configurations. Just be sure to rebuild your array without --assume-clean when you decide on your final configuration. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: >> > I don't see how TiVO has done this. They have placed no restrictions on >> > *modification* at all. What they have done is placed a restriction on >> > *REPLACEMENT* of the program. >> Technicality. In order for the software to remain free (which is what >> the GPL is all about), the user must not be stopped from adapting the >> software to suit his needs and running it for any purpose. TiVo >> places restrictions on it. It's really this simple. > No, this is completely and utterly wrong. By this logic, Linux isn't free if > I can't run it on *YOUR* laptop. TiVo places restrictions on *hardware*. The > hardware is not free. TiVo uses the hardware to stop the user from adapting the software to suit his/her needs. TiVo is imposing an artificial restriction on what you can do with the software you use. You don't use the software in my laptop. The laptop is not yours. You have no claims whatsoever about it. The GPL is not about letting you do whatever you want. It's about ensuring every licensees respect others' freedoms, rather than imposing artificial additional restrictions on the exercise of the freedoms. >> If these are not restrictions on the freedoms that the GPL is designed >> to protect to ensure that Free Software remains Free for all its >> users, I don't know what is. > So why is it not a restriction on this freedom that I can't modify the copy > of Linux running on *your* desktop? If I gave, rented or sold the desktop to you, then I should respect your freedom to do so. I have no obligation to grant you access to my desktop. If you're not a user of this computer or of the software installed in it. > If it helps you to understand the situation better, think of TiVo as > not really selling you the hardware. I see what you're getting at. This might be relevant. If I granted you remote access to my desktop, I probably wouldn't want to grant you permission to install and boot whatever kernel fancies you. The difference is that, when I grant you remote access to my desktop, I'm not distributing the software to you. But when TiVo places its DVR in your home, it is. And then, again, there's the issue of motivation, the intent. Why am I not granting you permission to reboot my computer into a different kernel? Would you think my motivations are similar to TiVo's? That I'm doing this for the purpose of denying you the freedom to adapt the software to your own needs? > They just want the source code, and TiVo gives it to them. GPL was about > source code not being secret, to them and to many others. They chose the GPL because it worked this way for them. But this is not what the GPL is *all* about. And GPLv3 shows the difference. -- 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/
Problems with hda_intel, Santa Rosa, and suspend
I just received a Dell Latitude D630, with the new Intel Santa Rosa
platform. Currently, the only major driver issue I have is sound. It
worked fine in Ubuntu Feisty's 2.6.20 kernel, but now I am using Gutsy
so I can have graphics drivers. Gutsy's 2.6.22-rc3-based kernel no
longer recognized my soundcard, a Sigmatel STAC9205, which uses the
hda_intel driver. I have since fixed that problem by compiling the
hda_intel driver into the kernel (I used 2.6.22-rc4 vanilla sources),
instead of a module, but it is still a bug that it does not work as a
module.
All the following debug information was obtained from kernel 2.6.22-rc4.
However, the bug that is currently affecting me is that sound no
longer works after using ACPI suspend-to-RAM or swsusp. I compiled
ALSA debugging in, and as soon as I resume, I get tons of messages
like:
[8.474830] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0970500
[8.474954] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0af0009
[8.475078] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0a70500
[8.475207] hda-intel: send_cmd timeout: IRS=0x1, val=0xd0bf0009
(etc)
There may be more before that, but that is more than the kernel
message buffer can hold, so I can't ever see it. I get similar
timeout messages each time a PCM gets set up:
[8.972859] hda_codec_setup_stream: NID=0x10, stream=0x5, channel=0, format=0
x11
[8.972987] hda-intel: send_cmd timeout: IRS=0x1, val=0x1070650
[9.006071] hda-intel: send_cmd timeout: IRS=0x1, val=0x1020011
[9.006081] hda_codec_setup_stream: NID=0x11, stream=0x5, channel=0, format=0
x11
[9.006207] hda-intel: send_cmd timeout: IRS=0x1, val=0x1170650
[9.016117] hda-intel: send_cmd timeout: IRS=0x1, val=0x1120011
I read some of sound/pci/hda/hda_intel.c, specifically the code that
output those messages. After octupling my kernel log buffer (to 1MB),
I noticed that for the first set of timeouts (immediately upon
resume), all the "codec" nibbles are odd, the last word of the val
("verb" and "para") are all either 0x0500 or 0x0009. For the second
set (when something tries to use the card) that last word is 0x0650 or
0x0011.
I have yet to go back and re-test compiling snd-hda-intel as a module.
Thank you in advance,
Matt Mullins
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
> 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. > Also, is there a mail thread or paper somewhere describing utrace, its > interfaces and what's needed to hook it up on a platform ? See http://redhat.com/~roland/utrace/ for the patches and a porting howto. The patches add a Documentation/ file and kerneldoc stuff for the interfaces. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support
> You: conceptully-new add-on which benefits 0.25% of the user base, provided > they select the right config options and filesystem. > > Me: simpler enhancement which benefits 100% of the user base (ie: includes > 4k blocksize, 4k pagesize) and which also fixes your performance problem > with that HBA. note that at least 2.6 is doing this "sort of", better than 2.4 at least. (30% hitrate or something like that). In addition, systems with an IOMMU (many really large systems have that, as well as several x86 ones, with more and more of that in the future), this is a moot point since the IOMMU will just linearize for the device. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, Jun 16, 2007 at 08:21:22PM -0600, Jeffrey V. Merkey wrote: > Linus, > > Just take a vote and start tagging files and ignore this needless > diatribe. It is was it is, I seriously doubt you will > get all of Linux moved to GPL3 as a monolith, since you will never get > concensus. You should fork a GPL3 kernel and let people decide > whether their code goes in or not. If they don't want to move to it, new > people can contribute new code. Start a 2.8 tree or whatever that is > GPL3 only. *snicker* Yeah, Linus - when do you finally understand that nobody WANTS your GPL3 kernel? :)) ROFL -- Carlo Wood <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
Jeffrey V. Merkey wrote: The trick in the NetWare 3 model was to segregate the directory entries onto special reserved 4K directory blocks (128 byte dir records). When it came time to purge storage after the file system filled, an entire 4K block and all chains was deleted during block allocation for new files. The dir blocks were ordered by date -- oldest ones got purged first. The model worked very well until compression was added to the filesystem, then it started getting complex. I would be willing to help instrument the NetWare 3 model in this proposal on ext3, since this is a basic versioning model and would provide coverage for 99% of the folks needing this capability. I am available for questions. Jeff I resigned as Chief Scientist of Solera Networks May 8 this year -- mostly because I was not allowed to have any freedom, including working on free Linux projects. This went on for almost 4 years (since 2003). Now that I am independent again, I can work on stuff like this again. I started a new company with John Noorda (Ray Noorda's oldest son) who runs Canopy now. That's my current status. I am an owner and entrepeneur again. So I have a lot of free time and will from now on. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 wrote: On Sun, 17 Jun 2007, Bron Gondwana wrote: No, I'm arguing that it's not "mere aggregation" - the kernel is useless on that machine unless the BIOS is present or replaced with something else with equivalent functionality. That's *not* a valid argument! Linus, Just take a vote and start tagging files and ignore this needless diatribe. It is was it is, I seriously doubt you will get all of Linux moved to GPL3 as a monolith, since you will never get concensus. You should fork a GPL3 kernel and let people decide whether their code goes in or not. If they don't want to move to it, new people can contribute new code. Start a 2.8 tree or whatever that is GPL3 only. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Cox wrote: (Vax/VMS System Software Handbook) (TOPS-20 User's Manual) Also Files/11 Basic versioning goes back to at least ITS Not sure how old doing file versioning and hiding it away with a tool to go rescue the stuff you blew away by mistake is, but Novell Netware 3 certainly did a good job on that one The trick in the NetWare 3 model was to segregate the directory entries onto special reserved 4K directory blocks (128 byte dir records). When it came time to purge storage after the file system filled, an entire 4K block and all chains was deleted during block allocation for new files. The dir blocks were ordered by date -- oldest ones got purged first. The model worked very well until compression was added to the filesystem, then it started getting complex. I would be willing to help instrument the NetWare 3 model in this proposal on ext3, since this is a basic versioning model and would provide coverage for 99% of the folks needing this capability. I am available for questions. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, 17 Jun 2007, Bron Gondwana wrote: > > No, I'm arguing that it's not "mere aggregation" - the kernel is useless > on that machine unless the BIOS is present or replaced with something > else with equivalent functionality. That's *not* a valid argument! I know, I know, it's a common one, but it is *nonsense*. The thing is, "mere aggregation" doesn't mean what you think it means. "Mere aggregation" doesn't mean that they cannot depend on each other. It means that they are not *based* on each other in the sense of GPLv2. In other words, "mere aggregation" is about two pieces that are not derivative works under copyright law. For example, on a Red Hat DVD, *every*single*binary* on that DVD requires a kernel to run on. And the kernel image itself "depends" on the user programs to actually do something _useful_. But it's all still "mere aggregation", because they are not related to each other in the sense of being derived works! So "mere aggregation" is not about intimacy. OF COURSE high-tech products depend intimately on each other. The Linux kernel cannot boot on a PC without a BIOS or something equivalent. You cannot run your graphical environment without a kernel, an X server, the CPU, the memory, the display, the BIOS, the power company (or an equivalent hand-crank) etc etc etc, and these things are all very much dependent on each other to make a "usable system", that has absolutely _zero_ relevance to whether they are "mere aggregation" or not. So the only thing the "mere aggregation" phrase in the GPLv2 means is simply: "putting together two or more pieces that are not derived works of each other". That's what that mere aggregation of another work not based on the Program part of the license is all about. The BIOS is "another work", and it clearly is "not based on the Program". The "aggregation" just means "putting them together", and the "mere" is there just to show that as far as the license is concerned, that is not even interesting! In other words, the sentence in section 2 about mere aggregation says one thing only: the fact that you lump things together storage-wise does not matter *at*all* for the license. The _only_ thing that matters for the GPLv2 is whether something is a derived work, _not_ whether it is lumped together, and depends on something else. This is why the BIOS is irrelevant. You can put it in the same flash chip as the kernel: it still isn't a derived work of Linux (and Linux is not a derived work of the BIOS), and the GPLv2 explicitly makes it clear that the license holds no sway over the BIOS, even though it's physically on the same chip. The BIOS can do whatever it wants to, and the GPLv2 has *nothing* to say about it. The GPLv2 makes that very clear indeed. It is just "mere aggregation", and the fact that they are in the same machine, on the same harddisk, on the same flash rom, or on the same DVD doesn't bring them any closer from a *copyright* angle. Copyright in general (and the GPLv2 in the specific) isn't about how things are *physically* tied together. It's not even about how things interconnect, and how "important" they are for each other. It is _purely_ about whether they are derived works. So when the GPLv2 talks about "mere aggregation", it talks about it specifically to say that it does not matter, and that the license _only_ affects the actual derived work! This is why the BIOS, the hardware, the programs you run under Linux etc etc are all totally irrelevant. The GPLv2 explicitly says that they are irrelevant as far as that license is concerned. 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: regression tracking (Re: Linux 2.6.21)
On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote: >... > [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too > few FireWire driver users run -rc kernels".] Getting more people testing -rc kernels might be possible, and I don't think it would be too hard. And not only FireWire would benefit from this, remember e.g. that at least 2 out of the last 5 kernels Linus released contained filesystem corruption regressions. The problem is that we aren't able to handle the many regression reports we get today, so asking for more testing and regression reports today would attack it at the wrong part of the chain. Additionally, every reported and unhandled regression will frustrate the reporter - never forget that we have _many_ unhandled bug reports (including but not limited to regression reports) where the submitter spent much time and energy in writing a good bug report. If we somehow gain the missing manpower for debugging regressions we can actively ask for more testing. Missing manpower (of people knowing some part of the kernel well) for debugging bug reports is IMHO the one big source of quality problems in the Linux kernel. If we get this solved, things like getting more testers for -rc kernels will become low hanging fruits. > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] update checkpatch.pl to version 0.05
Jan Engelhardt wrote:
> On Jun 16 2007 22:42, Andy Whitcroft wrote:
>> @@ -180,12 +182,17 @@ sub ctx_block_get {
>> sub ctx_block_outer {
>> my ($linenr, $remain) = @_;
>>
>> -return ctx_block_get($linenr, $remain, 1);
>> +return ctx_block_get($linenr, $remain, 1, '\{', '\}');
>
> '\\{'.
I want the string to be \{ ... '\}' gives me that:
$ perl
$q = '\}';
print "$q\n";
\}
> Or, if it works, directly use
> return _block_get($linenr, $remain, 1, qr/\{/, qr/\}/);
>
>> +sub ctx_statement {
>> +my ($linenr, $remain) = @_;
>> +
>> +return ctx_block_get($linenr, $remain, 0, '\(', '\)');
>
> ^^
>
>> +my $ident = '[A-Za-z\d_]+';
>
> Oh yes, use the qr operator here. (qr{}, qr//, choose anything like you
> would do with m//)
Well I want a combination of variable expanded and not expanded. I
think there will be a general cleanup to some standard quoting for the
RE's as there are hundreds, and about 7 different quote styles right now.
>
>> +my $storage = '(?:extern|static)';
>> +my $sparse = '(?:__user|__kernel|__force|__iomem)';
>> +my $type= '(?:unsigned\s+)?' .
>> + '(?:void|char|short|int|long|unsigned|float|double|' .
>> + 'long\s+long|' .
>> + "struct\\s+${ident}|" .
>> + "union\\s+${ident}|" .
>> + "${ident}_t)" .
>> + "(?:\\s+$sparse)*" .
>> + '(?:\s*\*+)?';
>> +my $attribute = '(?:__read_mostly|__init|__initdata)';
>> +
>> +my $Ident = $ident;
>> +my $Type= $type;
>> +my $Storage = $storage;
>> +my $Declare = "(?:$storage\\s+)?$type";
>> +my $Attribute = $attribute;
>> +
>
>> #trailing whitespace
>> -if ($line=~/\+.*\S\s+$/) {
>> +if ($line=~/^\+.*\S\s+$/) {
> if ($line =~ /^\+.*\S\s+$/) {
>> my $herevet = "$here\n" . cat_vet($line) . "\n\n";
>> print "trailing whitespace\n";
>> print "$herevet";
>> @@ -392,17 +420,20 @@ sub process {
>> #
>> next if ($in_comment);
>>
>> -# Remove comments from the line before processing.
>> +# Remove comments from the line before processing.
>> $line =~ s@/\*.*\*/@@g;
>> $line =~ s@/\*.*@@;
>
> C being a wonderful language, has this nice pitfall for parsers
>
> foo = number /*pointer_to_int;
Hmm really? Thats not how gcc seems to parse that, it seems to think
its a comment. Which makes us safe, as the compiler will trip them up.
$ cat test4.c
int main(int argc, char *argv[])
{
int _p = 10;
int *p = &_p;
int foo = 10 /*p;
printf("foo=%d\n", foo);
}
$ cc -o test4 test4.c
test4.c:6:15: error: unterminated comment
test4.c: In function 'main':
test4.c:6: error: expected ',' or ';' at end of input
test4.c:6: error: expected declaration or statement at end of input
>> $line =~ [EMAIL PROTECTED]/@@;
>>
>> -#
>> -# Checks which may be anchored in the context.
>> -#
>> +# Standardise the strings and chars within the input to simplify matching.
>> +$line = sanitise_line($line);
>> +
>> +#
>> +# Checks which may be anchored in the context.
>> +#
>>
>> -# Check for switch () and associated case and default
>> -# statements should be at the same indent.
>> +# Check for switch () and associated case and default
>> +# statements should be at the same indent.
>> if ($line=~/\bswitch\s*\(.*\)/) {
>
> Codingstyle warrants \bswitch\s+ :)
Yep and we check for that. But here we are trying to catch a switch and
case at differing levels, we want to catch that whether they got their
spacing right or not.
>> # * goes on variable not on type
>> -my $type = '(?:char|short|int|long|unsigned|float|double|' .
>> - 'struct\s+[A-Za-z\d_]+|' .
>> - 'union\s+[A-Za-z\d_]+)';
>> -
>
> qr. (I don't know what it is good for - compare qr/xyz/ with 'xyz'...,
> but there's a reason to its existence, so let's use it :-)
Well I would tend to say use what works and is easy to understand. The
semantics of '' and "" are well known, to change to qr{} I would have to
go read the manual to know what it is going to do. That said, _if_ it
did have the same semantics as m// then it may wel allow all of these to
be expressed as qr{} as it would expand variables but treat \ as if we
were in ''. So ... to the manual for me.
-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: b44: high ping times with wireless-dev
On Sunday 17 June 2007, Stephen Hemminger wrote: > On Sat, 16 Jun 2007 23:27:43 +0200 > > Maximilian Engelhardt <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I recently did some test and found out something interesting about the > > b44 problem I wrote earlier. > > > > The problem is the following: > > When I use my BCM4401 with the b44 driver in wireless-dev I get very high > > ping times looking like this: > > > > 64 bytes from 172.30.10.1: icmp_seq=1 ttl=64 time=1863 ms > > 64 bytes from 172.30.10.1: icmp_seq=2 ttl=64 time=855 ms > > 64 bytes from 172.30.10.1: icmp_seq=3 ttl=64 time=1855 ms > > 64 bytes from 172.30.10.1: icmp_seq=4 ttl=64 time=855 ms > > 64 bytes from 172.30.10.1: icmp_seq=5 ttl=64 time=1854 ms > > 64 bytes from 172.30.10.1: icmp_seq=6 ttl=64 time=854 ms > > 64 bytes from 172.30.10.1: icmp_seq=7 ttl=64 time=1851 ms > > 64 bytes from 172.30.10.1: icmp_seq=8 ttl=64 time=851 ms > > 64 bytes from 172.30.10.1: icmp_seq=9 ttl=64 time=1851 ms > > 64 bytes from 172.30.10.1: icmp_seq=10 ttl=64 time=851 ms > > > > I also found out that shortly after I boot my laptop and log into kde > > ping times are not that high but start to increase very quickly: > > > > 64 bytes from 172.30.10.1: icmp_seq=53 ttl=64 time=2.19 ms > > 64 bytes from 172.30.10.1: icmp_seq=54 ttl=64 time=2.22 ms > > 64 bytes from 172.30.10.1: icmp_seq=55 ttl=64 time=2.20 ms > > 64 bytes from 172.30.10.1: icmp_seq=56 ttl=64 time=2.20 ms > > 64 bytes from 172.30.10.1: icmp_seq=57 ttl=64 time=18.6 ms > > 64 bytes from 172.30.10.1: icmp_seq=58 ttl=64 time=1268 ms > > 64 bytes from 172.30.10.1: icmp_seq=59 ttl=64 time=268 ms > > 64 bytes from 172.30.10.1: icmp_seq=60 ttl=64 time=1268 ms > > 64 bytes from 172.30.10.1: icmp_seq=61 ttl=64 time=268 ms > > 64 bytes from 172.30.10.1: icmp_seq=62 ttl=64 time=6.08 ms > > 64 bytes from 172.30.10.1: icmp_seq=63 ttl=64 time=268 ms > > 64 bytes from 172.30.10.1: icmp_seq=64 ttl=64 time=1264 ms > > 64 bytes from 172.30.10.1: icmp_seq=65 ttl=64 time=264 ms > > > > After some time digging around I found out something really interesting. > > When I play some music ping times are immediately lower. If I stop > > playing music they are back to the same times as they were before. > > > > I guess that there is a problem with interrupts so I post some > > information of my system in hope it will be usefull. > > > > [EMAIL PROTECTED]:~$ cat /proc/interrupts > > CPU0 > > 0: 126317XT-PIC-XTtimer > > 1: 3600XT-PIC-XTi8042 > > 2: 0XT-PIC-XTcascade > > 7: 1XT-PIC-XTparport0 > > 8: 1XT-PIC-XTrtc > > 9: 17371XT-PIC-XTacpi > > 10: 13237XT-PIC-XTfirewire_ohci, yenta, yenta, > > ehci_hcd:usb1, uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4, Intel > > 82801DB-ICH4 Modem, eth0 > > 11: 89059XT-PIC-XTuhci_hcd:usb2, [EMAIL > > PROTECTED]::00:02.0 > > 12:632XT-PIC-XTi8042 > > 14: 10354XT-PIC-XTlibata > > 15: 7408XT-PIC-XTlibata > > NMI: 0 > > ERR: 0 > > > > > > [...] > > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10 > > ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low) > > -> IRQ 10 > > ssb: Sonics Silicon Backplane found on PCI device :02:02.0 > > b44.c:v2.0 > > eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:c0:9f:29:99:a7 > > [...] > > > > This problem did only happen with wireless-dev (checkout this evening) > > and with -mm kernels I used some time ago for testing. Currently I'm > > running 2.6.22-rc4 that works perfectly fine and doesn't show that > > problem. > > > > Maxi > > Can you build with APIC for uniprocessor. I did enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC and tried with lapic and apic=force but couldn't get APIC working. > > There is lots of IRQ sharing, so > - one of the other device's may be not handling shared IRQ properly. >Try unloading firewhire modem and yenta devices. > > - IRQ might be set edge triggered which doesn't work with NAPI > or shared IRQ. I did build a kernel without the three mentioned above but the problem is still the same. I also did remove everything but eth0 on interrupt 10 so the only device using that interrupt is eth0 and then the card completely stopped working. Maxi signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Alexandre Oliva wrote: > On Jun 16, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > >> Alexandre Oliva wrote: >>> On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: >>> What this means for the FSF goals if Tivo get up one morning and switch their system firmware to ROM however is interesting 8) >>> I'm not the FSF, and I don't speak for it, but it seems to me that >>> this would be "mission accomplished". > >> This is insane. You start with a lofty ideal involving "freedom", and >> when you end up with a meaningless technicality (and in technical terms >> a change for the worse) you consider it a victory? > > It accomplishes the mission in that everyone is on the same grounds. > Same freedom for everyone. See, that's the problem I have with your arguments. "Same freedom for everyone" is a political slogan. It is not a reasoned thought. "We must stop terrorists" is also a political slogan, and the consequence "Tivo should install ROMs so they don't have more rights than users" is about equivalent as a victory for freedom as disallowing liquids in hand luggage is a victory against terrorism. Both are nonsensical consequences of a political agenda that is applied without thought. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
[note: I'm writting this while offline and likely to remain so for the next 8 hours or so, so I'll probably miss a bunch of other replies] On Sat, Jun 16, 2007 at 02:14:29PM -0300, Alexandre Oliva wrote: > On Jun 16, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > > > On Sat, Jun 16, 2007 at 05:22:21AM -0300, Alexandre Oliva wrote: > >> On Jun 15, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > >> > >> > because it could easily be argued that they linked the BIOS with the > >> > Linux kernel > >> > >> How so? > > > Er, they installed it in the same piece of equipment, and the kernel > > couldn't function without it in that work. > > I see what you're getting at. You're thinking of a license that > doesn't respect the idea of "mere aggregation", right? No, I'm arguing that it's not "mere aggregation" - the kernel is useless on that machine unless the BIOS is present or replaced with something else with equivalent functionality. I suspect any decent lawyer could make the theory that this made the kernel as compiled on to that machine with specific chipset support selected for that hardware into a "derived work" of the BIOS - especially if the vendor had contributed GPLed code for drivers which interact with their hardware into said kernel. In fact, particularly if the hardware vendor has also contributed GPL code that interacts on one side of the software/(firmware, hardware) boundard which worked around bugs in said firmware/hardware which they also had the ability to change. The two really are a combined work of which only one part is GPLed. Ringing any binary kernel module video card driver bells yet? It's really the same thing from the opposite direction - the only criteria is where you fit in the pecking order - hardware manufacturers work around Windows bugs, Linux kernel drivers work around hardware bugs - it's all about who has more to lose if they aren't compatible. > For starters, this wouldn't evidently not qualify as an Open Source > license, and I'm pretty sure it wouldn't qualify as a Free Software > license either. Strawman licence? > > By using GPLix as part of their boot process along with their > > non-GPL BIOS, they're subverting the freedoms that the user should > > have in being able to control the entire boot process. > > You're pushing the "freedom to change" too far. Sure, I'd like to be > able to do that, and I prefer hardware that lets me do it, but it's > not like this BIOS in the scenario you described is being used as a > means to stop me from modifying the GPLed software. Well, yeah - except this is the direction GPL3 takes us, and it's a theory that GPL3 makes more likely to fly in court than GPL2 does - meaning that hardware vendor lawyers lie awake at night worrying about stuff (I'd hate to be a good lawyer - I'd never get any sleep!) > I have never said that including a GPLed piece of software should > grant users the right to modify anything whatsoever in the system, or > grant them control over the entire system. Others have, but it's not > true, it just shows how much mis-information is floating around. No, but your interactions with Linus (lazy bums 'r' us) have shown that the logical result of what you do want includes this. It's a lot harder to objectively judge one of these than the other: a) have they provided the source code to this binary to anyone who asks. b) have any of the limitations of this piece of hardware been created with the intent of making it more difficult for J. Random Enduser to build modified binaries from said source and have them function correctly. (b) has much more scope for shenanigans by bad apples on the copyright owner side - and don't pretend that only the hardware vendors are bad guys - it takes all sorts and the idea of a licence is to protect both parties. > All the GPL stands for is to defend the freedom of the users over the > particular program it applies to. You can't impose further > restrictions on the user's ability to modify what *that* software > does. Except where they run into limitations of the platform itself, or just plain bugs. Oops. The lawyers will have a field day discovering intent every time J. Random's kernel doesn't do what he wants after he fiddles the code a bit. > If you wanted to change something else, but this something else is not > covered by the license, and is not being used to contradict the terms > of the license, well, too bad, you lose. > > > b) deny themselves the ability to every offer a patch to said BIOS if > >bugs are found > > > Point (b) is also exactly on topic for the discussion of enforcing > > legal safety obligations in hardware on a peripheral rather than the > > software drivers. > > > It's requiring that these limitations be placed in a technically > > inferior location to hack around a legal "bug". > > I don't think this last sentence is true. If you implement hardware > locks that prevent modification of the software even by
Re: [RFC] [PATCH] selective signal ptracing
On Sat, 2007-06-16 at 00:26 +0100, Alan Cox wrote: > On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) > Roland McGrath <[EMAIL PROTECTED]> wrote: > > > I am not in favor of any enhancements to the ptrace interface. > > It is a terrible interface and just needs to die. > > That might make sense if utrace ever looked like it would solve the > questions about platforms like ARM What are the issues with arch like ARM ? Also, is there a mail thread or paper somewhere describing utrace, its interfaces and what's needed to hook it up on a platform ? /me mostly missed that train Thanks ! Cheers, 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, Jun 16, 2007 at 03:12:57PM -0700, Linus Torvalds wrote: >"In order to protect your freedoms, we sometimes have to take some > freedoms away. In particular, the freedom of critical thinking got > revoked last year, because people were just too 'confused'" ITYM "upgraded to Loyalty To The Cause, which is the best antidote against doubt and confusion plaguing the so-called rationalists". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Hi all. I'm currently running with the combined patch applied all the time, and it seems to be working fine here, including with hibernation. Regards, Nigel -- Nigel, Michelle and Alisdair Cunningham 5 Mitchell Street Cobden 3266 Victoria, Australia pgpWMNFx8xpyo.pgp Description: PGP signature
Re: b44: high ping times with wireless-dev
On Sat, 16 Jun 2007 23:27:43 +0200 Maximilian Engelhardt <[EMAIL PROTECTED]> wrote: > Hello, > > I recently did some test and found out something interesting about the b44 > problem I wrote earlier. > > The problem is the following: > When I use my BCM4401 with the b44 driver in wireless-dev I get very high > ping > times looking like this: > > 64 bytes from 172.30.10.1: icmp_seq=1 ttl=64 time=1863 ms > 64 bytes from 172.30.10.1: icmp_seq=2 ttl=64 time=855 ms > 64 bytes from 172.30.10.1: icmp_seq=3 ttl=64 time=1855 ms > 64 bytes from 172.30.10.1: icmp_seq=4 ttl=64 time=855 ms > 64 bytes from 172.30.10.1: icmp_seq=5 ttl=64 time=1854 ms > 64 bytes from 172.30.10.1: icmp_seq=6 ttl=64 time=854 ms > 64 bytes from 172.30.10.1: icmp_seq=7 ttl=64 time=1851 ms > 64 bytes from 172.30.10.1: icmp_seq=8 ttl=64 time=851 ms > 64 bytes from 172.30.10.1: icmp_seq=9 ttl=64 time=1851 ms > 64 bytes from 172.30.10.1: icmp_seq=10 ttl=64 time=851 ms > > I also found out that shortly after I boot my laptop and log into kde ping > times are not that high but start to increase very quickly: > > 64 bytes from 172.30.10.1: icmp_seq=53 ttl=64 time=2.19 ms > 64 bytes from 172.30.10.1: icmp_seq=54 ttl=64 time=2.22 ms > 64 bytes from 172.30.10.1: icmp_seq=55 ttl=64 time=2.20 ms > 64 bytes from 172.30.10.1: icmp_seq=56 ttl=64 time=2.20 ms > 64 bytes from 172.30.10.1: icmp_seq=57 ttl=64 time=18.6 ms > 64 bytes from 172.30.10.1: icmp_seq=58 ttl=64 time=1268 ms > 64 bytes from 172.30.10.1: icmp_seq=59 ttl=64 time=268 ms > 64 bytes from 172.30.10.1: icmp_seq=60 ttl=64 time=1268 ms > 64 bytes from 172.30.10.1: icmp_seq=61 ttl=64 time=268 ms > 64 bytes from 172.30.10.1: icmp_seq=62 ttl=64 time=6.08 ms > 64 bytes from 172.30.10.1: icmp_seq=63 ttl=64 time=268 ms > 64 bytes from 172.30.10.1: icmp_seq=64 ttl=64 time=1264 ms > 64 bytes from 172.30.10.1: icmp_seq=65 ttl=64 time=264 ms > > After some time digging around I found out something really interesting. When > I play some music ping times are immediately lower. If I stop playing music > they are back to the same times as they were before. > > I guess that there is a problem with interrupts so I post some information of > my system in hope it will be usefull. > > [EMAIL PROTECTED]:~$ cat /proc/interrupts > CPU0 > 0: 126317XT-PIC-XTtimer > 1: 3600XT-PIC-XTi8042 > 2: 0XT-PIC-XTcascade > 7: 1XT-PIC-XTparport0 > 8: 1XT-PIC-XTrtc > 9: 17371XT-PIC-XTacpi > 10: 13237XT-PIC-XTfirewire_ohci, yenta, yenta, > ehci_hcd:usb1, > uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, > eth0 > 11: 89059XT-PIC-XTuhci_hcd:usb2, [EMAIL > PROTECTED]::00:02.0 > 12:632XT-PIC-XTi8042 > 14: 10354XT-PIC-XTlibata > 15: 7408XT-PIC-XTlibata > NMI: 0 > ERR: 0 > > > [...] > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10 > ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> > IRQ 10 > ssb: Sonics Silicon Backplane found on PCI device :02:02.0 > b44.c:v2.0 > eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:c0:9f:29:99:a7 > [...] > > This problem did only happen with wireless-dev (checkout this evening) and > with -mm kernels I used some time ago for testing. Currently I'm running > 2.6.22-rc4 that works perfectly fine and doesn't show that problem. > > Maxi Can you build with APIC for uniprocessor. There is lots of IRQ sharing, so - one of the other device's may be not handling shared IRQ properly. Try unloading firewhire modem and yenta devices. - IRQ might be set edge triggered which doesn't work with NAPI or shared IRQ. -- Stephen Hemminger <[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: 2.6.22-rc4 XFS fails after hibernate/resume
On Saturday, 16 June 2007 21:56, David Greaves wrote: > This isn't a regression. > > I was seeing these problems on 2.6.21 (but 22 was in -rc so I waited to try > it). > I tried 2.6.22-rc4 (with Tejun's patches) to see if it had improved - no. > > Note this is a different (desktop) machine to that involved my recent bugs. > > The machine will work for days (continually powered up) without a problem and > then exhibits a filesystem failure within minutes of a resume. > > I know xfs/raid are OK with hibernate. Is lvm? > > The root filesystem is xfs on raid1 and that doesn't seem to have any > problems. What is the partition that's showing problems? How's it set up, on how many drives etc.? Also, is the dmesg output below from right after the resume? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] 2.6.22-rc4 XFS fails after hibernate/resume
David Greaves wrote: This isn't a regression. I was seeing these problems on 2.6.21 (but 22 was in -rc so I waited to try it). I tried 2.6.22-rc4 (with Tejun's patches) to see if it had improved - no. Note this is a different (desktop) machine to that involved my recent bugs. The machine will work for days (continually powered up) without a problem and then exhibits a filesystem failure within minutes of a resume. I know xfs/raid are OK with hibernate. Is lvm? I have LVM working with hibernate w/o any problems (w/ ext3). If there were a problem it wouldn't be with LVM but with device-mapper, and I doubt there's a problem with either. The stack trace shows that you're within XFS code (but it's likely its hibernate). You can easily check whether its LVM/device-mapper: 1) check "dmsetup table" - it should be the same before hibernating and after resuming. 2) read directly from the LV - ie, "dd if=/dev/mapper/video_vg-video_lv of=/dev/null bs=10M count=200". If dmsetup shows the same info and you can read directly from the LV I doubt it would be a LVM/device-mapper problem. Cheers, Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 18:01:59 Alexandre Oliva wrote:
> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Saturday 16 June 2007 04:21:04 Alexandre Oliva wrote:
> >> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> >> > In the case of renting a machine you can try to legislate new laws all
> >> > you want. It doesn't make a difference. There are certain rights you
> >> > don't get when renting something that you do when you own it.
> >>
> >> You mean renting the computer with the software in it is not
> >> distribution of the software?
> >
> > It is. But you don't have the same rights to a rented machine as you
> > do to one you have purchased.
>
> That's true. But since it's distribution, the licensing terms of the
> software in there must be followed, or the software must be removed.
> It's really this simple.
>
> It's not about the hardware. It's about the software and what you
> must not prevent others from doing with it.
>
> > And yes, they can even have terms in it that violate the GPL. Not
> > that a "renters contract" ("rental agreement" or whatever they call
> > them in your jurisdiction) that has those terms can *legally*
> > violate the GPL - but it doesn't stop them from existing.
>
> By "legally violate the GPL", do you mean lawfully escape the terms of
> the GPL, or that infringe the copyrights of the authors for violate
> its legal terms? I hope it's the latter.
Sorry, poor choice of words. I meant that they can violate the GPL, because
they have the right to say "You can't modify the software on the device you
are renting". I mis-stated it because I didn't make it clear that, even
though that is their legal right, they would still be in violation of the
GPL.
The reason that it is different from the TiVO case is that they have not
stopped you from doing any modification - what they have prevented is the use
of those modifications on the hardware they designed. The response from the
FSF and people like you (Alexandre) is childish - at best. "They have one of
our toys in their house but we can't play with it. WH!"
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > On 16/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> On Jun 16, 2007, Al Viro <[EMAIL PROTECTED]> wrote: >> >> > How the hell does that improve the situation for users? >> >> Maybe it doesn't. How does it make it worse? >> > Now not even the vendor can upgrade the software in the hardware and > fix problems for the user. The user loses. Assuming the vendor's intent as for patching the software is to help the user. If the vendor doesn't want to let the user do that independently, why should this assumption hold? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 15:27:37 Alexandre Oliva wrote: > On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > I don't see how TiVO has done this. They have placed no restrictions on > > *modification* at all. What they have done is placed a restriction on > > *REPLACEMENT* of the program. > > Technicality. In order for the software to remain free (which is what > the GPL is all about), the user must not be stopped from adapting the > software to suit his needs and running it for any purpose. TiVo > places restrictions on it. It's really this simple. Your arguments are all based on technicalities, so why are you complaining when I do the same? As it stands there is *NOTHING* that singular distinction makes all the difference in the world. What you are arguing - based on your *BELIEF* that such *REPLACEMENT* is a modification. By the way, Alexandre, I'm not so much of an *IDIOT* as to believe that you don't understand the difference. You are arguing about it because you *WANT* the difference to not exist. You are arguing about it because it makes your argument that what TiVO did broke the "spirit" of the license. If you want I'll go dig out the exact place where RMS said that he didn't care about hardware. You want another "technicality"? How about one that you *AGREED* is valid? That your right to configure a device ends at the point where it connects to a network? Well, unless you want to sacrifice *ALL* the stuff that makes a TiVO actually worth using, you *HAVE* to connect it to their network. At that point *ALL* of its configuration details - yes, even the Operating System - fall under their control. In the US there are laws that restrict this right when applied to "telecommunications" companies - but TiVO *isn't* a "telecommunications" company. > And then, TiVo doesn't really prohibit replacement. You can replace > it as much as you like; just not as conveniently as TiVo can replace > it. And then, if you do, it won't run, because it's not signed with a > key that they omit from the source code. And they do this in order to > prevent the user from changing the behavior of the Free Software that > they use, while they keep this ability to themselves. If your argument is that the final output binary is created by combining the signing key and an interrim binary then you *MIGHT* have a point. The simple fact is that that argument depends on whether the kernel itself is modified by the signing process or if the signing process generates a separate signature which is then verified as part of the boot process. > If these are not restrictions on the freedoms that the GPL is designed > to protect to ensure that Free Software remains Free for all its > users, I don't know what is. "Free as in beer" is the phrasing used, I believe. I see nothing in that TiVO has done that negates this. I do disagree with it - if I buy a TiVO box, I own it and should be able to do what I want with it. However, this does not negate the fact that it does connect to their network, and as a device that does such they are allowed to configure it in *ANY* manner they choose. What you and the FSF are trying to do is strip that right from them. If you have such a respect for peoples freedoms - and I don't doubt that you actually believe you do - then why are you stripping freedoms from people? DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, 16 Jun 2007, Jesper Juhl wrote: > > Now not even the vendor can upgrade the software in the hardware and > fix problems for the user. The user loses. You're seeing that the wrong way. The correct response is (and I quote from the manual, pick one talking point at random): "This is a great step for freedom, as the users now have exactly the same rights as the vendors." "When we talk about free software, we don't talk about 'free as in beer', we talk about 'free as in buggy and unfixable'" "You're now at least no less free than anybody else!" "Oh, except for the fact that those other people still design the hardware you are using, and the programs you watch. But we have a plan for that too! We will make the GPLv4 outlaw Disney and Britney Spears!" "In order to protect your freedoms, we sometimes have to take some freedoms away. In particular, the freedom of critical thinking got revoked last year, because people were just too 'confused'" "There are no American Infidels in Baghdad. Never!" There's a long list of those things, but sadly I didn't have time to copy them all when I sneaked into the FSF main office in my ninja suit under the cover of darkness. 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: Versioning file system
> (Vax/VMS System Software Handbook) > (TOPS-20 User's Manual) Also Files/11 Basic versioning goes back to at least ITS Not sure how old doing file versioning and hiding it away with a tool to go rescue the stuff you blew away by mistake is, but Novell Netware 3 certainly did a good job on that one - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> On Saturday 16 June 2007 04:21:04 Alexandre Oliva wrote:
>> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>> > In the case of renting a machine you can try to legislate new laws all
>> > you want. It doesn't make a difference. There are certain rights you
>> > don't get when renting something that you do when you own it.
>>
>> You mean renting the computer with the software in it is not
>> distribution of the software?
> It is. But you don't have the same rights to a rented machine as you
> do to one you have purchased.
That's true. But since it's distribution, the licensing terms of the
software in there must be followed, or the software must be removed.
It's really this simple.
It's not about the hardware. It's about the software and what you
must not prevent others from doing with it.
> And yes, they can even have terms in it that violate the GPL. Not
> that a "renters contract" ("rental agreement" or whatever they call
> them in your jurisdiction) that has those terms can *legally*
> violate the GPL - but it doesn't stop them from existing.
By "legally violate the GPL", do you mean lawfully escape the terms of
the GPL, or that infringe the copyrights of the authors for violate
its legal terms? I hope it's the latter.
--
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] update checkpatch.pl to version 0.05
On Jun 16 2007 22:42, Andy Whitcroft wrote:
>@@ -180,12 +182,17 @@ sub ctx_block_get {
> sub ctx_block_outer {
> my ($linenr, $remain) = @_;
>
>- return ctx_block_get($linenr, $remain, 1);
>+ return ctx_block_get($linenr, $remain, 1, '\{', '\}');
'\\{'.
Or, if it works, directly use
return _block_get($linenr, $remain, 1, qr/\{/, qr/\}/);
>+sub ctx_statement {
>+ my ($linenr, $remain) = @_;
>+
>+ return ctx_block_get($linenr, $remain, 0, '\(', '\)');
^^
>+ my $ident = '[A-Za-z\d_]+';
Oh yes, use the qr operator here. (qr{}, qr//, choose anything like you
would do with m//)
>+ my $storage = '(?:extern|static)';
>+ my $sparse = '(?:__user|__kernel|__force|__iomem)';
>+ my $type= '(?:unsigned\s+)?' .
>+'(?:void|char|short|int|long|unsigned|float|double|' .
>+'long\s+long|' .
>+"struct\\s+${ident}|" .
>+"union\\s+${ident}|" .
>+"${ident}_t)" .
>+"(?:\\s+$sparse)*" .
>+'(?:\s*\*+)?';
>+ my $attribute = '(?:__read_mostly|__init|__initdata)';
>+
>+ my $Ident = $ident;
>+ my $Type= $type;
>+ my $Storage = $storage;
>+ my $Declare = "(?:$storage\\s+)?$type";
>+ my $Attribute = $attribute;
>+
> #trailing whitespace
>- if ($line=~/\+.*\S\s+$/) {
>+ if ($line=~/^\+.*\S\s+$/) {
if ($line =~ /^\+.*\S\s+$/) {
> my $herevet = "$here\n" . cat_vet($line) . "\n\n";
> print "trailing whitespace\n";
> print "$herevet";
>@@ -392,17 +420,20 @@ sub process {
> #
> next if ($in_comment);
>
>- # Remove comments from the line before processing.
>+# Remove comments from the line before processing.
> $line =~ s@/\*.*\*/@@g;
> $line =~ s@/\*.*@@;
C being a wonderful language, has this nice pitfall for parsers
foo = number /*pointer_to_int;
> $line =~ [EMAIL PROTECTED]/@@;
>
>- #
>- # Checks which may be anchored in the context.
>- #
>+# Standardise the strings and chars within the input to simplify matching.
>+ $line = sanitise_line($line);
>+
>+#
>+# Checks which may be anchored in the context.
>+#
>
>- # Check for switch () and associated case and default
>- # statements should be at the same indent.
>+# Check for switch () and associated case and default
>+# statements should be at the same indent.
> if ($line=~/\bswitch\s*\(.*\)/) {
Codingstyle warrants \bswitch\s+ :)
> # * goes on variable not on type
>- my $type = '(?:char|short|int|long|unsigned|float|double|' .
>- 'struct\s+[A-Za-z\d_]+|' .
>- 'union\s+[A-Za-z\d_]+)';
>-
qr. (I don't know what it is good for - compare qr/xyz/ with 'xyz'...,
but there's a reason to its existence, so let's use it :-)
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/
need help with kmap_atomic() behavior
Hello We are mapping struct page ptrs from scattergather list entries using kmap_atomic(page_ptr, KM_USER0) to get the virtual address for doing a copy to work around some alignment restrictions in our driver. If the first entry in the scatterlist has length > 4k (say 11k) and has an offset of 1k then, will kmap of the struct page ptr in this scattergather entry map all of the relevant pages (3 in this case for 11k) needed to cover this sg entry? Thanks in advance. -Hari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
b44: high ping times with wireless-dev
Hello, I recently did some test and found out something interesting about the b44 problem I wrote earlier. The problem is the following: When I use my BCM4401 with the b44 driver in wireless-dev I get very high ping times looking like this: 64 bytes from 172.30.10.1: icmp_seq=1 ttl=64 time=1863 ms 64 bytes from 172.30.10.1: icmp_seq=2 ttl=64 time=855 ms 64 bytes from 172.30.10.1: icmp_seq=3 ttl=64 time=1855 ms 64 bytes from 172.30.10.1: icmp_seq=4 ttl=64 time=855 ms 64 bytes from 172.30.10.1: icmp_seq=5 ttl=64 time=1854 ms 64 bytes from 172.30.10.1: icmp_seq=6 ttl=64 time=854 ms 64 bytes from 172.30.10.1: icmp_seq=7 ttl=64 time=1851 ms 64 bytes from 172.30.10.1: icmp_seq=8 ttl=64 time=851 ms 64 bytes from 172.30.10.1: icmp_seq=9 ttl=64 time=1851 ms 64 bytes from 172.30.10.1: icmp_seq=10 ttl=64 time=851 ms I also found out that shortly after I boot my laptop and log into kde ping times are not that high but start to increase very quickly: 64 bytes from 172.30.10.1: icmp_seq=53 ttl=64 time=2.19 ms 64 bytes from 172.30.10.1: icmp_seq=54 ttl=64 time=2.22 ms 64 bytes from 172.30.10.1: icmp_seq=55 ttl=64 time=2.20 ms 64 bytes from 172.30.10.1: icmp_seq=56 ttl=64 time=2.20 ms 64 bytes from 172.30.10.1: icmp_seq=57 ttl=64 time=18.6 ms 64 bytes from 172.30.10.1: icmp_seq=58 ttl=64 time=1268 ms 64 bytes from 172.30.10.1: icmp_seq=59 ttl=64 time=268 ms 64 bytes from 172.30.10.1: icmp_seq=60 ttl=64 time=1268 ms 64 bytes from 172.30.10.1: icmp_seq=61 ttl=64 time=268 ms 64 bytes from 172.30.10.1: icmp_seq=62 ttl=64 time=6.08 ms 64 bytes from 172.30.10.1: icmp_seq=63 ttl=64 time=268 ms 64 bytes from 172.30.10.1: icmp_seq=64 ttl=64 time=1264 ms 64 bytes from 172.30.10.1: icmp_seq=65 ttl=64 time=264 ms After some time digging around I found out something really interesting. When I play some music ping times are immediately lower. If I stop playing music they are back to the same times as they were before. I guess that there is a problem with interrupts so I post some information of my system in hope it will be usefull. [EMAIL PROTECTED]:~$ cat /proc/interrupts CPU0 0: 126317XT-PIC-XTtimer 1: 3600XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 7: 1XT-PIC-XTparport0 8: 1XT-PIC-XTrtc 9: 17371XT-PIC-XTacpi 10: 13237XT-PIC-XTfirewire_ohci, yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, eth0 11: 89059XT-PIC-XTuhci_hcd:usb2, [EMAIL PROTECTED]::00:02.0 12:632XT-PIC-XTi8042 14: 10354XT-PIC-XTlibata 15: 7408XT-PIC-XTlibata NMI: 0 ERR: 0 [...] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10 ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 ssb: Sonics Silicon Backplane found on PCI device :02:02.0 b44.c:v2.0 eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:c0:9f:29:99:a7 [...] This problem did only happen with wireless-dev (checkout this evening) and with -mm kernels I used some time ago for testing. Currently I'm running 2.6.22-rc4 that works perfectly fine and doesn't show that problem. Maxi signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On 16/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 16, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > How the hell does that improve the situation for users? Maybe it doesn't. How does it make it worse? Now not even the vendor can upgrade the software in the hardware and fix problems for the user. The user loses. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] alpha: fix alignment problem in csum_ipv6_magic()
Hopefully this fixes http://bugzilla.kernel.org/show_bug.cgi?id=8635 The struct in6_addr passed to csum_ipv6_magic() is 4 byte aligned, so we can't use the regular 64-bit loads. Since the cost of handling of 4 byte and 1 byte aligned 64-bit data is roughly the same, this code can cope with any src/dst [mis]alignment. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> Ivan. --- 2.6.22-rc4/arch/alpha/lib/ev6-csum_ipv6_magic.S Sun Feb 4 21:44:54 2007 +++ linux/arch/alpha/lib/ev6-csum_ipv6_magic.S Sun Jun 17 00:41:53 2007 @@ -46,6 +46,10 @@ * add the 3 low ushorts together, generating a uint * a final add of the 2 lower ushorts * truncating the result. + * + * Misalignment handling added by Ivan Kokshaysky <[EMAIL PROTECTED]> + * The cost is 16 instructions (~8 cycles), including two extra loads which + * may cause additional delay in rare cases (load-load replay traps). */ .globl csum_ipv6_magic @@ -55,25 +59,45 @@ csum_ipv6_magic: .prologue 0 - ldq $0,0($16) # L : Latency: 3 + ldq_u $0,0($16) # L : Latency: 3 inslh $18,7,$4# U : 00AABBCC - ldq $1,8($16) # L : Latency: 3 + ldq_u $1,8($16) # L : Latency: 3 sll $19,8,$7# U : U L U L : 0x 00aabb00 + and $16,7,$6# E : src misalignment + ldq_u $5,15($16) # L : Latency: 3 zapnot $20,15,$20 # U : zero extend incoming csum - ldq $2,0($17) # L : Latency: 3 - sll $19,24,$19 # U : U L L U : 0x00aa bb00 - inswl $18,3,$18 # U : 00CCDD00 + ldq_u $2,0($17) # L : U L U L : Latency: 3 + + extql $0,$6,$0# U : + extqh $1,$6,$22 # U : + ldq_u $3,8($17) # L : Latency: 3 + sll $19,24,$19 # U : U U L U : 0x00aa bb00 + + cmoveq $6,$31,$22 # E : src aligned? + ldq_u $23,15($17) # L : Latency: 3 + or $18,$4,$18 # E : 00CCDDAABBCC + extql $1,$6,$1# U : U L L U : - ldq $3,8($17) # L : Latency: 3 - bis $18,$4,$18 # E : 00CCDDAABBCC + or $0,$22,$0 # E : 1st src word complete + extqh $5,$6,$5# U : addl$19,$7,$19 # E : bbaabb00 - nop # E : U L U L + and $17,7,$6# E : L U L U : dst misalignment + inswl $18,3,$18 # U : 00CCDD00 + or $1,$5,$1# E : 2nd src word complete + extql $2,$6,$2# U : + extqh $3,$6,$22 # U : U L U U : + + cmoveq $6,$31,$22 # E : dst aligned? + extql $3,$6,$3# U : addq$20,$0,$20 # E : begin summing the words + extqh $23,$6,$23 # U : L U L U : + srl $18,16,$4 # U : 00CCDDAA + or $2,$22,$2 # E : 1st dst word complete zap $19,0x3,$19 # U : bbaa - nop # E : L U U L + or $3,$23,$3 # E : U L U L : 2nd dst word complete cmpult $20,$0,$0 # E : addq$20,$1,$20 # E : --- 2.6.22-rc4/arch/alpha/lib/csum_ipv6_magic.S Sun Feb 4 21:44:54 2007 +++ linux/arch/alpha/lib/csum_ipv6_magic.S Sun Jun 17 00:29:28 2007 @@ -7,6 +7,9 @@ *__u32 len, *unsigned short proto, *unsigned int csum); + * + * Misalignment handling (which costs 16 instructions / 8 cycles) + * added by Ivan Kokshaysky <[EMAIL PROTECTED]> */ .globl csum_ipv6_magic @@ -16,37 +19,57 @@ csum_ipv6_magic: .prologue 0 - ldq $0,0($16) # e0: load src & dst addr words + ldq_u $0,0($16) # e0: load src & dst addr words zapnot $20,15,$20 # .. e1 : zero extend incoming csum extqh $18,1,$4# e0: byte swap len & proto while we wait - ldq $1,8($16) # .. e1 : + ldq_u $21,7($16) # .. e1 : handle misalignment extbl $18,1,$5# e0: - ldq $2,0($17) # .. e1 : + ldq_u $1,8($16) # .. e1 : extbl $18,2,$6# e0: - ldq $3,8($17) # .. e1 : + ldq_u $22,15($16) # .. e1 : extbl $18,3,$18 # e0: + ldq_u $2,0($17) # .. e1 : sra $4,32,$4# e0: + ldq_u $23,7($17) # .. e1 : + + extql $0,$16,$0 # e0: + ldq_u $3,8($17) # .. e1 : + extqh $21,$16,$21 # e0: + ldq_u $24,15($17) # .. e1 : + sll $5,16,$5# e0: + or $0,$21,$0 # .. e1 : 1st src word complete + extql $1,$16,$1 # e0: addq$20,$0,$20 # .. e1 : begin summing the words - sll $6,8,$6
[PATCH] update checkpatch.pl to version 0.05
This version brings a some new tests, and a host of changes to fix
false positives, of particular note:
- detect 'var ++;' and 'var --;' as a bad combination
- multistatement #defines are now checked based on statement count
- multistatement #defines with initialisation correctly reported
- checks the location of the inline keywords
- EXPORT_SYMBOL for variables are now understood
- typedefs are loosened to handle sparse etc
This version of checkpatch.pl can be found at the following URL:
http://www.shadowen.org/~apw/public/checkpatch/checkpatch.pl-0.05
Full Changelog:
Andy Whitcroft (18):
Version: 0.05
macro definition checks should be for a single statement
avoid assignements only in if conditionals
declarations of function pointers need no space
multiline macros which are purely initialisation cannot be wrapped
EXPORT_SYMBOL can also directly follow a variable definition
check on the location of the inline keyword
EXPORT_SYMBOL needs to allow for attributes
ensure we do not find C99 // in strings
handle malformed #include lines
accept the {0,} form
typedefs are sensible for defining function pointer parameters
ensure { handling correctly handles nested switch() statements
trailing whitespace checks are not anchored
typedefs for sparse bitwise annotations make sense
update the type matcher to include sparse annotations
clean up indent and spacing
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index aea90d3..56c364c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -9,7 +9,7 @@ use strict;
my $P = $0;
$P =~ [EMAIL PROTECTED]/@@g;
-my $V = '0.04';
+my $V = '0.05';
use Getopt::Long qw(:config no_auto_abbrev);
@@ -17,11 +17,13 @@ my $quiet = 0;
my $tree = 1;
my $chk_signoff = 1;
my $chk_patch = 1;
+my $tst_type = 0;
GetOptions(
'q|quiet' => \$quiet,
'tree!' => \$tree,
'signoff!' => \$chk_signoff,
'patch!'=> \$chk_patch,
+ 'test-type!'=> \$tst_type,
) or exit;
my $exit = 0;
@@ -151,7 +153,7 @@ sub sanitise_line {
}
sub ctx_block_get {
- my ($linenr, $remain, $outer) = @_;
+ my ($linenr, $remain, $outer, $open, $close) = @_;
my $line;
my $start = $linenr - 1;
my $blk = '';
@@ -165,8 +167,8 @@ sub ctx_block_get {
$blk .= $rawlines[$line];
- @o = ($blk =~ /\{/g);
- @c = ($blk =~ /\}/g);
+ @o = ($blk =~ /$open/g);
+ @c = ($blk =~ /$close/g);
if (!$outer || (scalar(@o) - scalar(@c)) == 1) {
push(@res, $rawlines[$line]);
@@ -180,12 +182,17 @@ sub ctx_block_get {
sub ctx_block_outer {
my ($linenr, $remain) = @_;
- return ctx_block_get($linenr, $remain, 1);
+ return ctx_block_get($linenr, $remain, 1, '\{', '\}');
}
sub ctx_block {
my ($linenr, $remain) = @_;
- return ctx_block_get($linenr, $remain, 0);
+ return ctx_block_get($linenr, $remain, 0, '\{', '\}');
+}
+sub ctx_statement {
+ my ($linenr, $remain) = @_;
+
+ return ctx_block_get($linenr, $remain, 0, '\(', '\)');
}
sub ctx_locate_comment {
@@ -264,9 +271,30 @@ sub process {
my $in_comment = 0;
my $first_line = 0;
+ my $ident = '[A-Za-z\d_]+';
+ my $storage = '(?:extern|static)';
+ my $sparse = '(?:__user|__kernel|__force|__iomem)';
+ my $type= '(?:unsigned\s+)?' .
+ '(?:void|char|short|int|long|unsigned|float|double|' .
+ 'long\s+long|' .
+ "struct\\s+${ident}|" .
+ "union\\s+${ident}|" .
+ "${ident}_t)" .
+ "(?:\\s+$sparse)*" .
+ '(?:\s*\*+)?';
+ my $attribute = '(?:__read_mostly|__init|__initdata)';
+
+ my $Ident = $ident;
+ my $Type= $type;
+ my $Storage = $storage;
+ my $Declare = "(?:$storage\\s+)?$type";
+ my $Attribute = $attribute;
+
foreach my $line (@lines) {
$linenr++;
+ my $rawline = $line;
+
#extract the filename as it passes
if ($line=~/^\+\+\+\s+(\S+)/) {
$realfile=$1;
@@ -361,7 +389,7 @@ sub process {
next if ($realfile !~ /\.(h|c|s|S|pl|sh)$/);
#trailing whitespace
- if ($line=~/\+.*\S\s+$/) {
+ if ($line=~/^\+.*\S\s+$/) {
my $herevet = "$here\n" . cat_vet($line) . "\n\n";
print "trailing whitespace\n";
print "$herevet";
@@ -392,17 +420,20 @@ sub process {
#
next if ($in_comment);
- # Remove comments from the
[PATCH] hwmon/coretemp: Fix a broken error path
Hi Soeren,
On Sat, 16 Jun 2007 22:43:05 +0200, Soeren Sonnenburg wrote:
> this commit makes coretemp fail on my macbook pro.
>
> 1) rmmod oopses (see below)
> 2) it breaks s2ram
>
> Soeren
>
> commit 67f363b1f6a31cf5027a97372f64bcced4f05ba6
> Author: Rudolf Marek <[EMAIL PROTECTED]>
> Date: Sun May 27 22:17:43 2007 +0200
>
> hwmon/coretemp: Add more safety checks
>
> Add detection of AE18 Errata of Core processor and warns
> users that the absolute readings might be wrong for Core2 processor.
>
> Signed-off-by: Rudolf Marek <[EMAIL PROTECTED]>Subject: hwmon/coretemp:
> Fix a broken error path
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Thanks for reporting. Indeed this patch is broken, sorry for
overlooking it. I tested it but my hardware is such that the faulty
error path was never taken. Please test the following patch (on top of
git-current) and confirm it fixes your problem:
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Cc: Rudolf Marek <[EMAIL PROTECTED]>
---
drivers/hwmon/coretemp.c |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.22-rc4.orig/drivers/hwmon/coretemp.c 2007-06-05
10:25:54.0 +0200
+++ linux-2.6.22-rc4/drivers/hwmon/coretemp.c 2007-06-16 23:14:06.0
+0200
@@ -185,6 +185,7 @@ static int __devinit coretemp_probe(stru
/* check for microcode update */
rdmsr_on_cpu(data->id, MSR_IA32_UCODE_REV, , );
if (edx < 0x39) {
+ err = -ENODEV;
dev_err(>dev,
"Errata AE18 not fixed, update BIOS or "
"microcode of the CPU!\n");
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
DEC had versioning files systems 30 years ago. Any patents on their style must certainly have expired long ago. Look at RSX-11 and other seventies era operating systems. This is ancient stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Machine Check Exception: 0...04
Hello All , Does anoyone know howto identify a cause for these(*) ? Or of any tools to help in the identification of the cause ? So far the Machine checks only happen when I am running bonnie++ against my software raid6 array . I have done everything I know to do to attempt to ascertain what is causing the machine checks . ie: 1) memtest86+ for days , no errors . 2) cpuburnP6 , The tests run were 'cpuburnP6 E' & 'cpuburnP6 H' for ~ 60 minutes each . All CPU's & HT were at 96+<->100% for 60+ Minutes , no excessive heating or lockups . In single user mode of course . I know cpuburn is old but it can excersize the comms between l1 & cpu & l1 & l2 -> cpu if done right . (*) CPU 5: Machine Check Exception: 0004 CPU 4: Machine Check Exception: 0004 Kernel panic - not syncing: Unable to continue root@(none):~ # uname -a Linux (none) 2.6.21.5 #1 SMP Fri Jun 15 04:37:23 UTC 2007 i686 pentium4 i386 GNU/Linux Complete serial console log of a boot to single user mode is here . http://www.baby-dragons.com/test-2.6.21.5-mptscsi-4.00.10.00-2007006161326.log Tia , JimL -- +-+ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 663 Beaumont Blvd | Give me Linux | | [EMAIL PROTECTED] | Pacifica, CA. 94044 | only on AXP | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Jan Harkes wrote: > Sites like portal.acm.org and citeseer.ist.psu.edu are good places to > find copies of these papers. They also provide links to other work that > either is cited by, or cites these papers which is a convenient way to > find other papers in this area. > > Researching, designing and implementing such systems is a lot of fun, > admittedly often more fun than long term debugging and/or maintaining, > but that is life. Don't get too upset if the end result cannot be > included in the main kernel. Just start over from scratch, you may just > end up with an even better design the second time around. Thank you very much for the info and the advice. I would also like to thank everyone for the help and enchouragement that they have given to me. Jack - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
git-current: latest coretemp changes break s2ram
this commit makes coretemp fail on my macbook pro. 1) rmmod oopses (see below) 2) it breaks s2ram Soeren commit 67f363b1f6a31cf5027a97372f64bcced4f05ba6 Author: Rudolf Marek <[EMAIL PROTECTED]> Date: Sun May 27 22:17:43 2007 +0200 hwmon/coretemp: Add more safety checks Add detection of AE18 Errata of Core processor and warns users that the absolute readings might be wrong for Core2 processor. Signed-off-by: Rudolf Marek <[EMAIL PROTECTED]> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> [...] PM: Adding info for platform:coretemp.0 coretemp coretemp.0: Errata AE18 not fixed, update BIOS or microcode of the CPU! PM: Adding info for platform:coretemp.1 coretemp coretemp.1: Errata AE18 not fixed, update BIOS or microcode of the CPU! [...] BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: f887c09f *pde = Oops: [#1] PREEMPT SMP Modules linked in: ohci1394 ieee1394 hfsplus binfmt_misc fuse eeprom coretemp applesmc hwmon snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm firewire_ohci firewire_core snd_timer i2c_i801 appletouch sky2 crc_itu_t snd soundcore snd_page_alloc intel_agp agpgart evdev CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.22-rc4-sonne #20) EIP is at coretemp_remove+0x1f/0x60 [coretemp] eax: f78c2800 ebx: f78c2890 ecx: edx: f887d23c esi: f78c2808 edi: ebp: c0496760 esp: f7c07ef4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process rmmod (pid: 2646, ti=f7c06000 task=dfc07440 task.ti=f7c06000) Stack: f78c2808 f887d23c f78c2890 c02b714c c02b580b f78c2808 f78c2808 c02b5c5e f78c2808 c02b50c0 c02b3508 f78c2800 f78c2800 f7a298f0 f7c06000 c02b73f0 f78c2800 f7a298b0 c02b7828 f7a298f0 f887c69a f887d380 Call Trace: [] platform_drv_remove+0xc/0x10 [] __device_release_driver+0x6b/0xa0 [] device_release_driver+0x1e/0x40 [] bus_remove_device+0x50/0x80 [] device_del+0x138/0x230 [] platform_device_del+0x10/0x70 [] platform_device_unregister+0x8/0x10 [] coretemp_exit+0x3a/0x7d [coretemp] [] sys_delete_module+0x148/0x1b0 [] do_page_fault+0x333/0x620 [] do_munmap+0x197/0x1f0 [] sysenter_past_esp+0x5f/0x85 === Code: 87 f8 5e 5f 5d e9 72 6a b4 c7 66 90 83 ec 0c 89 1c 24 89 c3 89 74 24 04 8d 70 08 81 c3 90 00 00 00 89 7c 24 08 8b be 20 01 00 00 <8b> 07 e8 5a 7f fc ff 89 d8 ba e0 c6 87 f8 e8 3e 20 94 c7 31 c0 EIP: [] coretemp_remove+0x1f/0x60 [coretemp] SS:ESP 0068:f7c07ef4 -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
On Sat, Jun 16, 2007 at 02:03:49PM -0600, Jeffrey V. Merkey wrote: > Jan Harkes wrote: > >implementation, just a high level description. Finally advising anyone > >(who is not an actual patent lawyer that could correctly interpret the > >language and scope of a patent) to go search out patents seems pretty > >bad advice. That can only result in not even attempting to research some > >potentially new and innovative approach. > > > >Researching prior published work in the area is considerably more > >helpful. Especially when something is complex beyond belief it has > >probably attracted various researchers over time and there are most > >likely various different solutions that have been explored previously. > >Such existing work can form a good basis for further work. > > When you get into the recycling issues with storage, the patents come > into play. Also, using the file name to reference revisions is already > the subject of a patent previously filed (I no longer own the patent, I > sold them to Canopy). There is a third one about to be issued. Congratulations on obtaining those patents, I hope they will be used wisely. I am however not a patent lawyer and as such in no position to evaluate their claims. As a more useful response, the original poster may want to look at some of the prior work in this area, I just picked a couple, (Cedar File System from Xerox PARC) A Caching File System for a Programmer's Workstation (1985) Michael D. Schroeder, David K. Gifford, Roger M. Needham (Vax/VMS System Software Handbook) (TOPS-20 User's Manual) (Plan 9 (file system)) Plan 9 from Bell Labs (1990) Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, Phil Winterbottom (Elephant File System) Elephant: The File System that Never Forgets (1999) Douglas J. Santry, Michael J. Feeley, Norman C. Hutchinson Workshop on Hot Topics in Operating Systems Deciding when to forget in the Elephant file system (1999) Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, Jacob Otir (Ext3Cow) Ext3cow: The Design, Implementation, and Analysis of Metadata for a Time-Shifting File System (2003) Zachary N. J. Peterson, Randal C. Burns Sites like portal.acm.org and citeseer.ist.psu.edu are good places to find copies of these papers. They also provide links to other work that either is cited by, or cites these papers which is a convenient way to find other papers in this area. Researching, designing and implementing such systems is a lot of fun, admittedly often more fun than long term debugging and/or maintaining, but that is life. Don't get too upset if the end result cannot be included in the main kernel. Just start over from scratch, you may just end up with an even better design the second time around. 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/
2.6.22-rc4 not compiling on the SH4/Dreamcast
This is a patched 2.6.21.5 - which might be an issue. But this is what I get: LD .tmp_vmlinux1 arch/sh/kernel/built-in.o: In function `restore_all': arch/sh/kernel/cpu/sh4/../sh3/entry.S:(.text+0x50cc): undefined reference to `in_nmi' make: *** [.tmp_vmlinux1] Error 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: accurate user accounting
On Sat, 16 Jun 2007, Ingo Molnar wrote: * malc <[EMAIL PROTECTED]> wrote: Interesting, the idle time accounting (done from account_system_time()) has not changed. Has your .config changed? Could you please send it across. I've downloaded apc and I am trying to reproduce your problem. http://www.boblycat.org/~malc/apc/cfs/ has config for 2.6.21 an the diff against 2.6.21.4-cfs-v16. hm. Could you add this to your kernel boot command line: highres=off nohz=off and retest, to inquire whether this problem is independent of any timer-events effects? It certainly makes a difference. Without dynticks however scheduler still moves the task (be it hog or mplayer) between CPUs for no good reason, for hog the switching is every few seconds (instead of more or less all the time in case of dynticks). What's rather strange is that while it hogs 7x% of CPU on core#1 it only hogs 3x% on core#2 (percentage is obtained by timing idle handler not form /proc/stat, according to /proc/stat either core is 0% loaded).. Live report... After a while it stabilized and was running on core#2 all the time, when the process was stopped and restarted it started to run constantly on core#1 (with ~70% load) Btw. i don't want to waste anyones time here. All i originally wanted is to know if something was done (as per LWN article) with increasing the accuracy of system wide statistics (in /proc/stat), turns out that nothing really happened in this area, but latest developments (CFS/dynticks) have some peculiar effect on hog. Plus this constant migration of hog/mplayer is somewhat strange. Live report... again.. Okay now that hog stabilized on running exclusively on core#1 and at 70% load i switched to the machine where it runs and after just switching the windows in IceWM resulted in system load dropping to 30%.. Quite reproducible too. -- vale - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Cox wrote: http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG=PCT_TYPE=19=1211506-KEY_FIELD=256=0=1205953=10_SET=IA,WO,TTL-EN=1=3=1=25=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG_IA=US2005045566=%28IN%2fmerkey%29+ The last one was filed with WIPO and has international protection, UK included. Nope. EU and UK law does not recognize software as patentable. See the caselaw. Thanks for clarifying Alan, I was uncertain about current patent laws in the UK and abroad. I know this area has undergone considerable debate and changes recently, and I have not been keeping up with all of it. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > I don't see how TiVO has done this. They have placed no restrictions on > > *modification* at all. What they have done is placed a restriction on > > *REPLACEMENT* of the program. > Technicality. In order for the software to remain free (which is what > the GPL is all about), the user must not be stopped from adapting the > software to suit his needs and running it for any purpose. TiVo > places restrictions on it. It's really this simple. No, this is completely and utterly wrong. By this logic, Linux isn't free if I can't run it on *YOUR* laptop. TiVo places restrictions on *hardware*. The hardware is not free. > And then, TiVo doesn't really prohibit replacement. You can replace > it as much as you like; just not as conveniently as TiVo can replace > it. And then, if you do, it won't run, because it's not signed with a > key that they omit from the source code. And they do this in order to > prevent the user from changing the behavior of the Free Software that > they use, while they keep this ability to themselves. > If these are not restrictions on the freedoms that the GPL is designed > to protect to ensure that Free Software remains Free for all its > users, I don't know what is. So why is it not a restriction on this freedom that I can't modify the copy of Linux running on *your* desktop? If it helps you to understand the situation better, think of TiVo as not really selling you the hardware. To see why this isn't a GPL issue, imagine if TiVo explicitly didn't sell the hardware. Imagine if they only rented it or sold it but retained the right to control what software ran on it. Essentially, your TiVo would be like my laptop -- you don't get to decide what software runs on it. But if you get GPL'd software, you get source code. Regardless of how the GPL came to be in the first place, the vast majority of people who chose to use the GPL (including Linus himself) choose it so that the code can't be modified and distributed and those modifications kept secret. The idea is that any change widely distributed in binary form is nearly assured to propogate back in source code form, and is assured to get to those who paid for the binary. Linus, and many other people, don't give a damn (from a GPL perspective) about what TiVo does with their hardware. They may agree with it, disagree with it, think it's legal, maybe even illegal, but they don't think it has *anything* to do with the intent or spirit of the GPLv2 as *they* understand it and for the reasons *they* chose it. They just want to get source code, and they really don't care what other people do with it -- they care about what *they* can do with it. They just want the source code, and TiVo gives it to them. GPL was about source code not being secret, to them and to many others. > No, they're using the hardware (along with other pieces of software) > to deny users (but not themselves) the freedoms that the license of > software *meant* to defend, for that software, even if some believe it > doesn't actually defend them. At least to Linus, the GPL was never meant to defend the freedom to run Linux on any hardware you want. It was just meant to ensure that you couldn't keep the source code secret. I personally feel precisely the same way and I think many other people do too. I think that what TiVo is doing is wrong for completely different reasons that have nothing to do with the fact that it happens to run Linux or that Linux happens to be free software. But I think I've already made that clear in other posts. 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
> http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG=PCT_TYPE=19=1211506-KEY_FIELD=256=0=1205953=10_SET=IA,WO,TTL-EN=1=3=1=25=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG_IA=US2005045566=%28IN%2fmerkey%29+ > > The last one was filed with WIPO and has international protection, UK > included. Nope. EU and UK law does not recognize software as patentable. See the caselaw. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/6] make pci_ids lowercase hexa
On Sat, Jun 16, 2007 at 05:44:52PM +0200, Jiri Slaby wrote: > make pci_ids lowercase hexa Why? What good is this going to do in the long run? Also, shouldn't you send pci specific patches like this to the pci maintainer? :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc4 XFS fails after hibernate/resume
This isn't a regression. I was seeing these problems on 2.6.21 (but 22 was in -rc so I waited to try it). I tried 2.6.22-rc4 (with Tejun's patches) to see if it had improved - no. Note this is a different (desktop) machine to that involved my recent bugs. The machine will work for days (continually powered up) without a problem and then exhibits a filesystem failure within minutes of a resume. I know xfs/raid are OK with hibernate. Is lvm? The root filesystem is xfs on raid1 and that doesn't seem to have any problems. System info: /dev/mapper/video_vg-video_lv on /scratch type xfs (rw) haze:~# vgdisplay --- Volume group --- VG Name video_vg System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 19 VG Access read/write VG Status resizable MAX LV0 Cur LV1 Open LV 1 Max PV0 Cur PV1 Act PV1 VG Size 372.61 GB PE Size 4.00 MB Total PE 95389 Alloc PE / Size 95389 / 372.61 GB Free PE / Size 0 / 0 VG UUID I2gW2x-aHcC-kqzs-Efpd-Q7TE-dkWf-KpHSO7 haze:~# pvdisplay --- Physical volume --- PV Name /dev/md1 VG Name video_vg PV Size 372.62 GB / not usable 3.25 MB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 95389 Free PE 0 Allocated PE 95389 PV UUID IUig5k-460l-sMZc-23Iz-MMFl-Cfh9-XuBMiq md1 : active raid5 sdd1[0] sda1[2] sdc1[1] 390716672 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0a.0 Mass storage controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02) 00:0b.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 12) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) tail end of info from dmesg: k_prepare_write+0x272/0x490 [] xfs_iomap+0x391/0x4b0 [] xfs_bmap+0x0/0x10 [] xfs_map_blocks+0x47/0x90 [] xfs_page_state_convert+0x3dc/0x7b0 [] xfs_ilock+0x71/0xa0 [] xfs_iunlock+0x85/0x90 [] xfs_vm_writepage+0x60/0xf0 [] __writepage+0x8/0x30 [] write_cache_pages+0x1ff/0x320 [] __writepage+0x0/0x30 [] generic_writepages+0x20/0x30 [] do_writepages+0x2b/0x50 [] __filemap_fdatawrite_range+0x72/0x90 [] xfs_file_fsync+0x0/0x80 [] filemap_fdatawrite+0x23/0x30 [] do_fsync+0x4e/0xb0 [] __do_fsync+0x25/0x40 [] syscall_call+0x7/0xb === Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file fs/xfs/xfs_btree.c. Caller 0xc01b27be [] xfs_btree_check_sblock+0x5b/0xd0 [] xfs_alloc_lookup+0x17e/0x390 [] xfs_alloc_lookup+0x17e/0x390 [] xfs_alloc_ag_vextent_near+0x59/0xa30 [] xfs_alloc_ag_vextent+0x8d/0x100 [] xfs_alloc_vextent+0x223/0x450 [] xfs_bmap_btalloc+0x400/0x770 [] xfs_iext_bno_to_ext+0x9d/0x1d0 [] xfs_bmapi+0x10bd/0x1490 [] xlog_grant_log_space+0x22e/0x2b0 [] xfs_log_reserve+0xc0/0xe0 [] xfs_iomap_write_allocate+0x27f/0x4f0 [] __block_prepare_write+0x421/0x490 [] __block_prepare_write+0x272/0x490 [] xfs_iomap+0x391/0x4b0 [] xfs_bmap+0x0/0x10 [] xfs_map_blocks+0x47/0x90 [] xfs_page_state_convert+0x3dc/0x7b0 [] xfs_ilock+0x71/0xa0 [] xfs_iunlock+0x85/0x90 [] xfs_vm_writepage+0x60/0xf0 [] __writepage+0x8/0x30 [] write_cache_pages+0x1ff/0x320 [] __writepage+0x0/0x30 [] generic_writepages+0x20/0x30 [] do_writepages+0x2b/0x50 [] __filemap_fdatawrite_range+0x72/0x90 [] xfs_file_fsync+0x0/0x80 [] filemap_fdatawrite+0x23/0x30 [] do_fsync+0x4e/0xb0 [] __do_fsync+0x25/0x40 [] syscall_call+0x7/0xb === Filesystem "dm-0": XFS internal error
Re: [PATCH] block: always requeue !fs requests at the front
On Fri, Jun 15, 2007 at 01:05:44PM +0200, Jens Axboe wrote: > On Fri, Jun 15 2007, Tejun Heo wrote: > > SCSI marks internal commands with REQ_PREEMPT and push it at the front > > of the request queue using blk_execute_rq(). When entering suspended > > or frozen state, SCSI devices are quiesced using > > scsi_device_quiesce(). In quiesced state, only REQ_PREEMPT requests > > are processed. This is how SCSI blocks other requests out while > > suspending and resuming. As all internal commands are pushed at the > > front of the queue, this usually works. > > > > Unfortunately, this interacts badly with ordered requeueing. To > > preserve request order on requeueing (due to busy device, active EH or > > other failures), requests are sorted according to ordered sequence on > > requeue if IO barrier is in progress. > > > > The following sequence deadlocks. > > > > 1. IO barrier sequence issues. > > > > 2. Suspend requested. Queue is quiesced with part of all of IO > >barrier sequence at the front. > > > > 3. During suspending or resuming, SCSI issues internal command which > >gets deferred and requeued for some reason. As the command is > >issued after the IO barrier in #1, ordered requeueing code puts the > >request after IO barrier sequence. > > > > 4. The device is ready to process requests again but still is in > >quiesced state and the first request of the queue isn't > >REQ_PREEMPT, so command processing is deadlocked - > >suspending/resuming waits for the issued request to complete while > >the request can't be processed till device is put back into > >running state by resuming. > > > > This can be fixed by always putting !fs requests at the front when > > requeueing. > > > > The following thread reports this deadlock. > > > > http://thread.gmane.org/gmane.linux.kernel/537473 > > > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > > Cc: Jenn Axboe <[EMAIL PROTECTED]> > > Cc: David Greaves <[EMAIL PROTECTED]> > > --- > > Okay, it took a lot of hours of debugging but boiled down to two liner > > fix. I feel so empty. :-) RAID6 triggers this reliably because it > > uses BIO_BARRIER heavily to update its superblock. The recent ATA > > suspend/resume rewrite is hit by this because it uses SCSI internal > > commands to spin down and up the drives for suspending and resuming. > > > > David, please test this. Jens, does it look okay? > > Yep looks good, except for the bad multi-line comment style, but that's > minor stuff ;-) > > Acked-by: Jens Axboe <[EMAIL PROTECTED]> I'd much much prefer having a description of the problem in the actual comment then a hyperlink. There's just too much chance of the latter breaking over time, and it's impossible to update it when things change that should be reflected in the comment. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: beeping patch for debugging acpi sleep
On Sat, Jun 09, 2007 at 03:08:17PM +0200, Pavel Machek wrote: > Starting beeper as soon as ACPI sleep returns is very useful in > debugging "apparently dead" machines. If it beeps at all, it makes > sense to start playing with CMOS tracer. thank you very much Pavel The results are a bit unclear, I took a 2.6.22-rc4 with beep. Logged into KDE. (hardware: Dell Latitude D810) S = successfull resume D = had to resume 2 times, that means when pressing the power button the LED goes from blinking to on and after a few seconds it goes back to blinking, but without a beep in between; after pressing the power button a second time resume is successfull F = resume failes, NO beep -run 1: D D F -run 2: D D D(some X garbadge) F -run 3: S S S S S S F -run 4: S S F -run 5: D F Very odd, nothing was changed in between and after each F i switched it off... because it was dead. With 2.6.19.7 i have never seen it fail. Christian Leber -- http://rettetdieti.vde-uni-mannheim.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] madvise_need_mmap_write() usage
On Fri, Jun 15, 2007 at 11:20:31AM -0400, Jason Baron wrote: > hi, > > i was just looking at the new madvise_need_mmap_write() call...can we > avoid an extra case statement and function call as follows? Sounds like a good idea, but please move the assignment out of the conditional. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Sanjoy Mahajan <[EMAIL PROTECTED]> writes: > So you have to give recipients the license text from a particular > version of the GPL. To make that the only version unde which the work > is licensed, you have to add something like "Licensed under the > GPLv2". Otherwise sec. 9 says that you offer the work under any > version of the GPL, and the licensee can take his or her pick -- even > using v1 (!). That's exactly what I meant by "not specifying the version". -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Jeffrey V. Merkey wrote: > When you get into the recycling issues with storage, the patents come > into play. Also, using the file name to reference revisions is already > the subject of a patent previously filed (I no longer own the patent, I > sold them to Canopy). There is a third one about to be issued. > > The patents are: > * > 6,862,609 > **6,795,895 > > and this one about to be issued: > > http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG=PCT_TYPE=19=1211506-KEY_FIELD=256=0=1205953=10_SET=IA,WO,TTL-EN=1=3=1=25=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG_IA=US2005045566=%28IN%2fmerkey%29+ > > > The last one was filed with WIPO and has international protection, UK > included. I have no idea about patents so if anyone could point me in the right direction I would be most obliged Jack - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > They are not keeping a priviledge over the *SOFTWARE* at all. They > are keeping a priviledge over the *HARDWARE*. No, they're using the hardware (along with other pieces of software) to deny users (but not themselves) the freedoms that the license of software *meant* to defend, for that software, even if some believe it doesn't actually defend them. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > I don't see how TiVO has done this. They have placed no restrictions on > *modification* at all. What they have done is placed a restriction on > *REPLACEMENT* of the program. Technicality. In order for the software to remain free (which is what the GPL is all about), the user must not be stopped from adapting the software to suit his needs and running it for any purpose. TiVo places restrictions on it. It's really this simple. And then, TiVo doesn't really prohibit replacement. You can replace it as much as you like; just not as conveniently as TiVo can replace it. And then, if you do, it won't run, because it's not signed with a key that they omit from the source code. And they do this in order to prevent the user from changing the behavior of the Free Software that they use, while they keep this ability to themselves. If these are not restrictions on the freedoms that the GPL is designed to protect to ensure that Free Software remains Free for all its users, I don't know what is. -- 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: My kernel hangs again: Help with git please
On Sat, 16 Jun 2007, Carlo Wood wrote:
> On Sat, Jun 16, 2007 at 01:28:13AM -0400, Daniel Barkalow wrote:
> > That's not actually the right image. There's a graph of commits with a lot
> > of splitting and joining lines. Each branch and each tag sits something in
> > this web. The difference between branches and tags is that you're expected
> > to move branch pointers around, and tags stay mostly in place. There's no
> > accounting of commits newer than the current spot in the web for a branch
> > belonging to that branch, so if you move a branch back to an older tag (or
> > other commit), the spot it's leaving is no longer "on the branch".
>
> Okay, it took me two hours before I understood this... but here's the
> picture that I have in mind now:
>
>master->X(merge point)
> /|
> / |
> ^ branch->3 X
> Time | | |
> | 2 X
> | |
> 1 X
> | |
> \ |
> \|
>X(branch point)
>|
Right, except that, in your repository, "master" has ended up pointing to
"3" also. Or, in any case, all of your local branches ("master" is no
different from other branches, except that it's the initial default name
for a branch) are somewhere down the web from the latest stuff from
Linus's repositry.
> Then if I define a branch pointer to point to '3', then the branch is
> 3--2--1. If next I move the branch pointer to point to '2', node '3' is
> no longer on the branch because now the branch exists of 2--1, and
> HEAD moves to '2' as well.
Right, except that "HEAD" is really just a symlink, not a pointer
directly to the history; the branch it points to is what you've got in
your working directory currently. So in that case, HEAD moves to '2'
simply because it's indirection for branch, which has moved to 2.
Side note: in more recent versions of git, there's the feature that you
seem to be trying to use. It's called "detatched HEAD", and means that you
can have HEAD be some arbitrary commit, not a link to a branch. You'd do
this with "git checkout ", and then your working directory
would match that revision, and "git branch" would have no *, and you
wouldn't have a current branch at all, and you wouldn't be moving branch
pointers around. But I don't think you're using a version of git that
supports this, and you need to get your branch pointers back to the
present anyway.
> This seems to make most sense in the light of your last sentence.
> I don't understand how I'd have moved branch pointers however. I thought
> I would just change my working copy along the branch by specifying
> tag nodes. Ie, I have a branch '3'(--2--1) and I say: give me '2',
> then give me '1' - and when I do: git reset --hard HEAD - it moves
> me to 3 because the branch was never touched.
git reset --hard moves the current branch to that revision, as
well as moving the working directory (and the index, which doesn't matter
for your case). If you were thinking that it only changed the working
directory, you probably moved some branches without realizing it.
> > So master is a point in the web, and bisect jumps around through the web
> > according to some special rules (due to having git-bisect use the good/bad
> > marks do determine which commit to try next, and jump there). git-bisect
> > doesn't really even care that you started on any single branch. It's just
> > operating on the web, and the branch you start on is treated as an
> > arbitrary commit that has the problem.
>
> Ok - so it does something magical that I don't have to understand :P
> The only thing that matters is that I choose the begin and end point,
> the first two points, correctly: where one is bad and the other is good.
> I seems that git bisect can't deal with swapping good/bad (the 'bad'
> one always has to be the newest revision), so I had decided to call
> 'kernel hangs' good and 'kernel works' bad. The problem then is that
> I can't find any starting point anymore that is 'bad'.
Right; since the normal goal is to find regressions, not fixes, "bad" is
the "after it changed" case, and "good" is the "before it changed". It is
trying to find a commit which all of the "bad" commits are descended from,
and which is descended from only "good" commits.
> > You may find "gitk --all" informative.
>
> The dates on the right side seem to make no sense. Even in a part
> where there are no branches/merges at all, the date goes in both
> direction (sometimes older, sometimes newer). Roughly it seems that
> the newest date is at the top - but I see a lot of times things like:
>
> |||O|| Description Author1 2007-05-14 03:43:20
> |||O|| Description Author2 2007-05-15 15:10:34
> |||O|| Description Author3 2007-05-13 17:50:27
>
> Thus, there seems to be no time related ordering :/
Those dates are when the patches which became the
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, 2007-06-16 at 14:43 -0400, Daniel Hazelton wrote:
> >
> > You mean renting the computer with the software in it is not
> > distribution of the software?
>
> It is. But you don't have the same rights to a rented machine as you do to
> one
> you have purchased. In fact, in renting a machine you have to agree to
> a "renters contract" - and that can state *whatever* the person that is
> renting the machine to you feels like having it state.
I ended up owning a piece of &*@( I rented from rent-a-center on a trip
because I wiped Windows and installed Debian.
> And yes, they can even
> have terms in it that violate the GPL. Not that a "renters contract" ("rental
> agreement" or whatever they call them in your jurisdiction) that has those
> terms can *legally* violate the GPL - but it doesn't stop them from existing.
I think you could be right. You (in 99% of all cases) agree to not
modify the machine anyway upon accepting it. Since you sign your rights
away at the minimum it would cost big time to enforce the license,
especially against a giant franchise.
That doesn't stop you from just letting people do what they want. If it
were me, I'd let people and that has nothing to do with the spirit of
the GPL, Windows is annoying and I wouldn't force someone to use it.
Probably, I'd just let them pick what they wanted and install it for
them.
I don't think they rent law degrees to go with computers however, you
have to get the blender or juicer to get that special.
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: [patch-mm 00/25] High resolution timer updates and x86_64 support - V2
On Sat, 2007-06-16 at 15:41 +0100, Alistair John Strachan wrote: > On Saturday 16 June 2007 11:36:00 Thomas Gleixner wrote: > > The -hrt tree at http://www.tglx.de/projects/hrtimers/2.6.22-rc4/ contains > > also an hpet force patch series from Venki Pallipadi, but I leave this up > > to Venki to send it mainline wards. > > What's the status on the nForce "hpet force fix" (Subject: "Enable hidden > HPET > on NVidia motherboards") that also exists? I think if one board can have its > HPET forced, so can another. > > Last I heard we were waiting on NVIDIA to confirm whether Mikko's logic was > supported by specifications? Any update on this? The full hpet force enable series is maintained by Venki and updates should go to him. I can add the patch to my -hrt queue for testing. 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: Separate arch patching (Re: [patch-mm 06/25] clockevents: Fix resume logic)
Oleg, On Sat, 2007-06-16 at 20:51 +0200, Oleg Verych wrote: > > arch/arm/plat-omap/timer32k.c |2 + > > Testers and users are most likely to run one particular arch on > one particular test bench. If individual patches are arch > separated, i think bisecting will be a little bit easier. No it is not. See below. > Thus, i would like to propose separate arch patching (x86_64/i386 mainly). This change adds an enum entry in a generic header file. _ALL_ users of clock events have a switch(this_changed_enum) in the set_mode() function. _ALL_ of them will spit warnings and some of them will even break, when the fix up is not done in one go. > Is it possible to do that? (And even set such check in ``checkpatch''?) It's possible, but results in an commit which will affect bisecting. I'm not going to send a patch which knowingly breaks bisecting either at compile or at run time. > You would say, why? Because current kbuild/kconfig support of builds > for whole tree. > > That's because to make download, build, test and debug particular arch > more easily, i'm trying to re-think and re-do some kbuild parts. With > minimum set of files, downloaded with git one can spend less > time/bandwidth for starting testing. Oh, well. That's going to be an interesting feature for git and the result will be published kernel trees with a total delta of 40MB against mainline, because someone tweaked the stuff in a way that it contains only the relevant files for a particular sub architecture. Embedded folks do this already and it makes it extremely hard to do efficient trouble shooting on such crippled trees. No thanks. If we would still have 9600 Baud modem connections I would understand that, but git is really effective since packing was added, so this argument is more or less an academic exercise. 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
On Jun 16, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > How the hell does that improve the situation for users? Maybe it doesn't. How does it make it worse? Maybe just providing an incentive for the vendor to respect users' freedoms will do the trick, and *some* vendors will do, while those who can't will keep the status quo. And then we're likely to be better off. > I realize that you have accepted the FSF credo, but if you want that > conversation to go anywhere you have to separate the things you > believe in from the things you can rationally explain. I've already explained what the spirit of the GPL is. I've already explained that the anti-Tivoization provision is in line with it. I've already asked in what sense Tivoization makes for a better tit-for-tat, and got no reply whatsoever, rational or otherwise. I have already hinted at why it makes things worse. You don't have to believe what I believe to analyze the arguments rationally, just like I don't have to believe what you believe to analyze your arguments rationally. We may still get to different conclusions as to what is better, if we have different values guiding us. But whatever conclusion you arrive at won't change the plain fact that Tivoization is against the spirit of the GPL, because it is a means to restrict users' freedoms that the GPL is designed to defend. It's really this simple. I'm not trying to convince you of anything other than that the spirit of the GPL is not being changed at all. You don't have to agree with that spirit in order to accept this simple fact. And while people keep on spreading this lie, I'll be inclined to point out that it's false. See, this is not about promoting GPLv3, or "pushing it down your throats", as some have claimed. This feeling is just a symptom of the high rejection for the FSF ideology, that appears to blind so many smart people from rational reasoning on matters that touch the FSF ideology. This is not even about showing that the letter of GPLv2 prohibited Tivoization. My arguments concerning Tivoization were all about the spirit of the license, and unfortunately so many people seem unable to tell the spirit from the letter that they keep on moving the discussion to legal technicalities, and then they shoot straw men and feel happy that they shot an argument. But the argument stands untouched, and the straw man was already dead before. Wasted time. As far as I'm concerned, Linux is released under GPLv2, and that's a good thing. It's unlikely to change. I wish it changed for better, but that's just me, and my contributions to Linux in term of code are really minimal. I have no say on that. But as someone involved in the GPLv3 development, it saddens me when people lie about it. I feel it's my moral obligation to set the record straight. And that's what I've been trying to do. -- 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: Versioning file system
Jan Harkes wrote: On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote: Jeffrey V. Merkey wrote: over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already, not to mention doing this is complex beyond belief. I reviewed your sample implementation, and it appears to infringe 3 patents already.You should do some research on this. First of all, you are responding to someone in the UK, I thought they didn't even have software patents over there. Second, I didn't see any implementation, just a high level description. Finally advising anyone (who is not an actual patent lawyer that could correctly interpret the language and scope of a patent) to go search out patents seems pretty bad advice. That can only result in not even attempting to research some potentially new and innovative approach. Researching prior published work in the area is considerably more helpful. Especially when something is complex beyond belief it has probably attracted various researchers over time and there are most likely various different solutions that have been explored previously. Such existing work can form a good basis for further work. Finally, even if there are patents they could be too limited in scope, overly broad, can be invalidated due to prior art. It may also be possible that a patent holder has no problem granting a royalty free license for a GPL licensed implementation. Jan When you get into the recycling issues with storage, the patents come into play. Also, using the file name to reference revisions is already the subject of a patent previously filed (I no longer own the patent, I sold them to Canopy). There is a third one about to be issued. The patents are: * 6,862,609 **6,795,895 and this one about to be issued: http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG=PCT_TYPE=19=1211506-KEY_FIELD=256=0=1205953=10_SET=IA,WO,TTL-EN=1=3=1=25=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG_IA=US2005045566=%28IN%2fmerkey%29+ The last one was filed with WIPO and has international protection, UK included. Jeff * Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 04:21:04 Alexandre Oliva wrote:
> On Jun 16, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Friday 15 June 2007 23:44:00 Alexandre Oliva wrote:
> >> On Jun 16, 2007, Tim Post <[EMAIL PROTECTED]> wrote:
> >> > On Fri, 2007-06-15 at 23:29 +0200, Ingo Molnar wrote:
> >> >> Tivo has two choices: either it gives
> >> >> users the content they want to watch, or it goes out of business. Is
> >> >> that legitimate enough of a reason to restrict the hardware?
> >> >
> >> > Can I submit that they could just rent the use of their machines?
> >>
> >> I don't think this would escape the wording of section 6 in GPLv3dd4:
> >>
> >> [...] User Product is transferred to the recipient in perpetuity or
> >> for a fixed term (regardless of how the transaction is
> >> characterized), [...]
> >>
> >> and IMHO that's as it should be to defend the freedoms of the user.
> >
> > In the case of renting a machine you can try to legislate new laws all
> > you want. It doesn't make a difference. There are certain rights you
> > don't get when renting something that you do when you own it.
>
> You mean renting the computer with the software in it is not
> distribution of the software?
It is. But you don't have the same rights to a rented machine as you do to one
you have purchased. In fact, in renting a machine you have to agree to
a "renters contract" - and that can state *whatever* the person that is
renting the machine to you feels like having it state. And yes, they can even
have terms in it that violate the GPL. Not that a "renters contract" ("rental
agreement" or whatever they call them in your jurisdiction) that has those
terms can *legally* violate the GPL - but it doesn't stop them from existing.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
Mark Williamson wrote: I reviewed your sample implementation, and it appears to infringe 3 patents already.You should do some research on this. Are you able to tell us which areas of the code infringe existing patents? Yes. Jeff Cheers, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: accurate user accounting
* malc <[EMAIL PROTECTED]> wrote: > > Interesting, the idle time accounting (done from > > account_system_time()) has not changed. Has your .config changed? > > Could you please send it across. I've downloaded apc and I am trying > > to reproduce your problem. > > http://www.boblycat.org/~malc/apc/cfs/ has config for 2.6.21 an the > diff against 2.6.21.4-cfs-v16. hm. Could you add this to your kernel boot command line: highres=off nohz=off and retest, to inquire whether this problem is independent of any timer-events effects? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Separate arch patching (Re: [patch-mm 06/25] clockevents: Fix resume logic)
* From: Thomas Gleixner [] > Fixup the existing users. > > This removes the sysfs entry for the HPET, which is now controlled by > the clockevents resume code. > > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> > > --- > arch/arm/mach-davinci/time.c |2 + > arch/arm/mach-imx/time.c |1 > arch/arm/mach-ixp4xx/common.c |2 + > arch/arm/mach-omap1/time.c|1 > arch/arm/plat-omap/timer32k.c |2 + Testers and users are most likely to run one particular arch on one particular test bench. If individual patches are arch separated, i think bisecting will be a little bit easier. Thus, i would like to propose separate arch patching (x86_64/i386 mainly). Is it possible to do that? (And even set such check in ``checkpatch''?) You would say, why? Because current kbuild/kconfig support of builds for whole tree. That's because to make download, build, test and debug particular arch more easily, i'm trying to re-think and re-do some kbuild parts. With minimum set of files, downloaded with git one can spend less time/bandwidth for starting testing. > arch/i386/kernel/apic.c |3 + > arch/i386/kernel/hpet.c | 71 > ++ > arch/i386/kernel/i8253.c | 26 ++--- > arch/i386/kernel/vmiclock.c |1 > arch/i386/xen/time.c |1 Opinions? > arch/sh/kernel/timers/timer-tmu.c |1 > arch/sparc64/kernel/time.c|1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 13:14:29 Alexandre Oliva wrote: > On Jun 16, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > > On Sat, Jun 16, 2007 at 05:22:21AM -0300, Alexandre Oliva wrote: > >> On Jun 15, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > >> > because it could easily be argued that they linked the BIOS with the > >> > Linux kernel > >> > >> How so? > > > > Er, they installed it in the same piece of equipment, and the kernel > > couldn't function without it in that work. > > I see what you're getting at. You're thinking of a license that > doesn't respect the idea of "mere aggregation", right? > > For starters, this wouldn't evidently not qualify as an Open Source > license, and I'm pretty sure it wouldn't qualify as a Free Software > license either. This situation is a general description that actually fits what TiVO has done. The difference in the TiVO case is that you (and everyone that thinks like you - ie: believes that the "tivoization" language in GPLv3 is good) equate "replace entirely" with "modification" when, in fact, the two are entirely separate acts. > > By using GPLix as part of their boot process along with their > > non-GPL BIOS, they're subverting the freedoms that the user should > > have in being able to control the entire boot process. > > You're pushing the "freedom to change" too far. Sure, I'd like to be > able to do that, and I prefer hardware that lets me do it, but it's > not like this BIOS in the scenario you described is being used as a > means to stop me from modifying the GPLed software. > > I have never said that including a GPLed piece of software should > grant users the right to modify anything whatsoever in the system, or > grant them control over the entire system. Others have, but it's not > true, it just shows how much mis-information is floating around. > > All the GPL stands for is to defend the freedom of the users over the > particular program it applies to. You can't impose further > restrictions on the user's ability to modify what *that* software > does. "You can't impose further restrictions on the user's ability to modify what *that* software does." I don't see how TiVO has done this. They have placed no restrictions on *modification* at all. What they have done is placed a restriction on *REPLACEMENT* of the program. If you're going to argue that "replacement == modification" then it is an *easy* argument to make that every time someone *replaces* linux with a proprietary system the proprietary system magically becomes GPL'd. And no, this isn't a logical fallacy on my part. It's on your part - all I've done is take the logic you have provided and extend it to cover a different situation. DRH > If you wanted to change something else, but this something else is not > covered by the license, and is not being used to contradict the terms > of the license, well, too bad, you lose. > > > b) deny themselves the ability to every offer a patch to said BIOS if > >bugs are found > > > > Point (b) is also exactly on topic for the discussion of enforcing > > legal safety obligations in hardware on a peripheral rather than the > > software drivers. > > > > It's requiring that these limitations be placed in a technically > > inferior location to hack around a legal "bug". > > I don't think this last sentence is true. If you implement hardware > locks that prevent modification of the software even by yourself, then > you're in compliance with the terms of the GPLv3dd4. But IANAL. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday 16 June 2007 12:57:59 Alexandre Oliva wrote: > On Jun 16, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > > Alexandre Oliva wrote: > >> On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: > >>> What this means for the FSF goals if Tivo get up one morning and switch > >>> their system firmware to ROM however is interesting 8) > >> > >> I'm not the FSF, and I don't speak for it, but it seems to me that > >> this would be "mission accomplished". > > > > This is insane. You start with a lofty ideal involving "freedom", and > > when you end up with a meaningless technicality (and in technical terms > > a change for the worse) you consider it a victory? > > It accomplishes the mission in that everyone is on the same grounds. > Same freedom for everyone. If the vendor tries to keep a privilege > over the software to itself, denying it to its customers, it's failing > to comply with the spirit of the license. It's really this simple. > Is this so hard to understand? -ELOGIC They are not keeping a priviledge over the *SOFTWARE* at all. They are keeping a priviledge over the *HARDWARE*. But, of course, you've already proven to everyone here that you are unwilling and/or unable to understand that. > The goal is not to push vendors away from GPLed software. If they > can't permit modification of the software, that's fine, they can still > accomplish this. replacement != modification If you can't understand that simple fact, then its pointless to continue this discussion. DRH > What they can't do is deny it to customers while they retain it to > themselves. This is unfair, this is wrong, and this disrespects > users' freedoms. Therefore, the GPL should not permit it. -- 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: coding style
[Stefan Richter - Sat, Jun 16, 2007 at 07:43:12PM +0200] | From: Stefan Richter <[EMAIL PROTECTED]> | To: [EMAIL PROTECTED] | CC: "Kok, Auke" <[EMAIL PROTECTED]>, | Chris Friesen <[EMAIL PROTECTED]>, | LKML , | Randy Dunlap <[EMAIL PROTECTED]>, | Jan Engelhardt <[EMAIL PROTECTED]>, | dave young <[EMAIL PROTECTED]>, Willy Tarreau <[EMAIL PROTECTED]>, | [EMAIL PROTECTED], [EMAIL PROTECTED] | Subject: Re: coding style | Date: Sat, 16 Jun 2007 19:43:12 +0200 | | [EMAIL PROTECTED] wrote: | > [Stefan Richter - Sat, Jun 16, 2007 at 03:07:43PM +0200] | > | Cyrill Gorcunov wrote: | > | > There sould be someting making strict rule over alignment (as it done | > | > for the tabs size). | > | | > | That's impracticable. Alignment, as it serves readability, cannot be | > | covered by a few strict rules. | | > Yes, but C syntax (and grammar) is limited set. And alignmet I'm talking | > about may cover the following statements only: | > | > 1) Mathematical | > 2) Logical | > 3) Function's arguments | | Sure, but we have sometimes long names and long ./-> dereference | expressions. Alignment of those after line wraps sometimes turns out | better if 'taste' rather than a simple rule is applied. | -- | Stefan Richter | -=-=-=== -==- = | http://arcgraph.de/sr/ | Of course you're absoulutely right!!! And that is why I've mentoined that it would be _recommendations_ only in CodingStyle. Cyrill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sat, Jun 16, 2007 at 01:57:59PM -0300, Alexandre Oliva wrote: > On Jun 16, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote: > > > Alexandre Oliva wrote: > >> On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: > >> > >>> What this means for the FSF goals if Tivo get up one morning and switch > >>> their system firmware to ROM however is interesting 8) > >> > >> I'm not the FSF, and I don't speak for it, but it seems to me that > >> this would be "mission accomplished". > > > This is insane. You start with a lofty ideal involving "freedom", and > > when you end up with a meaningless technicality (and in technical terms > > a change for the worse) you consider it a victory? > > It accomplishes the mission in that everyone is on the same grounds. > Same freedom for everyone. If the vendor tries to keep a privilege > over the software to itself, denying it to its customers, it's failing > to comply with the spirit of the license. It's really this simple. > Is this so hard to understand? > > The goal is not to push vendors away from GPLed software. If they > can't permit modification of the software, that's fine, they can still > accomplish this. > > What they can't do is deny it to customers while they retain it to > themselves. This is unfair, this is wrong, and this disrespects > users' freedoms. Therefore, the GPL should not permit it. How the hell does that improve the situation for users? Alexandre, please realize that you are preaching to non-believers. I realize that you have accepted the FSF credo, but if you want that conversation to go anywhere you have to separate the things you believe in from the things you can rationally explain. Apologetics of your variety is not going to cut it. _Can_ you separate the things relying on your beliefs from the things that can stand on their own? If you can't do that, please stop wasting everyone's time and bandwidth. It's a secular maillist; what any of us might happen to believe in is personal and frankly, none of your damn business. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: iov_iter_fault_in_readable fix
On 18:31 Чтв 14 Июн , Christoph Hellwig wrote: > On Wed, Jun 13, 2007 at 05:57:59PM +0400, Dmitriy Monakhov wrote: > > Function prerform check for signgle region, with out respect to > > segment nature of iovec, For example writev no longer works :) > > Btw, could someone please start to collect all sniplets like this in > a nice simple regression test suite? If no one wants to start a new > one we should probably just put it into xfsqa (which should be useable > for other filesystems aswell despite the name) I've prepared testcase (testcases/kernel/syscalls/writev/writev06.c) and sent it to ltp mailing list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Reporting the lid status using INPUT
On Saturday 16 June 2007 13:11, Richard Hughes wrote: > On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote: > > On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote: > > > On 6/15/07, Richard Hughes <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote: > > > > > in response to an event, but I'm thinking in a resume hook we should > > > > > probably do acpi_evaluate_integer(handle, "_LID", NULL, ) and > > > > > then > > > > > send an event, just so userspace is aware of what the state of the > > > > > panel > > > > > is. > > > > > > > > Attached patch fixed the issue for me. Comments? > > > > > > > > > > The patch makes perfect sense. The only issue I have is this: > > > > > > > + /* on resume we send the state; it might be the same, but > > > > userspace > > > > +* should handle duplicated events */ > > > > > > If switch state matches to what input layer thinks it is the event > > > will not even reach userspace. > > > > Okay, new patch attached, thanks for the speedy review. > > This fix is also confirmed by somebody else, see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243030 > > It would be great if this could go into .22, although I appreciate it's > quite late in the day. > This is of course Len's call but in my book this is a bugfix and as such is appropriate for -rc4/rc5. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
