Critical points about kernel 2.6.21 and pseudo-authorities

Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

Hi,
I swear I tested all seven release candidates of 2.6.21.
All were fine, and at least I haven't found any regressions.

But, what causes me some headache:

It seems to me that at every transition from the last release candidate
to the full kernel version stuff is being pushed in that should never be pushed in at all:

This happened with the final release of 2.6.20 (ide layer unusable),
and now it happens at some different place:

Symptoms:
for my AMD K7 machine, which is all but SiS chipset and configured as router,
the official 2.6.21 kernel is simply unusable, as it hangs up my machine
completely.

And now comes the critical point:
If I use kernel 2.6.21 in connection with git2 (NOT: git1) everything is fine so far.

BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code
in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab:

The regression is as follows:
If you run for instance a DVB card like the Pinnacle PCTV SAT (or CI) or the TwinHan DST (or CA) (which are two cards in a much bigger list of cards that, proven by facts, do not need any dvb-pll.c-module), you do not have any chance to deselect the compilation of the dvb-pll.c-module, as its deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1.
This part of the git2-code is a fallback to the development state of the year 2005.
All the almost excellent work that Michael Krufky has offered for that issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber exactly) is being wiped out and rolled back with his acknowledgement! Incredible!

So if I, as everybody else would, expect a clean and working kernel as final release,
where is the way out of this dilemma?? No idea!
And what happens at the transition of the last release candidate to the official kernel version? It's just another sad miracle!

I will append one dmesg for my AMD K7 router, which needs git2 to function at all,
plus one dmesg of my Intel P4 workstation, for which the official 2.6.21 plus all
preceding release candidates are fine, but NOT git2 definitely:

1. the dmesg of the AMD K7 router machine
Linux version 2.6.21-git2 (root@jerry) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Sat Apr 28 15:23:35 CEST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001def0000 end: 000000001dff0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001dff0000 size: 0000000000008000 end: 000000001dff8000 type: 3
copy_e820_map() start: 000000001dff8000 size: 0000000000008000 end: 000000001e000000 type: 4
copy_e820_map() start: 00000000ffee0000 size: 0000000000020000 end: 00000000fff00000 type: 2
copy_e820_map() start: 00000000fffc0000 size: 0000000000040000 end: 0000000100000000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001dff0000 (usable)
 BIOS-e820: 000000001dff0000 - 000000001dff8000 (ACPI data)
 BIOS-e820: 000000001dff8000 - 000000001e000000 (ACPI NVS)
 BIOS-e820: 00000000ffee0000 - 00000000fff00000 (reserved)
 BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
479MB LOWMEM available.
Entering add_active_range(0, 0, 122864) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   122864
early_node_map[1] active PFN ranges
    0:        0 ->   122864
On node 0 totalpages: 122864
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 927 pages used for memmap
  Normal zone: 117841 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000FA320, 0014 (r0 AMI   )
