Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Tue, 01 May 2007 04:19:41 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and pseudo-authorities Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Yes I mean like this. But I do not only talk about me. I talk about many many others. Above that you flamed Edgar Toernig with the invented alibi for not signing his contributions (yes I say invented alibi and I mean it exactly that way - in so far the word gatekeeper is no invention in this context at all, it's just a very cynical expression that shows a lot of frustration). To get it back to the comprehensive layer: 1. 4 unusable kernels are not just another cavalier's delict, but just a very harsh and deep cut in kernel development history (read: the time space for that breakdown is close to 9 or 10 months). This could have been some three months or less if you weren't the personality that you obviously are representing. 2. Although I tried to tell you a thousand times that I prefer to optimize the existing (read: bttv dependent - even if it may sound senseless to you) concept you continued to pursue a dead born child called cx878. This hopeful project which I would have highly admired if it ever were finished did not only die out of the personal time schedule of a very capable kaffeine developer called Christoph Pfister (who did the main work for it - not you), but it simply died as a consequence of your obviously missing knowledge. Some i2c bus bindings were missing - in so far the mounting of a 2000 meters high mountain was cancelled 50 meters before the top. So what do I mean by optimizing the existing concept? Very simple: Deselectable DST module, deselectable DST_CA module, deselectable dvb-pll module - not more - not less. Now if this very humble concept works, if all this horrible dvb_core_attach stuff and other problems are resolved let's talk about getting rid of all the not necessary bttv dependency nonsense, but never vice versa and never before that. Read: long way, small steps, but no breakdowns. Did I pronounce clear now, Mister Abraham? It can't be that hard to understand this, can it? Uwe Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: synchronization problems Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS. I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop
[linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Sun, 29 Apr 2007 18:37:00 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Linus Torvalds wrote: On Sun, 29 Apr 2007, Uwe Bugla wrote: BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab: You never explained what the problem even was, apart from compiling in some code that you didn't need to before. Didn't it work in the end? If it worked, I don't see what the big issue was. You are getting a _lot_ of other code in the kernel that you probably never use, you may not even have realized. I'd like to explain this a bit, for people seeing these messages who haven't been following this part of dvb development. dvb-pll is a simple driver for a number of I2C tuners, which are used in many many TV cards. These are simple devices, and drivers for host controllers (which usually support quite a few different models of tv card based on the same core chip) often didn't use dvb-pll. They would just re-implement an I2C tuner driver, sometimes more than once in the same file! The dvb tree ended up with over a dozen different re-implementations of the same basic tuner driver. Of course each implementation would have different bugs, quirks, and missing features. So we've been removing this code and using dvb-pll. If you look at some of my patches to do this: 14 files changed, 14 insertions(+), 199 deletions(-) 1 files changed, 4 insertions(+), 34 deletions(-) 4 files changed, 17 insertions(+), 204 deletions(-) These patches fixed bugs and added features, yet are very much net negative when if comes to lines of code in the kernel. any chance to deselect the compilation of the dvb-pll.c-module, as its deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1. dvb-pll has nothing to do with VIDEO_V4L1_COMPAT or VIDEO_V4L1. Uwe is just confused about what is causing what. Hi, I am NO WAY confused about what is causing what - I only wrote down what I say trying to compile 2.6.21-git2! Once again, and for the last time definitely, even if you do not want to perceive what goddamn crap you have produced, Mr. Piepho: If I want to compile drivers for a specific card ( let us call it Pinnacle PCTV SAT or TwinHan DST - just to mention two examples ) I a. need to say yes to VIEDO_V4L1 b. CANNOT deselect dvb-pll.c (Generic pll) exactly knowing that the PCTV SAT or the TwinHan DST DO NOT need dvb-pll.c. c. am trapped by still existing exported symbols like dvb_pll_lg_tdvs_h06xf in backend module dvb-bt8xx.c (line 614), which have never been a problem before this catastrophic rollback caused by you, Mr. Piepho! d. do not see any chance to get rid of static dependencies connected with dvb-pll.c because your work is reactionary and a regression, nothing else. Conclusion: Linus, I would appreciate you to rip this stuff out of git2, as long as there is no compromise solution that I can live with. This work, done by Mr. Piepho is very buggy, and buggy stuff like this does not belong into mainline. All the almost excellent work that Michael Krufky has offered for that issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber exactly) is being wiped out and rolled back with his acknowledgement! Uwe is probably talking about the dvb_attach() system, written mainly by Andrew de Quincey and myself, which went into 2.6.18. The basic concept is that a core driver uses symbol_request() to avoid any strong references to its helper drivers. This way only the helper drivers that are actually needed must be loaded. We want to make dvb-pll use this system too, but it doesn't fully work yet. I have several ideas about how to solve the problem, but it's not a high priority. YUP. And as long as this is not finished this stuff has absolutely no place in mainline vanilla. Basta! All you need is to offer a possibility to deselection for dvb-pll.c for cards that never neede it! As lang as you cannot offer this or do not want to offer this there is no place in mainline for that crap work. The dvb_attach() system worked almost perfectly optimized ( as far as RAM consommation is concerned) for me and a couple of other cards, until you Mr. Piepho, came up and offered this utmost regessive work. It is a shame that buggy stuff like this can reach the mainline. When I first saw it I could not trust my eyes. But seeing the complete personal situation @ linuxtv.org - well: Who wonders?? Anything is possible, even if its quality is horrible. Uwe -- Feel free - 10 GB Mailbox, 100
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 15:06:11 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 07:49:52 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Markus Rechberger [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Uwe Bugla wrote: So please Linus - rip that crap out of 2.6.21-git2. And if you do see questions what parts you need to rip out, please feel free to ask me Uwe. I'll say this ONCE more. No. Sorry! Sigh! Very utmost bad decision, but I must respect it. The accumulative principle is the opposite of effectiveness. Even if you do not understand the dvb issues in git2 (well I cannot expect this, can I?), you push a. immature code b. a regression Isn't it a pity that the maintainer title has more influence than any kind of common sense, reason or sophisticated argumentation? What a horrible thought! P. S.: In former kernel releases the specific last release candidate was almost identical to the official kernel release. Not only I have largest problems to understand why this wonderful principle has been broken, with the effect, that the so-called stable kernel releases are unusable in the end. 2.6.20, 2.6.21, 2.6.19, and may be former ones that I do not know about. A Final release should be round, but never in this life highly incomplete, shouldn't it?? And unless you can become politer and more respectful and stop ranting all the time, you'll be in the very rare situation of hitting my auto-filters and going into an email mbox of your own (read: one that I read in my copious spare time. Hint: I don't _have_ any.) Linus Poor Linus! I have got thousands of good reasons to be so rude towards some people. And I certainly know the smart polite way of the game too. I know both ways of dealing with. But if someone continues to nerve me for such a long time (whoever the specified person may be) I get out the big stick and then there will be bambule pure! Excuse me, you are only finnish origin: Bambule is an invention of Ulrike Meinhof and other 68ers and stands for revolt or something similar. BTW: Wasn't it you yourself stating that if one wants changes it is not always useful to be polite?? If you want to change something, it's not fine to be entirely polite all the time: (Linus Torvalds, March 6, 2007, 09:57:34, public Email). Happy reflection, Mister Torvalds! Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Uwe Bugla wrote: And I swear that this dvb-pll.c is completely obsolete for this scenario! For that reason (old variant): # CONFIG_DVB_TUNER_LGH06XF is not set And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey, but it was produced by Michael Krufky himself, and I was very thankful for that and still am! [...] And why the hell is that dvb-pll.c rollback part of git2 now? Additionally - with the acknowlegdement of Michael Krufky - incredible! The LG-H06xF NIM is slightly different from the other tuners supported by the dvb-pll library, in that it requires a 5th auxiliary byte, as opposed to only four bytes that are sent for all of the other devices supported by dvb-pll. In order to handle this, I had created a separate module, called lgh06xf. This module was able to re-use some code inside the dvb-pll module, while adding the additional required code to handle that 5th byte. As a side effect, caused by the creation of the lgh06xf module, the static dependency of dvb-bt8xx on dvb-pll was removed. Instead of dvb-bt8xx having to call dvb_pll_configure, causing the static dependency, it would now call lgh06xf_attach. lgh06xf_attach would fill the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the lgh06xf module. This change was done in an effort to improve support for the LG-TDVS-H06xF NIM family... The removal of the static dependency of dvb-bt8xx on dvb-pll was merely a side effect. I DID NOT DO THIS FOR YOUR BENEFIT, UWE. There is always a chance that a new bt8xx-based card may come around with a new tuner, and need the dvb-pll module in order to work properly. Then, Trent suggested that we add this 5th byte functionality to dvb-pll. Trent has shown us how this 5th byte is helpful for other devices, including the Thomson DTT 761X, and the Philips FMD1216ME, among others. Trent made the appropriate changes to the dvb-pll module, allowing it to absorb the functionality of the lgh06xf module into a centralized location, so that any other tuners can benefit from this shared code. Trent did a great thing here, by making the dvb-pll module a much more robust library, not to mention that his changes have in fact REDUCED the size of the kernel. (see Trent's earlier post in this thread) Uwe, this is quite a silly argument. You've been singing the same song ever since before I got involved with linuxtv.org, and quite frankly, I am sick of it. Let it be known to the world, that Uwe has praised me in his previous emails, as I have kept quiet and ignored his rants. Now that I am finally opening up my mouth, I am quite sure that I will be his next flame target. Nobody can take this kind of behavior seriously -- the only thing we can do is ignore you, and maybe you'll go away. My suggestion to you, Uwe, is to stop flaming the lists, and stop bothering us developers. Your devices work. You are complaining about wasted memory -- get over it. It is a small price to pay for globally supported devices and autodetection. You should be happy that people are still here working on this code. It seems that your emails are focused at driving away developers -- nothing more could be gained by this, then everybody is screwed. If your patches were correct, then, by all means, we would apply them. However, developers have pointed out problems in your patches, and you have done nothing but flame them. Who wants to continue a discussion with you, after only being flamed? I sure don't. Just know that if you respond to this email with yet another flame, I will simply ignore it. -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 11:30:34 -0400 Von: Michael Krufky [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Markus Rechberger [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org, [EMAIL PROTECTED], Trent Piepho [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Uwe Bugla wrote: And I swear that this dvb-pll.c is completely obsolete for this scenario! For that reason (old variant): # CONFIG_DVB_TUNER_LGH06XF is not set And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey, but it was produced by Michael Krufky himself, and I was very thankful for that and still am! [...] And why the hell is that dvb-pll.c rollback part of git2 now? Additionally - with the acknowlegdement of Michael Krufky - incredible! The LG-H06xF NIM is slightly different from the other tuners supported by the dvb-pll library, in that it requires a 5th auxiliary byte, as opposed to only four bytes that are sent for all of the other devices supported by dvb-pll. In order to handle this, I had created a separate module, called lgh06xf. This module was able to re-use some code inside the dvb-pll module, while adding the additional required code to handle that 5th byte. As a side effect, caused by the creation of the lgh06xf module, the static dependency of dvb-bt8xx on dvb-pll was removed. Instead of dvb-bt8xx having to call dvb_pll_configure, causing the static dependency, it would now call lgh06xf_attach. lgh06xf_attach would fill the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the lgh06xf module. This change was done in an effort to improve support for the LG-TDVS-H06xF NIM family... The removal of the static dependency of dvb-bt8xx on dvb-pll was merely a side effect. I DID NOT DO THIS FOR YOUR BENEFIT, UWE. There is always a chance that a new bt8xx-based card may come around with a new tuner, and need the dvb-pll module in order to work properly. Then, Trent suggested that we add this 5th byte functionality to dvb-pll. Trent has shown us how this 5th byte is helpful for other devices, including the Thomson DTT 761X, and the Philips FMD1216ME, among others. Trent made the appropriate changes to the dvb-pll module, allowing it to absorb the functionality of the lgh06xf module into a centralized location, so that any other tuners can benefit from this shared code. Trent did a great thing here, by making the dvb-pll module a much more robust library, not to mention that his changes have in fact REDUCED the size of the kernel. (see Trent's earlier post in this thread) Uwe, this is quite a silly argument. You've been singing the same song ever since before I got involved with linuxtv.org, and quite frankly, I am sick of it. Let it be known to the world, that Uwe has praised me in his previous emails, as I have kept quiet and ignored his rants. Now that I am finally opening up my mouth, I am quite sure that I will be his next flame target. Nobody can take this kind of behavior seriously -- the only thing we can do is ignore you, and maybe you'll go away. My suggestion to you, Uwe, is to stop flaming the lists, and stop bothering us developers. Your devices work. You are complaining about wasted memory -- get over it. It is a small price to pay for globally supported devices and autodetection. Hi Mike, first of all thank you for explainig us all the context - well done! I spent some 4 hours yesterday to try to find a compromise solution as Trent Piepho ignored my criticism, which is no fine behaviour at all. Even if you do not believe I even managed to nearly complete a compromise, making dvb-pll.c deselectable for both of the v4l layers. I only stumbled over line 614 of module dvb-bt8xx.c in current 2.6.21-git2 kernel. For this static dependency concerning support for the Fusion HDTV 5 Lite card I did not manage to find out a solution how to get rid of. I think I will send my stuff to Markus who already offered to help me to work this out. So there is no small price to pay at all if one knows how to resolve it. It's quite simple in fact - I am just missing the appropriate thought kick. You should be happy that people are still here working on this code. It seems that your emails are focused at driving away developers -- nothing more could be gained by this, then everybody is screwed. If your patches were correct, then, by all means, we would apply them. However, developers have pointed out problems in your patches, and you have done nothing but flame them. Who wants to continue a discussion with you, after only being flamed? I sure don't. Again I state: I haven't found any unresolved symbols caused by my DST deselection patches. Even if Mauro Chehab repeats that like a parrot it is like an air bubble on my testing side: empty
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 17:56:17 +0100 (BST) Von: Mauro Carvalho Chehab [EMAIL PROTECTED] An: Helge Hafting [EMAIL PROTECTED] CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Hi Helge and others, On Mon, 30 Apr 2007, Helge Hafting wrote: what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months. ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise. A sufficiently bad maintainer will also do it. If lots of submitters send their patches to andrew in order to get past a dysfunctional maintainer, then the subsystem effectively is unmaintained. The point is that Uwe patch will generate regressions by breaking for Twinhan. His patch just removes compilation for dst and dst_ca on Kconfig, without taking care or driver internals. So, two initialization functions won't be called by symbol_request(). Although those two functions will be undefined, as the dvb will do the linkedition at module runtume (if DVB_ATTACH is selected), modprobe won't detect the lack of those functions. At the end, cards with ST chips (DST and/or DST CA) will stop working, without even printing a warning. Mister Chehab, for the first and for the utmost last time now: My deselection patch implies a very good text to strongly discourage the use of DST and DST_CA in case someone does not know what he or she is doing. In so far the case that cards with ST chips (DST and/ or DST CA) will stop working will not happen at all. This patch IS NOT DONE TO MAKE ANY DST OR DST_CA MODULE REQUIRING CARD WORK - THIS IS YOUR PART OF SO-CALLED LOGIC THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL Example: Pinnacle PCTV SAT!!! And once again and for the last time: I did not manage to at least find one single unresolved module during compilation, and I have been working with this almost fantastic solution with several kernels for months now! Above that I gave you every proof one can ever give: You received dmesg, you received configs, you received proven thesis, you received everything. It would really be a perfect solution to bomb away the almost incredible meters thick wall in front of your head and your eyes. And at this time I will stop responding to your mails - I got enough of you!!! It's enough!! I've tried to explain this to Uwe several times, but, at the end, he always start insulting me and/or other developers. Cheers, Mauro. Happy reflection, Mister Chehab! -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 11:04:36 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Mauro Carvalho Chehab [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Uwe, you just made my kill-list. I've not actually done that in _years_. So you can feel proud. Your emails will get automatically filtered to their own (ignored) folder. I told you why, and you didn't seem to understand at all. Linus Wrong, but understandable reaction. But I have found somebody to help me to get this thing solved - in so far: counterproductive from your side! Cheers Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 11:14:14 -0700 Von: Andrew Morton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Mauro Carvalho Chehab [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007 19:25:47 +0200 Uwe Bugla [EMAIL PROTECTED] wrote: I did not manage to at least find one single unresolved module during compilation, and I have been working with this almost fantastic solution with several kernels for months now! That isn't what Mauro is saying. What he is saying is that the missing symbols will not be reported at build time. The kernel will all link correctly and will appear to load modules correctly. See, there's a third mechanism for symbol resolution which is used at runtime, not at build time: symbol_request(). What Mauro is saying is that these changes will cause symbol_request() to return different results on some people's setups with different hardware, causing those setups to fail. Hi Andrew, But, even if this is the case, it should be transparent WHAT DIFFERENT HARDWARE IS MEANT EXACTLY! DST AND DST_CA CANNOT BE MEANT - this I have made quite shure! I swear I did not notice any errors - so as long as I cannot see through where the problem is, and as long as I have been working with my patches without the slightest noise for months now - where should I apply some additions then? See, there's a third mechanism for symbol resolution which is used at runtime, not at build time: symbol_request(). If this symbol_request() appears at runtime, then there should be some feedback in dmesg or any other kind of syslog. But I swear I haven't seen any kind of bad or counterproductive messages like this! My system runs excelent with my patches - so why should I care? I meanwhile have sent my patches to someone, he will have a look at them - and we all will see what happens then. Above that I will at least try to enhance those two patches by a dvb-pll.c deselection feature which I said very politely to Trent that I am missing it. And I want to get out now of that horrible discussion - I am exhausted. Cheers Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL [...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Linux Kernel Mailing list [EMAIL PROTECTED], Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Piepho, you are a devil, and your links do not work at all! Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 5/1/07, Manu Abraham [EMAIL PROTECTED] wrote: Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? Please show me where this change makes your work more difficult, Trent's change is small and I don't see the problem where it seriously affects your work. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Dienstag, den 01.05.2007, 01:05 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Linus Torvalds [EMAIL PROTECTED] CC: Linux Kernel Mailing list [EMAIL PROTECTED], Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Piepho, you are a devil, and your links do not work at all! Uwe Try again, this devil's stuff almost always works :) Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Tue, 01 May 2007 02:58:49 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Trent Piepho [EMAIL PROTECTED] CC: Michael Krufky [EMAIL PROTECTED], [EMAIL PROTECTED], Linus Torvalds [EMAIL PROTECTED], Linux Kernel Mailing list [EMAIL PROTECTED], Linux DVB linux-dvb@linuxtv.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and pseudo-authorities Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Mister Manuel Abraham, 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - and in so far I personally would deeply recommend you to shut up now and go to hell (where you belong) without any thinkable return ticket as you are nothing else but just another motherfucker... 3. You have been ignoring my contributions out of a gesture of ignorance and arrogance and incapability of every kind of human skills for months now, and I will never even try to have any mercy for that 4. Your effort of making dvb-bt8xx cards independent from bttv has been dying out of your personified asociality, ignorance, and anti-communicative behaviour - thus the very hopeful cx878 project is another dead born child produced by your personal behaviour, asociality, ignorance, stupidity and incompatibility, with the effect that Christoph Pfister has turned off from that development tree and now is maintainer of kaffeine where he is doing a very good job, neglecting any further cooperation with you deeply asocial human being in pure incarnation 5. Mister Manuel Abraham, I am not alone just to say that I want you to vanish and shrink from here without any return ticket at all Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again Just goto hell, you goddamn deeply asocial miserable sonofabitch!! Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: synchronization problems Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS. I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches. In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: bythe or, even worse: autodected and Recognise) It was ME who corrected that in the past, and it was YOU personally who reversed that, if not to say: fucked it up in the current 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and apologize for that, but not MINE! b. attempts of documentation that do NOT correspond to their appropriate kernel design What do I mean with b.? 1. In Kernels 2.6.12 AND 2.6.13 the simple command modprobe dvb-bt8xx caused ALL OTHER modules to load automatically: cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the automatic loading of dst, dst-ca and dst-ci, every attempt of discussion about debug parameters is simply obsolete! So if I cannot load the dst module separately, how should I be able to hack in debug parameters? I know what debug parameters are for, and I deeply respect developers work, but what the hell is it all worth for if a kernel design suppresses hacking in debug parameters? 2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID = 113. But perhaps I have problems to deal with hexadecimal numbers, and this would
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Manu, also for you please stop it, we know that Uwe writes abusive stuff but you don't have to go on with it. It's about the patch Trent wrote if you're not able to discuss it wait for others to comment it. I only saw subjective reasons why you are against it, but the actual patch doesn't cross your development there. Markus On 5/1/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: synchronization problems Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS. I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please immediately stop doing that in such a bureaucratic manner. If synchronization of CVS and kernel.org only works unidirectional, and not bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real problem, but you personally have one without any doubts. And if you lack time, simply delegate your job to another person. But simply stop rubbing out other peoples coauthorship and pay respect to their contributions. And the biggest joke about your personal misbehaviour is the fact that you personally cosigned at least one of my patch attempts, without dropping me a single note asking me to not bypass the linuxtv CVS maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a little bit earlier in the future! Additionally you deleted information from bt8xx.txt which I think were useful help for debugging problems, and which were written there on purpose by the developer. So if you talk about respect, you could show some yourself by not bypassing the original authors and maintainers when sending patches. In fact I did, and I can tell you the simple reasons why. There are in fact two things that I simply cannot and will not tolerate: a. orthographic junk (examples: bythe or, even worse: autodected and Recognise) It was ME who corrected that in the past, and it was YOU personally who reversed that, if not to say: fucked it up in the current 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and apologize for that, but not MINE! b. attempts of documentation that do NOT correspond to their appropriate kernel design What do I mean with b.? 1. In Kernels 2.6.12 AND 2.6.13 the simple command modprobe dvb-bt8xx caused ALL OTHER modules to load automatically: cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the automatic loading of dst, dst-ca and dst-ci, every attempt of discussion about debug parameters is simply obsolete! So if I cannot load the dst module separately, how should I be able to hack in debug parameters? I know what debug parameters are for,
[linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Sun, 29 Apr 2007 11:49:40 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-dvb@linuxtv.org Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: And now comes the critical point: If I use kernel 2.6.21 in connection with git2 (NOT: git1) everything is fine so far. Sounds like the sis900 network driver problem. Hi Linus, I thought that this problem could be reduced to the sis900 driver issue, but today I found out that I was wrong. In so far: The kernel 2.6.21 official kernel makes my router hang up The kernel 2.6.21-git1 makes my router hang up Simply the 2.6.21-git2 is running stable. CLEARER: The sis900 patch is part of git1. In so far it cannot and will never be the real reason for the kernel Oopses on my router. I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). I did not manage to find out what part of the git2-code is necessary to make my AMD K7 router run stable. It is somewhere right between git1 and git2 - that is all I can say about that. It is definitely NOT the NIC issue. BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab: You never explained what the problem even was, apart from compiling in some code that you didn't need to before. Didn't it work in the end? Yes it works, but it is a regression in so far as I was fighting and arguing to get rid of some useless module attachments in the past which was then put into practice as solution done by Michael Krufky in a very sophisticated and fine manner. With the git2 solution I am condemned to waste RAM with at least one module that my card and a whole lot of other cards never needed. In so far it is a fallback and regression (like the router code that made floppy mounting impossible at the beginning of 2.6.21-rc1 or so, if you can remember this... You decided to rip that buggy stuff out - and this was a fine decision! I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! If it worked, I don't see what the big issue was. You are getting a _lot_ of other code in the kernel that you probably never use, you may not even have realized. May be, don't know! But wouldn't it be a nice trait to at least get rid of unusable code that the specific machine does not need at all? Now, if that aim sounds too abrasive, what's the use of kernel compilation then? Do you expect me to accept a Kernel of a size of 2 or 3 Megabytes, with module support completely disabled and the RAM overcrowded with modules that I never needed? In the specific example of git2's dvb code you cannot disable the compilation of dvb-pll.c if you use the v4l normal layer (VIDEO_V4L1). If you are forced to use the v4l compat layer (VIDEO_V4L1_COMPAT) to enable a specific group of cards you do not have any chance to get rid of this module! Now - if this is no serious bug or regression, please what else is a serious bug or regression then? Uwe, you really aren't helping yourself by being so damn abrasive. I know for a fact that your bug-reports are going ignored by some people, and I'm not surprised at all. Now what a gesture? I can show you a ten Emails long ping pong game between Mauro and me which will prove you simply that Mauro Chehab never even did a five minutes look on my contributions. Instead he spent three quarters of an hour or so to offer me nothing but 1. Lies 2. Unproved Theses 3. Unproved Assumptions With only one strategic aim: Fighting me down to make me give up, nothing else! Now Linus, how would you feel in my situation? Should I call this man a maintainer? Would you call this man a maintainer? See, I have had such a many positive experiences since I actively engaged in Linux. With maintainers, with quite a lots of other real fine people. And above that, I obviously am not alone at all. It was nobody but Johannes Stezenbach himself who uttered great sorrow where the personnel of linuxtv.org is going to (see mail list please). It seems like a 4 cylinder machine running on 2 or 3 cylinders, you know Linus Yours sincerely Uwe P. S.: If there are further questions I'd appreciate you to ask. -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure. Would you call Mauro Carvalho Chehab a maintainer! I can certify you that I cannot, even if I try. And I want him to be substituted as quick as possible as he is the biggest mismatch of gatekeeper one can ever imagine. And it is not only me personally perceiving this that there are people missing who can go upright and offer sophisticated and good work. Plus a real sophisticated discussion behaviour, in technical and in human terms. Going upright is thus far away from the behaviour NOT to be able to tolerate any criticism at all. Solution: This whole new quite young linuxtv.org
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure. Would you call Mauro Carvalho Chehab a maintainer! I can certify you that I cannot, even if I try. And I want him to be substituted as quick as possible as he is the biggest mismatch of gatekeeper one can ever imagine. And it is not only me personally perceiving this that there are people missing who can go upright and offer sophisticated and good work. Plus a real sophisticated discussion behaviour, in technical and
