DST/BT878 module customization (.. was: Critical points about ...)

DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

Hi,

Trent Piepho wrote another patch for it, it just completes Uwe's patch
in the end.

http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb

as far as I see from that patch it cleans up a memory leak which would
happen when the system tries to load the dst module if it's not
available and it also prints a message that points the user should
enable it in the kernel if needed.

It also bundles the dst and dst_ca objects to one selectable option.
So the idea remains the same.
>From my side I do not see any problem with that patch, if someone else
has a problem with it please state out the reason.

Markus


On 4/30/07, Markus Rechberger <mrechberger@gmail.com> wrote:
> On 4/30/07, Jan Engelhardt <jengelh@linux01.gwdg.de> 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
>


-- 
Markus Rechberger

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Simon Arlott]

On 30/04/07 22:17, Markus Rechberger wrote:
> Trent Piepho wrote another patch for it, it just completes Uwe's patch
> in the end.
> From my side I do not see any problem with that patch, if someone else
> has a problem with it please state out the reason.

I have no problem with the patch since it has nothing to do with my DVB 
card but you're only encouraging Uwe to be abusive since it seems to 
help get him what he wants:

On 01/05/07 00:05, Uwe Bugla wrote:
> Piepho, you are a devil, and your links do not work at all!
> Uwe

On 01/05/07 00:40, Uwe Bugla wrote:
> 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
 
> On 4/30/07, Markus Rechberger <mrechberger@gmail.com> wrote:
>> 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.

It's not working. Patches should still be applied on the basis of what 
they do and how, not why they were made, of course.

-- 
Simon Arlott

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/1/07, Simon Arlott <simon@fire.lp0.eu> wrote:
> On 30/04/07 22:17, Markus Rechberger wrote:
> > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > in the end.
> > From my side I do not see any problem with that patch, if someone else
> > has a problem with it please state out the reason.
>
> I have no problem with the patch since it has nothing to do with my DVB
> card but you're only encouraging Uwe to be abusive since it seems to
> help get him what he wants:
>
> On 01/05/07 00:05, Uwe Bugla wrote:
> > Piepho, you are a devil, and your links do not work at all!
> > Uwe
>
> On 01/05/07 00:40, Uwe Bugla wrote:
> > 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
>
> > On 4/30/07, Markus Rechberger <mrechberger@gmail.com> wrote:
> >> 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.
>
> It's not working. Patches should still be applied on the basis of what
> they do and how, not why they were made, of course.

this patch was written by Trent, and it seems like he already had that
idea earlier too.

I really don't care if that patch goes in or not in the end, there's
just no need to flame around for it.

The only reason I see is that it's not needed to link it statically
against the bt878 module and there isn't even much work to do.
Uwe's Makefile patch worked as expected, but it wasn't clean/complete
enough that was a reason to not include it.
Now with Trent's patch I don't see that as a valid argument against it anymore.
And the email from Manu claiming that it generates alot work (which is
btw. 2 years old) doesn't seem to be valid either.

Markus

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 1 May 2007 11:00:44 +0200
Von: "Markus Rechberger" <mrechberger@gmail.com>
An: "Simon Arlott" <simon@fire.lp0.eu>
CC: Manu Abraham <abraham.manu@gmail.com>, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, Jan Engelhardt <jengelh@linux01.gwdg.de>, helge.hafting@aitel.hist.no, akpm@linux-foundation.org, linux-dvb@linuxtv.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points about ...)

> On 5/1/07, Simon Arlott <simon@fire.lp0.eu> wrote:
> > On 30/04/07 22:17, Markus Rechberger wrote:
> > > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > > in the end.
> > > From my side I do not see any problem with that patch, if someone else
> > > has a problem with it please state out the reason.
> >
> > I have no problem with the patch since it has nothing to do with my DVB
> > card but you're only encouraging Uwe to be abusive since it seems to
> > help get him what he wants:
> >
> > On 01/05/07 00:05, Uwe Bugla wrote:
> > > Piepho, you are a devil, and your links do not work at all!
> > > Uwe
> >
> > On 01/05/07 00:40, Uwe Bugla wrote:
> > > 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
> >
> > > On 4/30/07, Markus Rechberger <mrechberger@gmail.com> wrote:
> > >> 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.
> >
> > It's not working. Patches should still be applied on the basis of what
> > they do and how, not why they were made, of course.
> 
> this patch was written by Trent, and it seems like he already had that
> idea earlier too.
> 
> I really don't care if that patch goes in or not in the end, there's
> just no need to flame around for it.
> 
> The only reason I see is that it's not needed to link it statically
> against the bt878 module and there isn't even much work to do.
> Uwe's Makefile patch worked as expected, but it wasn't clean/complete
> enough that was a reason to not include it.
> Now with Trent's patch I don't see that as a valid argument against it
> anymore.
> And the email from Manu claiming that it generates alot work (which is
> btw. 2 years old) doesn't seem to be valid either.
> 
> Markus

Thank you, Markus - you are a real fine and straight chap.
You should be team leader of this community.
BTW:
Are my latest attempts sent to you already involved in the latest development state
(Read: Is dvb-pll.c deselectable now without breaking support for lgdt330)?
I simply stumbled over that lgdt330 binding in module dvb-bt8xx.c, line 641 or so.
Anything else I resolved at least from my personal side.

A thousands of thanks to you and Trent - well done!
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: DST/BT878 module customization (.. was: Critical points about ...)

[Mauro Carvalho Chehab]

Hi Markus,

Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> Hi,
> 
> Trent Piepho wrote another patch for it, it just completes Uwe's patch
> in the end.
> 
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb

The above patch plus the other on
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb

Implements properly the Uwe's ide. 

However, I did a test here applying both patches, and de-selecting dst
drivers.

With this configuration, dvb-bt8xx hangs during initialization,
generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
never returns).

$ ps ax|grep modprobe
 2769 pts/0    S      0:00 modprobe dvb_bt8xx
 2779 pts/0    S+     0:00 grep --color modprobe

$ dmesg
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
Unable to handle kernel NULL pointer dereference at 00000000000002f0 RIP:
<ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195}
PGD 7cfba067 PUD 7cfc5067 PMD 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat v4l2_common forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd usbcore reiserfs sd_mod sata_nv libata scsi_mod
Pid: 1286, comm: modprobe Tainted: P      2.6.17.4 #1
RIP: 0010:[<ffffffff8825f11b>] <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195}
RSP: 0018:ffff81007c239e38  EFLAGS: 00010296
RAX: 000000000000002b RBX: ffff81007c05a800 RCX: 0000000000000003
RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffffffff803905bc
RBP: 0000000000000000 R08: 0000000000004c72 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff81007c190000
R13: ffff81007c05a8d0 R14: ffff81007c05ac98 R15: ffff81007c05abc8
FS:  00002b8b39ddf6f0(0000) GS:ffffffff80476000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002f0 CR3: 000000007cfc2000 CR4: 00000000000006e0
Process modprobe (pid: 1286, threadinfo ffff81007c238000, task ffff81007dfd4960)
Stack: ffff81007c05acb0 ffff81007c05a870 000000717c1e31c0 ffff81007c190198
       ffff81007c190000 ffffffff88261940 ffffffff88261940 0000000000000000
       0000000000518130 ffffffff8026ce95
Call Trace: <ffffffff8026ce95>{driver_probe_device+101}
       <ffffffff8026d00a>{__driver_attach+122} <ffffffff8026cf90>{__driver_attach+0}
       <ffffffff8026c6f9>{bus_for_each_dev+73} <ffffffff8026c2e8>{bus_add_driver+136}
       <ffffffff80152977>{sys_init_module+199} <ffffffff80109d2a>{system_call+126}

Code: f6 04 25 f0 02 00 00 20 0f 84 01 ff ff ff e9 7d fd ff ff 66
RIP <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195} RSP <ffff81007c239e38>
CR2: 00000000000002f0

So, those patches aren't enough to fix the issue.

Cheers,
Mauro

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 11:55:33 -0300
Von: Mauro Carvalho Chehab <mchehab@infradead.org>
An: Markus Rechberger <mrechberger@gmail.com>
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, Manu Abraham <abraham.manu@gmail.com>
Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical	points about ...)

> Hi Markus,
> 
> Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> > Hi,
> > 
> > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > in the end.
> > 
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
> 
> The above patch plus the other on
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
> 
> Implements properly the Uwe's ide. 
> 
> However, I did a test here applying both patches, and de-selecting dst
> drivers.
> 
> With this configuration, dvb-bt8xx hangs during initialization,
> generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> never returns).
Hi, please: Could you explain to me why you are turning around the logical principle all the time?

Those patches (and my humble ones too of course that gained no attention for months) were made for the POSITIVE CASE
in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT VICE VERSA!

So please in how far isn't that fantastic work done by Trent enough?
So it is very clear that if there are oopses and hangups if such a card exists and its drivers are deselected.
No point at all!
So please explain me the essence why you use the inversion of the given logic to NOT ACK or SIGN this beautiful work.
I want to see THREE valid arguments for this turnaround illogical behaviour please.

Uwe

P. S.: I tested Trent's work and I can ensure that there aren't any Oopses at all!
So your case studies are not only highly invented and strange, but they aren't any help either. I really wonder what the hell is going on in your brain.
I really ask myself why you are doing this nerve war, this ping-pong game all the time.
This work is done for the case where there aren't any DST cards inside the machine,
so you cannot just come up, turn everything around, and thus pick up the inversion that fits into your strange concept (whatever that may be - noone except you
knows) for blocking that good work.
So I'd deeply appreciate you to stop this strange hindrance policy. You will do nobody any favour with that strange behaviour!
In my eyes you do not want to help at all - you just want to provoke. And if in the end someone insults you you seem to have won.
But you do not win anything with your strange gestures behind other peoples backs, you're instead counterproductive.

And EVEN IF you write this publically you should immediately stop to do this behind the author's back - so I CCed Trent Piepho.
Just to see and show him the bad methods that you are using to qualify other people's efforts.

> 
> $ ps ax|grep modprobe
>  2769 pts/0    S      0:00 modprobe dvb_bt8xx
>  2779 pts/0    S+     0:00 grep --color modprobe
> 
> $ dmesg
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> Unable to handle kernel NULL pointer dereference at 00000000000002f0 RIP:
> <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195}
> PGD 7cfba067 PUD 7cfc5067 PMD 0
> Oops: 0000 [1] SMP
> CPU 0
> Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
> tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
> tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat v4l2_common
> forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd
> usbcore reiserfs sd_mod sata_nv libata scsi_mod
> Pid: 1286, comm: modprobe Tainted: P      2.6.17.4 #1
> RIP: 0010:[<ffffffff8825f11b>]
> <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195}
> RSP: 0018:ffff81007c239e38  EFLAGS: 00010296
> RAX: 000000000000002b RBX: ffff81007c05a800 RCX: 0000000000000003
> RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffffffff803905bc
> RBP: 0000000000000000 R08: 0000000000004c72 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff81007c190000
> R13: ffff81007c05a8d0 R14: ffff81007c05ac98 R15: ffff81007c05abc8
> FS:  00002b8b39ddf6f0(0000) GS:ffffffff80476000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000002f0 CR3: 000000007cfc2000 CR4: 00000000000006e0
> Process modprobe (pid: 1286, threadinfo ffff81007c238000, task
> ffff81007dfd4960)
> Stack: ffff81007c05acb0 ffff81007c05a870 000000717c1e31c0 ffff81007c190198
>        ffff81007c190000 ffffffff88261940 ffffffff88261940 0000000000000000
>        0000000000518130 ffffffff8026ce95
> Call Trace: <ffffffff8026ce95>{driver_probe_device+101}
>        <ffffffff8026d00a>{__driver_attach+122}
> <ffffffff8026cf90>{__driver_attach+0}
>        <ffffffff8026c6f9>{bus_for_each_dev+73}
> <ffffffff8026c2e8>{bus_add_driver+136}
>        <ffffffff80152977>{sys_init_module+199}
> <ffffffff80109d2a>{system_call+126}
> 
> Code: f6 04 25 f0 02 00 00 20 0f 84 01 ff ff ff e9 7d fd ff ff 66
> RIP <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195} RSP
> <ffff81007c239e38>
> CR2: 00000000000002f0
> 
> So, those patches aren't enough to fix the issue.
> 
> Cheers,
> Mauro
> 
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 18:40:54 +0200
Von: "Uwe Bugla" <uwe.bugla@gmx.de>
An: Mauro Carvalho Chehab <mchehab@infradead.org>, mrechberger@gmail.com
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, abraham.manu@gmail.com, xyzzy@speakeasy.org
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical	points about ...)

> 
> -------- Original-Nachricht --------
> Datum: Tue, 01 May 2007 11:55:33 -0300
> Von: Mauro Carvalho Chehab <mchehab@infradead.org>
> An: Markus Rechberger <mrechberger@gmail.com>
> CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, Manu Abraham
> <abraham.manu@gmail.com>
> Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was:
> Critical	points about ...)
> 
> > Hi Markus,
> > 
> > Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> > > Hi,
> > > 
> > > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > > in the end.
> > > 
> > >
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
> > 
> > The above patch plus the other on
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
> > 
> > Implements properly the Uwe's ide. 
> > 
> > However, I did a test here applying both patches, and de-selecting dst
> > drivers.
> > 
> > With this configuration, dvb-bt8xx hangs during initialization,
> > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > never returns).
> Hi, please: Could you explain to me why you are turning around the logical
> principle all the time?
> 
> Those patches (and my humble ones too of course that gained no attention
> for months) were made for the POSITIVE CASE
> in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT
> VICE VERSA!
> 
> So please in how far isn't that fantastic work done by Trent enough?
> So it is very clear that if there are oopses and hangups if such a card
> exists and its drivers are deselected.
> No point at all!
> So please explain me the essence why you use the inversion of the given
> logic to NOT ACK or SIGN this beautiful work.
> I want to see THREE valid arguments for this turnaround illogical
> behaviour please.
> 
> Uwe
> 
> P. S.: I tested Trent's work and I can ensure that there aren't any Oopses
> at all!
> So your case studies are not only highly invented and strange, but they
> aren't any help either. I really wonder what the hell is going on in your
> brain.
> I really ask myself why you are doing this nerve war, this ping-pong game
> all the time.
> This work is done for the case where there aren't any DST cards inside the
> machine,
> so you cannot just come up, turn everything around, and thus pick up the
> inversion that fits into your strange concept (whatever that may be - noone
> except you
> knows) for blocking that good work.
> So I'd deeply appreciate you to stop this strange hindrance policy. You
> will do nobody any favour with that strange behaviour!
> In my eyes you do not want to help at all - you just want to provoke. And
> if in the end someone insults you you seem to have won.
> But you do not win anything with your strange gestures behind other
> peoples backs, you're instead counterproductive.
> 
> And EVEN IF you write this publically you should immediately stop to do
> this behind the author's back - so I CCed Trent Piepho.
> Just to see and show him the bad methods that you are using to qualify
> other people's efforts.
> 
> > 
> > $ ps ax|grep modprobe
> >  2769 pts/0    S      0:00 modprobe dvb_bt8xx
> >  2779 pts/0    S+     0:00 grep --color modprobe
> > 
> > $ dmesg
> > DVB: registering new adapter (bttv0).
> > DVB: Unable to find symbol dst_attach()
> > Unable to handle kernel NULL pointer dereference at 00000000000002f0
> RIP:
> > <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195}
> > PGD 7cfba067 PUD 7cfc5067 PMD 0
> > Oops: 0000 [1] SMP
> > CPU 0
> > Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
> > tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
> > tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
> v4l2_common
> > forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd
> ohci_hcd
> > usbcore reiserfs sd_mod sata_nv libata scsi_mod
> > Pid: 1286, comm: modprobe Tainted: P      2.6.17.4 #1
> > RIP: 0010:[<ffffffff8825f11b>]
> > <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195}
> > RSP: 0018:ffff81007c239e38  EFLAGS: 00010296
> > RAX: 000000000000002b RBX: ffff81007c05a800 RCX: 0000000000000003
> > RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffffffff803905bc
> > RBP: 0000000000000000 R08: 0000000000004c72 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: ffff81007c190000
> > R13: ffff81007c05a8d0 R14: ffff81007c05ac98 R15: ffff81007c05abc8
> > FS:  00002b8b39ddf6f0(0000) GS:ffffffff80476000(0000)
> > knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 00000000000002f0 CR3: 000000007cfc2000 CR4: 00000000000006e0
> > Process modprobe (pid: 1286, threadinfo ffff81007c238000, task
> > ffff81007dfd4960)
> > Stack: ffff81007c05acb0 ffff81007c05a870 000000717c1e31c0
> ffff81007c190198
> >        ffff81007c190000 ffffffff88261940 ffffffff88261940
> 0000000000000000
> >        0000000000518130 ffffffff8026ce95
> > Call Trace: <ffffffff8026ce95>{driver_probe_device+101}
> >        <ffffffff8026d00a>{__driver_attach+122}
> > <ffffffff8026cf90>{__driver_attach+0}
> >        <ffffffff8026c6f9>{bus_for_each_dev+73}
> > <ffffffff8026c2e8>{bus_add_driver+136}
> >        <ffffffff80152977>{sys_init_module+199}
> > <ffffffff80109d2a>{system_call+126}
> > 
> > Code: f6 04 25 f0 02 00 00 20 0f 84 01 ff ff ff e9 7d fd ff ff 66
> > RIP <ffffffff8825f11b>{:dvb_bt8xx:dvb_bt8xx_probe+3195} RSP
> > <ffff81007c239e38>
> > CR2: 00000000000002f0
> > 
> > So, those patches aren't enough to fix the issue.
> > 
> > Cheers,
> > Mauro
> > 
> > 
> > _______________________________________________
> > linux-dvb mailing list
> > linux-dvb@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 
> -- 
> "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

Mr. Chehab,

if your specific invented case
(read: DST card in the machine with DST modules disabled)
would be at least transparent there would be at least corresponding lines like these
part of the dmesg:

bttv: Bt8xx card found (0).
PCI: Enabling device 0000:02:0b.0 (0004 -> 0006)
ACPI: PCI Interrupt 0000:02:0b.0[A] -> GSI 23 (level, low) -> IRQ 20
bttv0: Bt878 (rev 17) at 0000:02:0b.0, irq: 20, latency: 32, mmio: 0xf3000000
bttv0: detected: Pinnacle PCTV Sat [card=94], PCI subsystem ID is 11bd:001c
bttv0: using: Pinnacle PCTV Sat [card=94,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00cf47fc [init]
bttv0: using tuner=-1
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
bttv0: add subdevice "dvb0"
bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
PCI: Enabling device 0000:02:0b.1 (0004 -> 0006)
ACPI: PCI Interrupt 0000:02:0b.1[A] -> GSI 23 (level, low) -> IRQ 20
bt878_probe: card id=[0x1c11bd],[ Pinnacle PCTV Sat ] has DVB functions.
bt878(0): Bt878 (rev 17) at 02:0b.1, irq: 20, latency: 32, memory: 0xf2800000
DVB: registering new adapter (bttv0).
DVB: registering frontend 0 (Conexant CX24110 DVB-S)...

But I cannot find those lines in your dmesg at all.

The biggest problem that I had with you in the past weeks is and was that you never even once offer full transparency when you are building up theses NOT TO accept patches.

And if it is only the other side (me, Trent, others) to be forced to offer transparent information BUT NOT YOU YOURSELF
then this is what I would call a deep anti-democratic behaviour.

You can neither help nor can you solve any problem continuing in that manner,
can you?

Happy reflection on your very strange methods, with the hope to do better in the future! If there is some hope - well, I doubt!

Uwe

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Simon Arlott]

On 01/05/07 19:30, Uwe Bugla wrote:
> <fewer rude comments than usual>

If you would avoid making inflammatory comments, the people who are trying to 
help you will be more inclined to fix the problems that these patches DO cause 
so they can be added.

A while ago, you went on and on about your broken floppy drive and how people 
shouldn't do things that break other systems - even if they have no idea that 
was happening - yet here you are now demanding people do the same thing.

It's easy to maintain your own changes to the kernel until equivalent changes 
are committed - you need to be much more patient, especially when something is 
being done about them.

-- 
Simon Arlott

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[e9hack]