ACPI: RSDT 1DFF0000, 0028 (r1 AMIINT SiS740XX     1000 MSFT  100000B)
ACPI: FACP 1DFF0030, 0081 (r2 AMIINT SiS740XX       11 MSFT  100000B)
ACPI: DSDT 1DFF00C0, 3297 (r1    SiS      740      100 MSFT  100000D)
ACPI: FACS 1DFF8000, 0040
ACPI: PM-Timer IO Port: 0x808
Allocating PCI resources starting at 20000000 (gap: 1e000000:e1ee0000)
Built 1 zonelists.  Total pages: 121905
Kernel command line: root=/dev/hda1 ro vga=791
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (013c2000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 1526.880 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 484532k/491456k available (1349k kernel code, 6376k reserved, 477k data, 136k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb8000 - 0xfffff000   ( 284 kB)
    vmalloc : 0xde800000 - 0xfffb6000   ( 535 MB)
    lowmem  : 0xc0000000 - 0xddff0000   ( 479 MB)
      .init : 0xc02cc000 - 0xc02ee000   ( 136 kB)
      .data : 0xc0251682 - 0xc02c8cd0   ( 477 kB)
      .text : 0xc0100000 - 0xc0251682   (1349 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3054.53 BogoMIPS (lpj=1527269)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff c1c3f9ff 00000000 00000000 00000000 00000000 00000000
CPU: CLK_CTL MSR was 6003d22f. Reprogramming to 2003d22f
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383f9ff c1c3f9ff 00000000 00000420 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: AMD Athlon(tm) XP 1800+ stepping 01
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 0820)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=2
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Enabling SiS 96x SMBus.
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 *11 12 14 15)
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
Time: tsc clocksource has been installed.
PCI: Ignore bogus resource 6 [0:0] of 0000:01:00.0
PCI: Bridge: 0000:00:01.0
  IO window: a000-afff
  MEM window: cfd00000-cfefffff
  PREFETCH window: bfa00000-cfbfffff
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
io scheduler noop registered (default)
vesafb: framebuffer at 0xc0000000, mapped to 0xde880000, using 3072k, total 32768k
vesafb: mode is 1024x768x16, linelength=2048, pages=4
vesafb: protected mode interface info at cbd0:000c
vesafb: pmi: set display start = c00cbd46, set palette = c00cbd9c
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot 0000:00:02.5
SIS5513: chipset revision 0
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller
    ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: HDS728080PLAT20, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TSSTcorpDVD-ROM SH-D162C, ATAPI CD/DVD-ROM drive
hdd: CD-540E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 512KiB
hda: 160836480 sectors (82348 MB) w/1719KiB Cache, CHS=16383/255/63, UDMA(133)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
TCP cubic registered
Using IPI Shortcut mode
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 136k freed
NET: Registered protocol family 1
Linux agpgart interface v0.102 (c) Dave Jones
agpgart: Detected SiS 740 chipset
agpgart: AGP aperture is 64M @ 0xd0000000
sis900.c: v1.08.10 Apr. 2 2006
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
0000:00:04.0: VIA 6103 PHY transceiver found at address 1.
0000:00:04.0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xd000, IRQ 11, 00:0a:e6:67:a3:c1.
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at de81cf80.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKE] -> GSI 5 (level, low) -> IRQ 5
ohci_hcd 0000:00:03.0: OHCI Host Controller
ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:03.0: irq 5, io mem 0xcfff7000
SCSI subsystem initialized
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP(,...)]
hdc: ATAPI 48X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdd: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:03.1[B] -> Link [LNKF] -> GSI 11 (level, low) -> IRQ 11
ohci_hcd 0000:00:03.1: OHCI Host Controller
ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:03.1: irq 11, io mem 0xcfff8000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:03.2[C] -> Link [LNKG] -> GSI 11 (level, low) -> IRQ 11
ohci_hcd 0000:00:03.2: OHCI Host Controller
ohci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:03.2: irq 11, io mem 0xcfff9000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:03.3[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:00:03.3: EHCI Host Controller
ehci_hcd 0000:00:03.3: new USB bus registered, assigned bus number 4
PCI: cache line size of 64 is not supported by device 0000:00:03.3
ehci_hcd 0000:00:03.3: irq 11, io mem 0xcfffa000
ehci_hcd 0000:00:03.3: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
sis96x_smbus 0000:00:02.1: SiS96x SMBus base address: 0x0c00
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940A Ultra SCSI adapter>
        aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs

ACPI: PCI Interrupt 0000:00:02.7[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
intel8x0_measure_ac97_clock: measured 50839 usecs
intel8x0: clocking to 48000
Adding 1951856k swap on /dev/hda7.  Priority:-1 extents:1 across:1951856k
EXT3 FS on hda1, internal journal
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
input: Sleep Button (CM) as /class/input/input2
ACPI: Sleep Button (CM) [SLPB]
NET: Registered protocol family 17
mice: PS/2 mouse device common for all mice
PNP: PS/2 Controller [PNP030b:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
loop: loaded (max 8 devices)
logips2pp: Detected unknown logitech mouse model 5
input: PS/2 Logitech Mouse as /class/input/input3
input: AT Translated Set 2 keyboard as /class/input/input4
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth1:  setting full-duplex.
eth1:  setting full-duplex.
eth0: Media Link On 100mbps full-duplex 
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
lp0: using parport0 (interrupt-driven).
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (3839 buckets, 30712 max)

2. The dmesg of the Intel P4 workstation, whose DVB card (Pinnacle PCTV SAT) is, in spite of all attempts of Mister Mauro Carvalho Chehab (chief maintainer of linuxtv.org) to ignore my contributions and fighting them down, WORKING EXCELLENTLY
without the modules dst, dst_ca AND, latest git2 regression caused by Chehab personally, WITHOUT module dvb-pll.c!
Linux version 2.6.21.1 (root@brian) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Sun Apr 29 15:48:44 CEST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001feec000 end: 000000001ffec000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001ffec000 size: 0000000000003000 end: 000000001ffef000 type: 3
copy_e820_map() start: 000000001ffef000 size: 0000000000010000 end: 000000001ffff000 type: 2
copy_e820_map() start: 000000001ffff000 size: 0000000000001000 end: 0000000020000000 type: 4
copy_e820_map() start: 00000000fec00000 size: 0000000000001000 end: 00000000fec01000 type: 2
copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end: 00000000fee01000 type: 2
copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end: 0000000100000000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ffec000 (usable)
 BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data)
 BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved)
 BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
Entering add_active_range(0, 0, 131052) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   131052
early_node_map[1] active PFN ranges
    0:        0 ->   131052
On node 0 totalpages: 131052
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 991 pages used for memmap
  Normal zone: 125965 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000F5360, 0014 (r0 ASUS  )
ACPI: RSDT 1FFEC000, 0030 (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: FACP 1FFEC0C0, 0074 (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: DSDT 1FFEC134, 2A43 (r1   ASUS P4PE         1000 MSFT  100000B)
ACPI: FACS 1FFFF000, 0040
ACPI: BOOT 1FFEC030, 0028 (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: APIC 1FFEC058, 005A (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: PM-Timer IO Port: 0xe408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Built 1 zonelists.  Total pages: 130029
Kernel command line: root=/dev/hda1 ro vga=791
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 1818.051 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 517076k/524208k available (1309k kernel code, 6596k reserved, 485k data, 136k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb8000 - 0xfffff000   ( 284 kB)
    vmalloc : 0xe0800000 - 0xfffb6000   ( 503 MB)
    lowmem  : 0xc0000000 - 0xdffec000   ( 511 MB)
      .init : 0xc02c4000 - 0xc02e6000   ( 136 kB)
      .data : 0xc02475aa - 0xc02c0b90   ( 485 kB)
      .text : 0xc0100000 - 0xc02475aa   (1309 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3637.56 BogoMIPS (lpj=1818780)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 3febfbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: 3febfbff 00000000 00000000 00003080 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 04
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf1e60, last bus=2
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
* The chipset may have PM-Timer Bug. Due to workarounds for a bug,
* this clock source is slow. If you are sure your timer does not have
* this bug, please use "acpi_pm_good" to disable the workaround
PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region ec00-ec3f claimed by ICH4 GPIO
PCI: Enabled i801 SMBus device
Boot video device is 0000:01:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 17 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved
pnp: 00:00: iomem range 0xf0000-0xfffff could not be reserved
pnp: 00:00: iomem range 0x100000-0x1fffffff could not be reserved
pnp: 00:00: iomem range 0xfec00000-0xfec000ff could not be reserved
pnp: 00:02: ioport range 0xe400-0xe47f has been reserved
pnp: 00:02: ioport range 0xe800-0xe81f has been reserved
pnp: 00:02: ioport range 0xec00-0xec3f has been reserved
pnp: 00:02: ioport range 0x4d6-0x4d6 has been reserved
pnp: 00:02: iomem range 0xfff80000-0xffffffff could not be reserved
pnp: 00:02: iomem range 0xffb80000-0xffbfffff has been reserved
pnp: 00:10: ioport range 0x3f0-0x3f1 has been reserved
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: f2000000-f27fffff
  PREFETCH window: f3f00000-f7ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: f1000000-f17fffff
  PREFETCH window: f2800000-f3efffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
Simple Boot Flag at 0x3a set to 0x1
io scheduler noop registered (default)
vesafb: framebuffer at 0xf4000000, mapped to 0xe0880000, using 3072k, total 32768k
vesafb: mode is 1024x768x16, linelength=2048, pages=20
vesafb: protected mode interface info at c000:441b
vesafb: pmi: set display start = c00c4489, set palette = c00c44c3
vesafb: pmi: ports = d810 d816 d854 d838 d83c d85c d800 d804 d8b0 d8b2 d8b4 
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: IC35L080AVVA07-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: HL-DT-STDVD-ROM GDR8163B, ATAPI CD/DVD-ROM drive
hdd: CD-W54E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
TCP cubic registered
Using IPI Shortcut mode
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 136k freed
NET: Registered protocol family 1
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 17, io base 0x0000b800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 18, io base 0x0000b400
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 16, io base 0x0000b000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Enabling device 0000:00:1d.7 (0004 -> 0006)
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xf1800000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
hdc: ATAPI 52X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Linux video capture interface: v2.00
b44.c:v1.01 (Jun 16, 2006)
PCI: Enabling device 0000:02:05.0 (0004 -> 0006)
ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 20 (level, low) -> IRQ 20
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0c:6e:19:46:cf
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 1280kB Cache, DMA
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
PCI: Enabling device 0000:00:1f.5 (0004 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1f.5 to 64
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
intel8x0_measure_ac97_clock: measured 50043 usecs
intel8x0: clocking to 48000
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 21
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 19
bttv0: Bt878 (rev 17) at 0000:02:0b.0, irq: 19, 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=00df00fc [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 19
bt878_probe: card id=[0x1c11bd],[ Pinnacle PCTV Sat ] has DVB functions.
bt878(0): Bt878 (rev 17) at 02:0b.1, irq: 19, latency: 32, memory: 0xf2800000
Adding 1951856k swap on /dev/hda6.  Priority:-1 extents:1 across:1951856k
EXT3 FS on hda1, internal journal
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
ACPI: Invalid PBLK length [5]
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
NET: Registered protocol family 17
mice: PS/2 mouse device common for all mice
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard as /class/input/input2
DVB: registering new adapter (bttv0).
DVB: registering frontend 0 (Conexant CX24110 DVB-S)...
loop: loaded (max 8 devices)
logips2pp: Detected unknown logitech mouse model 11
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
input: PS/2 Logitech Mouse as /class/input/input3
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.

Hope there is a way out of the dilemma.
Why can't I even expect sober kernels that are being released as official final releases? I assume that this has got something to do with rather pseudo-authority hierarchies, at least in one proven and certified case @linuxtv.org!

Cheers
Uwe

-- 



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

Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Linus Torvalds]

On Sun, 29 Apr 2007, Uwe Bugla wrote:
> 
> And now comes the critical point:
> If I use kernel 2.6.21 in connection with git2 (NOT: git1) everything is fine so far.

Sounds like the sis900 network driver problem.

> BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code
> in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab:

You never explained what the problem even was, apart from compiling in 
some code that you didn't need to before. Didn't it work in the end?

If it worked, I don't see what the big issue was. You are getting a _lot_ 
of other code in the kernel that you probably never use, you may not even 
have realized.

Uwe, you really aren't helping yourself by being so damn abrasive. I know 
for a fact that your bug-reports are going ignored by some people, and I'm 
not surprised at all.

			Linus

Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 11:49:40 -0700 (PDT)
Von: Linus Torvalds <torvalds@linux-foundation.org>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, mchehab@infradead.org, mkruky@linuxtv.org, linux-dvb@linuxtv.org
Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities

> 
> 
> On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > 
> > And now comes the critical point:
> > If I use kernel 2.6.21 in connection with git2 (NOT: git1) everything is
> fine so far.
> 
> Sounds like the sis900 network driver problem.

Hi Linus,
I thought that this problem could be reduced to the sis900 driver issue, but today I found out that I was wrong. In so far:
The kernel 2.6.21 official kernel makes my router hang up
The kernel 2.6.21-git1 makes my router hang up

Simply the 2.6.21-git2 is running stable.

CLEARER: The sis900 patch is part of git1. In so far it cannot and will never be the real reason for the kernel Oopses on my router.

I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it).
I did not manage to find out what part of the git2-code is necessary to make my AMD K7 router run stable. It is somewhere right between git1 and git2 - that is all I can say about that. It is definitely NOT the NIC issue.
> 
> > BUT: This 2.6.21-git2 is unusable in so far as it contains regressive
> code
> > in the dvb-section, authored by Trent Piepho, acked by Michael Krufky,
> and signed-off-by Mauro Carvalho Chehab:
> 
> You never explained what the problem even was, apart from compiling in 
> some code that you didn't need to before. Didn't it work in the end?

Yes it works, but it is a regression in so far as I was fighting and arguing to get rid of some useless module attachments in the past which was then put into practice as solution done by Michael Krufky in a very sophisticated and fine manner.

With the git2 solution I am condemned to waste RAM with at least one module that my card and a whole lot of other cards never needed. In so far it is a fallback and regression (like the router code that made floppy mounting impossible at the beginning of 2.6.21-rc1 or so, if you can remember this...
You decided to rip that buggy stuff out - and this was a fine decision!

I like small and effective kernels instead of blown up RAM waste.
This is no Windoze, man, this is Linux!
> 
> If it worked, I don't see what the big issue was. You are getting a _lot_ 
> of other code in the kernel that you probably never use, you may not even 
> have realized.

May be, don't know! But wouldn't it be a nice trait to at least get rid of unusable code that the specific machine does not need at all?

Now, if that aim sounds too abrasive, what's the use of kernel compilation then?
Do you expect me to accept a Kernel of a size of 2 or 3 Megabytes, with module support completely disabled and the RAM overcrowded with modules that I never needed?

In the specific example of git2's dvb code you cannot disable the compilation of dvb-pll.c if you use the v4l normal layer (VIDEO_V4L1).

If you are forced to use the v4l compat layer (VIDEO_V4L1_COMPAT) to enable a specific group of cards you do not have any chance to get rid of this module!

Now - if this is no serious bug or regression, please what else is a serious bug or regression then?

> 
> Uwe, you really aren't helping yourself by being so damn abrasive. I know 
> for a fact that your bug-reports are going ignored by some people, and I'm
> not surprised at all.

Now what a gesture?
I can show you a ten Emails long ping pong game between Mauro and me which will prove you simply that Mauro Chehab never even did a five minutes look on my contributions.
Instead he spent three quarters of an hour or so to offer me nothing but
1. Lies
2. Unproved Theses
3. Unproved Assumptions

With only one strategic aim: Fighting me down to make me give up, nothing else!

Now Linus, how would you feel in my situation?
Should I call this man a maintainer?
Would you call this man a maintainer?

See, I have had such a many positive experiences since I actively engaged in Linux.
With maintainers, with quite a lots of other real fine people.

And above that, I obviously am not alone at all. It was nobody but Johannes Stezenbach himself who uttered great sorrow where the personnel of linuxtv.org is going to (see mail list please).

It seems like a 4 cylinder machine running on 2 or 3 cylinders, you know....
> 
> 			Linus

Yours sincerely

Uwe

P. S.: If there are further questions I'd appreciate you to ask.

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

Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Linus Torvalds]

On Sun, 29 Apr 2007, Uwe Bugla wrote:
> 
> I have been trying diff and other tools in various variants (except 
> git-bisect that I cannot handle because I do not understand the practice 
> of it).

git bisect is _really_ simple if you already have a git tree anyway. And 
even if you don't, getting one isn't really hard either. Just do

	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

and you have a tree (it will take a little while - it's going to dowload 
about 170MB or so of stuff, so the initial clone is going to be a bit 
painful unless you have a fast internet connection).

Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's 
really as easy as just saying

	git bisect start
	git bisect good v2.6.21-rc7
	git bisect bad v2.6.21

and git will think for a short while (most of the time is going to be 
checking out the new tree) and give you a tree to test.

Just build, boot, and test that tree.

If it was fine, do

	git bisect good

and git will pick a new tree to test. And if it wasn't, instead just do 
"git bisect bad", and git will pick _another_ version to test. Do this a 
few times, and git will tell you which commit introduced them.

There were just 125 commits in between 2.6.21-rc7 and the final one, so it 
should be quite quick - bisection basically does a binary search, so doing 
seven reboots should have you with the result.

The fact that it already works in 2.6.21-git2 obviously means that _I_ end 
up being less interested, but the -stable tree people would love to hear 
what broke!

> I like small and effective kernels instead of blown up RAM waste.
> This is no Windoze, man, this is Linux!

Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere 
at all.

This is Linux, not Windows. But that also means that those developers that 
you denigrate aren't getting paid by you, and if you don't show them 
respect, they'll totally ignore you.

		Linus

Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
Von: Linus Torvalds <torvalds@linux-foundation.org>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org, mchehab@infradead.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities

> 
> 
> On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > 
> > I have been trying diff and other tools in various variants (except 
> > git-bisect that I cannot handle because I do not understand the practice
> > of it).
> 
> git bisect is _really_ simple if you already have a git tree anyway. And 
> even if you don't, getting one isn't really hard either. Just do
> 
> 	git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> 
> and you have a tree (it will take a little while - it's going to dowload 
> about 170MB or so of stuff, so the initial clone is going to be a bit 
> painful unless you have a fast internet connection).
> 
> Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's 
> really as easy as just saying
> 
> 	git bisect start
> 	git bisect good v2.6.21-rc7
> 	git bisect bad v2.6.21
> 
> and git will think for a short while (most of the time is going to be 
> checking out the new tree) and give you a tree to test.
> 
> Just build, boot, and test that tree.
> 
> If it was fine, do
> 
> 	git bisect good
> 
> and git will pick a new tree to test. And if it wasn't, instead just do 
> "git bisect bad", and git will pick _another_ version to test. Do this a 
> few times, and git will tell you which commit introduced them.
> 
> There were just 125 commits in between 2.6.21-rc7 and the final one, so it
> should be quite quick - bisection basically does a binary search, so doing
> seven reboots should have you with the result.
> 
> The fact that it already works in 2.6.21-git2 obviously means that _I_ end
> up being less interested, but the -stable tree people would love to hear 
> what broke!

Hi again Linus,
my deep thanks for your excellent explication of git-bisect.
But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more).
Just to take up a different approach:

The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all.

On the other hand I found out that:
2.6.21-rc7 made my AMD K7 router work fine
2.6.21 official hung my AMD K7 router up
2.6.21-git1 hung my AMD K7 router up
2.6.21-git2 made my AMD K7 router work.

In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem.
Or am I saying something wrong as far as logical terms are concerned?

> 
> > I like small and effective kernels instead of blown up RAM waste.
> > This is no Windoze, man, this is Linux!
> 
> Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere 
> at all.
> 
> This is Linux, not Windows. But that also means that those developers that
> you denigrate aren't getting paid by you, and if you don't show them 
> respect, they'll totally ignore you.
> 
> 		Linus

Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called "maintainers" who behave like kids, but not like grown-ups at all!
Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped!

For the majority of all cases of the so-called "maintainer personnel" at linuxtv.org the statement of some missing "politeness" or some missing "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence.

They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks.
And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure.

Would you call Mauro Carvalho Chehab a maintainer!
I can certify you that I cannot, even if I try. And I want him to be substituted as quick as possible as he is the biggest mismatch of gatekeeper one can ever imagine.

And it is not only me personally perceiving this that there are people missing who can go upright and offer sophisticated and good work.
Plus a real sophisticated discussion behaviour, in technical and in human terms.
Going upright is thus far away from the behaviour NOT to be able to tolerate any criticism at all.

Solution: This whole new quite young linuxtv.org team is missing a real grown up and experienced team leader. Not only that is definitely too much for Mauro Carvalho Chehab. That is the pain - the consistence of the whole group is the pain, that's all. Too young, too many lacks of human skills, and missing an appropriate team leader.............

So, if I show respect or not, or if I show politeness or not will never change the whole structural situation at all, as great parts of the whole team is a disease:
1. By Chehab being the team leader the whole fish stinks from the head startup.
Solution: Substitution of Mauro Carvalho Chehab as quick as possible - even quicker than a storm!
2. By Krufky being one part of it, doing good work, but executing wrong solidarities by his bowing behaviour towards pseudo-authorities although he knows better at least technically this is a question of wrong or right leadership, nothing else
3. By Abraham offering us great ranting aims that never are being put into practice out of certified missing human skills and missing technical knowledge (the four completely unusable 2.6 kernels were never apologized by himself) urgent substitution  is utmost necessary.

CLEARER: If anyone of the people knowing the deeper context claims those "gatekeeper methods" to be a consequence of missing "respect" or missing "politeness" then those people are either strictly dumb and superficial, or they owe a gesture that I would call a "Well, I know, but I do not want to see what's going on"-disease, nothing else.

Another term to describe the latter would be "bureaucratic lamb head behaviour".

See, Linus, if for instance Andrew Morton mails me some statement from that Chehab going: "Again, do not take the patches from Uwe - he is always regarding things through his personal prisma, and the rest he simply does not perceive at all"

then this is nothing but a gesture full of lies (somehow typical for this Brazilian fascistoid opinion block head dictator), but it simply shows that the linuxtv.org teamleader is a horrible mismatch, nothing else!

His mediocrity and dumbness simply defines through the fact that he is using stigmatizations very soon in a so-called "discussion" because he misses
a. human skills
b. technical proven arguments and theses 
c. enough experience, human or technical one.

And the biggest threat and shame is the proven fact that Andrew Morton does obey to such a stupid reactionary idiot and let his face soap in by this dirty Brazilian hypocrite instead of giving contributions at least a chance through his mm-tree.

So there are exactly two solutions:
1. Andrew Morton should not obey to Chehab anymore and be real open
2. Chehab and Abraham should be substituted as quick as possible without any hesitation in no way!!!!

The one that got to be fired with the most urgent priority is called Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper, but this is nothing but a real personified ape or disease.

And the argument whether those people are paid for their work or not is exactly as important as if a sack of rice falls down somewhere in capitalist China or not.....
OBSOLETE!!!

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: Critical points about kernel 2.6.21 and pseudo-authorities

[hermann pitton]

Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
> -------- Original-Nachricht --------
> Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> Von: Linus Torvalds <torvalds@linux-foundation.org>
> An: Uwe Bugla <uwe.bugla@gmx.de>
> CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org, mchehab@infradead.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org
> Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities
> 
> > 
> > 
> > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > 
> > > I have been trying diff and other tools in various variants (except 
> > > git-bisect that I cannot handle because I do not understand the practice
> > > of it).
> > 
> > git bisect is _really_ simple if you already have a git tree anyway. And 
> > even if you don't, getting one isn't really hard either. Just do
> > 
> > 	git clone
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> > 
> > and you have a tree (it will take a little while - it's going to dowload 
> > about 170MB or so of stuff, so the initial clone is going to be a bit 
> > painful unless you have a fast internet connection).
> > 
> > Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's 
> > really as easy as just saying
> > 
> > 	git bisect start
> > 	git bisect good v2.6.21-rc7
> > 	git bisect bad v2.6.21
> > 
> > and git will think for a short while (most of the time is going to be 
> > checking out the new tree) and give you a tree to test.
> > 
> > Just build, boot, and test that tree.
> > 
> > If it was fine, do
> > 
> > 	git bisect good
> > 
> > and git will pick a new tree to test. And if it wasn't, instead just do 
> > "git bisect bad", and git will pick _another_ version to test. Do this a 
> > few times, and git will tell you which commit introduced them.
> > 
> > There were just 125 commits in between 2.6.21-rc7 and the final one, so it
> > should be quite quick - bisection basically does a binary search, so doing
> > seven reboots should have you with the result.
> > 
> > The fact that it already works in 2.6.21-git2 obviously means that _I_ end
> > up being less interested, but the -stable tree people would love to hear 
> > what broke!
> 
> Hi again Linus,
> my deep thanks for your excellent explication of git-bisect.
> But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more).
> Just to take up a different approach:
> 
> The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all.
> 
> On the other hand I found out that:
> 2.6.21-rc7 made my AMD K7 router work fine
> 2.6.21 official hung my AMD K7 router up
> 2.6.21-git1 hung my AMD K7 router up
> 2.6.21-git2 made my AMD K7 router work.
> 
> In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem.
> Or am I saying something wrong as far as logical terms are concerned?
> 
> > 
> > > I like small and effective kernels instead of blown up RAM waste.
> > > This is no Windoze, man, this is Linux!
> > 
> > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere 
> > at all.
> > 
> > This is Linux, not Windows. But that also means that those developers that
> > you denigrate aren't getting paid by you, and if you don't show them 
> > respect, they'll totally ignore you.
> > 
> > 		Linus
> 
> Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called "maintainers" who behave like kids, but not like grown-ups at all!
> Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped!
> 
> For the majority of all cases of the so-called "maintainer personnel" at linuxtv.org the statement of some missing "politeness" or some missing "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence.
> 
> They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks.
> And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality structure.
> 
> Would you call Mauro Carvalho Chehab a maintainer!
> I can certify you that I cannot, even if I try. And I want him to be substituted as quick as possible as he is the biggest mismatch of gatekeeper one can ever imagine.
> 
> And it is not only me personally perceiving this that there are people missing who can go upright and offer sophisticated and good work.
> Plus a real sophisticated discussion behaviour, in technical and in human terms.
> Going upright is thus far away from the behaviour NOT to be able to tolerate any criticism at all.
> 
> Solution: This whole new quite young linuxtv.org team is missing a real grown up and experienced team leader. Not only that is definitely too much for Mauro Carvalho Chehab. That is the pain - the consistence of the whole group is the pain, that's all. Too young, too many lacks of human skills, and missing an appropriate team leader.............
> 
> So, if I show respect or not, or if I show politeness or not will never change the whole structural situation at all, as great parts of the whole team is a disease:
> 1. By Chehab being the team leader the whole fish stinks from the head startup.
> Solution: Substitution of Mauro Carvalho Chehab as quick as possible - even quicker than a storm!
> 2. By Krufky being one part of it, doing good work, but executing wrong solidarities by his bowing behaviour towards pseudo-authorities although he knows better at least technically this is a question of wrong or right leadership, nothing else
> 3. By Abraham offering us great ranting aims that never are being put into practice out of certified missing human skills and missing technical knowledge (the four completely unusable 2.6 kernels were never apologized by himself) urgent substitution  is utmost necessary.
> 
> CLEARER: If anyone of the people knowing the deeper context claims those "gatekeeper methods" to be a consequence of missing "respect" or missing "politeness" then those people are either strictly dumb and superficial, or they owe a gesture that I would call a "Well, I know, but I do not want to see what's going on"-disease, nothing else.
> 
> Another term to describe the latter would be "bureaucratic lamb head behaviour".
> 
> See, Linus, if for instance Andrew Morton mails me some statement from that Chehab going: "Again, do not take the patches from Uwe - he is always regarding things through his personal prisma, and the rest he simply does not perceive at all"
> 
> then this is nothing but a gesture full of lies (somehow typical for this Brazilian fascistoid opinion block head dictator), but it simply shows that the linuxtv.org teamleader is a horrible mismatch, nothing else!
> 
> His mediocrity and dumbness simply defines through the fact that he is using stigmatizations very soon in a so-called "discussion" because he misses
> a. human skills
> b. technical proven arguments and theses 
> c. enough experience, human or technical one.
> 
> And the biggest threat and shame is the proven fact that Andrew Morton does obey to such a stupid reactionary idiot and let his face soap in by this dirty Brazilian hypocrite instead of giving contributions at least a chance through his mm-tree.
> 
> So there are exactly two solutions:
> 1. Andrew Morton should not obey to Chehab anymore and be real open
> 2. Chehab and Abraham should be substituted as quick as possible without any hesitation in no way!!!!
> 
> The one that got to be fired with the most urgent priority is called Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper, but this is nothing but a real personified ape or disease.
> 
> And the argument whether those people are paid for their work or not is exactly as important as if a sack of rice falls down somewhere in capitalist China or not.....
> OBSOLETE!!!
> 
> Yours sincerely
> Uwe
> 

If eventually somebody thinks this kind of stuff could be helpful,
please say so and give us some pointers.

Hermann

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 02:58:33 +0200
Von: hermann pitton <hermann-pitton@arcor.de>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: Linus Torvalds <torvalds@linux-foundation.org>, mkruky@linuxtv.org, akpm@linux-foundation.org, linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities

> Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
> > -------- Original-Nachricht --------
> > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> > Von: Linus Torvalds <torvalds@linux-foundation.org>
> > An: Uwe Bugla <uwe.bugla@gmx.de>
> > CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org, mchehab@infradead.org,
> linux-kernel@vger.kernel.org, akpm@linux-foundation.org
> > Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities
> > 
> > > 
> > > 
> > > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > > 
> > > > I have been trying diff and other tools in various variants (except 
> > > > git-bisect that I cannot handle because I do not understand the
> practice
> > > > of it).
> > > 
> > > git bisect is _really_ simple if you already have a git tree anyway.
> And 
> > > even if you don't, getting one isn't really hard either. Just do
> > > 
> > > 	git clone
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> linux-2.6
> > > 
> > > and you have a tree (it will take a little while - it's going to
> dowload 
> > > about 170MB or so of stuff, so the initial clone is going to be a bit 
> > > painful unless you have a fast internet connection).
> > > 
> > > Once you have the git tree, assuming that 2.6.21-rc7 worked for you,
> it's 
> > > really as easy as just saying
> > > 
> > > 	git bisect start
> > > 	git bisect good v2.6.21-rc7
> > > 	git bisect bad v2.6.21
> > > 
> > > and git will think for a short while (most of the time is going to be 
> > > checking out the new tree) and give you a tree to test.
> > > 
> > > Just build, boot, and test that tree.
> > > 
> > > If it was fine, do
> > > 
> > > 	git bisect good
> > > 
> > > and git will pick a new tree to test. And if it wasn't, instead just
> do 
> > > "git bisect bad", and git will pick _another_ version to test. Do this
> a 
> > > few times, and git will tell you which commit introduced them.
> > > 
> > > There were just 125 commits in between 2.6.21-rc7 and the final one,
> so it
> > > should be quite quick - bisection basically does a binary search, so
> doing
> > > seven reboots should have you with the result.
> > > 
> > > The fact that it already works in 2.6.21-git2 obviously means that _I_
> end
> > > up being less interested, but the -stable tree people would love to
> hear 
> > > what broke!
> > 
> > Hi again Linus,
> > my deep thanks for your excellent explication of git-bisect.
> > But I unfortunately owe a 100Kbit flatrate, and so downloading some 170
> MB git tree will need the time amount of one entire night (11.5 kb /s if I
> am lucky - no more).
> > Just to take up a different approach:
> > 
> > The difference between 2.6.21-rc7 and 2.6.21 official does not play any
> role at all.
> > 
> > On the other hand I found out that:
> > 2.6.21-rc7 made my AMD K7 router work fine
> > 2.6.21 official hung my AMD K7 router up
> > 2.6.21-git1 hung my AMD K7 router up
> > 2.6.21-git2 made my AMD K7 router work.
> > 
> > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves
> the problem.
> > Or am I saying something wrong as far as logical terms are concerned?
> > 
> > > 
> > > > I like small and effective kernels instead of blown up RAM waste.
> > > > This is no Windoze, man, this is Linux!
> > > 
> > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get
> anywhere 
> > > at all.
> > > 
> > > This is Linux, not Windows. But that also means that those developers
> that
> > > you denigrate aren't getting paid by you, and if you don't show them 
> > > respect, they'll totally ignore you.
> > > 
> > > 		Linus
> > 
> > Now this is the old problem about it all: the hypocricy factor, the
> utmost small, if not to say pre-pubertarian character plus some other obviously
> counter-productive character traits in those so-called "maintainers" who
> behave like kids, but not like grown-ups at all!
> > Not only you, but also Andrew perfectly and willingly step into the
> hypocritic trap and do not even feel that they are trapped!
> > 
> > For the majority of all cases of the so-called "maintainer personnel" at
> linuxtv.org the statement of some missing "politeness" or some missing
> "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost
> stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness,
> wrong solidarity, kiddishness and technical incompetence.
> > 
> > They are building up pseudo-authorities to hide their lack of
> competence, no matter if their lack of competence funds on technical or human lacks.
> > And at least the Brazilian Mauro Carvalho Chehab does go even so far to
> soap in Andrew Morton's face with this enourmous threat of incompetence,
> kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness,
> lack of experience, pre-pubertarian behaviour, fascistoid opinion
> dictatorship as part of a deep immature anti-democratic and reactionary personality
> structure.
> > 
> > Would you call Mauro Carvalho Chehab a maintainer!
> > I can certify you that I cannot, even if I try. And I want him to be
> substituted as quick as possible as he is the biggest mismatch of gatekeeper
> one can ever imagine.
> > 
> > And it is not only me personally perceiving this that there are people
> missing who can go upright and offer sophisticated and good work.
> > Plus a real sophisticated discussion behaviour, in technical and in
> human terms.
> > Going upright is thus far away from the behaviour NOT to be able to
> tolerate any criticism at all.
> > 
> > Solution: This whole new quite young linuxtv.org team is missing a real
> grown up and experienced team leader. Not only that is definitely too much
> for Mauro Carvalho Chehab. That is the pain - the consistence of the whole
> group is the pain, that's all. Too young, too many lacks of human skills,
> and missing an appropriate team leader.............
> > 
> > So, if I show respect or not, or if I show politeness or not will never
> change the whole structural situation at all, as great parts of the whole
> team is a disease:
> > 1. By Chehab being the team leader the whole fish stinks from the head
> startup.
> > Solution: Substitution of Mauro Carvalho Chehab as quick as possible -
> even quicker than a storm!
> > 2. By Krufky being one part of it, doing good work, but executing wrong
> solidarities by his bowing behaviour towards pseudo-authorities although he
> knows better at least technically this is a question of wrong or right
> leadership, nothing else
> > 3. By Abraham offering us great ranting aims that never are being put
> into practice out of certified missing human skills and missing technical
> knowledge (the four completely unusable 2.6 kernels were never apologized by
> himself) urgent substitution  is utmost necessary.
> > 
> > CLEARER: If anyone of the people knowing the deeper context claims those
> "gatekeeper methods" to be a consequence of missing "respect" or missing
> "politeness" then those people are either strictly dumb and superficial, or
> they owe a gesture that I would call a "Well, I know, but I do not want to
> see what's going on"-disease, nothing else.
> > 
> > Another term to describe the latter would be "bureaucratic lamb head
> behaviour".
> > 
> > See, Linus, if for instance Andrew Morton mails me some statement from
> that Chehab going: "Again, do not take the patches from Uwe - he is always
> regarding things through his personal prisma, and the rest he simply does
> not perceive at all"
> > 
> > then this is nothing but a gesture full of lies (somehow typical for
> this Brazilian fascistoid opinion block head dictator), but it simply shows
> that the linuxtv.org teamleader is a horrible mismatch, nothing else!
> > 
> > His mediocrity and dumbness simply defines through the fact that he is
> using stigmatizations very soon in a so-called "discussion" because he
> misses
> > a. human skills
> > b. technical proven arguments and theses 
> > c. enough experience, human or technical one.
> > 
> > And the biggest threat and shame is the proven fact that Andrew Morton
> does obey to such a stupid reactionary idiot and let his face soap in by
> this dirty Brazilian hypocrite instead of giving contributions at least a
> chance through his mm-tree.
> > 
> > So there are exactly two solutions:
> > 1. Andrew Morton should not obey to Chehab anymore and be real open
> > 2. Chehab and Abraham should be substituted as quick as possible without
> any hesitation in no way!!!!
> > 
> > The one that got to be fired with the most urgent priority is called
> Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper, but this
> is nothing but a real personified ape or disease.
> > 
> > And the argument whether those people are paid for their work or not is
> exactly as important as if a sack of rice falls down somewhere in
> capitalist China or not.....
> > OBSOLETE!!!
> > 
> > Yours sincerely
> > Uwe
> > 
> 
> If eventually somebody thinks this kind of stuff could be helpful,
> please say so and give us some pointers.
> 
> Hermann
> 
Hi Hermann,

now if you are searching for helpful stuff I can make public a ten Emails ping pong
betwwen stupid Chehab and me about my almost excellent dst-deselection patch contributions.

In this ten Emails you will yourself see the intellectual and technical proof in how far Mr. Chehab is acting with nothing else but:

a. Lies
b. Unproven thesis
c. Stigmatizations

and so on.

THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!

That's it what I cannot live with!
I swear I never stumbled over such an utomst stubborn, stupid and horrible idiot in my whole year lasting Linux experience, and I thought I could not trust my eyes when I saw what incredible crap work was pushed into mainline by the signature of this
incredible and horrible team chief from Brazil.

If you want to see the Emails, just ask me and I will forward them with a couple of CCs. They will show the truth about the real consistence of this "maintainer leader".

Cheers
Uwe

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Helge Hafting]

Uwe Bugla wrote:
> In this ten Emails you will yourself see the intellectual and technical proof in how far Mr. Chehab is acting with nothing else but:
>
> a. Lies
> b. Unproven thesis
> c. Stigmatizations
>
> and so on.
>
> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
>   
Please note that there are ways to replace a bad maintainer. 
We still try to keep it polite.

But note that you can't have someone "fired", no matter how bad they
do their job.  A bad maintainer is usually better than none - the bad
maintainer might improve. Or at least get some simple stuff done.

You therefore replace a bad maintainer by taking over the position. 
Contact whoever is above the maintainer (Linus or some other
higher-level maintainer). You explain the problem, and you must also
show that you have the time and knowledge to do a better job. 
You can, for example, maintain the same subsystem in parallel.  After a 
while,
all interested parties sees that your tree works better and that
communicating with you is easier.
If you aren't prepared to do this - then you have to live with the current
maintainer.  There is no staff ready to replace maintainers after
complaints, a volunteer doing a better job is always necessary.

Helge Hafting

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 13:21:29 +0200
Von: Helge Hafting <helge.hafting@aitel.hist.no>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities

> Uwe Bugla wrote:
> > In this ten Emails you will yourself see the intellectual and technical
> proof in how far Mr. Chehab is acting with nothing else but:
> >
> > a. Lies
> > b. Unproven thesis
> > c. Stigmatizations
> >
> > and so on.
> >
> > THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
> >   
> Please note that there are ways to replace a bad maintainer. 
> We still try to keep it polite.
> 
> But note that you can't have someone "fired", no matter how bad they
> do their job.  A bad maintainer is usually better than none - the bad
> maintainer might improve. Or at least get some simple stuff done.
> 
> You therefore replace a bad maintainer by taking over the position. 
> Contact whoever is above the maintainer (Linus or some other
> higher-level maintainer). You explain the problem, and you must also
> show that you have the time and knowledge to do a better job. 

Hi Helge,
A. I do neither have enough skills to take up a maintainers role
B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement.
That is at least my impression. 

> You can, for example, maintain the same subsystem in parallel.  After a 
> while,
> all interested parties sees that your tree works better and that
> communicating with you is easier.
> If you aren't prepared to do this - then you have to live with the current
> maintainer.  There is no staff ready to replace maintainers after
> complaints, a volunteer doing a better job is always necessary.

Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months.
ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise.

So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all!

But the practice now is the typical "Sit out and do not react at all" behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years.....

So there will be no "soft" or "polite" solution at all, but only a harsh and rude one:
"Kick out the Jams!"

> 
> Helge Hafting
> 
> 
Cheers
Uwe

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Helge Hafting]

Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Mon, 30 Apr 2007 13:21:29 +0200
> Von: Helge Hafting <helge.hafting@aitel.hist.no>
> An: Uwe Bugla <uwe.bugla@gmx.de>
> CC: linux-kernel@vger.kernel.org
> Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities
>
>   
>> Uwe Bugla wrote:
>>     
>>> In this ten Emails you will yourself see the intellectual and technical
>>>       
>> proof in how far Mr. Chehab is acting with nothing else but:
>>     
>>> a. Lies
>>> b. Unproven thesis
>>> c. Stigmatizations
>>>
>>> and so on.
>>>
>>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
>>>   
>>>       
>> Please note that there are ways to replace a bad maintainer. 
>> We still try to keep it polite.
>>
>> But note that you can't have someone "fired", no matter how bad they
>> do their job.  A bad maintainer is usually better than none - the bad
>> maintainer might improve. Or at least get some simple stuff done.
>>
>> You therefore replace a bad maintainer by taking over the position. 
>> Contact whoever is above the maintainer (Linus or some other
>> higher-level maintainer). You explain the problem, and you must also
>> show that you have the time and knowledge to do a better job. 
>>     
>
> Hi Helge,
> A. I do neither have enough skills to take up a maintainers role
>   
Then your only hope is to find someone else that is interested.
> B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement.
> That is at least my impression. 
>   
The aren't doing any less than you do. They don't provide a better
maintainer, but neither do you.   Linus and  Andrew don't have that
much more resources than you have.  They have programming skills
and lots of trust in the community.

>> You can, for example, maintain the same subsystem in parallel.  After a 
>> while,
>> all interested parties sees that your tree works better and that
>> communicating with you is easier.
>> If you aren't prepared to do this - then you have to live with the current
>> maintainer.  There is no staff ready to replace maintainers after
>> complaints, a volunteer doing a better job is always necessary.
>>     
>
> Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months.
> ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise.
>   
A sufficiently bad maintainer will also do it.  If lots of submitters send
their patches to andrew in order to get past a dysfunctional maintainer,
then the subsystem effectively is unmaintained.
> So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all!
>   
Well then - create a patch to the MAINTAINERS file that removes this 
maintainer
leaving the position open.  Perhaps you can get that accepted despite the
existing maintainer - *if* you can get most other developers for that
subsystem to add signed-off lines.  It will then be clear that the
community agrees with you. 

However, if the bulk of them thinks the current maintainer is fine, then
it stays that way.  Satisfying everybody is unfortunately not always 
possible.
You can always try submitting your own patches above this maintainer.
> But the practice now is the typical "Sit out and do not react at all" behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years.....
>
> So there will be no "soft" or "polite" solution at all, but only a harsh and rude one:
> "Kick out the Jams!"
Dropping lazy or incompetent maintainers do happen occationally.
But don't let frustration lead to angry emails - all you get that way is 
lost
credibility, that will only make it harder to convince people.

Helge Hafting

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Markus Rechberger]

all these discussions are about Makefile and documentation changes as
far as I see.
I don't see the point why there's a need for such a big discussion
here just about these changes.
Uwe please resend your patch files and lets get this story done, if
your work breaks something we can point you out to what is wrong.
We have what's in the repository now and it won't change unless we put
some time in it again.

Uwe, if you have a problem with anyone here keep it for yourself just
submit the latest patches and I'll have a look asap at it. There's no
need to be unfriendly here.

Markus

On 4/30/07, Helge Hafting <helge.hafting@aitel.hist.no> wrote:
> Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Mon, 30 Apr 2007 13:21:29 +0200
> > Von: Helge Hafting <helge.hafting@aitel.hist.no>
> > An: Uwe Bugla <uwe.bugla@gmx.de>
> > CC: linux-kernel@vger.kernel.org
> > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21
> and	pseudo-authorities
> >
> >
> >> Uwe Bugla wrote:
> >>
> >>> In this ten Emails you will yourself see the intellectual and technical
> >>>
> >> proof in how far Mr. Chehab is acting with nothing else but:
> >>
> >>> a. Lies
> >>> b. Unproven thesis
> >>> c. Stigmatizations
> >>>
> >>> and so on.
> >>>
> >>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
> >>>
> >>>
> >> Please note that there are ways to replace a bad maintainer.
> >> We still try to keep it polite.
> >>
> >> But note that you can't have someone "fired", no matter how bad they
> >> do their job.  A bad maintainer is usually better than none - the bad
> >> maintainer might improve. Or at least get some simple stuff done.
> >>
> >> You therefore replace a bad maintainer by taking over the position.
> >> Contact whoever is above the maintainer (Linus or some other
> >> higher-level maintainer). You explain the problem, and you must also
> >> show that you have the time and knowledge to do a better job.
> >>
> >
> > Hi Helge,
> > A. I do neither have enough skills to take up a maintainers role
> >
> Then your only hope is to find someone else that is interested.
> > B. Linus and Andrew are high-leveled informed about the whole structural
> problem, but they close their eyes, they simply do not want to see the
> necessity of a replacement.
> > That is at least my impression.
> >
> The aren't doing any less than you do. They don't provide a better
> maintainer, but neither do you.   Linus and  Andrew don't have that
> much more resources than you have.  They have programming skills
> and lots of trust in the community.
>
> >> You can, for example, maintain the same subsystem in parallel.  After a
> >> while,
> >> all interested parties sees that your tree works better and that
> >> communicating with you is easier.
> >> If you aren't prepared to do this - then you have to live with the
> current
> >> maintainer.  There is no staff ready to replace maintainers after
> >> complaints, a volunteer doing a better job is always necessary.
> >>
> >
> > Neither nor: I do not livbe with persons like Chehab and others, no matter
> what the consequence is. To be truthful I would strategically prefare a
> vacuum at the price that the work isn't even done for months.
> > ONLY IF there is a personnel vacuum the necessity for others to volunteer
> will arise.
> >
> A sufficiently bad maintainer will also do it.  If lots of submitters send
> their patches to andrew in order to get past a dysfunctional maintainer,
> then the subsystem effectively is unmaintained.
> > So if you want a real change you gotta first kick the reactionary dumb
> bastards off from their seats without any return ticket - without that there
> won't be any changes at all!
> >
> Well then - create a patch to the MAINTAINERS file that removes this
> maintainer
> leaving the position open.  Perhaps you can get that accepted despite the
> existing maintainer - *if* you can get most other developers for that
> subsystem to add signed-off lines.  It will then be clear that the
> community agrees with you.
>
> However, if the bulk of them thinks the current maintainer is fine, then
> it stays that way.  Satisfying everybody is unfortunately not always
> possible.
> You can always try submitting your own patches above this maintainer.
> > But the practice now is the typical "Sit out and do not react at all"
> behaviour as far as Chehab himself is concerned - Germans remember that
> reactionary gesture from the time when Hellmut Kohl was chancellor for 16
> horrible years.....
> >
> > So there will be no "soft" or "polite" solution at all, but only a harsh
> and rude one:
> > "Kick out the Jams!"
> Dropping lazy or incompetent maintainers do happen occationally.
> But don't let frustration lead to angry emails - all you get that way is
> lost
> credibility, that will only make it harder to convince people.
>
> Helge Hafting
> -
> 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/
>


-- 
Markus Rechberger

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 17:04:43 +0200
Von: Helge Hafting <helge.hafting@aitel.hist.no>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, mchehab@infradead.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities

> Uwe Bugla wrote:
> > -------- Original-Nachricht --------
> > Datum: Mon, 30 Apr 2007 13:21:29 +0200
> > Von: Helge Hafting <helge.hafting@aitel.hist.no>
> > An: Uwe Bugla <uwe.bugla@gmx.de>
> > CC: linux-kernel@vger.kernel.org
> > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21
> and	pseudo-authorities
> >
> >   
> >> Uwe Bugla wrote:
> >>     
> >>> In this ten Emails you will yourself see the intellectual and
> technical
> >>>       
> >> proof in how far Mr. Chehab is acting with nothing else but:
> >>     
> >>> a. Lies
> >>> b. Unproven thesis
> >>> c. Stigmatizations
> >>>
> >>> and so on.
> >>>
> >>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
> >>>   
> >>>       
> >> Please note that there are ways to replace a bad maintainer. 
> >> We still try to keep it polite.
> >>
> >> But note that you can't have someone "fired", no matter how bad they
> >> do their job.  A bad maintainer is usually better than none - the bad
> >> maintainer might improve. Or at least get some simple stuff done.
> >>
> >> You therefore replace a bad maintainer by taking over the position. 
> >> Contact whoever is above the maintainer (Linus or some other
> >> higher-level maintainer). You explain the problem, and you must also
> >> show that you have the time and knowledge to do a better job. 
> >>     
> >
> > Hi Helge,
> > A. I do neither have enough skills to take up a maintainers role
> >   
> Then your only hope is to find someone else that is interested.
> > B. Linus and Andrew are high-leveled informed about the whole structural
> problem, but they close their eyes, they simply do not want to see the
> necessity of a replacement.
> > That is at least my impression. 
> >   
> The aren't doing any less than you do. They don't provide a better
> maintainer, but neither do you.   Linus and  Andrew don't have that
> much more resources than you have.  They have programming skills
> and lots of trust in the community.
> 
> >> You can, for example, maintain the same subsystem in parallel.  After a
> >> while,
> >> all interested parties sees that your tree works better and that
> >> communicating with you is easier.
> >> If you aren't prepared to do this - then you have to live with the
> current
> >> maintainer.  There is no staff ready to replace maintainers after
> >> complaints, a volunteer doing a better job is always necessary.
> >>     
> >
> > Neither nor: I do not livbe with persons like Chehab and others, no
> matter what the consequence is. To be truthful I would strategically prefare a
> vacuum at the price that the work isn't even done for months.
> > ONLY IF there is a personnel vacuum the necessity for others to
> volunteer will arise.
> >   
> A sufficiently bad maintainer will also do it.  If lots of submitters send
> their patches to andrew in order to get past a dysfunctional maintainer,
> then the subsystem effectively is unmaintained.
Hi,
False!
I in fact tried the mm-tree strategy, and it in fact worked - until Mauro Chehab started to soap in Andrew Morton's face with some utmost stigmatizing and stuipd rant to build up a "coalition of sit-out".
I know what I have to think about Mauro Carvalho Chehab, and I hate people like him.
And this stinking rotten "Apparatschnik" behaviour (I wouldn't even call this "conservative" as it isn't conservative at all, but simply stinking and rotten, if not to say reactionary) is driving me insane sometimes.....

> > So if you want a real change you gotta first kick the reactionary dumb
> bastards off from their seats without any return ticket - without that there
> won't be any changes at all!
> >   
> Well then - create a patch to the MAINTAINERS file that removes this 
> maintainer
> leaving the position open.  Perhaps you can get that accepted despite the
> existing maintainer - *if* you can get most other developers for that
> subsystem to add signed-off lines.  It will then be clear that the
> community agrees with you.

That sounds very naive, as many people do see the structural problems as they are, but do not build up solidarities leading to real structural changes.
Everyone tries to make the best out of it, and thus the whole thing resembles to a cancer growth scenery: metastase after metastase getting fatter and fatter, not smaller. With real structural problems never resolved, but always delegated or brushed under the carpet to make the own "Apparatschnik" life a lots of more easier.
> 
> However, if the bulk of them thinks the current maintainer is fine, then
> it stays that way.  Satisfying everybody is unfortunately not always 
> possible.
> You can always try submitting your own patches above this maintainer.
NO I CANNOT, if not to say: I tried so often, but in vain!
And some people see through the problems, but aren't ready to take up action.

The biggest problem is to build up majorities, it is almost impossible!

> > But the practice now is the typical "Sit out and do not react at all"
> behaviour as far as Chehab himself is concerned - Germans remember that
> reactionary gesture from the time when Hellmut Kohl was chancellor for 16
> horrible years.....
> >
> > So there will be no "soft" or "polite" solution at all, but only a harsh
> and rude one:
> > "Kick out the Jams!"
> Dropping lazy or incompetent maintainers do happen occationally.
> But don't let frustration lead to angry emails - all you get that way is 
> lost
> credibility, that will only make it harder to convince people.
I know that very much, but I ain't no machine or master in suppressing emotions.
And I have not lost hopes that there will be personal changes at linuxtv.org which are utmost necessary. That's why I keep on fighting....

Cheers
Uwe
> 
> Helge Hafting

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Mauro Carvalho Chehab]

Hi Helge and others,

On Mon, 30 Apr 2007, Helge Hafting wrote:

>> what the consequence is. To be truthful I would strategically prefare a 
>> vacuum at the price that the work isn't even done for months.
>> ONLY IF there is a personnel vacuum the necessity for others to volunteer 
>> will arise.
>> 
> A sufficiently bad maintainer will also do it.  If lots of submitters send
> their patches to andrew in order to get past a dysfunctional maintainer,
> then the subsystem effectively is unmaintained.

The point is that Uwe patch will generate regressions by breaking for 
Twinhan. His patch just removes compilation for dst and dst_ca on Kconfig, 
without taking care or driver internals. So, two initialization functions 
won't be called by symbol_request(). Although those two functions will be 
undefined, as the dvb will do the linkedition at module runtume (if 
DVB_ATTACH is selected), modprobe won't detect the lack of those functions.
At the end, cards with ST chips (DST and/or DST CA) will stop working, 
without even printing a warning.

I've tried to explain this to Uwe several times, but, at the end, he 
always start insulting me and/or other developers.

Cheers,
Mauro.

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 17:56:17 +0100 (BST)
Von: Mauro Carvalho Chehab <mchehab@infradead.org>
An: Helge Hafting <helge.hafting@aitel.hist.no>
CC: Uwe Bugla <uwe.bugla@gmx.de>, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> Hi Helge and others,
> 
> On Mon, 30 Apr 2007, Helge Hafting wrote:
> 
> >> what the consequence is. To be truthful I would strategically prefare a
> >> vacuum at the price that the work isn't even done for months.
> >> ONLY IF there is a personnel vacuum the necessity for others to
> volunteer 
> >> will arise.
> >> 
> > A sufficiently bad maintainer will also do it.  If lots of submitters
> send
> > their patches to andrew in order to get past a dysfunctional maintainer,
> > then the subsystem effectively is unmaintained.
> 
> The point is that Uwe patch will generate regressions by breaking for 
> Twinhan. His patch just removes compilation for dst and dst_ca on Kconfig,
> without taking care or driver internals. So, two initialization functions 
> won't be called by symbol_request(). Although those two functions will be 
> undefined, as the dvb will do the linkedition at module runtume (if 
> DVB_ATTACH is selected), modprobe won't detect the lack of those
> functions.
> At the end, cards with ST chips (DST and/or DST CA) will stop working, 
> without even printing a warning.

Mister Chehab, for the first and for the utmost last time now:

My deselection patch implies a very good text to strongly discourage the use of DST
and DST_CA in case someone does not know what he or she is doing. In so far the case that "cards with ST chips (DST and/ or DST CA) will stop working" will not happen at all.
This patch IS NOT DONE TO MAKE ANY DST OR DST_CA MODULE REQUIRING CARD WORK - 
THIS IS YOUR PART OF SO-CALLED LOGIC!!!!

THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL!!!!

Example: Pinnacle PCTV SAT!!!

And once again and for the last time:

I did not manage to at least find one single unresolved module during compilation, and I have been working with this almost fantastic solution with several kernels for months now!

Above that I gave you every proof one can ever give: You received dmesg, you received configs, you received proven thesis, you received everything.

It would really be a perfect solution to bomb away the almost incredible meters thick wall in front of your head and your eyes.

And at this time I will stop responding to your mails - I got enough of you!!!
It's enough!!
> 
> I've tried to explain this to Uwe several times, but, at the end, he 
> always start insulting me and/or other developers.
> 
> Cheers,
> Mauro.

Happy reflection, Mister Chehab!!!!!

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Linus Torvalds]

