Re: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Sat, Feb 02, 2008 at 09:03:10PM -0800, Greg KH wrote: > On Sat, Feb 02, 2008 at 07:52:37PM -0500, Daniel Hazelton wrote: > > Actually, Greg, a hell of a lot of people that don't track linux kernel > > development do think that way. And there are always going to be people that > > think that way. > > So why would to more sentances trying to say "see, we really do know > what we are doing, we aren't idiots" make things any better to these > people? (hint, it wouldn't...) I have similar experience as Daniel.. It seems we need to say that because I have heard some people complain about the lack of stable interfaces. In fact, I wrote the original patch just after one person blamed Linux for not having stable interfaces, and that Linux people just change those APIs to be mean for third parties (which is obviously false). > The whole article explains why apis are change for very good reasons > (evolution of hardware, security, we now know better, etc.) That's the > whole point of the document... ... And the new paragraph supports that goal by assuring others that we don't do unnecessary changes. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Improve Documentation/stable_api_nonsense.txt v2
On Sat, Feb 02, 2008 at 09:03:10PM -0800, Greg KH wrote: On Sat, Feb 02, 2008 at 07:52:37PM -0500, Daniel Hazelton wrote: Actually, Greg, a hell of a lot of people that don't track linux kernel development do think that way. And there are always going to be people that think that way. So why would to more sentances trying to say see, we really do know what we are doing, we aren't idiots make things any better to these people? (hint, it wouldn't...) I have similar experience as Daniel.. It seems we need to say that because I have heard some people complain about the lack of stable interfaces. In fact, I wrote the original patch just after one person blamed Linux for not having stable interfaces, and that Linux people just change those APIs to be mean for third parties (which is obviously false). The whole article explains why apis are change for very good reasons (evolution of hardware, security, we now know better, etc.) That's the whole point of the document... ... And the new paragraph supports that goal by assuring others that we don't do unnecessary changes. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Improve Documentation/stable_api_nonsense.txt v2
This is version 2 of the patch. Address Gregs, Matts and Andis comments. Retain the word "exact" due to request of Greg. Use "the exact same" as per "Matt Mackall". * Change wording * Make a remark about necessary changes in interfaces Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]> --- Documentation/stable_api_nonsense.txt | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt index 847b342..a7c29ad 100644 --- a/Documentation/stable_api_nonsense.txt +++ b/Documentation/stable_api_nonsense.txt @@ -19,7 +19,7 @@ Executive Summary You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also -get lots of other good benefits if your driver is in the main kernel +get lots of other benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place. @@ -69,7 +69,7 @@ consider the following facts about the Linux kernel: on another architecture properly. Now a number of these issues can be addressed by simply compiling your -module for the exact specific kernel configuration, using the same exact +module for the exact same kernel configuration, using the exact same C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific Linux distribution. But multiply that single build by the number of @@ -116,7 +116,7 @@ issues: This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This -provides the ability for new developers to accidentally use the old +has the risk for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer. @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +However, changing an interface can be delicate work and it can take +significant amount of developer effort. Therefore, an interface is +not changed unless the change is regarded as very important by the +developers. What to do -- -- 1.5.3.4.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Improve Documentation/stable_api_nonsense.txt v2
This is version 2 of the patch. Address Gregs, Matts and Andis comments. Retain the word exact due to request of Greg. Use the exact same as per Matt Mackall. * Change wording * Make a remark about necessary changes in interfaces Signed-off-by: Heikki Orsila [EMAIL PROTECTED] --- Documentation/stable_api_nonsense.txt | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt index 847b342..a7c29ad 100644 --- a/Documentation/stable_api_nonsense.txt +++ b/Documentation/stable_api_nonsense.txt @@ -19,7 +19,7 @@ Executive Summary You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also -get lots of other good benefits if your driver is in the main kernel +get lots of other benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place. @@ -69,7 +69,7 @@ consider the following facts about the Linux kernel: on another architecture properly. Now a number of these issues can be addressed by simply compiling your -module for the exact specific kernel configuration, using the same exact +module for the exact same kernel configuration, using the exact same C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific Linux distribution. But multiply that single build by the number of @@ -116,7 +116,7 @@ issues: This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This -provides the ability for new developers to accidentally use the old +has the risk for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer. @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +However, changing an interface can be delicate work and it can take +significant amount of developer effort. Therefore, an interface is +not changed unless the change is regarded as very important by the +developers. What to do -- -- 1.5.3.4.GIT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt
ss the change is regarded as very important by the developers. > > Why do you feel this paragraph is needed at all? Some people may feel there is nothing to prevent constant changes. This paragraph tries to assure it is not the case. Actually, the whole point of this documentation is to comfort others. PS. Off topic: I think documentation is a very important topic for Linux systems in general (there is lot to be improved!). I wonder how many bugs in programs could be avoided by writing good man pages. For example, many people tend to get select() wrong, and I suspect it's partly because the man page is not as good as it could be. An example of good man page would Davide Libenzi's epoll that has an FAQ for common questions and an example of suggested usage. Good examples drive developers for solutions that are known to work in practice. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Improve Documentation/stable_api_nonsense.txt
CC'ing Andi as he commented also.. On Mon, Jan 28, 2008 at 08:48:05PM -0800, Greg KH wrote: > On Tue, Jan 29, 2008 at 01:09:59AM +0200, Heikki Orsila wrote: > > * Make a remark about avoiding unnecessary changes in interfaces > > * Improve wording > > Well, "improve" is a bit judgemental :) The places I corrected were somewhat unreadable English in my opinion. The problem with this text is mostly style that breaks common sense rules how to write simple sentences. Documentation should not try to represent its writer but convey the idea as well as possible. > > @@ -68,11 +68,11 @@ consider the following facts about the Linux kernel: > > There is no way that binary drivers from one architecture will run > > on another architecture properly. > > > > -Now a number of these issues can be addressed by simply compiling your > > -module for the exact specific kernel configuration, using the same exact > > +Now, a number of these issues can be addressed by simply compiling your > > +module for the same kernel configuration, using the same > > No, I want to emphasize the word "exact" here. It has to be the same. Do you want preserve both "exact specific" and "same exact"? Imo, "same exact C compiler" is just bad language, because C compilers are always "exact". "exactly same C compiler" would do. > > C compiler that the kernel was built with. This is sufficient if you > > want to provide a module for a specific release version of a specific > > -Linux distribution. But multiply that single build by the number of > > +Linux distribution. However, multiply that single build by the number of > > You messed with the "two space" rule, and changed the word unecessarily > in my opinion. > > > different Linux distributions and the number of different supported > > releases of the Linux distribution and you quickly have a nightmare of > > different build options on different releases. Also realize that each > > @@ -93,7 +93,7 @@ keep a Linux kernel driver that is not in the main kernel > > tree up to > > date over time. > > > > Linux kernel development is continuous and at a rapid pace, never > > -stopping to slow down. As such, the kernel developers find bugs in > > +slowing down. As such, the kernel developers find bugs in > > No, they never stop, I say leave it as is. Imo, that statement is very odd. The meaning of it has to be guessed. "never slowing down" is very simple and conveys the essential idea. > > @@ -116,7 +116,7 @@ issues: > > > > This is in stark contrast to a number of closed source operating systems > > which have had to maintain their older USB interfaces over time. This > > -provides the ability for new developers to accidentally use the old > > +has the risk for new developers to accidentally use the old > > It's not so much as a "risk" as it is what always seems to happen. So I > don't like this change either. No, it's definitely more "risk" than "ability" because "ability" should refer to a positive property. Here "ability" is used to refer to a "negative outcome". > > @@ -145,6 +145,10 @@ as small as possible, and that all potential > > interfaces are tested as > > well as they can be (unused interfaces are pretty much impossible to > > test for validity.) > > > > +Some complain that kernel interfaces change too often for out-of-the-tree > > +modules, but this claim is false. Changing an interface can be delicate > > work, > > +and it can take significant amount of developer effort. Therefore, > > interfaces > > +are not changed without a good reason. > > No, their claim is a valid one, it's not "false". However we are not > going to do anything about it, and as such, we don't need this kind of > wording to get people worried about it even more. How about this (scrap the whole paragraph): Changing an interface can be delicate work and it can take significant amount of developer effort. Therefore, an interface is not changed unless the change is regarded as very important by the developers. > So, care to redo the patch? Will try.. > Also note, there are other translations of this text already, so if you > want to change phrases like this, you might want to cc: those > maintainers as well to get their input. OK. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Improve Documentation/stable_api_nonsense.txt
This is my last counter argument. Based on this I'll submit a new patch that is less intrusive. On Tue, Jan 29, 2008 at 05:15:00AM -0800, Greg KH wrote: I strongly disagree with this. If you are reading documentation, you should at least be intertained a bit, and if you take the flavor of the writer out of it entirely, it becomes quite boring and dry. I hope we agree that by definition the success of documentation is measured by its ability to convey ideas. So the basic disagreement is simple English versus some flavor of English. entertainment value is there only to keep the person reading, but complicated sentences harm readability. @@ -68,11 +68,11 @@ consider the following facts about the Linux kernel: There is no way that binary drivers from one architecture will run on another architecture properly. -Now a number of these issues can be addressed by simply compiling your -module for the exact specific kernel configuration, using the same exact +Now, a number of these issues can be addressed by simply compiling your +module for the same kernel configuration, using the same No, I want to emphasize the word exact here. It has to be the same. Do you want preserve both exact specific and same exact? Both. Imo, same exact C compiler is just bad language, because C compilers are always exact. exactly same C compiler would do. No, exactly same C compiler doesn't parse well in English. Same exact C compiler does not mean what you try to say. C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific -Linux distribution. But multiply that single build by the number of +Linux distribution. However, multiply that single build by the number of You messed with the two space rule, and changed the word unecessarily in my opinion. different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases. Also realize that each @@ -93,7 +93,7 @@ keep a Linux kernel driver that is not in the main kernel tree up to date over time. Linux kernel development is continuous and at a rapid pace, never -stopping to slow down. As such, the kernel developers find bugs in +slowing down. As such, the kernel developers find bugs in No, they never stop, I say leave it as is. Imo, that statement is very odd. The meaning of it has to be guessed. never slowing down is very simple and conveys the essential idea. Hm, but you understood the idea conveyed here, right? That's the important issue, we can argue about the exact structure of words all day, which will get us no where. Right, this argument can't continue without other people's perspectives. Ok, fair enough, I can agree with that. Good :) @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +Some complain that kernel interfaces change too often for out-of-the-tree +modules, but this claim is false. Changing an interface can be delicate work, +and it can take significant amount of developer effort. Therefore, interfaces +are not changed without a good reason. No, their claim is a valid one, it's not false. However we are not going to do anything about it, and as such, we don't need this kind of wording to get people worried about it even more. How about this (scrap the whole paragraph): Changing an interface can be delicate work and it can take significant amount of developer effort. Therefore, an interface is not changed unless the change is regarded as very important by the developers. Why do you feel this paragraph is needed at all? Some people may feel there is nothing to prevent constant changes. This paragraph tries to assure it is not the case. Actually, the whole point of this documentation is to comfort others. PS. Off topic: I think documentation is a very important topic for Linux systems in general (there is lot to be improved!). I wonder how many bugs in programs could be avoided by writing good man pages. For example, many people tend to get select() wrong, and I suspect it's partly because the man page is not as good as it could be. An example of good man page would Davide Libenzi's epoll that has an FAQ for common questions and an example of suggested usage. Good examples drive developers for solutions that are known to work in practice. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt
On Tue, Jan 29, 2008 at 01:09:59AM +0200, Heikki Orsila wrote: > * Make a remark about avoiding unnecessary changes in interfaces > * Improve wording Forgot to CC Greg. - Heikki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Improve Documentation/stable_api_nonsense.txt
* Make a remark about avoiding unnecessary changes in interfaces * Improve wording Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]> --- Documentation/stable_api_nonsense.txt | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt index 847b342..e644099 100644 --- a/Documentation/stable_api_nonsense.txt +++ b/Documentation/stable_api_nonsense.txt @@ -19,7 +19,7 @@ Executive Summary You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also -get lots of other good benefits if your driver is in the main kernel +get lots of other benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place. @@ -68,11 +68,11 @@ consider the following facts about the Linux kernel: There is no way that binary drivers from one architecture will run on another architecture properly. -Now a number of these issues can be addressed by simply compiling your -module for the exact specific kernel configuration, using the same exact +Now, a number of these issues can be addressed by simply compiling your +module for the same kernel configuration, using the same C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific -Linux distribution. But multiply that single build by the number of +Linux distribution. However, multiply that single build by the number of different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases. Also realize that each @@ -93,7 +93,7 @@ keep a Linux kernel driver that is not in the main kernel tree up to date over time. Linux kernel development is continuous and at a rapid pace, never -stopping to slow down. As such, the kernel developers find bugs in +slowing down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and @@ -116,7 +116,7 @@ issues: This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This -provides the ability for new developers to accidentally use the old +has the risk for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer. @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +Some complain that kernel interfaces change too often for out-of-the-tree +modules, but this claim is false. Changing an interface can be delicate work, +and it can take significant amount of developer effort. Therefore, interfaces +are not changed without a good reason. What to do -- -- 1.5.3.4.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt
On Tue, Jan 29, 2008 at 01:09:59AM +0200, Heikki Orsila wrote: * Make a remark about avoiding unnecessary changes in interfaces * Improve wording Forgot to CC Greg. - Heikki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Improve Documentation/stable_api_nonsense.txt
* Make a remark about avoiding unnecessary changes in interfaces * Improve wording Signed-off-by: Heikki Orsila [EMAIL PROTECTED] --- Documentation/stable_api_nonsense.txt | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt index 847b342..e644099 100644 --- a/Documentation/stable_api_nonsense.txt +++ b/Documentation/stable_api_nonsense.txt @@ -19,7 +19,7 @@ Executive Summary You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also -get lots of other good benefits if your driver is in the main kernel +get lots of other benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place. @@ -68,11 +68,11 @@ consider the following facts about the Linux kernel: There is no way that binary drivers from one architecture will run on another architecture properly. -Now a number of these issues can be addressed by simply compiling your -module for the exact specific kernel configuration, using the same exact +Now, a number of these issues can be addressed by simply compiling your +module for the same kernel configuration, using the same C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific -Linux distribution. But multiply that single build by the number of +Linux distribution. However, multiply that single build by the number of different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases. Also realize that each @@ -93,7 +93,7 @@ keep a Linux kernel driver that is not in the main kernel tree up to date over time. Linux kernel development is continuous and at a rapid pace, never -stopping to slow down. As such, the kernel developers find bugs in +slowing down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and @@ -116,7 +116,7 @@ issues: This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This -provides the ability for new developers to accidentally use the old +has the risk for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer. @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +Some complain that kernel interfaces change too often for out-of-the-tree +modules, but this claim is false. Changing an interface can be delicate work, +and it can take significant amount of developer effort. Therefore, interfaces +are not changed without a good reason. What to do -- -- 1.5.3.4.GIT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Fri, Jan 25, 2008 at 02:13:00AM +0300, Dmitri Vorobiev wrote: > Care to explain why? Because functions are always external objects in C. I just verified that from K -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Fri, Jan 25, 2008 at 01:32:04AM +0300, Dmitri Vorobiev wrote: > diff --git a/fs/bfs/bfs.h b/fs/bfs/bfs.h > index 090b96e..ecc74bb 100644 > --- a/fs/bfs/bfs.h > +++ b/fs/bfs/bfs.h ... > +/* inode.c */ > +extern void dump_imap(const char *, struct super_block *); > + Functions should not be externed, remove extern keyword. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Fri, Jan 25, 2008 at 01:32:04AM +0300, Dmitri Vorobiev wrote: diff --git a/fs/bfs/bfs.h b/fs/bfs/bfs.h index 090b96e..ecc74bb 100644 --- a/fs/bfs/bfs.h +++ b/fs/bfs/bfs.h ... +/* inode.c */ +extern void dump_imap(const char *, struct super_block *); + Functions should not be externed, remove extern keyword. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] bfs: move function prototype to the proper header file
On Fri, Jan 25, 2008 at 02:13:00AM +0300, Dmitri Vorobiev wrote: Care to explain why? Because functions are always external objects in C. I just verified that from KR. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Sun, Nov 25, 2007 at 12:16:08PM +0100, Geert Uytterhoeven wrote: > > ISA NeedNeed > > natural alignment > > alignment by x > > > > m68kNo 2 > > `No' for >= 68020. > `Yes' for < 68020. My bad, yes.. mc68020+No No (mc68000/010No 2) (not for Linux) -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Sun, Nov 25, 2007 at 12:16:08PM +0100, Geert Uytterhoeven wrote: ISA NeedNeed natural alignment alignment by x m68kNo 2 `No' for = 68020. `Yes' for 68020. My bad, yes.. mc68020+No No (mc68000/010No 2) (not for Linux) -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Fri, Nov 23, 2007 at 12:15:53AM +, Daniel Drake wrote: > Why unaligned access is bad > === > > Most architectures are unable to perform unaligned memory accesses. Any > unaligned access causes a processor exception. "Some architectures are unable to perform unaligned memory accesses, either an exception is generated, or the data access is silently invalid. In architectures that allow unaligned access, natural aligned accesses are usually faster than non-aligned." > In summary: if your code causes unaligned memory accesses to happen, your code > will not work on some platforms, and will perform *very* badly on others. *very* -> *slower* > Natural alignment > = Please move this definition before "Why unaligned access is bad". Also, it would be nice to have a table of ISAs: ISA NeedNeed natural alignment alignment by x m68kNo 2 powerpc/ppc Yes Word size x86 No No x86_64 No No -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
On Fri, Nov 23, 2007 at 12:15:53AM +, Daniel Drake wrote: Why unaligned access is bad === Most architectures are unable to perform unaligned memory accesses. Any unaligned access causes a processor exception. Some architectures are unable to perform unaligned memory accesses, either an exception is generated, or the data access is silently invalid. In architectures that allow unaligned access, natural aligned accesses are usually faster than non-aligned. In summary: if your code causes unaligned memory accesses to happen, your code will not work on some platforms, and will perform *very* badly on others. *very* - *slower* Natural alignment = Please move this definition before Why unaligned access is bad. Also, it would be nice to have a table of ISAs: ISA NeedNeed natural alignment alignment by x m68kNo 2 powerpc/ppc Yes Word size x86 No No x86_64 No No -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 08/16] skge: fix ram buffer size calculation
On Thu, Nov 15, 2007 at 08:48:58AM -0800, Linus Torvalds wrote: > This is my commit message for the revert - note the suggested possible > fix (but also why I didn't apply it, and why things got reverted). > > Linus > --- > commit 279e1dab949d33737557babfe9f74e0b74fbe39a > Author: Linus Torvalds <[EMAIL PROTECTED]> > Date: Thu Nov 15 08:44:36 2007 -0800 > > Revert "skge: fix ram buffer size calculation" > > This reverts commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32. > > Heikki Orsila reports that it causes a regression: > > "Doing > > nc host port < /dev/zero > >on a sending machine (not skge) to an skge machine that is receiving: > > nc -l -p port >/dev/null > >with ~60 MiB/s speed, causes the interface go malfunct. A slow >transfer doesn't cause a problem." > > See > > http://bugzilla.kernel.org/show_bug.cgi?id=9321 > > for some more information. > > There is a workaround (also reported by Heikki): > > "After some fiddling, I noticed that not changing the register write >order on patch: > >+ skge_write32(hw, RB_ADDR(q, RB_END), end); >skge_write32(hw, RB_ADDR(q, RB_WP), start); >skge_write32(hw, RB_ADDR(q, RB_RP), start); >- skge_write32(hw, RB_ADDR(q, RB_END), end); > >fixes the visible effect.. Possibly not the root cause of the >problem, but changing the order back fixes networking here." > > but that has yet to be ack'ed or tested more widely, so the whole > problem-causing commit gets reverted until this is resolved properly. > > Bisected-and-requested-by: Heikki Orsila <[EMAIL PROTECTED]> > Cc: Stephen Hemminger <[EMAIL PROTECTED]> > Cc: Jeff Garzik <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > drivers/net/skge.c | 51 +++ > 1 files changed, 27 insertions(+), 24 deletions(-) Thanks. I pulled commit 8c0863403f109a43d7000b4646da4818220d501f and now the skge driver works here. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 08/16] skge: fix ram buffer size calculation
On Thu, Nov 15, 2007 at 08:48:58AM -0800, Linus Torvalds wrote: This is my commit message for the revert - note the suggested possible fix (but also why I didn't apply it, and why things got reverted). Linus --- commit 279e1dab949d33737557babfe9f74e0b74fbe39a Author: Linus Torvalds [EMAIL PROTECTED] Date: Thu Nov 15 08:44:36 2007 -0800 Revert skge: fix ram buffer size calculation This reverts commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32. Heikki Orsila reports that it causes a regression: Doing nc host port /dev/zero on a sending machine (not skge) to an skge machine that is receiving: nc -l -p port /dev/null with ~60 MiB/s speed, causes the interface go malfunct. A slow transfer doesn't cause a problem. See http://bugzilla.kernel.org/show_bug.cgi?id=9321 for some more information. There is a workaround (also reported by Heikki): After some fiddling, I noticed that not changing the register write order on patch: + skge_write32(hw, RB_ADDR(q, RB_END), end); skge_write32(hw, RB_ADDR(q, RB_WP), start); skge_write32(hw, RB_ADDR(q, RB_RP), start); - skge_write32(hw, RB_ADDR(q, RB_END), end); fixes the visible effect.. Possibly not the root cause of the problem, but changing the order back fixes networking here. but that has yet to be ack'ed or tested more widely, so the whole problem-causing commit gets reverted until this is resolved properly. Bisected-and-requested-by: Heikki Orsila [EMAIL PROTECTED] Cc: Stephen Hemminger [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/net/skge.c | 51 +++ 1 files changed, 27 insertions(+), 24 deletions(-) Thanks. I pulled commit 8c0863403f109a43d7000b4646da4818220d501f and now the skge driver works here. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 08/16] skge: fix ram buffer size calculation
On Thu, Nov 15, 2007 at 08:27:25AM -0800, Stephen Hemminger wrote: > I can't reproduce the users problem with the hardware I have. And > without the patch the dual > port board doesn't work. So it is a question of regression, versus > fixing pre-existing bugs. > I am okay with reverting the patch, as a temporary state, but concerned > with how > to make progress in fixing this. I can reproduce the bug in a second. I will test any version you send me. I take it you have tested the driver on gigabit ethernet by sending zero from one netcat to another (the sending machine being something, and the receiving machine being skge)? The only thing that needed to be done for the last 6 patches in the mainline was reversing the order of two register writes, meaning that the dual port stuff need not be thrown away. This was explained in my bug report (that was hard to read). I'm not suggesting this is a proper fix. In fact, I think it's not, because we can not explain the problem. It would _very_ nice to get to the bottom of this issue, so I would favor reverting the patch and trying and debugging carefully before creating quick and dirty fixes.. Thank you all.. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/16] 2.6.23-stable review, network driver changes
On Wed, Nov 14, 2007 at 10:39:21PM -0800, Greg KH wrote: > This is the start of the stable review cycle for the 2.6.23.X release. > There are 16 patches in this series, all will be posted as a response to > this one. If anyone has any issues with these being applied, please let > us know. > ... > drivers/net/skge.c | 141 > + > drivers/net/skge.h |6 - I found a regression when I applied drivers/net/skge.[ch] patches on top of 2.6.23.1 at stable tree (4367388f04eea72e78347dc9b299698bf4275f92). It hangs the network on high speed transfers. This the same regression that happened for 2.6.24-rc*: http://bugzilla.kernel.org/show_bug.cgi?id=9321 The driver in 2.6.23.1 works for me. Afaik, Stephen Hemminger is working on it. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/16] 2.6.23-stable review, network driver changes
On Wed, Nov 14, 2007 at 10:39:21PM -0800, Greg KH wrote: This is the start of the stable review cycle for the 2.6.23.X release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. ... drivers/net/skge.c | 141 + drivers/net/skge.h |6 - I found a regression when I applied drivers/net/skge.[ch] patches on top of 2.6.23.1 at stable tree (4367388f04eea72e78347dc9b299698bf4275f92). It hangs the network on high speed transfers. This the same regression that happened for 2.6.24-rc*: http://bugzilla.kernel.org/show_bug.cgi?id=9321 The driver in 2.6.23.1 works for me. Afaik, Stephen Hemminger is working on it. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 08/16] skge: fix ram buffer size calculation
On Thu, Nov 15, 2007 at 08:27:25AM -0800, Stephen Hemminger wrote: I can't reproduce the users problem with the hardware I have. And without the patch the dual port board doesn't work. So it is a question of regression, versus fixing pre-existing bugs. I am okay with reverting the patch, as a temporary state, but concerned with how to make progress in fixing this. I can reproduce the bug in a second. I will test any version you send me. I take it you have tested the driver on gigabit ethernet by sending zero from one netcat to another (the sending machine being something, and the receiving machine being skge)? The only thing that needed to be done for the last 6 patches in the mainline was reversing the order of two register writes, meaning that the dual port stuff need not be thrown away. This was explained in my bug report (that was hard to read). I'm not suggesting this is a proper fix. In fact, I think it's not, because we can not explain the problem. It would _very_ nice to get to the bottom of this issue, so I would favor reverting the patch and trying and debugging carefully before creating quick and dirty fixes.. Thank you all.. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 11:54:16AM -0800, Linus Torvalds wrote: > Actually, I'm pretty happy reverting patches that cause regressions even > if it *can* be "fixed for release". If there isn't a fix available within > a day or two, it should get reverted. > ... > Also, please notice the latter part of the suggestion above: even if > somebody has bisected down their problem to a specific commit, I really > *do* want to hear that actually undoing the commit on top of the current > tree acually fixes it again, because sometimes that just isn't the case - > sometimes you end up having various interactions that means that reverting > a commit might simply not even work. Ok. drivers/net/skge has been broken for several weeks. I have manually fixed the driver at each rc* release since then. Please revert skge changes, the commit that broke driver is 7fb7ac241162dc51ec0f7644d4a97b2855213c32 See http://bugzilla.kernel.org/show_bug.cgi?id=9321 for more information. I think Stephen Hemminger is working on the skge fix, but it has been several days since I've heard anything from him. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 11:54:16AM -0800, Linus Torvalds wrote: Actually, I'm pretty happy reverting patches that cause regressions even if it *can* be fixed for release. If there isn't a fix available within a day or two, it should get reverted. ... Also, please notice the latter part of the suggestion above: even if somebody has bisected down their problem to a specific commit, I really *do* want to hear that actually undoing the commit on top of the current tree acually fixes it again, because sometimes that just isn't the case - sometimes you end up having various interactions that means that reverting a commit might simply not even work. Ok. drivers/net/skge has been broken for several weeks. I have manually fixed the driver at each rc* release since then. Please revert skge changes, the commit that broke driver is 7fb7ac241162dc51ec0f7644d4a97b2855213c32 See http://bugzilla.kernel.org/show_bug.cgi?id=9321 for more information. I think Stephen Hemminger is working on the skge fix, but it has been several days since I've heard anything from him. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strage buffer behaviour
On Mon, Nov 12, 2007 at 12:44:53PM -0700, Denys Vlasenko wrote: > IIRC only mounted partitions' reads are cached. That seems to be the case. Thanks. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strage buffer behaviour
On Mon, Nov 12, 2007 at 12:44:53PM -0700, Denys Vlasenko wrote: IIRC only mounted partitions' reads are cached. That seems to be the case. Thanks. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strage buffer behaviour
On Sun, Nov 11, 2007 at 07:33:35PM +0100, Tino Keitel wrote: > I noticed that the kernel (2.6.23.1) seems to buffer only certain > partitions on my system: > > $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null > bs=1024k count=100 ; done ; done > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s > > The dd command reads 100 MB from each partition two times in a row. It > looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but > sda3 and sda4 are (the last 4 dd runs). Strange.. I'm running 2.6.24-rc1 here. Reading data from /dev/hda1 caches well, but not from /dev/sd[ab]1. PS. you can flush caches with: echo 1 > /proc/sys/vm/drop_caches -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strage buffer behaviour
On Sun, Nov 11, 2007 at 07:33:35PM +0100, Tino Keitel wrote: I noticed that the kernel (2.6.23.1) seems to buffer only certain partitions on my system: $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null bs=1024k count=100 ; done ; done 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s The dd command reads 100 MB from each partition two times in a row. It looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but sda3 and sda4 are (the last 4 dd runs). Strange.. I'm running 2.6.24-rc1 here. Reading data from /dev/hda1 caches well, but not from /dev/sd[ab]1. PS. you can flush caches with: echo 1 /proc/sys/vm/drop_caches -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: skge breakage on 2.6.24-rc1
On Wed, Nov 07, 2007 at 03:06:21PM -0800, Andrew Morton wrote: > > On Wed, 7 Nov 2007 23:50:30 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > > wrote: > > On Wednesday, 7 of November 2007, Heikki Orsila wrote: > > > On Wed, Nov 07, 2007 at 11:46:21PM +0200, Heikki Orsila wrote: > > > > After some bisecting, I found that net skge driver broke on > > > > > > > > commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32 > > > Thanks for doing the bisection. It's a good idea to cc the author of the > offending patch after having done this. Sorry, I just forgot this time. Just after the bug report I did mail the author in private (out of the list). -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: skge breakage on 2.6.24-rc1
On Wed, Nov 07, 2007 at 11:46:21PM +0200, Heikki Orsila wrote: > After some bisecting, I found that net skge driver broke on > > commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32 > > My network card is: > > :00:0e.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T > [Marvell] (rev 12) > > Linux cheradenine 2.6.24-rc1-dirty #15 Wed Nov 7 23:39:28 EET 2007 x86_64 > GNU/Linux Sorry, forgot to say what the problem is. Doing nc host port < /dev/zero on a sending machine (not skge) to an skge machine that is receiving: nc -l -p port >/dev/null with ~60 MiB/s speed, causes the interface go malfunct. A slow transfer doesn't cause a problem. Also, after some fiddling, I noticed that not changing the register write order on patch: + skge_write32(hw, RB_ADDR(q, RB_END), end); skge_write32(hw, RB_ADDR(q, RB_WP), start); skge_write32(hw, RB_ADDR(q, RB_RP), start); - skge_write32(hw, RB_ADDR(q, RB_END), end); fixes the visible effect.. Possibly not the root cause of the problem, but changing the order back fixes networking here. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net: skge breakage on 2.6.24-rc1
After some bisecting, I found that net skge driver broke on commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32 My network card is: :00:0e.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) Linux cheradenine 2.6.24-rc1-dirty #15 Wed Nov 7 23:39:28 EET 2007 x86_64 GNU/Linux -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net: skge breakage on 2.6.24-rc1
After some bisecting, I found that net skge driver broke on commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32 My network card is: :00:0e.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) Linux cheradenine 2.6.24-rc1-dirty #15 Wed Nov 7 23:39:28 EET 2007 x86_64 GNU/Linux -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: skge breakage on 2.6.24-rc1
On Wed, Nov 07, 2007 at 11:46:21PM +0200, Heikki Orsila wrote: After some bisecting, I found that net skge driver broke on commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32 My network card is: :00:0e.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) Linux cheradenine 2.6.24-rc1-dirty #15 Wed Nov 7 23:39:28 EET 2007 x86_64 GNU/Linux Sorry, forgot to say what the problem is. Doing nc host port /dev/zero on a sending machine (not skge) to an skge machine that is receiving: nc -l -p port /dev/null with ~60 MiB/s speed, causes the interface go malfunct. A slow transfer doesn't cause a problem. Also, after some fiddling, I noticed that not changing the register write order on patch: + skge_write32(hw, RB_ADDR(q, RB_END), end); skge_write32(hw, RB_ADDR(q, RB_WP), start); skge_write32(hw, RB_ADDR(q, RB_RP), start); - skge_write32(hw, RB_ADDR(q, RB_END), end); fixes the visible effect.. Possibly not the root cause of the problem, but changing the order back fixes networking here. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: skge breakage on 2.6.24-rc1
On Wed, Nov 07, 2007 at 03:06:21PM -0800, Andrew Morton wrote: On Wed, 7 Nov 2007 23:50:30 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Wednesday, 7 of November 2007, Heikki Orsila wrote: On Wed, Nov 07, 2007 at 11:46:21PM +0200, Heikki Orsila wrote: After some bisecting, I found that net skge driver broke on commit 7fb7ac241162dc51ec0f7644d4a97b2855213c32 Thanks for doing the bisection. It's a good idea to cc the author of the offending patch after having done this. Sorry, I just forgot this time. Just after the bug report I did mail the author in private (out of the list). -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange freezes (seems like SATA related)
device 0035 (rev 01) > 63:09.0 Multimedia controller: BittWare, Inc. Unknown device 0035 (rev 01) > 80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) > 80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) > 80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) > 81:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet > Controller (Copper) (rev 06) Mine is a Pentium 4 on Intel chips.. 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 RAID bus controller: Intel Corporation 82801ER (ICH5R) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 04) 02:04.0 RAID bus controller: VIA Technologies, Inc. VT6410 ATA133 RAID controller (rev 06) 02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) If this is the same error, then the problem is not ata_piix/nvidia specific since you seem to have an nvidia SATA controller. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange freezes (seems like SATA related)
PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 81:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Mine is a Pentium 4 on Intel chips.. 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 RAID bus controller: Intel Corporation 82801ER (ICH5R) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 04) 02:04.0 RAID bus controller: VIA Technologies, Inc. VT6410 ATA133 RAID controller (rev 06) 02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) If this is the same error, then the problem is not ata_piix/nvidia specific since you seem to have an nvidia SATA controller. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
On Wed, Oct 31, 2007 at 03:25:54AM -0400, Theodore Tso wrote: > On Tue, Oct 30, 2007 at 03:59:24PM +0200, Heikki Orsila wrote: > > 3. fsck -p on boot failed > > > > (it is very probable not many files were corrupted at this stage) > > Maybe... The system wouldn't have worked as it did, if there were so many broken files before fsck. For example, the system booted properly before fsck. After fsck the grub was broken. So, most files that were corrupted, were unrelated to writes that happened that night. For example, many files at .deb cache at /var were corrupted, but it has been a long time since those were touched. > > 4. I ran fsck.ext3 -y > > > > => that corrupted lots and lots of files. This went > > into a loop, the fsck.ext3 restarted checking over and over again. > > It's possible that e2fsck corrupted the files, but they also could > have been corrupted earlier by the earlier I/O errors. At least there were no IO errors in log files before that night. The only IO error that happened put filesystem into RO state. > There are some > relatively rare filesystem corruptions which e2fsck doesn't handle as > gracefully as it should, though, I will admit. I would need to see > the e2fsck transcript to be sure. Unfortunately, I do not have it. > Were there any messages about needing to relocate inode tables by any > chance? I don't recall. I recall seeing messages about "too many blocks inside inode" and "clearing inodes". There were hundreds or thousands of these messages. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
On Wed, Oct 31, 2007 at 03:25:54AM -0400, Theodore Tso wrote: On Tue, Oct 30, 2007 at 03:59:24PM +0200, Heikki Orsila wrote: 3. fsck -p on boot failed (it is very probable not many files were corrupted at this stage) Maybe... The system wouldn't have worked as it did, if there were so many broken files before fsck. For example, the system booted properly before fsck. After fsck the grub was broken. So, most files that were corrupted, were unrelated to writes that happened that night. For example, many files at .deb cache at /var were corrupted, but it has been a long time since those were touched. 4. I ran fsck.ext3 -y = that corrupted lots and lots of files. This went into a loop, the fsck.ext3 restarted checking over and over again. It's possible that e2fsck corrupted the files, but they also could have been corrupted earlier by the earlier I/O errors. At least there were no IO errors in log files before that night. The only IO error that happened put filesystem into RO state. There are some relatively rare filesystem corruptions which e2fsck doesn't handle as gracefully as it should, though, I will admit. I would need to see the e2fsck transcript to be sure. Unfortunately, I do not have it. Were there any messages about needing to relocate inode tables by any chance? I don't recall. I recall seeing messages about too many blocks inside inode and clearing inodes. There were hundreds or thousands of these messages. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
On Fri, Oct 26, 2007 at 09:21:52PM -0500, Chris Holvenstot wrote: > In each case the failure mode appears to have been the same ??? the system > appears to lock up. When rebooted I get a long string of messages like: > > > Oct 26 20:07:37 localhost kernel: [ 101.581091] ata2: timeout waiting > for ADMA IDLE, stat=0x440 > > Oct 26 20:07:37 localhost kernel: [ 101.581096] sd 1:0:0:0: [sda] Write > Protect is off > > Oct 26 20:07:37 localhost kernel: [ 101.581174] res > 71/04:08:00:00:00/04:00:1d:00:00/e0 Emask 0x1 (device error) > > Oct 26 20:07:37 localhost kernel: [ 101.644992] ata2.00: configured for > UDMA/33 > > Oct 26 20:07:37 localhost kernel: [ 101.644994] ata2: EH complete > > Oct 26 20:07:37 localhost kernel: [ 101.645006] sd 1:0:0:0: [sda] Write > cache: disabled, read cache: enabled, doesn't support DPO or FUA As it turns out, our organizations version control server just blew up last night. The filesystem is rather corrupt at the moment, fortunately we have backups. We are running 2.6.22.5 (vanilla) on Debian 4.0. It has two SATA devices with Linux software raid mirror (mdadm) on Intel ata_piix chipset. The filesystem is EXT3. 1. This happened during nightly backup: init_special_inode: bogus i_mode (17) ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd ca/00:68:6f:3a:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 53248 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: device not ready (errno=-16), forcing hardreset ata1: soft resetting port ata1.00: revalidation failed (errno=-2) ata1: failed to recover some devices, retrying in 5 secs ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA init_special_inode: bogus i_mode (17) init_special_inode: bogus i_mode (17) init_special_inode: bogus i_mode (17) journal_bmap: journal block not found at offset 5133 on md2 Aborting journal on device md2. ext3_abort called. EXT3-fs error (device md2): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only __journal_remove_journal_head: freeing b_committed_data 2. I rebooted 3. fsck -p on boot failed (it is very probable not many files were corrupted at this stage) 4. I ran fsck.ext3 -y => that corrupted lots and lots of files. This went into a loop, the fsck.ext3 restarted checking over and over again. Heikki Orsila - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major SATA / EXT3 Issue?
On Fri, Oct 26, 2007 at 09:21:52PM -0500, Chris Holvenstot wrote: In each case the failure mode appears to have been the same ??? the system appears to lock up. When rebooted I get a long string of messages like: Oct 26 20:07:37 localhost kernel: [ 101.581091] ata2: timeout waiting for ADMA IDLE, stat=0x440 Oct 26 20:07:37 localhost kernel: [ 101.581096] sd 1:0:0:0: [sda] Write Protect is off Oct 26 20:07:37 localhost kernel: [ 101.581174] res 71/04:08:00:00:00/04:00:1d:00:00/e0 Emask 0x1 (device error) Oct 26 20:07:37 localhost kernel: [ 101.644992] ata2.00: configured for UDMA/33 Oct 26 20:07:37 localhost kernel: [ 101.644994] ata2: EH complete Oct 26 20:07:37 localhost kernel: [ 101.645006] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA As it turns out, our organizations version control server just blew up last night. The filesystem is rather corrupt at the moment, fortunately we have backups. We are running 2.6.22.5 (vanilla) on Debian 4.0. It has two SATA devices with Linux software raid mirror (mdadm) on Intel ata_piix chipset. The filesystem is EXT3. 1. This happened during nightly backup: init_special_inode: bogus i_mode (17) ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd ca/00:68:6f:3a:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 53248 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: device not ready (errno=-16), forcing hardreset ata1: soft resetting port ata1.00: revalidation failed (errno=-2) ata1: failed to recover some devices, retrying in 5 secs ata1: soft resetting port ata1.00: configured for UDMA/133 ata1: EH complete sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA init_special_inode: bogus i_mode (17) init_special_inode: bogus i_mode (17) init_special_inode: bogus i_mode (17) journal_bmap: journal block not found at offset 5133 on md2 Aborting journal on device md2. ext3_abort called. EXT3-fs error (device md2): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only __journal_remove_journal_head: freeing b_committed_data 2. I rebooted 3. fsck -p on boot failed (it is very probable not many files were corrupted at this stage) 4. I ran fsck.ext3 -y = that corrupted lots and lots of files. This went into a loop, the fsck.ext3 restarted checking over and over again. Heikki Orsila - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] mthca: allow setting "dmabarrier" on user-allocated memory
On Tue, Oct 02, 2007 at 07:50:07PM -0700, [EMAIL PROTECTED] wrote:
> +struct mthca_reg_mr {
> + __u32 mr_attrs;
> +#define MTHCA_MR_DMAFLUSH 0x1/* flush in-flight DMA on a write to
> + * memory region */
> + __u32 reserved;
> +};
Seems like a very odd place to #define something new..
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] mthca: allow setting dmabarrier on user-allocated memory
On Tue, Oct 02, 2007 at 07:50:07PM -0700, [EMAIL PROTECTED] wrote:
+struct mthca_reg_mr {
+ __u32 mr_attrs;
+#define MTHCA_MR_DMAFLUSH 0x1/* flush in-flight DMA on a write to
+ * memory region */
+ __u32 reserved;
+};
Seems like a very odd place to #define something new..
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Revised signalfd man-page
On Thu, Sep 27, 2007 at 02:19:05PM +0200, Michael Kerrisk wrote: > uint28_t pad[\fIX\fP]; /* Pad size to 128 bytes (allow space > additional fields in the future) */ I think you mean uint8_t.. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revised signalfd man-page
On Thu, Sep 27, 2007 at 02:19:05PM +0200, Michael Kerrisk wrote: uint28_t pad[\fIX\fP]; /* Pad size to 128 bytes (allow space additional fields in the future) */ I think you mean uint8_t.. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On thread scheduling
Consider a simple embedded system:
void interrupt_handler(void)
{
...
}
int main(void)
{
...
}
I would like to "emulate" this system with a workstation to make
development faster. I would create two threads, one executing the
main() function, and the other occasionally calling interrupt_handler().
Before interrupt_handler() is called, the main() thread should be
stopped asynchronously.
I looked into pthreads documentation and found only pthread_kill(thread,
SIGTSTP) to do asynchronous stop, but then I also have to play terminal
tricks to avoid problems..
Is there are function to just disable scheduling of a single thread
without having other side-effects (such as terminal stuff)? Functions
like pthread_disable_scheduling(thread) and
pthread_enable_scheduling(thread) would be good for this..
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On thread scheduling
Consider a simple embedded system:
void interrupt_handler(void)
{
...
}
int main(void)
{
...
}
I would like to emulate this system with a workstation to make
development faster. I would create two threads, one executing the
main() function, and the other occasionally calling interrupt_handler().
Before interrupt_handler() is called, the main() thread should be
stopped asynchronously.
I looked into pthreads documentation and found only pthread_kill(thread,
SIGTSTP) to do asynchronous stop, but then I also have to play terminal
tricks to avoid problems..
Is there are function to just disable scheduling of a single thread
without having other side-effects (such as terminal stuff)? Functions
like pthread_disable_scheduling(thread) and
pthread_enable_scheduling(thread) would be good for this..
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] manpage for fallocate
On Wed, Jul 11, 2007 at 01:48:20AM +0530, Amit K. Arora wrote: > .BI "int syscall(int, int fd, int mode, loff_t offset, loff_t len); Correction: "int syscall(int fd, int mode, ...)", > .SH "ERRORS" > .TP > .B EBADF > .I fd > is not a valid file descriptor, or is not opened for writing. > .TP > .B EFBIG > .I offset+len > exceeds the maximum file size. > .TP > .B EINVAL > .I offset > or > .I len > was less than 0. > .TP > .B ENODEV > .I fd > does not refer to a regular file or a directory. > .TP > .B ENOSPC > There is not enough space left on the device containing the file > referred to by > .IR fd. > .TP > .B ESPIPE > .I fd > refers to a pipe of file descriptor. > .B ENOSYS > The filesystem underlying the file descriptor does not support this > operation. EINTR? -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] manpage for fallocate
On Wed, Jul 11, 2007 at 01:48:20AM +0530, Amit K. Arora wrote: .BI int syscall(int, int fd, int mode, loff_t offset, loff_t len); Correction: int syscall(int fd, int mode, ...), .SH ERRORS .TP .B EBADF .I fd is not a valid file descriptor, or is not opened for writing. .TP .B EFBIG .I offset+len exceeds the maximum file size. .TP .B EINVAL .I offset or .I len was less than 0. .TP .B ENODEV .I fd does not refer to a regular file or a directory. .TP .B ENOSPC There is not enough space left on the device containing the file referred to by .IR fd. .TP .B ESPIPE .I fd refers to a pipe of file descriptor. .B ENOSYS The filesystem underlying the file descriptor does not support this operation. EINTR? -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] some kmalloc/memset ->kzalloc (tree wide)
> Transform some calls to kmalloc/memset to a single kzalloc (or > kcalloc). I looked all the files through. They looked good to me, except one case: In drivers/net/hamradio/dmascc.c you removed one comment, and I think it should not be removed: /* Initialize what is necessary for write_scc and write_scc_data */ -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSA support into kernel?
On Thu, Jul 05, 2007 at 05:53:11PM -0700, Gautam Singaraju wrote: > Is there any attempt being made to provide software based RSA > cryptographic support in kernel? I fail to see how it would be useful. RSA is such a slow operation that doing it in userspace is efficient and safer. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSA support into kernel?
On Thu, Jul 05, 2007 at 05:53:11PM -0700, Gautam Singaraju wrote: Is there any attempt being made to provide software based RSA cryptographic support in kernel? I fail to see how it would be useful. RSA is such a slow operation that doing it in userspace is efficient and safer. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] some kmalloc/memset -kzalloc (tree wide)
Transform some calls to kmalloc/memset to a single kzalloc (or kcalloc). I looked all the files through. They looked good to me, except one case: In drivers/net/hamradio/dmascc.c you removed one comment, and I think it should not be removed: /* Initialize what is necessary for write_scc and write_scc_data */ -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: improvement to volatile considered harmful (resubmit)
I'm resubmitting this as I didn't get any replies, this time CCeing proper people, sorry.. Kernel locking/synchronization primitives are better than volatile types from code readability point of view also. This patch is against 2.6.22-rc6. Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]> diff --git a/Documentation/volatile-considered-harmful.txt b/Documentation/volatile-considered-harmful.txt index 10c2e41..ab9e62e 100644 --- a/Documentation/volatile-considered-harmful.txt +++ b/Documentation/volatile-considered-harmful.txt @@ -17,8 +17,9 @@ all optimization-related problems in a more efficient way. Like volatile, the kernel primitives which make concurrent access to data safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent -unwanted optimization. If they are being used properly, there will be no -need to use volatile as well. If volatile is still necessary, there is +unwanted optimization. If they are being used properly, there will be no +need to use volatile as well. Also, they make code more readable as they +represent their intent explicitly. If volatile is still necessary, there is almost certainly a bug in the code somewhere. In properly-written kernel code, volatile can only serve to slow things down. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Man page correction: epoll (7)
Here's a bit of email I exchanged with Davide Libenzi on epoll (7) man page. There is an error in answer 9: Davide Libenzi wrote: > On Mon, 25 Jun 2007, Heikki Orsila wrote: >> >From epoll man page: >> >>Q9 Do I need to continuously read/write an fd until EAGAIN when >> using the EPOLLET flag ( Edge Triggered behaviour ) ? >> >>A9 No you don't. >> ... >> For example, if you call read(2) by asking to read >> a certain amount of data and read(2) returns a lower number of >> bytes, you can be sure to have exhausted the read I/O space for >> such file descriptor. >> ... >> >> This doesn't seem very true in the general case. Afaik, terminal >> devices can be configured to return only one line per read(). For >> example, >> >> read(terminal_fd, buf, 4096) >> >> will return 34 (the length of the line) but obviously the IO space would >> not be exhausted if _two_ lines arrived into terminal fd during IO wait. >> And thus, arrival of the second line went unnoticed. >> >> Teaching to optimise nonblocking reads will likely cause more bugs. >> >> I'm I correct? If yes, that number should be removed from the question >> list. > > Yes, you are correct. Although the above is true for the majority of > stream files, so it better be fixed with the few counter-examples > instead of being removed. > > - Davide and Davide Libenzi wrote: > Heikki Orsila wrote: >> Maybe so that we say that as a general rule one must read until EAGAIN, >> but mention specific cases where one only needs to wait for "short" >> reads? > > Yes, that's fine with me. So, the Q9 should be changed: Q9 Do I need to continuously read/write an fd until EAGAIN when using the EPOLLET flag ( Edge Triggered behaviour ) ? A9 As a general rule, yes. However, there are exceptions. With some types of fds it is enough to wait until read returns less bytes than was requested by the read call. Are there any fd types where such behavior is guaranteed by the Linux kernel (for the future)? I.e. one can assume that edge-triggered fds will behave properly if x = read(fd, data, count) and x < count ? Regular files? Sockets? What? -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Man page correction: epoll (7)
Here's a bit of email I exchanged with Davide Libenzi on epoll (7) man page. There is an error in answer 9: Davide Libenzi wrote: On Mon, 25 Jun 2007, Heikki Orsila wrote: From epoll man page: Q9 Do I need to continuously read/write an fd until EAGAIN when using the EPOLLET flag ( Edge Triggered behaviour ) ? A9 No you don't. ... For example, if you call read(2) by asking to read a certain amount of data and read(2) returns a lower number of bytes, you can be sure to have exhausted the read I/O space for such file descriptor. ... This doesn't seem very true in the general case. Afaik, terminal devices can be configured to return only one line per read(). For example, read(terminal_fd, buf, 4096) will return 34 (the length of the line) but obviously the IO space would not be exhausted if _two_ lines arrived into terminal fd during IO wait. And thus, arrival of the second line went unnoticed. Teaching to optimise nonblocking reads will likely cause more bugs. I'm I correct? If yes, that number should be removed from the question list. Yes, you are correct. Although the above is true for the majority of stream files, so it better be fixed with the few counter-examples instead of being removed. - Davide and Davide Libenzi wrote: Heikki Orsila wrote: Maybe so that we say that as a general rule one must read until EAGAIN, but mention specific cases where one only needs to wait for short reads? Yes, that's fine with me. So, the Q9 should be changed: Q9 Do I need to continuously read/write an fd until EAGAIN when using the EPOLLET flag ( Edge Triggered behaviour ) ? A9 As a general rule, yes. However, there are exceptions. With some types of fds it is enough to wait until read returns less bytes than was requested by the read call. Are there any fd types where such behavior is guaranteed by the Linux kernel (for the future)? I.e. one can assume that edge-triggered fds will behave properly if x = read(fd, data, count) and x count ? Regular files? Sockets? What? -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: improvement to volatile considered harmful (resubmit)
I'm resubmitting this as I didn't get any replies, this time CCeing proper people, sorry.. Kernel locking/synchronization primitives are better than volatile types from code readability point of view also. This patch is against 2.6.22-rc6. Signed-off-by: Heikki Orsila [EMAIL PROTECTED] diff --git a/Documentation/volatile-considered-harmful.txt b/Documentation/volatile-considered-harmful.txt index 10c2e41..ab9e62e 100644 --- a/Documentation/volatile-considered-harmful.txt +++ b/Documentation/volatile-considered-harmful.txt @@ -17,8 +17,9 @@ all optimization-related problems in a more efficient way. Like volatile, the kernel primitives which make concurrent access to data safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent -unwanted optimization. If they are being used properly, there will be no -need to use volatile as well. If volatile is still necessary, there is +unwanted optimization. If they are being used properly, there will be no +need to use volatile as well. Also, they make code more readable as they +represent their intent explicitly. If volatile is still necessary, there is almost certainly a bug in the code somewhere. In properly-written kernel code, volatile can only serve to slow things down. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: improvement to volatile considered harmful
Kernel locking/synchronization primitives are better than volatile types from code readability point of view also. This patch is against 2.6.22-rc6. Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]> diff --git a/Documentation/volatile-considered-harmful.txt b/Documentation/volatile-considered-harmful.txt index 10c2e41..ab9e62e 100644 --- a/Documentation/volatile-considered-harmful.txt +++ b/Documentation/volatile-considered-harmful.txt @@ -17,8 +17,9 @@ all optimization-related problems in a more efficient way. Like volatile, the kernel primitives which make concurrent access to data safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent -unwanted optimization. If they are being used properly, there will be no -need to use volatile as well. If volatile is still necessary, there is +unwanted optimization. If they are being used properly, there will be no +need to use volatile as well. Also, they make code more readable as they +represent their intent explicitly. If volatile is still necessary, there is almost certainly a bug in the code somewhere. In properly-written kernel code, volatile can only serve to slow things down. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: improvement to volatile considered harmful
Kernel locking/synchronization primitives are better than volatile types from code readability point of view also. This patch is against 2.6.22-rc6. Signed-off-by: Heikki Orsila [EMAIL PROTECTED] diff --git a/Documentation/volatile-considered-harmful.txt b/Documentation/volatile-considered-harmful.txt index 10c2e41..ab9e62e 100644 --- a/Documentation/volatile-considered-harmful.txt +++ b/Documentation/volatile-considered-harmful.txt @@ -17,8 +17,9 @@ all optimization-related problems in a more efficient way. Like volatile, the kernel primitives which make concurrent access to data safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent -unwanted optimization. If they are being used properly, there will be no -need to use volatile as well. If volatile is still necessary, there is +unwanted optimization. If they are being used properly, there will be no +need to use volatile as well. Also, they make code more readable as they +represent their intent explicitly. If volatile is still necessary, there is almost certainly a bug in the code somewhere. In properly-written kernel code, volatile can only serve to slow things down. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove unnecessary ARM SHA-1 preprocessor directive
Remove an unnecessary C style preprocessor directive from ARM SHA-1
assember implementation. It confuses sloccount.
Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]>
diff --git a/arch/arm/lib/sha1.S b/arch/arm/lib/sha1.S
index ff6ece4..67c2bf4 100644
--- a/arch/arm/lib/sha1.S
+++ b/arch/arm/lib/sha1.S
@@ -29,7 +29,7 @@ ENTRY(sha_transform)
stmfd sp!, {r4 - r8, lr}
@ for (i = 0; i < 16; i++)
- @ W[i] = be32_to_cpu(in[i]); */
+ @ W[i] = be32_to_cpu(in[i]);
#ifdef __ARMEB__
mov r4, r0
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove unnecessary ARM SHA-1 preprocessor directive
Remove an unnecessary C style preprocessor directive from ARM SHA-1
assember implementation. It confuses sloccount.
Signed-off-by: Heikki Orsila [EMAIL PROTECTED]
diff --git a/arch/arm/lib/sha1.S b/arch/arm/lib/sha1.S
index ff6ece4..67c2bf4 100644
--- a/arch/arm/lib/sha1.S
+++ b/arch/arm/lib/sha1.S
@@ -29,7 +29,7 @@ ENTRY(sha_transform)
stmfd sp!, {r4 - r8, lr}
@ for (i = 0; i 16; i++)
- @ W[i] = be32_to_cpu(in[i]); */
+ @ W[i] = be32_to_cpu(in[i]);
#ifdef __ARMEB__
mov r4, r0
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, Jun 02, 2007 at 07:10:58AM -0700, Tear wrote: > I would like this patch to be merged into the main > tree. If there is any revision/correction that needs to > be done on the patch, please let me know. You forgot: Signed-off-by: Random J Developer <[EMAIL PROTECTED]> (See Documentation/SubmittingPatches) -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] IO-APIC blacklist
On Sat, Jun 02, 2007 at 07:10:58AM -0700, Tear wrote: I would like this patch to be merged into the main tree. If there is any revision/correction that needs to be done on the patch, please let me know. You forgot: Signed-off-by: Random J Developer [EMAIL PROTECTED] (See Documentation/SubmittingPatches) -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] LZO: Further cleanup of the kernel LZO library headers
On Fri, May 18, 2007 at 03:51:26PM +0100, Richard Purdie wrote: > A further cleanup of the kernel LZO library headers which untangles and > removes ~400 lines of defines. This doesn't change the core minilzo code > so diffability is maintained. You should just throw away that. Guptas implementation is much cleaner, work with that. Putting a few bound checks into Guptas version will solve crashes and overruns by returning an error. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO1X de/compression support
This file is part of the LZO real-time data compression library. > + > + Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 2004 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 2003 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 2002 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 2001 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 2000 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 1999 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 1998 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 1997 Markus Franz Xaver Johannes Oberhumer > + Copyright (C) 1996 Markus Franz Xaver Johannes Oberhumer > + All Rights Reserved. > + > + The LZO library is free software; you can redistribute it and/or > + modify it under the terms of the GNU General Public License, > + version 2, as published by the Free Software Foundation. > + > + The LZO library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + GNU General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with the LZO library; see the file COPYING. > + If not, write to the Free Software Foundation, Inc., > + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + > + Markus F.X.J. Oberhumer > + <[EMAIL PROTECTED]> > + http://www.oberhumer.com/opensource/lzo/ > + > + > + This file was derived from several header files found in original > + LZO 2.02 code. Some additional changes have also been made to make > + it work in kernel space. > + > + Nitin Gupta > + <[EMAIL PROTECTED]> > + */ > + > +#ifndef __LZO1X_INT_H > +#define __LZO1X_INT_H > + > +#include > + > +#define D_SIZE (1u << D_BITS) > +#define D_MASK (D_SIZE - 1) > +#define D_HIGH ((D_MASK >> 1) + 1) > + > +#define DX2(p,s1,s2) \ > + (size_t)((p)[2]) << (s2)) ^ (p)[1]) << (s1)) ^ (p)[0]) > +#define DX3(p,s1,s2,s3) ((DX2((p)+1,s2,s3) << (s1)) ^ (p)[0]) > +#define DMUL(a,b)((size_t) ((a) * (b))) > +#define DMS(v,s) ((size_t) (((v) & (D_MASK >> (s))) << (s))) > +#define DM(v)DMS(v,0) > + > +#define D_BITS 14 > +#define DINDEX1(d,p) d = DM(DMUL(0x21,DX3(p,5,5,6)) >> 5) > +#define DINDEX2(d,p) d = (d & (D_MASK & 0x7ff)) ^ (D_HIGH | 0x1f) > +#define DENTRY(p,in) (p) > + > +#define PTR(a) ((unsigned long) (a)) > +#define PTR_LT(a,b) (PTR(a) < PTR(b)) > +#define PTR_GE(a,b) (PTR(a) >= PTR(b)) > +#define PTR_DIFF(a,b)(PTR(a) - PTR(b)) > +#define pd(a,b) ((size_t) ((a)-(b))) > + > +#define LZO_CHECK_MPOS_NON_DET(m_pos,m_off,in,ip,max_offset) \ > + ( m_pos = ip - (size_t) PTR_DIFF(ip,m_pos), \ > + PTR_LT(m_pos,in) || \ > + (m_off = (size_t) PTR_DIFF(ip,m_pos)) <= 0 || \ > + m_off > max_offset ) > + > +#define COPY4(dst,src) *(uint32_t *)(dst) = *(uint32_t *)(src) Use u32. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb-storage nice value
On Thu, May 17, 2007 at 12:03:08PM +0200, DervishD wrote: > I'm having problems when reading/writing to external USB harddisks: > my *internal* harddisk stalls from time to time, so watching a movie > while copying data is a PITA (well, if the movie is bad, the leaps help > a bit...). I've had a similar problem that is caused due to USB write caching. When a process rapidly writes to a USB device, the whole memory gets filled with write cache. When the memory is full of write cache for USB, it is very slow to get clean pages as the USB device is slow. This stalls the entire system performance. Using sync mount option for USB solves this problem, but decreases write performance significantly. Would it be possible to limit per device write caching to N pages from userspace? Having just 128 MiB of write cache for a USB device would be sufficient for high performance, but yet have plenty of clean pages for other purposes. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb-storage nice value
On Thu, May 17, 2007 at 12:03:08PM +0200, DervishD wrote: I'm having problems when reading/writing to external USB harddisks: my *internal* harddisk stalls from time to time, so watching a movie while copying data is a PITA (well, if the movie is bad, the leaps help a bit...). I've had a similar problem that is caused due to USB write caching. When a process rapidly writes to a USB device, the whole memory gets filled with write cache. When the memory is full of write cache for USB, it is very slow to get clean pages as the USB device is slow. This stalls the entire system performance. Using sync mount option for USB solves this problem, but decreases write performance significantly. Would it be possible to limit per device write caching to N pages from userspace? Having just 128 MiB of write cache for a USB device would be sufficient for high performance, but yet have plenty of clean pages for other purposes. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO1X de/compression support
) +#define DENTRY(p,in) (p) + +#define PTR(a) ((unsigned long) (a)) +#define PTR_LT(a,b) (PTR(a) PTR(b)) +#define PTR_GE(a,b) (PTR(a) = PTR(b)) +#define PTR_DIFF(a,b)(PTR(a) - PTR(b)) +#define pd(a,b) ((size_t) ((a)-(b))) + +#define LZO_CHECK_MPOS_NON_DET(m_pos,m_off,in,ip,max_offset) \ + ( m_pos = ip - (size_t) PTR_DIFF(ip,m_pos), \ + PTR_LT(m_pos,in) || \ + (m_off = (size_t) PTR_DIFF(ip,m_pos)) = 0 || \ + m_off max_offset ) + +#define COPY4(dst,src) *(uint32_t *)(dst) = *(uint32_t *)(src) Use u32. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] LZO: Further cleanup of the kernel LZO library headers
On Fri, May 18, 2007 at 03:51:26PM +0100, Richard Purdie wrote: A further cleanup of the kernel LZO library headers which untangles and removes ~400 lines of defines. This doesn't change the core minilzo code so diffability is maintained. You should just throw away that. Guptas implementation is much cleaner, work with that. Putting a few bound checks into Guptas version will solve crashes and overruns by returning an error. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On __pure and __attribute_pure__
Both __pure and __attribute_pure__ are the same, and I found out that there is only a handful of users for these. __attribute_pure__ is used in approximately 15 places, and __pure is not used anywhere. Is either __pure or __attribute_pure__ preferred? Imo, __pure looks much nicer than __attribute_pure__ so we could do a replacement. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On __pure and __attribute_pure__
Both __pure and __attribute_pure__ are the same, and I found out that there is only a handful of users for these. __attribute_pure__ is used in approximately 15 places, and __pure is not used anywhere. Is either __pure or __attribute_pure__ preferred? Imo, __pure looks much nicer than __attribute_pure__ so we could do a replacement. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] ALSA sound driver for SEGA Dreamcast AICA (pcm)
t; +{
> + /* Allocate a DMA buffer using ALSA built-ins */
> + return
> + snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params));
> +}
> +
> +static int snd_aicapcm_pcm_prepare(struct snd_pcm_substream
> +*substream)
> +{
> + struct snd_card_aica *dreamcastcard = substream->pcm->private_data;
> + if ((substream->runtime)->format == SNDRV_PCM_FORMAT_S16_LE)
> + dreamcastcard->channel->sfmt = SM_16BIT;
> + dreamcastcard->channel->freq = substream->runtime->rate;
> + dreamcastcard->substream = substream;
> + return 0;
> +}
> +
> +static int snd_aicapcm_pcm_trigger(struct snd_pcm_substream
> +*substream, int cmd)
> +{
> + struct snd_card_aica *dreamcastcard;
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + spu_begin_dma(substream);
> + break;
> + case SNDRV_PCM_TRIGGER_STOP:
> + dreamcastcard = substream->pcm->private_data;
> + if (dreamcastcard->timer.data)
> + del_timer(>timer);
> + aica_chn_halt();
> + break;
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static unsigned long snd_aicapcm_pcm_pointer(struct snd_pcm_substream
> + *substream)
> +{
> + return readl(AICA_CONTROL_CHANNEL_SAMPLE_NUMBER);
> +}
> +
> +static struct snd_pcm_ops snd_aicapcm_playback_ops = {
> + .open = snd_aicapcm_pcm_open,
> + .close = snd_aicapcm_pcm_close,
> + .ioctl = snd_pcm_lib_ioctl,
> + .hw_params = snd_aicapcm_pcm_hw_params,
> + .hw_free = snd_aicapcm_pcm_hw_free,
> + .prepare = snd_aicapcm_pcm_prepare,
> + .trigger = snd_aicapcm_pcm_trigger,
> + .pointer = snd_aicapcm_pcm_pointer,
> +};
> +
> +/* TO DO: set up to handle more than one pcm instance */
> +static int __init snd_aicapcmchip(struct snd_card_aica
> + *dreamcastcard, int pcm_index)
> +{
> + struct snd_pcm *pcm;
> + int err;
> + /* AICA has no capture ability */
> + err =
> + snd_pcm_new(dreamcastcard->card, "AICA PCM", pcm_index, 1, 0, );
> + if (unlikely(err < 0))
> + return err;
> + pcm->private_data = dreamcastcard;
> + strcpy(pcm->name, "AICA PCM");
> + snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK,
> + _aicapcm_playback_ops);
> + /* Allocate the DMA buffers */
> + err =
> + snd_pcm_lib_preallocate_pages_for_all(pcm,
> + SNDRV_DMA_TYPE_CONTINUOUS,
> + snd_dma_continuous_data
> + (GFP_KERNEL),
> + AICA_BUFFER_SIZE,
> + AICA_BUFFER_SIZE);
> + return err;
> +}
> +
> +/* Mixer controls */
> +static int aica_pcmswitch_info(struct snd_kcontrol *kcontrol,
> +struct snd_ctl_elem_info *uinfo)
> +{
> + uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
> + uinfo->count = 1;
> + uinfo->value.integer.min = 0;
> + uinfo->value.integer.max = 1;
> + return 0;
> +}
> +
> +static int aica_pcmswitch_get(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + ucontrol->value.integer.value[0] = 1; /* TO DO: Fix me */
> + return 0;
> +}
> +
> +static int aica_pcmswitch_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + if (ucontrol->value.integer.value[0] == 1)
> + return 0; /* TO DO: Fix me */
> + else
> + aica_chn_halt();
> + return 0;
> +}
> +
> +static int aica_pcmvolume_info(struct snd_kcontrol *kcontrol,
> +struct snd_ctl_elem_info *uinfo)
> +{
> + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> + uinfo->count = 1;
> + uinfo->value.integer.min = 0;
> + uinfo->value.integer.max = 0xFF;
> + return 0;
> +}
> +
> +static int aica_pcmvolume_get(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_card_aica *dreamcastcard;
> + dreamcastcard = kcontrol->private_data;
> + if (unlikely(!dreamcastcard->channel))
> + return -ETXTBSY;/* we've not yet been set up */
> + ucontrol->value.integer.value[0] = dreamcastcard->channel->vol;
> + return 0;
> +}
> +
> +static int aica_pcmvolume_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_card_aica *dreamcastcard;
> + dreamcastcard = kcontrol->private_data;
> + if (unlikely(!dreamcastcard->channel))
> + return -ETXTBSY;
> + if (unlikely(dreamcastcard->channel->vol ==
> + ucontrol->value.integer.value[0]))
> + return 0;
> + dreamcastcard->channel->vol = ucontrol->value.integer.value[0];
> + dreamcastcard->master_volume = ucontrol->value.integer.value[0];
> + spu_memload(AICA_CHANNEL0_CONTROL_OFFSET,
> + (u8 *) dreamcastcard->channel,
Unuseful cast again.
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ALSA sound driver for SEGA Dreamcast AICA (pcm)
firmware.bin", >dev);
> + if (unlikely(err))
> + return err;
> + /* write firware into memory */
> + spu_disable();
> + spu_memload(0, fw_entry->data, fw_entry->size);
> + spu_enable();
> + release_firmware(fw_entry);
> + return err;
> +}
> +
> +static int __devinit add_aicamixer_controls(struct snd_card_aica
> + *dreamcastcard)
> +{
> + int err;
> + err = snd_ctl_add
> + (dreamcastcard->card,
> + snd_ctl_new1(_aica_pcmvolume_control, dreamcastcard));
> + if (unlikely(err < 0))
> + return err;
> + err = snd_ctl_add
> + (dreamcastcard->card,
> + snd_ctl_new1(_aica_pcmswitch_control, dreamcastcard));
> + if (unlikely(err < 0))
> + return err;
> + return 0;
> +}
> +
> +static int snd_aica_remove(struct platform_device *devptr)
> +{
> + struct snd_card_aica *dreamcastcard;
> + dreamcastcard = platform_get_drvdata(devptr);
> + if (unlikely(!dreamcastcard))
> + return -ENODEV;
> + snd_card_free(dreamcastcard->card);
> + kfree(dreamcastcard);
> + platform_set_drvdata(devptr, NULL);
> + return 0;
> +}
> +
> +static int __init snd_aica_probe(struct platform_device *devptr)
> +{
> + int err;
> + struct snd_card_aica *dreamcastcard;
> + dreamcastcard = kmalloc(sizeof(struct snd_card_aica), GFP_KERNEL);
> + if (unlikely(!dreamcastcard))
> + return -ENOMEM;
> + dreamcastcard->card =
> + snd_card_new(index, SND_AICA_DRIVER, THIS_MODULE, 0);
> + if (unlikely(!dreamcastcard->card)) {
> + kfree(dreamcastcard);
> + return -ENODEV;
> + }
> + strcpy(dreamcastcard->card->driver, "snd_aica");
> + strcpy(dreamcastcard->card->shortname, SND_AICA_DRIVER);
> + strcpy(dreamcastcard->card->longname,
> +"Yamaha AICA Super Intelligent Sound Processor for SEGA
> Dreamcast");
> + /* Load the PCM 'chip' */
> + err = snd_aicapcmchip(dreamcastcard, 0);
> + if (unlikely(err < 0))
> + goto freedreamcast;
> + snd_card_set_dev(dreamcastcard->card, >dev);
> + dreamcastcard->timer.data = 0;
> + dreamcastcard->channel = NULL;
> + /* Add basic controls */
> + err = add_aicamixer_controls(dreamcastcard);
> + if (unlikely(err < 0))
> + goto freedreamcast;
> + /* Register the card with ALSA subsystem */
> + err = snd_card_register(dreamcastcard->card);
> + if (unlikely(err < 0))
> + goto freedreamcast;
> + platform_set_drvdata(devptr, dreamcastcard);
> + aica_queue = create_workqueue("aica");
Use CARD_NAME instead of "aica" as you already have that defined..
> + if (unlikely(!aica_queue))
> + goto freedreamcast;
> + snd_printk
> + ("ALSA Driver for Yamaha AICA Super Intelligent Sound Processor\n");
> + return 0;
> + freedreamcast:
> + snd_card_free(dreamcastcard->card);
> + kfree(dreamcastcard);
> + return err;
> +}
> +
> +static struct platform_driver snd_aica_driver = {
> + .probe = snd_aica_probe,
> + .remove = snd_aica_remove,
> + .driver = {
> +.name = SND_AICA_DRIVER},
> +};
> +
> +static int __init aica_init(void)
> +{
> + int err;
> + err = platform_driver_register(_aica_driver);
> + if (unlikely(err < 0))
> + return err;
> + pd = platform_device_register_simple(SND_AICA_DRIVER, -1,
> + aica_memory_space, 2);
> + if (unlikely(IS_ERR(pd))) {
> + platform_driver_unregister(_aica_driver);
> + return PTR_ERR(pd);
> + }
> + /* Load the firmware */
> + err = load_aica_firmware();
> + if (unlikely(err < 0))
> + return err;
> +
> + return 0;
> +}
return load_aica_firmware(); ?
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ALSA sound driver for SEGA Dreamcast AICA (pcm)
..
+ if (unlikely(!aica_queue))
+ goto freedreamcast;
+ snd_printk
+ (ALSA Driver for Yamaha AICA Super Intelligent Sound Processor\n);
+ return 0;
+ freedreamcast:
+ snd_card_free(dreamcastcard-card);
+ kfree(dreamcastcard);
+ return err;
+}
+
+static struct platform_driver snd_aica_driver = {
+ .probe = snd_aica_probe,
+ .remove = snd_aica_remove,
+ .driver = {
+.name = SND_AICA_DRIVER},
+};
+
+static int __init aica_init(void)
+{
+ int err;
+ err = platform_driver_register(snd_aica_driver);
+ if (unlikely(err 0))
+ return err;
+ pd = platform_device_register_simple(SND_AICA_DRIVER, -1,
+ aica_memory_space, 2);
+ if (unlikely(IS_ERR(pd))) {
+ platform_driver_unregister(snd_aica_driver);
+ return PTR_ERR(pd);
+ }
+ /* Load the firmware */
+ err = load_aica_firmware();
+ if (unlikely(err 0))
+ return err;
+
+ return 0;
+}
return load_aica_firmware(); ?
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] ALSA sound driver for SEGA Dreamcast AICA (pcm)
;
+ }
+ return 0;
+}
+
+static unsigned long snd_aicapcm_pcm_pointer(struct snd_pcm_substream
+ *substream)
+{
+ return readl(AICA_CONTROL_CHANNEL_SAMPLE_NUMBER);
+}
+
+static struct snd_pcm_ops snd_aicapcm_playback_ops = {
+ .open = snd_aicapcm_pcm_open,
+ .close = snd_aicapcm_pcm_close,
+ .ioctl = snd_pcm_lib_ioctl,
+ .hw_params = snd_aicapcm_pcm_hw_params,
+ .hw_free = snd_aicapcm_pcm_hw_free,
+ .prepare = snd_aicapcm_pcm_prepare,
+ .trigger = snd_aicapcm_pcm_trigger,
+ .pointer = snd_aicapcm_pcm_pointer,
+};
+
+/* TO DO: set up to handle more than one pcm instance */
+static int __init snd_aicapcmchip(struct snd_card_aica
+ *dreamcastcard, int pcm_index)
+{
+ struct snd_pcm *pcm;
+ int err;
+ /* AICA has no capture ability */
+ err =
+ snd_pcm_new(dreamcastcard-card, AICA PCM, pcm_index, 1, 0, pcm);
+ if (unlikely(err 0))
+ return err;
+ pcm-private_data = dreamcastcard;
+ strcpy(pcm-name, AICA PCM);
+ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK,
+ snd_aicapcm_playback_ops);
+ /* Allocate the DMA buffers */
+ err =
+ snd_pcm_lib_preallocate_pages_for_all(pcm,
+ SNDRV_DMA_TYPE_CONTINUOUS,
+ snd_dma_continuous_data
+ (GFP_KERNEL),
+ AICA_BUFFER_SIZE,
+ AICA_BUFFER_SIZE);
+ return err;
+}
+
+/* Mixer controls */
+static int aica_pcmswitch_info(struct snd_kcontrol *kcontrol,
+struct snd_ctl_elem_info *uinfo)
+{
+ uinfo-type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
+ uinfo-count = 1;
+ uinfo-value.integer.min = 0;
+ uinfo-value.integer.max = 1;
+ return 0;
+}
+
+static int aica_pcmswitch_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ ucontrol-value.integer.value[0] = 1; /* TO DO: Fix me */
+ return 0;
+}
+
+static int aica_pcmswitch_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ if (ucontrol-value.integer.value[0] == 1)
+ return 0; /* TO DO: Fix me */
+ else
+ aica_chn_halt();
+ return 0;
+}
+
+static int aica_pcmvolume_info(struct snd_kcontrol *kcontrol,
+struct snd_ctl_elem_info *uinfo)
+{
+ uinfo-type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+ uinfo-count = 1;
+ uinfo-value.integer.min = 0;
+ uinfo-value.integer.max = 0xFF;
+ return 0;
+}
+
+static int aica_pcmvolume_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_card_aica *dreamcastcard;
+ dreamcastcard = kcontrol-private_data;
+ if (unlikely(!dreamcastcard-channel))
+ return -ETXTBSY;/* we've not yet been set up */
+ ucontrol-value.integer.value[0] = dreamcastcard-channel-vol;
+ return 0;
+}
+
+static int aica_pcmvolume_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_card_aica *dreamcastcard;
+ dreamcastcard = kcontrol-private_data;
+ if (unlikely(!dreamcastcard-channel))
+ return -ETXTBSY;
+ if (unlikely(dreamcastcard-channel-vol ==
+ ucontrol-value.integer.value[0]))
+ return 0;
+ dreamcastcard-channel-vol = ucontrol-value.integer.value[0];
+ dreamcastcard-master_volume = ucontrol-value.integer.value[0];
+ spu_memload(AICA_CHANNEL0_CONTROL_OFFSET,
+ (u8 *) dreamcastcard-channel,
Unuseful cast again.
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] "volatile considered harmful", take 3
On Sat, May 12, 2007 at 09:53:03AM +0200, Stefan Richter wrote: > H. Peter Anvin wrote: > [slightly off topic: GCCisms in Linux kernel] > > It contains *many* constructs that are not defined in, for > > example, C99, and it would in fact be impossible to write the Linux > > kernel using only C99-compliant constructs. > > True. On the other hand, it is possible to keep large parts of the > kernel independent of compiler implementation details. And it is not > only possible but also beneficial, e.g. because the compiler's > implementation changes over time. I think the most important reason for portable code is that new readers are more familiar with effects of the code. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] volatile considered harmful, take 3
On Sat, May 12, 2007 at 09:53:03AM +0200, Stefan Richter wrote: H. Peter Anvin wrote: [slightly off topic: GCCisms in Linux kernel] It contains *many* constructs that are not defined in, for example, C99, and it would in fact be impossible to write the Linux kernel using only C99-compliant constructs. True. On the other hand, it is possible to keep large parts of the kernel independent of compiler implementation details. And it is not only possible but also beneficial, e.g. because the compiler's implementation changes over time. I think the most important reason for portable code is that new readers are more familiar with effects of the code. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] "volatile considered harmful" document
Imo, the best style to relay information is by directly stating facts. I'm going to try to suggest some improvements on this.. On Wed, May 09, 2007 at 03:05:44PM -0600, Jonathan Corbet wrote: > Andrew Morton recently called out[1] use of volatile in a > +submitted patch, saying: > + > + The volatiles are a worry - volatile is said to be > + basically-always-wrong in-kernel, although we've never managed to > + document why, and i386 cheerfully uses it in readb() and friends. > + > +In response, Randy Dunlap pulled together some email from Linus[2] on the > +topic and suggested that we could maybe "document why." Here is the > +result. I think previous text is unnecessary. Just tell the reasons why volatile is bad and what should be used instead, no need to quote people. > +The point that Linus often makes with regard to volatile is that > +its purpose is to suppress optimization, which is almost never what one > +really wants to do. In the kernel, one must protect accesses to data > +against race conditions, which is very much a different task. Again, I would write this in non-personal way: "Volatile is often used to prevent optimization, but it is not the behavior that is actually wanted. Access to data must be protected and handled with kernel provided synchronization, mutual exclusion and barriers tools. These tools make volatile useless." > +Like volatile, the kernel primitives which make concurrent access to data > +safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent > +unwanted optimization. If they are being used properly, there will be no > +need to use volatile as well. The previous suggestion takes care of explaining that, remove this. > If volatile is still necessary, there is > +almost certainly a bug in the code somewhere. In properly-written kernel > +code, volatile can only serve to slow things down. > + > +Consider a typical block of kernel code: > + > +spin_lock(_lock); > +do_something_on(_data); > +do_something_else_with(_data); > +spin_unlock(_lock); > + > +If all the code follows the locking rules, the value of shared_data cannot > +change unexpectedly while the_lock is held. Any other code which might > +want to play with that data will be waiting on the lock. Ok > +The spinlock > +primitives act as memory barriers - they are explicitly written to do so - > +meaning that data accesses will not be optimized across them. "Spinlock primitives will serialise execution of code regions, and memory barrier functions must be used inside spinlocks to force loads and stores." > So the > +compiler might think it knows what will be in some_data, but the > +spin_lock() call will force it to forget anything it knows. There will be > +no optimization problems with accesses to that data. I would say it directly: "Spinlock will force an implicit memory barrier, thus preventing optimizations to data access." > +If shared_data were declared volatile, the locking would > +still be necessary. But the compiler would also be prevented from > +optimizing access to shared _within_ the critical section, > +when we know that nobody else can be working with it. While the lock is > +held, shared_data is not volatile. ok > This is why Linus says: > + > + Also, more importantly, "volatile" is on the wrong _part_ of the > + whole system. In C, it's "data" that is volatile, but that is > + insane. Data isn't volatile - _accesses_ are volatile. So it may > + make sense to say "make this particular _access_ be careful", but > + not "make all accesses to this data use some random strategy". Unnecessary quoting, imo. Tell the same information directly without personifying the statement. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] volatile considered harmful document
Imo, the best style to relay information is by directly stating facts. I'm going to try to suggest some improvements on this.. On Wed, May 09, 2007 at 03:05:44PM -0600, Jonathan Corbet wrote: Andrew Morton recently called out[1] use of volatile in a +submitted patch, saying: + + The volatiles are a worry - volatile is said to be + basically-always-wrong in-kernel, although we've never managed to + document why, and i386 cheerfully uses it in readb() and friends. + +In response, Randy Dunlap pulled together some email from Linus[2] on the +topic and suggested that we could maybe document why. Here is the +result. I think previous text is unnecessary. Just tell the reasons why volatile is bad and what should be used instead, no need to quote people. +The point that Linus often makes with regard to volatile is that +its purpose is to suppress optimization, which is almost never what one +really wants to do. In the kernel, one must protect accesses to data +against race conditions, which is very much a different task. Again, I would write this in non-personal way: Volatile is often used to prevent optimization, but it is not the behavior that is actually wanted. Access to data must be protected and handled with kernel provided synchronization, mutual exclusion and barriers tools. These tools make volatile useless. +Like volatile, the kernel primitives which make concurrent access to data +safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent +unwanted optimization. If they are being used properly, there will be no +need to use volatile as well. The previous suggestion takes care of explaining that, remove this. If volatile is still necessary, there is +almost certainly a bug in the code somewhere. In properly-written kernel +code, volatile can only serve to slow things down. + +Consider a typical block of kernel code: + +spin_lock(the_lock); +do_something_on(shared_data); +do_something_else_with(shared_data); +spin_unlock(the_lock); + +If all the code follows the locking rules, the value of shared_data cannot +change unexpectedly while the_lock is held. Any other code which might +want to play with that data will be waiting on the lock. Ok +The spinlock +primitives act as memory barriers - they are explicitly written to do so - +meaning that data accesses will not be optimized across them. Spinlock primitives will serialise execution of code regions, and memory barrier functions must be used inside spinlocks to force loads and stores. So the +compiler might think it knows what will be in some_data, but the +spin_lock() call will force it to forget anything it knows. There will be +no optimization problems with accesses to that data. I would say it directly: Spinlock will force an implicit memory barrier, thus preventing optimizations to data access. +If shared_data were declared volatile, the locking would +still be necessary. But the compiler would also be prevented from +optimizing access to shared _within_ the critical section, +when we know that nobody else can be working with it. While the lock is +held, shared_data is not volatile. ok This is why Linus says: + + Also, more importantly, volatile is on the wrong _part_ of the + whole system. In C, it's data that is volatile, but that is + insane. Data isn't volatile - _accesses_ are volatile. So it may + make sense to say make this particular _access_ be careful, but + not make all accesses to this data use some random strategy. Unnecessary quoting, imo. Tell the same information directly without personifying the statement. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: eata.c potential namespace collision and optimisation
This fixes a potential namespace collision and does an optimisation for
2.6.20 drivers/scsi/eata.c:
* sort() is renamed to eata_sort() to avoid conflict with kernel
proper sort(). It does _not_ conflict currently in 2.6.20 so
this is a pre-emptive change.
* in eata_sort(), one if-condition per loop iteration is avoided
by moving the comparison out of the loop
Warning: The patch compiles but is not tested with real hardware since I
don't have the card.
diffstat:
eata.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]>
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
diff -upr linux-2.6.20-org/drivers/scsi/eata.c linux-2.6.20/drivers/scsi/eata.c
--- linux-2.6.20-org/drivers/scsi/eata.c2007-02-04 20:44:54.0
+0200
+++ linux-2.6.20/drivers/scsi/eata.c2007-02-24 15:43:08.0 +0200
@@ -2089,8 +2089,8 @@ int eata2x_bios_param(struct scsi_device
return 0;
}
-static void sort(unsigned long sk[], unsigned int da[], unsigned int n,
-unsigned int rev)
+static void eata_sort(unsigned long sk[], unsigned int da[], unsigned int n,
+ unsigned int rev)
{
unsigned int i, j, k, y;
unsigned long x;
@@ -2098,14 +2098,17 @@ static void sort(unsigned long sk[], uns
for (i = 0; i < n - 1; i++) {
k = i;
- for (j = k + 1; j < n; j++)
- if (rev) {
+ if (rev) {
+ for (j = k + 1; j < n; j++) {
if (sk[j] > sk[k])
k = j;
- } else {
+ }
+ } else {
+ for (j = k + 1; j < n; j++) {
if (sk[j] < sk[k])
k = j;
}
+ }
if (k != i) {
x = sk[k];
@@ -2116,8 +2119,6 @@ static void sort(unsigned long sk[], uns
da[i] = y;
}
}
-
- return;
}
static int reorder(struct hostdata *ha, unsigned long cursec,
@@ -2194,7 +2195,7 @@ static int reorder(struct hostdata *ha,
rev = 0;
if (!((rev && r) || (!rev && s)))
- sort(sl, il, n_ready, rev);
+ eata_sort(sl, il, n_ready, rev);
if (!input_only)
for (n = 0; n < n_ready; n++) {
@@ -2214,7 +2215,7 @@ static int reorder(struct hostdata *ha,
}
if (overlap)
- sort(pl, il, n_ready, 0);
+ eata_sort(pl, il, n_ready, 0);
if (link_statistics) {
if (cursec > sl[0])
[PATCH] scsi: eata.c potential namespace collision and optimisation
This fixes a potential namespace collision and does an optimisation for
2.6.20 drivers/scsi/eata.c:
* sort() is renamed to eata_sort() to avoid conflict with kernel
proper sort(). It does _not_ conflict currently in 2.6.20 so
this is a pre-emptive change.
* in eata_sort(), one if-condition per loop iteration is avoided
by moving the comparison out of the loop
Warning: The patch compiles but is not tested with real hardware since I
don't have the card.
diffstat:
eata.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
Signed-off-by: Heikki Orsila [EMAIL PROTECTED]
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
diff -upr linux-2.6.20-org/drivers/scsi/eata.c linux-2.6.20/drivers/scsi/eata.c
--- linux-2.6.20-org/drivers/scsi/eata.c2007-02-04 20:44:54.0
+0200
+++ linux-2.6.20/drivers/scsi/eata.c2007-02-24 15:43:08.0 +0200
@@ -2089,8 +2089,8 @@ int eata2x_bios_param(struct scsi_device
return 0;
}
-static void sort(unsigned long sk[], unsigned int da[], unsigned int n,
-unsigned int rev)
+static void eata_sort(unsigned long sk[], unsigned int da[], unsigned int n,
+ unsigned int rev)
{
unsigned int i, j, k, y;
unsigned long x;
@@ -2098,14 +2098,17 @@ static void sort(unsigned long sk[], uns
for (i = 0; i n - 1; i++) {
k = i;
- for (j = k + 1; j n; j++)
- if (rev) {
+ if (rev) {
+ for (j = k + 1; j n; j++) {
if (sk[j] sk[k])
k = j;
- } else {
+ }
+ } else {
+ for (j = k + 1; j n; j++) {
if (sk[j] sk[k])
k = j;
}
+ }
if (k != i) {
x = sk[k];
@@ -2116,8 +2119,6 @@ static void sort(unsigned long sk[], uns
da[i] = y;
}
}
-
- return;
}
static int reorder(struct hostdata *ha, unsigned long cursec,
@@ -2194,7 +2195,7 @@ static int reorder(struct hostdata *ha,
rev = 0;
if (!((rev r) || (!rev s)))
- sort(sl, il, n_ready, rev);
+ eata_sort(sl, il, n_ready, rev);
if (!input_only)
for (n = 0; n n_ready; n++) {
@@ -2214,7 +2215,7 @@ static int reorder(struct hostdata *ha,
}
if (overlap)
- sort(pl, il, n_ready, 0);
+ eata_sort(pl, il, n_ready, 0);
if (link_statistics) {
if (cursec sl[0])
[RFC] New driver information
I just read http://kerneltrap.org/node/7729 and it occured to me that it would be informative to have a new device driver macro. The motivation for the new macro would be 4 issues: * Is it possible to get specifications for the device? * If yes, under what terms? (nda, public) * Where to get public specs? * How many closed and open drivers in the Linux source tree? I suggest to add following macro: MODULE_SPECIFICATION(terms, source); where "terms" is one of * MODULE_SPEC_ANY_PARTY_NDA - specification available to any party for an NDA * MODULE_SPEC_ANY_PARTY - specification available in public, or at least available without NDA to any party * MODULE_SPEC_RESTRICTED - none of the above and "source": * contact address for nda specs * any public source for a public specification (http://, email address, ...) * empty string otherwise I realise this macro somewhat circumvents the purpose of Documentation/ directory but the idea is to have a direct 1:1 mapping between drivers and specification sources so that it would be easy to collect statistics of "open" hardware by using grep et al. What do you think? Useless annotations or useful information? -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] New driver information
I just read http://kerneltrap.org/node/7729 and it occured to me that it would be informative to have a new device driver macro. The motivation for the new macro would be 4 issues: * Is it possible to get specifications for the device? * If yes, under what terms? (nda, public) * Where to get public specs? * How many closed and open drivers in the Linux source tree? I suggest to add following macro: MODULE_SPECIFICATION(terms, source); where terms is one of * MODULE_SPEC_ANY_PARTY_NDA - specification available to any party for an NDA * MODULE_SPEC_ANY_PARTY - specification available in public, or at least available without NDA to any party * MODULE_SPEC_RESTRICTED - none of the above and source: * contact address for nda specs * any public source for a public specification (http://, email address, ...) * empty string otherwise I realise this macro somewhat circumvents the purpose of Documentation/ directory but the idea is to have a direct 1:1 mapping between drivers and specification sources so that it would be easy to collect statistics of open hardware by using grep et al. What do you think? Useless annotations or useful information? -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 000/196] V4L/DVB updates
On Thu, Feb 15, 2007 at 03:59:55AM -0200, Mauro Carvalho Chehab wrote: > Basically, this series adds support for a bunch of newer cards and newer > drivers, do some relevant cleanups on cx88 (improving source code > readability and reducing binary code size), adds FM radio support on > pvrusb2 and do several other fixes and improvements. > > A more detailed log: > > [removed 100+ lines of stuff] > > > PS.: Due to the size of this series, I'm not mailbombing them into LKML. > > V4L/DVB development is hosted at http://linuxtv.org Why weren't these submitted in smaller batches? Why were all these patches held back before releasing any? Heikki Orsila - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 000/196] V4L/DVB updates
On Thu, Feb 15, 2007 at 03:59:55AM -0200, Mauro Carvalho Chehab wrote: Basically, this series adds support for a bunch of newer cards and newer drivers, do some relevant cleanups on cx88 (improving source code readability and reducing binary code size), adds FM radio support on pvrusb2 and do several other fixes and improvements. A more detailed log: [removed 100+ lines of stuff] PS.: Due to the size of this series, I'm not mailbombing them into LKML. V4L/DVB development is hosted at http://linuxtv.org Why weren't these submitted in smaller batches? Why were all these patches held back before releasing any? Heikki Orsila - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] saa7134: cleanup
A cleanup patch against 2.6.20 for saa7134 video4linux driver:
- use generic sort instead of bubblesort
- removed useless saa7134_video_fini function
- small coding style changes
Signed-off-by: Heikki Orsila <[EMAIL PROTECTED]>
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
diff -urp linux-2.6.20-org/drivers/media/video/saa7134/saa7134-core.c
linux-2.6.20/drivers/media/video/saa7134/saa7134-core.c
--- linux-2.6.20-org/drivers/media/video/saa7134/saa7134-core.c 2007-02-04
20:44:54.0 +0200
+++ linux-2.6.20/drivers/media/video/saa7134/saa7134-core.c 2007-02-10
00:51:01.0 +0200
@@ -703,7 +703,6 @@ static int saa7134_hwfini(struct saa7134
saa7134_ts_fini(dev);
saa7134_input_fini(dev);
saa7134_vbi_fini(dev);
- saa7134_video_fini(dev);
saa7134_tvaudio_fini(dev);
return 0;
}
diff -urp linux-2.6.20-org/drivers/media/video/saa7134/saa7134-video.c
linux-2.6.20/drivers/media/video/saa7134/saa7134-video.c
--- linux-2.6.20-org/drivers/media/video/saa7134/saa7134-video.c
2007-02-04 20:44:54.0 +0200
+++ linux-2.6.20/drivers/media/video/saa7134/saa7134-video.c2007-02-10
00:51:01.0 +0200
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "saa7134-reg.h"
#include "saa7134.h"
@@ -516,14 +517,12 @@ static int res_get(struct saa7134_dev *d
return 1;
}
-static
-int res_check(struct saa7134_fh *fh, unsigned int bit)
+static int res_check(struct saa7134_fh *fh, unsigned int bit)
{
return (fh->resources & bit);
}
-static
-int res_locked(struct saa7134_dev *dev, unsigned int bit)
+static int res_locked(struct saa7134_dev *dev, unsigned int bit)
{
return (dev->resources & bit);
}
@@ -732,25 +731,6 @@ struct cliplist {
__u8 disable;
};
-static void sort_cliplist(struct cliplist *cl, int entries)
-{
- struct cliplist swap;
- int i,j,n;
-
- for (i = entries-2; i >= 0; i--) {
- for (n = 0, j = 0; j <= i; j++) {
- if (cl[j].position > cl[j+1].position) {
- swap = cl[j];
- cl[j] = cl[j+1];
- cl[j+1] = swap;
- n++;
- }
- }
- if (0 == n)
- break;
- }
-}
-
static void set_cliplist(struct saa7134_dev *dev, int reg,
struct cliplist *cl, int entries, char *name)
{
@@ -784,15 +764,27 @@ static int clip_range(int val)
return val;
}
+/* Sort into smallest position first order */
+static int cliplist_cmp(const void *a, const void *b)
+{
+ const struct cliplist *cla = a;
+ const struct cliplist *clb = b;
+ if (cla->position < clb->position)
+ return -1;
+ if (cla->position > clb->position)
+ return 1;
+ return 0;
+}
+
static int setup_clipping(struct saa7134_dev *dev, struct v4l2_clip *clips,
int nclips, int interlace)
{
struct cliplist col[16], row[16];
- int cols, rows, i;
+ int cols = 0, rows = 0, i;
int div = interlace ? 2 : 1;
- memset(col,0,sizeof(col)); cols = 0;
- memset(row,0,sizeof(row)); rows = 0;
+ memset(col, 0, sizeof(col));
+ memset(row, 0, sizeof(row));
for (i = 0; i < nclips && i < 8; i++) {
col[cols].position = clip_range(clips[i].c.left);
col[cols].enable = (1 << i);
@@ -808,8 +800,8 @@ static int setup_clipping(struct saa7134
row[rows].disable = (1 << i);
rows++;
}
- sort_cliplist(col,cols);
- sort_cliplist(row,rows);
+ sort(col, cols, sizeof col[0], cliplist_cmp, NULL);
+ sort(row, rows, sizeof row[0], cliplist_cmp, NULL);
set_cliplist(dev,0x380,col,cols,"cols");
set_cliplist(dev,0x384,row,rows,"rows");
return 0;
@@ -1261,19 +1253,14 @@ static struct videobuf_queue* saa7134_qu
static int saa7134_resource(struct saa7134_fh *fh)
{
- int res = 0;
+ if (fh->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return RESOURCE_VIDEO;
- switch (fh->type) {
- case V4L2_BUF_TYPE_VIDEO_CAPTURE:
- res = RESOURCE_VIDEO;
- break;
- case V4L2_BUF_TYPE_VBI_CAPTURE:
- res = RESOURCE_VBI;
- break;
- default:
- BUG();
- }
- return res;
+ if (fh->type == V4L2_BUF_TYPE_VBI_CAPTURE)
+ return RESOURCE_VBI;
+
+ BUG();
+ return 0;
}
static int video_open(struct inode *inode, struct file *file)
@@ -1461,8 +1448,7 @@ static int video_release(s
[PATCH] saa7134: cleanup
A cleanup patch against 2.6.20 for saa7134 video4linux driver:
- use generic sort instead of bubblesort
- removed useless saa7134_video_fini function
- small coding style changes
Signed-off-by: Heikki Orsila [EMAIL PROTECTED]
--
Heikki Orsila Barbie's law:
[EMAIL PROTECTED] Math is hard, let's go shopping!
http://www.iki.fi/shd
diff -urp linux-2.6.20-org/drivers/media/video/saa7134/saa7134-core.c
linux-2.6.20/drivers/media/video/saa7134/saa7134-core.c
--- linux-2.6.20-org/drivers/media/video/saa7134/saa7134-core.c 2007-02-04
20:44:54.0 +0200
+++ linux-2.6.20/drivers/media/video/saa7134/saa7134-core.c 2007-02-10
00:51:01.0 +0200
@@ -703,7 +703,6 @@ static int saa7134_hwfini(struct saa7134
saa7134_ts_fini(dev);
saa7134_input_fini(dev);
saa7134_vbi_fini(dev);
- saa7134_video_fini(dev);
saa7134_tvaudio_fini(dev);
return 0;
}
diff -urp linux-2.6.20-org/drivers/media/video/saa7134/saa7134-video.c
linux-2.6.20/drivers/media/video/saa7134/saa7134-video.c
--- linux-2.6.20-org/drivers/media/video/saa7134/saa7134-video.c
2007-02-04 20:44:54.0 +0200
+++ linux-2.6.20/drivers/media/video/saa7134/saa7134-video.c2007-02-10
00:51:01.0 +0200
@@ -26,6 +26,7 @@
#include linux/moduleparam.h
#include linux/kernel.h
#include linux/slab.h
+#include linux/sort.h
#include saa7134-reg.h
#include saa7134.h
@@ -516,14 +517,12 @@ static int res_get(struct saa7134_dev *d
return 1;
}
-static
-int res_check(struct saa7134_fh *fh, unsigned int bit)
+static int res_check(struct saa7134_fh *fh, unsigned int bit)
{
return (fh-resources bit);
}
-static
-int res_locked(struct saa7134_dev *dev, unsigned int bit)
+static int res_locked(struct saa7134_dev *dev, unsigned int bit)
{
return (dev-resources bit);
}
@@ -732,25 +731,6 @@ struct cliplist {
__u8 disable;
};
-static void sort_cliplist(struct cliplist *cl, int entries)
-{
- struct cliplist swap;
- int i,j,n;
-
- for (i = entries-2; i = 0; i--) {
- for (n = 0, j = 0; j = i; j++) {
- if (cl[j].position cl[j+1].position) {
- swap = cl[j];
- cl[j] = cl[j+1];
- cl[j+1] = swap;
- n++;
- }
- }
- if (0 == n)
- break;
- }
-}
-
static void set_cliplist(struct saa7134_dev *dev, int reg,
struct cliplist *cl, int entries, char *name)
{
@@ -784,15 +764,27 @@ static int clip_range(int val)
return val;
}
+/* Sort into smallest position first order */
+static int cliplist_cmp(const void *a, const void *b)
+{
+ const struct cliplist *cla = a;
+ const struct cliplist *clb = b;
+ if (cla-position clb-position)
+ return -1;
+ if (cla-position clb-position)
+ return 1;
+ return 0;
+}
+
static int setup_clipping(struct saa7134_dev *dev, struct v4l2_clip *clips,
int nclips, int interlace)
{
struct cliplist col[16], row[16];
- int cols, rows, i;
+ int cols = 0, rows = 0, i;
int div = interlace ? 2 : 1;
- memset(col,0,sizeof(col)); cols = 0;
- memset(row,0,sizeof(row)); rows = 0;
+ memset(col, 0, sizeof(col));
+ memset(row, 0, sizeof(row));
for (i = 0; i nclips i 8; i++) {
col[cols].position = clip_range(clips[i].c.left);
col[cols].enable = (1 i);
@@ -808,8 +800,8 @@ static int setup_clipping(struct saa7134
row[rows].disable = (1 i);
rows++;
}
- sort_cliplist(col,cols);
- sort_cliplist(row,rows);
+ sort(col, cols, sizeof col[0], cliplist_cmp, NULL);
+ sort(row, rows, sizeof row[0], cliplist_cmp, NULL);
set_cliplist(dev,0x380,col,cols,cols);
set_cliplist(dev,0x384,row,rows,rows);
return 0;
@@ -1261,19 +1253,14 @@ static struct videobuf_queue* saa7134_qu
static int saa7134_resource(struct saa7134_fh *fh)
{
- int res = 0;
+ if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return RESOURCE_VIDEO;
- switch (fh-type) {
- case V4L2_BUF_TYPE_VIDEO_CAPTURE:
- res = RESOURCE_VIDEO;
- break;
- case V4L2_BUF_TYPE_VBI_CAPTURE:
- res = RESOURCE_VBI;
- break;
- default:
- BUG();
- }
- return res;
+ if (fh-type == V4L2_BUF_TYPE_VBI_CAPTURE)
+ return RESOURCE_VBI;
+
+ BUG();
+ return 0;
}
static int video_open(struct inode *inode, struct file *file)
@@ -1461,8 +1448,7 @@ static int video_release(struct inode *i
return 0;
}
-static int
-video_mmap(struct file *file, struct vm_area_struct * vma)
+static
Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
On Sun, Jan 21, 2007 at 11:40:40AM +0100, Bodo Eggert wrote: > 1) This change isn't nescensary - any sane person will know that it's not a >SI unit. You wouldn't talk about megabananas == 100 bananas and >expect to be taken seriously. I've met quite a few non-sane persons then. I find using kilo, mega and giga prefixes convenient to use. For example, I often use GEUR to refer to Giga Euros, because the word billion is overloaded. > 2) No sane person would say kibibyte as required by the standard. You'd need >a sppech defect in order to do this, and a mental defect in order to try. >So why should anybody adhere to the rest of this bullshit? I think I'm not sane then. I find it easy to use and pronounce. IEC 60027-2 is a great standard! It removes some annoying ambiquity in speech and text. Adhering strictly to proper SI units (k, M, G, ...) makes life easier as they are taught in school to everyone. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB-KiB, MB - MiB, ... (IEC 60027-2)
On Sun, Jan 21, 2007 at 11:40:40AM +0100, Bodo Eggert wrote: 1) This change isn't nescensary - any sane person will know that it's not a SI unit. You wouldn't talk about megabananas == 100 bananas and expect to be taken seriously. I've met quite a few non-sane persons then. I find using kilo, mega and giga prefixes convenient to use. For example, I often use GEUR to refer to Giga Euros, because the word billion is overloaded. 2) No sane person would say kibibyte as required by the standard. You'd need a sppech defect in order to do this, and a mental defect in order to try. So why should anybody adhere to the rest of this bullshit? I think I'm not sane then. I find it easy to use and pronounce. IEC 60027-2 is a great standard! It removes some annoying ambiquity in speech and text. Adhering strictly to proper SI units (k, M, G, ...) makes life easier as they are taught in school to everyone. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] SCSI: Add the SGPIO support for sata_nv.c
On Fri, Nov 17, 2006 at 04:36:37PM +0800, Peer Chen wrote:
> I didn't get any comment from you guys for new patch, does someone take
> care this patch, do we still need some modification upon it? Or do we
> need re-submit it in other thread?
One small change suggestion:
> +static inline bool nv_sgpio_capable(const struct pci_device_id *ent)
> +{
> + if (ent->device == PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA2)
> + return 1;
> + else
> + return 0;
> +}
Make it shorter ->
return ent->device == PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA2;
- Heikki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] SCSI: Add the SGPIO support for sata_nv.c
On Fri, Nov 17, 2006 at 04:36:37PM +0800, Peer Chen wrote:
I didn't get any comment from you guys for new patch, does someone take
care this patch, do we still need some modification upon it? Or do we
need re-submit it in other thread?
One small change suggestion:
+static inline bool nv_sgpio_capable(const struct pci_device_id *ent)
+{
+ if (ent-device == PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA2)
+ return 1;
+ else
+ return 0;
+}
Make it shorter -
return ent-device == PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA2;
- Heikki
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: diabling interrupts on pentium 4 processor
On Thu, Nov 16, 2006 at 11:23:12AM +, ranjith kumar wrote: > Hi, > How to disable interrupts on pentium 4 (or any > i386) > machine? > > I tried to include "cli" instruction in a kernel > module. But got runtime error. Read Documentation/cli-sti-removal.txt. - Heikki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, Patch 1/1] OProfile for Cell: Initial profiling support -- new patch
On Wed, Nov 15, 2006 at 12:51:08PM -0600, Maynard Johnson wrote:
> +/* This function is called once for all cpus combined */
> +static void
> +cell_reg_setup(struct op_counter_config *ctr,
> +struct op_system_config *sys, int num_ctrs)
> +{
> [SNIP]
> + for (i = 0; i < num_ctrs; ++i) {
> +
> + if ((ctr[i].event >= 2100) && (ctr[i].event <= 2111))
> + pmc_cntrl[1][i].evnts = ctr[i].event + 19;
> + else if (ctr[i].event == 2203)
> + pmc_cntrl[1][i].evnts = ctr[i].event;
> + else if ((ctr[i].event >= 2200) && (ctr[i].event <= 2215))
> + pmc_cntrl[1][i].evnts = ctr[i].event + 16;
> + else
> + pmc_cntrl[1][i].evnts = ctr[i].event;
> +
I think the previous code would be more readable with a switch()
statement.
switch (ctr[i].event) {
case 2100 ... 2111:
pmc_cntrl[1][i] = ctr[i].event + 19;
break;
case 2200 ... 2202:
case 2204 ... 2215:
pmc_cntrl[1][i] = ctr[i].event + 16;
break;
default:
pmc_cntrl[1][i] = ctr[i].event;
}
- Heikki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, Patch 1/1] OProfile for Cell: Initial profiling support -- new patch
On Wed, Nov 15, 2006 at 12:51:08PM -0600, Maynard Johnson wrote:
+/* This function is called once for all cpus combined */
+static void
+cell_reg_setup(struct op_counter_config *ctr,
+struct op_system_config *sys, int num_ctrs)
+{
[SNIP]
+ for (i = 0; i num_ctrs; ++i) {
+
+ if ((ctr[i].event = 2100) (ctr[i].event = 2111))
+ pmc_cntrl[1][i].evnts = ctr[i].event + 19;
+ else if (ctr[i].event == 2203)
+ pmc_cntrl[1][i].evnts = ctr[i].event;
+ else if ((ctr[i].event = 2200) (ctr[i].event = 2215))
+ pmc_cntrl[1][i].evnts = ctr[i].event + 16;
+ else
+ pmc_cntrl[1][i].evnts = ctr[i].event;
+
I think the previous code would be more readable with a switch()
statement.
switch (ctr[i].event) {
case 2100 ... 2111:
pmc_cntrl[1][i] = ctr[i].event + 19;
break;
case 2200 ... 2202:
case 2204 ... 2215:
pmc_cntrl[1][i] = ctr[i].event + 16;
break;
default:
pmc_cntrl[1][i] = ctr[i].event;
}
- Heikki
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: diabling interrupts on pentium 4 processor
On Thu, Nov 16, 2006 at 11:23:12AM +, ranjith kumar wrote: Hi, How to disable interrupts on pentium 4 (or any i386) machine? I tried to include cli instruction in a kernel module. But got runtime error. Read Documentation/cli-sti-removal.txt. - Heikki - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Edge triggered epoll with pts devices acts as level triggered
Adam Langley wrote: >epoll_wait(epoll_fd, events, 4, -1); >write(1, ".", 1); The test case is faulty. write will trigger the event again infinitely. fds 0 and 1 are the same in many cases. Try this: $ ./epolltest > foo Now you will only get 1 trigger for each input. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Edge triggered epoll with pts devices acts as level triggered
Adam Langley wrote: epoll_wait(epoll_fd, events, 4, -1); write(1, ., 1); The test case is faulty. write will trigger the event again infinitely. fds 0 and 1 are the same in many cases. Try this: $ ./epolltest foo Now you will only get 1 trigger for each input. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCQ support NVidia NForce4 (CK804) SATAII
Michael Thonke <[EMAIL PROTECTED]> wrote: > USB works also great for all chipsets :-) Not here. I've had plenty of problems with VIA K8T800 USB, but only with USB mass storage devices: http://bugzilla.kernel.org/show_bug.cgi?id=2915 Otherwise the chipset has worked very well. Only one crash in a year, and that was with a recent 2.6.13-rc[2-5] TCP bug, which has already been fixed. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