Uwe Bugla wrote:
> 
> The biggest problem that I had with you in the past weeks is and was that you never even once offer full transparency when you are building up theses NOT TO accept patches.
> 
> And if it is only the other side (me, Trent, others) to be forced to offer transparent information BUT NOT YOU YOURSELF
> then this is what I would call a deep anti-democratic behaviour.
> 
> You can neither help nor can you solve any problem continuing in that manner,
> can you?
> 
> Happy reflection on your very strange methods, with the hope to do better in the future! If there is some hope - well, I doubt!
> 

Hi Uwe,

I would like it if you only post technical topics without any comments to some person. In your case, the comments are
mostly a personally attacks against someone. If I use google to search for your name: in the last 5 years, on every
board, forum, ML,.. you had trouble with many people. It was always because someone wasn't your opinion or someone
didn't do what you seems to expect. Afterwards, you did always start your attacks and flame war. As a result nobody did
response to you and you was fired from some places. Your problem with some people from this list isn't a problem of this
people. It's a problem of your own and of your communicative skills. If you cannot respect sentence #1, please go away
and do never post to this list again.

Just my two cents..

- Hartmut

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 21:20:01 +0200
Von: e9hack <e9hack@googlemail.com>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: mrechberger@gmail.com, mchehab@infradead.org, linux-dvb@linuxtv.org, xyzzy@speakeasy.org, abraham.manu@gmail.com, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

> Uwe Bugla wrote:
> > 
> > The biggest problem that I had with you in the past weeks is and was
> that you never even once offer full transparency when you are building up
> theses NOT TO accept patches.
> > 
> > And if it is only the other side (me, Trent, others) to be forced to
> offer transparent information BUT NOT YOU YOURSELF
> > then this is what I would call a deep anti-democratic behaviour.
> > 
> > You can neither help nor can you solve any problem continuing in that
> manner,
> > can you?
> > 
> > Happy reflection on your very strange methods, with the hope to do
> better in the future! If there is some hope - well, I doubt!
> > 
> 
> Hi Uwe,
> 
> I would like it if you only post technical topics without any comments to
> some person. In your case, the comments are
> mostly a personally attacks against someone. If I use google to search for
> your name: in the last 5 years, on every
> board, forum, ML,.. you had trouble with many people. It was always
> because someone wasn't your opinion or someone
> didn't do what you seems to expect. Afterwards, you did always start your
> attacks and flame war. As a result nobody did
> response to you and you was fired from some places. Your problem with some
> people from this list isn't a problem of this
> people. It's a problem of your own and of your communicative skills. If
> you cannot respect sentence #1, please go away
> and do never post to this list again.
> 
> Just my two cents..
> 
> - Hartmut

Hartmut,
one strategy to establish democratic principles is showing up methods of other people like Abraham and Chehab. If you are not ready to perceive this you're really poor.
Uwe


-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 19:50:38 +0100
Von: Simon Arlott <simon@fire.lp0.eu>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: mrechberger@gmail.com, mchehab@infradead.org, linux-dvb@linuxtv.org, xyzzy@speakeasy.org, abraham.manu@gmail.com, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

> On 01/05/07 19:30, Uwe Bugla wrote:
> > <fewer rude comments than usual>
> 
> If you would avoid making inflammatory comments, the people who are trying
> to 
> help you will be more inclined to fix the problems that these patches DO
> cause 
> so they can be added.
> 
> A while ago, you went on and on about your broken floppy drive and how
> people 
> shouldn't do things that break other systems - even if they have no idea
> that 
> was happening - yet here you are now demanding people do the same thing.

WRONG!
I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context!

So I say it again:
The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else!
It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself!
And it's exactly the same thing with Abraham or Krufky!

And does that behaviour conform with democratic terms? NO WAY!
So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab!

Uwe

> 
> It's easy to maintain your own changes to the kernel until equivalent
> changes 
> are committed - you need to be much more patient, especially when
> something is 
> being done about them.
> 
> -- 
> Simon Arlott

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Simon Arlott]

On 01/05/07 20:34, Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Tue, 01 May 2007 19:50:38 +0100
> Von: Simon Arlott <simon@fire.lp0.eu>
>> On 01/05/07 19:30, Uwe Bugla wrote:
>>> <fewer rude comments than usual>
>> If you would avoid making inflammatory comments, the people who are trying
>> to 
>> help you will be more inclined to fix the problems that these patches DO
>> cause 
>> so they can be added.
>>
>> A while ago, you went on and on about your broken floppy drive and how
>> people 
>> shouldn't do things that break other systems - even if they have no idea
>> that 
>> was happening - yet here you are now demanding people do the same thing.
> 
> WRONG!
> I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context!

You complained that changes which break your system[1] shouldn't be added 
and now rudely demand your desired changes which have been shown to break 
others' should be added immediately. I don't believe I misunderstood you 
or got the wrong context - it has nothing to do with the related patch.

[1] http://lkml.org/lkml/2007/2/25/127


> So I say it again:
> The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else!
> It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself!
> And it's exactly the same thing with Abraham or Krufky!
> 
> And does that behaviour conform with democratic terms? NO WAY!
> So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab!

You're worse than that reiser4 fanatic, at least he wasn't rude when he 
repeated himself over and over and over. I was going to offer to help 
you bisect between -git1 and -git2 (it'd be trivial to run the bisect 
here and provide patches to test) but I won't bother if you're going to 
hijack every email with your abuse.

-- 
Simon Arlott

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 21:35:44 +0100
Von: Simon Arlott <simon@fire.lp0.eu>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-kernel@vger.kernel.org, abraham.manu@gmail.com, xyzzy@speakeasy.org, linux-dvb@linuxtv.org, mchehab@infradead.org, mrechberger@gmail.com
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

> On 01/05/07 20:34, Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Tue, 01 May 2007 19:50:38 +0100
> > Von: Simon Arlott <simon@fire.lp0.eu>
> >> On 01/05/07 19:30, Uwe Bugla wrote:
> >>> <fewer rude comments than usual>
> >> If you would avoid making inflammatory comments, the people who are
> trying
> >> to 
> >> help you will be more inclined to fix the problems that these patches
> DO
> >> cause 
> >> so they can be added.
> >>
> >> A while ago, you went on and on about your broken floppy drive and how
> >> people 
> >> shouldn't do things that break other systems - even if they have no
> idea
> >> that 
> >> was happening - yet here you are now demanding people do the same
> thing.
> > 
> > WRONG!
> > I offered a patch for the broken floppy, but Linus was faster and ripped
> the whole section out, so do not even try to misunderstand or quote me out
> of context!
> 
> You complained that changes which break your system[1] shouldn't be added 
> and now rudely demand your desired changes which have been shown to break 
> others' should be added immediately. I don't believe I misunderstood you 
> or got the wrong context - it has nothing to do with the related patch.
> 
> [1] http://lkml.org/lkml/2007/2/25/127
> 
> 
> > So I say it again:
> > The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully
> transparent information with them. It's just air bubbles that he is
> producing, nothing else!
> > It's always and ever the other part that is exposed to offer transparent
> info, but never Chehab himself!
> > And it's exactly the same thing with Abraham or Krufky!
> > 
> > And does that behaviour conform with democratic terms? NO WAY!
> > So there are three mismatches around: Their names are: Abraham, Krufky,
> and Chehab!
> 
> You're worse than that reiser4 fanatic, at least he wasn't rude when he 
> repeated himself over and over and over. I was going to offer to help 
> you bisect between -git1 and -git2 (it'd be trivial to run the bisect 
> here and provide patches to test)

Well, thank you for that offer in mind, but the git bisect is only necessary for some people needing to know what the reasons for the AMD K7 router Oopses are (speak: what needs to be inserted in vanilla mainline to make it "round" (2.6.21.3, 4, 5,.....)).

But meanwhile I got three perfect running machines, implying 
Trent's stuff, implying self-built stuff, and everything built up on 2.6.21-git4), so I can solve my problems on my own.
See, if it is almost impossible to build up necessary majorities to get rid of some utmost nasty gatekeepers @linuxtv.org then I can keep my own patch repositories and save lots of energy.
Why should I fight against windmills of such an enourmous stupidity like diagnosed around here? No reason for that!
Why should I take part in testing the mm-tree?
Nothing but waste of time, isn't it??

The technical issues that still need to be fixed plus some creative ideas I sent to mrechberger@gmail.com plus to Trent Piepho. If they get this done - excellent!
If not - why should I waste nerves?
Because of some stupid Abraham or Krufky??
Or the intransparence of Mr. Chehab's air bubbles??
Why should I??
 
snip
_____________________________________________

Uwe

(Rest blather cut off)

> Simon Arlott

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Trent Piepho]

On Tue, 1 May 2007, Simon Arlott wrote:
> On 30/04/07 22:17, Markus Rechberger wrote:
> > From my side I do not see any problem with that patch, if someone else
> > has a problem with it please state out the reason.
>
> I have no problem with the patch since it has nothing to do with my DVB
> card but you're only encouraging Uwe to be abusive since it seems to
> help get him what he wants:

I've been aware of the problem with dst not fully using the dvb customization
systems(*) for a long time.  It came up when dvb_attach() et al were first
being integrated, well before any rejected patches or strongly worded emails
or whatever from certain people that I'm aware of.

I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since
I already know about the issues here, I felt I should post a patch for them
any other reasonable developers who might spend time on this.

If there is an abusive person, I'm not going to let it affect my behavior.
You lose if you let them influence your decisions one way, or influence them
another way.


(*) There are two customization/dependency control systems in DVB.  One is
dvb_attach(), the other is DVB_FE_CUSTOMISE.  They are not two entirely
separate systems, but overlap in their design a great deal.

The significant part, common to both, is the overall design of the driver
framework.  DVB uses what I would describe as an object oriented system.  A
driver for a certain type of hardware exports a single attach function, which
returns an object for one instance of that hardware.  All control of that
hardware is done via methods defined in this object.  There is typical
hierarchy, where an 'adapter' object will contain a 'frontend' object which
will contain a 'tuner' object.  Of course hardware designers are not
constrained by the software frameworks we create, so sometimes it's more
complex (e.g., dst).

This design means the actual hard link between different drivers is limited to
each driver's single attach function (**).  By breaking this one link, we can
control which drivers must be loaded or linked to only those necessary or
wanted.  dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
controlling these links.

dvb_attach() is based on symbol_request()
A.  It's only useful with modules
B.  It doesn't prevent drivers from being compiled
C.  It allows one to build support for hardware, yet not actually load that
    support until it is needed.  This allows supporting a wide array of
    possible hardware without a large amount of wasted resources, useful for
    distribution kernels for example.

DVB_FE_CUSTOMISE is based on Kconfig and static inline stub functions
A.  It works with drivers compiled into the kernel, not using modules.
B.  It prevents drivers from even being compiled in the first place.
C.  Disabled drivers are truly disabled, it is not possible to have support
    for hardware and yet not load it.
This is useful for the smallest & simplest kernel, for set top boxes and the
like.  It's entirely possible to use both at once:  compile some drivers into
your kernel, leave others as modules, not compile modules for hardware you
don't have, only load the modules for the hardware you are using at the
moment, and still support hardware you might connect later.


(**) The dvb-pll module still exports more symbols than just dvb_pll_attach(),
that is why the customization systems don't fully work with it yet.  It also
exports dvb_pll_configure(), an obsolete interface which only a couple
remaining users that have yet been converted.  And it exports PLL definition
structs, which isn't a difficult problem and I know several ways to fix it, we
just haven't decided or actually done it yet.

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Trent Piepho]

On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> With this configuration, dvb-bt8xx hangs during initialization,
> generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> never returns).

Stupid typo in the first patch, a != should have been ==.

Fixed:
http://linuxtv.org/hg/~tap/dst-new

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Mauro Carvalho Chehab]

Em Ter, 2007-05-01 às 16:16 -0700, Trent Piepho escreveu:
> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> > With this configuration, dvb-bt8xx hangs during initialization,
> > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > never returns).
> 
> Stupid typo in the first patch, a != should have been ==.
> 
> Fixed:
> http://linuxtv.org/hg/~tap/dst-new

With the changes, the dst unselection worked.

Those are the logs with dst unselected:

DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800


However, when dst is selected, I got those errors:


DVB: registering new adapter (bttv0).
dst(0) dst_get_device_id: Recognise [DSTMCI]
dst(0) dst_get_device_id: Unsupported
dst(0) dst_check_mb86a15: Found a MB86A15 NIM
DST type flags : 0x1 newtuner 0x1000 VLF 0x10 firmware version = 2
dst(0) dst_get_mac: MAC Address=[00:00:00:00:00:00]
dst(0) dst_get_tuner_info: DST TYpe = MULTI FE
dst(0) dst_fw_ver: Firmware Ver = 1.4 Build = 02, on 11:5, 22-2-2005
dst(0) dst_card_type: Device Model=[VP1032]
dst(0) dst_get_vendor: Vendor=[TWINHAN]
Unable to handle kernel NULL pointer dereference at 00000000000002f0 RIP:
<ffffffff883ede94>{:dvb_bt8xx:dvb_bt8xx_probe+2548}
PGD 6c2c1067 PUD 73f56067 PMD 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in: dst dvb_bt8xx dvb_core bt878 tuner bttv video_buf ir_common compat_ioctl32 btcx_risc tveeprom videodev v4l2_common v4l1_compat dvb_pll ipt_ULOG x_tables autofs4 tun it87 hwmon_vid hwmon eeprom i2c_isa i2c_nforce2 ipv6 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd soundcore af_packet capi capifs kernelcapi bridge ide_cd binfmt_misc isofs loop nls_iso8859_1 nls_cp850 vfat fat evdev dm_mod usbmouse video usbhid thermal fan container button battery ac cpufreq_ondemand cpufreq_conservative cpufreq_powersave powernow_k8 freq_table processor firmware_class i2c_algo_bit i2c_core pcspkr forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd usbcore reiserfs sd_mod sata_nv libata scsi_mod
Pid: 4211, comm: modprobe Tainted: P      2.6.17.4 #1
RIP: 0010:[<ffffffff883ede94>] <ffffffff883ede94>{:dvb_bt8xx:dvb_bt8xx_probe+2548}
RSP: 0018:ffff81006f0b5e38  EFLAGS: 00010286
RAX: ffff8100716bf018 RBX: ffff81007962a000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8100716bf018 RDI: ffff8100716bf270
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000080
R10: 0000000000000000 R11: ffffffff8011c530 R12: ffff8100717f7800
R13: ffff81007962a0d0 R14: ffff81007962a498 R15: ffff81007962a3c8
FS:  00002aff6d9c06f0(0000) GS:ffffffff80476000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002f0 CR3: 000000006c1d4000 CR4: 00000000000006e0
Process modprobe (pid: 4211, threadinfo ffff81006f0b4000, task ffff81007dff42c0)
Stack: ffff81007962a4b0 ffff81007962a070 0000007176bdc0c0 ffff8100717f7998
       ffff8100717f7800 ffffffff883f0940 ffffffff883f0940 0000000000000000
       0000000000518130 ffffffff8026ce95
Call Trace: <ffffffff8026ce95>{driver_probe_device+101}
       <ffffffff8026d00a>{__driver_attach+122} <ffffffff8026cf90>{__driver_attach+0}
       <ffffffff8026c6f9>{bus_for_each_dev+73} <ffffffff8026c2e8>{bus_add_driver+136}
       <ffffffff80152977>{sys_init_module+199} <ffffffff80109d2a>{system_call+126}

Code: f6 04 25 f0 02 00 00 20 0f 84 ae 01 00 00 48 c7 c7 ae ee 3e
RIP <ffffffff883ede94>{:dvb_bt8xx:dvb_bt8xx_probe+2548} RSP <ffff81006f0b5e38>
CR2: 00000000000002f0


-- 
Cheers,
Mauro

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1422 bytes --]

On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> Em Ter, 2007-05-01 às 16:16 -0700, Trent Piepho escreveu:
> > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> > > With this configuration, dvb-bt8xx hangs during initialization,
> > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > > never returns).
> >
> > Stupid typo in the first patch, a != should have been ==.
> >
> > Fixed:
> > http://linuxtv.org/hg/~tap/dst-new
>
> With the changes, the dst unselection worked.
>
> Those are the logs with dst unselected:
>
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800

This is the dvb_attach() "not found" message.  You should see this same
message if you leave dst selected and then just delete the dst modules before
loading dvb-bt8xx.

If you turn dvb_attach off, you should see a different "dst support was
disabled" message (and no crash!).

> However, when dst is selected, I got those errors:

When I made this patch I was basing it off a patch I made around 9 months
ago.  I thought since that one was ok, this would be ok too, and in my
hurry to get it done I've clearly put too little effort into checking it,
and I'm sorry to have wasted your time.

I promise, this time it's right!
http://linuxtv.org/hg/~tap/dst-new

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Wed, 2 May 2007 04:10:03 -0700 (PDT)
Von: Trent Piepho <xyzzy@speakeasy.org>
An: Mauro Carvalho Chehab <mchehab@infradead.org>
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, Manu Abraham <abraham.manu@gmail.com>
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was:	Critical	points about ...)

> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> > Em Ter, 2007-05-01 Ã s 16:16 -0700, Trent Piepho escreveu:
> > > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> > > > With this configuration, dvb-bt8xx hangs during initialization,
> > > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > > > never returns).
> > >
> > > Stupid typo in the first patch, a != should have been ==.
> > >
> > > Fixed:
> > > http://linuxtv.org/hg/~tap/dst-new
> >
> > With the changes, the dst unselection worked.
> >
> > Those are the logs with dst unselected:
> >
> > DVB: registering new adapter (bttv0).
> > DVB: Unable to find symbol dst_attach()
> > frontend_init: Could not find a Twinhan DST.
> > dvb-bt8xx: A frontend driver was not found for device 109e/0878
> subsystem fbfb/f800
> 
> This is the dvb_attach() "not found" message.  You should see this same
> message if you leave dst selected and then just delete the dst modules
> before
> loading dvb-bt8xx.
> 
> If you turn dvb_attach off, you should see a different "dst support was
> disabled" message (and no crash!).
> 
> > However, when dst is selected, I got those errors:
> 
> When I made this patch I was basing it off a patch I made around 9 months
> ago.  I thought since that one was ok, this would be ok too, and in my
> hurry to get it done I've clearly put too little effort into checking it,
> and I'm sorry to have wasted your time.
> 
> I promise, this time it's right!
> http://linuxtv.org/hg/~tap/dst-new

The DST card with CA slot and the DST card without CA slot are two different cases.
Like the Pinnacle PCTV SAT with CI extension and the Pinnacle PCTV SAT without CI extension.

In so far my questions are:
Shouldn't there be two cases for deselecting DST modules?
At least my basic approach tried to distinct those two cases.
In how far is it enough or technically sufficient to treat those two cases as one?

And, as already mentioned: At least in all of those 4 cases no dvb-pll module
isn't needed at all - someone simply forgot to add some lines for the exception handling in dvb-bt8xx to get rid of dvb-pll.c if there is no lgdt330x frontend needed (read: if there is no Fusion HDTV Lite card in the machine at all).

If this small case is being fixed you simply can expand the deselection of dvb-pll.c
on all cards treated in backend module dvb-bt8xx.c.

Uwe

> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Trent Piepho wrote:
> On Tue, 1 May 2007, Simon Arlott wrote:
>> On 30/04/07 22:17, Markus Rechberger wrote:
>>> From my side I do not see any problem with that patch, if someone else
>>> has a problem with it please state out the reason.
>> I have no problem with the patch since it has nothing to do with my DVB
>> card but you're only encouraging Uwe to be abusive since it seems to
>> help get him what he wants:
> 
> I've been aware of the problem with dst not fully using the dvb customization
> systems(*) for a long time.  It came up when dvb_attach() et al were first
> being integrated, well before any rejected patches or strongly worded emails
> or whatever from certain people that I'm aware of.
> 

Well, your understanding of the device is quite limited and hence your
comments and patches.