Uwe, you just made my kill-list.

I've not actually done that in _years_. So you can feel proud. Your emails 
will get automatically filtered to their own (ignored) folder. I told you 
why, and you didn't seem to understand at all.

		Linus

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 11:04:36 -0700 (PDT)
Von: Linus Torvalds <torvalds@linux-foundation.org>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>, helge.hafting@aitel.hist.no, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-dvb@linuxtv.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> 
> 
> Uwe, you just made my kill-list.
> 
> I've not actually done that in _years_. So you can feel proud. Your emails
> will get automatically filtered to their own (ignored) folder. I told you 
> why, and you didn't seem to understand at all.
> 
> 		Linus
Wrong, but understandable reaction. But I have found somebody to help me to get this thing solved - in so far: counterproductive from your side!

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Andrew Morton]

On Mon, 30 Apr 2007 19:25:47 +0200
"Uwe Bugla" <uwe.bugla@gmx.de> wrote:

> I did not manage to at least find one single unresolved module during compilation, and I have been working with this almost fantastic solution with several kernels for months now!

That isn't what Mauro is saying.  What he is saying is that the missing
symbols will not be reported at build time.  The kernel will all link
correctly and will appear to load modules correctly.

See, there's a third mechanism for symbol resolution which is used at
runtime, not at build time: symbol_request().

