On 24/11/18 1:53 am, Szabolcs Nagy wrote:
On 23/11/18 14:11, David Newall wrote:
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to e
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues. We need to abstract over these di
Hi all,
First, I'm not subscribed to any of the mailing lists addressed. Please
copy me in replies.
I'm not sure if this is an LVM issue or a MM issue. I rather think it's
the latter, and I'll explain why, towards the end of this email.
I'm running a qemu virtual machine, 2 x i686 with 2GB
On 20/05/14 14:25, valdis.kletni...@vt.edu wrote:
So yes, we*do* need to do something sensible there - either frag the packet
on the way out, or something.
I think the problem is that a bridge cannot be used across incompatible
media. That's the job of a router.
A bridge should act like a
Thanks for the reply. I've been hanging out for it!
On 19/05/14 23:31, Florian Westphal wrote:
Well, did you test what happens if we try to refrag a packet
containing ip options after the revert?
can happen e.g. when using netfilter conntrack on top of a bridge.
No. I expect it would panic,
462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge :
Sanitize skb before it enters the IP stack)
Date: Sat, 17 May 2014 00:03:16 +0930
From: David Newall
To: Lukas Tribus , Eric Dumazet
, Netdev
CC: f...@strlen.de
We should revert commit 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge
: Sanitize
David Brownell wrote:
> On Tuesday 26 February 2008, David Newall wrote:
>
>> Hardware can be inserted and removed while we're in a suspend state; and
>> there's nothing that we can do about it until we resume. Is it fair to
>> say, then, that having started s
David Brownell wrote:
> This "flaw" isn't a new thing, of course. I remember pointing out the rather
> annoying proclivity of the PM framework to deadlock when suspend() tried to
> remove USB devices ... back around 2.6.10 or so. Things have shuffled around
> a bit, and gotten better in some case
Linus Torvalds wrote:
> On Sat, 23 Feb 2008, David Newall wrote:
>
>> Do you actually get 80 columns wide on it?
>>
>
> Do people really care that deeply?
> ...
> And do I find lines longer than 80 charactes unreadable? Hell no.
>
I care, yes. I
Jan Engelhardt wrote:
> static void blah(void)
> {
> if (foo) {
> bar;
> bar2;
> return;
> }
> if (this) {
> that;
> that2;
> return;
> }
> /* yay, got rid of two levels of indent! */
>
Pavel Machek wrote:
> On Sat 2008-02-23 23:08:58, David Newall wrote:
>
>> Pavel Machek wrote:
>>
>>> On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote:
>>>
>>>
>>>> Pavel Machek <[EMAIL PROTECTED]> writes:
>
Matthew Wilcox wrote:
> On Sat, Feb 23, 2008 at 04:14:08PM +0800, WANG Cong wrote:
>
>> Use get_personality() macro instead of explicit reference
>> for parisc code.
>> -if (personality(current->personality) == PER_LINUX32
>> +if (personality(get_personality()) == PER_LINUX32
>>
>
>
Pavel Machek wrote:
> On Fri 2008-02-22 23:44:09, Krzysztof Halasa wrote:
>
>> Pavel Machek <[EMAIL PROTECTED]> writes:
>>
>>
>>> Zaurus is one example, second is small screen where you need big font
>>> to keep it readable (x60 on desk).
>>>
>> Come on, are you doing Linux kernel de
Bart Van Assche wrote:
> There is a reason to limit line length: scientific research has shown
> that readability of regular texts is optimal for a line length between
> 55 and 65 characters.
Putting aside the point that we're talking code, not regular text, I've
heard that said before and I don't
Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>> I'm personally of the opinion that a lot of checkpatch "fixes" are
>> anything but. That mainly concerns fixing overlong lines
>>
>
> Perhaps we should increase line length limit, 132 should be fine.
> Especially useful w
Greg KH wrote:
> On Thu, Feb 21, 2008 at 10:00:58PM +0100, Willy Tarreau wrote:
>
>> I too agree to merge, it especially since it fixed several problems
>> for David. However, I would like to know first if the same problems
>> also happen with the 2.6 driver or if it is OK. The risk is getting
>
Sorry, I forgot to include the changes to pl2303.h. Here's a second patch:
--- pl2303.h.orig 2008-01-01 22:36:40.0 +1030
+++ pl2303.h2008-02-22 06:11:19.0 +1030
@@ -9,7 +9,10 @@
*/
#define PL2303_VENDOR_ID 0x067b
#define PL2303_PRODUCT_ID 0x2303
-#define P
Hi Willy,
Lacking hardware for a week, I've had a bit of a hiatus from PL2303, but
I've got it back again now, and finished my work back-porting the 2.6
driver to 2.4. Here's a new patch, which is more complete than my
previous one. It's based on the 2.6.24.1.
There's a lot of trivial white-spa
Alan Cox wrote:
>> developing is entirely wrong. Oh well. Mind you, providing a
>> write_room function is NOT a real solution; it merely reduces the
>> condition to a usually-winnable race. (Ironically, when I back-ported
>> the 2.6 driver, I excluded its new write_room function. Mistake.)
>>
Alan,
Alan Cox wrote:
>> That's a very good point. Even so: on the 2.4 driver, write_room isn't
>> implemented (refer to a previous message by Alan); and in 2.6, a 1k
>> buffer is built into the driver, with nothing to prevent it being sent
>> when the hardware buffer fills.
>>
[...]
> Care
Stephan,
Jiri Slaby wrote:
> On 02/14/2008 03:57 PM, Stephan Rose wrote:
>> I recently purchased a USB->Com Port serial cable from Radio Shack
>> (Model number 26-183) which did no seem to want to work. After looking
>> into it I discovered that it is based on the Prolific chipset using the
>> PL2
Adrian Bunk wrote:
> Forks are allowed, so when you don't like the way some software is
> developed you can always release a version of the software that is in
> your eyes better.
>
What a silly thought. Nobody, I should hope, wants multiple Linuxes
competing and diluting the market. That's
Greg KH wrote:
> On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
>
>> The current 2.6 driver maintains it's own buffer. I think that's a bad
>> thing: usbserial already buffers writes, and the extra buffer copy seems
>> unnecessary, however
Alan Cox wrote:
>> byte of a packet is being thrown away about .1% of the time for the pl2303,
>> but I'm not sure if the FTDI driver still suffers from a similar rash. I
>>
>
> A 20 byte low speed message is too small for flow control to account for
> it.
I agree. I've observed the first
Arjan van de Ven wrote:
> Bill Davidsen wrote:
>> Note that because the hardware is old, it's highly likely that most
>> of it will be retired before that sk98lin driver needs a change. I
>> can't see anyone using sk98lin on a new system, so it would be less
>> contentious to let the hardware (or u
Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write. I think it's
>> essential to delay submission of the URB on a stop-transmit cond
Greg KH wrote:
> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
>
>> Consider a USB-attached serial port that is set to do RTS/CTS (or
>> DSR/DTR) handshaking: What stops the kernel sending more data to it when
>> the remote end lowers CTS (or DTR)?
&
Consider a USB-attached serial port that is set to do RTS/CTS (or
DSR/DTR) handshaking: What stops the kernel sending more data to it when
the remote end lowers CTS (or DTR)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
Greg KH wrote:
> A "driver" is not an "application" as you tried to reference in your
> prior quotes.
I think your treating what the learned Professors said to literally.
> It is a tiny portion of the whole kernel,
The Copyright Act draws no such a distinction.
> and as such,
> does fall under
My, I am full of post scripts today. This one is a peace token for Alan.
David Newall wrote:
> there are more reliable and transparent sources [than Alan.] Don't take his
> word on it. Take the words of real experts in the law, because instead
> of a mere four word conclusion
I explained something poorly:
> Now, Alan has made a big issue over numerous legal opinions he has
> received, but he's been completely coy in the details.
The point I wanted to make is that a few people have said that lawyers
say that kernel modules are derivative, but I only remember Alan saying
Marcel Holtmann wrote:
> Anyway you are still under the impression that a Linux kernel module can
> be original work in the end. We keep telling you that could be a wrong
> assumption which is based on the view of many of the kernel developers
> and of most of the lawyers that looked at this specif
Alan Cox wrote:
> On Fri, 08 Feb 2008 13:25:33 +1030
> David Newall <[EMAIL PROTECTED]> wrote:
>
>
>> Alan Cox wrote:
>>
>>>> It would not be improper to say that "such and such a lawyer said this
>>>> and that.&q
Marcel Holtmann wrote:
> Hi David,
>
>
> I think you're missing my point: as long as the license stays the way
> it is now, you can never distribute proprietary code unless you've
> consulted a lawyer and even then you run the risk of being sued for
> infringement if the copyrigh
Alan Cox wrote:
>> It would not be improper to say that "such and such a lawyer said this
>> and that." I'm not proposing that you breach their copyright in their
>>
>
> It would be highly improper given these were business discussions
> involving companies using Linux.
Then you should never
Hans-Jürgen Koch wrote:
> The license says that derivative work has to be GPL. Naturally, every
> sensible and practically usable license has gray areas. We know that
> and we live with that. But if there's room for interpretation, it's
> perfectly OK and helpful, if the copyright holder states wha
Hans-Jürgen Koch wrote:
> Am Fri, 08 Feb 2008 01:01:24 +1030
> schrieb David Newall <[EMAIL PROTECTED]>:
>
>>> It is not legally meaningless if copyright holders publicly state
>>> how they interpret the license and what they consider a license
>>> v
Alan Cox wrote:
>> previous statements which seemed to say, "you've spoken to numerous
>>
>
> Please don't use "seemed to say" and then quote words I've never said.
> That's misleading, rude and also awful language style.
No, it's called, "paraphrasing," and it's quite normal in a
conversatio
Alan Cox wrote:
>> No, I'm right. The word "proof" is appropriate in context. (I write in
>> plain English, not Legalese.) I certainly didn't intend "proof" to mean
>> "mathematically certain." Anybody who pretends that proof in court
>> means that must be ignorant or trying to deceive.
>>
Alan Cox wrote:
>> That's what you claim it says, but has any court, anywhere, agreed with
>> you? You claim the authority of others (i.e. numerous lawyers), but I
>> don't believe you have that authority. You're just starting hearsay.
>> You've never said what lawyers and you've never told us w
Alan Cox wrote:
>> It's nonsense, it's a reasonable reading of the GPL. What I am doing is
>> telling you what the GPL says, not what you wish it said.
>>
>
> In which case for each statement please give the case at appeal or higher
> level which is the precedent for the interpretation.
>
Alan Cox wrote:
>> Again, I missed who wrote the above. I'm reminded of Apple computer,
>> who explaining some engineering decisions in the Apple ][ pointed out
>> that an additional 10c in components adds $10 to the retail price (or
>> something rather like that.) Cheap, cheap, cheap helps mark
Diego Zuccato wrote:
> David Newall ha scritto:
>
>> That's naive, since requirements differ in different jurisdictions, as
>> I'm sure you are perfectly aware.
> Naive? Who thinks a limit can be enforced by sw is naive!
Of course. Naturally it's near imposs
Alan Cox wrote:
>>> IANAL, but when looking at the "But when you distribute the same
>>> sections as part of a whole which is a work based on the Program, the
>>> distribution of the whole must be on the terms of this License" of the
>>> GPLv2 I would still consult a lawyer before e.g. selling a
Alan Cox wrote:
>> No. Holders of Linux copyrights would have to prove that the
>> proprietary code is derived from the kernel. They have the burden of
>> proof, and defence needs merely show that their arguments are wrong.
>>
>
> Wrong again. In civil law in the USA and most of europe the t
Alan Cox wrote:
>> In Australia, devices require approval from a regulatory body. Such
>> approval is withheld if appropriate safeguards are not applied.
>>
>
> We were talking about the USA.
We most certainly were not. We are talking about Linux, and everybody
wants it be used globally.
>
Alan Cox wrote:
>> The contract (GPL) doesn't prevent me from using GPL work, in fact it
>> encourages me. Neither can it impose conditions upon original work
>> authored by a third party.
>>
>
> First mistake: The GPL is not a contract it is a license.
Mea culpa. It is indeed a licence, whi
Hans-Jürgen Koch wrote:
> Am Thu, 07 Feb 2008 23:49:42 +1030
> schrieb David Newall <[EMAIL PROTECTED]>:
>
>> Nobody is saying "I don't like your licence." The issue is a
>> technical restriction in Linux that attempts to restrict non-GPL
>> so
Alan Cox wrote:
>> I heard this all before and I don't buy it anymore. At some point the
>> companies in Asia will understand that the whole picture looks different
>> and that not always cheap, cheap, cheap is best for their margins.
Again, I missed who wrote the above. I'm reminded of Apple com
Marcel Holtmann wrote:
>>> if a new drivers is originally written for Linux, then you are breaking
>>> the GPL.
>>>
>> Completely wrong. However if the driver is distributed as built-in, then it
>> would need to be licensed under GPL. This means that a driver can be
>> written and distri
Marcel Holtmann wrote:
> Hi David,
>
>
>>> I think you're missing my point: as long as the license stays the way
>>> it is now, you can never distribute proprietary code unless you've
>>> consulted a lawyer and even then you run the risk of being sued for
>>> infringement if the copyright holder
Greg KH wrote:
> On Tue, Feb 05, 2008 at 10:09:07PM +1030, David Newall wrote:
>
>> Marcel Holtmann writes:
>>
>>> if a new drivers is originally written for Linux, then you are breaking
>>> the GPL.
>>>
>> Completely wrong. How
Chris Friesen wrote:
> Marcel Holtmann wrote:
>
>> If the developers say that this symbol can only be used in GPL code (and
>> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that
>> license or don't use this symbol at all.
>>
>> If you use that symbol inside non-GPL (meaning you
Diego Zuccato wrote:
> David Newall ha scritto:
>
>> "Of course", because in many parts of the world, a device who's
>> manufacturer fails to take reasonable steps to prevent it from being
>> used outside regulatory limits is illegal. Providing source code
Pekka Enberg wrote:
> I have simply stated that (1) the problem boils down to what is
> derived work and what is no and (2) the developers use the
> EXPORT_SYMBOL_GPL as a hint of what they think to be derived work (not
> necessarily tested in court). The _logical conclusion_ of these two
> simple
Adrian Bunk wrote:
> On Tue, Feb 05, 2008 at 05:34:23PM -0600, Chris Friesen wrote:
>
>> David Newall wrote:
>>
>>> That being said, a module can be written such that it only dynamically
>>> links with the kernel. Ndiswrapper is an example of ho
Marcel Holtmann wrote:
> I disagree here. They either play by the roles or they really do pay
> Microsoft or go with BSD. I really couldn't care less.
Then you should keep away from the kernel. The last thing that Linux
needs is someone who doesn't care if Linux succeeds or fails. "I don't
care"
Hans-Jürgen Koch wrote:
> If somebody prefers an other OS for license reasons only, let them. You
> cannot have open source software without open source license. If a
> company chooses Linux, they do it for technical reasons, and because
> they're able to modify the sources to suit their needs. Wha
Christer Weinigel wrote:
> I also think that my customers, that decided to keep their kernel
> modules binary only, made a big mistake and have told them so. But I
> still think it's better for the Linux community to be a bit soft on
> such companies for a while. It's better to let them get away
Greg KH wrote:
> On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
>
>> On Tue, 5 Feb 2008 12:34:18 -0800
>> Greg KH <[EMAIL PROTECTED]> wrote:
>>
>>
>>> In the end, it's up to the copyright holders to enforce the license.
>>> And as I have stated in the past, a number of t
Chris Friesen wrote:
> if I were to write a new GPL shim and then a new closed-source module
> that uses the shim to access kernel symbols, it is entirely possible
> that a court could rule that my closed-source module is a derivative
> work of the linux kernel because it was written specifically t
Alan Cox wrote:
>> "Of course", because in many parts of the world, a device who's manufacturer
>> fails to take reasonable steps to prevent it from being used outside
>> regulatory limits is illegal. Providing source code not only is a failure
>> to take those reasonable steps, but is quite th
Greg KH wrote:
> On Wed, Feb 06, 2008 at 09:44:36AM +1030, David Newall wrote:
>
>> A kernel module is akin to a process. It uses services of the kernel
>> without being part of the kernel.
>>
>
> No Linux does not work like this at all.
> ...
> Als
Alan Cox wrote:
>> If we're still talking about whether a kernel module is required to be
>> released under GPL, then yes, this is not a gray area. This is something
>> that authors of original works can decide for themselves. They have no
>>
^^^
>
> Onl
Marcel Holtmann wrote:
>>> If the developers say that this symbol can only be used in GPL code (and
>>> with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that
>>> license or don't use this symbol at all.
>>>
Not sure who wrote the above, but it contains a glaring legal error
Diego Zuccato writes:
David Newall ha scritto:
This does, of course,
disadvantage Linux with respect to many classes of devices, for example
GSM transceivers when used in those parts of the world^ where regulatory
requirements prohibit modification of power or frequency settings, which
Greg KH writes:
No, it really is not a gray area at all, especially when you are writing
a new driver for Linux. Go talk to a lawyer if you want the details.
If we're still talking about whether a kernel module is required to be
released under GPL, then yes, this is not a gray area. This is
Marcel Holtmann writes:
if a new drivers is originally written for Linux, then you are breaking
the GPL.
Completely wrong. However if the driver is distributed as built-in, then it
would need to be licensed under GPL. This means that a driver can be
written and distributed as a module under
Pekka Enberg writes:
I think you're missing my point: as long as the license stays the way
it is now, you can never distribute proprietary code unless you've
consulted a lawyer and even then you run the risk of being sued for
infringement if the copyright holder thinks what you have is derived
wo
Bernd Petrovitsch writes:
On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote:
[...]
disadvantage Linux with respect to many classes of devices, for example
GSM transceivers when used in those parts of the world^ where regulatory
requirements prohibit modification of power or frequency
Pekka Enberg wrote:
> Hi David,
>
> On Feb 3, 2008 5:12 PM, David Newall <[EMAIL PROTECTED]> wrote:
>
>> By the way, I'm almost certain that the COPYING file is the first, last
>> and only document specifying licence conditions, and nothing in that
&g
Greg KH wrote:
> It comes down to the simple fact, if you wish to use Linux, abide by the
> license it comes under. To do otherwise is both disenginous and
> illegal[1].
By the way, I'm almost certain that the COPYING file is the first, last
and only document specifying licence conditions, and not
Greg KH wrote:
> It comes down to the simple fact, if you wish to use Linux, abide by the
> license it comes under. To do otherwise is both disenginous and
> illegal[1].
I think you're being dishonest. This isn't really about Linux and it
being licensed under GPL, is it? Not if you're being 100
Hi Willy,
Willy Tarreau wrote:
> Based on the above conditions, I'd like you to tell Greg and I if you
> consider it worth to merge this backport in 2.4 now. From my point of
> view, your work looks OK but I want your feedback as a user (and not
> as the backporter), then Greg's approval.
The dat
David Miller wrote:
> From: David Newall <[EMAIL PROTECTED]>
> Date: Fri, 01 Feb 2008 11:17:14 +1030
>
>
>> Patrick McHardy wrote:
>>
>>> Jozsef Kadlecsik wrote:
>>>
>>>> Strange, but there are a lot of incorrect check
H. Peter Anvin wrote:
> David Newall wrote:
>> Isn't a crc32 calculation already defined? Yes; in lib/crc32.c. One is
>> surely enough.
>
> As long as it can be included in user-space code we should use that one.
You're right. I misread the patch. I thought the
I've been working on a buffer overflow problem in pl2303. Admittedly
I'm using a 2.4 kernel, but I've back-ported the latest pl2303.c.
(Please make no unnecessary fuss over that.) For the record, the
pl2303.c from 2.6.23 is substantially identical to that from 2.4. The
significant change, other
Patrick McHardy wrote:
> Jozsef Kadlecsik wrote:
>> Strange, but there are a lot of incorrect checksum packets. How does
>> it come on the loopback interface?
>
> Loopback doesn't perform full checksumming, so thats expected.
The question remains: How do loopback packets get incorrect checksum?
W
Isn't a crc32 calculation already defined? Yes; in lib/crc32.c. One is
surely enough.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Adrian Bunk wrote:
> IANAL, but I have serious doubts whether putting some glue layer between
> the GPL'ed code and the code with a not GPL compatible licence is really
> a legally effictive way of circumventing the GPL.
Just to refresh my memory, I re-read the GPLv2, and specifically the
licen
Jan Engelhardt wrote:
> On Jan 30 2008 12:53, Steve French wrote:
>
>> I have mounted to Windows98 a few months ago with no problems (other
>> than a few restrictions like you can't set the file times via utimes).
>> For mounts to Windows98 note that you have to specify the server
>> netbios nam
I experienced major major data loss on a PL-2303 USB-serial converter
under 2.4.36, which I remedied by back-porting the pl2303.c from the
latest 2.6 kernel tree.
---
diff -u linux-2.4.36/drivers/usb/serial/pl2303.c.orig
linux-2.4.36/drivers/usb/serial/pl2303.c
--- pl2303.c.orig 2008-01-01
What's the process for submitting patches for a linux-2.4 driver? I'm
sure this is a FAQ, but I can't find the answer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
Pavel Machek wrote:
> /-\
> | |
> | Stop feeding the TROLL |
> | |
> \-/
> ||
> ||
> ||
> ||
> ||
> ||
> ||
>
Pavel
Andi Kleen wrote:
>> The performance benefit is trivial,
>>
>
> That's actually not true when you're talking about potential cache misses.
> Cache misses are very expensive.
>
They are when in a tight loop, but are trivial in this case. I'll go
further and say that unless the system is co
Adrian Bunk wrote:
> On Fri, Jan 25, 2008 at 04:25:24AM +1030, David Newall wrote:
>
>> The performance benefit is trivial, and the improvement to
>> maintainability is even less.
>>
>
> The effects become bigger when you realize that there are many such
&
Adrian Bunk wrote:
> Removing dead code makes:
> - the kernel smaller,
> - the kernel faster and
> - makes it easier to maintain the non-dead code.
>
The performance benefit is trivial, and the improvement to
maintainability is even less.
> All of these are considered useful by the people who
Alan Cox wrote:
>
>
>> You're being silly. Either that or you're not reading what I write.
>> You know perfectly well iBCS2 compatibility doesn't work (anymore.) The
>> question, in my mind, is will it ever be made to work again? I think
>> the answer should be yes.
>>
>
> We await yo
Andi Kleen wrote:
> I stand by my earlier point that it doesn't make sense to have all
> Linux kernels always execute these strcmps.
>
Why? It's a trivial expense. Alternatively, (rhetorically), why not
also remove AOUT and COFF support? Same argument.
--
To unsubscribe from this list: send
Adrian Bunk wrote:
> But Linux kernel development is not driven by people producing hot air
> about what they wish to see in the future, Linux kernel development is
> driven by people sending patches.
Removal of code is not development. It's the opposite of development.
At one stage iBCS2 supp
Ingo Molnar wrote:
> unfortunately you have not replied to my (rather clear) question. Let me
> repeat the question (which can be clearly seen in the quoted sections
> above). Andi made this assertion:
>
> | You seem to be under the illusion that iBCS2 support works currently
> | in mainline an
Ingo Molnar wrote:
> * David Newall <[EMAIL PROTECTED]> wrote:
>
>> Andi Kleen wrote:
>>
>>> You seem to be under the illusion that iBCS2 support works currently
>>> in mainline and that only this patch would break it.
>>>
>
Karl Kiniger wrote:
> on http://www.feise.com/~jfeise/Downloads/linux-abi/
>
> a patch named linux-abi-2.6.22.3_3.diff.bz2 can be found.
>
Thankyou for that.
Matter of interest: if it works, why isn't it in the mainline?
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Andi Kleen wrote:
> You seem to be under the illusion that iBCS2 support works currently
> in mainline and that only this patch would break it.
I cannot imagine what brings you to that conclusion. Suffice to say you
are entirely and inexplicably wrong.
--
To unsubscribe from this list: send the li
Alan Cox wrote:
>> It's not necessarily that simple. It might be for KFC and Dominoes, but
>> for others, SCO is not the complete story. Many legacy systems are
>> written in COBOL, and must pay a per-seat licence for that on top of the
>> per-seat licence for UNIX. It is these systems that are
Andi Kleen wrote:
> On Sun, Jan 20, 2008 at 04:03:22PM +1030, David Newall wrote:
>
>> It's not necessarily that simple. It might be for KFC and Dominoes, but
>> for others, SCO is not the complete story. Many legacy systems are
>> written in COBOL, and must pay a
Andi Kleen wrote:
> On Sun, Jan 20, 2008 at 03:16:25PM +1030, David Newall wrote:
>
>> Andi Kleen wrote:
>>
>>> On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote:
>>>
>>>
>>>> compatibility.
Andi Kleen wrote:
>> Isn't it the case that an idle machine will use
>> less power when throttled than when not?
>>
>
> No that is not the case (not even on old CPUs)
>
Then why would it run cooler? What generates the heat when not
throttled? What stops generating heat when throttled? A
Andi Kleen wrote:
> On Sun, Jan 20, 2008 at 12:57:29PM +1030, David Newall wrote:
>
>> compatibility. This is a sleeping giant for Linux. There are plenty of
>>
>
> Interesting choice of words.
>
KFC and Dominoes use SCO for their cash registers, to pi
Andi Kleen wrote:
> I think the misunderstanding on your side is relative to what there
> is less heat. Throttling essentially reduces temporary heat spikes on
> the silicon, but does not make the system overall take less power
> or generate less heat as measured over a longer time because it will
1 - 100 of 201 matches
Mail list logo