The DST as it refers to is an embedded system a x86 Compatible RISC core
[1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
IO and 2 DMA channels. What we have is a PQFP device

This is the case in most cases. On some cheaper cards the embedded
system is replaced by an 8 bit host microcontroller, to cut down costs
where all the features are not required for a specific model

Additionally this embedded system has a fast shovelling engine for the
MPEG2 TS routing in between the
This embedded system is connected to an actual
(1) DVB frontend [2]
(2) DVB CA interface [3]
(3) Analog tuner
(4) Audio interfaces

These features are not the characteristics of a DVB Frontend. Here there
is a DVB frontend like the normal ones which is hidden behind another
pseudo bridge (So you don't have *any* access to the frontend at large)

It is not necessary that *all* the dst cards (there are around ~15
different variants of the same) do have the very same feature set.

It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
fact it is a combo driver supporting the entire devices using a common
command set

In such a case it has more characteristics of the PCI bridge and in fact
heavily tied to it and has it's own advantages.

> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since
> I already know about the issues here, I felt I should post a patch for them
> any other reasonable developers who might spend time on this.
> 

I would think that it would be *extremely* rude for a person to send in
patches for a device that which you don't understand at all, when it is
for limiting the capability of the said device


> If there is an abusive person, I'm not going to let it affect my behavior.
> You lose if you let them influence your decisions one way, or influence them
> another way.
> 
> 
> (*) There are two customization/dependency control systems in DVB.  One is
> dvb_attach(), the other is DVB_FE_CUSTOMISE.  They are not two entirely
> separate systems, but overlap in their design a great deal.
> 


Here we have the attach method attaching different objects, but
basically it can be handled for the frontend devices only (and that too
that share a very common trait, in this case, frontends are coupled
using the i2c bus) and not for other devices. Situation changes when you
use another interface such as SPI, where the interface is not well defined.

In the DVB OO concept we have, where the objects are at different
levels, the basic concept is that an object is indeed a smaller subset,
depending on the level that which it pertains to. In such a case the
frontend is limited to do just frontend related operations. There could
be other ways that things can be done maybe the DVB API can be redone to
have all DVB operations through the frontend alone. But that is not at
all decent way of doing it.


> The significant part, common to both, is the overall design of the driver
> framework.  DVB uses what I would describe as an object oriented system.  A
> driver for a certain type of hardware exports a single attach function, which
> returns an object for one instance of that hardware.  All control of that
> hardware is done via methods defined in this object.  There is typical
> hierarchy, where an 'adapter' object will contain a 'frontend' object which
> will contain a 'tuner' object.  Of course hardware designers are not
> constrained by the software frameworks we create, so sometimes it's more
> complex (e.g., dst).

It is a bit more complex than you think. You can imagine the entire
DVB-CORE along with proprietory vendor specific tuning algorithms (on
all devices, specific to the hardware onbaord. Algorithms do change from
slight change of hardware such as demodulators and or CA interface
stacks) on CA devices it has an onboard EN50221 CA stack from SCM [4]
called the Sunplus CI stack. On Hybrid DST devices they do feature in
analog core support in there as well as Audio too on some cards.

It is not a constraint as what you might think, as the DST is complete
hardware solution of the interfaces that you are talking about. (There
are 2 approaches, (1) do everything in hardware (2) do everything in
software) there are merits and demerits equally to both the approaches.

So here we are talking about 3 different subsystems DVB, V4L and ALSA.
Currently the DST supports *only* DVB and that too it is limited. There
is more to DVB than what you see in the DST as of now.
Support for multiple delivery systems do not exists as of now (requires
the multiproto DVB API patches)

With these said, i wouldn't want to close the window for the dst to be a
DVB frontend alone, as that's what you are trying to do

> This design means the actual hard link between different drivers is limited to
> each driver's single attach function (**).  By breaking this one link, we can
> control which drivers must be loaded or linked to only those necessary or
> wanted.  dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
> controlling these links.

dvb_attach will have to go away for the DST. It doesn't work for the
mentioned reasons that it is just pushing the device to a corner as a
DVB frontend whereas it is not a DVB Frontend at all.

[1] R8820 CPU core
http://jusst.de/manu/misc/R8820-F19.pdf

[2] DVB Fontend
A DVB Frontend consists of a Demodulator
(http://www.linuxtv.org/wiki/index.php/Demodulator) and a tuner

[3] DVB CA interface
A CA Interface consists of a CI slot
(http://www.linuxtv.org/wiki/index.php/Common_Interface) and a
CA module (http://www.linuxtv.org/wiki/index.php/CAM)

[4] http://www.scmmicro.com/

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Wed, 02 May 2007 17:30:32 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: Trent Piepho <xyzzy@speakeasy.org>
CC: Simon Arlott <simon@fire.lp0.eu>, Linux Kernel Mailing list <linux-kernel@vger.kernel.org>, torvalds@linux-foundation.org, Jan Engelhardt <jengelh@linux01.gwdg.de>, helge.hafting@aitel.hist.no, akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points	about ...)

> Trent Piepho wrote:
> > On Tue, 1 May 2007, Simon Arlott wrote:
> >> On 30/04/07 22:17, Markus Rechberger wrote:
> >>> From my side I do not see any problem with that patch, if someone else
> >>> has a problem with it please state out the reason.
> >> I have no problem with the patch since it has nothing to do with my DVB
> >> card but you're only encouraging Uwe to be abusive since it seems to
> >> help get him what he wants:
> > 
> > I've been aware of the problem with dst not fully using the dvb
> customization
> > systems(*) for a long time.  It came up when dvb_attach() et al were
> first
> > being integrated, well before any rejected patches or strongly worded
> emails
> > or whatever from certain people that I'm aware of.
> > 
> 
> Well, your understanding of the device is quite limited and hence your
> comments and patches.
> 
> The DST as it refers to is an embedded system a x86 Compatible RISC core
> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
> IO and 2 DMA channels. What we have is a PQFP device
> 
> This is the case in most cases. On some cheaper cards the embedded
> system is replaced by an 8 bit host microcontroller, to cut down costs
> where all the features are not required for a specific model
> 
> Additionally this embedded system has a fast shovelling engine for the
> MPEG2 TS routing in between the
> This embedded system is connected to an actual
> (1) DVB frontend [2]
> (2) DVB CA interface [3]
> (3) Analog tuner
> (4) Audio interfaces
> 
> These features are not the characteristics of a DVB Frontend. Here there
> is a DVB frontend like the normal ones which is hidden behind another
> pseudo bridge (So you don't have *any* access to the frontend at large)
> 
> It is not necessary that *all* the dst cards (there are around ~15
> different variants of the same) do have the very same feature set.
> 
> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
> fact it is a combo driver supporting the entire devices using a common
> command set
> 
> In such a case it has more characteristics of the PCI bridge and in fact
> heavily tied to it and has it's own advantages.
> 
> > I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
> since
> > I already know about the issues here, I felt I should post a patch for
> them
> > any other reasonable developers who might spend time on this.
> > 
> 
> I would think that it would be *extremely* rude for a person to send in
> patches for a device that which you don't understand at all, when it is
> for limiting the capability of the said device

Hi Manu,
now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it.

Fact is:
Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did...

Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level.

So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level?
Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen...
And this would conform to practising the synergetic principle, wouldn't it?

Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years  ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do).

Above that:
1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality.
2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter.
3. When I wrote patches since then I never gave up until there weren't any
a. fuzz factors
b. rejections
anymore. Instead I highly tried to put Andrew's "The perfect patch"-guidelines into practice. Although this kind of perfection reduces maintainers to gatekeepers in some cases - the borders of what is what and who is who are highly mutual...

So the basic thing is just:
1. To understand that everyone develops, independent from the knowledge and understanding level.
2. To understand that everyone has good ideas at least sometimes, independent from knowledge and understanding level.

And, even if you do not want to understand it out of whatever reason, it is no fun for any person to sound or act "abusive".
We're all just trying to search and find solutions, that's all.

Above that I want to thank you for the theoretical introduction that you gave.
And I hope it helps after all.
But I am still very sad that the cx878 project died the way it died, so very close before its maturity to be implied into Mercurial tree. I did my best to help, but in the end I nothing but wasted time - and after all, I do not remember where the repository resides, after thaddatil.net has been down for months now... What a pity!

Cheers
Uwe

> 
> > If there is an abusive person, I'm not going to let it affect my
> behavior.
> > You lose if you let them influence your decisions one way, or influence
> them
> > another way.
> > 
> > 
> > (*) There are two customization/dependency control systems in DVB.  One
> is
> > dvb_attach(), the other is DVB_FE_CUSTOMISE.  They are not two entirely
> > separate systems, but overlap in their design a great deal.
> > 
> 
> 
> Here we have the attach method attaching different objects, but
> basically it can be handled for the frontend devices only (and that too
> that share a very common trait, in this case, frontends are coupled
> using the i2c bus) and not for other devices. Situation changes when you
> use another interface such as SPI, where the interface is not well
> defined.
> 
> In the DVB OO concept we have, where the objects are at different
> levels, the basic concept is that an object is indeed a smaller subset,
> depending on the level that which it pertains to. In such a case the
> frontend is limited to do just frontend related operations. There could
> be other ways that things can be done maybe the DVB API can be redone to
> have all DVB operations through the frontend alone. But that is not at
> all decent way of doing it.
> 
> 
> > The significant part, common to both, is the overall design of the
> driver
> > framework.  DVB uses what I would describe as an object oriented system.
>  A
> > driver for a certain type of hardware exports a single attach function,
> which
> > returns an object for one instance of that hardware.  All control of
> that
> > hardware is done via methods defined in this object.  There is typical
> > hierarchy, where an 'adapter' object will contain a 'frontend' object
> which
> > will contain a 'tuner' object.  Of course hardware designers are not
> > constrained by the software frameworks we create, so sometimes it's more
> > complex (e.g., dst).
> 
> It is a bit more complex than you think. You can imagine the entire
> DVB-CORE along with proprietory vendor specific tuning algorithms (on
> all devices, specific to the hardware onbaord. Algorithms do change from
> slight change of hardware such as demodulators and or CA interface
> stacks) on CA devices it has an onboard EN50221 CA stack from SCM [4]
> called the Sunplus CI stack. On Hybrid DST devices they do feature in
> analog core support in there as well as Audio too on some cards.
> 
> It is not a constraint as what you might think, as the DST is complete
> hardware solution of the interfaces that you are talking about. (There
> are 2 approaches, (1) do everything in hardware (2) do everything in
> software) there are merits and demerits equally to both the approaches.
> 
> So here we are talking about 3 different subsystems DVB, V4L and ALSA.
> Currently the DST supports *only* DVB and that too it is limited. There
> is more to DVB than what you see in the DST as of now.
> Support for multiple delivery systems do not exists as of now (requires
> the multiproto DVB API patches)
> 
> With these said, i wouldn't want to close the window for the dst to be a
> DVB frontend alone, as that's what you are trying to do
> 
> > This design means the actual hard link between different drivers is
> limited to
> > each driver's single attach function (**).  By breaking this one link,
> we can
> > control which drivers must be loaded or linked to only those necessary
> or
> > wanted.  dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
> > controlling these links.
> 
> dvb_attach will have to go away for the DST. It doesn't work for the
> mentioned reasons that it is just pushing the device to a corner as a
> DVB frontend whereas it is not a DVB Frontend at all.
> 
> [1] R8820 CPU core
> http://jusst.de/manu/misc/R8820-F19.pdf
> 
> [2] DVB Fontend
> A DVB Frontend consists of a Demodulator
> (http://www.linuxtv.org/wiki/index.php/Demodulator) and a tuner
> 
> [3] DVB CA interface
> A CA Interface consists of a CI slot
> (http://www.linuxtv.org/wiki/index.php/Common_Interface) and a
> CA module (http://www.linuxtv.org/wiki/index.php/CAM)
> 
> [4] http://www.scmmicro.com/
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Wed, 02 May 2007 17:30:32 +0400
> Von: Manu Abraham <abraham.manu@gmail.com>
> An: Trent Piepho <xyzzy@speakeasy.org>
> CC: Simon Arlott <simon@fire.lp0.eu>, Linux Kernel Mailing list <linux-kernel@vger.kernel.org>, torvalds@linux-foundation.org, Jan Engelhardt <jengelh@linux01.gwdg.de>, helge.hafting@aitel.hist.no, akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points	about ...)
> 
>> Trent Piepho wrote:
>>> On Tue, 1 May 2007, Simon Arlott wrote:
>>>> On 30/04/07 22:17, Markus Rechberger wrote:
>>>>> From my side I do not see any problem with that patch, if someone else
>>>>> has a problem with it please state out the reason.
>>>> I have no problem with the patch since it has nothing to do with my DVB
>>>> card but you're only encouraging Uwe to be abusive since it seems to
>>>> help get him what he wants:
>>> I've been aware of the problem with dst not fully using the dvb
>> customization
>>> systems(*) for a long time.  It came up when dvb_attach() et al were
>> first
>>> being integrated, well before any rejected patches or strongly worded
>> emails
>>> or whatever from certain people that I'm aware of.
>>>
>> Well, your understanding of the device is quite limited and hence your
>> comments and patches.
>>
>> The DST as it refers to is an embedded system a x86 Compatible RISC core
>> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
>> IO and 2 DMA channels. What we have is a PQFP device
>>
>> This is the case in most cases. On some cheaper cards the embedded
>> system is replaced by an 8 bit host microcontroller, to cut down costs
>> where all the features are not required for a specific model
>>
>> Additionally this embedded system has a fast shovelling engine for the
>> MPEG2 TS routing in between the
>> This embedded system is connected to an actual
>> (1) DVB frontend [2]
>> (2) DVB CA interface [3]
>> (3) Analog tuner
>> (4) Audio interfaces
>>
>> These features are not the characteristics of a DVB Frontend. Here there
>> is a DVB frontend like the normal ones which is hidden behind another
>> pseudo bridge (So you don't have *any* access to the frontend at large)
>>
>> It is not necessary that *all* the dst cards (there are around ~15
>> different variants of the same) do have the very same feature set.
>>
>> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
>> fact it is a combo driver supporting the entire devices using a common
>> command set
>>
>> In such a case it has more characteristics of the PCI bridge and in fact
>> heavily tied to it and has it's own advantages.
>>
>>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
>> since
>>> I already know about the issues here, I felt I should post a patch for
>> them
>>> any other reasonable developers who might spend time on this.
>>>
>> I would think that it would be *extremely* rude for a person to send in
>> patches for a device that which you don't understand at all, when it is
>> for limiting the capability of the said device
> 
> Hi Manu,
> now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it.
> 
> Fact is:
> Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did...
> 
> Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level.
> 
> So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level?
> Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen...
> And this would conform to practising the synergetic principle, wouldn't it?
> 
> Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years  ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do).
> 
> Above that:
> 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality.
> 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter.


i did really start very small during those early stages. Johannes did
help me a lot in many areas, he gave me a lot of valuable information,
for which i am thankful to him. The same goes to Ralph Metzler and many
others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
all in this regard (I did try to pass on such information to some
people, they thought i was trying to sabotage their project etc. I
stopped responding publicly as you might have seen. At one point i did
throw away all DVB development, i did write the same on the #linuxtv IRC
channel, did send a mail to Johannes too on that) It was just one user
who got me back again on it, a North American DVB user

In many cases it would be very nerving to work on hardware that is
extremely undocumented. Sometimes you will have to wait for weeks for a
certain person (persons who worked on the chips etc. On top of this
people who worked on the devices will move away to newer organizations.
Currently facing the same with another chip) to be free to provide an
answer for the question. In short requires a lot of patience. On top of
this when someone flames you in the little time one has.. well, many a
times i lost my temper, yes.

Sorry, if i was real bad.

> 3. When I wrote patches since then I never gave up until there weren't any
> a. fuzz factors
> b. rejections
> anymore. Instead I highly tried to put Andrew's "The perfect patch"-guidelines into practice. Although this kind of perfection reduces maintainers to gatekeepers in some cases - the borders of what is what and who is who are highly mutual...
> 
> So the basic thing is just:
> 1. To understand that everyone develops, independent from the knowledge and understanding level.
> 2. To understand that everyone has good ideas at least sometimes, independent from knowledge and understanding level.
> 
> And, even if you do not want to understand it out of whatever reason, it is no fun for any person to sound or act "abusive".
> We're all just trying to search and find solutions, that's all.
> 
> Above that I want to thank you for the theoretical introduction that you gave.
> And I hope it helps after all.
> But I am still very sad that the cx878 project died the way it died, so very close before its maturity to be implied into Mercurial tree. I did my best to help, but in the end I nothing but wasted time - and after all, I do not remember where the repository resides, after thaddatil.net has been down for months now... What a pity!

No, the cx878 project never died. thadathil.net was hosted at my office.
When the office moved a bit and some other complications, thadathil.net
went offline. on top of that, at work i was given additional
responsibilities for which i was struggling real hard. work with regards
to DVB i just do it in my spare time, but i try to steal away some time
from office work as well.

Christoph usually used to review all my code as well as some others.
With the upcoming KDE4, he was working more with kaffeine and had little
time, himself.

And as you might be aware i was working with a new delivery system
DVB-S2. When one works with a new delivery system, the existing API
proved too restrictive. Then working on which i trampled onto many
issues (not even referring to the new delivery system, or the issues
with the demodulator, mind you S2 is a bit complex and can really
confuse people.) with DVB-CORE itself, which led to another API update
other than multiproto, the Adapter API extensions. while on this again
stumbled where advanced operations where performed at the in kernel
demuxer, not forgetting an additional DSS demuxer is also needed in
kernel for DSS support.

With all these and struggling hard with 4 hours sleep, well i couldn't
take all those flames (More than what you see on the ML's many people
tend to send private mails for some reason or the other for help.
Normally i don't reject anyone's request), you can say i was kind of
worn out. Above all these some developers were very "unfriendly", some
did mischief (politics) too, which led to a larger rift.

So i chose to remain silent. That's all.

During this period, Julian was kind enough to provide me hosting for my
requirements. I will try to get thadathil.net up soon (many people used
to have firmware downloads from there, also some people had access there
for hosting test repo's and so on)

Well, that was a long rant

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Wed, 02 May 2007 17:30:32 +0400
> Von: Manu Abraham <abraham.manu@gmail.com>
> An: Trent Piepho <xyzzy@speakeasy.org>
> CC: Simon Arlott <simon@fire.lp0.eu>, Linux Kernel Mailing list <linux-kernel@vger.kernel.org>, torvalds@linux-foundation.org, Jan Engelhardt <jengelh@linux01.gwdg.de>, helge.hafting@aitel.hist.no, akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points	about ...)
> 
>> Trent Piepho wrote:
>>> On Tue, 1 May 2007, Simon Arlott wrote:
>>>> On 30/04/07 22:17, Markus Rechberger wrote:
>>>>> From my side I do not see any problem with that patch, if someone else
>>>>> has a problem with it please state out the reason.
>>>> I have no problem with the patch since it has nothing to do with my DVB
>>>> card but you're only encouraging Uwe to be abusive since it seems to
>>>> help get him what he wants:
>>> I've been aware of the problem with dst not fully using the dvb
>> customization
>>> systems(*) for a long time.  It came up when dvb_attach() et al were
>> first
>>> being integrated, well before any rejected patches or strongly worded
>> emails
>>> or whatever from certain people that I'm aware of.
>>>
>> Well, your understanding of the device is quite limited and hence your
>> comments and patches.
>>
>> The DST as it refers to is an embedded system a x86 Compatible RISC core
>> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
>> IO and 2 DMA channels. What we have is a PQFP device
>>
>> This is the case in most cases. On some cheaper cards the embedded
>> system is replaced by an 8 bit host microcontroller, to cut down costs
>> where all the features are not required for a specific model
>>
>> Additionally this embedded system has a fast shovelling engine for the
>> MPEG2 TS routing in between the
>> This embedded system is connected to an actual
>> (1) DVB frontend [2]
>> (2) DVB CA interface [3]
>> (3) Analog tuner
>> (4) Audio interfaces
>>
>> These features are not the characteristics of a DVB Frontend. Here there
>> is a DVB frontend like the normal ones which is hidden behind another
>> pseudo bridge (So you don't have *any* access to the frontend at large)
>>
>> It is not necessary that *all* the dst cards (there are around ~15
>> different variants of the same) do have the very same feature set.
>>
>> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
>> fact it is a combo driver supporting the entire devices using a common
>> command set
>>
>> In such a case it has more characteristics of the PCI bridge and in fact
>> heavily tied to it and has it's own advantages.
>>
>>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
>> since
>>> I already know about the issues here, I felt I should post a patch for
>> them
>>> any other reasonable developers who might spend time on this.
>>>
>> I would think that it would be *extremely* rude for a person to send in
>> patches for a device that which you don't understand at all, when it is
>> for limiting the capability of the said device
> 
> Hi Manu,
> now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it.
> 
> Fact is:
> Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did...
> 
> Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level.
> 
> So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level?
> Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen...
> And this would conform to practising the synergetic principle, wouldn't it?
> 
> Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years  ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do).
> 
> Above that:
> 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality.
> 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter.


i did really start very small during those early stages. Johannes did
help me a lot in many areas, he gave me a lot of valuable information,
for which i am thankful to him. The same goes to Ralph Metzler and many
others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
all in this regard (I did try to pass on such information to some
people, they thought i was trying to sabotage their project etc. I
stopped responding publicly as you might have seen. At one point i did
throw away all DVB development, i did write the same on the #linuxtv IRC
channel, did send a mail to Johannes too on that) It was just one user
who got me back again on it, a North American DVB user

In many cases it would be very nerving to work on hardware that is
extremely undocumented. Sometimes you will have to wait for weeks for a
certain person (persons who worked on the chips etc. On top of this
people who worked on the devices will move away to newer organizations.
Currently facing the same with another chip) to be free to provide an
answer for the question. In short requires a lot of patience. On top of
this when someone flames you in the little time one has.. well, many a
times i lost my temper, yes.

Sorry, if i was real bad.

> 3. When I wrote patches since then I never gave up until there weren't any
> a. fuzz factors
> b. rejections
> anymore. Instead I highly tried to put Andrew's "The perfect patch"-guidelines into practice. Although this kind of perfection reduces maintainers to gatekeepers in some cases - the borders of what is what and who is who are highly mutual...
> 
> So the basic thing is just:
> 1. To understand that everyone develops, independent from the knowledge and understanding level.
> 2. To understand that everyone has good ideas at least sometimes, independent from knowledge and understanding level.
> 
> And, even if you do not want to understand it out of whatever reason, it is no fun for any person to sound or act "abusive".
> We're all just trying to search and find solutions, that's all.
> 
> Above that I want to thank you for the theoretical introduction that you gave.
> And I hope it helps after all.
> But I am still very sad that the cx878 project died the way it died, so very close before its maturity to be implied into Mercurial tree. I did my best to help, but in the end I nothing but wasted time - and after all, I do not remember where the repository resides, after thaddatil.net has been down for months now... What a pity!

No, the cx878 project never died. thadathil.net was hosted at my office.
When the office moved a bit and some other complications, thadathil.net
went offline. on top of that, at work i was given additional
responsibilities for which i was struggling real hard. work with regards
to DVB i just do it in my spare time, but i try to steal away some time
from office work as well.

Christoph usually used to review all my code as well as some others.
With the upcoming KDE4, he was working more with kaffeine and had little
time, himself.

And as you might be aware i was working with a new delivery system
DVB-S2. When one works with a new delivery system, the existing API
proved too restrictive. Then working on which i trampled onto many
issues (not even referring to the new delivery system, or the issues
with the demodulator, mind you S2 is a bit complex and can really
confuse people.) with DVB-CORE itself, which led to another API update
other than multiproto, the Adapter API extensions. while on this again
stumbled where advanced operations where performed at the in kernel
demuxer, not forgetting an additional DSS demuxer is also needed in
kernel for DSS support.

With all these and struggling hard with 4 hours sleep, well i couldn't
take all those flames (More than what you see on the ML's many people
tend to send private mails for some reason or the other for help.
Normally i don't reject anyone's request), you can say i was kind of
worn out. Above all these some developers were very "unfriendly", some
did mischief (politics) too, which led to a larger rift.

So i chose to remain silent. That's all.

During this period, Julian was kind enough to provide me hosting for my
requirements. I will try to get thadathil.net up soon (many people used
to have firmware downloads from there, also some people had access there
for hosting test repo's and so on)

Well, that was a long rant

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/2/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Wed, 02 May 2007 17:30:32 +0400
> > Von: Manu Abraham <abraham.manu@gmail.com>
> > An: Trent Piepho <xyzzy@speakeasy.org>
> > CC: Simon Arlott <simon@fire.lp0.eu>, Linux Kernel Mailing list
> <linux-kernel@vger.kernel.org>, torvalds@linux-foundation.org, Jan
> Engelhardt <jengelh@linux01.gwdg.de>, helge.hafting@aitel.hist.no,
> akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was:
> Critical	points	about ...)
> >
> >> Trent Piepho wrote:
> >>> On Tue, 1 May 2007, Simon Arlott wrote:
> >>>> On 30/04/07 22:17, Markus Rechberger wrote:
> >>>>> From my side I do not see any problem with that patch, if someone else
> >>>>> has a problem with it please state out the reason.
> >>>> I have no problem with the patch since it has nothing to do with my DVB
> >>>> card but you're only encouraging Uwe to be abusive since it seems to
> >>>> help get him what he wants:
> >>> I've been aware of the problem with dst not fully using the dvb
> >> customization
> >>> systems(*) for a long time.  It came up when dvb_attach() et al were
> >> first
> >>> being integrated, well before any rejected patches or strongly worded
> >> emails
> >>> or whatever from certain people that I'm aware of.
> >>>
> >> Well, your understanding of the device is quite limited and hence your
> >> comments and patches.
> >>
> >> The DST as it refers to is an embedded system a x86 Compatible RISC core
> >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own
> >> IO and 2 DMA channels. What we have is a PQFP device
> >>
> >> This is the case in most cases. On some cheaper cards the embedded
> >> system is replaced by an 8 bit host microcontroller, to cut down costs
> >> where all the features are not required for a specific model
> >>
> >> Additionally this embedded system has a fast shovelling engine for the
> >> MPEG2 TS routing in between the
> >> This embedded system is connected to an actual
> >> (1) DVB frontend [2]
> >> (2) DVB CA interface [3]
> >> (3) Analog tuner
> >> (4) Audio interfaces
> >>
> >> These features are not the characteristics of a DVB Frontend. Here there
> >> is a DVB frontend like the normal ones which is hidden behind another
> >> pseudo bridge (So you don't have *any* access to the frontend at large)
> >>
> >> It is not necessary that *all* the dst cards (there are around ~15
> >> different variants of the same) do have the very same feature set.
> >>
> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
> >> fact it is a combo driver supporting the entire devices using a common
> >> command set
> >>
> >> In such a case it has more characteristics of the PCI bridge and in fact
> >> heavily tied to it and has it's own advantages.
> >>
> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and
> >> since
> >>> I already know about the issues here, I felt I should post a patch for
> >> them
> >>> any other reasonable developers who might spend time on this.
> >>>
> >> I would think that it would be *extremely* rude for a person to send in
> >> patches for a device that which you don't understand at all, when it is
> >> for limiting the capability of the said device
> >
> > Hi Manu,
> > now if this is your evalution about it all, then let me tell you that I
> feel deeply sorry about it.
> >
> > Fact is:
> > Noone ever intended to send in patches limiting the capability of the said
> device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others
> never did...
> >
> > Instead of this we all have very different knowledge and understanding
> levels, with you obviously being the one with the most elaborate and
> sophisticated level.
> >
> > So please why, instead of marking other people as "rude" whose solutions
> you do not appreciate at all, don't you just pick up the pratical proposals
> of other persons, even if you do not like them for some reasons, and at
> least try to raise them up to a far more better level?
> > Thus you definitely could avoid a lots of flaming, misunderstanding, and
> other counterproductive things to happen...
> > And this would conform to practising the synergetic principle, wouldn't
> it?
> >
> > Just one hint to help you: I remember a mail from Johannes in which he
> told me that you started up this whole development thing from a zero level
> some two or three years  ago. And Johannes not forgot to state that in the
> beginning you were nothing but nerving... (now add a smiley behind this,
> please, I'd deeply appreciate you to do).
> >
> > Above that:
> > 1. Taking part in testing the mm-tree and eliminating horrible bugs in it
> I never experienced but positive and warm compromise solutions in the end.
> Experiencing this is highly enlarging one's own personality.
> > 2. If you start up at zero (like you did once too - see above and ask
> Johannes if you do not remember at all) it is no good start at all if your
> humble effort is being thrown off after the first or second reject. That's
> highly discouraging, and if it happens very often the bad experience remains
> in one's own subjective perception filter.
>
>
> i did really start very small during those early stages. Johannes did
> help me a lot in many areas, he gave me a lot of valuable information,
> for which i am thankful to him. The same goes to Ralph Metzler and many
> others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
> all in this regard (I did try to pass on such information to some
> people, they thought i was trying to sabotage their project etc.

Instead of describing what the matter was why don't you just try to
get forward now without playing the rebellian here, we sorted out a
way and accept it now.
Afterwards let's discuss what you want to change to get your changes in.

I really have the impression that you try to limit to give away useful
information, and afterwards you wonder why people don't understand
what you mean.
You should also describe the impact on other things (eg. your upcoming
work), don't expect that anyone on any mailinglist here knows what
code you host somewhere on your private servers at home.

> I stopped responding publicly as you might have seen. At one point i did
> throw away all DVB development, i did write the same on the #linuxtv IRC
> channel, did send a mail to Johannes too on that) It was just one user
> who got me back again on it, a North American DVB user
>
> In many cases it would be very nerving to work on hardware that is
> extremely undocumented. Sometimes you will have to wait for weeks for a
> certain person (persons who worked on the chips etc. On top of this
> people who worked on the devices will move away to newer organizations.
> Currently facing the same with another chip) to be free to provide an
> answer for the question. In short requires a lot of patience. On top of
> this when someone flames you in the little time one has.. well, many a
> times i lost my temper, yes.
>
> Sorry, if i was real bad.
>
> > 3. When I wrote patches since then I never gave up until there weren't any
> > a. fuzz factors
> > b. rejections
> > anymore. Instead I highly tried to put Andrew's "The perfect
> patch"-guidelines into practice. Although this kind of perfection reduces
> maintainers to gatekeepers in some cases - the borders of what is what and
> who is who are highly mutual...
> >
> > So the basic thing is just:
> > 1. To understand that everyone develops, independent from the knowledge
> and understanding level.
> > 2. To understand that everyone has good ideas at least sometimes,
> independent from knowledge and understanding level.
> >
> > And, even if you do not want to understand it out of whatever reason, it
> is no fun for any person to sound or act "abusive".
> > We're all just trying to search and find solutions, that's all.
> >
> > Above that I want to thank you for the theoretical introduction that you
> gave.
> > And I hope it helps after all.
> > But I am still very sad that the cx878 project died the way it died, so
> very close before its maturity to be implied into Mercurial tree. I did my
> best to help, but in the end I nothing but wasted time - and after all, I do
> not remember where the repository resides, after thaddatil.net has been down
> for months now... What a pity!
>
> No, the cx878 project never died. thadathil.net was hosted at my office.
> When the office moved a bit and some other complications, thadathil.net
> went offline. on top of that, at work i was given additional
> responsibilities for which i was struggling real hard. work with regards
> to DVB i just do it in my spare time, but i try to steal away some time
> from office work as well.
>
> Christoph usually used to review all my code as well as some others.
> With the upcoming KDE4, he was working more with kaffeine and had little
> time, himself.
>
> And as you might be aware i was working with a new delivery system
> DVB-S2. When one works with a new delivery system, the existing API
> proved too restrictive. Then working on which i trampled onto many
> issues (not even referring to the new delivery system, or the issues
> with the demodulator, mind you S2 is a bit complex and can really
> confuse people.) with DVB-CORE itself, which led to another API update
> other than multiproto, the Adapter API extensions. while on this again
> stumbled where advanced operations where performed at the in kernel
> demuxer, not forgetting an additional DSS demuxer is also needed in
> kernel for DSS support.
>

Is there any proposal available which describes these changes?

> With all these and struggling hard with 4 hours sleep, well i couldn't
> take all those flames (More than what you see on the ML's many people
> tend to send private mails for some reason or the other for help.
> Normally i don't reject anyone's request), you can say i was kind of
> worn out. Above all these some developers were very "unfriendly", some
> did mischief (politics) too, which led to a larger rift.
>


Try to get all parties satisfied here, if you don't want dvb_attach
for the DST/BT878 to be used here explain why so that everyone
understands it, I don't see that anything gets locked out because the
current code uses a very similar method at the moment (yes I know that
it's no frontend, but it's not even implemented as something really
special)
If you have future plans about it write about them, and write why they
will hurt your work.

Markus

> So i chose to remain silent. That's all.
>
> During this period, Julian was kind enough to provide me hosting for my
> requirements. I will try to get thadathil.net up soon (many people used
> to have firmware downloads from there, also some people had access there
> for hosting test repo's and so on)
>
> Well, that was a long rant
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>


-- 
Markus Rechberger

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Wed, 02 May 2007 20:45:58 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points	about ...)

> Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Wed, 02 May 2007 17:30:32 +0400
> > Von: Manu Abraham <abraham.manu@gmail.com>
> > An: Trent Piepho <xyzzy@speakeasy.org>
> > CC: Simon Arlott <simon@fire.lp0.eu>, Linux Kernel Mailing list
> <linux-kernel@vger.kernel.org>, torvalds@linux-foundation.org, Jan Engelhardt
> <jengelh@linux01.gwdg.de>, helge.hafting@aitel.hist.no,
> akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was:
> Critical	points	about ...)
> > 
> >> Trent Piepho wrote:
> >>> On Tue, 1 May 2007, Simon Arlott wrote:
> >>>> On 30/04/07 22:17, Markus Rechberger wrote:
> >>>>> From my side I do not see any problem with that patch, if someone
> else
> >>>>> has a problem with it please state out the reason.
> >>>> I have no problem with the patch since it has nothing to do with my
> DVB
> >>>> card but you're only encouraging Uwe to be abusive since it seems to
> >>>> help get him what he wants:
> >>> I've been aware of the problem with dst not fully using the dvb
> >> customization
> >>> systems(*) for a long time.  It came up when dvb_attach() et al were
> >> first
> >>> being integrated, well before any rejected patches or strongly worded
> >> emails
> >>> or whatever from certain people that I'm aware of.
> >>>
> >> Well, your understanding of the device is quite limited and hence your
> >> comments and patches.
> >>
> >> The DST as it refers to is an embedded system a x86 Compatible RISC
> core
> >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's
> own
> >> IO and 2 DMA channels. What we have is a PQFP device
> >>
> >> This is the case in most cases. On some cheaper cards the embedded
> >> system is replaced by an 8 bit host microcontroller, to cut down costs
> >> where all the features are not required for a specific model
> >>
> >> Additionally this embedded system has a fast shovelling engine for the
> >> MPEG2 TS routing in between the
> >> This embedded system is connected to an actual
> >> (1) DVB frontend [2]
> >> (2) DVB CA interface [3]
> >> (3) Analog tuner
> >> (4) Audio interfaces
> >>
> >> These features are not the characteristics of a DVB Frontend. Here
> there
> >> is a DVB frontend like the normal ones which is hidden behind another
> >> pseudo bridge (So you don't have *any* access to the frontend at large)
> >>
> >> It is not necessary that *all* the dst cards (there are around ~15
> >> different variants of the same) do have the very same feature set.
> >>
> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In
> >> fact it is a combo driver supporting the entire devices using a common
> >> command set
> >>
> >> In such a case it has more characteristics of the PCI bridge and in
> fact
> >> heavily tied to it and has it's own advantages.
> >>
> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton,
> and
> >> since
> >>> I already know about the issues here, I felt I should post a patch for
> >> them
> >>> any other reasonable developers who might spend time on this.
> >>>
> >> I would think that it would be *extremely* rude for a person to send in
> >> patches for a device that which you don't understand at all, when it is
> >> for limiting the capability of the said device
> > 
> > Hi Manu,
> > now if this is your evalution about it all, then let me tell you that I
> feel deeply sorry about it.
> > 
> > Fact is:
> > Noone ever intended to send in patches limiting the capability of the
> said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and
> others never did...
> > 
> > Instead of this we all have very different knowledge and understanding
> levels, with you obviously being the one with the most elaborate and
> sophisticated level.
> > 
> > So please why, instead of marking other people as "rude" whose solutions
> you do not appreciate at all, don't you just pick up the pratical
> proposals of other persons, even if you do not like them for some reasons, and at
> least try to raise them up to a far more better level?
> > Thus you definitely could avoid a lots of flaming, misunderstanding, and
> other counterproductive things to happen...
> > And this would conform to practising the synergetic principle, wouldn't
> it?
> > 
> > Just one hint to help you: I remember a mail from Johannes in which he
> told me that you started up this whole development thing from a zero level
> some two or three years  ago. And Johannes not forgot to state that in the
> beginning you were nothing but nerving... (now add a smiley behind this,
> please, I'd deeply appreciate you to do).
> > 
> > Above that:
> > 1. Taking part in testing the mm-tree and eliminating horrible bugs in
> it I never experienced but positive and warm compromise solutions in the
> end. Experiencing this is highly enlarging one's own personality.
> > 2. If you start up at zero (like you did once too - see above and ask
> Johannes if you do not remember at all) it is no good start at all if your
> humble effort is being thrown off after the first or second reject. That's
> highly discouraging, and if it happens very often the bad experience remains
> in one's own subjective perception filter.
> 
> 
> i did really start very small during those early stages. Johannes did
> help me a lot in many areas, he gave me a lot of valuable information,
> for which i am thankful to him. The same goes to Ralph Metzler and many
> others who gave me a big hand to bootup. Can't forget Andrew, Marcel et
> all in this regard (I did try to pass on such information to some
> people, they thought i was trying to sabotage their project etc.

Hi Manu,

I think noone ever thought you were trying to sabotage any project.
Perhaps you simply missed to „sell“ your ideas a little bit better on the eloquence level.

Example: During this horrible bt8xx breakdown period (kernels 2.6.13 up to 2.6.17-rc1) it was Edgar who definitely did not have the technically better approach, but „sold“ his thoughts far more transparent, reading more logical.
But in the end it was your approach that ensured the best possible solution in the end, not anybody else's.

 I
> stopped responding publicly as you might have seen. At one point i did
> throw away all DVB development, i did write the same on the #linuxtv IRC
> channel, did send a mail to Johannes too on that) It was just one user
> who got me back again on it, a North American DVB user

I would like to be the second one to encourage you to get back on it, as it is a great pity if such a great profound knowledge just disappears from the surface.

> 
> In many cases it would be very nerving to work on hardware that is
> extremely undocumented.

I know, as I had Email contact to Peter Hettkamp, the author of the cx24110 frontend. He told me about the hindrance policy executed by the companies:

a. Pinnacle never offered free cards for linux driver development
b. Connexant only offers info if you sign a very restrictive paper

Plus, on the other hand, the drivers that are written and published for Windoze are a catastrophe like the whole system itself is a catastrophe.

 Sometimes you will have to wait for weeks for a
> certain person (persons who worked on the chips etc. On top of this
> people who worked on the devices will move away to newer organizations.
> Currently facing the same with another chip) to be free to provide an
> answer for the question. In short requires a lot of patience. On top of
> this when someone flames you in the little time one has.. well, many a
> times i lost my temper, yes.
> 
> Sorry, if i was real bad.

I can accept that as it reads very truthful. But in fact the biggest shame is on me because I started to flame you. So please forgive me for having done this.

When I first saw this cx878 project I had the impression that you were trying to get it done on people's backs without ensuring the continuity of a working driver (speak: a bttv dependent one). This may sound quite absurd, but it's my personally view why this immensely long breakdown period ever happened at all.

IMHO there should be exactly two plans:

a. Trying to improve the existing working concept by making dst, dst_ca, and dvb-pll deselectable in a way that does not cause any Oopses or regressions anyway: There is not much work to be done. Just merge my work on makefile and Kconfig with Trent Piepho's work on the rest.
And if you are not satisfied with that for whatever reason I'd deeply appreciate you to settle down in it and add the necessary code that you personally are missing. Should not be much effort, should it?

b. Trying to finish the bt878 project, which is very close to being real mature (Christoph responded that he does not have any time for it so he personally sees no future for it, which is a pity, but should never be a hindrance not to finish it as it follows the right path).

On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound.
I do not think that the traditional bttv dependencies are such a high and hopeless hindrance reason that cannot be overcome at all.
We're gonna make it if we stick together.

BUT:
It would be utmost terrible to merge both plans with two different priorities into one. For the moment, plan a is highest priority.
But plan b should not be forgotten anyway.
I can offer testing and documentary work for both plans.

> 
> > 3. When I wrote patches since then I never gave up until there weren't
> any
> > a. fuzz factors
> > b. rejections
> > anymore. Instead I highly tried to put Andrew's "The perfect
> patch"-guidelines into practice. Although this kind of perfection reduces maintainers
> to gatekeepers in some cases - the borders of what is what and who is who
> are highly mutual...
> > 
> > So the basic thing is just:
> > 1. To understand that everyone develops, independent from the knowledge
> and understanding level.
> > 2. To understand that everyone has good ideas at least sometimes,
> independent from knowledge and understanding level.
> > 
> > And, even if you do not want to understand it out of whatever reason, it
> is no fun for any person to sound or act "abusive".
> > We're all just trying to search and find solutions, that's all.
> > 
> > Above that I want to thank you for the theoretical introduction that you
> gave.
> > And I hope it helps after all.
> > But I am still very sad that the cx878 project died the way it died, so
> very close before its maturity to be implied into Mercurial tree. I did my
> best to help, but in the end I nothing but wasted time - and after all, I
> do not remember where the repository resides, after thaddatil.net has been
> down for months now... What a pity!
> 
> No, the cx878 project never died. thadathil.net was hosted at my office.
> When the office moved a bit and some other complications, thadathil.net
> went offline. on top of that, at work i was given additional
> responsibilities for which i was struggling real hard. work with regards
> to DVB i just do it in my spare time, but i try to steal away some time
> >from office work as well.
> 
> Christoph usually used to review all my code as well as some others.
> With the upcoming KDE4, he was working more with kaffeine and had little
> time, himself.
> 
> And as you might be aware i was working with a new delivery system
> DVB-S2. When one works with a new delivery system, the existing API
> proved too restrictive. Then working on which i trampled onto many
> issues (not even referring to the new delivery system, or the issues
> with the demodulator, mind you S2 is a bit complex and can really
> confuse people.) with DVB-CORE itself, which led to another API update
> other than multiproto, the Adapter API extensions. while on this again
> stumbled where advanced operations where performed at the in kernel
> demuxer, not forgetting an additional DSS demuxer is also needed in
> kernel for DSS support.
> 
> With all these and struggling hard with 4 hours sleep, well i couldn't
> take all those flames (More than what you see on the ML's many people
> tend to send private mails for some reason or the other for help.
> Normally i don't reject anyone's request), you can say i was kind of
> worn out. Above all these some developers were very "unfriendly", some
> did mischief (politics) too, which led to a larger rift.

Sounds horrible. I once again deeply regret what I started in the past, but I hope I gave enough hints how we all can learn out of it, including me.
If there is no team chief stepping in between to settle down attacks and ellbow egoisms then I think there is a big gap in the personnel structure of the linuxtv.org developpers team.

> 
> So i chose to remain silent. That's all.
> 
> During this period, Julian was kind enough to provide me hosting for my
> requirements. I will try to get thadathil.net up soon (many people used
> to have firmware downloads from there, also some people had access there
> for hosting test repo's and so on)

That sounds fantastic. So can we continue to put plan b into practice too??

> 
> Well, that was a long rant

I hate the word „rant“ for its negative taste at least in the german translation.
I would rather say it was necessary to state all this.
And I also hat terminologies like „The perfect patch.“
Nothing is perfect. But the stepping forward idea is simply to put some puzzle parts together in an appropriate manner.

I guess the only reason why I flamed Mike Krufky was his rejection of unsigned patches. That was my fault too and I regret what I said about him. So please Mike, if you read this please forgive me.

IMHO a missing signature should not be treated like a fetish.
Also unsigned patches can contain good ideas, can't they?
Sometimes it is just necessary to merge the appropriate puzzle parts.

But, on the other hand I remember having asked Edgar at least five times for what reason he remained so stubborn in the signature question.
I never got back at least one reply on that, for whatever reason....

See, the conflict culture here very often conforms to something like a kindergarden, and I deeply regret that...

Above all I still am very hopeful that we can get back to the technical points to be resolved concerning plan a (optimize the bttv dependent concept for now).

Perhaps we should start another thread on this if everybody can agree.
And if you or anybody else feel that you run out of temper or lose control of whatever reason, just move one step backwards, sleep over it one or two nights, and take a new start then with a cool and calm mind... 

Do I expect too much? Hope I do not!

Yours sincerely

Uwe

P. S.:

A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested.

B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can.

Must not be immediately (no sweat please), but I am looking forward to receive a response from you.

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Mauro Carvalho Chehab]

Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu:
> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:

> > However, when dst is selected, I got those errors:
> 
> When I made this patch I was basing it off a patch I made around 9 months
> ago.  I thought since that one was ok, this would be ok too, and in my
> hurry to get it done I've clearly put too little effort into checking it,
> and I'm sorry to have wasted your time.
> 
> I promise, this time it's right!
> http://linuxtv.org/hg/~tap/dst-new

Confirmed. Now the patch is properly working. My tests were done with a
board with DST. Those are the results:

1) when DST is unselected, on a board with DST, it will print the errors
indicating that the Kconfig items were not selected:

DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800

The only issue is the wrong printk msg, stating that a "frontend driver"
were not found. As this issue also happens with the current driver, due
the usage of dvb_attach() macro, I don't see any regressions.

It would be nice, however, to have a patch making dvb_attach more
generic, by e.g. having a variant that allows passing another message.

Trying to run dvb programs like scan and kaffeine will properly fail.

2) With DST selected, the driver works properly. 

The changes also solved the issue of removing the dst drivers. Before
the patch, sometimes it is required to force removal of dst module with
the '-f' flag, since the module count were wrong.

---

I'll risk to make a briefing of the technical points:

<SUMMARY>
Current issues:
	1) allow deselecting DST/DST_CA support, since this is not needed by
some supported boards;
	2) sometimes, module removal don't work with dst, since usage count
becomes wrong;
	3) if dst or dst_ca is not properly loaded, the printk message wrongly
indicates that "A frontend driver was not found"

The Trent's original patch were written on Aug, 2006 (*). The current
version fixes (1) and (2). It doesn't touch on (3). There aren't any
other patches properly fixing (1) and (2).

There's an argument against the prototype changes on dst_attach and
dst_ca_attach since they aren't frontend.
</SUMMARY>

(*) Notice: I can't remember why the patches were not applied on that
time. I think somebody nacked they, although I didn't found any record
about the patch on my mailbox.

About the usage of frontend support for a non-frontend module, I really
can't see any issues at the current implementation, since even before
the patch, all DST initialization are done by a routine called
"frontend_init()". Even dst not being a frontend, the initialization
gets the result of the attachment process, using it as a "frontend":

	state = kmalloc(sizeof (struct dst_state), GFP_KERNEL);

        state->config = &dst_config;
        state->i2c = card->i2c_adapter;
        state->bt = card->bt;
        state->dst_ca = NULL;

        dvb_attach(dst_attach, state, &card->dvb_adapter);

        card->fe = &state->frontend;

	(comments and error checks removed to make code cleaner)

The patch basically moved state initialization to dst_attach. The above
code, after the patch is:
	
	card->fe = dvb_attach(dst_attach, &dst_config, card->bt, card->i2c_adapter);

So, I didn't noticed any regressions by running the modified driver nor
I couldn't identify any regressions by inspecting the source code. 

The end result seems also cleaner and easier to understand, preserving
all characteristics of the original code. Also, it uses dvb_attach the
same way as the other dvb helper modules.

If later any changes will be needed to allow using DST on different
configurations, future patches probably will need to move dst
initialization to other places, and use different callbacks for it,
altering the above initialization. I can't see why those changes would
possibly avoid any further changes at the driver.

That's said, I intend to commit the two patches, fixing the current
issues, at this weekend.

I'm open to other technical reviews of the patches. 

-- 
Cheers,
Mauro

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Uwe Bugla wrote:

> On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound.

Can you send your compile warnings ? I couldn't find the same in my
mailbox any report on the same. Maybe my mail filter did something.

> A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested.
> 
> B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can.
> 
> Must not be immediately (no sweat please), but I am looking forward to receive a response from you.
> 

What i would like to do is like this: Have the current state frozen as
it is, such that there is a fallback case (The dst is quite fragile and
change at some place would break another. ie, what looks good for one
DST variant is bad for the other). Work on a new tree (CX878) and
migrate stuff to it. Remove the old one, once things are done.

I wouldn't want to mess up the current working situation and hence.

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Mauro Carvalho Chehab wrote:
> Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu:
>> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> 
>>> However, when dst is selected, I got those errors:
>> When I made this patch I was basing it off a patch I made around 9 months
>> ago.  I thought since that one was ok, this would be ok too, and in my
>> hurry to get it done I've clearly put too little effort into checking it,
>> and I'm sorry to have wasted your time.
>>
>> I promise, this time it's right!
>> http://linuxtv.org/hg/~tap/dst-new
> 
> Confirmed. Now the patch is properly working. My tests were done with a
> board with DST. Those are the results:
> 
> 1) when DST is unselected, on a board with DST, it will print the errors
> indicating that the Kconfig items were not selected:
> 
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800
> 
> The only issue is the wrong printk msg, stating that a "frontend driver"
> were not found. As this issue also happens with the current driver, due
> the usage of dvb_attach() macro, I don't see any regressions.
> 
> It would be nice, however, to have a patch making dvb_attach more
> generic, by e.g. having a variant that allows passing another message.
> 
> Trying to run dvb programs like scan and kaffeine will properly fail.
> 
> 2) With DST selected, the driver works properly. 
> 
> The changes also solved the issue of removing the dst drivers. Before
> the patch, sometimes it is required to force removal of dst module with
> the '-f' flag, since the module count were wrong.
> 
> ---
> 
> I'll risk to make a briefing of the technical points:
> 
> <SUMMARY>
> Current issues:
> 	1) allow deselecting DST/DST_CA support, since this is not needed by
> some supported boards;
> 	2) sometimes, module removal don't work with dst, since usage count
> becomes wrong;
> 	3) if dst or dst_ca is not properly loaded, the printk message wrongly
> indicates that "A frontend driver was not found"
> 
> The Trent's original patch were written on Aug, 2006 (*). The current
> version fixes (1) and (2). It doesn't touch on (3). There aren't any
> other patches properly fixing (1) and (2).
> 
> There's an argument against the prototype changes on dst_attach and
> dst_ca_attach since they aren't frontend.
> </SUMMARY>
> 
> (*) Notice: I can't remember why the patches were not applied on that
> time. I think somebody nacked they, although I didn't found any record
> about the patch on my mailbox.
> 
> About the usage of frontend support for a non-frontend module, I really
> can't see any issues at the current implementation, since even before
> the patch, all DST initialization are done by a routine called
> "frontend_init()". 