What Mauro is saying is that these changes will cause symbol_request() to
return different results on some people's setups with different hardware,
causing those setups to fail.

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 11:14:14 -0700
Von: Andrew Morton <akpm@linux-foundation.org>
An: "Uwe Bugla" <uwe.bugla@gmx.de>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>, helge.hafting@aitel.hist.no, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, linux-dvb@linuxtv.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> On Mon, 30 Apr 2007 19:25:47 +0200
> "Uwe Bugla" <uwe.bugla@gmx.de> wrote:
> 
> > I did not manage to at least find one single unresolved module during
> compilation, and I have been working with this almost fantastic solution with
> several kernels for months now!
> 
> That isn't what Mauro is saying.  What he is saying is that the missing
> symbols will not be reported at build time.  The kernel will all link
> correctly and will appear to load modules correctly.
> 
> See, there's a third mechanism for symbol resolution which is used at
> runtime, not at build time: symbol_request().
> 
> What Mauro is saying is that these changes will cause symbol_request() to
> return different results on some people's setups with different hardware,
> causing those setups to fail.

Hi Andrew,
But, even if this is the case, it should be transparent WHAT DIFFERENT HARDWARE
IS MEANT EXACTLY! DST AND DST_CA CANNOT BE MEANT - this I have made quite shure!

I swear I did not notice any errors - so as long as I cannot see through where the problem is, and as long as I have been working with my patches without the slightest noise for months now - where should I apply some additions then?

See, there's a third mechanism for symbol resolution which is used at
runtime, not at build time: symbol_request().

If this symbol_request() appears at runtime, then there should be some feedback in dmesg or any other kind of syslog.

But I swear I haven't seen any kind of bad or counterproductive messages like this!
My system runs excelent with my patches - so why should I care?

I meanwhile have sent my patches to someone, he will have a look at them - and we all will see what happens then.

Above that I will at least try to enhance those two patches by a dvb-pll.c deselection feature which I said very politely to Trent that I am missing it.

And I want to get out now of that horrible discussion - I am exhausted.

Cheers
Uwe

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Jan Engelhardt]

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?


Jan
-- 

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Markus Rechberger]

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Thomas Gleixner]

Uwe,

On Mon, 2007-04-30 at 13:02 +0200, Uwe Bugla wrote:
> > stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness,
> > wrong solidarity, kiddishness and technical incompetence.
...
> > soap in Andrew Morton's face with this enourmous threat of incompetence,
> > kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness,
> > lack of experience, pre-pubertarian behaviour, fascistoid opinion
> > dictatorship as part of a deep immature anti-democratic and reactionary personality
> > structure.
...
> > > then this is nothing but a gesture full of lies (somehow typical for
> > this Brazilian fascistoid opinion block head dictator), but it simply shows
...
> > does obey to such a stupid reactionary idiot and let his face soap in by
> > this dirty Brazilian hypocrite instead of giving contributions at least a
...
> > is nothing but a real personified ape or disease.
...
> betwwen stupid Chehab and me about my almost excellent dst-deselection patch contributions.
...
> I swear I never stumbled over such an utomst stubborn, stupid and
> horrible idiot in my whole year lasting Linux experience, and I
> thought I could not trust my eyes when I saw what incredible crap work
> was pushed into mainline by the signature of this
> incredible and horrible team chief from Brazil.

what do you want to achieve with these disgusting and annoying ad
hominem attacks ? 

You disqualify yourself with your outrageous and embarrassing rants. Do
you really believe that your behaviour is in any way competent, grown up
and appropriate ? 

Before you accuse others of missing human skills, you might go and check
your own.

Welcome to my killfile.

	tglx

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Markus Rechberger]

On 4/30/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
>
> -------- Original-Nachricht --------
> Datum: Mon, 30 Apr 2007 02:58:33 +0200
> Von: hermann pitton <hermann-pitton@arcor.de>
> An: Uwe Bugla <uwe.bugla@gmx.de>
> CC: Linus Torvalds <torvalds@linux-foundation.org>, mkruky@linuxtv.org,
> akpm@linux-foundation.org, linux-dvb@linuxtv.org,
> linux-kernel@vger.kernel.org
> Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21
> and	pseudo-authorities
>
> > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
> > > -------- Original-Nachricht --------
> > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> > > Von: Linus Torvalds <torvalds@linux-foundation.org>
> > > An: Uwe Bugla <uwe.bugla@gmx.de>
> > > CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org, mchehab@infradead.org,
> > linux-kernel@vger.kernel.org, akpm@linux-foundation.org
> > > Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities
> > >
> > > >
> > > >
> > > > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > > >
> > > > > I have been trying diff and other tools in various variants (except
> > > > > git-bisect that I cannot handle because I do not understand the
> > practice
> > > > > of it).
> > > >
> > > > git bisect is _really_ simple if you already have a git tree anyway.
> > And
> > > > even if you don't, getting one isn't really hard either. Just do
> > > >
> > > > 	git clone
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > linux-2.6
> > > >
> > > > and you have a tree (it will take a little while - it's going to
> > dowload
> > > > about 170MB or so of stuff, so the initial clone is going to be a bit
> > > > painful unless you have a fast internet connection).
> > > >
> > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for you,
> > it's
> > > > really as easy as just saying
> > > >
> > > > 	git bisect start
> > > > 	git bisect good v2.6.21-rc7
> > > > 	git bisect bad v2.6.21
> > > >
> > > > and git will think for a short while (most of the time is going to be
> > > > checking out the new tree) and give you a tree to test.
> > > >
> > > > Just build, boot, and test that tree.
> > > >
> > > > If it was fine, do
> > > >
> > > > 	git bisect good
> > > >
> > > > and git will pick a new tree to test. And if it wasn't, instead just
> > do
> > > > "git bisect bad", and git will pick _another_ version to test. Do this
> > a
> > > > few times, and git will tell you which commit introduced them.
> > > >
> > > > There were just 125 commits in between 2.6.21-rc7 and the final one,
> > so it
> > > > should be quite quick - bisection basically does a binary search, so
> > doing
> > > > seven reboots should have you with the result.
> > > >
> > > > The fact that it already works in 2.6.21-git2 obviously means that _I_
> > end
> > > > up being less interested, but the -stable tree people would love to
> > hear
> > > > what broke!
> > >
> > > Hi again Linus,
> > > my deep thanks for your excellent explication of git-bisect.
> > > But I unfortunately owe a 100Kbit flatrate, and so downloading some 170
> > MB git tree will need the time amount of one entire night (11.5 kb /s if I
> > am lucky - no more).
> > > Just to take up a different approach:
> > >
> > > The difference between 2.6.21-rc7 and 2.6.21 official does not play any
> > role at all.
> > >
> > > On the other hand I found out that:
> > > 2.6.21-rc7 made my AMD K7 router work fine
> > > 2.6.21 official hung my AMD K7 router up
> > > 2.6.21-git1 hung my AMD K7 router up
> > > 2.6.21-git2 made my AMD K7 router work.
> > >
> > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves
> > the problem.
> > > Or am I saying something wrong as far as logical terms are concerned?
> > >
> > > >
> > > > > I like small and effective kernels instead of blown up RAM waste.
> > > > > This is no Windoze, man, this is Linux!
> > > >
> > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get
> > anywhere
> > > > at all.
> > > >
> > > > This is Linux, not Windows. But that also means that those developers
> > that
> > > > you denigrate aren't getting paid by you, and if you don't show them
> > > > respect, they'll totally ignore you.
> > > >
> > > > 		Linus
> > >
> > > Now this is the old problem about it all: the hypocricy factor, the
> > utmost small, if not to say pre-pubertarian character plus some other
> obviously
> > counter-productive character traits in those so-called "maintainers" who
> > behave like kids, but not like grown-ups at all!
> > > Not only you, but also Andrew perfectly and willingly step into the
> > hypocritic trap and do not even feel that they are trapped!
> > >
> > > For the majority of all cases of the so-called "maintainer personnel" at
> > linuxtv.org the statement of some missing "politeness" or some missing
> > "respect" is nothing but an utmost dumb, kiddish, human mediocre and
> utmost
> > stupid and utmost hypocritic excuse for bare naked incompatibility,
> dumbness,
> > wrong solidarity, kiddishness and technical incompetence.
> > >
> > > They are building up pseudo-authorities to hide their lack of
> > competence, no matter if their lack of competence funds on technical or
> human lacks.
> > > And at least the Brazilian Mauro Carvalho Chehab does go even so far to
> > soap in Andrew Morton's face with this enourmous threat of incompetence,
> > kiddishness, incompatibility, hypocricy, lies, stigmatisations,
> stubbornness,
> > lack of experience, pre-pubertarian behaviour, fascistoid opinion
> > dictatorship as part of a deep immature anti-democratic and reactionary
> personality
> > structure.
> > >
> > > Would you call Mauro Carvalho Chehab a maintainer!
> > > I can certify you that I cannot, even if I try. And I want him to be
> > substituted as quick as possible as he is the biggest mismatch of
> gatekeeper
> > one can ever imagine.
> > >
> > > And it is not only me personally perceiving this that there are people
> > missing who can go upright and offer sophisticated and good work.
> > > Plus a real sophisticated discussion behaviour, in technical and in
> > human terms.
> > > Going upright is thus far away from the behaviour NOT to be able to
> > tolerate any criticism at all.
> > >
> > > Solution: This whole new quite young linuxtv.org team is missing a real
> > grown up and experienced team leader. Not only that is definitely too much
> > for Mauro Carvalho Chehab. That is the pain - the consistence of the whole
> > group is the pain, that's all. Too young, too many lacks of human skills,
> > and missing an appropriate team leader.............
> > >
> > > So, if I show respect or not, or if I show politeness or not will never
> > change the whole structural situation at all, as great parts of the whole
> > team is a disease:
> > > 1. By Chehab being the team leader the whole fish stinks from the head
> > startup.
> > > Solution: Substitution of Mauro Carvalho Chehab as quick as possible -
> > even quicker than a storm!
> > > 2. By Krufky being one part of it, doing good work, but executing wrong
> > solidarities by his bowing behaviour towards pseudo-authorities although
> he
> > knows better at least technically this is a question of wrong or right
> > leadership, nothing else
> > > 3. By Abraham offering us great ranting aims that never are being put
> > into practice out of certified missing human skills and missing technical
> > knowledge (the four completely unusable 2.6 kernels were never apologized
> by
> > himself) urgent substitution  is utmost necessary.
> > >
> > > CLEARER: If anyone of the people knowing the deeper context claims those
> > "gatekeeper methods" to be a consequence of missing "respect" or missing
> > "politeness" then those people are either strictly dumb and superficial,
> or
> > they owe a gesture that I would call a "Well, I know, but I do not want to
> > see what's going on"-disease, nothing else.
> > >
> > > Another term to describe the latter would be "bureaucratic lamb head
> > behaviour".
> > >
> > > See, Linus, if for instance Andrew Morton mails me some statement from
> > that Chehab going: "Again, do not take the patches from Uwe - he is always
> > regarding things through his personal prisma, and the rest he simply does
> > not perceive at all"
> > >
> > > then this is nothing but a gesture full of lies (somehow typical for
> > this Brazilian fascistoid opinion block head dictator), but it simply
> shows
> > that the linuxtv.org teamleader is a horrible mismatch, nothing else!
> > >
> > > His mediocrity and dumbness simply defines through the fact that he is
> > using stigmatizations very soon in a so-called "discussion" because he
> > misses
> > > a. human skills
> > > b. technical proven arguments and theses
> > > c. enough experience, human or technical one.
> > >
> > > And the biggest threat and shame is the proven fact that Andrew Morton
> > does obey to such a stupid reactionary idiot and let his face soap in by
> > this dirty Brazilian hypocrite instead of giving contributions at least a
> > chance through his mm-tree.
> > >
> > > So there are exactly two solutions:
> > > 1. Andrew Morton should not obey to Chehab anymore and be real open
> > > 2. Chehab and Abraham should be substituted as quick as possible without
> > any hesitation in no way!!!!
> > >
> > > The one that got to be fired with the most urgent priority is called
> > Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper, but
> this
> > is nothing but a real personified ape or disease.
> > >
> > > And the argument whether those people are paid for their work or not is
> > exactly as important as if a sack of rice falls down somewhere in
> > capitalist China or not.....
> > > OBSOLETE!!!
> > >
> > > Yours sincerely
> > > Uwe
> > >
> >
> > If eventually somebody thinks this kind of stuff could be helpful,
> > please say so and give us some pointers.
> >
> > Hermann
> >
> Hi Hermann,
>
> now if you are searching for helpful stuff I can make public a ten Emails
> ping pong
> betwwen stupid Chehab and me about my almost excellent dst-deselection patch
> contributions.
>
> In this ten Emails you will yourself see the intellectual and technical
> proof in how far Mr. Chehab is acting with nothing else but:
>
> a. Lies
> b. Unproven thesis
> c. Stigmatizations
>
> and so on.
>
> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
>
> That's it what I cannot live with!
> I swear I never stumbled over such an utomst stubborn, stupid and horrible
> idiot in my whole year lasting Linux experience, and I thought I could not
> trust my eyes when I saw what incredible crap work was pushed into mainline
> by the signature of this
> incredible and horrible team chief from Brazil.
>
> If you want to see the Emails, just ask me and I will forward them with a
> couple of CCs. They will show the truth about the real consistence of this
> "maintainer leader".
>

Uwe,

which patches do you refer to?
Can you submit a list of your patches which got no attention (I'm only
interested in the patches, not in discussions you had)

