Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, 2005-04-13 at 21:47 +0200, Sven Luther wrote: > On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote: > > > > This is different. They are not giving the source at all. The licence > > > > for those object files _has_ to be different. _They_ want it to be > > > > different. > > > > > > Sure, but in this case, the binary firmware blob is also a binary without > > > sources. If they really did write said firmware directly as it is, then > > > they > > > should say so, but this is contrary to everyone's expectation, and a > > > dangerous > > > precedent to set. > > > > You should realize that any author can publish his work in the form he > > likes. He's not bound to "everyone's expectation". I see no danger in > > that. > > I think there may be some limitation of using the GPL as licence in this case > though, as such behavior may limit its value, and the GPL itself is by no > means free software. That GPL isn't the best license in this case (firmware included as hexstring in the driver source), we already know. But fixing it is up to the copyright holder. We or GPL face no risk. Note that the holder does. I'd be interesting if someone produced a derivative work, such a translation. A translation from the hex form to some kind of textual formally defined language, such as, say, assembler, or C. That would be covered by GPL. And would be distributable under it. Say that the resulting binary is slightly different. You are _required_ by GPL to provide the source in the preferred form, this time, preferred by _you_. What if that is C? Interesting enough. Can the hexstring be reverse-engineered into C, if it's placed under GPL? Can the copyright holder really prevent that? Something new to think of. :-) Have a nice day, .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, 2005-04-13 at 21:47 +0200, Sven Luther wrote: On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote: This is different. They are not giving the source at all. The licence for those object files _has_ to be different. _They_ want it to be different. Sure, but in this case, the binary firmware blob is also a binary without sources. If they really did write said firmware directly as it is, then they should say so, but this is contrary to everyone's expectation, and a dangerous precedent to set. You should realize that any author can publish his work in the form he likes. He's not bound to everyone's expectation. I see no danger in that. I think there may be some limitation of using the GPL as licence in this case though, as such behavior may limit its value, and the GPL itself is by no means free software. That GPL isn't the best license in this case (firmware included as hexstring in the driver source), we already know. But fixing it is up to the copyright holder. We or GPL face no risk. Note that the holder does. I'd be interesting if someone produced a derivative work, such a translation. A translation from the hex form to some kind of textual formally defined language, such as, say, assembler, or C. That would be covered by GPL. And would be distributable under it. Say that the resulting binary is slightly different. You are _required_ by GPL to provide the source in the preferred form, this time, preferred by _you_. What if that is C? Interesting enough. Can the hexstring be reverse-engineered into C, if it's placed under GPL? Can the copyright holder really prevent that? Something new to think of. :-) Have a nice day, .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote: > On Tue, Apr 12, 2005 at 06:14:17PM +0200, Marco Colombo wrote: > > No one will ever do that. If you are distributing the software I released > > under GPL, be sure I _will_ sue you if you break the licence. What do you > > want from me? A promise I won't sue you if you don't? That is implicit > > in the existance of the licence. > > > > Are you implying debian will stop distributing _any_ software unless > > the all the copyright holders of GPL software "explicitly say" they > > won't sue you? > > Well, we won't distribute binaries placed under the GPL, definitively not. And > if there is a dubious case, we ask for clarification of the author. Your choice, of course. [...] > > This is different. They are not giving the source at all. The licence > > for those object files _has_ to be different. _They_ want it to be > > different. > > Sure, but in this case, the binary firmware blob is also a binary without > sources. If they really did write said firmware directly as it is, then they > should say so, but this is contrary to everyone's expectation, and a dangerous > precedent to set. You should realize that any author can publish his work in the form he likes. He's not bound to "everyone's expectation". I see no danger in that. > > >So, really, i doubt any manufacturer distributing non-free firmware would > > >really have trouble in adding to their licence something like this : > > > > > > In addition, , considers the firmware blob, identified as > > > <...>, as > > > a non-derivative piece of work, and thus not covered by the GPL of the > > > rest > > > of it. gives permission to distribute said firmware blob as > > > part of the linux kernel module driver for their hardware. The actual > > > syntax > > > of the inclusion of the code is still covered by the GPL, as is the rest > > > of > > > the driver code. > > > > This is fine with me. It is the existance of legal threats versus > > debian I don't agree upon. > > Notice that debian can't afford to be sued even if they are right, so ... So what? This is not the point. You can be sued any time by any one, even if you're right. If debian can't afford it, it can't afford existance. > > >>Yes, but it does not apply to our case here. There's no "all other > > >>copyright holders". _You_ stated that the firmware is included by mere > > >>aggregation, so there's no other holders involved. We're talking > > >>about the firmware case. A is one or two well identified subjects. > > >>And A wrote it is GPL'ed. Whether you agree or not, that's the licence > > >>A chose. A placed the copyright notice. > > > > > >This is where i would need legal counsel, as to whether this means C or > > >someone else may stop you from distributing unless you provide the source. > > >And > > >the real problem is that A didn't state anything, so we are only working on > > >the assumption that this may be the case, and A can change its mind later, > > >and > > >the costs to defend ourselves in front of a judge, even if your > > >interpretations are right, are enough prohibitive for debian not to > > >distribute > > >said files. > > > > A did put a GPL notice on it. He can't change his mind later. > > Then he should give us the source. No, why? GPL cannot place restrictions or obligations on the copyright owner. Let's stop discussing it please, you can't buy me on this either. I have my own interpretation of what a license it, and it seems you don't agree with it: to me, it's one way: _you_, the licensee, get some rights if you fulfill some conditions. Conditions are all placed on you, none on the copyright holder. In particular, the one about making source available is placed on distributors, verbatim copies of the source for binary distribution of the work, or full source of the modifications for modified versions of the work. And anyway, this has nothing to do with with legal threats from the copyright holder. My point being: he cannot sue you for not distributing the source "as provided by him" if he failed to provide them in the first place in a different from. That is, he has to give you the source, if he is trying to force you distributing it. > > >>The licence is a matter between A and D. A may sue D and D may (less > > >>likely) sue A, if conditions are not met. I'm not sure at all GPL > > >>is enforceable by D upon A. Let's assume it is, for sake of discussion, > > >>anyway. > &
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote: On Tue, Apr 12, 2005 at 06:14:17PM +0200, Marco Colombo wrote: No one will ever do that. If you are distributing the software I released under GPL, be sure I _will_ sue you if you break the licence. What do you want from me? A promise I won't sue you if you don't? That is implicit in the existance of the licence. Are you implying debian will stop distributing _any_ software unless the all the copyright holders of GPL software explicitly say they won't sue you? Well, we won't distribute binaries placed under the GPL, definitively not. And if there is a dubious case, we ask for clarification of the author. Your choice, of course. [...] This is different. They are not giving the source at all. The licence for those object files _has_ to be different. _They_ want it to be different. Sure, but in this case, the binary firmware blob is also a binary without sources. If they really did write said firmware directly as it is, then they should say so, but this is contrary to everyone's expectation, and a dangerous precedent to set. You should realize that any author can publish his work in the form he likes. He's not bound to everyone's expectation. I see no danger in that. So, really, i doubt any manufacturer distributing non-free firmware would really have trouble in adding to their licence something like this : In addition, manufacturer, considers the firmware blob, identified as ..., as a non-derivative piece of work, and thus not covered by the GPL of the rest of it. manufacturer gives permission to distribute said firmware blob as part of the linux kernel module driver for their hardware. The actual syntax of the inclusion of the code is still covered by the GPL, as is the rest of the driver code. This is fine with me. It is the existance of legal threats versus debian I don't agree upon. Notice that debian can't afford to be sued even if they are right, so ... So what? This is not the point. You can be sued any time by any one, even if you're right. If debian can't afford it, it can't afford existance. Yes, but it does not apply to our case here. There's no all other copyright holders. _You_ stated that the firmware is included by mere aggregation, so there's no other holders involved. We're talking about the firmware case. A is one or two well identified subjects. And A wrote it is GPL'ed. Whether you agree or not, that's the licence A chose. A placed the copyright notice. This is where i would need legal counsel, as to whether this means C or someone else may stop you from distributing unless you provide the source. And the real problem is that A didn't state anything, so we are only working on the assumption that this may be the case, and A can change its mind later, and the costs to defend ourselves in front of a judge, even if your interpretations are right, are enough prohibitive for debian not to distribute said files. A did put a GPL notice on it. He can't change his mind later. Then he should give us the source. No, why? GPL cannot place restrictions or obligations on the copyright owner. Let's stop discussing it please, you can't buy me on this either. I have my own interpretation of what a license it, and it seems you don't agree with it: to me, it's one way: _you_, the licensee, get some rights if you fulfill some conditions. Conditions are all placed on you, none on the copyright holder. In particular, the one about making source available is placed on distributors, verbatim copies of the source for binary distribution of the work, or full source of the modifications for modified versions of the work. And anyway, this has nothing to do with with legal threats from the copyright holder. My point being: he cannot sue you for not distributing the source as provided by him if he failed to provide them in the first place in a different from. That is, he has to give you the source, if he is trying to force you distributing it. The licence is a matter between A and D. A may sue D and D may (less likely) sue A, if conditions are not met. I'm not sure at all GPL is enforceable by D upon A. Let's assume it is, for sake of discussion, anyway. Ah, but the licence is transitive, and if D may sue A, then C may also sue D, since the GPL makes no distinction between who makes the distribution, apart from the fact that A may relicence its code. But if he distributes it as part of the GPL ... Pardon me, I have no idea of what a transitive licence could be. Sublicencing or relicencing is _explicitly_ not covered by GPL anyway. You give away the source to someone, he has the same rights you had, except relicencing, this is what i meant by transitive. GPL explicitly says that when you, a distributor, give the source to someone, he receives a license, another instance of GPL so to say
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 12 Apr 2005, Sven Luther wrote: On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote: Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. The main problem is that i feel that those binary firmware copyright holders may have put it under the GPL, but i doubt they realize that this means they have to release the source code of said firmware blobs. They released it not in object format, but in the C language. An hexstring, agreed, but still C. The copyright holders can release their work how they please. If you think GPL can place restrictions on what they can do, please see below. Also, i believe you are wrong in the above, the only interpretation that is important is the one the judge will take in case someone goes to suing. Agreed, let me rephrase then. The only interpretation that is important _to the judge_ is the one of the parties involved. In any agreement, the parties express their will. Here, the holders "wrote" the agreement alone, so _their_ interpretation counts. That is, their interpretation as it was when they licenced the software. Not as is it after later thinking (or acquisition by some bad guy). And finally, if anyone could claim that a binary is the prefered form of modification, which is most of the time obviously false, then the GPL would be worthless. And anyway, the GPL states this (first paragraph after subclause c in clause 3) : I don't care about GPL being worthless. This is not the GPL advocacy list. I'm just saying that if you distribute the source in the form the author published it, you can't be sued by him for breaking GPL. That's what any linux distro and its mirrors are doing. The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. So, this is not some interpretation of the GPL by the FSF, and since it is written black on white in the actual GPL text, i don't think there is any doubt what a judge will decice : judge : so, to create this piece of work, what do you use to make modifications ? A (having sworn on the bible to say the truth and only the truth) : euh, some C or asm code, and a compiler or assembler to compile it. judge : and you did voluntarily place said code and distribute it under the GPL ? A : yes, it was going into the linux kernel, so ... judge : so you should distribute the source code to your work also, and distributing it under GPL is a breach of expectation from whoever you distribute it to. Or something such. Again, I'm not following. The author release the source under GPL. You can't release a binary under GPL, it makes no sense. So there's no "so you should distribute the source code to your work _also_". You released a software, it the form you claimed to be the source. You like LISP, you release it in LISP. You like C, you release it in C. You like hexcode, you release it in hexcode. No one can ask you to change it. You seems to keep forgetting what GPL is. It's a licence. The copyright holders grant some rights to third parties, _if_ they comply to some conditions. Conditions are all placed on the third parties, including the source disclosure one (source of _modifications_). There is no condition the _holders_ have to meet. It'd be a nonsense. The GPL says: "I grant you a right if you do this." and not: "I grant you a right if _I_ do this.". GPL doesn't backfire. Again, IANAL, but I see little room for "interpretation" here. If A is going to say that he is the only author, and that he would never sue because of this breach of the GPL, he could just as well have put it under a different licence, or put a small disclaimer about it, since we cannot really act as if we believed that A would never sue us, if he doesn't explicitly say so. No one will ever do that. If you are distributing the software I released under GPL, be sure I _will_ sue you if you break the licence. What do you want from me? A promise I won't sue you if you don't? That is implicit in the existance of the licence. Are you implying debian will stop distributing _any_ software unless the all the copyright holders of GPL software "explicitly say" they won't sue you? As an example, i package the unicorn driver for the bewan soft-ADSL pci and usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL emulating library, but are otherwise GPL, i discussed the matter with upstream, and after council from debian-legal, and possibly the FSF people themselves, we got to use this as GPL exception
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 12 Apr 2005, Sven Luther wrote: On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote: Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. The main problem is that i feel that those binary firmware copyright holders may have put it under the GPL, but i doubt they realize that this means they have to release the source code of said firmware blobs. They released it not in object format, but in the C language. An hexstring, agreed, but still C. The copyright holders can release their work how they please. If you think GPL can place restrictions on what they can do, please see below. Also, i believe you are wrong in the above, the only interpretation that is important is the one the judge will take in case someone goes to suing. Agreed, let me rephrase then. The only interpretation that is important _to the judge_ is the one of the parties involved. In any agreement, the parties express their will. Here, the holders wrote the agreement alone, so _their_ interpretation counts. That is, their interpretation as it was when they licenced the software. Not as is it after later thinking (or acquisition by some bad guy). And finally, if anyone could claim that a binary is the prefered form of modification, which is most of the time obviously false, then the GPL would be worthless. And anyway, the GPL states this (first paragraph after subclause c in clause 3) : I don't care about GPL being worthless. This is not the GPL advocacy list. I'm just saying that if you distribute the source in the form the author published it, you can't be sued by him for breaking GPL. That's what any linux distro and its mirrors are doing. The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. So, this is not some interpretation of the GPL by the FSF, and since it is written black on white in the actual GPL text, i don't think there is any doubt what a judge will decice : judge : so, to create this piece of work, what do you use to make modifications ? A (having sworn on the bible to say the truth and only the truth) : euh, some C or asm code, and a compiler or assembler to compile it. judge : and you did voluntarily place said code and distribute it under the GPL ? A : yes, it was going into the linux kernel, so ... judge : so you should distribute the source code to your work also, and distributing it under GPL is a breach of expectation from whoever you distribute it to. Or something such. Again, I'm not following. The author release the source under GPL. You can't release a binary under GPL, it makes no sense. So there's no so you should distribute the source code to your work _also_. You released a software, it the form you claimed to be the source. You like LISP, you release it in LISP. You like C, you release it in C. You like hexcode, you release it in hexcode. No one can ask you to change it. You seems to keep forgetting what GPL is. It's a licence. The copyright holders grant some rights to third parties, _if_ they comply to some conditions. Conditions are all placed on the third parties, including the source disclosure one (source of _modifications_). There is no condition the _holders_ have to meet. It'd be a nonsense. The GPL says: I grant you a right if you do this. and not: I grant you a right if _I_ do this.. GPL doesn't backfire. Again, IANAL, but I see little room for interpretation here. If A is going to say that he is the only author, and that he would never sue because of this breach of the GPL, he could just as well have put it under a different licence, or put a small disclaimer about it, since we cannot really act as if we believed that A would never sue us, if he doesn't explicitly say so. No one will ever do that. If you are distributing the software I released under GPL, be sure I _will_ sue you if you break the licence. What do you want from me? A promise I won't sue you if you don't? That is implicit in the existance of the licence. Are you implying debian will stop distributing _any_ software unless the all the copyright holders of GPL software explicitly say they won't sue you? As an example, i package the unicorn driver for the bewan soft-ADSL pci and usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL emulating library, but are otherwise GPL, i discussed the matter with upstream, and after council from debian-legal, and possibly the FSF people themselves, we got to use this as GPL exception : In addition, as a special exception, BeWAN systems gives permission
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005, Sven Luther wrote: On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote: In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. Well, i am not sure with your interpretation, but even if you where right, we have no guarantee that A will continue being lenient, and no guarantee that A will not start suing D or whoever for illegally distributing his stuff without sources. Let's keep things separated. I'm saying that the only one that may sue D is A, not C. If we agree on this, we may abandon the case of a third party sueing D. As for threats coming from A, IMHO D is safe as long as he distributes what A claims the source is, even if it's a hex string. In no world A can publicly state "this is the source" and then sue D because "no, that's not the source" (assuming D is copying it verbatim). So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A So, i get some random bit of GPLed software, i add a module or some code to it, i distribute that code in binary format only, and claim that i have used an hex editor to write it, or simply that it is the 'right' source. I have some serious doubts that i will not get sued by all the authors of the original GPLed work if i were to do that, and rightly so. No. Please don't throw irrelevant matters in. D is not modifing the software at all. D is a mere distributor. We're not addressing issues related to modification, since no one is going to modify the firmware anyway. This is not a general discussion on GPL. Issues related to modification do not belong to this thread, which already very close to off topic on l-k. Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Even in that case, you still need explicit permission of A, and all the other copyright holders of the rest of the GPLed work, to give you an explicit exception to link with this non-free bit of code. Yes, but it does not apply to our case here. There's no "all other copyright holders". _You_ stated that the firmware is included by mere aggregation, so there's no other holders involved. We're talking about the firmware case. A is one or two well identified subjects. And A wrote it is GPL'ed. Whether you agree or not, that's the licence A chose. A placed the copyright notice. The licence is a matter between A and D. A may sue D and D may (less likely) sue A, if conditions are not met. I'm not sure at all GPL is enforceable by D upon A. Let's assume it is, for sake of discussion, anyway. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. No. The source code is clearly the prefered form of modification, not some random intermediate state A may be claiming is source. In this context, it is. Only A may sue D for not distributing the source. Whatever D distributes, D has to make A happy. If A is happy with D distributing `dd if=/dev/random count=1` as source, no one can stop D from doing that. Keep in mind A is the copyright holder. He grants rights to third parties. No one but A can remove them. [...] I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 2005-04-11 at 18:25 +0200, Sven Luther wrote: > On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote: [...] > > A - is the Author (or rights owner) of the software (GPL'ed); > > B - is an user, who got the a copy of the software from A; > > C - is another user, who got a copy indirectly, that is from a > > distributor; > > D - is the distributor C got the copy from. [...] > > Now. It seems to me that the relationship between D (distributor) and C > > (target of the distribution) is _not_ regulated by GPL at all. GPL is a > > license, the _owner_ of the rights (A) and the recipient of some rights > > (C, as an user) are the only subjects. D _owns_ no rights on the > > software, so can't grant any to C. There's no GPL between D and C. > > I think you are missing the point. D get's a licence from A, the GPL, and this > licence includes a licence, not on use, but on redistribution, and the act of > D distributing the copy to C is covered by it. In a sense A allows D to > distribute the software under the GPL to C. Now, D is only allowed to do this > distribution if he also distribute the source code of it, which he can't do > for the firmware. I think only a lawyer can answer here. What I'm saying is that the license always comes from the copyright owner, that is A. Sublicensing is not covered by GPL. Distribution is not sublicensing. Quoting GPL itself: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. ... The wording is clear, the license is between A and C. There's no license between D and C. There's no way C can enforce anything on D (well, not on GPL basis). > Notice also the fact that there are so many contributors to the linux kernel > in effect means that there is nobody with the full rights as A, but only a > multitude of people in the D case. In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. > > So, even if C comes to think D is breaking GPL, all C can do is notify > > A. The GPL D is supposedly breaking is an agreement between A and D > > only. On which basis may C sue D? For breaking what agreement? It's up > > to A to sue D for breaking GPL. > > This is indeed an interpretation. I am not sure myself if a user receiving > GPLed software in binary only fashion as is the case here can sue either D or > A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Maybe mine it's only one interpretation. But I can't see any other. > Now you could argue that any number of authors of GPLed bits of the linux > kernel could sue D for distributing their software as a derived work of the > binary-only bit, and the fact that D doesn't distribute the source code to the > binary bit voids any other right allowed him by the GPL, and thus he has no > right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. > > What is the risk for D, if D is distributing the source of the software > > _exactly_ in the form A publicly provides it? It's not up to D to > > produce the source, all D has to do is to provide verbatim copies of > > it to anyone D distributes the software to, on request. > > Imagine one of those companies got bought up by some predatory company who > wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able > to sue for damage or prejudice or whatever. And given what i have heard about > the uncertainities of the Alteon ownership, this seems indeed like a plausible > scenario, which could result in a SCO bis case. I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in the first place, it's not D's fault for sure. Do you really think the following scenario is l
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
[I'm not subscribed, so this in not a real reply - sorry if it breaks threading somehow.] Sven Luther wrote: > The ftp-master are the ones reviewing the licencing problems, and they are the > ones handling the infrastructure, and putting their responsability on the > stake. If they feel that some piece of software has dubious legal issues which > come at a risk of having them personally come on the receiving end of a legal > case, then they will say, no, we don't distribute this software, and that is > the end of it. I've been following the whole discussion (including later messages), but I'm still missing one point. You seem to have investigated a lot on the subject, so I'll ask you. I don't get what real legal issues distributors may have. Let me explain with an example. Lets say: A - is the Author (or rights owner) of the software (GPL'ed); B - is an user, who got the a copy of the software from A; C - is another user, who got a copy indirectly, that is from a distributor; D - is the distributor C got the copy from. Now, IANAL at all. But it seems to me that B has the right to _use_ the software by means of GPL. As long as A thinks B doesn't break GPL, B is fine. All B needs to do is to fulfill GPL conditions (as a user, there's little to do). C also has the right to use the software, in a very similar way. As long as A thinks C doesn't break GPL, C is fine. D has the right to distribute the software, under GPL terms. As long as A thinks D doesn't break GPL, D is fine. Now. It seems to me that the relationship between D (distributor) and C (target of the distribution) is _not_ regulated by GPL at all. GPL is a license, the _owner_ of the rights (A) and the recipient of some rights (C, as an user) are the only subjects. D _owns_ no rights on the software, so can't grant any to C. There's no GPL between D and C. So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. What is the risk for D, if D is distributing the source of the software _exactly_ in the form A publicly provides it? It's not up to D to produce the source, all D has to do is to provide verbatim copies of it to anyone D distributes the software to, on request. Does is really matter if C thinks the source being incomplete, or missing? C can take the issue up with A (by means of the GPL that exists between A and C), but not with D, since there's no GPL between D and C. C is in the same position of B. If the source is incomplete, they may ask A to comply to the GPL, but not D. D made no promises to them. So, as long as they don't modify the source, distributors are safe. No one can ask them to provide the "right" source, but A. And "right" means "right for A", of course, when it's A asking, by definition. What am I missing? TIA, .TM. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
[I'm not subscribed, so this in not a real reply - sorry if it breaks threading somehow.] Sven Luther wrote: The ftp-master are the ones reviewing the licencing problems, and they are the ones handling the infrastructure, and putting their responsability on the stake. If they feel that some piece of software has dubious legal issues which come at a risk of having them personally come on the receiving end of a legal case, then they will say, no, we don't distribute this software, and that is the end of it. I've been following the whole discussion (including later messages), but I'm still missing one point. You seem to have investigated a lot on the subject, so I'll ask you. I don't get what real legal issues distributors may have. Let me explain with an example. Lets say: A - is the Author (or rights owner) of the software (GPL'ed); B - is an user, who got the a copy of the software from A; C - is another user, who got a copy indirectly, that is from a distributor; D - is the distributor C got the copy from. Now, IANAL at all. But it seems to me that B has the right to _use_ the software by means of GPL. As long as A thinks B doesn't break GPL, B is fine. All B needs to do is to fulfill GPL conditions (as a user, there's little to do). C also has the right to use the software, in a very similar way. As long as A thinks C doesn't break GPL, C is fine. D has the right to distribute the software, under GPL terms. As long as A thinks D doesn't break GPL, D is fine. Now. It seems to me that the relationship between D (distributor) and C (target of the distribution) is _not_ regulated by GPL at all. GPL is a license, the _owner_ of the rights (A) and the recipient of some rights (C, as an user) are the only subjects. D _owns_ no rights on the software, so can't grant any to C. There's no GPL between D and C. So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. What is the risk for D, if D is distributing the source of the software _exactly_ in the form A publicly provides it? It's not up to D to produce the source, all D has to do is to provide verbatim copies of it to anyone D distributes the software to, on request. Does is really matter if C thinks the source being incomplete, or missing? C can take the issue up with A (by means of the GPL that exists between A and C), but not with D, since there's no GPL between D and C. C is in the same position of B. If the source is incomplete, they may ask A to comply to the GPL, but not D. D made no promises to them. So, as long as they don't modify the source, distributors are safe. No one can ask them to provide the right source, but A. And right means right for A, of course, when it's A asking, by definition. What am I missing? TIA, .TM. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 2005-04-11 at 18:25 +0200, Sven Luther wrote: On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote: [...] A - is the Author (or rights owner) of the software (GPL'ed); B - is an user, who got the a copy of the software from A; C - is another user, who got a copy indirectly, that is from a distributor; D - is the distributor C got the copy from. [...] Now. It seems to me that the relationship between D (distributor) and C (target of the distribution) is _not_ regulated by GPL at all. GPL is a license, the _owner_ of the rights (A) and the recipient of some rights (C, as an user) are the only subjects. D _owns_ no rights on the software, so can't grant any to C. There's no GPL between D and C. I think you are missing the point. D get's a licence from A, the GPL, and this licence includes a licence, not on use, but on redistribution, and the act of D distributing the copy to C is covered by it. In a sense A allows D to distribute the software under the GPL to C. Now, D is only allowed to do this distribution if he also distribute the source code of it, which he can't do for the firmware. I think only a lawyer can answer here. What I'm saying is that the license always comes from the copyright owner, that is A. Sublicensing is not covered by GPL. Distribution is not sublicensing. Quoting GPL itself: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. ... The wording is clear, the license is between A and C. There's no license between D and C. There's no way C can enforce anything on D (well, not on GPL basis). Notice also the fact that there are so many contributors to the linux kernel in effect means that there is nobody with the full rights as A, but only a multitude of people in the D case. In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Maybe mine it's only one interpretation. But I can't see any other. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. What is the risk for D, if D is distributing the source of the software _exactly_ in the form A publicly provides it? It's not up to D to produce the source, all D has to do is to provide verbatim copies of it to anyone D distributes the software to, on request. Imagine one of those companies got bought up by some predatory company who wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able to sue for damage or prejudice or whatever. And given what i have heard about the uncertainities of the Alteon ownership, this seems indeed like a plausible scenario, which could result in a SCO bis case. I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in the first place, it's not D's fault for sure. Do you really think the following scenario is likely: A to D: you must distribute the complete source, or the license will be terminated! D to A: gimme the complete source, and I'll distribute it. A to D: no, I'm not willing to give you the full source of my firmware, but you
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005, Sven Luther wrote: On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote: In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. Well, i am not sure with your interpretation, but even if you where right, we have no guarantee that A will continue being lenient, and no guarantee that A will not start suing D or whoever for illegally distributing his stuff without sources. Let's keep things separated. I'm saying that the only one that may sue D is A, not C. If we agree on this, we may abandon the case of a third party sueing D. As for threats coming from A, IMHO D is safe as long as he distributes what A claims the source is, even if it's a hex string. In no world A can publicly state this is the source and then sue D because no, that's not the source (assuming D is copying it verbatim). So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A So, i get some random bit of GPLed software, i add a module or some code to it, i distribute that code in binary format only, and claim that i have used an hex editor to write it, or simply that it is the 'right' source. I have some serious doubts that i will not get sued by all the authors of the original GPLed work if i were to do that, and rightly so. No. Please don't throw irrelevant matters in. D is not modifing the software at all. D is a mere distributor. We're not addressing issues related to modification, since no one is going to modify the firmware anyway. This is not a general discussion on GPL. Issues related to modification do not belong to this thread, which already very close to off topic on l-k. Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Even in that case, you still need explicit permission of A, and all the other copyright holders of the rest of the GPLed work, to give you an explicit exception to link with this non-free bit of code. Yes, but it does not apply to our case here. There's no all other copyright holders. _You_ stated that the firmware is included by mere aggregation, so there's no other holders involved. We're talking about the firmware case. A is one or two well identified subjects. And A wrote it is GPL'ed. Whether you agree or not, that's the licence A chose. A placed the copyright notice. The licence is a matter between A and D. A may sue D and D may (less likely) sue A, if conditions are not met. I'm not sure at all GPL is enforceable by D upon A. Let's assume it is, for sake of discussion, anyway. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. No. The source code is clearly the prefered form of modification, not some random intermediate state A may be claiming is source. In this context, it is. Only A may sue D for not distributing the source. Whatever D distributes, D has to make A happy. If A is happy with D distributing `dd if=/dev/random count=1` as source, no one can stop D from doing that. Keep in mind A is the copyright holder. He grants rights to third parties. No one but A can remove them. [...] I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source
Re: VM Requirement Document - v0.0
On Tue, 3 Jul 2001, Daniel Phillips wrote: > On Tuesday 03 July 2001 12:33, Marco Colombo wrote: > > Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only > > when background aging, maybe it's not enough to keep processes like > > updatedb from causing interactive pages to be evicted. > > That's why I said we should have another way to detect that kind of > > activity... well, the application could just let us know (no need to > > embed an autotuning-genetic-page-replacement-optimizer into the kernel). > > We should just drop all FS metadata accessed by updatedb, since we > > know that's one-shot only, without raising pressure at all. > > Note that some of updatedb's metadata pages are of the accessed-often kind, > e.g., directory blocks and inodes. A blanket low priority on all the pages > updatedb touches just won't do. Remember that the first message was about a laptop. At 4:00AM there's no activity but the updatedb one (and the other cron jobs). Simply, there's no 'accessed-often' data. Moreover, I'd bet that 90% of the metadata touched by updatedb won't be accessed at all in the future. Laptop users don't do find /usr/share/terminfo/ so often. > > Just like > > (not that I'm proposing it) putting those "one-shot" pages directly on > > the inactive-clean list instead of the active list. How an application > > could declare such a behaviour is an open question, of course. Maybe it's > > even possible to detect it. And BTW that's really fine tuning. > > Evicting an 8 hours old page may be a mistake sometime, but it's never > > a *big* mistake. > > IMHO, updatedb *should* evict all the "interactive" pages that aren't > actually doing anything[1]. That way it should run faster, provided of > course its accessed-once pages are properly given low priority. So in the morning you find your Gnome session completely on swap, and at the same time a lot of free mem. > I see three page priority levels: > > 0 - accessed-never/aged to zero > 1 - accessed-once/just loaded > 2 - accessed-often > > with these transitions: > > 0 -> 1, if a page is accessed > 1 -> 2, if a page is accessed a second time > 1 -> 0, if a page gets old > 2 -> 0, if a page gets old > > The 0 and 1 level pages are on a fifo queue, the 2 level pages are scanned > clock-wise, relying on the age computation[2]. Eviction candidates are taken > from the cold end of the 0 level list, unless it is empty, in which case they > are taken from the 1 level list. In desperation, eviction candidates are > taken from the 2 level list, i.e., random eviction policy, as opposed to what > we do now which is to initiate an emergency scan of the active list for new > inactive candidates - rather like calling a quick board meeting when the > building is on fire. Well, it's just aging faster when it's needed. Random evicting is not good. List 2 is ordered by age, and there're always better candidates at the end of the list than at the front. The higher the pressure, the shorter is the time a page has to rest idle to get at the end of the list. But the list *is* ordered. > Note that the above is only a very slight departure from the current design. > And by the way, this is just brainstorming, it hasn't reached the 'proposal' > stage yet. > > [1] It would be nice to have a mechanism whereby the evicted 'interactive' > pages are automatically reloaded when updatedb has finished its work. This > is a case of scavenging unused disk bandwidth for something useful, i.e., > improving the interactive experience. updatedb doesn't really need all the memory it takes. All it needs is a small buffer to sequentially scan all the disk. So we should just drop all the pages it references, since we already know they won't be referenced again by noone else. > [2] I much prefer the hot/cold terminology over old/young. The latter gets > confusing because a 'high' age is 'young'. I'd rather think of a high value > as being 'hot'. True. s/page->age/page->temp/g B-) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Tue, 3 Jul 2001, Daniel Phillips wrote: > On Monday 02 July 2001 20:42, Rik van Riel wrote: > > On Thu, 28 Jun 2001, Marco Colombo wrote: > > > I'm not sure that, in general, recent pages with only one access are > > > still better eviction candidates compared to 8 hours old pages. Here > > > we need either another way to detect one-shot activity (like the one > > > performed by updatedb), > > > > Fully agreed, but there is one problem with this idea. > > Suppose you have a maximum of 20% of your RAM for these > > "one-shot" things, now how are you going to be able to > > page in an application with a working set of, say, 25% > > the size of RAM ? > > Easy. What's the definition of working set? Those pages that are frequently > referenced. So as the application starts up some of its pages will get > promoted from used-once to used-often. (On the other hand, the target > behavior here conflicts with the goal of grouping together several > temporally-related accesses to the same page together as one access, so > there's a subtle distinction to be made here, see below.) [...] In Rik example, the ws is larger than available memory. Part of it (the "hottest" one) will get double-accesses, but other pages will keep condending the few available (physical) pages with no chance of being accessed twice. But see my previous posting... .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Tue, 3 Jul 2001, Daniel Phillips wrote: On Monday 02 July 2001 20:42, Rik van Riel wrote: On Thu, 28 Jun 2001, Marco Colombo wrote: I'm not sure that, in general, recent pages with only one access are still better eviction candidates compared to 8 hours old pages. Here we need either another way to detect one-shot activity (like the one performed by updatedb), Fully agreed, but there is one problem with this idea. Suppose you have a maximum of 20% of your RAM for these one-shot things, now how are you going to be able to page in an application with a working set of, say, 25% the size of RAM ? Easy. What's the definition of working set? Those pages that are frequently referenced. So as the application starts up some of its pages will get promoted from used-once to used-often. (On the other hand, the target behavior here conflicts with the goal of grouping together several temporally-related accesses to the same page together as one access, so there's a subtle distinction to be made here, see below.) [...] In Rik example, the ws is larger than available memory. Part of it (the hottest one) will get double-accesses, but other pages will keep condending the few available (physical) pages with no chance of being accessed twice. But see my previous posting... .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Tue, 3 Jul 2001, Daniel Phillips wrote: On Tuesday 03 July 2001 12:33, Marco Colombo wrote: Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only when background aging, maybe it's not enough to keep processes like updatedb from causing interactive pages to be evicted. That's why I said we should have another way to detect that kind of activity... well, the application could just let us know (no need to embed an autotuning-genetic-page-replacement-optimizer into the kernel). We should just drop all FS metadata accessed by updatedb, since we know that's one-shot only, without raising pressure at all. Note that some of updatedb's metadata pages are of the accessed-often kind, e.g., directory blocks and inodes. A blanket low priority on all the pages updatedb touches just won't do. Remember that the first message was about a laptop. At 4:00AM there's no activity but the updatedb one (and the other cron jobs). Simply, there's no 'accessed-often' data. Moreover, I'd bet that 90% of the metadata touched by updatedb won't be accessed at all in the future. Laptop users don't do find /usr/share/terminfo/ so often. Just like (not that I'm proposing it) putting those one-shot pages directly on the inactive-clean list instead of the active list. How an application could declare such a behaviour is an open question, of course. Maybe it's even possible to detect it. And BTW that's really fine tuning. Evicting an 8 hours old page may be a mistake sometime, but it's never a *big* mistake. IMHO, updatedb *should* evict all the interactive pages that aren't actually doing anything[1]. That way it should run faster, provided of course its accessed-once pages are properly given low priority. So in the morning you find your Gnome session completely on swap, and at the same time a lot of free mem. I see three page priority levels: 0 - accessed-never/aged to zero 1 - accessed-once/just loaded 2 - accessed-often with these transitions: 0 - 1, if a page is accessed 1 - 2, if a page is accessed a second time 1 - 0, if a page gets old 2 - 0, if a page gets old The 0 and 1 level pages are on a fifo queue, the 2 level pages are scanned clock-wise, relying on the age computation[2]. Eviction candidates are taken from the cold end of the 0 level list, unless it is empty, in which case they are taken from the 1 level list. In desperation, eviction candidates are taken from the 2 level list, i.e., random eviction policy, as opposed to what we do now which is to initiate an emergency scan of the active list for new inactive candidates - rather like calling a quick board meeting when the building is on fire. Well, it's just aging faster when it's needed. Random evicting is not good. List 2 is ordered by age, and there're always better candidates at the end of the list than at the front. The higher the pressure, the shorter is the time a page has to rest idle to get at the end of the list. But the list *is* ordered. Note that the above is only a very slight departure from the current design. And by the way, this is just brainstorming, it hasn't reached the 'proposal' stage yet. [1] It would be nice to have a mechanism whereby the evicted 'interactive' pages are automatically reloaded when updatedb has finished its work. This is a case of scavenging unused disk bandwidth for something useful, i.e., improving the interactive experience. updatedb doesn't really need all the memory it takes. All it needs is a small buffer to sequentially scan all the disk. So we should just drop all the pages it references, since we already know they won't be referenced again by noone else. [2] I much prefer the hot/cold terminology over old/young. The latter gets confusing because a 'high' age is 'young'. I'd rather think of a high value as being 'hot'. True. s/page-age/page-temp/g B-) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Mon, 2 Jul 2001, Rik van Riel wrote: > On Thu, 28 Jun 2001, Marco Colombo wrote: > > > I'm not sure that, in general, recent pages with only one access are > > still better eviction candidates compared to 8 hours old pages. Here > > we need either another way to detect one-shot activity (like the one > > performed by updatedb), > > Fully agreed, but there is one problem with this idea. > Suppose you have a maximum of 20% of your RAM for these > "one-shot" things, now how are you going to be able to > page in an application with a working set of, say, 25% > the size of RAM ? > > If you don't have any special measures, the pages from > this "new" application will always be treated as one-shot > pages and the process will never be able to be cached in > memory completely... I see your point. Running Gnome on a 64MB box means you have most of the pages that are "warm" (using my definition), so there's little room for "cold" (new) pages, and maybe they don't get a chance of being accessed a second time before they are evicted, which leads to thrashing if you're trying to start something really big (well, I guess the access pattern within a typical ws is not uniformly distributed, so some pages will get accessed twice, but I see the problem). I'll try and make my point a bit clearer. I was referring to background aging only. When aging is caused by pressure, you don't make any difference between pages. I don't know how the idea to give high values for page->age on the second access instead of the first is going to be implemented, but I'm assuming that new pages are going to be placed on the active list with a low age value (PAGE_AGE_START_FIRST ?), maybe even 0 (well, I'm not a guru of course). I'm just saying that, to avoid Mike's "problem" (which BTW I don't believe is a big one, really), we could stop background aging on interactive pages (short form for "pages that belong to the ws of an interactive process") at a certain miminum age, say PAGE_AGE_BG_INTERACTIVE_MINIMUM, with PAGE_AGE_BG_INTERACTIVE_MINIMUM > PAGE_AGE_START_FIRST). Weighting the difference between the two ages, you can give long-standing interactive pages some advantage vs new pages. But they will be aged below PAGE_AGE_START_FIRST and eventually moved to the inactive list. After all, they *are* good candidates. Does this make some sense? Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only when background aging, maybe it's not enough to keep processes like updatedb from causing interactive pages to be evicted. That's why I said we should have another way to detect that kind of activity... well, the application could just let us know (no need to embed an autotuning-genetic-page-replacement-optimizer into the kernel). We should just drop all FS metadata accessed by updatedb, since we know that's one-shot only, without raising pressure at all. Just like (not that I'm proposing it) putting those "one-shot" pages directly on the inactive-clean list instead of the active list. How an application could declare such a behaviour is an open question, of course. Maybe it's even possible to detect it. And BTW that's really fine tuning. Evicting an 8 hours old page may be a mistake sometime, but it's never a *big* mistake. > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ http://distro.conectiva.com/ > > Send all your spam to [EMAIL PROTECTED] (spam digging piggy) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Mon, 2 Jul 2001, Rik van Riel wrote: On Thu, 28 Jun 2001, Marco Colombo wrote: I'm not sure that, in general, recent pages with only one access are still better eviction candidates compared to 8 hours old pages. Here we need either another way to detect one-shot activity (like the one performed by updatedb), Fully agreed, but there is one problem with this idea. Suppose you have a maximum of 20% of your RAM for these one-shot things, now how are you going to be able to page in an application with a working set of, say, 25% the size of RAM ? If you don't have any special measures, the pages from this new application will always be treated as one-shot pages and the process will never be able to be cached in memory completely... I see your point. Running Gnome on a 64MB box means you have most of the pages that are warm (using my definition), so there's little room for cold (new) pages, and maybe they don't get a chance of being accessed a second time before they are evicted, which leads to thrashing if you're trying to start something really big (well, I guess the access pattern within a typical ws is not uniformly distributed, so some pages will get accessed twice, but I see the problem). I'll try and make my point a bit clearer. I was referring to background aging only. When aging is caused by pressure, you don't make any difference between pages. I don't know how the idea to give high values for page-age on the second access instead of the first is going to be implemented, but I'm assuming that new pages are going to be placed on the active list with a low age value (PAGE_AGE_START_FIRST ?), maybe even 0 (well, I'm not a guru of course). I'm just saying that, to avoid Mike's problem (which BTW I don't believe is a big one, really), we could stop background aging on interactive pages (short form for pages that belong to the ws of an interactive process) at a certain miminum age, say PAGE_AGE_BG_INTERACTIVE_MINIMUM, with PAGE_AGE_BG_INTERACTIVE_MINIMUM PAGE_AGE_START_FIRST). Weighting the difference between the two ages, you can give long-standing interactive pages some advantage vs new pages. But they will be aged below PAGE_AGE_START_FIRST and eventually moved to the inactive list. After all, they *are* good candidates. Does this make some sense? Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only when background aging, maybe it's not enough to keep processes like updatedb from causing interactive pages to be evicted. That's why I said we should have another way to detect that kind of activity... well, the application could just let us know (no need to embed an autotuning-genetic-page-replacement-optimizer into the kernel). We should just drop all FS metadata accessed by updatedb, since we know that's one-shot only, without raising pressure at all. Just like (not that I'm proposing it) putting those one-shot pages directly on the inactive-clean list instead of the active list. How an application could declare such a behaviour is an open question, of course. Maybe it's even possible to detect it. And BTW that's really fine tuning. Evicting an 8 hours old page may be a mistake sometime, but it's never a *big* mistake. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Thu, 28 Jun 2001, Daniel Phillips wrote: > On Thursday 28 June 2001 14:20, [EMAIL PROTECTED] wrote: > > > If individual pages could be classified as code (text segments), > > > data, file cache, and so on, I would specify costs to the paging > > > of such pages in or out. This way I can make the system perfer > > > to drop a file cache page that has not been accessed for five > > > minutes, over a program text page that has not been acccessed > > > for one hour (or much more). > > > > This would be extremely useful. My laptop has 256mb of ram, but every day > > it runs the updatedb for locate. This fills the memory with the file > > cache. Interactivity is then terrible, and swap is unnecessarily used. On > > the laptop all this hard drive thrashing is bad news for battery life > > (plus the fact that laptop hard drives are not the fastest around). I > > purposely do not run more applications than can comfortably fit in the > > 256mb of memory. > > > > If fact, to get interactivity back, I've got a small 10 liner that mallocs > > memory to *force* stuff into swap purely so I can have a large block of > > memory back for interactivity. > > > > Something simple that did "you haven't used this file for 30mins, flush it > > out of the cache would be sufficient" > > Updatedb fills memory full of clean file pages so there's nothing to flush. > Did you mean "evict"? Well, I believe all inodes get dirtied for access time update, unless the FS is mounted no_atime. And it does write its database file... > Roughly speaking we treat clean pages as "instantly relaimable". Eviction > and reclaiming are done in the same step (look at reclaim_page). The key to > efficient mm is nothing more or less than choosing the best victim for > reclaiming and we aren't doing a spectacularly good job of that right now. > > There is a simple change in strategy that will fix up the updatedb case quite > nicely, it goes something like this: a single access to a page (e.g., reading > it) isn't enough to bring it to the front of the LRU queue, but accessing it > twice or more is. This is being looked at. You mean that pages that belong to interactive applications (working sets) won't be evicted to make room for the cache? And that pages just filled with data read by updatedb will be chosen instead (a kind of drop-behind)? There's nothing really wrong in the kernel "swapping out" interactive applications at 4 a.m., their pages have the property of both not being accessed recently and (the kernel doesn't know, of course) not going to be useful in the near future (say for another 4 hours). In the end they *are* good canditates for eviction. > Note that we don't actually use a LRU queue, we use a more efficient > approximation called aging, so the above is not a recipe for implementation. I'm not sure that, in general, recent pages with only one access are still better eviction candidates compared to 8 hours old pages. Here we need either another way to detect one-shot activity (like the one performed by updatedb), or to keep pages that belong to the working set of interactive processes somewhat "warm", and never let them age too much. A page with one one (read) access can be "cold". A page with more than one access becomes "hot". Aging moves page towards the "cold" state, and of course "cold" pages are the best candidates for eviction. Pages belonging to interactive processes are never moved from the "warm" state into the "cold" state by the background aging. Maybe this can be implemented just leaving such pages on the active list, and deactivating them only on pressure. Or not leaving their age reach 0. (Well, i'm not really into current VM implementation. I guess that those single access pages will be placed on the end of the active list with age 0, or something like that). If I understand the current VM code, after 8 hours of idle time, all pages of interactive applications will be on the inactive(_clean?) list, ready for eviction. Even if you place new pages (the updatedb activity) at the *end* of the active list, (instead of the front), it won't be enough to prevent application pages from being evicted. It won't solve Mike's problem, that is. > > -- > Daniel > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Thu, 28 Jun 2001, Daniel Phillips wrote: On Thursday 28 June 2001 14:20, [EMAIL PROTECTED] wrote: If individual pages could be classified as code (text segments), data, file cache, and so on, I would specify costs to the paging of such pages in or out. This way I can make the system perfer to drop a file cache page that has not been accessed for five minutes, over a program text page that has not been acccessed for one hour (or much more). This would be extremely useful. My laptop has 256mb of ram, but every day it runs the updatedb for locate. This fills the memory with the file cache. Interactivity is then terrible, and swap is unnecessarily used. On the laptop all this hard drive thrashing is bad news for battery life (plus the fact that laptop hard drives are not the fastest around). I purposely do not run more applications than can comfortably fit in the 256mb of memory. If fact, to get interactivity back, I've got a small 10 liner that mallocs memory to *force* stuff into swap purely so I can have a large block of memory back for interactivity. Something simple that did you haven't used this file for 30mins, flush it out of the cache would be sufficient Updatedb fills memory full of clean file pages so there's nothing to flush. Did you mean evict? Well, I believe all inodes get dirtied for access time update, unless the FS is mounted no_atime. And it does write its database file... Roughly speaking we treat clean pages as instantly relaimable. Eviction and reclaiming are done in the same step (look at reclaim_page). The key to efficient mm is nothing more or less than choosing the best victim for reclaiming and we aren't doing a spectacularly good job of that right now. There is a simple change in strategy that will fix up the updatedb case quite nicely, it goes something like this: a single access to a page (e.g., reading it) isn't enough to bring it to the front of the LRU queue, but accessing it twice or more is. This is being looked at. You mean that pages that belong to interactive applications (working sets) won't be evicted to make room for the cache? And that pages just filled with data read by updatedb will be chosen instead (a kind of drop-behind)? There's nothing really wrong in the kernel swapping out interactive applications at 4 a.m., their pages have the property of both not being accessed recently and (the kernel doesn't know, of course) not going to be useful in the near future (say for another 4 hours). In the end they *are* good canditates for eviction. Note that we don't actually use a LRU queue, we use a more efficient approximation called aging, so the above is not a recipe for implementation. I'm not sure that, in general, recent pages with only one access are still better eviction candidates compared to 8 hours old pages. Here we need either another way to detect one-shot activity (like the one performed by updatedb), or to keep pages that belong to the working set of interactive processes somewhat warm, and never let them age too much. A page with one one (read) access can be cold. A page with more than one access becomes hot. Aging moves page towards the cold state, and of course cold pages are the best candidates for eviction. Pages belonging to interactive processes are never moved from the warm state into the cold state by the background aging. Maybe this can be implemented just leaving such pages on the active list, and deactivating them only on pressure. Or not leaving their age reach 0. (Well, i'm not really into current VM implementation. I guess that those single access pages will be placed on the end of the active list with age 0, or something like that). If I understand the current VM code, after 8 hours of idle time, all pages of interactive applications will be on the inactive(_clean?) list, ready for eviction. Even if you place new pages (the updatedb activity) at the *end* of the active list, (instead of the front), it won't be enough to prevent application pages from being evicted. It won't solve Mike's problem, that is. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Tue, 26 Jun 2001, Rik van Riel wrote: > On Tue, 26 Jun 2001, John Stoffel wrote: > > > >> * If we're getting low cache hit rates, don't flush > > >> processes to swap. > > >> * If we're getting good cache hit rates, flush old, idle > > >> processes to swap. > > > > Rik> ... but I fail to see this one. If we get a low cache hit rate, > > Rik> couldn't that just mean we allocated too little memory for the > > Rik> cache ? > > > > Or that we're doing big sequential reads of file(s) which are > > larger than memory, in which case expanding the cache size buys > > us nothing, and can actually hurt us alot. > > That's a big "OR". I think we should have an algorithm to > see which of these two is the case, otherwise we're just > making the wrong decision half of the time. > > Also, in many systems we'll be doing IO on _multiple_ files > at the same time, so I guess this will have to be a file-by-file > decision. Of course, you can always think of a "bad" behaviour. That should really be a page-by-page decision. An application may have both data and meta-data on the same file. You want to keep the metadata on core (think of access by an index, it's much better if all the index is there, even some unused parts) *and* cache commonly used data (that's just a cache of hot objects, normal replacement algoriths may be used) *and* drop-behind data on sequential scans... trying to understand what an application is doing, in order to foresee what it will be doing, it's bad attitude. Let's give an application writer a way to code it sanely (setting per-file VM attributes is fine). If an application is not friendly (gives no hints on its VM behaviour) just punish it. I mean, when tuning the VM behaviour, system health and friendly applications performance are the goals - do whatever necessary to preserve them, even kill the offender and rm its executable if someone it's running it again (*grin*) B-). .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
On 27 Jun 2001, David Wagner wrote: > H. Peter Anvin wrote: > >By author:Jorgen Cederlof <[EMAIL PROTECTED]> > >> If we only allow user chroots for processes that have never been > >> chrooted before, and if the suid/sgid bits won't have any effect under > >> the new root, it should be perfectly safe to allow any user to chroot. > > > >Safe, perhaps, but also completely useless: there is no way the user > >can set up a functional environment inside the chroot. > > Why is it useless? It sounds useful to me, on first glance. If I want > to run a user-level network daemon I don't trust (for instance, fingerd), > isolating it in a chroot area sounds pretty nice: If there is a buffer > overrun in the daemon, you can get some protection [*] against the rest > of your system being trashed. Am I missing something obvious? Just write a small program that chroots, drop privileges, and execs the untrusted daemon. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: When the FUD is all around (sniff).
On Tue, 26 Jun 2001, Alan Cox wrote:
> > I suppose they received some pression from M$, but if people read of a FUD
> > from a M$ employed, then they can guess what is going on, if it is a
> > newspaper usually telling facts in a correct way...
>
> It is common for newspaper staff to be corrupt, same with magazine people.
> Sometimes because people generally believe in a cause and are not impartial
> (which I've seen both pro and anti Linux btw) and sometimes because advertising
> revenue is a good thing.
>
> > The situation is going to be sad
>
> There is a saying in he UK 'You can fool all of the people some of the time,
> you can fool some of the people all the time, but you cannot fool all of the
> people all of the time'. You only have to look at the incredibly dim view
> technical people take of most printed reviews to see that.
>
> Alan
The problem here is the audience. That was on a major Italian newspaper,
and targeted to business people. This is not technical FUD you can find
on some magazines ("NT is faster" and so on). I personally don't care
a bit, I've enough arguments to turn it into a holy war, at least.
But the article summary could be: "Microsoft legal problems are going to
end, Linus' ones are just starting." A clear message to IT managers who
are about to decide how to invest thier IT budget.
As for the saying, see http://finance.yahoo.com/q?s=MSFT, and take 2 seconds
to realize what that exactly means (both as a fact and as concept)
and reconsider the part "but you cannot fool all of the people
all of the time" (just s/people/business people/ and re-read). B-)
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [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: When the FUD is all around (sniff).
On Tue, 26 Jun 2001, Alan Cox wrote: I suppose they received some pression from M$, but if people read of a FUD from a M$ employed, then they can guess what is going on, if it is a newspaper usually telling facts in a correct way... It is common for newspaper staff to be corrupt, same with magazine people. Sometimes because people generally believe in a cause and are not impartial (which I've seen both pro and anti Linux btw) and sometimes because advertising revenue is a good thing. The situation is going to be sad There is a saying in he UK 'You can fool all of the people some of the time, you can fool some of the people all the time, but you cannot fool all of the people all of the time'. You only have to look at the incredibly dim view technical people take of most printed reviews to see that. Alan The problem here is the audience. That was on a major Italian newspaper, and targeted to business people. This is not technical FUD you can find on some magazines (NT is faster and so on). I personally don't care a bit, I've enough arguments to turn it into a holy war, at least. But the article summary could be: Microsoft legal problems are going to end, Linus' ones are just starting. A clear message to IT managers who are about to decide how to invest thier IT budget. As for the saying, see http://finance.yahoo.com/q?s=MSFT, and take 2 seconds to realize what that exactly means (both as a fact and as concept) and reconsider the part but you cannot fool all of the people all of the time (just s/people/business people/ and re-read). B-) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] User chroot
On 27 Jun 2001, David Wagner wrote: H. Peter Anvin wrote: By author:Jorgen Cederlof [EMAIL PROTECTED] If we only allow user chroots for processes that have never been chrooted before, and if the suid/sgid bits won't have any effect under the new root, it should be perfectly safe to allow any user to chroot. Safe, perhaps, but also completely useless: there is no way the user can set up a functional environment inside the chroot. Why is it useless? It sounds useful to me, on first glance. If I want to run a user-level network daemon I don't trust (for instance, fingerd), isolating it in a chroot area sounds pretty nice: If there is a buffer overrun in the daemon, you can get some protection [*] against the rest of your system being trashed. Am I missing something obvious? Just write a small program that chroots, drop privileges, and execs the untrusted daemon. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: VM Requirement Document - v0.0
On Tue, 26 Jun 2001, Rik van Riel wrote: On Tue, 26 Jun 2001, John Stoffel wrote: * If we're getting low cache hit rates, don't flush processes to swap. * If we're getting good cache hit rates, flush old, idle processes to swap. Rik ... but I fail to see this one. If we get a low cache hit rate, Rik couldn't that just mean we allocated too little memory for the Rik cache ? Or that we're doing big sequential reads of file(s) which are larger than memory, in which case expanding the cache size buys us nothing, and can actually hurt us alot. That's a big OR. I think we should have an algorithm to see which of these two is the case, otherwise we're just making the wrong decision half of the time. Also, in many systems we'll be doing IO on _multiple_ files at the same time, so I guess this will have to be a file-by-file decision. Of course, you can always think of a bad behaviour. That should really be a page-by-page decision. An application may have both data and meta-data on the same file. You want to keep the metadata on core (think of access by an index, it's much better if all the index is there, even some unused parts) *and* cache commonly used data (that's just a cache of hot objects, normal replacement algoriths may be used) *and* drop-behind data on sequential scans... trying to understand what an application is doing, in order to foresee what it will be doing, it's bad attitude. Let's give an application writer a way to code it sanely (setting per-file VM attributes is fine). If an application is not friendly (gives no hints on its VM behaviour) just punish it. I mean, when tuning the VM behaviour, system health and friendly applications performance are the goals - do whatever necessary to preserve them, even kill the offender and rm its executable if someone it's running it again (*grin*) B-). .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: Controversy over dynamic linking -- how to end the panic
On Thu, 21 Jun 2001, Alan Cox wrote: > > 1) Oracle Corp. builds their database for Linux on a Linux system. > > 2) Said system comes with standard header files, which happen in this case to > >be GPL'd header files. > > 3) Oracle Corp.'s database becomes GPL. > > > > There's not a court in the civilised world that would uphold the GPL in that > > scenario. > > Yes but the concern is the USA 8) Pardon me, but what does "Oracle Corp.'s database becomes GPL" mean in the above 3)? (I'm asking to you since you seem to agree). Even if the database is found to be linked with a GPLed piece of SW, this doesn't make it (the database) GPLed, it just breaks Oracle's licence on the GPL SW. They only have to recompile their program against non-GPLed code (e.g. rewrite that part from scratch) and redistribute it. That's not like everyone going to Oracle and say "Your SW is now GPLed, hand me the Source. Resistance is Futile." ... GPL has a viral behaviour iff you want to keep using the GPLed part that you included, or am I missing something? .TM. -- ____/ / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [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: Controversy over dynamic linking -- how to end the panic
On Thu, 21 Jun 2001, Alan Cox wrote: 1) Oracle Corp. builds their database for Linux on a Linux system. 2) Said system comes with standard header files, which happen in this case to be GPL'd header files. 3) Oracle Corp.'s database becomes GPL. There's not a court in the civilised world that would uphold the GPL in that scenario. Yes but the concern is the USA 8) Pardon me, but what does Oracle Corp.'s database becomes GPL mean in the above 3)? (I'm asking to you since you seem to agree). Even if the database is found to be linked with a GPLed piece of SW, this doesn't make it (the database) GPLed, it just breaks Oracle's licence on the GPL SW. They only have to recompile their program against non-GPLed code (e.g. rewrite that part from scratch) and redistribute it. That's not like everyone going to Oracle and say Your SW is now GPLed, hand me the Source. Resistance is Futile. ... GPL has a viral behaviour iff you want to keep using the GPLed part that you included, or am I missing something? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, 23 Mar 2001, Jonathan Morton wrote: > >The main point is letting malloc fail when the memory cannot be > >guaranteed. > > If I read various things correctly, malloc() is supposed to fail as you > would expect if /proc/sys/vm/overcommit_memory is 0. This is the case on > my RH 6.2 box, dunno about yours. I can write a simple test program which > simply allocates tons of memory if you like... > > ...and I did. It filled up my physical and swap memory, and got killed by > the OOM handler before malloc() failed, even though overcommit_memory was > set to 0. > > *BAD!* Please search list archives, there are plenty of threads about overcommitment. Have a look at the sources, that part is easy to read and you'll realize that /proc/sys/vm/overcommit_memory does not really enable / disable memory overcommitment: its closer to a sanity check to disallow absurdly sized requests, IIRC. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, 23 Mar 2001, Jonathan Morton wrote: The main point is letting malloc fail when the memory cannot be guaranteed. If I read various things correctly, malloc() is supposed to fail as you would expect if /proc/sys/vm/overcommit_memory is 0. This is the case on my RH 6.2 box, dunno about yours. I can write a simple test program which simply allocates tons of memory if you like... ...and I did. It filled up my physical and swap memory, and got killed by the OOM handler before malloc() failed, even though overcommit_memory was set to 0. *BAD!* Please search list archives, there are plenty of threads about overcommitment. Have a look at the sources, that part is easy to read and you'll realize that /proc/sys/vm/overcommit_memory does not really enable / disable memory overcommitment: its closer to a sanity check to disallow absurdly sized requests, IIRC. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More compile warning fixes for 2.4.0
On Wed, 10 Jan 2001, Linus Torvalds wrote: > > > On Wed, 10 Jan 2001, Marco Colombo wrote: > > > > > > case xxx: > > > /* fallthrough */ ; > > > } > > > > > > or something (or maybe just a "break" statement), just so that we don't > > > turn the poor C language into line noise (can anybody say "perl" ;) > > > > Of course, you don't mean that the fallthrough comment and the break > > statement have the same functionality! (well you put the closing > > bracket and I agree that for the last case it's the same). > > Note that the warning case we're discussing was really only about case > statements at the end of a compound statement. > > In the middle of compound statements we're already fine: it's only the > corner case of a case "statement" without the statement that gcc > historically used to accept without warning, and that the gcc people only > recently noticed that they really shouldn't accept at all. > > So that's why a comment and a "break" is equivalent. ONLY for the special > case of the new compile warning, though, obviously (see the subject line, > but yes, I should have made that more explicit). I see. The choice between the comment and the 'break' can be left to the author, maybe he knows what is the best one (the one that will let us add a new case with less effort). If you bother setting a styleguide rule, I believe the latter is more common. But still I dislike semicolons *after* comments. Why not: case a: ... ; /* fallthrough */ case b: ... ; /* fallthrough */ } It looks just a little less ugly to my eyes (please take a few seconds to get used at it), maybe it's because it's reminiscent of shell double-semicolon. In general, I find it more readable when comments are somewhat "outside" the C code. [ Note: I still put it after the first case, both for documenting the fallthrough behaviour, which is a good thing anyway, and to allow deleting the last case with no thinking of it. ] I'd even put a tab before the comment. case b: ... ; /* fallthrough */ } Ok, that's really a matter of taste. You spend more time in front of the source than me, and you know better. I'd like you to set a kind of rule, because it's something that many are not used to see and it's easier to recognise it if it looks the same everywhere. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More compile warning fixes for 2.4.0
On 10 Jan 2001, Alan Shutko wrote: > Marco Colombo <[EMAIL PROTECTED]> writes: > > > But what happens if I delete the stm1 line? We have: > > > > case xxx: > > /* fallthrough */ > > case yyy: > > stm2; > > > > which is wrong. > > AFAIK, that's perfectly correct. It's only the case where you have a > label at the end of a block (without a statement following it) where > it's an error. > > In the grammar, a statement must follow a label, but a > labeled-statement is a type of statement, so you can stack labels as > much as you want, as long as there's a statement somewhere after them. > > That is, assuming I'm reading the standard right (ISO/IEC 9899:1990, > Section 6.6, 6.6.1). Opps, sorry, I misunderstood Linus' message, then. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More compile warning fixes for 2.4.0
On Tue, 9 Jan 2001, Linus Torvalds wrote:
>
>
> On Wed, 10 Jan 2001, Andrea Arcangeli wrote:
>
> > On Tue, Jan 09, 2001 at 01:31:35PM -0800, Linus Torvalds wrote:
> > > don't have to worry about undocumented extensions etc.
> >
> > Infact I don't blame gcc maintainers for that, but the standard. Ok, minor
> > issue.
>
> Yeah, and nothing we can do about it any more.. Oh, well.
>
> The fact is that the
>
> case xxx: ;
>
> syntax is fairly ugly, so I'd prefer the fixup patches to look more like
>
> case xxx:
> /* fallthrough */ ;
> }
>
> or something (or maybe just a "break" statement), just so that we don't
> turn the poor C language into line noise (can anybody say "perl" ;)
Of course, you don't mean that the fallthrough comment and the break
statement have the same functionality! (well you put the closing
bracket and I agree that for the last case it's the same).
I think it's always a good idea to put a comment when you relay on the
(otherwise implicit) fallthrough, especially if there are statements
in between:
case xxx:
stm1;
/* fallthrough */
case yyy:
stm2;
but, note the absence of the semicolon after the comment (which is legal,
if stm1 is present).
The above is just what i feel "natural": it says that case xxx
is almost the same as case yyy but for a single (initial) statement.
It looks like "good C" to my eyes.
But what happens if I delete the stm1 line? We have:
case xxx:
/* fallthrough */
case yyy:
stm2;
which is wrong. It could be:
case xxx:
case yyy:
stm2;
which says that xxx and yyy are just the same, and looks fine to me.
Here the "fallthrough" rule is very readable. Too bad it's wrong.
So let me state the rule:
1) always put a comment when relaying on the fallthrough, followed
by a semicolon, even if not strictly necessary (so that you can
delete the statements above it later).
2) put the same comment or a break after the last case.
Maybe it's time to update Documentation/CodingStyle? (a very pleasant
reading, BTW. I must say I sometimes re-read it just for fun)
> I have to say, I think it was Pascal had this "no semicolon needed before
> an 'end'" rule, and I always really hated that. The C statement rules make
> a lo tmore sense, and requiring a statement after a case statement is
> probably a very good requirement from a language standpoint. It's just not
> very pretty - but adding a break or a comment will at least separate out
> the colon and the semi-colon a bit.
>
> Linus
Well, I've always hated the Pascal rule, too. It makes you feel that
there's a missing semicolon AND it forces you to add one when you decide
to add new statements after the last one (i used to forget it most of
the time). Now, this C rule makes you see a semicolon where you don't
expect it to be, after a comment. I'm used to see comments after the
semicolon, as in:
int foo;/* this is foo */
or alone. The only place I'd expect to see a comment before a
semicolon is in:
for(;;)
/* nop */;
but I'd write that differently anyway:
for(;;) {
continue;
}
which makes easier to add statements inside the loop. For maximum
readability I'd leave the "continue" even if there are other statements:
for(;;) {
stm1;
if (condition) {
break;
}
stm2;
continue;
}
(it's like a comment that says "loop again", opposed to the break which
says "stop looping") but I agree that's overkill. B-)
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More compile warning fixes for 2.4.0
On Tue, 9 Jan 2001, Linus Torvalds wrote:
On Wed, 10 Jan 2001, Andrea Arcangeli wrote:
On Tue, Jan 09, 2001 at 01:31:35PM -0800, Linus Torvalds wrote:
don't have to worry about undocumented extensions etc.
Infact I don't blame gcc maintainers for that, but the standard. Ok, minor
issue.
Yeah, and nothing we can do about it any more.. Oh, well.
The fact is that the
case xxx: ;
syntax is fairly ugly, so I'd prefer the fixup patches to look more like
case xxx:
/* fallthrough */ ;
}
or something (or maybe just a "break" statement), just so that we don't
turn the poor C language into line noise (can anybody say "perl" ;)
Of course, you don't mean that the fallthrough comment and the break
statement have the same functionality! (well you put the closing
bracket and I agree that for the last case it's the same).
I think it's always a good idea to put a comment when you relay on the
(otherwise implicit) fallthrough, especially if there are statements
in between:
case xxx:
stm1;
/* fallthrough */
case yyy:
stm2;
but, note the absence of the semicolon after the comment (which is legal,
if stm1 is present).
The above is just what i feel "natural": it says that case xxx
is almost the same as case yyy but for a single (initial) statement.
It looks like "good C" to my eyes.
But what happens if I delete the stm1 line? We have:
case xxx:
/* fallthrough */
case yyy:
stm2;
which is wrong. It could be:
case xxx:
case yyy:
stm2;
which says that xxx and yyy are just the same, and looks fine to me.
Here the "fallthrough" rule is very readable. Too bad it's wrong.
So let me state the rule:
1) always put a comment when relaying on the fallthrough, followed
by a semicolon, even if not strictly necessary (so that you can
delete the statements above it later).
2) put the same comment or a break after the last case.
Maybe it's time to update Documentation/CodingStyle? (a very pleasant
reading, BTW. I must say I sometimes re-read it just for fun)
I have to say, I think it was Pascal had this "no semicolon needed before
an 'end'" rule, and I always really hated that. The C statement rules make
a lo tmore sense, and requiring a statement after a case statement is
probably a very good requirement from a language standpoint. It's just not
very pretty - but adding a break or a comment will at least separate out
the colon and the semi-colon a bit.
Linus
Well, I've always hated the Pascal rule, too. It makes you feel that
there's a missing semicolon AND it forces you to add one when you decide
to add new statements after the last one (i used to forget it most of
the time). Now, this C rule makes you see a semicolon where you don't
expect it to be, after a comment. I'm used to see comments after the
semicolon, as in:
int foo;/* this is foo */
or alone. The only place I'd expect to see a comment before a
semicolon is in:
for(;;)
/* nop */;
but I'd write that differently anyway:
for(;;) {
continue;
}
which makes easier to add statements inside the loop. For maximum
readability I'd leave the "continue" even if there are other statements:
for(;;) {
stm1;
if (condition) {
break;
}
stm2;
continue;
}
(it's like a comment that says "loop again", opposed to the break which
says "stop looping") but I agree that's overkill. B-)
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More compile warning fixes for 2.4.0
On 10 Jan 2001, Alan Shutko wrote: Marco Colombo [EMAIL PROTECTED] writes: But what happens if I delete the stm1 line? We have: case xxx: /* fallthrough */ case yyy: stm2; which is wrong. AFAIK, that's perfectly correct. It's only the case where you have a label at the end of a block (without a statement following it) where it's an error. In the grammar, a statement must follow a label, but a labeled-statement is a type of statement, so you can stack labels as much as you want, as long as there's a statement somewhere after them. That is, assuming I'm reading the standard right (ISO/IEC 9899:1990, Section 6.6, 6.6.1). Opps, sorry, I misunderstood Linus' message, then. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] More compile warning fixes for 2.4.0
On Wed, 10 Jan 2001, Linus Torvalds wrote:
On Wed, 10 Jan 2001, Marco Colombo wrote:
case xxx:
/* fallthrough */ ;
}
or something (or maybe just a "break" statement), just so that we don't
turn the poor C language into line noise (can anybody say "perl" ;)
Of course, you don't mean that the fallthrough comment and the break
statement have the same functionality! (well you put the closing
bracket and I agree that for the last case it's the same).
Note that the warning case we're discussing was really only about case
statements at the end of a compound statement.
In the middle of compound statements we're already fine: it's only the
corner case of a case "statement" without the statement that gcc
historically used to accept without warning, and that the gcc people only
recently noticed that they really shouldn't accept at all.
So that's why a comment and a "break" is equivalent. ONLY for the special
case of the new compile warning, though, obviously (see the subject line,
but yes, I should have made that more explicit).
I see. The choice between the comment and the 'break' can be left
to the author, maybe he knows what is the best one (the one that will
let us add a new case with less effort).
If you bother setting a styleguide rule, I believe the latter is more
common.
But still I dislike semicolons *after* comments. Why not:
case a:
...
; /* fallthrough */
case b:
...
; /* fallthrough */
}
It looks just a little less ugly to my eyes (please take a few seconds to
get used at it), maybe it's because it's reminiscent of shell
double-semicolon. In general, I find it more readable when comments
are somewhat "outside" the C code.
[ Note: I still put it after the first case, both for documenting the
fallthrough behaviour, which is a good thing anyway, and to allow
deleting the last case with no thinking of it. ]
I'd even put a tab before the comment.
case b:
...
; /* fallthrough */
}
Ok, that's really a matter of taste. You spend more time in front
of the source than me, and you know better. I'd like you to set a kind
of rule, because it's something that many are not used to see and it's
easier to recognise it if it looks the same everywhere.
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, James Bourne wrote: > On Thu, 7 Dec 2000, Alan Cox wrote: > > > > > Should be the rtl8139 driver. > > > > > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. > > > Mike, if you have problems, search list archives: a few people (including > > > me) reported problems under load. I've never solved them. > > > > 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his > > own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be > > way better (but not perfect) > > Yes, still running 2.2.17 though. > > The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess > replaces the 538 as that is no longer listed on the Dlink site) is an > rtl8139 chip. You mean that D-Link made a card named DFE530TX VIA based and one named DFE530TX+ rtl based? Isn't it a bit confusing? B-) > > Jim .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Alan Cox wrote: > > > Should be the rtl8139 driver. > > > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. > > Mike, if you have problems, search list archives: a few people (including > > me) reported problems under load. I've never solved them. > > 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his > own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be > way better (but not perfect) > Ehm, does it drive the DFE-530TX, which, I believe, it's a via-rhine? I had problems with the 530. I've been told that the 538 (rtl8139) works under the same load (NFS server on a small LAN, and a 5-ports D-Link Switch), even with the old driver. .TM. -- / ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, James Bourne wrote:
> On Wed, 6 Dec 2000, Mike A. Harris wrote:
>
> > Which ethernet module works with this card? 2.2.17 kernel
>
> Should be the rtl8139 driver.
AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
Mike, if you have problems, search list archives: a few people (including
me) reported problems under load. I've never solved them.
>
> Regards,
> Jim
>
> > --
> > Mike A. Harris - Linux advocate - Open source advocate
> > This message is copyright 2000, all rights reserved.
> > Views expressed are my own, not necessarily shared by my employer.
> > --
>
>
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Alan Cox wrote: Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) Ehm, does it drive the DFE-530TX, which, I believe, it's a via-rhine? I had problems with the 530. I've been told that the 538 (rtl8139) works under the same load (NFS server on a small LAN, and a 5-ports D-Link Switch), even with the old driver. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, James Bourne wrote: On Thu, 7 Dec 2000, Alan Cox wrote: Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) Yes, still running 2.2.17 though. The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess replaces the 538 as that is no longer listed on the Dlink site) is an rtl8139 chip. You mean that D-Link made a card named DFE530TX VIA based and one named DFE530TX+ rtl based? Isn't it a bit confusing? B-) Jim .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Thu, 9 Nov 2000, Paul Jakma wrote: > On Thu, 9 Nov 2000, Michael Rothwell wrote: > > > Well, then, problem solved. > > > > :) > > > > afaik linus allows binary modules in most cases. > > > > And since an "Advanced Linux Kernel Project" wouldn't be a Linus kernel, > > what then? Would they have the same discretion as Linus? Would Linus' > > exception apply to them? > > don't know. you'd have to ask him... > > I actually think Linus has been too loose/vague on modules. The > official COPYING txt file in the tree contains an exception on linking > to the kernel using syscalls from linus and the GPL. nothing about > binary modules, and afaik the only statements he's ever made about > binary modules were off the cuff on l-k a long time (unless someone > knows a binary module whose vendor can show a written exception from > Linus et al). > > The result of all this is that we've had plenty of vendors ignoring > the GPL as it applies to linux and release binary modules all because > linus said on a mailling list that he doesn't mind too much. not a > very strong affirmation of the conditions under which linux is > licensed. Well, HW vendors may provide a binary module as a timid attempt to support Linux. A few have already understood that providing an Open Source one is far a better attitude: they can *get* support for it from the kernel community. They end up with a better driver, and they can even learn something useful for their W98/NT/Sco/whatever drivers, too. If they don't abuse of it (they are sicerely willing to "provide" something) it's clearly a winning move. Other vendors are just scared of the two words "Open Source" so they make a little first step in releasing a binary only driver, which they are more used to. I believe that sooner or later they'll realize the advantages of the Open Source attitude, and they'll make the move. A binary only file-system module is a completely different matter. Legally, it may have the same "status" of a binary only driver. Technically, it's just another module. But it seems to me a much clearer violation of GPL. If you want to hide the internals of your software, you're not GPL-compatible (a driver is slightly different in that a HW company is probably worried about the internals of their HW). > > be nice if the binary module thing could be clarified by the copyright > holders. Of course. > > --paulj > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Thu, 9 Nov 2000, Michael Rothwell wrote: > Alexander Viro wrote: > > > > On Thu, 9 Nov 2000, Michael Rothwell wrote: > > > > > Same as before -- freedom and low cost. The primary advantae of Linux > > > over other OSes is the GPL. > > > > Now, that's more than slightly insulting... > > Well, it wasn't meant to be. I imagine RMS would make the same type of > statement -- Linux is libre, therefore superior. There's a number of > OSes that have advantages of Linux in some area; Solaris can use more > processors; QNX is real-time, smaller and still posix; Windows has > better application support (i.e., more of them); MacOS has better color > and font management. But, Linux is free. Let's say for a moment that > Linux was exactly the same as Solaris, technically. Linux would be > superior because it is licensed under the GPL, and is free; whereas > Solaris would not be. Sorry, I couldn't resist. 1) "Solaris running on more processors"? Think of Beowulf clusters. Strangely enough, people running them choose Linux as the kernel. 2) "QNX is real-time", true. Linux is not. Please don't compare apples with oranges. 3) "Windows has more apps"? True. Is it a kernel property of any kind? No. 4) "MacOS has better color and font management" this is funny as it speaks for itself. I'd also add "MacOS is usually housed in a better-looking case". Luckily enough, under Linux color and font management is NOT a kernel job. No more than the external design of the case, I mean. And I really hope Linux will *never* be exactly the same as Solaris, technically. > > The problem with the hooks et.al. is very simple - they promote every > > bloody implementation detail to exposed API. Sorry, but... See Figure 1. > > It won't fly. > > Figure 1? >From "The design and implementation of the Perfect OS 1.0", yet to be published. The good thing about this book is that there will never be a second edition. Of course the only release of Perfect OS will be 1.0! B-) B-) B-) B-) > > -M > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Thu, 9 Nov 2000, Michael Rothwell wrote: Alexander Viro wrote: On Thu, 9 Nov 2000, Michael Rothwell wrote: Same as before -- freedom and low cost. The primary advantae of Linux over other OSes is the GPL. Now, that's more than slightly insulting... Well, it wasn't meant to be. I imagine RMS would make the same type of statement -- Linux is libre, therefore superior. There's a number of OSes that have advantages of Linux in some area; Solaris can use more processors; QNX is real-time, smaller and still posix; Windows has better application support (i.e., more of them); MacOS has better color and font management. But, Linux is free. Let's say for a moment that Linux was exactly the same as Solaris, technically. Linux would be superior because it is licensed under the GPL, and is free; whereas Solaris would not be. lurker off Sorry, I couldn't resist. 1) "Solaris running on more processors"? Think of Beowulf clusters. Strangely enough, people running them choose Linux as the kernel. 2) "QNX is real-time", true. Linux is not. Please don't compare apples with oranges. 3) "Windows has more apps"? True. Is it a kernel property of any kind? No. 4) "MacOS has better color and font management" this is funny as it speaks for itself. I'd also add "MacOS is usually housed in a better-looking case". Luckily enough, under Linux color and font management is NOT a kernel job. No more than the external design of the case, I mean. And I really hope Linux will *never* be exactly the same as Solaris, technically. /lurker on The problem with the hooks et.al. is very simple - they promote every bloody implementation detail to exposed API. Sorry, but... See Figure 1. It won't fly. Figure 1? From "The design and implementation of the Perfect OS 1.0", yet to be published. The good thing about this book is that there will never be a second edition. Of course the only release of Perfect OS will be 1.0! B-) B-) B-) B-) -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Thu, 9 Nov 2000, Paul Jakma wrote:
On Thu, 9 Nov 2000, Michael Rothwell wrote:
Well, then, problem solved.
:)
afaik linus allows binary modules in most cases.
And since an "Advanced Linux Kernel Project" wouldn't be a Linus kernel,
what then? Would they have the same discretion as Linus? Would Linus'
exception apply to them?
don't know. you'd have to ask him...
I actually think Linus has been too loose/vague on modules. The
official COPYING txt file in the tree contains an exception on linking
to the kernel using syscalls from linus and the GPL. nothing about
binary modules, and afaik the only statements he's ever made about
binary modules were off the cuff on l-k a long time (unless someone
knows a binary module whose vendor can show a written exception from
Linus et al).
The result of all this is that we've had plenty of vendors ignoring
the GPL as it applies to linux and release binary modules all because
linus said on a mailling list that he doesn't mind too much. not a
very strong affirmation of the conditions under which linux is
licensed.
Well, HW vendors may provide a binary module as a timid attempt to
support Linux. A few have already understood that providing an Open Source
one is far a better attitude: they can *get* support for it from the
kernel community. They end up with a better driver, and they can even
learn something useful for their W98/NT/Sco/whatever drivers, too.
If they don't abuse of it (they are sicerely willing to "provide" something)
it's clearly a winning move.
Other vendors are just scared of the two words "Open Source" so they make
a little first step in releasing a binary only driver, which they are
more used to. I believe that sooner or later they'll realize the advantages
of the Open Source attitude, and they'll make the move.
A binary only file-system module is a completely different matter.
Legally, it may have the same "status" of a binary only driver.
Technically, it's just another module. But it seems to me a much clearer
violation of GPL. If you want to hide the internals of your software,
you're not GPL-compatible (a driver is slightly different in that
a HW company is probably worried about the internals of their HW).
be nice if the binary module thing could be clarified by the copyright
holders.
Of course.
--paulj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE disk slow? There's help...
On Fri, 20 Oct 2000, Andre Hedrick wrote:
>
> Michael,
>
> Whatever card you are using, in you are getting that low I need to know
> more info. That drive should cook at 30MB/sec.
Andre, he wrote "old triton 2 board (Intel 430HX)". Do you really mean
you can do 30MB/sec on that board (no UDMA at all, AFAIK)?
# hdparm -i /dev/hda
/dev/hda:
Model=IBM-DPTA-372050, FwRev=P76OA30A, SerialNo=JMYJMG52550
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
BuffType=3(DualPortCache), BuffSize=1961kB, MaxMultSect=16, MultSect=16
DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes
LBA CHS=1023/256/63 Remapping, LBA=yes, LBAsects=40088160
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2
# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 4.95 seconds =25.86 MB/sec
Timing buffered disk reads: 64 MB in 8.46 seconds = 7.57 MB/sec
Kernel is a 2.2.16 RedHat-patched but not IDE-patched. I suppose I could get
more with your patches (but really? DMA seems to work, it's just a pre UDMA
chipset, AFAIK), but I doubt I could go over the 25.10 MB/sec thing.
It'a an *old* MB, with a *slow* CPU (133MHz).
# lspci
00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 02)
00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I] (rev 02)
(OK, mine is a 430FX, even older than Michael's one. The chipset is buggy,
I think, since doesn't let you go DMA on the second IDE channel. But a
430HX should be close in performance).
The DPTA-372050 does 20MB/sec on an Athlon MB, BTW. A DTLA-307030 does
35.5MB/sec on AMD-751/6-based boards (UDMA/66). But you know that... B-)
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
On Mon, 9 Oct 2000, Linus Torvalds wrote: > On Mon, 9 Oct 2000, Rik van Riel wrote: > > > > > I'd prefer just X having a higher "mm nice level" or something. > > > > Which it has, because: > > > > 1) CAP_RAW_IO > > 2) p->euid == 0 > > Oh, I agree, but we might want to generalize this a bit so that root could > say "this process is important" and then drop root privileges and still > get "credited" for the fact that it's important. > > It's not a big deal. It works for X right now. How about using p->rlim[RLIMIT_AS].rlim_cur to weight the badness point for a process? On my system, a 128MB RAM + 256MB swap, it defaults to some (insane?) value: bash$ ulimit -vH -vS virtual memory (kbytes) 4194302 virtual memory (kbytes) 2105343 for every process, which just means it is unused. The idea is: 1) set default for rlim[RLIMIT_AS].rlim_max to a saner value; 2) processes with higher rlim[RLIMIT_AS].rlim_cur get lower badness. This way, the badness of a process is not proportional to its absolute size, but to the fraction of allowed AS it is using. Processes that are capable(CAP_SYS_RESOURCE) can set RLIMIT_AS to a very high value, so they get less badness point. X is a perfect candidate. User's runaway processes (netscape) will have lower rlim[RLIMIT_AS].rlim_cur, thus will get higher badness. Something like: - points = p->mm->total_vm; + points = p->mm->total_vm / (p->rlim[RLIMIT_AS].rlim_cur << AS_FACTOR); with #define AS_FACTOR 30 maybe? (this is Rik's call, he knows better than me how to balance it...) It's simple, it's configurable. 1) may be enforced by the kernel, or completely left to user space. On my system, in its default configuration (no use of RLIMIT_AS), it has no impact at all (all processes have the same limit). Sounds good or am I missing something? > > Linus > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Linus Torvalds wrote: On Mon, 9 Oct 2000, Rik van Riel wrote: I'd prefer just X having a higher "mm nice level" or something. Which it has, because: 1) CAP_RAW_IO 2) p-euid == 0 Oh, I agree, but we might want to generalize this a bit so that root could say "this process is important" and then drop root privileges and still get "credited" for the fact that it's important. It's not a big deal. It works for X right now. How about using p-rlim[RLIMIT_AS].rlim_cur to weight the badness point for a process? On my system, a 128MB RAM + 256MB swap, it defaults to some (insane?) value: bash$ ulimit -vH -vS virtual memory (kbytes) 4194302 virtual memory (kbytes) 2105343 for every process, which just means it is unused. The idea is: 1) set default for rlim[RLIMIT_AS].rlim_max to a saner value; 2) processes with higher rlim[RLIMIT_AS].rlim_cur get lower badness. This way, the badness of a process is not proportional to its absolute size, but to the fraction of allowed AS it is using. Processes that are capable(CAP_SYS_RESOURCE) can set RLIMIT_AS to a very high value, so they get less badness point. X is a perfect candidate. User's runaway processes (netscape) will have lower rlim[RLIMIT_AS].rlim_cur, thus will get higher badness. Something like: - points = p-mm-total_vm; + points = p-mm-total_vm / (p-rlim[RLIMIT_AS].rlim_cur AS_FACTOR); with #define AS_FACTOR 30 maybe? (this is Rik's call, he knows better than me how to balance it...) It's simple, it's configurable. 1) may be enforced by the kernel, or completely left to user space. On my system, in its default configuration (no use of RLIMIT_AS), it has no impact at all (all processes have the same limit). Sounds good or am I missing something? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
On Mon, 9 Oct 2000, Rik van Riel wrote: > On Mon, 9 Oct 2000, Marco Colombo wrote: > > On Fri, 6 Oct 2000, Rik van Riel wrote: > > > > [...] > > > They are niced because the user thinks them a bit less > > > important. > > > > Please don't, this assumption is quite wrong. I use nice just to > > be 'nice' to other users. I can run my *important* CPU hog > > simulation nice +10 in order to let other people get more CPU > > when the need it. > > In that case the time the process has been running and the > CPU time used will save the process if it's been running for > a long time. > > Please read the /entire/ algorithm before making rash > conclusions like this. What "conclusions"? YOU stated that "They are niced because the user thinks them a bit less important", and I was only commenting on that. I've never said your /entire/ algorithm is failing, the point was on the purpose of the 'nice' level. Users don't use nice to mark less important processes. It's completely orthogonal. And if you really want to correlate nice level and importance, I'd rather say that niced processes tend to be more important that "normal" processes, on average. > If nice is used for important, long-running tasks, the fact > that they are long-running will save them (and be honest, > would you really care if a simulation would be killed after > 5 minutes? it's only inconvenient if it gets killed after > a few hours...) Ok. Now tell me what's the purpose to run your 'ls' at nice +5 at all. You nice processes that are going to take a while, otherwise nicing them has hardly a measurable effect, if any. > > But if you put the logic "niced == not important" somewhere into > > the kernel, nobody will use nice anymore. I'd rather give a > > bonus to niced processes. > > This doesn't make ANY sense at all. The objective is to destroy > the least amount of work, which means giving a bonus to processes > which have used a lot of CPU time already ... regardless of nice > value. 'regardless of nice value' is the part I like. > > all. But my point here is that you do, and you take it as an hint for > > process importance as percieved by the user that run it, and I believe > > it's just wrong guessing). > > If you have a better algorithm, feel free to send patches. No need. Either reverse the weight you give to nice level or just ignore it, which probably is easier. I agree that giving a bonus to niced processed it's nearly useless. As I've written in my previous message, I don't think it's a big issue. OOM should not happen, full stop. OOM killer is a last resort measure, so it needs not to be *too* careful. > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ > > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
On Fri, 6 Oct 2000, Rik van Riel wrote: [...] > They are niced because the user thinks them a bit less > important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. I agree this is a small issue, the OOM killer job isn't "nice" at all anyway. B-) (at OOM time, I'd not even look at the nice of a process at all. But my point here is that you do, and you take it as an hint for process importance as percieved by the user that run it, and I believe it's just wrong guessing). .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. I agree this is a small issue, the OOM killer job isn't "nice" at all anyway. B-) (at OOM time, I'd not even look at the nice of a process at all. But my point here is that you do, and you take it as an hint for process importance as percieved by the user that run it, and I believe it's just wrong guessing). .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Rik van Riel wrote:
On Mon, 9 Oct 2000, Marco Colombo wrote:
On Fri, 6 Oct 2000, Rik van Riel wrote:
[...]
They are niced because the user thinks them a bit less
important.
Please don't, this assumption is quite wrong. I use nice just to
be 'nice' to other users. I can run my *important* CPU hog
simulation nice +10 in order to let other people get more CPU
when the need it.
In that case the time the process has been running and the
CPU time used will save the process if it's been running for
a long time.
Please read the /entire/ algorithm before making rash
conclusions like this.
flame level=+1
What "conclusions"? YOU stated that "They are niced because the user
thinks them a bit less important", and I was only commenting on that.
I've never said your /entire/ algorithm is failing, the point was on
the purpose of the 'nice' level. Users don't use nice to mark less
important processes. It's completely orthogonal. And if you really
want to correlate nice level and importance, I'd rather say that
niced processes tend to be more important that "normal" processes,
on average.
/flame
If nice is used for important, long-running tasks, the fact
that they are long-running will save them (and be honest,
would you really care if a simulation would be killed after
5 minutes? it's only inconvenient if it gets killed after
a few hours...)
Ok. Now tell me what's the purpose to run your 'ls' at nice +5 at all.
You nice processes that are going to take a while, otherwise nicing
them has hardly a measurable effect, if any.
But if you put the logic "niced == not important" somewhere into
the kernel, nobody will use nice anymore. I'd rather give a
bonus to niced processes.
This doesn't make ANY sense at all. The objective is to destroy
the least amount of work, which means giving a bonus to processes
which have used a lot of CPU time already ... regardless of nice
value.
'regardless of nice value' is the part I like.
all. But my point here is that you do, and you take it as an hint for
process importance as percieved by the user that run it, and I believe
it's just wrong guessing).
If you have a better algorithm, feel free to send patches.
No need. Either reverse the weight you give to nice level or just
ignore it, which probably is easier. I agree that giving a bonus to
niced processed it's nearly useless.
As I've written in my previous message, I don't think it's a big
issue. OOM should not happen, full stop. OOM killer is a last resort
measure, so it needs not to be *too* careful.
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17 crashes with RTL8139B and/or IPv6
On Wed, 20 Sep 2000, Simon Richter wrote: > Hi, > > I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit ^^ isn't it overclocked? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17 crashes with RTL8139B and/or IPv6
On Wed, 20 Sep 2000, Simon Richter wrote: Hi, I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit ^^ isn't it overclocked? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
On Fri, 15 Sep 2000, Russell King wrote: > Mitchell Blank Jr writes: > > If they're able to create a patch, hopefully they'd be able to fill in > > a simple email template (and I've seen some pretty dim folks manage to > > register domains with InterNIC, so email templates aren't that hard :-) > > > > We could even have a simple web page where you check a few boxes and > > fill in "URL to patch" and hit submit. > > You reckon? Its hard enough with mailing lists - I've seen people send > email subscription requests to majordomo@list to subscribe to a mailman > list, along with sending subscription requests to the mailing list address > etc. What makes you think that if humanity can't handle mailing lists > that humanity will handle an email template or a simple web page? >_ > |_| - ---+---+- > | | Russell King[EMAIL PROTECTED] --- --- > | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | > | +-+-+ --- -+- > / | THE developer of ARM Linux |+| /|\ > / | | | --- | > +-+-+ - /\\\ | Remember? This is not humanity. We're a community made of one Great Penguin (you guess who), few smaller penguins (kernel developers), and many many little rabbits (tring to learn something, with or without a debugger)... what has Mankind to do with us? B-) B-) B-) Anyway, you mean that one could: 1) read l-k, 2) choose an item from some TODO list, 3) download the kernel tarball and correctly untar it, 4) fire the editor of choice, 5) read the Source, 6) understand the Source, 7) contemplate It, 8) even dare to modify It, 9) produce a patch file with correct diff options, 10) find out the correct address to send the patch to, 11) launch the browser, and successfully open the form page, and after that stop for not being able to fill the template? You *really* believe this is a likely scenario? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The case for a standard kernel debugger
On Thu, 14 Sep 2000, Frederic Magniette wrote: [...] > In that way, I think that a kernel debugger could be a powerful coding > tool and not only a patching tool as you say. I don't have enough background to judge on the merits of a kernel debugger. I simply trust Linus' feelings on the matter. I don't agree with his arguments on (in)natural selection of rabbits (ops, kernel developers, I mean). BTW, a kernel debugger *is* available. And maybe even a more powerful one will be if Jeff decides to port and publicly release it. Many people already use kdb, I think, so why don't you just do the same? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The case for a standard kernel debugger
On Wed, 13 Sep 2000, Timur Tabi wrote: > ** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 14 Sep 2000 > 08:49:50 +1100 > > > > (5) Easier for kernel beginners to learn the kernel internals. Having > > worked on 10+ operating systems over the years, I can testify that > > some form of kernel/OS tracing facility is extremely useful to get > > people started. > > Excellent post, but I can relate to this point the most. Using the debugger to > aid in understanding the kernel is akin, IMHO, to knowing assembly language > when programming in a high-level language. People who understand how the > computer works (which is only possible if you know asm) are better programmers > than those who don't. Similarly, interacting with the kernel while its doing > its "magic" makes it easier to understand that magic. > > I lost a lot of respect for Linus when he made comments that basically implied > that I was not worthy of learning the Linux kernel because I did not want to do > it the hard way. So Linus is right. His main argument is about people selection. Keep the ones who don't want to do it the hard way out of the door. You're just saying that his strategy is succeeding. Let me ask: if you want to learn how the kernel works, and you think you need a debugger, why don't you apply the patches yourself? What Linus does with his own tree has little impact on you. You won't buy Linus with the 'learning' argument, I think. I don't think Linus' main point is "do I the hard way or don't". The point is that "doing it with a debugger is not the easy way". It seems to be easier but you don't get the Knowledge. So in the end it's 'the right way' vs. 'the wrong way'. not 'hard' vs. 'easy'. In this, I must say I agree with him. I'd also add that source code is (should be) a language to express ideas (at the same time to implement them). With a well written source, you don't need a debugger at all to understand 'how it works'. And if you find you need it, we've quite a problem with the source in the beginning. Source code should be more human readable than debugger output, *expecially* for beginners. In this Linus is doing a great job. My points againts Linus' arguments: 1) you should give people freedom to do what they do. If they want to spend thier time with a debugger let them do. This 'social engineering' thing is crap. You don't make people better by filtering them. 2) apply tight filters on what people produce (patches, features) not on how they produce. If Linus is right (and in the end I believe it), 'debugger people' will produce low quality patches (the ones that fix the syntoms not the problems), and those patches won't be blessed by Linus. I think Alan made the point that those patches sometimes may be useful to others who are looking for the real problems. Also, Jeff, if you're reading this, go on with your (better) debugger. The whole point of releasing something under GPL is the feedback you get for free, which sometimes happens to be high quality feedback, contributions, bug-fixes, an so on. You get a better product, in the end, and since you find it useful to you, in primis, it makes *your* life easier. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The case for a standard kernel debugger
On Thu, 14 Sep 2000, Frederic Magniette wrote: [...] In that way, I think that a kernel debugger could be a powerful coding tool and not only a patching tool as you say. I don't have enough background to judge on the merits of a kernel debugger. I simply trust Linus' feelings on the matter. I don't agree with his arguments on (in)natural selection of rabbits (ops, kernel developers, I mean). BTW, a kernel debugger *is* available. And maybe even a more powerful one will be if Jeff decides to port and publicly release it. Many people already use kdb, I think, so why don't you just do the same? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Linus Torvalds wrote: > > > On Wed, 6 Sep 2000, Marco Colombo wrote: > > > > As you said, the are two kinds of reactions. I don't understand why you > > think that the presence of a debugger will *prevent* people from doing > > the Right Thing and "think about problems another way". Are debuggers so > > evil? Will a KDB option in the standard tarball seduce ALL the smart guys > > , and even YOU, and lead you all to the Dark Side? Do you believe a > > debugger has such a power? > > Go back. Read the mail again. > > Read the part about weeding out the people who are not careful. > > Think about it. > > Carefully. I've done. I understand you want to implement a filter. You are not trying to increase the quality of Linux kernel developers as a group, you're just implementing a 'high level' filter on your mailbox (something procmail is not able to handle yet), just letting only the people you like in. In that, yes, you're a bastard. B-) Your right, anyway. I also understand your 'rabbits' arguments. You don't buy me with them. Human brains are quite different from rabbits. All historical attempts to improve them *by selection* failed soundly. You simply don't make people better *reducing* their freedom. A good programmer is a good programmer no matter how many debuggers are available out there. I do believe that Linux kernel programming is NOT the place to start learing programming at all. So, most kernel newbie are already experienced programmers. They may have the kind of "taste" you like or not, but hardly you're going to change thier habits. The ones with a bad taste won't be able to produce patches / bug fixes anyway, so what's the deal? Even if this is just a mail filter, it is not an effective one. Programmers who are not careful, the ones you don't like, are not going to produce anything. With or without a debugger. And even if they produce bad patches, you, or some of the guys you like, will look at them, just to see where the bug is, and produce better ones. Of course, all this under the statement that 'you include into your tarballs whatever you like'. I'm not advocating the inclusion of anything into the "standard" kernel. I'm just replying to your arguments. [ I put this sentence last since I'm a bastard, too... B-) ] > > Linus > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Sun, 10 Sep 2000, Jeff V. Merkey wrote: > Since Linus has rejected kdb there's every indication he will reject any other > kernel debugger submissions -- also his right. I think my time would be better > spent completing the merge of the Linux code base onto MANOS since moving the > debugger over to Linux seems to not be something Linus would adopt and it's > contrary to his development philosophy, so it's probably a complete waste of my > time. You seem to miss the implications of GPL. There's nothing Linus can do to prevent you from distributing your debugger, both as a patch and as a part of the kernel, as long as you don't break GPL. So it won't be 'a complete waste of time'. If your debugger is useful (and you seem to believe strongly it is), people will start using it anyway, Linus blessing it or not. You may notice that *very few* systems out there run a vanilla (Linus') kernel. They run [a kernel including] many patches which are not Linus-blessed. It takes some work if you want to be really up to date with the lastest vanilla release. But for many systems I run I'm just quite happy with RedHat updates. As many others are happy with Suse reiser-enabled kernels, I believe. If you don't want to hear from Linus (and others) about how useless/useful debuggers are, just don't ask them. Post a link to your patch here on l-k, WITHOUT asking for inclusion. If you do so, I doubt Linus will ever say a word about that. > If I get time to create a patch for Linux, I'll put it up. kdb seems to be > already there, so folks can use it on Linux for now, and I'll stick to printk() > and code reviews for my debugging on Linux. Jeff, there's on think I don't really understand. If the lack of a kernel debugger does slows YOUR delopment time under Linux down so much, why don't you take time to write your own debugger (or integrate the one you already wrote) just for YOU? We'll be glad to see it under GPL, of course, but that's your choice. Since you seem to think that a debugger will have an huge impact on development time, you and your company will have a *great* advantage over competitors when you release it. > > :-) > > Jeff. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- ____/ / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Sun, 10 Sep 2000, Jeff V. Merkey wrote: Since Linus has rejected kdb there's every indication he will reject any other kernel debugger submissions -- also his right. I think my time would be better spent completing the merge of the Linux code base onto MANOS since moving the debugger over to Linux seems to not be something Linus would adopt and it's contrary to his development philosophy, so it's probably a complete waste of my time. You seem to miss the implications of GPL. There's nothing Linus can do to prevent you from distributing your debugger, both as a patch and as a part of the kernel, as long as you don't break GPL. So it won't be 'a complete waste of time'. If your debugger is useful (and you seem to believe strongly it is), people will start using it anyway, Linus blessing it or not. You may notice that *very few* systems out there run a vanilla (Linus') kernel. They run [a kernel including] many patches which are not Linus-blessed. It takes some work if you want to be really up to date with the lastest vanilla release. But for many systems I run I'm just quite happy with RedHat updates. As many others are happy with Suse reiser-enabled kernels, I believe. If you don't want to hear from Linus (and others) about how useless/useful debuggers are, just don't ask them. Post a link to your patch here on l-k, WITHOUT asking for inclusion. If you do so, I doubt Linus will ever say a word about that. If I get time to create a patch for Linux, I'll put it up. kdb seems to be already there, so folks can use it on Linux for now, and I'll stick to printk() and code reviews for my debugging on Linux. Jeff, there's on think I don't really understand. If the lack of a kernel debugger does slows YOUR delopment time under Linux down so much, why don't you take time to write your own debugger (or integrate the one you already wrote) just for YOU? We'll be glad to see it under GPL, of course, but that's your choice. Since you seem to think that a debugger will have an huge impact on development time, you and your company will have a *great* advantage over competitors when you release it. :-) Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Linus Torvalds wrote: On Wed, 6 Sep 2000, Marco Colombo wrote: As you said, the are two kinds of reactions. I don't understand why you think that the presence of a debugger will *prevent* people from doing the Right Thing and "think about problems another way". Are debuggers so evil? Will a KDB option in the standard tarball seduce ALL the smart guys , and even YOU, and lead you all to the Dark Side? Do you believe a debugger has such a power? Go back. Read the mail again. Read the part about weeding out the people who are not careful. Think about it. Carefully. I've done. I understand you want to implement a filter. You are not trying to increase the quality of Linux kernel developers as a group, you're just implementing a 'high level' filter on your mailbox (something procmail is not able to handle yet), just letting only the people you like in. In that, yes, you're a bastard. B-) Your right, anyway. I also understand your 'rabbits' arguments. You don't buy me with them. Human brains are quite different from rabbits. All historical attempts to improve them *by selection* failed soundly. You simply don't make people better *reducing* their freedom. A good programmer is a good programmer no matter how many debuggers are available out there. I do believe that Linux kernel programming is NOT the place to start learing programming at all. So, most kernel newbie are already experienced programmers. They may have the kind of "taste" you like or not, but hardly you're going to change thier habits. The ones with a bad taste won't be able to produce patches / bug fixes anyway, so what's the deal? Even if this is just a mail filter, it is not an effective one. Programmers who are not careful, the ones you don't like, are not going to produce anything. With or without a debugger. And even if they produce bad patches, you, or some of the guys you like, will look at them, just to see where the bug is, and produce better ones. Of course, all this under the statement that 'you include into your tarballs whatever you like'. I'm not advocating the inclusion of anything into the "standard" kernel. I'm just replying to your arguments. [ I put this sentence last since I'm a bastard, too... B-) ] Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Linus Torvalds wrote: [...] > Oh. And sure, when things crash and you fsck and you didn't even get a > clue about what went wrong, you get frustrated. Tough. There are two kinds > of reactions to that: you start being careful, or you start whining about > a kernel debugger. > [...] > I happen to believe that not having a kernel debugger forces people to > think about their problem on a different level than with a debugger. I > think that without a debugger, you don't get into that mindset where you > know how it behaves, and then you fix it from there. Without a debugger, > you tend to think about problems another way. You want to understand > things on a different _level_. > > It's partly "source vs binary", but it's more than that. It's not that you > have to look at the sources (of course you have to - and any good debugger > will make that _easy_). It's that you have to look at the level _above_ > sources. At the meaning of things. Without a debugger, you basically have > to go the next step: understand what the program does. Not just that > particular line. As you said, the are two kinds of reactions. I don't understand why you think that the presence of a debugger will *prevent* people from doing the Right Thing and "think about problems another way". Are debuggers so evil? Will a KDB option in the standard tarball seduce ALL the smart guys , and even YOU, and lead you all to the Dark Side? Do you believe a debugger has such a power? You don't need to be blind to be able to listen to music. It just happens that you sometimes close your eyes, since it makes it a deeper experience. So, when you want to "look at the Source" (== "understand things on a different _level_"), just leave the debugger off. Don't compile it. People who don't understand this will keep looking at the debugger prompt. If the bug is a "easy" one, they'll fix it. If it's an hard one, one that needs an Higher Knowledge, they won't. And you'll never see a patch from them. So? Darwin rules anyway... That said, I believe that you don't need to explain why you don't include a kernel db in the standard kernel. As far as I'm concerned, the standard kernel is just a tarball of your kernel tree. And you put whatever YOU like in it. I call it "the standard kernel" only because *I* decided to think of it as a reference. It just happens that many people think that same way I do, and go and grab the latest 'official' tarball as soon as you release it. I do apply patches (e.g. RAID), but I won't tell you: "put them in YOUR kernel" the same why I don't tell you of what color you should paint the walls of your house... You can be as "bastard" as you like with your kernel since it's YOURS. You don't like debuggers. Fine. Maybe you don't like them because you think they will prevent YOU from thinking about bugs the right way. So they'll never make their way into YOUR kernel. But please don't say that debuggers are bad for everyone... others may be able to close their eyes and "look at the Source" even in the presence of a debugger... IMHO, there good reasons to leave a debugger out. Technical ones. You don't need a religious one. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Linus Torvalds wrote: [...] Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger. [...] I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. It's partly "source vs binary", but it's more than that. It's not that you have to look at the sources (of course you have to - and any good debugger will make that _easy_). It's that you have to look at the level _above_ sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line. As you said, the are two kinds of reactions. I don't understand why you think that the presence of a debugger will *prevent* people from doing the Right Thing and "think about problems another way". Are debuggers so evil? Will a KDB option in the standard tarball seduce ALL the smart guys , and even YOU, and lead you all to the Dark Side? Do you believe a debugger has such a power? You don't need to be blind to be able to listen to music. It just happens that you sometimes close your eyes, since it makes it a deeper experience. So, when you want to "look at the Source" (== "understand things on a different _level_"), just leave the debugger off. Don't compile it. People who don't understand this will keep looking at the debugger prompt. If the bug is a "easy" one, they'll fix it. If it's an hard one, one that needs an Higher Knowledge, they won't. And you'll never see a patch from them. So? Darwin rules anyway... That said, I believe that you don't need to explain why you don't include a kernel db in the standard kernel. As far as I'm concerned, the standard kernel is just a tarball of your kernel tree. And you put whatever YOU like in it. I call it "the standard kernel" only because *I* decided to think of it as a reference. It just happens that many people think that same way I do, and go and grab the latest 'official' tarball as soon as you release it. I do apply patches (e.g. RAID), but I won't tell you: "put them in YOUR kernel" the same why I don't tell you of what color you should paint the walls of your house... You can be as "bastard" as you like with your kernel since it's YOURS. You don't like debuggers. Fine. Maybe you don't like them because you think they will prevent YOU from thinking about bugs the right way. So they'll never make their way into YOUR kernel. But please don't say that debuggers are bad for everyone... others may be able to close their eyes and "look at the Source" even in the presence of a debugger... IMHO, there good reasons to leave a debugger out. Technical ones. You don't need a religious one. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On Thu, 31 Aug 2000, Alan Cox wrote: > > Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So > you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre > patch of choice. One day I hope you'll explain to us why this is not 2.2.17pre21... Either you are sure pre20 is going to be the official 2.2.17, or I'm missing something. And now that I look closer, you used the work 'Fix' a lot in the changelog. It won't be a great idea to release 2.2.17 with many outstanding bugs (however little they are...). > 2.2.18pre1 (versus 2.2.17pre20) fgrep Fix 2.2.18-changes | wc -l 16 B-) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Thu, 31 Aug 2000, Erik McKee wrote:
> Hello!
>
> This is one of my first posts here, so try to be gentle, please ;)
>
> Seems like if a thread which shares a VM with all the other threads of the
> same family does an execve, the following would be likely to occurr, using
> the standard definition of execve. The vm would be overwriteen with the
> new image, but this would have to wwipe out all the other threads in the
> process, 'cuz otherwise everything they refer to has just been overwritten
> by the results of the execve. However, if the execve'ing thread was
> allowed to spawn off intop a new address space before the execve, it would
> then become a new process, and leave the parent procvess with one less
> thread to worry about.
I think that's close to Linus' idea.
But it reminds me more a fork()+exec() rather than a simple exec().
OK. I'm clueless C programmer. I write:
program A:
pid = getpid(); /* imagine is 300 */
...
exec("program B");
program B:
...
pid = getpid(); /* I'm expecting 300 */
Then I modify A:
program A2:
pid = getpid(); /* 400 */
if (!fork()) {
exec("program B);
}
...
program B:
...
pid = getpid(); /* I'm expecting != 400 */
This is ok because that's what I asked for.
Suppose I make a MT version of A. It would behave just like A2.
The thread who's performing the exec() becomes a different process
and program B sees a different pid.
It's like saying: an exec() in a MT process behaves like a fork()+exec()
sequence in a normal process.
I'm not really against it... it's just a little weird.
Killing all threads, and doing a "real" exec(), leads to the expected
semantic. Of course, since you should expect the "defined" semantic,
that matter is about choosing the definition. B-)
BTW, I don't think it needs to be a kernel matter. exec() in a MT
program can be defined to kill all threads in userland before doing
the exec().
>
> Or am I being very stupid and overlooking something critical here?
Do you consider the above problem "critical"? B-)
>
> Have a nice day ;)
> Erik McKee
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
.TM.
--
/ / /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_/ _/ _/ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Large File support and blocks.
On Fri, 1 Sep 2000, Linda Walsh wrote: > Perhaps an "easy" way to go would be to convert block numbers to > type "block_nr_t", then one could measure the difference that 10's of > nanoseconds make against seeks and reads of disk data. True for DOS. On Linux, most file operations are done in RAM and only a part of them ever committed to disk. And anyway, even if the process doing disk I/O has to sleep, the sooner it releases the CPU, the better. Other processes maybe need just CPU cycles, so why waste them? On a single user, single task system I agree that the FS code could run seti@home while waiting for disk seeks to complete... B-) > Obviously the effect would be greater on ramdisks, but on computers with > equivalent generation hard disks we might be talking something non-measurable > or at least down in the noise level. Even transfers of 512 bytes of > data from a buffer to user space is going to take significantly more cycles. Again, it may take 100 cycles to do the job, but it doesn't mean you can make them 110 and be happy. The *user* who's waiting for I/O won't notice. Others will. I agree that if you are certain that a piece of code will run once a second, it doesn't really matter if it takes 100 cycles or 110... you're loosing 10 cycles per second. But are you sure that all the code that would use 'block_nr_t' is in such a slow path? > If the change became as simple as changing a typedef in a file, then you > could even allow a user to choose to allow "very large files" -- compiling > with long long when turned on, or simple ints when turned off -- if that > was seen as a necessity -- but I'd still lean toward it not being noticable. > > -l > > -- > Linda A Walsh| Trust Technology, Core Linux, SGI > [EMAIL PROTECTED] | Voice: (650) 933-5338 .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Large File support and blocks.
On Fri, 1 Sep 2000, Linda Walsh wrote: Perhaps an "easy" way to go would be to convert block numbers to type "block_nr_t", then one could measure the difference that 10's of nanoseconds make against seeks and reads of disk data. True for DOS. On Linux, most file operations are done in RAM and only a part of them ever committed to disk. And anyway, even if the process doing disk I/O has to sleep, the sooner it releases the CPU, the better. Other processes maybe need just CPU cycles, so why waste them? On a single user, single task system I agree that the FS code could run seti@home while waiting for disk seeks to complete... B-) Obviously the effect would be greater on ramdisks, but on computers with equivalent generation hard disks we might be talking something non-measurable or at least down in the noise level. Even transfers of 512 bytes of data from a buffer to user space is going to take significantly more cycles. Again, it may take 100 cycles to do the job, but it doesn't mean you can make them 110 and be happy. The *user* who's waiting for I/O won't notice. Others will. I agree that if you are certain that a piece of code will run once a second, it doesn't really matter if it takes 100 cycles or 110... you're loosing 10 cycles per second. But are you sure that all the code that would use 'block_nr_t' is in such a slow path? If the change became as simple as changing a typedef in a file, then you could even allow a user to choose to allow "very large files" -- compiling with long long when turned on, or simple ints when turned off -- if that was seen as a necessity -- but I'd still lean toward it not being noticable. -l -- Linda A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On Thu, 31 Aug 2000, Alan Cox wrote: Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre patch of choice. One day I hope you'll explain to us why this is not 2.2.17pre21... Either you are sure pre20 is going to be the official 2.2.17, or I'm missing something. And now that I look closer, you used the work 'Fix' a lot in the changelog. It won't be a great idea to release 2.2.17 with many outstanding bugs (however little they are...). 2.2.18pre1 (versus 2.2.17pre20) fgrep Fix 2.2.18-changes | wc -l 16 B-) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Tue, 29 Aug 2000, Pavel Machek wrote: > Hi! > [...] > > > So you need some hackery to make mount(8) cause change in all > > > namespaces at once. Whatever is done, this will be gross. > > > I suppose you'd require a loopback of some sort, so that one > > > might rip the real filesystem out from under /var/mail instead > > > of trying to unmount it in 50 different namespaces... ugh. > > > > Not. Loopback would be gross, but I'm not proposing it. OTOH, getting all > > mailreaders work with IMAP with _no_ changes in said mailreaders is a > > Good Thing(tm). So is free (for mailreaders) support of any weird > > protocol, format and location of mailbox, locking scheme, etc. - do it in > > one place and that's it. Everything looks like we have the mailbox in > > fixed format on local filesystem, no matter WTF is actually out there. > > And guess what? It doesn't have to be one process and it's nowhere near > > the kernel mode, or even suid. > > What does this have to do with private namespaces? > > mailfsd /dev/coda0 --enable-imap & > mount /dev/coda0 /var/spool/mail So every user will see /var/spool/mail. There must be a single mailfsd for all users. With private namespaces, every user can run his/her own mailfsd, privately mount /var/spool/mail, and run a mailer program to access one or more IMAP mailbox as /var/spool/mail/. But I must say I don't really get the difference in running my own mailfsd, mounting ~/mail and having the mailer program read IMAP mailboxes there (OK, /var/spool/mail/ is the default INBOX for many mailers, and some of them don't let you change that... but this is a minor issue, just recompile them). All I need is a private mount point (and privileges to mount on it). > > It looks easy to me, today and without private namespaces. > [Shall I hack podfuk into providing imap? Okay, it would not be easy > because > * /var/spool/mail/xxx is _writable_, so your imap dream is probably > dream. What does your mailfs do when someone does cat /bin/bash > > $MYMAIL > * podfuk is has file granularity > > I could see it working with some kind of directory format, however.] > Pavel > -- > I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." > Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