*Wrong*.  Frontend Init sends a command to the whole system to
initialize the frontend, Not initialize the DST
Whatever frontend naming conventions are in there are a relic from
Andrew's FE_REFACTORING changesets.

Even dst not being a frontend, the initialization
> gets the result of the attachment process, using it as a "frontend":
> 
> 	state = kmalloc(sizeof (struct dst_state), GFP_KERNEL);
> 
>         state->config = &dst_config;
>         state->i2c = card->i2c_adapter;
>         state->bt = card->bt;
>         state->dst_ca = NULL;
> 
>         dvb_attach(dst_attach, state, &card->dvb_adapter);
> 
>         card->fe = &state->frontend;
> 
> 	(comments and error checks removed to make code cleaner)
> 
> The patch basically moved state initialization to dst_attach. The above
> code, after the patch is:
> 	
> 	card->fe = dvb_attach(dst_attach, &dst_config, card->bt, card->i2c_adapter);
> 
> So, I didn't noticed any regressions by running the modified driver nor
> I couldn't identify any regressions by inspecting the source code. 
> 
> The end result seems also cleaner and easier to understand, preserving
> all characteristics of the original code. Also, it uses dvb_attach the
> same way as the other dvb helper modules.
> 
> If later any changes will be needed to allow using DST on different
> configurations, future patches probably will need to move dst
> initialization to other places, and use different callbacks for it,
> altering the above initialization. I can't see why those changes would
> possibly avoid any further changes at the driver.
> 
> That's said, I intend to commit the two patches, fixing the current
> issues, at this weekend.
> 