Markus

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 13:48:34 +0200
Von: "Markus Rechberger" <mrechberger@gmail.com>
An: "Uwe Bugla" <uwe.bugla@gmx.de>
CC: "hermann pitton" <hermann-pitton@arcor.de>, mkruky@linuxtv.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> On 4/30/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
> >
> > -------- Original-Nachricht --------
> > Datum: Mon, 30 Apr 2007 02:58:33 +0200
> > Von: hermann pitton <hermann-pitton@arcor.de>
> > An: Uwe Bugla <uwe.bugla@gmx.de>
> > CC: Linus Torvalds <torvalds@linux-foundation.org>, mkruky@linuxtv.org,
> > akpm@linux-foundation.org, linux-dvb@linuxtv.org,
> > linux-kernel@vger.kernel.org
> > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21
> > and	pseudo-authorities
> >
> > > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
> > > > -------- Original-Nachricht --------
> > > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> > > > Von: Linus Torvalds <torvalds@linux-foundation.org>
> > > > An: Uwe Bugla <uwe.bugla@gmx.de>
> > > > CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org,
> mchehab@infradead.org,
> > > linux-kernel@vger.kernel.org, akpm@linux-foundation.org
> > > > Betreff: Re: Critical points about kernel 2.6.21 and
> pseudo-authorities
> > > >
> > > > >
> > > > >
> > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > > > >
> > > > > > I have been trying diff and other tools in various variants
> (except
> > > > > > git-bisect that I cannot handle because I do not understand the
> > > practice
> > > > > > of it).
> > > > >
> > > > > git bisect is _really_ simple if you already have a git tree
> anyway.
> > > And
> > > > > even if you don't, getting one isn't really hard either. Just do
> > > > >
> > > > > 	git clone
> > > > >
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > > linux-2.6
> > > > >
> > > > > and you have a tree (it will take a little while - it's going to
> > > dowload
> > > > > about 170MB or so of stuff, so the initial clone is going to be a
> bit
> > > > > painful unless you have a fast internet connection).
> > > > >
> > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for
> you,
> > > it's
> > > > > really as easy as just saying
> > > > >
> > > > > 	git bisect start
> > > > > 	git bisect good v2.6.21-rc7
> > > > > 	git bisect bad v2.6.21
> > > > >
> > > > > and git will think for a short while (most of the time is going to
> be
> > > > > checking out the new tree) and give you a tree to test.
> > > > >
> > > > > Just build, boot, and test that tree.
> > > > >
> > > > > If it was fine, do
> > > > >
> > > > > 	git bisect good
> > > > >
> > > > > and git will pick a new tree to test. And if it wasn't, instead
> just
> > > do
> > > > > "git bisect bad", and git will pick _another_ version to test. Do
> this
> > > a
> > > > > few times, and git will tell you which commit introduced them.
> > > > >
> > > > > There were just 125 commits in between 2.6.21-rc7 and the final
> one,
> > > so it
> > > > > should be quite quick - bisection basically does a binary search,
> so
> > > doing
> > > > > seven reboots should have you with the result.
> > > > >
> > > > > The fact that it already works in 2.6.21-git2 obviously means that
> _I_
> > > end
> > > > > up being less interested, but the -stable tree people would love
> to
> > > hear
> > > > > what broke!
> > > >
> > > > Hi again Linus,
> > > > my deep thanks for your excellent explication of git-bisect.
> > > > But I unfortunately owe a 100Kbit flatrate, and so downloading some
> 170
> > > MB git tree will need the time amount of one entire night (11.5 kb /s
> if I
> > > am lucky - no more).
> > > > Just to take up a different approach:
> > > >
> > > > The difference between 2.6.21-rc7 and 2.6.21 official does not play
> any
> > > role at all.
> > > >
> > > > On the other hand I found out that:
> > > > 2.6.21-rc7 made my AMD K7 router work fine
> > > > 2.6.21 official hung my AMD K7 router up
> > > > 2.6.21-git1 hung my AMD K7 router up
> > > > 2.6.21-git2 made my AMD K7 router work.
> > > >
> > > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously
> solves
> > > the problem.
> > > > Or am I saying something wrong as far as logical terms are
> concerned?
> > > >
> > > > >
> > > > > > I like small and effective kernels instead of blown up RAM
> waste.
> > > > > > This is no Windoze, man, this is Linux!
> > > > >
> > > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get
> > > anywhere
> > > > > at all.
> > > > >
> > > > > This is Linux, not Windows. But that also means that those
> developers
> > > that
> > > > > you denigrate aren't getting paid by you, and if you don't show
> them
> > > > > respect, they'll totally ignore you.
> > > > >
> > > > > 		Linus
> > > >
> > > > Now this is the old problem about it all: the hypocricy factor, the
> > > utmost small, if not to say pre-pubertarian character plus some other
> > obviously
> > > counter-productive character traits in those so-called "maintainers"
> who
> > > behave like kids, but not like grown-ups at all!
> > > > Not only you, but also Andrew perfectly and willingly step into the
> > > hypocritic trap and do not even feel that they are trapped!
> > > >
> > > > For the majority of all cases of the so-called "maintainer
> personnel" at
> > > linuxtv.org the statement of some missing "politeness" or some missing
> > > "respect" is nothing but an utmost dumb, kiddish, human mediocre and
> > utmost
> > > stupid and utmost hypocritic excuse for bare naked incompatibility,
> > dumbness,
> > > wrong solidarity, kiddishness and technical incompetence.
> > > >
> > > > They are building up pseudo-authorities to hide their lack of
> > > competence, no matter if their lack of competence funds on technical
> or
> > human lacks.
> > > > And at least the Brazilian Mauro Carvalho Chehab does go even so far
> to
> > > soap in Andrew Morton's face with this enourmous threat of
> incompetence,
> > > kiddishness, incompatibility, hypocricy, lies, stigmatisations,
> > stubbornness,
> > > lack of experience, pre-pubertarian behaviour, fascistoid opinion
> > > dictatorship as part of a deep immature anti-democratic and
> reactionary
> > personality
> > > structure.
> > > >
> > > > Would you call Mauro Carvalho Chehab a maintainer!
> > > > I can certify you that I cannot, even if I try. And I want him to be
> > > substituted as quick as possible as he is the biggest mismatch of
> > gatekeeper
> > > one can ever imagine.
> > > >
> > > > And it is not only me personally perceiving this that there are
> people
> > > missing who can go upright and offer sophisticated and good work.
> > > > Plus a real sophisticated discussion behaviour, in technical and in
> > > human terms.
> > > > Going upright is thus far away from the behaviour NOT to be able to
> > > tolerate any criticism at all.
> > > >
> > > > Solution: This whole new quite young linuxtv.org team is missing a
> real
> > > grown up and experienced team leader. Not only that is definitely too
> much
> > > for Mauro Carvalho Chehab. That is the pain - the consistence of the
> whole
> > > group is the pain, that's all. Too young, too many lacks of human
> skills,
> > > and missing an appropriate team leader.............
> > > >
> > > > So, if I show respect or not, or if I show politeness or not will
> never
> > > change the whole structural situation at all, as great parts of the
> whole
> > > team is a disease:
> > > > 1. By Chehab being the team leader the whole fish stinks from the
> head
> > > startup.
> > > > Solution: Substitution of Mauro Carvalho Chehab as quick as possible
> -
> > > even quicker than a storm!
> > > > 2. By Krufky being one part of it, doing good work, but executing
> wrong
> > > solidarities by his bowing behaviour towards pseudo-authorities
> although
> > he
> > > knows better at least technically this is a question of wrong or right
> > > leadership, nothing else
> > > > 3. By Abraham offering us great ranting aims that never are being
> put
> > > into practice out of certified missing human skills and missing
> technical
> > > knowledge (the four completely unusable 2.6 kernels were never
> apologized
> > by
> > > himself) urgent substitution  is utmost necessary.
> > > >
> > > > CLEARER: If anyone of the people knowing the deeper context claims
> those
> > > "gatekeeper methods" to be a consequence of missing "respect" or
> missing
> > > "politeness" then those people are either strictly dumb and
> superficial,
> > or
> > > they owe a gesture that I would call a "Well, I know, but I do not
> want to
> > > see what's going on"-disease, nothing else.
> > > >
> > > > Another term to describe the latter would be "bureaucratic lamb head
> > > behaviour".
> > > >
> > > > See, Linus, if for instance Andrew Morton mails me some statement
> from
> > > that Chehab going: "Again, do not take the patches from Uwe - he is
> always
> > > regarding things through his personal prisma, and the rest he simply
> does
> > > not perceive at all"
> > > >
> > > > then this is nothing but a gesture full of lies (somehow typical for
> > > this Brazilian fascistoid opinion block head dictator), but it simply
> > shows
> > > that the linuxtv.org teamleader is a horrible mismatch, nothing else!
> > > >
> > > > His mediocrity and dumbness simply defines through the fact that he
> is
> > > using stigmatizations very soon in a so-called "discussion" because he
> > > misses
> > > > a. human skills
> > > > b. technical proven arguments and theses
> > > > c. enough experience, human or technical one.
> > > >
> > > > And the biggest threat and shame is the proven fact that Andrew
> Morton
> > > does obey to such a stupid reactionary idiot and let his face soap in
> by
> > > this dirty Brazilian hypocrite instead of giving contributions at
> least a
> > > chance through his mm-tree.
> > > >
> > > > So there are exactly two solutions:
> > > > 1. Andrew Morton should not obey to Chehab anymore and be real open
> > > > 2. Chehab and Abraham should be substituted as quick as possible
> without
> > > any hesitation in no way!!!!
> > > >
> > > > The one that got to be fired with the most urgent priority is called
> > > Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper,
> but
> > this
> > > is nothing but a real personified ape or disease.
> > > >
> > > > And the argument whether those people are paid for their work or not
> is
> > > exactly as important as if a sack of rice falls down somewhere in
> > > capitalist China or not.....
> > > > OBSOLETE!!!
> > > >
> > > > Yours sincerely
> > > > Uwe
> > > >
> > >
> > > If eventually somebody thinks this kind of stuff could be helpful,
> > > please say so and give us some pointers.
> > >
> > > Hermann
> > >
> > Hi Hermann,
> >
> > now if you are searching for helpful stuff I can make public a ten
> Emails
> > ping pong
> > betwwen stupid Chehab and me about my almost excellent dst-deselection
> patch
> > contributions.
> >
> > In this ten Emails you will yourself see the intellectual and technical
> > proof in how far Mr. Chehab is acting with nothing else but:
> >
> > a. Lies
> > b. Unproven thesis
> > c. Stigmatizations
> >
> > and so on.
> >
> > THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
> >
> > That's it what I cannot live with!
> > I swear I never stumbled over such an utomst stubborn, stupid and
> horrible
> > idiot in my whole year lasting Linux experience, and I thought I could
> not
> > trust my eyes when I saw what incredible crap work was pushed into
> mainline
> > by the signature of this
> > incredible and horrible team chief from Brazil.
> >
> > If you want to see the Emails, just ask me and I will forward them with
> a
> > couple of CCs. They will show the truth about the real consistence of
> this
> > "maintainer leader".
> >
> 
> Uwe,
> 
> which patches do you refer to?
> Can you submit a list of your patches which got no attention (I'm only
> interested in the patches, not in discussions you had)
> 
> Markus

Hi Markus,
a thousands of thanks for your friendly response - very nice! What a pleasure!

I do not send in the two patches for one more time. I have sent them in so often!
If you take a closer look at the mailing list you will easily find them.

One is a docu fix, and the other one, causing so much trouble out of nothing but Chehab's stubbornness and incompetence, is the one that makes the two DST modules
deselectable (i. e. DST itself for TwinHan DST and clones plus DST_CA for TwinHan cards with CA slot and Pinnacle PCTV SAT cards with CI extension for example).

Chehab told me some crap about unresolved symbols which never existed as this second patch just runs fine.
I also did not miss any warning lines in the deselection menu that I programmed and I can swear I definitely missed no chance to convince Chehab and others that my patches are close to being real perfect! IN VAIN!

So, if you do not find my patches on the mailing list or if there are any questions as far as what concerns that issue please feel free to ask me as I believe that you are really open-minded towards that.

Above that I want to confirm the utmost necessity to rip Trent Piepho's regressive work out of 2.6.21-git2 as it is in fact technically the most regressive and reactionary crap that I ever have seen......

So please Linus - rip that crap out of 2.6.21-git2. And if you do see questions what parts you need to rip out, please feel free to ask me....

Cheers
Uwe

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Markus Rechberger]

On 4/30/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
>
> -------- Original-Nachricht --------
> Datum: Mon, 30 Apr 2007 13:48:34 +0200
> Von: "Markus Rechberger" <mrechberger@gmail.com>
> An: "Uwe Bugla" <uwe.bugla@gmx.de>
> CC: "hermann pitton" <hermann-pitton@arcor.de>, mkruky@linuxtv.org,
> akpm@linux-foundation.org, torvalds@linux-foundation.org,
> linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
> Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and
> pseudo-authorities
>
> > On 4/30/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
> > >
> > > -------- Original-Nachricht --------
> > > Datum: Mon, 30 Apr 2007 02:58:33 +0200
> > > Von: hermann pitton <hermann-pitton@arcor.de>
> > > An: Uwe Bugla <uwe.bugla@gmx.de>
> > > CC: Linus Torvalds <torvalds@linux-foundation.org>, mkruky@linuxtv.org,
> > > akpm@linux-foundation.org, linux-dvb@linuxtv.org,
> > > linux-kernel@vger.kernel.org
> > > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21
> > > and	pseudo-authorities
> > >
> > > > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
> > > > > -------- Original-Nachricht --------
> > > > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> > > > > Von: Linus Torvalds <torvalds@linux-foundation.org>
> > > > > An: Uwe Bugla <uwe.bugla@gmx.de>
> > > > > CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org,
> > mchehab@infradead.org,
> > > > linux-kernel@vger.kernel.org, akpm@linux-foundation.org
> > > > > Betreff: Re: Critical points about kernel 2.6.21 and
> > pseudo-authorities
> > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > > > > >
> > > > > > > I have been trying diff and other tools in various variants
> > (except
> > > > > > > git-bisect that I cannot handle because I do not understand the
> > > > practice
> > > > > > > of it).
> > > > > >
> > > > > > git bisect is _really_ simple if you already have a git tree
> > anyway.
> > > > And
> > > > > > even if you don't, getting one isn't really hard either. Just do
> > > > > >
> > > > > > 	git clone
> > > > > >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > > > linux-2.6
> > > > > >
> > > > > > and you have a tree (it will take a little while - it's going to
> > > > dowload
> > > > > > about 170MB or so of stuff, so the initial clone is going to be a
> > bit
> > > > > > painful unless you have a fast internet connection).
> > > > > >
> > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for
> > you,
> > > > it's
> > > > > > really as easy as just saying
> > > > > >
> > > > > > 	git bisect start
> > > > > > 	git bisect good v2.6.21-rc7
> > > > > > 	git bisect bad v2.6.21
> > > > > >
> > > > > > and git will think for a short while (most of the time is going to
> > be
> > > > > > checking out the new tree) and give you a tree to test.
> > > > > >
> > > > > > Just build, boot, and test that tree.
> > > > > >
> > > > > > If it was fine, do
> > > > > >
> > > > > > 	git bisect good
> > > > > >
> > > > > > and git will pick a new tree to test. And if it wasn't, instead
> > just
> > > > do
> > > > > > "git bisect bad", and git will pick _another_ version to test. Do
> > this
> > > > a
> > > > > > few times, and git will tell you which commit introduced them.
> > > > > >
> > > > > > There were just 125 commits in between 2.6.21-rc7 and the final
> > one,
> > > > so it
> > > > > > should be quite quick - bisection basically does a binary search,
> > so
> > > > doing
> > > > > > seven reboots should have you with the result.
> > > > > >
> > > > > > The fact that it already works in 2.6.21-git2 obviously means that
> > _I_
> > > > end
> > > > > > up being less interested, but the -stable tree people would love
> > to
> > > > hear
> > > > > > what broke!
> > > > >
> > > > > Hi again Linus,
> > > > > my deep thanks for your excellent explication of git-bisect.
> > > > > But I unfortunately owe a 100Kbit flatrate, and so downloading some
> > 170
> > > > MB git tree will need the time amount of one entire night (11.5 kb /s
> > if I
> > > > am lucky - no more).
> > > > > Just to take up a different approach:
> > > > >
> > > > > The difference between 2.6.21-rc7 and 2.6.21 official does not play
> > any
> > > > role at all.
> > > > >
> > > > > On the other hand I found out that:
> > > > > 2.6.21-rc7 made my AMD K7 router work fine
> > > > > 2.6.21 official hung my AMD K7 router up
> > > > > 2.6.21-git1 hung my AMD K7 router up
> > > > > 2.6.21-git2 made my AMD K7 router work.
> > > > >
> > > > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously
> > solves
> > > > the problem.
> > > > > Or am I saying something wrong as far as logical terms are
> > concerned?
> > > > >
> > > > > >
> > > > > > > I like small and effective kernels instead of blown up RAM
> > waste.
> > > > > > > This is no Windoze, man, this is Linux!
> > > > > >
> > > > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get
> > > > anywhere
> > > > > > at all.
> > > > > >
> > > > > > This is Linux, not Windows. But that also means that those
> > developers
> > > > that
> > > > > > you denigrate aren't getting paid by you, and if you don't show
> > them
> > > > > > respect, they'll totally ignore you.
> > > > > >
> > > > > > 		Linus
> > > > >
> > > > > Now this is the old problem about it all: the hypocricy factor, the
> > > > utmost small, if not to say pre-pubertarian character plus some other
> > > obviously
> > > > counter-productive character traits in those so-called "maintainers"
> > who
> > > > behave like kids, but not like grown-ups at all!
> > > > > Not only you, but also Andrew perfectly and willingly step into the
> > > > hypocritic trap and do not even feel that they are trapped!
> > > > >
> > > > > For the majority of all cases of the so-called "maintainer
> > personnel" at
> > > > linuxtv.org the statement of some missing "politeness" or some missing
> > > > "respect" is nothing but an utmost dumb, kiddish, human mediocre and
> > > utmost
> > > > stupid and utmost hypocritic excuse for bare naked incompatibility,
> > > dumbness,
> > > > wrong solidarity, kiddishness and technical incompetence.
> > > > >
> > > > > They are building up pseudo-authorities to hide their lack of
> > > > competence, no matter if their lack of competence funds on technical
> > or
> > > human lacks.
> > > > > And at least the Brazilian Mauro Carvalho Chehab does go even so far
> > to
> > > > soap in Andrew Morton's face with this enourmous threat of
> > incompetence,
> > > > kiddishness, incompatibility, hypocricy, lies, stigmatisations,
> > > stubbornness,
> > > > lack of experience, pre-pubertarian behaviour, fascistoid opinion
> > > > dictatorship as part of a deep immature anti-democratic and
> > reactionary
> > > personality
> > > > structure.
> > > > >
> > > > > Would you call Mauro Carvalho Chehab a maintainer!
> > > > > I can certify you that I cannot, even if I try. And I want him to be
> > > > substituted as quick as possible as he is the biggest mismatch of
> > > gatekeeper
> > > > one can ever imagine.
> > > > >
> > > > > And it is not only me personally perceiving this that there are
> > people
> > > > missing who can go upright and offer sophisticated and good work.
> > > > > Plus a real sophisticated discussion behaviour, in technical and in
> > > > human terms.
> > > > > Going upright is thus far away from the behaviour NOT to be able to
> > > > tolerate any criticism at all.
> > > > >
> > > > > Solution: This whole new quite young linuxtv.org team is missing a
> > real
> > > > grown up and experienced team leader. Not only that is definitely too
> > much
> > > > for Mauro Carvalho Chehab. That is the pain - the consistence of the
> > whole
> > > > group is the pain, that's all. Too young, too many lacks of human
> > skills,
> > > > and missing an appropriate team leader.............
> > > > >
> > > > > So, if I show respect or not, or if I show politeness or not will
> > never
> > > > change the whole structural situation at all, as great parts of the
> > whole
> > > > team is a disease:
> > > > > 1. By Chehab being the team leader the whole fish stinks from the
> > head
> > > > startup.
> > > > > Solution: Substitution of Mauro Carvalho Chehab as quick as possible
> > -
> > > > even quicker than a storm!
> > > > > 2. By Krufky being one part of it, doing good work, but executing
> > wrong
> > > > solidarities by his bowing behaviour towards pseudo-authorities
> > although
> > > he
> > > > knows better at least technically this is a question of wrong or right
> > > > leadership, nothing else
> > > > > 3. By Abraham offering us great ranting aims that never are being
> > put
> > > > into practice out of certified missing human skills and missing
> > technical
> > > > knowledge (the four completely unusable 2.6 kernels were never
> > apologized
> > > by
> > > > himself) urgent substitution  is utmost necessary.
> > > > >
> > > > > CLEARER: If anyone of the people knowing the deeper context claims
> > those
> > > > "gatekeeper methods" to be a consequence of missing "respect" or
> > missing
> > > > "politeness" then those people are either strictly dumb and
> > superficial,
> > > or
> > > > they owe a gesture that I would call a "Well, I know, but I do not
> > want to
> > > > see what's going on"-disease, nothing else.
> > > > >
> > > > > Another term to describe the latter would be "bureaucratic lamb head
> > > > behaviour".
> > > > >
> > > > > See, Linus, if for instance Andrew Morton mails me some statement
> > from
> > > > that Chehab going: "Again, do not take the patches from Uwe - he is
> > always
> > > > regarding things through his personal prisma, and the rest he simply
> > does
> > > > not perceive at all"
> > > > >
> > > > > then this is nothing but a gesture full of lies (somehow typical for
> > > > this Brazilian fascistoid opinion block head dictator), but it simply
> > > shows
> > > > that the linuxtv.org teamleader is a horrible mismatch, nothing else!
> > > > >
> > > > > His mediocrity and dumbness simply defines through the fact that he
> > is
> > > > using stigmatizations very soon in a so-called "discussion" because he
> > > > misses
> > > > > a. human skills
> > > > > b. technical proven arguments and theses
> > > > > c. enough experience, human or technical one.
> > > > >
> > > > > And the biggest threat and shame is the proven fact that Andrew
> > Morton
> > > > does obey to such a stupid reactionary idiot and let his face soap in
> > by
> > > > this dirty Brazilian hypocrite instead of giving contributions at
> > least a
> > > > chance through his mm-tree.
> > > > >
> > > > > So there are exactly two solutions:
> > > > > 1. Andrew Morton should not obey to Chehab anymore and be real open
> > > > > 2. Chehab and Abraham should be substituted as quick as possible
> > without
> > > > any hesitation in no way!!!!
> > > > >
> > > > > The one that got to be fired with the most urgent priority is called
> > > > Mauro Carvalho Chehab. This is no maintainer, this is no gatekeeper,
> > but
> > > this
> > > > is nothing but a real personified ape or disease.
> > > > >
> > > > > And the argument whether those people are paid for their work or not
> > is
> > > > exactly as important as if a sack of rice falls down somewhere in
> > > > capitalist China or not.....
> > > > > OBSOLETE!!!
> > > > >
> > > > > Yours sincerely
> > > > > Uwe
> > > > >
> > > >
> > > > If eventually somebody thinks this kind of stuff could be helpful,
> > > > please say so and give us some pointers.
> > > >
> > > > Hermann
> > > >
> > > Hi Hermann,
> > >
> > > now if you are searching for helpful stuff I can make public a ten
> > Emails
> > > ping pong
> > > betwwen stupid Chehab and me about my almost excellent dst-deselection
> > patch
> > > contributions.
> > >
> > > In this ten Emails you will yourself see the intellectual and technical
> > > proof in how far Mr. Chehab is acting with nothing else but:
> > >
> > > a. Lies
> > > b. Unproven thesis
> > > c. Stigmatizations
> > >
> > > and so on.
> > >
> > > THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
> > >
> > > That's it what I cannot live with!
> > > I swear I never stumbled over such an utomst stubborn, stupid and
> > horrible
> > > idiot in my whole year lasting Linux experience, and I thought I could
> > not
> > > trust my eyes when I saw what incredible crap work was pushed into
> > mainline
> > > by the signature of this
> > > incredible and horrible team chief from Brazil.
> > >
> > > If you want to see the Emails, just ask me and I will forward them with
> > a
> > > couple of CCs. They will show the truth about the real consistence of
> > this
> > > "maintainer leader".
> > >
> >
> > Uwe,
> >
> > which patches do you refer to?
> > Can you submit a list of your patches which got no attention (I'm only
> > interested in the patches, not in discussions you had)
> >
> > Markus
>
> Hi Markus,
> a thousands of thanks for your friendly response - very nice! What a
> pleasure!
>
> I do not send in the two patches for one more time. I have sent them in so
> often!
> If you take a closer look at the mailing list you will easily find them.
>
> One is a docu fix, and the other one, causing so much trouble out of nothing
> but Chehab's stubbornness and incompetence, is the one that makes the two
> DST modules
> deselectable (i. e. DST itself for TwinHan DST and clones plus DST_CA for
> TwinHan cards with CA slot and Pinnacle PCTV SAT cards with CI extension for
> example).
>
> Chehab told me some crap about unresolved symbols which never existed as
> this second patch just runs fine.