I did explain my stand in a previous mail.

NACK

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Thu, 03 May 2007 18:44:36 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-kernel@vger.kernel.org, linux-dvb@linuxtv.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points	about ...)

> Uwe Bugla wrote:
> 
> > On the technical layer I noticed that I heard some Pinnacle relais click
> during testing, but there were some i2c_bus symbols missing during
> compilation. So I guess those missing symbols are responsible for getting neither
> picture nor sound.
> 
> Can you send your compile warnings ? I couldn't find the same in my
> mailbox any report on the same. Maybe my mail filter did something.

I can certainly send compile warnings and dmesg and whatever you need.

But at first I need another link WHERE I can download the actual cx878 code.

Is it thaddathil.net or where the hell has it gone?

Just send me one link please, otherwise I do not have any chance to help you, OK?

> 
> > A. If you are really interested I can send you my basic puzzle parts in
> short, opening a new thread on this issue. Just give me a short response if
> you are interested.
> > 
> > B. If you want to continue the cx878 project please drop me a short note
> where I can download it to test and enlarge it with my own ideas as good
> as I can.
> > 
> > Must not be immediately (no sweat please), but I am looking forward to
> receive a response from you.
> > 
> 
> What i would like to do is like this: Have the current state frozen as
> it is, such that there is a fallback case (The dst is quite fragile and
> change at some place would break another. ie, what looks good for one
> DST variant is bad for the other). Work on a new tree (CX878) and
> migrate stuff to it. Remove the old one, once things are done.
> 
> I wouldn't want to mess up the current working situation and hence.

Hi Manu,

But it would be an acceptable compromise FOR NOW, wouldn't it?
So please don't turn your back on it, even if it may be incomplete for your needs.
Just add your SOB and then focus on cx878 with full power, OK?
Anything else would be terrible in pschological terms, you know?
Just think about Trent, Markus, me, so many others, you know.
Do I expect too much? Hope I do not!

Plus:

If I should help you it would be a pleasure for me if you could offer an acceptable time window that fulfills the following aims:

a. not to exhaust or threaten or bug you or nerve you (noone wants that, you know)
b. give me and others a feeling for when things of whatever issue are done and resolved, you know.

So at least for me it's very hard to continue if the whole thing looks like a never ending story, you know? So please give us a chance. And please do better this time.
Just learn and develop, you know.
And be more transparent and eloquent this time, but do not crawl back into a snail house, OK?

Waiting for your link meanwhile to download that hopeful project...
CCing some other persons who are perhaps interested in this....

Yours sincerely
Uwe

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Thu, 03 May 2007 19:15:32 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: Mauro Carvalho Chehab <mchehab@infradead.org>
CC: linux-dvb@linuxtv.org, Trent Piepho <xyzzy@speakeasy.org>, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (..	was:	Critical	points about ...)

> Mauro Carvalho Chehab wrote:
> > Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu:
> >> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
> > 
> >>> However, when dst is selected, I got those errors:
> >> When I made this patch I was basing it off a patch I made around 9
> months
> >> ago.  I thought since that one was ok, this would be ok too, and in my
> >> hurry to get it done I've clearly put too little effort into checking
> it,
> >> and I'm sorry to have wasted your time.
> >>
> >> I promise, this time it's right!
> >> http://linuxtv.org/hg/~tap/dst-new
> > 
> > Confirmed. Now the patch is properly working. My tests were done with a
> > board with DST. Those are the results:
> > 
> > 1) when DST is unselected, on a board with DST, it will print the errors
> > indicating that the Kconfig items were not selected:
> > 
> > DVB: registering new adapter (bttv0).
> > DVB: Unable to find symbol dst_attach()
> > frontend_init: Could not find a Twinhan DST.
> > dvb-bt8xx: A frontend driver was not found for device 109e/0878
> subsystem fbfb/f800
> > 
> > The only issue is the wrong printk msg, stating that a "frontend driver"
> > were not found. As this issue also happens with the current driver, due
> > the usage of dvb_attach() macro, I don't see any regressions.
> > 
> > It would be nice, however, to have a patch making dvb_attach more
> > generic, by e.g. having a variant that allows passing another message.
> > 
> > Trying to run dvb programs like scan and kaffeine will properly fail.
> > 
> > 2) With DST selected, the driver works properly. 
> > 
> > The changes also solved the issue of removing the dst drivers. Before
> > the patch, sometimes it is required to force removal of dst module with
> > the '-f' flag, since the module count were wrong.
> > 
> > ---
> > 
> > I'll risk to make a briefing of the technical points:
> > 
> > <SUMMARY>
> > Current issues:
> > 	1) allow deselecting DST/DST_CA support, since this is not needed by
> > some supported boards;
> > 	2) sometimes, module removal don't work with dst, since usage count
> > becomes wrong;
> > 	3) if dst or dst_ca is not properly loaded, the printk message wrongly
> > indicates that "A frontend driver was not found"
> > 
> > The Trent's original patch were written on Aug, 2006 (*). The current
> > version fixes (1) and (2). It doesn't touch on (3). There aren't any
> > other patches properly fixing (1) and (2).
> > 
> > There's an argument against the prototype changes on dst_attach and
> > dst_ca_attach since they aren't frontend.
> > </SUMMARY>
> > 
> > (*) Notice: I can't remember why the patches were not applied on that
> > time. I think somebody nacked they, although I didn't found any record
> > about the patch on my mailbox.
> > 
> > About the usage of frontend support for a non-frontend module, I really
> > can't see any issues at the current implementation, since even before
> > the patch, all DST initialization are done by a routine called
> > "frontend_init()". 
> 
> *Wrong*.  Frontend Init sends a command to the whole system to
> initialize the frontend, Not initialize the DST
> Whatever frontend naming conventions are in there are a relic from
> Andrew's FE_REFACTORING changesets.
> 
> Even dst not being a frontend, the initialization
> > gets the result of the attachment process, using it as a "frontend":
> > 
> > 	state = kmalloc(sizeof (struct dst_state), GFP_KERNEL);
> > 
> >         state->config = &dst_config;
> >         state->i2c = card->i2c_adapter;
> >         state->bt = card->bt;
> >         state->dst_ca = NULL;
> > 
> >         dvb_attach(dst_attach, state, &card->dvb_adapter);
> > 
> >         card->fe = &state->frontend;
> > 
> > 	(comments and error checks removed to make code cleaner)
> > 
> > The patch basically moved state initialization to dst_attach. The above
> > code, after the patch is:
> > 	
> > 	card->fe = dvb_attach(dst_attach, &dst_config, card->bt,
> card->i2c_adapter);
> > 
> > So, I didn't noticed any regressions by running the modified driver nor
> > I couldn't identify any regressions by inspecting the source code. 
> > 
> > The end result seems also cleaner and easier to understand, preserving
> > all characteristics of the original code. Also, it uses dvb_attach the
> > same way as the other dvb helper modules.
> > 
> > If later any changes will be needed to allow using DST on different
> > configurations, future patches probably will need to move dst
> > initialization to other places, and use different callbacks for it,
> > altering the above initialization. I can't see why those changes would
> > possibly avoid any further changes at the driver.
> > 
> > That's said, I intend to commit the two patches, fixing the current
> > issues, at this weekend.
> > 
> 
> I did explain my stand in a previous mail.
> 
> NACK

Technically may be OK, psychologically this decision is desasterous. Why don't you learn, for god's sake?
> 
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Uwe Bugla wrote:

> Hi Manu,
> 
> But it would be an acceptable compromise FOR NOW, wouldn't it?


The reason is i do not wish to make changes to it, till i can fix it. It
is indeed hard to fix things that support a lot of devices, with
different issues. There are enough of issues in there.

You can look at all those frontend not found issues on the DVB ML.

The people who make all these noise, do nothing but just play politics.
Just do a search on the linux-dvb ML at gmane.org. You can easily find them.

> Waiting for your link meanwhile to download that hopeful project...

http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Uwe Bugla wrote:
>
> > Hi Manu,
> >
> > But it would be an acceptable compromise FOR NOW, wouldn't it?
>
>
> The reason is i do not wish to make changes to it, till i can fix it. It
> is indeed hard to fix things that support a lot of devices, with
> different issues. There are enough of issues in there.
>
> You can look at all those frontend not found issues on the DVB ML.
>
> The people who make all these noise, do nothing but just play politics.
> Just do a search on the linux-dvb ML at gmane.org. You can easily find them.
>

Manu,

to me it looks like your  attitude is not acceptable here, I sent
several mails already which you just use to ignore.
If you don't change that attitude immediatelly I'd really wish to get
you banned of this community until you're open for discussions.

http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html

there's a bugreport and you fully ignore it, and you blame it on the
"politicians" here, telling me that there are mails out there
somewhere shows that you're not interested in getting forward.

I'm waiting for your response here.

Markus

> > Waiting for your link meanwhile to download that hopeful project...
>
> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
>