> The compiler errors are the following:
> WARNING: "dst_ca_attach" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
> WARNING: "dst_attach" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
> WARNING: "dvb_pll_configure" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
> WARNING: "dvb_pll_lg_tdvs_h06xf" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!

> WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dst_attach
> WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dst_ca_attach
> WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dvb_pll_lg_tdvs_h06xf
> WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dvb_pll_configure

I just looked over the patches and Mauro's response shortly, Mauro
just wrote that your patch leaves undefined symbols. That way Mauro
won't commit any patches, nevermind if the patch comes from you or
someone else.

I'll have a closer look at what your patch causes tonight, afterwards
I can say more about it.
If these symbols aren't needed you might insert dummy functions which
print that the real implementation isn't compiled into the kernel
(dvb_attach does it that way)

Some of your mails only contain 10% information about what you really
want to solve please cut out the private abusive stuff. The people you
judge here contributed alot during the last years, it probably
wouldn't even be possible to compile the whole project that easy if
these people wouldn't have done all that work for everyone.

2.6.21 won't be the last kernel out there, the right place to fix that
problem is the v4l-dvb repository on linuxtv.org first.

Markus

> I also did not miss any warning lines in the deselection menu that I
> programmed and I can swear I definitely missed no chance to convince Chehab
> and others that my patches are close to being real perfect! IN VAIN!
>
> So, if you do not find my patches on the mailing list or if there are any
> questions as far as what concerns that issue please feel free to ask me as I
> believe that you are really open-minded towards that.
>
> Above that I want to confirm the utmost necessity to rip Trent Piepho's
> regressive work out of 2.6.21-git2 as it is in fact technically the most
> regressive and reactionary crap that I ever have seen......
>
> So please Linus - rip that crap out of 2.6.21-git2. And if you do see
> questions what parts you need to rip out, please feel free to ask me....
>
> Cheers
> Uwe
>
> --
> "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
> Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
>


-- 
Markus Rechberger

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 15:06:11 +0200
Von: "Markus Rechberger" <mrechberger@gmail.com>
An: "Uwe Bugla" <uwe.bugla@gmx.de>
CC: linux-kernel@vger.kernel.org, linux-dvb@linuxtv.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, mkrufky@linuxtv.org, hermann-pitton@arcor.de
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> On 4/30/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
> >
> > -------- Original-Nachricht --------
> > Datum: Mon, 30 Apr 2007 13:48:34 +0200
> > Von: "Markus Rechberger" <mrechberger@gmail.com>
> > An: "Uwe Bugla" <uwe.bugla@gmx.de>
> > CC: "hermann pitton" <hermann-pitton@arcor.de>, mkruky@linuxtv.org,
> > akpm@linux-foundation.org, torvalds@linux-foundation.org,
> > linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org
> > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and
> > pseudo-authorities
> >
> > > On 4/30/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
> > > >
> > > > -------- Original-Nachricht --------
> > > > Datum: Mon, 30 Apr 2007 02:58:33 +0200
> > > > Von: hermann pitton <hermann-pitton@arcor.de>
> > > > An: Uwe Bugla <uwe.bugla@gmx.de>
> > > > CC: Linus Torvalds <torvalds@linux-foundation.org>,
> mkruky@linuxtv.org,
> > > > akpm@linux-foundation.org, linux-dvb@linuxtv.org,
> > > > linux-kernel@vger.kernel.org
> > > > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21
> > > > and	pseudo-authorities
> > > >
> > > > > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
> > > > > > -------- Original-Nachricht --------
> > > > > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> > > > > > Von: Linus Torvalds <torvalds@linux-foundation.org>
> > > > > > An: Uwe Bugla <uwe.bugla@gmx.de>
> > > > > > CC: linux-dvb@linuxtv.org, mkruky@linuxtv.org,
> > > mchehab@infradead.org,
> > > > > linux-kernel@vger.kernel.org, akpm@linux-foundation.org
> > > > > > Betreff: Re: Critical points about kernel 2.6.21 and
> > > pseudo-authorities
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > > > > > >
> > > > > > > > I have been trying diff and other tools in various variants
> > > (except
> > > > > > > > git-bisect that I cannot handle because I do not understand
> the
> > > > > practice
> > > > > > > > of it).
> > > > > > >
> > > > > > > git bisect is _really_ simple if you already have a git tree
> > > anyway.
> > > > > And
> > > > > > > even if you don't, getting one isn't really hard either. Just
> do
> > > > > > >
> > > > > > > 	git clone
> > > > > > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > > > > linux-2.6
> > > > > > >
> > > > > > > and you have a tree (it will take a little while - it's going
> to
> > > > > dowload
> > > > > > > about 170MB or so of stuff, so the initial clone is going to
> be a
> > > bit
> > > > > > > painful unless you have a fast internet connection).
> > > > > > >
> > > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked
> for
> > > you,
> > > > > it's
> > > > > > > really as easy as just saying
> > > > > > >
> > > > > > > 	git bisect start
> > > > > > > 	git bisect good v2.6.21-rc7
> > > > > > > 	git bisect bad v2.6.21
> > > > > > >
> > > > > > > and git will think for a short while (most of the time is
> going to
> > > be
> > > > > > > checking out the new tree) and give you a tree to test.
> > > > > > >
> > > > > > > Just build, boot, and test that tree.
> > > > > > >
> > > > > > > If it was fine, do
> > > > > > >
> > > > > > > 	git bisect good
> > > > > > >
> > > > > > > and git will pick a new tree to test. And if it wasn't,
> instead
> > > just
> > > > > do
> > > > > > > "git bisect bad", and git will pick _another_ version to test.
> Do
> > > this
> > > > > a
> > > > > > > few times, and git will tell you which commit introduced them.
> > > > > > >
> > > > > > > There were just 125 commits in between 2.6.21-rc7 and the
> final
> > > one,
> > > > > so it
> > > > > > > should be quite quick - bisection basically does a binary
> search,
> > > so
> > > > > doing
> > > > > > > seven reboots should have you with the result.
> > > > > > >
> > > > > > > The fact that it already works in 2.6.21-git2 obviously means
> that
> > > _I_
> > > > > end
> > > > > > > up being less interested, but the -stable tree people would
> love
> > > to
> > > > > hear
> > > > > > > what broke!
> > > > > >
> > > > > > Hi again Linus,
> > > > > > my deep thanks for your excellent explication of git-bisect.
> > > > > > But I unfortunately owe a 100Kbit flatrate, and so downloading
> some
> > > 170
> > > > > MB git tree will need the time amount of one entire night (11.5 kb
> /s
> > > if I
> > > > > am lucky - no more).
> > > > > > Just to take up a different approach:
> > > > > >
> > > > > > The difference between 2.6.21-rc7 and 2.6.21 official does not
> play
> > > any
> > > > > role at all.
> > > > > >
> > > > > > On the other hand I found out that:
> > > > > > 2.6.21-rc7 made my AMD K7 router work fine
> > > > > > 2.6.21 official hung my AMD K7 router up
> > > > > > 2.6.21-git1 hung my AMD K7 router up
> > > > > > 2.6.21-git2 made my AMD K7 router work.
> > > > > >
> > > > > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously
> > > solves
> > > > > the problem.
> > > > > > Or am I saying something wrong as far as logical terms are
> > > concerned?
> > > > > >
> > > > > > >
> > > > > > > > I like small and effective kernels instead of blown up RAM
> > > waste.
> > > > > > > > This is no Windoze, man, this is Linux!
> > > > > > >
> > > > > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't
> get
> > > > > anywhere
> > > > > > > at all.
> > > > > > >
> > > > > > > This is Linux, not Windows. But that also means that those
> > > developers
> > > > > that
> > > > > > > you denigrate aren't getting paid by you, and if you don't
> show
> > > them
> > > > > > > respect, they'll totally ignore you.
> > > > > > >
> > > > > > > 		Linus
> > > > > >
> > > > > > Now this is the old problem about it all: the hypocricy factor,
> the
> > > > > utmost small, if not to say pre-pubertarian character plus some
> other
> > > > obviously
> > > > > counter-productive character traits in those so-called
> "maintainers"
> > > who
> > > > > behave like kids, but not like grown-ups at all!
> > > > > > Not only you, but also Andrew perfectly and willingly step into
> the
> > > > > hypocritic trap and do not even feel that they are trapped!
> > > > > >
> > > > > > For the majority of all cases of the so-called "maintainer
> > > personnel" at
> > > > > linuxtv.org the statement of some missing "politeness" or some
> missing
> > > > > "respect" is nothing but an utmost dumb, kiddish, human mediocre
> and
> > > > utmost
> > > > > stupid and utmost hypocritic excuse for bare naked
> incompatibility,
> > > > dumbness,
> > > > > wrong solidarity, kiddishness and technical incompetence.
> > > > > >
> > > > > > They are building up pseudo-authorities to hide their lack of
> > > > > competence, no matter if their lack of competence funds on
> technical
> > > or
> > > > human lacks.
> > > > > > And at least the Brazilian Mauro Carvalho Chehab does go even so
> far
> > > to
> > > > > soap in Andrew Morton's face with this enourmous threat of
> > > incompetence,
> > > > > kiddishness, incompatibility, hypocricy, lies, stigmatisations,
> > > > stubbornness,
> > > > > lack of experience, pre-pubertarian behaviour, fascistoid opinion
> > > > > dictatorship as part of a deep immature anti-democratic and
> > > reactionary
> > > > personality
> > > > > structure.
> > > > > >
> > > > > > Would you call Mauro Carvalho Chehab a maintainer!
> > > > > > I can certify you that I cannot, even if I try. And I want him
> to be
> > > > > substituted as quick as possible as he is the biggest mismatch of
> > > > gatekeeper
> > > > > one can ever imagine.
> > > > > >
> > > > > > And it is not only me personally perceiving this that there are
> > > people
> > > > > missing who can go upright and offer sophisticated and good work.
> > > > > > Plus a real sophisticated discussion behaviour, in technical and
> in
> > > > > human terms.
> > > > > > Going upright is thus far away from the behaviour NOT to be able
> to
> > > > > tolerate any criticism at all.
> > > > > >
> > > > > > Solution: This whole new quite young linuxtv.org team is missing
> a
> > > real
> > > > > grown up and experienced team leader. Not only that is definitely
> too
> > > much
> > > > > for Mauro Carvalho Chehab. That is the pain - the consistence of
> the
> > > whole
> > > > > group is the pain, that's all. Too young, too many lacks of human
> > > skills,
> > > > > and missing an appropriate team leader.............
> > > > > >
> > > > > > So, if I show respect or not, or if I show politeness or not
> will
> > > never
> > > > > change the whole structural situation at all, as great parts of
> the
> > > whole
> > > > > team is a disease:
> > > > > > 1. By Chehab being the team leader the whole fish stinks from
> the
> > > head
> > > > > startup.
> > > > > > Solution: Substitution of Mauro Carvalho Chehab as quick as
> possible
> > > -
> > > > > even quicker than a storm!
> > > > > > 2. By Krufky being one part of it, doing good work, but
> executing
> > > wrong
> > > > > solidarities by his bowing behaviour towards pseudo-authorities
> > > although
> > > > he
> > > > > knows better at least technically this is a question of wrong or
> right
> > > > > leadership, nothing else
> > > > > > 3. By Abraham offering us great ranting aims that never are
> being
> > > put
> > > > > into practice out of certified missing human skills and missing
> > > technical
> > > > > knowledge (the four completely unusable 2.6 kernels were never
> > > apologized
> > > > by
> > > > > himself) urgent substitution  is utmost necessary.
> > > > > >
> > > > > > CLEARER: If anyone of the people knowing the deeper context
> claims
> > > those
> > > > > "gatekeeper methods" to be a consequence of missing "respect" or
> > > missing
> > > > > "politeness" then those people are either strictly dumb and
> > > superficial,
> > > > or
> > > > > they owe a gesture that I would call a "Well, I know, but I do not
> > > want to
> > > > > see what's going on"-disease, nothing else.
> > > > > >
> > > > > > Another term to describe the latter would be "bureaucratic lamb
> head
> > > > > behaviour".
> > > > > >
> > > > > > See, Linus, if for instance Andrew Morton mails me some
> statement
> > > from
> > > > > that Chehab going: "Again, do not take the patches from Uwe - he
> is
> > > always
> > > > > regarding things through his personal prisma, and the rest he
> simply
> > > does
> > > > > not perceive at all"
> > > > > >
> > > > > > then this is nothing but a gesture full of lies (somehow typical
> for
> > > > > this Brazilian fascistoid opinion block head dictator), but it
> simply
> > > > shows
> > > > > that the linuxtv.org teamleader is a horrible mismatch, nothing
> else!
> > > > > >
> > > > > > His mediocrity and dumbness simply defines through the fact that
> he
> > > is
> > > > > using stigmatizations very soon in a so-called "discussion"
> because he
> > > > > misses
> > > > > > a. human skills
> > > > > > b. technical proven arguments and theses
> > > > > > c. enough experience, human or technical one.
> > > > > >
> > > > > > And the biggest threat and shame is the proven fact that Andrew
> > > Morton
> > > > > does obey to such a stupid reactionary idiot and let his face soap
> in
> > > by
> > > > > this dirty Brazilian hypocrite instead of giving contributions at
> > > least a
> > > > > chance through his mm-tree.
> > > > > >
> > > > > > So there are exactly two solutions:
> > > > > > 1. Andrew Morton should not obey to Chehab anymore and be real
> open
> > > > > > 2. Chehab and Abraham should be substituted as quick as possible
> > > without
> > > > > any hesitation in no way!!!!
> > > > > >
> > > > > > The one that got to be fired with the most urgent priority is
> called
> > > > > Mauro Carvalho Chehab. This is no maintainer, this is no
> gatekeeper,
> > > but
> > > > this
> > > > > is nothing but a real personified ape or disease.
> > > > > >
> > > > > > And the argument whether those people are paid for their work or
> not
> > > is
> > > > > exactly as important as if a sack of rice falls down somewhere in
> > > > > capitalist China or not.....
> > > > > > OBSOLETE!!!
> > > > > >
> > > > > > Yours sincerely
> > > > > > Uwe
> > > > > >
> > > > >
> > > > > If eventually somebody thinks this kind of stuff could be helpful,
> > > > > please say so and give us some pointers.
> > > > >
> > > > > Hermann
> > > > >
> > > > Hi Hermann,
> > > >
> > > > now if you are searching for helpful stuff I can make public a ten
> > > Emails
> > > > ping pong
> > > > betwwen stupid Chehab and me about my almost excellent
> dst-deselection
> > > patch
> > > > contributions.
> > > >
> > > > In this ten Emails you will yourself see the intellectual and
> technical
> > > > proof in how far Mr. Chehab is acting with nothing else but:
> > > >
> > > > a. Lies
> > > > b. Unproven thesis
> > > > c. Stigmatizations
> > > >
> > > > and so on.
> > > >
> > > > THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
> > > >
> > > > That's it what I cannot live with!
> > > > I swear I never stumbled over such an utomst stubborn, stupid and
> > > horrible
> > > > idiot in my whole year lasting Linux experience, and I thought I
> could
> > > not
> > > > trust my eyes when I saw what incredible crap work was pushed into
> > > mainline
> > > > by the signature of this
> > > > incredible and horrible team chief from Brazil.
> > > >
> > > > If you want to see the Emails, just ask me and I will forward them
> with
> > > a
> > > > couple of CCs. They will show the truth about the real consistence
> of
> > > this
> > > > "maintainer leader".
> > > >
> > >
> > > Uwe,
> > >
> > > which patches do you refer to?
> > > Can you submit a list of your patches which got no attention (I'm only
> > > interested in the patches, not in discussions you had)
> > >
> > > Markus
> >
> > Hi Markus,
> > a thousands of thanks for your friendly response - very nice! What a
> > pleasure!
> >
> > I do not send in the two patches for one more time. I have sent them in
> so
> > often!
> > If you take a closer look at the mailing list you will easily find them.
> >
> > One is a docu fix, and the other one, causing so much trouble out of
> nothing
> > but Chehab's stubbornness and incompetence, is the one that makes the
> two
> > DST modules
> > deselectable (i. e. DST itself for TwinHan DST and clones plus DST_CA
> for
> > TwinHan cards with CA slot and Pinnacle PCTV SAT cards with CI extension
> for
> > example).
> >
> > Chehab told me some crap about unresolved symbols which never existed as
> > this second patch just runs fine.
> 
> > The compiler errors are the following:
> > WARNING: "dst_ca_attach" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko]
> undefined!
> > WARNING: "dst_attach" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
> > WARNING: "dvb_pll_configure" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko]
> undefined!
> > WARNING: "dvb_pll_lg_tdvs_h06xf" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko]
> undefined!
> 
> > WARNING:
> /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dst_attach
> > WARNING:
> /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dst_ca_attach
> > WARNING:
> /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dvb_pll_lg_tdvs_h06xf
> > WARNING:
> /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dvb_pll_configure
> 
> I just looked over the patches and Mauro's response shortly, Mauro
> just wrote that your patch leaves undefined symbols. That way Mauro
> won't commit any patches, nevermind if the patch comes from you or
> someone else.
> 
> I'll have a closer look at what your patch causes tonight, afterwards
> I can say more about it.
> If these symbols aren't needed you might insert dummy functions which
> print that the real implementation isn't compiled into the kernel
> (dvb_attach does it that way)
> 
> Some of your mails only contain 10% information about what you really
> want to solve please cut out the private abusive stuff. The people you
> judge here contributed alot during the last years, it probably
> wouldn't even be possible to compile the whole project that easy if
> these people wouldn't have done all that work for everyone.
> 
> 2.6.21 won't be the last kernel out there, the right place to fix that
> problem is the v4l-dvb repository on linuxtv.org first.
> 
> Markus

Hi Markus,
Sure! BUT:

you again state that there ar obviously unresolved symbols
caused by my DST deselection patches.

Why then do I not get any? (And I told this Mauro a thousands of times that I do and did not get any)!
And I even sent him dmesg, config and absolutely everything he needs to
a. prove that my patches are OK
b. get deeper into it

But he simply ignored that, like a thesis repeating wall, some oracle, or some parrot!

Perhaps the relevant part of my 2.6.21.1 config will offer
some answer for this crucial question:

# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set

#
# Encoders/decoders and other helper chips
#

#
# Audio decoders
#
# CONFIG_VIDEO_TVAUDIO is not set
# CONFIG_VIDEO_TDA7432 is not set
# CONFIG_VIDEO_TDA9840 is not set
# CONFIG_VIDEO_TDA9875 is not set
# CONFIG_VIDEO_TEA6415C is not set
# CONFIG_VIDEO_TEA6420 is not set
# CONFIG_VIDEO_MSP3400 is not set
# CONFIG_VIDEO_CS53L32A is not set
# CONFIG_VIDEO_TLV320AIC23B is not set
# CONFIG_VIDEO_WM8775 is not set
# CONFIG_VIDEO_WM8739 is not set

#
# Video decoders
#
# CONFIG_VIDEO_BT819 is not set
# CONFIG_VIDEO_BT856 is not set
# CONFIG_VIDEO_BT866 is not set
# CONFIG_VIDEO_KS0127 is not set
# CONFIG_VIDEO_OV7670 is not set
# CONFIG_VIDEO_SAA7110 is not set
# CONFIG_VIDEO_SAA7111 is not set
# CONFIG_VIDEO_SAA7114 is not set
# CONFIG_VIDEO_SAA711X is not set
# CONFIG_VIDEO_SAA7191 is not set
# CONFIG_VIDEO_TVP5150 is not set
# CONFIG_VIDEO_VPX3220 is not set

#
# Video and audio decoders
#
# CONFIG_VIDEO_CX25840 is not set

#
# MPEG video encoders
#
# CONFIG_VIDEO_CX2341X is not set

#
# Video encoders
#
# CONFIG_VIDEO_SAA7127 is not set
# CONFIG_VIDEO_SAA7185 is not set
# CONFIG_VIDEO_ADV7170 is not set
# CONFIG_VIDEO_ADV7175 is not set

#
# Video improvement chips
#
# CONFIG_VIDEO_UPD64031A is not set
# CONFIG_VIDEO_UPD64083 is not set
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_BT848_DVB is not set
# CONFIG_VIDEO_SAA6588 is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_CAFE_CCIC is not set

#
# V4L USB devices
#
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set

#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_USB_DSBR is not set

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m
CONFIG_DVB_CORE_ATTACH=y

#
# Supported SAA7146 based PCI Adapters
#
# CONFIG_DVB_AV7110 is not set
# CONFIG_DVB_BUDGET is not set
# CONFIG_DVB_BUDGET_CI is not set
# CONFIG_DVB_BUDGET_AV is not set

#
# Supported USB Adapters
#
# CONFIG_DVB_USB is not set
# CONFIG_DVB_TTUSB_BUDGET is not set
# CONFIG_DVB_TTUSB_DEC is not set
# CONFIG_DVB_CINERGYT2 is not set

#
# Supported FlexCopII (B2C2) Adapters
#
# CONFIG_DVB_B2C2_FLEXCOP is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Customise DST support
#
CONFIG_DVB_DST_CUSTOMISE=y
# CONFIG_DVB_DST is not set
# CONFIG_DVB_DST_CA is not set

#
# Supported Pluto2 Adapters
#
# CONFIG_DVB_PLUTO2 is not set

#
# Supported DVB Frontends
#

#
# Customise DVB Frontends
#
CONFIG_DVB_FE_CUSTOMISE=y

#
# DVB-S (satellite) frontends
#
# CONFIG_DVB_STV0299 is not set
CONFIG_DVB_CX24110=m
# CONFIG_DVB_CX24123 is not set
# CONFIG_DVB_TDA8083 is not set
# CONFIG_DVB_MT312 is not set
# CONFIG_DVB_VES1X93 is not set
# CONFIG_DVB_S5H1420 is not set
# CONFIG_DVB_TDA10086 is not set

#
# DVB-T (terrestrial) frontends
#
# CONFIG_DVB_SP8870 is not set
# CONFIG_DVB_SP887X is not set
# CONFIG_DVB_CX22700 is not set
# CONFIG_DVB_CX22702 is not set
# CONFIG_DVB_L64781 is not set
# CONFIG_DVB_TDA1004X is not set
# CONFIG_DVB_NXT6000 is not set
# CONFIG_DVB_MT352 is not set
# CONFIG_DVB_ZL10353 is not set
# CONFIG_DVB_DIB3000MB is not set
# CONFIG_DVB_DIB3000MC is not set
# CONFIG_DVB_DIB7000M is not set
# CONFIG_DVB_DIB7000P is not set

#
# DVB-C (cable) frontends
#
# CONFIG_DVB_VES1820 is not set
# CONFIG_DVB_TDA10021 is not set
# CONFIG_DVB_STV0297 is not set

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
# CONFIG_DVB_NXT200X is not set
# CONFIG_DVB_OR51211 is not set
# CONFIG_DVB_OR51132 is not set
# CONFIG_DVB_BCM3510 is not set
# CONFIG_DVB_LGDT330X is not set

#
# Tuners/PLL support
#
# CONFIG_DVB_TDA826X is not set
# CONFIG_DVB_TUNER_QT1010 is not set
# CONFIG_DVB_TUNER_MT2060 is not set
# CONFIG_DVB_TUNER_LGH06XF is not set

I swear I did not even produce ONE unresolved symbol!
I use cx24110, I use CONFIG_DVB_FE_CUSTOMISE=y, I use CONFIG_DVB_BT8XX=m,
I use CONFIG_DVB_CORE_ATTACH=y, AND I use my self built additions like

CONFIG_DVB_DST_CUSTOMISE=y
# CONFIG_DVB_DST is not set
# CONFIG_DVB_DST_CA is not set

And I swear that this dvb-pll.c is completely obsolete for this scenario!
For that reason (old variant):
# CONFIG_DVB_TUNER_LGH06XF is not set

And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey,
but it was produced by Michael Krufky himself, and I was very thankful for that and still am!

So where the hell do these unresolved symbols come from, if I did not get even ONE????
AND, in so far, how should I correct something whose hidden cause I cannot see, as my
scenario DOES NOT produce any unresolved symbols??

May be your configuration differs from mine, and that is where the pain is!
But please do not waste time if there is no reason for it.

Is it in the end another frontend except the cx24110 whose
activation causes those unresolved symbols?

Are there different frontends in the end except cx24110 that need those dst attachments?

If yes, which frontends are the relevant ones?
See, Markus, either noone knows, or the Manuel Abraham primadonna refuses to answer once again. This is the hopeless situation that I am talking about - incredible!

In so far a very sophisticated team leader who knows about this all in general terms would be a necessity for the personnel @linuxtv.org.

Gerd Knorr was doing that job very fine - I swear I never had any trouble with him! Not even once!
He was communicative, he was technically excellent, he was just incredibly fine!

Now if yes, I always stated that I do not owe a whole bunch of testing cards.

If yes I suppose this whole dvb_attach issue is just another big, buggy and half-boiled chaos.

And why the hell is that dvb-pll.c rollback part of git2 now?
Additionally - with the acknowlegdement of Michael Krufky - incredible!

Cheers and a thousands of thanks for your pain

Uwe

> 
> > I also did not miss any warning lines in the deselection menu that I
> > programmed and I can swear I definitely missed no chance to convince
> Chehab
> > and others that my patches are close to being real perfect! IN VAIN!
> >
> > So, if you do not find my patches on the mailing list or if there are
> any
> > questions as far as what concerns that issue please feel free to ask me
> as I
> > believe that you are really open-minded towards that.
> >
> > Above that I want to confirm the utmost necessity to rip Trent Piepho's
> > regressive work out of 2.6.21-git2 as it is in fact technically the most
> > regressive and reactionary crap that I ever have seen......
> >
> > So please Linus - rip that crap out of 2.6.21-git2. And if you do see
> > questions what parts you need to rip out, please feel free to ask me....
> >
> > Cheers
> > Uwe
> >
> > --
> > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
> > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
> >
> 
> 
> -- 
> Markus Rechberger

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Michael Krufky]

Uwe Bugla wrote:
> And I swear that this dvb-pll.c is completely obsolete for this scenario!
> For that reason (old variant):
> # CONFIG_DVB_TUNER_LGH06XF is not set
>
> And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey,
> but it was produced by Michael Krufky himself, and I was very thankful for that and still am!
>
> [...]
>
> And why the hell is that dvb-pll.c rollback part of git2 now?
> Additionally - with the acknowlegdement of Michael Krufky - incredible!
The LG-H06xF NIM is slightly different from the other tuners supported
by the dvb-pll library, in that it requires a 5th auxiliary byte, as
opposed to only four bytes that are sent for all of the other devices
supported by dvb-pll.  In order to handle this, I had created a separate
module, called lgh06xf.  This module was able to re-use some code inside
the dvb-pll module, while adding the additional required code to handle
that 5th byte.

As a side effect, caused by the creation of the lgh06xf module, the
static dependency of dvb-bt8xx on dvb-pll was removed.  Instead of
dvb-bt8xx having to call dvb_pll_configure, causing the static
dependency, it would now call lgh06xf_attach.  lgh06xf_attach would fill
the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the
lgh06xf module.  This change was done in an effort to improve support
for the LG-TDVS-H06xF NIM family...  The removal of the static
dependency of dvb-bt8xx on dvb-pll was merely a side effect.  I DID NOT
DO THIS FOR YOUR BENEFIT, UWE.  There is always a chance that a new
bt8xx-based card may come around with a new tuner, and need the dvb-pll
module in order to work properly.

Then, Trent suggested that we add this 5th byte functionality to
dvb-pll.  Trent has shown us how this 5th byte is helpful for other
devices, including the Thomson DTT 761X, and the Philips FMD1216ME,
among others.  Trent made the appropriate changes to the dvb-pll module,
allowing it to absorb the functionality of the lgh06xf module into a
centralized location, so that any other tuners can benefit from this
shared code.  Trent did a great thing here, by making the dvb-pll module
a much more robust library, not to mention that his changes have in fact
REDUCED the size of the kernel.  (see Trent's earlier post in this thread)

Uwe, this is quite a silly argument.  You've been singing the same song
ever since before I got involved with linuxtv.org, and quite frankly, I
am sick of it.

Let it be known to the world, that Uwe has praised me in his previous
emails, as I have kept quiet and ignored his rants.  Now that I am
finally opening up my mouth, I am quite sure that I will be his next
flame target.  Nobody can take this kind of behavior seriously -- the
only thing we can do is ignore you, and maybe you'll go away.

My suggestion to you, Uwe, is to stop flaming the lists, and stop
bothering us developers.  Your devices work.  You are complaining about
wasted memory -- get over it.  It is a small price to pay for globally
supported devices and autodetection.  You should be happy that people
are still here working on this code.  It seems that your emails are
focused at driving away developers -- nothing more could be gained by
this, then everybody is screwed.

If your patches were correct, then, by all means, we would apply them. 
However, developers have pointed out problems in your patches, and you
have done nothing but flame them.  Who wants to continue a discussion
with you, after only being flamed?  I sure don't.

Just know that if you respond to this email with yet another flame, I
will simply ignore it.

-Mike

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 11:30:34 -0400
Von: Michael Krufky <mkrufky@linuxtv.org>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: Markus Rechberger <mrechberger@gmail.com>, hermann-pitton@arcor.de, akpm@linux-foundation.org, torvalds@linux-foundation.org, linux-dvb@linuxtv.org, linux-kernel@vger.kernel.org, Trent Piepho <xyzzy@speakeasy.org>
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> Uwe Bugla wrote:
> > And I swear that this dvb-pll.c is completely obsolete for this
> scenario!
> > For that reason (old variant):
> > # CONFIG_DVB_TUNER_LGH06XF is not set
> >
> > And this old variant was NOT done by Trent Piepho, it was NOT done by
> Andrew Quincey,
> > but it was produced by Michael Krufky himself, and I was very thankful
> for that and still am!
> >
> > [...]
> >
> > And why the hell is that dvb-pll.c rollback part of git2 now?
> > Additionally - with the acknowlegdement of Michael Krufky - incredible!
> The LG-H06xF NIM is slightly different from the other tuners supported
> by the dvb-pll library, in that it requires a 5th auxiliary byte, as
> opposed to only four bytes that are sent for all of the other devices
> supported by dvb-pll.  In order to handle this, I had created a separate
> module, called lgh06xf.  This module was able to re-use some code inside
> the dvb-pll module, while adding the additional required code to handle
> that 5th byte.
> 
> As a side effect, caused by the creation of the lgh06xf module, the
> static dependency of dvb-bt8xx on dvb-pll was removed.  Instead of
> dvb-bt8xx having to call dvb_pll_configure, causing the static
> dependency, it would now call lgh06xf_attach.  lgh06xf_attach would fill
> the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the
> lgh06xf module.  This change was done in an effort to improve support
> for the LG-TDVS-H06xF NIM family...  The removal of the static
> dependency of dvb-bt8xx on dvb-pll was merely a side effect.  I DID NOT
> DO THIS FOR YOUR BENEFIT, UWE.  There is always a chance that a new
> bt8xx-based card may come around with a new tuner, and need the dvb-pll
> module in order to work properly.
> 
> Then, Trent suggested that we add this 5th byte functionality to
> dvb-pll.  Trent has shown us how this 5th byte is helpful for other
> devices, including the Thomson DTT 761X, and the Philips FMD1216ME,
> among others.  Trent made the appropriate changes to the dvb-pll module,
> allowing it to absorb the functionality of the lgh06xf module into a
> centralized location, so that any other tuners can benefit from this
> shared code.  Trent did a great thing here, by making the dvb-pll module
> a much more robust library, not to mention that his changes have in fact
> REDUCED the size of the kernel.  (see Trent's earlier post in this thread)
> 
> Uwe, this is quite a silly argument.  You've been singing the same song
> ever since before I got involved with linuxtv.org, and quite frankly, I
> am sick of it.
> 
> Let it be known to the world, that Uwe has praised me in his previous
> emails, as I have kept quiet and ignored his rants.  Now that I am
> finally opening up my mouth, I am quite sure that I will be his next
> flame target.  Nobody can take this kind of behavior seriously -- the
> only thing we can do is ignore you, and maybe you'll go away.
> 
> My suggestion to you, Uwe, is to stop flaming the lists, and stop
> bothering us developers.  Your devices work.  You are complaining about
> wasted memory -- get over it.  It is a small price to pay for globally
> supported devices and autodetection.

Hi Mike,
first of all thank you for explainig us all the context - well done!

I spent some 4 hours yesterday to try to find a compromise solution as Trent Piepho ignored my criticism, which is no fine behaviour at all.
Even if you do not believe I even managed to nearly complete a compromise, making dvb-pll.c deselectable for both of the v4l layers.

I only stumbled over line 614 of module dvb-bt8xx.c in current 2.6.21-git2 kernel.
For this static dependency concerning support for the Fusion HDTV 5 Lite card I did not manage to find out a solution how to get rid of.

I think I will send my stuff to Markus who already offered to help me to work this out.
So there is no "small price to pay" at all if one knows how to resolve it. It's quite simple in fact - I am just missing the appropriate thought kick.

  You should be happy that people
> are still here working on this code.  It seems that your emails are
> focused at driving away developers -- nothing more could be gained by
> this, then everybody is screwed.
> 
> If your patches were correct, then, by all means, we would apply them. 
> However, developers have pointed out problems in your patches, and you
> have done nothing but flame them.  Who wants to continue a discussion
> with you, after only being flamed?  I sure don't.

Again I state:
I haven't found any unresolved symbols caused by my DST deselection patches.
Even if Mauro Chehab repeats that like a parrot it is like an air bubble on my testing side: empty, non existant, wrong!

Uwe
> 
> Just know that if you respond to this email with yet another flame, I
> will simply ignore it.
> 
> -Mike

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Linus Torvalds]

On Mon, 30 Apr 2007, Uwe Bugla wrote:
> 
> So please Linus - rip that crap out of 2.6.21-git2. And if you do see questions what parts you need to rip out, please feel free to ask me....
> 

Uwe. I'll say this ONCE more.

No.

And unless you can become politer and more respectful and stop ranting all 
the time, you'll be in the very rare situation of hitting my auto-filters 
and going into an email mbox of your own (read: one that I read in my 
copious spare time. Hint: I don't _have_ any.)

		Linus

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 07:49:52 -0700 (PDT)
Von: Linus Torvalds <torvalds@linux-foundation.org>
An: Uwe Bugla <uwe.bugla@gmx.de>
CC: Markus Rechberger <mrechberger@gmail.com>, linux-kernel@vger.kernel.org, linux-dvb@linuxtv.org, akpm@linux-foundation.org, mkruky@linuxtv.org, hermann-pitton@arcor.de
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> 
> 
> On Mon, 30 Apr 2007, Uwe Bugla wrote:
> > 
> > So please Linus - rip that crap out of 2.6.21-git2. And if you do see
> questions what parts you need to rip out, please feel free to ask me....
> > 
> 
> Uwe. I'll say this ONCE more.
> 
> No.

Sorry! Sigh! Very utmost bad decision, but I must respect it.
The accumulative principle is the opposite of effectiveness.
Even if you do not understand the dvb issues in git2 (well I cannot expect this, can I?), you push

a. immature code
b. a regression

Isn't it a pity that the "maintainer" title has more influence than any kind of
common sense, reason or sophisticated argumentation?
What a horrible thought!

P. S.: In former kernel releases the specific last release candidate was almost identical to the official kernel release.

Not only I have largest problems to understand why this wonderful principle has been broken, with the effect, that the so-called "stable" kernel releases are unusable in the end.
2.6.20, 2.6.21, 2.6.19, and may be former ones that I do not know about.

A "Final" release should be "round", but never in this life highly incomplete, shouldn't it??

> 
> And unless you can become politer and more respectful and stop ranting all
> the time, you'll be in the very rare situation of hitting my auto-filters 
> and going into an email mbox of your own (read: one that I read in my 
> copious spare time. Hint: I don't _have_ any.)
> 
> 		Linus

Poor Linus!
I have got thousands of good reasons to be so rude towards some people. And I certainly know the smart polite way of the game too. I know both ways of dealing with. But if someone continues to nerve me for such a long time (whoever the specified person may be) I get out the big stick and then there will be bambule pure!

Excuse me, you are only finnish origin: "Bambule" is an invention of Ulrike Meinhof and other 68ers and stands for "revolt" or something similar.

BTW:
Wasn't it you yourself stating that if one wants changes it is not always useful to be polite??

"If you want to change something, it's not fine to be entirely polite all the time:"

(Linus Torvalds, March 6, 2007, 09:57:34, public Email).

Happy reflection, Mister Torvalds!

Uwe

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Linus Torvalds]

On Mon, 30 Apr 2007, Uwe Bugla wrote:
> 
> "If you want to change something, it's not fine to be entirely polite all the time:"

"entirely polite all the time" is totally different from "cannot _ever_ 
be polite".

Also, quite frankly, in order to be impolite, you have to build up a 
certain amount of street-cred first. For example, Al Viro can afford to be 
very abrasive, because he's pretty much shown over the years that every 
single time he flames somebody, he's right.

Anyway, I'll get out of the discussion. There's clearly some personality 
issues in the DVB area, and I don't know quite _why_ that is, but Uwe, 
you're definitely not helping.

			Linus

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Trent Piepho]

On Mon, 30 Apr 2007, Linus Torvalds wrote:
> Anyway, I'll get out of the discussion. There's clearly some personality
> issues in the DVB area, and I don't know quite _why_ that is, but Uwe,
> you're definitely not helping.

There isn't a problem here, just a lot of noise coming from one source.  I
have no problem with Mauro and think he does a good job and is an extremely
reasonable person.  He is just getting Uwe's thesaurus thrown at him
because he's the closest target.

Sure there are disagreements sometimes, but this is always the case.  I can
think of plenty of lists far more full of flames and personality conflicts
than linux-dvb.

The issue with dst is just a minor missing feature to fully support the dvb
helper module customization system.  So nobody needs to worry about this
anymore, the last two patches in this repository will fix it correctly.

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

Making dvb-pll work fully with this same system is a little more complex.
It's on the virtual todo list, but not at the top.

I'll finish with this completely unrelated quote.

------------
   "Especially important is the warning to avoid conversations with the demon.
   We may ask what is relevant but anything beyond that is dangerous.  He is a
   liar.  The demon is a liar.  He will lie to confuse us.  But he will also
   mix lies with the truth to attack us.  The attack is psychological, Damien,
   and powerful.  So don't listen to him.  Remember that - do not listen."
    - from "The Exorcist"

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Manu Abraham]