-- 
Markus Rechberger

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Thu, 03 May 2007 19:48:50 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, mchehab@infradead.org, mrechberger@gmail.com, mkrufky@linuxtv.org, xyzzy@speakeasy.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points	about ...)

> Uwe Bugla wrote:
> 
> > Hi Manu,
> > 
> > But it would be an acceptable compromise FOR NOW, wouldn't it?
> 
> 
> The reason is i do not wish to make changes to it, till i can fix it. It
> is indeed hard to fix things that support a lot of devices, with
> different issues. There are enough of issues in there.
> 
> You can look at all those frontend not found issues on the DVB ML.
> 
> The people who make all these noise, do nothing but just play politics.
> Just do a search on the linux-dvb ML at gmane.org. You can easily find
> them.
> 
> > Waiting for your link meanwhile to download that hopeful project...
> 
> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2

Sorry Manu,

incorrect link!
Why?

If you download the thing as tar.bz2 you get a zero file down.

However, if you download the thing as tar.gz you will succeed in getting it.

I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned.

I am really looking forward to see this fantastic thing finished....
It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others...

So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see.

OKIDOK so far?

Uwe



-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Thu, 03 May 2007 19:48:50 +0400
> Von: Manu Abraham <abraham.manu@gmail.com>
> An: Uwe Bugla <uwe.bugla@gmx.de>
> CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, mchehab@infradead.org, mrechberger@gmail.com, mkrufky@linuxtv.org, xyzzy@speakeasy.org
> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points	about ...)
> 
>> Uwe Bugla wrote:
>>
>>> Hi Manu,
>>>
>>> But it would be an acceptable compromise FOR NOW, wouldn't it?
>>
>> The reason is i do not wish to make changes to it, till i can fix it. It
>> is indeed hard to fix things that support a lot of devices, with
>> different issues. There are enough of issues in there.
>>
>> You can look at all those frontend not found issues on the DVB ML.
>>
>> The people who make all these noise, do nothing but just play politics.
>> Just do a search on the linux-dvb ML at gmane.org. You can easily find
>> them.
>>
>>> Waiting for your link meanwhile to download that hopeful project...
>> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
> 
> Sorry Manu,
> 
> incorrect link!
> Why?
> 
> If you download the thing as tar.bz2 you get a zero file down.

I think could be a bug in hgweb probably.

> 
> However, if you download the thing as tar.gz you will succeed in getting it.
> 

Ok. The gzip archive should be as good as the bzip archive, just that it
is slightly larger.

> I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned.
> 
> I am really looking forward to see this fantastic thing finished....
> It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others...
> 
> So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see.
> 

Let me see why hgweb gives a zero length archive

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Markus Rechberger wrote:

> Manu,
> 
> to me it looks like your  attitude is not acceptable here, I sent
> several mails already which you just use to ignore.

You very well know the reason why i am ignoring your mails. You just
tend to flame people for nothing. I tend to ignore the flamers.

> If you don't change that attitude immediatelly I'd really wish to get
> you banned of this community until you're open for discussions.
> 
> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
> 
> there's a bugreport and you fully ignore it, and you blame it on the
> "politicians" here, telling me that there are mails out there
> somewhere shows that you're not interested in getting forward.
> 

That bug report very well proves my point.

> I'm waiting for your response here.
> 
> Markus
> 
>> > Waiting for your link meanwhile to download that hopeful project...
>>
>> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
>>
>>
> 
> 

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Thu, 3 May 2007 17:59:18 +0200
Von: "Markus Rechberger" <mrechberger@gmail.com>
An: "Manu Abraham" <abraham.manu@gmail.com>
CC: "Uwe Bugla" <uwe.bugla@gmx.de>, linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, mchehab@infradead.org, mkrufky@linuxtv.org, xyzzy@speakeasy.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

> On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> > Uwe Bugla wrote:
> >
> > > Hi Manu,
> > >
> > > But it would be an acceptable compromise FOR NOW, wouldn't it?
> >
> >
> > The reason is i do not wish to make changes to it, till i can fix it. It
> > is indeed hard to fix things that support a lot of devices, with
> > different issues. There are enough of issues in there.
> >
> > You can look at all those frontend not found issues on the DVB ML.
> >
> > The people who make all these noise, do nothing but just play politics.
> > Just do a search on the linux-dvb ML at gmane.org. You can easily find
> them.
> >
> 
> Manu,
> 
> to me it looks like your  attitude is not acceptable here, I sent
> several mails already which you just use to ignore.
> If you don't change that attitude immediatelly I'd really wish to get
> you banned of this community until you're open for discussions.
> 
> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
> 
> there's a bugreport and you fully ignore it, and you blame it on the
> "politicians" here, telling me that there are mails out there
> somewhere shows that you're not interested in getting forward.
> 
> I'm waiting for your response here.
> 
> Markus

Hey Markus, fine chap: Please cool down! I just downloaded this cx878 thing which will beat a couple of flies with one attack once it is finished.

It will be more stable than every preceding driver, it will revolutionize RAM usage extraordinarily, and it will solve all outstanding technical problems involved in the current DST driver concept, if I did understand Manu right, which is different sometimes, but, as it seems, not impossible.

So he just changed his priorities, and if this thing is finished we all will be winning a lot in the end I guess...

So please at least try to get yourself involved into that project, even if there are outstanding human drawbacks - its hard with him, I know, but it is not impossible at all.
And the cx878 project is worth to engage oneself in for a thousands of very good reasons - just believe me, as I have already done a lot of testing work on it.
It's fine, and it will revolutionize the whole bt8xx driver concept.

So if there are many many people helping to finish it, that will be the best thing ever seen...

And as far Manu is concerned: he is a primadonna, as I am.
Primadonnas are real extraordinary people, you know.
So please do not beat him or treat him like this.

Yours sincerely

Uwe

Peace, brother!
> 
> > > Waiting for your link meanwhile to download that hopeful project...
> >
> >
> http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2
> >
> 
> 
> -- 
> Markus Rechberger

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Michael Krufky]

Manu Abraham wrote:
> Uwe Bugla wrote:
>   
>> If you download the thing as tar.bz2 you get a zero file down.
>>     
>
> I think could be a bug in hgweb probably.
[snip]
> Let me see why hgweb gives a zero length archive
>   
Manu,

We reported this bug to the selenic guys quite a long time ago...   You
should inherit the fix if you upgrade mercurial on your server.


Regards,

Mike

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Michael Krufky wrote:
> Manu Abraham wrote:
>> Uwe Bugla wrote:
>>   
>>> If you download the thing as tar.bz2 you get a zero file down.
>>>     
>> I think could be a bug in hgweb probably.
> [snip]
>> Let me see why hgweb gives a zero length archive
>>   
> Manu,
> 
> We reported this bug to the selenic guys quite a long time ago...   You
> should inherit the fix if you upgrade mercurial on your server.
> 

Cool. Thanks.

I think it is a newer version ..

[manu@bh ~]$ hg --version
Mercurial Distributed SCM (version 0.9)

Copyright (C) 2005 Matt Mackall <mpm@selenic.com>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

You have an account on that machine. Would you like to take a look ?

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Markus Rechberger wrote:
>
> > Manu,
> >
> > to me it looks like your  attitude is not acceptable here, I sent
> > several mails already which you just use to ignore.
>
> You very well know the reason why i am ignoring your mails. You just
> tend to flame people for nothing. I tend to ignore the flamers.
>

You should stop to rely on the history, since such a flame needs at
least 2 parties and back then you were also involved. There's nothing
else to say about that.

> > If you don't change that attitude immediatelly I'd really wish to get
> > you banned of this community until you're open for discussions.
> >
> > http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
> >
> > there's a bugreport and you fully ignore it, and you blame it on the
> > "politicians" here, telling me that there are mails out there
> > somewhere shows that you're not interested in getting forward.
> >
>
> That bug report very well proves my point.

Well it would be nice if you could answer the question in that mail
then, I don't see any reason why you shouldn't answer it.

It's just a guess, but it seems like that you had a problem with other
developers at that part and it seems like it didn't get to an end
(probably because both parties didn't agree with each other)

Markus

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Mauro Carvalho Chehab wrote:
> Enough. Let's stop arguing non technical issues.
> 
> If either one of you have any technical argue against the Trent's
> patches, please point where the fix is wrong. Otherwise, if you wish,
> you may send an acked-by agreeing with the fix.
> 

Why don't you stop this childish behaviour ?

After explaining to you the reasons in the previous mail:
being the author and maintainer of dst/dst_ca and maintainer of
dvb-bt8xx, i NACK this change

(1) You aren't DVB maintainer
(2) one shouldn't make such judgement calls on somebody else's driver
unless it falls within your own maintainership


> Mauro.
> 
> Em Qui, 2007-05-03 às 19:19 +0200, Markus Rechberger escreveu:
>> On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
>>> Markus Rechberger wrote:
>>>
>>>> Manu,
>>>>
>>>> to me it looks like your  attitude is not acceptable here, I sent
>>>> several mails already which you just use to ignore.
>>> You very well know the reason why i am ignoring your mails. You just
>>> tend to flame people for nothing. I tend to ignore the flamers.
>>>
>> You should stop to rely on the history, since such a flame needs at
>> least 2 parties and back then you were also involved. There's nothing
>> else to say about that.
>>
>>>> If you don't change that attitude immediatelly I'd really wish to get
>>>> you banned of this community until you're open for discussions.
>>>>
>>>> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
>>>>
>>>> there's a bugreport and you fully ignore it, and you blame it on the
>>>> "politicians" here, telling me that there are mails out there
>>>> somewhere shows that you're not interested in getting forward.
>>>>
>>> That bug report very well proves my point.
>> Well it would be nice if you could answer the question in that mail
>> then, I don't see any reason why you shouldn't answer it.
>>
>> It's just a guess, but it seems like that you had a problem with other
>> developers at that part and it seems like it didn't get to an end
>> (probably because both parties didn't agree with each other)
>>
>> Markus
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/3/07, VDR User <user.vdr@gmail.com> wrote:
> STOP FIGHTING ALL THE DAMN TIME!  From an outsiders perspective there
> is a lot of unnecessary & childish behavior going on at the expense of
> good ideas and coding.  It seems as though the Markus/Mauro team will
> go against anything Manu says simply because Manu is the one saying
> it.
> From what I've seen he is very knowledgeable and a good coder.

>From his technical knowledge he's as ok as many other developers are
who have been involved for several years now.

He tries to become the DVB Maintainer, from my side I wrote he first
has to prove it for at least a half year that he supports the project
and helps out people. Till now I haven't seen any response to the
technical questions I had.

And telling that the politicians here are so bad to everyone who'd
like to help finding a solution for it is definitelly the wrong way
either, so other people will not even be able to get an insight into
the whole story.

> Manu is an asset and all the personal bickering and immature attitudes
> being displayed do not benefit any projects in any way.  If you can't
> get past your personal problems then step down until you can learn to
> be unbiased and start treating these projects with some sanity/common
> sense.
>
> When you drive good people away, guess who loses?  EVERYONE.
> Grow up and quit letting your personal feelings interfere in places it should
> not be in the first place!!

Since all these issues have been there for more than one year now it
either would be better that he leaves the project OR starts to
seriously discuss the issues and how it would be best to solve them
(and in a way where everyone agrees here)
He just nacks the changes proposed by Uwe which got implemented by
Trent and now Mauro wants to get it done somehow, either in a way
explaining what he wants to do with it in future or changing these few
lines NOW.
I couldn't care less what will happen with his driver, the whole story
gets blown up just because one party here doesn't understand that the
other one doesn't know what he wants to do (and if he seriously will
do something)

>
> I apologize for going off-topic but this is relevant to dvb dev as a
> whole.  Things have degraded to a ridiculous state and it's time to
> knock it off.  Enough is enough.  The dvb projects should NOT have to
> suffer simply because people have lost the decency to act civil
> towards one another!
>
> Lastly, the opinions I'm sharing in this post are held by many others,
> although they hesitate to do the same publicly for certain reasons.
>

I fully agree with that.

Markus

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Mauro Carvalho Chehab wrote:
> > Enough. Let's stop arguing non technical issues.
> >
> > If either one of you have any technical argue against the Trent's
> > patches, please point where the fix is wrong. Otherwise, if you wish,
> > you may send an acked-by agreeing with the fix.
> >
>
> Why don't you stop this childish behaviour ?
>
> After explaining to you the reasons in the previous mail:
> being the author and maintainer of dst/dst_ca and maintainer of
> dvb-bt8xx, i NACK this change
>
> (1) You aren't DVB maintainer

I've seen that too often already, now we could point to a mail someone
sent to Uwe regarding maintainership.

You wouldn't be better at the moment, Mauro at least aknowlidges the
work of others.
I don't know what problems you have with Mauro I heard that there have
been some mails between you and some other developers as well and the
whole situation is just terrible.
If you want to change the whole situation, think about what you can do
for improving the whole situation even if it means that you have to
work with people you don't like.


> (2) one shouldn't make such judgement calls on somebody else's driver
> unless it falls within your own maintainership
>

I wrote what I'd like to see from you, it would be a start if you
could work on that first.

Markus

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Markus Rechberger wrote:
> On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
>> Mauro Carvalho Chehab wrote:
>> > Enough. Let's stop arguing non technical issues.
>> >
>> > If either one of you have any technical argue against the Trent's
>> > patches, please point where the fix is wrong. Otherwise, if you wish,
>> > you may send an acked-by agreeing with the fix.
>> >
>>
>> Why don't you stop this childish behaviour ?
>>
>> After explaining to you the reasons in the previous mail:
>> being the author and maintainer of dst/dst_ca and maintainer of
>> dvb-bt8xx, i NACK this change
>>
>> (1) You aren't DVB maintainer
> 
> I've seen that too often already, now we could point to a mail someone
> sent to Uwe regarding maintainership.


FYI, I have never written to Uwe regarding any sort of maintainership.
You seem to be quite up with an overdose of drugs

>From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from
my side to Uwe, none of which has a topic whatsoever you say. Only the
first mail was a private mail and that is CC'd to Johannes as well.

Firstly you seem to play politics by getting Uwe to flame me, then when
it backfired, you are trying to play tricks with the rest of the
community as well, by spreading nonsense statements.

Great!

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Markus Rechberger wrote:
> > On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> >> Mauro Carvalho Chehab wrote:
> >> > Enough. Let's stop arguing non technical issues.
> >> >
> >> > If either one of you have any technical argue against the Trent's
> >> > patches, please point where the fix is wrong. Otherwise, if you wish,
> >> > you may send an acked-by agreeing with the fix.
> >> >
> >>
> >> Why don't you stop this childish behaviour ?
> >>
> >> After explaining to you the reasons in the previous mail:
> >> being the author and maintainer of dst/dst_ca and maintainer of
> >> dvb-bt8xx, i NACK this change
> >>
> >> (1) You aren't DVB maintainer
> >
> > I've seen that too often already, now we could point to a mail someone
> > sent to Uwe regarding maintainership.
>
>
> FYI, I have never written to Uwe regarding any sort of maintainership.
> You seem to be quite up with an overdose of drugs
>

I mean the mail from Helge Hafting (thread  [linux-dvb] Critical
points about kernel 2.6.21 and pseudo-authorities) at the very first
beginning.

> From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from
> my side to Uwe, none of which has a topic whatsoever you say. Only the
> first mail was a private mail and that is CC'd to Johannes as well.
>
> Firstly you seem to play politics by getting Uwe to flame me, then when
> it backfired, you are trying to play tricks with the rest of the
> community as well, by spreading nonsense statements.
>

I sent several comments to Uwe to stop flaming, Trent was in the CC
sometimes I never wrote that he should flame on anyone.
I can simply forward you all mails I sent to Uwe there's not one bad mail.

My point is moreover to get that issue sorted out by either accepting
his "proposal" or stating out why not to add it (and there must be a
reason behind it, and no mail which is 2 years old, or explaining what
the device is, again it got explained what's required from you)

seems like your response is based on that misunderstood sentence,
sorry for not beeing clear enough.

Markus

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Markus Rechberger wrote:

> I mean the mail from Helge Hafting (thread  [linux-dvb] Critical
> points about kernel 2.6.21 and pseudo-authorities) at the very first
> beginning.
> 

I am replying to this mail, just because someone's spreading lies all
around.
On the mentioned thread, what i wrote (and that was the only mail from
my side):

There is a saying: "He who lives by the sword, dies by the sword."


-------- Original Message --------
Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21	and
pseudo-authorities
Date: Tue, 01 May 2007 04:19:41 +0400
From: Manu Abraham <abraham.manu@gmail.com>
To: Uwe Bugla <uwe.bugla@gmx.de>
CC: xyzzy@speakeasy.org,  linux-dvb@linuxtv.org,
linux-kernel@vger.kernel.org,  torvalds@linux-foundation.org,
akpm@linux-foundation.org,  mkrufky@linuxtv.org
References: <20070429182209.267430@gmx.net>
<alpine.LFD.0.98.0704291147530.9964@woody.linux-foundation.org>
<20070429205925.129920@gmx.net>
<alpine.LFD.0.98.0704291412500.9964@woody.linux-foundation.org>
<20070429230037.95120@gmx.net>	<1177894713.3046.5.camel@p
<alpine.LFD.0.98.0704300854090.9964@woody.linux-foundation.org>
<Pine.LNX.4.58.0704301458460.315@shell2.speakeasy.net>
<463674A9.9040100@gmail.com> <20070430234000.181660@gmx.net>

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 <uwe.bugla@gmx.de>
To: manu@linuxtv.org
CC: js@linuxtv.org

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 <uwe.bugla@gmx.de>
To: js@linuxtv.org
CC: manu@linuxtv.org

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 simply be my problem, not yours!

4 rules for a real good documentation:
1. understandable and transparent information for different understanding
levels
2. strictly corresponding to the laws of the current kernel design
3. absolutely errorfree concerning orthographic junk
4. structured in a senseful manner (f. ex.: headliner corresponds to real
contents)

If an attempt of documentation lacks at least one of the four, it is simply
useless to my opinion. Why aren't debug parameters part of another part of
documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt goes:
"How to get the Nebula, PCTV, and TwinHan DST cards working."
My question: If the essence of a documentation text is how to bring up a
specified card, then please what the hell has that got to do with debug
parameters? Who are the addressed groups of such a text? To my opinion at
least the headliner says that the following text addresses users and nobody
else!
So I simply never intended to bypass any developer, but I simply found out
that the bt8xx-documentation simply did not correspond to the actual kernel
design. In other words: Was unusable. So I decided to write a patch and
simply act instead of performing endless discussions, and that's all about
it!
And: If you reinvent the name of cards: Do it for whatever reason, for god's
sake! But: How the hell do you define to a person not convenient with all
that special technical vocabulary, what the hell a BT8xx-card is? Remember
the first of my 4 rules (see above!). So at least a complete list of cards
conforming to that standard is necessary for transparent information:
Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
clones, Avermedia of all kinds..... Is that list complete? If not, please
drop me a note where I can get that complete list of cards corresponding to
that standard, and I'll instantly sit down and write a patch to improve
documentation.
But before I even think about doing that I appreciate you to do your
homework:
a. readd my name (I didn't delete it, so I won't do the same job again, not
for sync reasons, and not for reasons of lack of time, and not for any other
reason.
b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
in point a.)
c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
d. reflect very well, whether debug parameters should not better be situated
in different documentation texts (logically structured, understandable)

Regards

Uwe Bugla

P. S.: akpm never complains about lack of time, and he is doing a very fair
and good job, and, at least for him, the amount of 54 patches is simply
peanuts. I love cooperation with guys like him!
In other words: I respect the demand that cvs-tree and current kernel must
be in sync somehow, but if the output is rubbish for several reasons and,
moreover, neglects my work, there is simply no reason for any kind of
respect. Because I ain't no idiot, just to say it in very simple words.
So please in future avoid to blame my person for things that you personally
don't get worked (synchronization or whatever kind).
And would you please answer me one question: How can I be shure that my
patchwork at least enters the institution akpm, if there is someone like you
in between complaining for lack of time and synchronization faults? I prefer
flat hierarchies (the real hidden success principle of Linux) and
cooperation with akpm works very fine.
So, as a matter of principle, I don't see any reason why I should prepare
and send in my work three, four, five times, just because at the other end
someone doesn't get his stuff synchronized or lacks time. I ain't no idiot!
Ya Basta!
And even if I would give in now for strategic reasons and do the same
fuckin' work again, how many Stezenbach clones or whoever would come up
afterwards and continue to fuck up my work in the same or just in a
different way you personally did? Who do you think you are and who do you
think I am? So please do your homework, and do it correct in the future, or
leave that job simply to another person. OK?
Any further questions, Mr. Johannes Stezenbach?

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

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 simply be my problem, not yours!

4 rules for a real good documentation:
1. understandable and transparent information for different understanding
levels
2. strictly corresponding to the laws of the current kernel design
3. absolutely errorfree concerning orthographic junk
4. structured in a senseful manner (f. ex.: headliner corresponds to real
contents)

If an attempt of documentation lacks at least one of the four, it is simply
useless to my opinion. Why aren't debug parameters part of another part of
documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt goes:
"How to get the Nebula, PCTV, and TwinHan DST cards working."
My question: If the essence of a documentation text is how to bring up a
specified card, then please what the hell has that got to do with debug
parameters? Who are the addressed groups of such a text? To my opinion at
least the headliner says that the following text addresses users and nobody
else!
So I simply never intended to bypass any developer, but I simply found out
that the bt8xx-documentation simply did not correspond to the actual kernel
design. In other words: Was unusable. So I decided to write a patch and
simply act instead of performing endless discussions, and that's all about
it!
And: If you reinvent the name of cards: Do it for whatever reason, for god's
sake! But: How the hell do you define to a person not convenient with all
that special technical vocabulary, what the hell a BT8xx-card is? Remember
the first of my 4 rules (see above!). So at least a complete list of cards
conforming to that standard is necessary for transparent information:
Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
clones, Avermedia of all kinds..... Is that list complete? If not, please
drop me a note where I can get that complete list of cards corresponding to
that standard, and I'll instantly sit down and write a patch to improve
documentation.
But before I even think about doing that I appreciate you to do your
homework:
a. readd my name (I didn't delete it, so I won't do the same job again, not
for sync reasons, and not for reasons of lack of time, and not for any other
reason.
b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
in point a.)
c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
d. reflect very well, whether debug parameters should not better be situated
in different documentation texts (logically structured, understandable)

Regards

Uwe Bugla

P. S.: akpm never complains about lack of time, and he is doing a very fair
and good job, and, at least for him, the amount of 54 patches is simply
peanuts. I love cooperation with guys like him!
In other words: I respect the demand that cvs-tree and current kernel must
be in sync somehow, but if the output is rubbish for several reasons and,
moreover, neglects my work, there is simply no reason for any kind of
respect. Because I ain't no idiot, just to say it in very simple words.
So please in future avoid to blame my person for things that you personally
don't get worked (synchronization or whatever kind).
And would you please answer me one question: How can I be shure that my
patchwork at least enters the institution akpm, if there is someone like you
in between complaining for lack of time and synchronization faults? I prefer
flat hierarchies (the real hidden success principle of Linux) and
cooperation with akpm works very fine.
So, as a matter of principle, I don't see any reason why I should prepare
and send in my work three, four, five times, just because at the other end
someone doesn't get his stuff synchronized or lacks time. I ain't no idiot!
Ya Basta!
And even if I would give in now for strategic reasons and do the same
fuckin' work again, how many Stezenbach clones or whoever would come up
afterwards and continue to fuck up my work in the same or just in a
different way you personally did? Who do you think you are and who do you
think I am? So please do your homework, and do it correct in the future, or
leave that job simply to another person. OK?
Any further questions, Mr. Johannes Stezenbach?

-- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Markus Rechberger]

On 5/4/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Markus Rechberger wrote:
>
> > I mean the mail from Helge Hafting (thread  [linux-dvb] Critical
> > points about kernel 2.6.21 and pseudo-authorities) at the very first
> > beginning.
> >
>
> I am replying to this mail, just because someone's spreading lies all
> around.
> On the mentioned thread, what i wrote (and that was the only mail from
> my side):
>
> There is a saying: "He who lives by the sword, dies by the sword."
>

And what issues are outstanding of these discussions? I went over it
and it just shows up that there have been communication problems in
2005.

We now have open issues with several device drivers and that's what we
should focus at.

Markus

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Fri, 4 May 2007 00:06:51 +0200
Von: "Markus Rechberger" <mrechberger@gmail.com>
An: "Manu Abraham" <abraham.manu@gmail.com>
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points about ...)