Trent Piepho wrote:

> The issue with dst is just a minor missing feature to fully support the dvb
> helper module customization system.  So nobody needs to worry about this
> anymore, the last two patches in this repository will fix it correctly.

With regards to the dst, i have explained earlier to you that

1) the dst is not a frontend
2) i do not wish to use the frontend attach methods with regards to
dst/dst_ca

To mention, we had these discussions much long back how to go about it
and don't think that every time a new developer get's an account with
linuxtv.org, this has to be a matter that has to discussed to death

http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup

(eventhough of not much concern) If you now see most of the code in
dvb-bt8xx especially the DMA stuff was refactored from the dst driver.

But that said, the dst *is* different, so WTH ?

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Markus Rechberger]

On 5/1/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Trent Piepho wrote:
>
> > The issue with dst is just a minor missing feature to fully support the
> dvb
> > helper module customization system.  So nobody needs to worry about this
> > anymore, the last two patches in this repository will fix it correctly.
>
> With regards to the dst, i have explained earlier to you that
>
> 1) the dst is not a frontend
> 2) i do not wish to use the frontend attach methods with regards to
> dst/dst_ca
>
> To mention, we had these discussions much long back how to go about it
> and don't think that every time a new developer get's an account with
> linuxtv.org, this has to be a matter that has to discussed to death
>
> http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup
>
> (eventhough of not much concern) If you now see most of the code in
> dvb-bt8xx especially the DMA stuff was refactored from the dst driver.
>
> But that said, the dst *is* different, so WTH ?
>

Please show me where this change makes your work more difficult,
Trent's change is small and I don't see the problem where it seriously
affects your work.

Markus

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 02:58:49 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: Trent Piepho <xyzzy@speakeasy.org>
CC: Michael Krufky <mkrufky@linuxtv.org>, akpm@linux-foundation.org, Linus Torvalds <torvalds@linux-foundation.org>, Linux Kernel Mailing list <linux-kernel@vger.kernel.org>, Linux DVB <linux-dvb@linuxtv.org>
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21	and	pseudo-authorities

> Trent Piepho wrote:
> 
> > The issue with dst is just a minor missing feature to fully support the
> dvb
> > helper module customization system.  So nobody needs to worry about this
> > anymore, the last two patches in this repository will fix it correctly.
> 
> With regards to the dst, i have explained earlier to you that
> 
> 1) the dst is not a frontend
> 2) i do not wish to use the frontend attach methods with regards to
> dst/dst_ca
> 
> To mention, we had these discussions much long back how to go about it
> and don't think that every time a new developer get's an account with
> linuxtv.org, this has to be a matter that has to discussed to death
> 
> http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup
> 
> (eventhough of not much concern) If you now see most of the code in
> dvb-bt8xx especially the DMA stuff was refactored from the dst driver.
> 
> But that said, the dst *is* different, so WTH ?
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Mister Manuel Abraham,

1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16!
2. You did not even want to imply to resolve that issue by incarnating that "community and synergy principle" that linux community needs to exist at all, but you just perverted it by flaming capable people - and in so far I personally would deeply recommend you to shut up now and go to hell (where you belong) without any thinkable return ticket as you are nothing else but just another motherfucker...
3. You have been ignoring my contributions out of a gesture of ignorance and arrogance and incapability of every kind of human skills for months now, and I will never even try to have any mercy for that
4. Your effort of making dvb-bt8xx cards independent from bttv has been dying out of your personified asociality, ignorance, and anti-communicative behaviour - thus the very hopeful cx878 project is another dead born child produced by your personal behaviour, asociality, ignorance, stupidity and incompatibility, with the effect that Christoph Pfister has turned off from that development tree and now is maintainer of kaffeine where he is doing a very good job, neglecting any further cooperation with you deeply asocial human being in pure incarnation
5. Mister Manuel Abraham, I am not alone just to say that I want you to vanish and shrink from here without any return ticket at all

Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again
Just goto hell, you goddamn deeply asocial miserable sonofabitch!!

Uwe

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Manu Abraham]

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] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Markus Rechberger]

Manu, also for you please stop it, we know that Uwe writes abusive
stuff but you don't have to go on with it.

It's about the patch Trent wrote if you're not able to discuss it wait
for others to comment it.
I only saw subjective reasons why you are against it, but the actual
patch doesn't cross your development there.

Markus

On 5/1/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> Uwe Bugla wrote:
>
> > 1. You utmost personally are responsible for 4 ununsable kernels, as far
> as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16!
> > 2. You did not even want to imply to resolve that issue by incarnating
> that "community and synergy principle" that linux community needs to exist
> at all, but you just perverted it by flaming capable people -
>
> You mean like this:
>
>
> -------- Original Message --------
> Subject: kernel patch practice in 2.6.13-mm2
> Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST)
> From: Uwe Bugla <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
>


-- 
Markus Rechberger

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 01 May 2007 04:19:41 +0400
Von: Manu Abraham <abraham.manu@gmail.com>
An: 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
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21	and	pseudo-authorities

> Uwe Bugla wrote:
> 
> > 1. You utmost personally are responsible for 4 ununsable kernels, as far
> as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16!
> > 2. You did not even want to imply to resolve that issue by incarnating
> that "community and synergy principle" that linux community needs to exist
> at all, but you just perverted it by flaming capable people - 
> 
> You mean like this:
> 

Yes I mean like this. But I do not only talk about me. I talk about many many others.
Above that you flamed Edgar Toernig with the invented alibi for not signing his contributions (yes I say invented alibi and I mean it exactly that way - in so far the word "gatekeeper" is no invention in this context at all, it's just a very cynical expression that shows a lot of frustration).

To get it back to the comprehensive layer:

1. 4 unusable kernels are not just another cavalier's delict, but just a very harsh and deep cut in kernel development history (read: the time space for that breakdown is close to 9 or 10 months). This could have been some three months or less if you weren't the personality that you obviously are representing.
2. Although I tried to tell you a thousand times that I prefer to optimize the existing (read: bttv dependent - even if it may sound senseless to you) concept you continued to pursue a dead born child called cx878.
This hopeful project which I would have highly admired if it ever were finished did not only die out of the personal time schedule of a very capable kaffeine developer called Christoph Pfister (who did the main work for it - not you), but it simply died as a consequence of your obviously missing knowledge.
Some i2c bus bindings were missing - in so far the mounting of a 2000 meters high mountain was cancelled 50 meters before the top.

So what do I mean by optimizing the existing concept?
Very simple: Deselectable DST module, deselectable DST_CA module, deselectable dvb-pll module - not more - not less.

Now if this very humble concept works, if all this horrible dvb_core_attach stuff and other problems are resolved let's talk about getting rid of all the not necessary bttv dependency nonsense, but never vice versa and never before that.

Read: long way, small steps, but no breakdowns.

Did I pronounce clear now, Mister Abraham? It can't be that hard to understand this, can it?

Uwe
> 
> -------- Original Message --------
> Subject: kernel patch practice in 2.6.13-mm2
> Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST)
> From: Uwe Bugla <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

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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT)
Von: Trent Piepho <xyzzy@speakeasy.org>
An: Linus Torvalds <torvalds@linux-foundation.org>
CC: Linux Kernel Mailing list <linux-kernel@vger.kernel.org>, Michael Krufky <mkrufky@linuxtv.org>, akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities

> On Mon, 30 Apr 2007, Linus Torvalds wrote:
> > Anyway, I'll get out of the discussion. There's clearly some personality
> > issues in the DVB area, and I don't know quite _why_ that is, but Uwe,
> > you're definitely not helping.
> 
> There isn't a problem here, just a lot of noise coming from one source.  I
> have no problem with Mauro and think he does a good job and is an
> extremely
> reasonable person.  He is just getting Uwe's thesaurus thrown at him
> because he's the closest target.
> 
> Sure there are disagreements sometimes, but this is always the case.  I
> can
> think of plenty of lists far more full of flames and personality conflicts
> than linux-dvb.
> 
> The issue with dst is just a minor missing feature to fully support the
> dvb
> helper module customization system.  So nobody needs to worry about this
> anymore, the last two patches in this repository will fix it correctly.
> 
> http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb
> 
> Making dvb-pll work fully with this same system is a little more complex.
> It's on the virtual todo list, but not at the top.
> 
> I'll finish with this completely unrelated quote.
> 
> ------------
>    "Especially important is the warning to avoid conversations with the
> demon.
>    We may ask what is relevant but anything beyond that is dangerous.  He
> is a
>    liar.  The demon is a liar.  He will lie to confuse us.  But he will
> also
>    mix lies with the truth to attack us.  The attack is psychological,
> Damien,
>    and powerful.  So don't listen to him.  Remember that - do not listen."
>     - from "The Exorcist"
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Piepho, you are a devil, and your links do not work at all!
Uwe


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

Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[hermann pitton]

Am Dienstag, den 01.05.2007, 01:05 +0200 schrieb Uwe Bugla:
> -------- Original-Nachricht --------
> Datum: Mon, 30 Apr 2007 15:41:03 -0700 (PDT)
> Von: Trent Piepho <xyzzy@speakeasy.org>
> An: Linus Torvalds <torvalds@linux-foundation.org>
> CC: Linux Kernel Mailing list <linux-kernel@vger.kernel.org>, Michael Krufky <mkrufky@linuxtv.org>, akpm@linux-foundation.org, Linux DVB <linux-dvb@linuxtv.org>
> Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and	pseudo-authorities
> 
> > On Mon, 30 Apr 2007, Linus Torvalds wrote:
> > > Anyway, I'll get out of the discussion. There's clearly some personality
> > > issues in the DVB area, and I don't know quite _why_ that is, but Uwe,
> > > you're definitely not helping.
> > 
> > There isn't a problem here, just a lot of noise coming from one source.  I
> > have no problem with Mauro and think he does a good job and is an
> > extremely
> > reasonable person.  He is just getting Uwe's thesaurus thrown at him
> > because he's the closest target.
> > 
> > Sure there are disagreements sometimes, but this is always the case.  I
> > can
> > think of plenty of lists far more full of flames and personality conflicts
> > than linux-dvb.
> > 
> > The issue with dst is just a minor missing feature to fully support the
> > dvb
> > helper module customization system.  So nobody needs to worry about this
> > anymore, the last two patches in this repository will fix it correctly.
> > 
> > http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb
> > 
> > Making dvb-pll work fully with this same system is a little more complex.
> > It's on the virtual todo list, but not at the top.
> > 
> > I'll finish with this completely unrelated quote.
> > 
> > ------------
> >    "Especially important is the warning to avoid conversations with the
> > demon.
> >    We may ask what is relevant but anything beyond that is dangerous.  He
> > is a
> >    liar.  The demon is a liar.  He will lie to confuse us.  But he will
> > also
> >    mix lies with the truth to attack us.  The attack is psychological,
> > Damien,
> >    and powerful.  So don't listen to him.  Remember that - do not listen."
> >     - from "The Exorcist"
> > 
> > _______________________________________________
> > linux-dvb mailing list
> > linux-dvb@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 
> Piepho, you are a devil, and your links do not work at all!
> Uwe
> 

Try again, this devil's stuff almost always works :)

Cheers,
Hermann

Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Trent Piepho]

On Sun, 29 Apr 2007, Linus Torvalds wrote:
> On Sun, 29 Apr 2007, Uwe Bugla wrote:
>
> > BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code
> > in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab:
>
> You never explained what the problem even was, apart from compiling in
> some code that you didn't need to before. Didn't it work in the end?
>
> If it worked, I don't see what the big issue was. You are getting a _lot_
> of other code in the kernel that you probably never use, you may not even
> have realized.

I'd like to explain this a bit, for people seeing these messages who haven't
been following this part of dvb development.

dvb-pll is a simple driver for a number of I2C tuners, which are used in
many many TV cards.

These are simple devices, and drivers for host controllers (which usually
support quite a few different models of tv card based on the same core chip)
often didn't use dvb-pll.  They would just re-implement an I2C tuner driver,
sometimes more than once in the same file!

The dvb tree ended up with over a dozen different re-implementations of the
same basic tuner driver.  Of course each implementation would have different
bugs, quirks, and missing features.

So we've been removing this code and using dvb-pll.  If you look at some of
my patches to do this:

 14 files changed, 14 insertions(+), 199 deletions(-)
 1 files changed, 4 insertions(+), 34 deletions(-)
 4 files changed, 17 insertions(+), 204 deletions(-)

These patches fixed bugs and added features, yet are very much net negative
when if comes to lines of code in the kernel.

> any chance to deselect the compilation of the dvb-pll.c-module, as its
> deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1.

dvb-pll has nothing to do with VIDEO_V4L1_COMPAT or VIDEO_V4L1.  Uwe is just
confused about what is causing what.

> All the almost excellent work that Michael Krufky has offered for that
> issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber
> exactly) is being wiped out and rolled back with his acknowledgement!

Uwe is probably talking about the dvb_attach() system, written mainly by
Andrew de Quincey and myself, which went into 2.6.18.  The basic concept is
that a core driver uses symbol_request() to avoid any strong references to
its helper drivers.  This way only the helper drivers that are actually
needed must be loaded.  We want to make dvb-pll use this system too, but it
doesn't fully work yet.  I have several ideas about how to solve the
problem, but it's not a high priority.

Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 18:37:00 -0700 (PDT)
Von: Trent Piepho <xyzzy@speakeasy.org>
An: Linus Torvalds <torvalds@linux-foundation.org>
CC: Uwe Bugla <uwe.bugla@gmx.de>, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, mchehab@infradead.org, mkruky@linuxtv.org, linux-dvb@linuxtv.org
Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities

> On Sun, 29 Apr 2007, Linus Torvalds wrote:
> > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> >
> > > BUT: This 2.6.21-git2 is unusable in so far as it contains regressive
> code
> > > in the dvb-section, authored by Trent Piepho, acked by Michael Krufky,
> and signed-off-by Mauro Carvalho Chehab:
> >
> > You never explained what the problem even was, apart from compiling in
> > some code that you didn't need to before. Didn't it work in the end?
> >
> > If it worked, I don't see what the big issue was. You are getting a
> _lot_
> > of other code in the kernel that you probably never use, you may not
> even
> > have realized.
> 
> I'd like to explain this a bit, for people seeing these messages who
> haven't
> been following this part of dvb development.
> 
> dvb-pll is a simple driver for a number of I2C tuners, which are used in
> many many TV cards.
> 
> These are simple devices, and drivers for host controllers (which usually
> support quite a few different models of tv card based on the same core
> chip)
> often didn't use dvb-pll.  They would just re-implement an I2C tuner
> driver,
> sometimes more than once in the same file!
> 
> The dvb tree ended up with over a dozen different re-implementations of
> the
> same basic tuner driver.  Of course each implementation would have
> different
> bugs, quirks, and missing features.
> 
> So we've been removing this code and using dvb-pll.  If you look at some
> of
> my patches to do this:
> 
>  14 files changed, 14 insertions(+), 199 deletions(-)
>  1 files changed, 4 insertions(+), 34 deletions(-)
>  4 files changed, 17 insertions(+), 204 deletions(-)
> 
> These patches fixed bugs and added features, yet are very much net
> negative
> when if comes to lines of code in the kernel.
> 
> > any chance to deselect the compilation of the dvb-pll.c-module, as its
> > deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1.
> 
> dvb-pll has nothing to do with VIDEO_V4L1_COMPAT or VIDEO_V4L1.  Uwe is
> just
> confused about what is causing what.

Hi,
I am NO WAY confused about what is causing what - I only wrote down what I say trying to compile 2.6.21-git2!

Once again, and for the last time definitely, even if you do not want to perceive what goddamn crap you have produced, Mr. Piepho:

If I want to compile drivers for a specific card ( let us call it Pinnacle PCTV SAT or TwinHan DST - just to mention two examples ) I

a. need to say yes to VIEDO_V4L1
b. CANNOT deselect dvb-pll.c (Generic pll) exactly knowing that the PCTV SAT or the TwinHan DST DO NOT need dvb-pll.c.
c. am trapped by still existing exported symbols like "dvb_pll_lg_tdvs_h06xf" in backend module dvb-bt8xx.c (line 614), which have never been a problem before this catastrophic rollback caused by you, Mr. Piepho!
d. do not see any chance to get rid of static dependencies connected with dvb-pll.c because your work is reactionary and a regression, nothing else.

Conclusion:

Linus, I would appreciate you to rip this stuff out of git2, as long as there is no compromise solution that I can live with.

This work, done by Mr. Piepho is very buggy, and buggy stuff like this does not belong into mainline.

> 
> > All the almost excellent work that Michael Krufky has offered for that
> > issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber
> > exactly) is being wiped out and rolled back with his acknowledgement!
> 
> Uwe is probably talking about the dvb_attach() system, written mainly by
> Andrew de Quincey and myself, which went into 2.6.18.  The basic concept
> is
> that a core driver uses symbol_request() to avoid any strong references to
> its helper drivers.  This way only the helper drivers that are actually
> needed must be loaded.  We want to make dvb-pll use this system too, but
> it
> doesn't fully work yet.  I have several ideas about how to solve the
> problem, but it's not a high priority.

YUP. And as long as this is not finished this stuff has absolutely no place in mainline vanilla. Basta!

All you need is to offer a possibility to deselection for dvb-pll.c for cards that never neede it! As lang as you cannot offer this or do not want to offer this there is no place in mainline for that crap work.

The dvb_attach() system worked almost perfectly optimized ( as far as RAM consommation is concerned) for me and a couple of other cards, until you Mr. Piepho, came up and offered this utmost regessive work.

It is a shame that buggy stuff like this can reach the mainline. When I first saw it I could not trust my eyes.

But seeing the complete personal situation @ linuxtv.org - well: Who wonders??
Anything is possible, even if its quality is horrible.

Uwe

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