> On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> > Markus Rechberger wrote:
> > > On 5/3/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> > >> Mauro Carvalho Chehab wrote:
> > >> > Enough. Let's stop arguing non technical issues.
> > >> >
> > >> > If either one of you have any technical argue against the Trent's
> > >> > patches, please point where the fix is wrong. Otherwise, if you
> wish,
> > >> > you may send an acked-by agreeing with the fix.
> > >> >
> > >>
> > >> Why don't you stop this childish behaviour ?
> > >>
> > >> After explaining to you the reasons in the previous mail:
> > >> being the author and maintainer of dst/dst_ca and maintainer of
> > >> dvb-bt8xx, i NACK this change
> > >>
> > >> (1) You aren't DVB maintainer
> > >
> > > I've seen that too often already, now we could point to a mail someone
> > > sent to Uwe regarding maintainership.
> >
> >
> > FYI, I have never written to Uwe regarding any sort of maintainership.
> > You seem to be quite up with an overdose of drugs
> >
> 
> I mean the mail from Helge Hafting (thread  [linux-dvb] Critical
> points about kernel 2.6.21 and pseudo-authorities) at the very first
> beginning.
> 
> > From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from
> > my side to Uwe, none of which has a topic whatsoever you say. Only the
> > first mail was a private mail and that is CC'd to Johannes as well.
> >
> > Firstly you seem to play politics by getting Uwe to flame me, then when
> > it backfired, you are trying to play tricks with the rest of the
> > community as well, by spreading nonsense statements.
> >
> 
> I sent several comments to Uwe to stop flaming, Trent was in the CC
> sometimes I never wrote that he should flame on anyone.
> I can simply forward you all mails I sent to Uwe there's not one bad mail.
> 
> My point is moreover to get that issue sorted out by either accepting
> his "proposal" or stating out why not to add it (and there must be a
> reason behind it, and no mail which is 2 years old, or explaining what
> the device is, again it got explained what's required from you)
> 
> seems like your response is based on that misunderstood sentence,
> sorry for not beeing clear enough.
> 
> Markus

Hi Markus, fine chap,
Please cool down...

I guess I understood Manu's response:

a. He just changed his priorities to pick up an old project that seemed to have died, but did not die at all - this project is called cx878 project, and it is the most radical approach that I ever have seen - trying to make all BT8xx drivers independent from bttv, which is not horrible, but only consequent, necessary, and good and fine.
Please see my previous mails on that issue.

Just read the ML to get the appropriate link and please get yourself in it to help developping it. I swear it is the right path, although I am still missing the avoidance of dvb-pll.c. A closer look into that module will quite easily tell you
that there aren't any BT8xx based PCI cards needing that module except the ones needing the lgdt330x frontend driver, which is maintained by Mike Krufky. So for all other cards treated by the dvb-bt8xx backend this module is nothing but heavily obsolete and nonsense, if not to say: RAM-Wasting.

b. In so far, Manu's statements do not base on any mail that is 2 years old, but he simply changed his mind, after it was necessarily me personally to build up "the golden bridge" for him, Mike and others as well.

c. I am deeply thankful for your diplomatic behaviour involving Trent, as this brought up Manu to react in the end instead of crawling back into his snail house.

d. But please let us establish peace among each other now, because without peace we will not be able to continue the whole thing...

Hi Trent,
I want to thank you for all your efforts - as they at least work for my deep satisfaction, but they may not work for other people as well for simply technical reasons (example: treating dst and dst_ca as one simple case does no good at all, does it?), but our primadonna Manuel Abraham simply follows another far more radical path - to get the whole thing independent from bttv, which is the RIGHT path.

Your invested energies weren't wasted at all, but they only approach "plan a" while "plan b" goes much more further than "plan a." It is as simple as that.

And, as I stated already, I am open for both plans - and if the more radical one gains more mercy I will not disagree, but simply follow it and trying my best to improve it.

Hi Mauro,

I would deeply appreciate you to pull my "proposal" for the Kconfig in the frontends section as at least the semantic problem gotta be resolved (SPO instead of SO - whoever wrote this). The question what card needs dvb-pll.c does not stay open so far - I just involved some fact about what card does really need it and what card simply never did.

However, also in "plan a" as in "plan b" the dvb-pll.c dependency issue stays open and I would deeply appreciate Mike Krufky to prepare a fix for us all.
It cannot be sufficient at all to be forced to compile a dvb-pll.c module for the whole group of bt8xx PCI cards if there is only one card that needs it being maintained by Mike, can it?

Again I state: The only bt8xx PCI based card that needs it is the one using the lgdt330x frontend driver - for all other cards of the BT8xx PCI kind that module is simply completely obsolete, if not to say: RAM-wasting nonsense.

And please stop to kill my deeply correct criticism with words like: "99 % of all cards need this module" or something like that, like you did in the past.
And please stop to kill my invested energies with sentences like "Again I say, please do not pull Uwe's patches at all, as he is only regarding things through his personal prisma."
Above from the fact that this is not really true it simply hurts and brings down all my invested energies for no acceptable reason.
In so far, you are NOT a neutral maintainer, like Markus stated, but you simply act playing unreasonable politics on me without knowing what you do.

Just be a little bit more open for the exception handling, even if you do not like to be. What I say is FACT, so please do not simply ignore the facts.

And after all I deeply respect that you are trying to be utmost restrictive as far as kernel oopses and regressions are concerned - I guess you're really doing fine as a team leader, although you are NOT neutral at least sometimes.

Hi Manuel,

I would deeply wish you to avoid the following words:
a. rant
b. childish behaviour
c. You aren't DVB maintainer
d. You seem to be quite up with an overdose of drugs

and other words like that.

Just to give you a very humble help:
Although Johannes stated that you were nothing but nerving when you were beginning this whole thing he himself tried to be always warm and encouraging to you.
So where is the reason in you personally that you cannot give back that positive behaviour please?

BTW:
I am really working hard on that cx878 project after the mercurial tree has been proven to work fine, and I hope that I can bring out some test report in order to make its development continue...

Yours sincerely

Uwe

> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[hermann pitton]

Am Freitag, den 04.05.2007, 02:31 +0400 schrieb Manu Abraham:
> Markus Rechberger wrote:
> 
> > I mean the mail from Helge Hafting (thread  [linux-dvb] Critical
> > points about kernel 2.6.21 and pseudo-authorities) at the very first
> > beginning.
> > 
> 
> I am replying to this mail, just because someone's spreading lies all
> around.
> On the mentioned thread, what i wrote (and that was the only mail from
> my side):
> 
> There is a saying: "He who lives by the sword, dies by the sword."
> 

Within the last six years there was in the end exactly one, never asked
for, private mail with worst *bullshit* about another person, Mauro in
this case.

It came from you, out of any feasible arguments for me anymore.

I'm stupid, but not stupid enough to allow such stuff coming in rule.

But I still say you have been first and are waiting longest to get your
work in, please try again to get your ACKs and rant about not enough
replies.

Cheers,
Hermann

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Fri, 04 May 2007 02:31:49 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: linux-dvb@linuxtv.org
CC: linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points about ...)

> Markus Rechberger wrote:
> 
> > I mean the mail from Helge Hafting (thread  [linux-dvb] Critical
> > points about kernel 2.6.21 and pseudo-authorities) at the very first
> > beginning.
> > 
> 
> I am replying to this mail, just because someone's spreading lies all
> around.
> On the mentioned thread, what i wrote (and that was the only mail from
> my side):
> 
> There is a saying: "He who lives by the sword, dies by the sword."

Hi Manu,

The saying that you stated is a very christian one.
I perhaps should state that I am 47 years old now, raised in in utmost reactionary region called Bavaria (Western Germany), and also raised by parents of Russian / Polonian origin who shared the Nazi regime with the usual "I-do-not-want-to-talk-about-it-and-I-do-not-want-to-feel-responsible-about-it                                                                                                                                                                                                                                              "-behaviour.
And I am very much not only interested in german post-war history, but I simply love to write provocative letters or mails to make my conviction utmost clear that all this capitalist bullshit around us should vanish and shrink and be overcome some day.

Basic christian ideals are very close to basic marxist ideas.
The one who never does perceive that is a real poor human being in my eyes, if not to say: a complete idiot or a system-conforming hypocrite.

BUT:
I in fact do not read this "saying" for the first time:

In my personal experience (feel very sorry about it, but it's true) it has always truthfully been an excuse for persons being strongly limited on what I would call utmost primitive instincts like greed or rapacity (i. e. the utmost perfect sounding "would-like-to-capitalists", if not to say: the perfect slaves or: the perfect counterrevolutionaries or strike-breakers, if not to say: the utmost perfect asscreepers).

Please forgive me for that statement, but I am simply stating my personal experiences very truthfully, without playing any politics, but just telling you my "personal truth" or the sum of all my personal life experience unfortunately bound to that.

And if there is discussion needed on that we should do it private or anyway on some other thread, but definitely not on this one.

Hints to help you to understand the difference:

1. There is a GPL license written by Richard Stallman whose origin I do not know:
Its essence is the philosophy to share and to be highly transparent as far as information level is concerned.

2. There is a saying by Linus in which he states the best choice he ever did was conforming his work to the terms of Richard Stallman, the GPL.

3. Wikipedia says that Linus's father was no christian at all, but simply a communist.

See, Manu, there are deeply primitive instinct-driven hypocrites around like hell, but there are also truthful human beings around.

But:
The Internet does not provide a platform to find out who is who and what is what.
The Internet may be necessary, but in the end it's just a drag, isn't it?

Sincerely
Uwe
> 
> 
> -------- Original Message --------
> Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21	and
> pseudo-authorities
> Date: Tue, 01 May 2007 04:19:41 +0400
> From: Manu Abraham <abraham.manu@gmail.com>
> To: Uwe Bugla <uwe.bugla@gmx.de>
> CC: xyzzy@speakeasy.org,  linux-dvb@linuxtv.org,
> linux-kernel@vger.kernel.org,  torvalds@linux-foundation.org,
> akpm@linux-foundation.org,  mkrufky@linuxtv.org
> References: <20070429182209.267430@gmx.net>
> <alpine.LFD.0.98.0704291147530.9964@woody.linux-foundation.org>
> <20070429205925.129920@gmx.net>
> <alpine.LFD.0.98.0704291412500.9964@woody.linux-foundation.org>
> <20070429230037.95120@gmx.net>	<1177894713.3046.5.camel@p
> <alpine.LFD.0.98.0704300854090.9964@woody.linux-foundation.org>
> <Pine.LNX.4.58.0704301458460.315@shell2.speakeasy.net>
> <463674A9.9040100@gmail.com> <20070430234000.181660@gmx.net>
> 
> 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 <uwe.bugla@gmx.de>
> To: manu@linuxtv.org
> CC: js@linuxtv.org
> 
> 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 <uwe.bugla@gmx.de>
> To: js@linuxtv.org
> CC: manu@linuxtv.org
> 
> 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 simply be my problem, not yours!
> 
> 4 rules for a real good documentation:
> 1. understandable and transparent information for different understanding
> levels
> 2. strictly corresponding to the laws of the current kernel design
> 3. absolutely errorfree concerning orthographic junk
> 4. structured in a senseful manner (f. ex.: headliner corresponds to real
> contents)
> 
> If an attempt of documentation lacks at least one of the four, it is
> simply
> useless to my opinion. Why aren't debug parameters part of another part of
> documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt
> goes:
> "How to get the Nebula, PCTV, and TwinHan DST cards working."
> My question: If the essence of a documentation text is how to bring up a
> specified card, then please what the hell has that got to do with debug
> parameters? Who are the addressed groups of such a text? To my opinion at
> least the headliner says that the following text addresses users and
> nobody
> else!
> So I simply never intended to bypass any developer, but I simply found out
> that the bt8xx-documentation simply did not correspond to the actual
> kernel
> design. In other words: Was unusable. So I decided to write a patch and
> simply act instead of performing endless discussions, and that's all about
> it!
> And: If you reinvent the name of cards: Do it for whatever reason, for
> god's
> sake! But: How the hell do you define to a person not convenient with all
> that special technical vocabulary, what the hell a BT8xx-card is? Remember
> the first of my 4 rules (see above!). So at least a complete list of cards
> conforming to that standard is necessary for transparent information:
> Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
> clones, Avermedia of all kinds..... Is that list complete? If not, please
> drop me a note where I can get that complete list of cards corresponding
> to
> that standard, and I'll instantly sit down and write a patch to improve
> documentation.
> But before I even think about doing that I appreciate you to do your
> homework:
> a. readd my name (I didn't delete it, so I won't do the same job again,
> not
> for sync reasons, and not for reasons of lack of time, and not for any
> other
> reason.
> b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
> in point a.)
> c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
> d. reflect very well, whether debug parameters should not better be
> situated
> in different documentation texts (logically structured, understandable)
> 
> Regards
> 
> Uwe Bugla
> 
> P. S.: akpm never complains about lack of time, and he is doing a very
> fair
> and good job, and, at least for him, the amount of 54 patches is simply
> peanuts. I love cooperation with guys like him!
> In other words: I respect the demand that cvs-tree and current kernel must
> be in sync somehow, but if the output is rubbish for several reasons and,
> moreover, neglects my work, there is simply no reason for any kind of
> respect. Because I ain't no idiot, just to say it in very simple words.
> So please in future avoid to blame my person for things that you
> personally
> don't get worked (synchronization or whatever kind).
> And would you please answer me one question: How can I be shure that my
> patchwork at least enters the institution akpm, if there is someone like
> you
> in between complaining for lack of time and synchronization faults? I
> prefer
> flat hierarchies (the real hidden success principle of Linux) and
> cooperation with akpm works very fine.
> So, as a matter of principle, I don't see any reason why I should prepare
> and send in my work three, four, five times, just because at the other end
> someone doesn't get his stuff synchronized or lacks time. I ain't no
> idiot!
> Ya Basta!
> And even if I would give in now for strategic reasons and do the same
> fuckin' work again, how many Stezenbach clones or whoever would come up
> afterwards and continue to fuck up my work in the same or just in a
> different way you personally did? Who do you think you are and who do you
> think I am? So please do your homework, and do it correct in the future,
> or
> leave that job simply to another person. OK?
> Any further questions, Mr. Johannes Stezenbach?
> 
> -- 
> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
> 
> 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 simply be my problem, not yours!
> 
> 4 rules for a real good documentation:
> 1. understandable and transparent information for different understanding
> levels
> 2. strictly corresponding to the laws of the current kernel design
> 3. absolutely errorfree concerning orthographic junk
> 4. structured in a senseful manner (f. ex.: headliner corresponds to real
> contents)
> 
> If an attempt of documentation lacks at least one of the four, it is
> simply
> useless to my opinion. Why aren't debug parameters part of another part of
> documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt
> goes:
> "How to get the Nebula, PCTV, and TwinHan DST cards working."
> My question: If the essence of a documentation text is how to bring up a
> specified card, then please what the hell has that got to do with debug
> parameters? Who are the addressed groups of such a text? To my opinion at
> least the headliner says that the following text addresses users and
> nobody
> else!
> So I simply never intended to bypass any developer, but I simply found out
> that the bt8xx-documentation simply did not correspond to the actual
> kernel
> design. In other words: Was unusable. So I decided to write a patch and
> simply act instead of performing endless discussions, and that's all about
> it!
> And: If you reinvent the name of cards: Do it for whatever reason, for
> god's
> sake! But: How the hell do you define to a person not convenient with all
> that special technical vocabulary, what the hell a BT8xx-card is? Remember
> the first of my 4 rules (see above!). So at least a complete list of cards
> conforming to that standard is necessary for transparent information:
> Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
> clones, Avermedia of all kinds..... Is that list complete? If not, please
> drop me a note where I can get that complete list of cards corresponding
> to
> that standard, and I'll instantly sit down and write a patch to improve
> documentation.
> But before I even think about doing that I appreciate you to do your
> homework:
> a. readd my name (I didn't delete it, so I won't do the same job again,
> not
> for sync reasons, and not for reasons of lack of time, and not for any
> other
> reason.
> b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
> in point a.)
> c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
> d. reflect very well, whether debug parameters should not better be
> situated
> in different documentation texts (logically structured, understandable)
> 
> Regards
> 
> Uwe Bugla
> 
> P. S.: akpm never complains about lack of time, and he is doing a very
> fair
> and good job, and, at least for him, the amount of 54 patches is simply
> peanuts. I love cooperation with guys like him!
> In other words: I respect the demand that cvs-tree and current kernel must
> be in sync somehow, but if the output is rubbish for several reasons and,
> moreover, neglects my work, there is simply no reason for any kind of
> respect. Because I ain't no idiot, just to say it in very simple words.
> So please in future avoid to blame my person for things that you
> personally
> don't get worked (synchronization or whatever kind).
> And would you please answer me one question: How can I be shure that my
> patchwork at least enters the institution akpm, if there is someone like
> you
> in between complaining for lack of time and synchronization faults? I
> prefer
> flat hierarchies (the real hidden success principle of Linux) and
> cooperation with akpm works very fine.
> So, as a matter of principle, I don't see any reason why I should prepare
> and send in my work three, four, five times, just because at the other end
> someone doesn't get his stuff synchronized or lacks time. I ain't no
> idiot!
> Ya Basta!
> And even if I would give in now for strategic reasons and do the same
> fuckin' work again, how many Stezenbach clones or whoever would come up
> afterwards and continue to fuck up my work in the same or just in a
> different way you personally did? Who do you think you are and who do you
> think I am? So please do your homework, and do it correct in the future,
> or
> leave that job simply to another person. OK?
> Any further questions, Mr. Johannes Stezenbach?
> 
> -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2597 bytes --]

On Thu, 3 May 2007, Mauro Carvalho Chehab wrote:
> Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu:
> > I promise, this time it's right!
> > http://linuxtv.org/hg/~tap/dst-new
>
> Confirmed. Now the patch is properly working. My tests were done with a
> board with DST. Those are the results:
>
> 1) when DST is unselected, on a board with DST, it will print the errors
> indicating that the Kconfig items were not selected:
>
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800
>
> The only issue is the wrong printk msg, stating that a "frontend driver"
> were not found. As this issue also happens with the current driver, due
> the usage of dvb_attach() macro, I don't see any regressions.
>
> It would be nice, however, to have a patch making dvb_attach more
> generic, by e.g. having a variant that allows passing another message.

Only this message is from dvb_attach():
> DVB: Unable to find symbol dst_attach()

Is it saying that it cannot load the module that dst_attach() is in (it
doesn't know what module that is, modprobe knows that).  If you enabled dst
support and deleted the module, it would be the same.

If you turn off dvb_attach() and also disable dst, you should instead get
this message:
dst_attach: driver disabled by Kconfig

Maybe that would look nicer with a "DVB:  " prefix?  That would easier if it
wasn't necessary to update the printk in each boilerplate stub function.  What
if one macro created these stubs....

> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800

These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
It would be trivial to change of course, but I'm not sure what would be
pedantically correct for both dst and non-dst based hardware.

> There's an argument against the prototype changes on dst_attach and
> dst_ca_attach since they aren't frontend.

The reason I changed that, is the dst_attach() already did return a
dvb_frontend pointer, it was just inside an enclosing structure.  i.e. what
existed before:

{
	struct dst_state *state;
	state = dst_attach(...);
	card->fe = &state->frontend;
} /* state goes out of scope */

The frontend is inside the state struct and the state pointer isn't saved
anywhere.  dvb-bt8xx just saves a frontend pointer from inside the dst state
and tosses the state pointer away.  So I changed that to:

	card->fe = dst_attach(...);

Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

[Mauro Carvalho Chehab]

> > It would be nice, however, to have a patch making dvb_attach more
> > generic, by e.g. having a variant that allows passing another message.
> 
> Only this message is from dvb_attach():
> > DVB: Unable to find symbol dst_attach()
> 
> Is it saying that it cannot load the module that dst_attach() is in (it
> doesn't know what module that is, modprobe knows that).  If you enabled dst
> support and deleted the module, it would be the same.
> 
> If you turn off dvb_attach() and also disable dst, you should instead get
> this message:
> dst_attach: driver disabled by Kconfig
> 
> Maybe that would look nicer with a "DVB:  " prefix?  That would easier if it
> wasn't necessary to update the printk in each boilerplate stub function.  What
> if one macro created these stubs....
> 
> > frontend_init: Could not find a Twinhan DST.
> > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800
> 
> These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
> It would be trivial to change of course, but I'm not sure what would be
> pedantically correct for both dst and non-dst based hardware.

Sorry, this is what I meant: to fix the above message. The dvb_attach is
generic enough.

Maybe a more nice text would be something like:
	"Couldn't initialize frontend helper modules for device ..."

since dvb_attach will also print what modules were not loaded.
> 
> > There's an argument against the prototype changes on dst_attach and
> > dst_ca_attach since they aren't frontend.
> 
> The reason I changed that, is the dst_attach() already did return a
> dvb_frontend pointer, it was just inside an enclosing structure.  i.e. what
> existed before:
> 
> {
> 	struct dst_state *state;
> 	state = dst_attach(...);
> 	card->fe = &state->frontend;
> } /* state goes out of scope */
> 
> The frontend is inside the state struct and the state pointer isn't saved
> anywhere.  dvb-bt8xx just saves a frontend pointer from inside the dst state
> and tosses the state pointer away.  So I changed that to:
> 
> 	card->fe = dst_attach(...);

IMO, this made the code cleaner.

-- 
Cheers,
Mauro

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Mauro Carvalho Chehab]

Hi Manu,

Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:
> > Enough. Let's stop arguing non technical issues.
> > 
> > If either one of you have any technical argue against the Trent's
> > patches, please point where the fix is wrong. Otherwise, if you wish,
> > you may send an acked-by agreeing with the fix.
> > 
> 
> Why don't you stop this childish behaviour ?

I just want to solve the current issue, and decide the proper way for Trent's fixes. 

I consider you a very skilled programmer. Unfortunately, it seems that
you're not interested anymore on submitting kernel patches, since your
last contribution, as an author, were back on Aug, 8, 2006:

        commit bbdd11fa957913d6648cabbca59be1da479180ed
        Author: Manu Abraham <abraham.manu@gmail.com>
        Date:   Tue Aug 8 15:48:08 2006 -0300

            V4L/DVB (4432): Fix Circular dependencies

            Signed-off-by: Manu Abraham <manu@linuxtv.org>
            Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> 

It would be a pleasure to have you contributing again. However, we need to fix the pointed issues.

Also, considering that:

1) the Trent patches addressing the issues exists since august, 2006;

2) nobody pointed any troubles at the current approach;

3) the patch does provide a proper fix for module removal, working well on both hardwares with and without DST;

4) I'm responsible for reviewing and forwarding patches for /drivers/media stuff;

I think there's no reason for me to not forward the proper fixes to mainstream.

-- 
Cheers,
Mauro

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Hello Mauro,

Mauro Carvalho Chehab wrote:
> Hi Manu,
> 
> Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
>>> Enough. Let's stop arguing non technical issues.
>>>
>>> If either one of you have any technical argue against the Trent's
>>> patches, please point where the fix is wrong. Otherwise, if you wish,
>>> you may send an acked-by agreeing with the fix.
>>>
>> Why don't you stop this childish behaviour ?
> 
> I just want to solve the current issue, and decide the proper way for Trent's fixes. 
> 
> I consider you a very skilled programmer. Unfortunately, it seems that
> you're not interested anymore on submitting kernel patches, since your
> last contribution, as an author, were back on Aug, 8, 2006:

hmm .. multiple Caps "I 's" ..  anyway.

>From my side, quite some time has been put forward to write that mail.
Inspite of that if you feel that you do have to go your own way, then it
is completely upto you. I would say: do as you feel in such a case.

In such a case are you willing to fix all the issues/requests that surface ?

Really do you want me to explain those issues in this thread ? I would
say, think over it yourself, why that huge gap occurred. Take some time
off all this, think on a cool mind.


> 
>         commit bbdd11fa957913d6648cabbca59be1da479180ed
>         Author: Manu Abraham <abraham.manu@gmail.com>
>         Date:   Tue Aug 8 15:48:08 2006 -0300
> 
>             V4L/DVB (4432): Fix Circular dependencies
> 
>             Signed-off-by: Manu Abraham <manu@linuxtv.org>
>             Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> 
> 
> It would be a pleasure to have you contributing again. However, we need to fix the pointed issues.


I do have a written another mail with regards to the issues that do
prevail on the "discussions thread"


> 
> Also, considering that:
> 
> 1) the Trent patches addressing the issues exists since august, 2006;
> 
> 2) nobody pointed any troubles at the current approach;
> 

Surely there was a long mail from my side. I don't know whether you
missed that mail, but surely you should read it again.


> 3) the patch does provide a proper fix for module removal, working well on both hardwares with and without DST;
>

Other than what i wrote earlier:

DST is not for just one device alone (It is really a combo driver),
AFAICS there are ~15 -20 main devices, for which there are additional 5
- 6 clone manufacturers. So eventually there are around 80 different
cards at least.

So, in fact there are a large number of cards that do exist rather than
the one card that i have sent you, some time back.

The non dst cards supported by dvb-bt8xx are just 3 or 4 cards, IIRC.


> 4) I'm responsible for reviewing and forwarding patches for /drivers/media stuff;
> 
> I think there's no reason for me to not forward the proper fixes to mainstream.
> 

>From what i know, you do need an ACK from the relevant maintainer too.
Did the concept of dvb-maintainers change without any of the DVB
developers knowing ?

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Mauro Carvalho Chehab]

Hi Manu,

> From my side, quite some time has been put forward to write that mail.
> Inspite of that if you feel that you do have to go your own way, then
> it is completely upto you. I would say: do as you feel in such a case.

The point is that those issues are pending for a long time, and they
should be solved, especially the module removal issue (*)

If you are so afraid about applying those changes, maybe the better is
to apply those patches at v4l-dvb tree and at -mm, asking people to
test.

We may hold their commit on kernel mainstream until the next kernel
release, if nobody complains about, or otherwise revert the changes, if
they proofed to cause troubles at dst and/or dvb-bt8xx.

Also, you (or others) may write another approach keeping the fixes with
an strategy more adequate for dst.

Do you agree with this way?

-- 
Cheers,
Mauro

(*) Currently, dst can be removed only with "rmmod -f", due to a wrong
usage count. With Trent's patches, this were fixed.

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Mauro Carvalho Chehab wrote:
> Hi Manu,
> 
>> From my side, quite some time has been put forward to write that mail.
>> Inspite of that if you feel that you do have to go your own way, then
>> it is completely upto you. I would say: do as you feel in such a case.
> 
> The point is that those issues are pending for a long time, and they
> should be solved, especially the module removal issue (*)
> 
> If you are so afraid about applying those changes, maybe the better is
> to apply those patches at v4l-dvb tree and at -mm, asking people to
> test.
> 
> We may hold their commit on kernel mainstream until the next kernel
> release, if nobody complains about, or otherwise revert the changes, if
> they proofed to cause troubles at dst and/or dvb-bt8xx.
> 
> Also, you (or others) may write another approach keeping the fixes with
> an strategy more adequate for dst.
> 
> Do you agree with this way?

NACK

> 
> -- 
> Cheers,
> Mauro
> 
> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
> usage count. With Trent's patches, this were fixed.

http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Michael Krufky]

Manu Abraham wrote:
> Mauro Carvalho Chehab wrote:
>> Hi Manu,
>>
>>> From my side, quite some time has been put forward to write that mail.
>>> Inspite of that if you feel that you do have to go your own way, then
>>> it is completely upto you. I would say: do as you feel in such a case.
>> The point is that those issues are pending for a long time, and they
>> should be solved, especially the module removal issue (*)
>>
>> If you are so afraid about applying those changes, maybe the better is
>> to apply those patches at v4l-dvb tree and at -mm, asking people to
>> test.
>>
>> We may hold their commit on kernel mainstream until the next kernel
>> release, if nobody complains about, or otherwise revert the changes, if
>> they proofed to cause troubles at dst and/or dvb-bt8xx.
>>
>> Also, you (or others) may write another approach keeping the fixes with
>> an strategy more adequate for dst.
>>
>> Do you agree with this way?
> 
> NACK
> 
>> -- 
>> Cheers,
>> Mauro
>>
>> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
>> usage count. With Trent's patches, this were fixed.
> 
> http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx

Just to make things clear, Manu, Are you telling us that the patch in the above
link addresses the use count bug?

If that is the case, are you suggesting that that patch be applied to the
repository instead of Trent's changesets?

Moreso, if that is the case, then the patch in the above link lacks a
sign-off...  We need to apply SOMETHING to fix this problem, and you know the
rules...

What should be done to fix the use count bug?

Regards,

Michael Krufky

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Michael Krufky wrote:
> Manu Abraham wrote:
>> Mauro Carvalho Chehab wrote:
>>> Hi Manu,
>>>
>>>> From my side, quite some time has been put forward to write that mail.
>>>> Inspite of that if you feel that you do have to go your own way, then
>>>> it is completely upto you. I would say: do as you feel in such a case.
>>> The point is that those issues are pending for a long time, and they
>>> should be solved, especially the module removal issue (*)
>>>
>>> If you are so afraid about applying those changes, maybe the better is
>>> to apply those patches at v4l-dvb tree and at -mm, asking people to
>>> test.
>>>
>>> We may hold their commit on kernel mainstream until the next kernel
>>> release, if nobody complains about, or otherwise revert the changes, if
>>> they proofed to cause troubles at dst and/or dvb-bt8xx.
>>>
>>> Also, you (or others) may write another approach keeping the fixes with
>>> an strategy more adequate for dst.
>>>
>>> Do you agree with this way?
>> NACK
>>
>>> -- 
>>> Cheers,
>>> Mauro
>>>
>>> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
>>> usage count. With Trent's patches, this were fixed.
>> http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx
> 
> Just to make things clear, Manu, Are you telling us that the patch in the above
> link addresses the use count bug?
>

Yes

> If that is the case, are you suggesting that that patch be applied to the
> repository instead of Trent's changesets?
> 

Yes

> Moreso, if that is the case, then the patch in the above link lacks a
> sign-off...  We need to apply SOMETHING to fix this problem, and you know the
> rules...
> 

Signed-off-by: Manu Abraham <manu@linuxtv.org>

> What should be done to fix the use count bug?
> 

It does fix, AFAIR

Regards,
Manu

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 07 May 2007 17:54:29 -0300
Von: Mauro Carvalho Chehab <mchehab@infradead.org>
An: Manu Abraham <abraham.manu@gmail.com>
CC: linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical	points about ...)

> Hi Manu,
> 
> > From my side, quite some time has been put forward to write that mail.
> > Inspite of that if you feel that you do have to go your own way, then
> > it is completely upto you. I would say: do as you feel in such a case.
> 
> The point is that those issues are pending for a long time, and they
> should be solved, especially the module removal issue (*)
> 
> If you are so afraid about applying those changes, maybe the better is
> to apply those patches at v4l-dvb tree and at -mm, asking people to
> test.
> 
> We may hold their commit on kernel mainstream until the next kernel
> release, if nobody complains about, or otherwise revert the changes, if
> they proofed to cause troubles at dst and/or dvb-bt8xx.
> 
> Also, you (or others) may write another approach keeping the fixes with
> an strategy more adequate for dst.
> 
> Do you agree with this way?
> 
> -- 
> Cheers,
> Mauro
> 
> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
> usage count. With Trent's patches, this were fixed.

Mauro,
First of all, Manu is not a machine shitting out solutions on other one's pressure.
And he is doing right so far, as far as what happened.

Second: You should do some self-reflection on the damage you did on the human layer.
You appear like not even having any intention or idea on how to do that, you just behave technocratic and cold, you are just doing "I-AM-THE-BOSS, AND-NOTHING-GOES-WITHOUT-ME"-politics, that's all. 

Even if you do not have at least partially any idea about it all, you just try to rule "godlike", you know. Not everybody agrees with that ruling style, just a hint for you that you do not ever want to see, because you prefer to be blind in order to rule, to move on to the daily dayplan, as if nothing happened. But there happened many things. But you just prefer to be blind.

Currently me and Manu are working on a long lasting project very harmonizing, which I never believed to be possible at all, but we do work together :-).

And as long as the the ruler behaviour and the ruling structure of linuxtv.org keeps on behaving like this (including all the nasty people like mrechberger for instance), then let me tell you that I care a shit about what is being pulled into the kernel and what is not, man!

Now if you cannot take that I feel sorry, but he whole system around here gotta be changed as far as maintainership is concerned.

You cannot go on like this, Mr. Chehab, and even if you keep on ignoring this message you will be producing nothing but damage in the end.

Noone was born to act and behave like a nodding nigger in front of you - and if you do not want to take that, well, then you're strictly obsolete, man!

Without any politeness

Uwe
> 
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Trent Piepho]

On Wed, 2 May 2007, Manu Abraham wrote:
> > I've been aware of the problem with dst not fully using the dvb customization
> > systems(*) for a long time.  It came up when dvb_attach() et al were first
> > being integrated, well before any rejected patches or strongly worded emails
> > or whatever from certain people that I'm aware of.
> >
>
> Well, your understanding of the device is quite limited and hence your
> comments and patches.

Manu, have you actually looked at the patch?  It seems like you are just
rejecting everything that has anything to do with dst out of hand.

Can you point to any line of code there, and say what it breaks or what it
will make impossible?

> These features are not the characteristics of a DVB Frontend. Here there
> is a DVB frontend like the normal ones which is hidden behind another
> pseudo bridge (So you don't have *any* access to the frontend at large)

Again, did you actually look at the patch?  I never so much as used the
word frontend to describe the dst.  I didn't change the operation of the
dst in any way.  I didn't move it to a new place in the framework.

The bt8xx driver talks to the dst module via the dvb_frontend object, my
patch has nothing to do with this.  It is a simple patch for simple
programming issues and nothing to do with these larger issues you bring up.

> I would think that it would be *extremely* rude for a person to send in
> patches for a device that which you don't understand at all, when it is
> for limiting the capability of the said device

Is the problem that there is a bug in my patch?  Or is your problem that I
was rude in submitting any patch at all that had anything to do with your
code?  Do you feel that this part of the Linux kernel is owned by you, and
that no one else should be permitted to have anything to do with it?

> > (*) There are two customization/dependency control systems in DVB.  One is
> > dvb_attach(), the other is DVB_FE_CUSTOMISE.  They are not two entirely
> > separate systems, but overlap in their design a great deal.
>
> Here we have the attach method attaching different objects, but
> basically it can be handled for the frontend devices only (and that too
> that share a very common trait, in this case, frontends are coupled
> using the i2c bus) and not for other devices. Situation changes when you
> use another interface such as SPI, where the interface is not well defined.

This is not correct.  The dvb_attach() system has no assumption that it will
be used for a front-end device.  There are already users which are not
front-ends, such as tuners or lnb supply control chips, and yes, dst, which
will all know very well is not a frontend.

It also has nothing do with the i2c.  The attached device could be connected
in any way.  I plan to add dvb_attach() support for the cx88 secondary i2c bus
driver (aka vp3054), and that isn't even a different chip.

> > This design means the actual hard link between different drivers is limited to
> > each driver's single attach function (**).  By breaking this one link, we can
> > control which drivers must be loaded or linked to only those necessary or
> > wanted.  dvb_attach() and DVB_FE_CUSTOMISE are two different ways of
> > controlling these links.
>
> dvb_attach will have to go away for the DST. It doesn't work for the
> mentioned reasons that it is just pushing the device to a corner as a
> DVB frontend whereas it is not a DVB Frontend at all.

The dst is already using dvb_attach()!  I'm not changing that at all.

> being the author and maintainer of dst/dst_ca and maintainer of
> dvb-bt8xx, i NACK this change

Can one become a maintainer just be declaring ones self to be so?  Or is there
an expectation that a maintainer will in fact, maintain.  That is to say,
address concerns in a timely fashion, review patches and work in good faith to
resolve problems with said patches.

> What i would like to do is like this: Have the current state frozen as
> it is,

So as maintainer you are declaring that no changes of any kind are permitted?
That is to say, the code should become frozen, un-fixed and un-updated, in
other words, _unmaintained_.

How can you have it both ways, that you are the maintainer and that it should
be unmaintained?

Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)

[Manu Abraham]

Trent Piepho wrote:

> This is not correct.  The dvb_attach() system has no assumption that it will
> be used for a front-end device.  There are already users which are not
> front-ends, such as tuners or lnb supply control chips, 

SEC (aka Satellite Equipment Control) is a part of the frontend.

> 
> So as maintainer you are declaring that no changes of any kind are permitted?

Please do take a look at the changesets whether it is as you say.