[git pull] drm request 3

[git pull] drm request 3

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 19662 bytes --]


Fixes for default y + CONFIG_STAGING + CONFIG_DRM_NOUVEAU enabled.

Dave.

The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
  Linus Torvalds (1):
        Linux 2.6.33

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

Alex Deucher (34):
      drm/radeon/kms: add radeon i2c algo
      drm/radeon/kms: add support for hw i2c on r1xx-r5xx
      drm/radeon/kms: add workaround for rn50/rv100 servers
      drm/radeon/kms: add support for hardcoded edids in rom (v2)
      drm/radeon/kms: clean up some low-hanging magic numbers
      drm/radeon/kms: rework pll algo selection
      drm/radeon/kms: add pll quirk for toshiba laptop panel
      drm/radeon/kms/atom: clean up spread spectrum code
      drm/radeon/kms/atom: add a helper function to get the radeon connector priv
      drm/radeon/kms/r600: reduce gpu cache flushing
      drm/radeon/kms: consolidate crtc count in rdev
      drm/radeon/kms: add functions to get current pcie lanes
      drm/radeon/kms: pull power mode info from bios tables (v3)
      drm/radeon/kms: add a power state type based on power state flags
      drm/radeon/kms: add code to select power state
      drm/radeon/kms: use power states for dynamic reclocking
      drm/radeon/kms: dynclks fixes
      drm/radeon/kms: take the pm mutex when using hw i2c
      drm/radeon/kms: update atombios.h to latest upstream.
      drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx)
      drm/radeon/kms: fix prescale calculations
      drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE
      drm/radeon/kms/evergreen: fix multi-head
      drm/radeon/kms/evergreen: adapt to i2c changes
      drm/radeon/r600: fix warnings in CS checker
      drm/radeon/kms: add LVDS pll quirk for Dell Studio 15
      drm/radeon/kms: remove HDP flushes from fence emit (v2)
      drm/radeon/kms: remove unused r600_gart_clear_page
      drm/radeon/rv740: fix backend setup
      drm/radeon: fixes for r6xx/r7xx gfx init
      drm/radeon/kms/evergreen: fix typo in cursor code
      drm/radeon/kms: update new pll algo
      drm/radeon/kms/atom: fix shr/shl ops
      drm/radeon: fix typo in Makefile

Andy Shevchenko (1):
      drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi()

Ben Skeggs (17):
      drm/nv50: switch to indirect push buffer controls
      drm/nouveau: remove PUSHBUF_CAL macro
      drm/nv50: make pushbuf dma object cover entire vm
      drm/nouveau: new gem pushbuf interface, bump to 0.0.16
      drm/nouveau: allow retrieval of vbios image from debugfs
      drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table
      drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table
      drm/nouveau: merge nvbios and nouveau_bios_info
      drm/nouveau: reorganise bios header, add dcb connector type enums
      drm/nouveau: parse dcb gpio/connector tables after encoders
      drm/nouveau: check for known dcb connector types
      drm/nouveau: construct a connector table for cards that lack a real one
      drm/nouveau: use dcb connector table for creating drm connectors
      drm/nv50: enable hpd on any connector we know the gpio line for
      drm/nouveau: use dcb connector types throughout the driver
      drm/nouveau: support version 0x20 displayport tables
      drm/nouveau: report unknown connector state if lid closed

Chris Wilson (2):
      drm/i915: Replace open-coded eviction in i915_gem_idle()
      drm/i915: Record batch buffer following GPU error

Daniel Vetter (11):
      drm/i915: overlay: nuke readback to flush wc caches
      drm/i915: overlay: drop superflous gpu flushes
      drm/i915: move a gtt flush to the correct place
      drm/i915: blow away userspace mappings before fence change
      drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code
      drm/i915: fixup active list locking in object_unbind
      drm/i915: extract fence stealing code
      drm/i915: ensure lru ordering of fence_list
      drm/i915: reuse i915_gpu_idle helper
      drm/i915: clean-up i915_gem_flush_gpu_write_domain
      drm/i915: check for multiple write domains in pin_and_relocate

Dave Airlie (23):
      drm/radeon/kms: switch all KMS driver ioctls to unlocked.
      drm/radeon/kms: use udelay for short delays
      drm: switch all GEM/KMS ioctls to unlocked ioctl status.
      drm/kms: fix fb_changed = true else statement
      drm/radeon/kms: check for valid PCI bios and not OF rom
      drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page
      drm/radeon/kms: flush HDP cache on GART table updates.
      [rfc] drm/radeon/kms: pm debugging check for vbl.
      Merge remote branch 'korg/drm-core-next' into drm-next-stage
      Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
      fb: for framebuffer handover don't exit the loop early.
      Merge remote branch 'korg/drm-radeon-testing' into drm-next-stage
      Merge remote branch 'korg/drm-core-next' into drm-next-stage
      Merge remote branch 'nouveau/for-airlied' into drm-next-stage
      Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
      drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond
      Merge branch 'drm-radeon-testing' of /ssd/git/drm-radeon-next into drm-next-stage
      vga_switcheroo: initial implementation (v15)
      Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage
      drm/radeon/kms: bump the KMS version number for square tiling support.
      vga_switcheroo: fix build on platforms with no ACPI
      drm/nouveau: fix *staging* driver build with switcheroo off.
      vga_switcheroo: disable default y by new rules.

Eric Anholt (13):
      drm/i915: Don't reserve compatibility fence regs in KMS mode.
      agp/intel: Add support for Sandybridge.
      drm/i915: Add initial bits for VGA modesetting bringup on Sandybridge.
      drm/i915: Set up fence registers on sandybridge.
      drm/i915: Fix sandybridge status page setup.
      agp/intel: Use a non-reserved value for the cache field of the PTEs.
      drm/i915: Disable the surface tile swizzling on Sandybridge.
      drm/i915: Correct locking in the modesetting failure path, fixing a BUG_ON.
      agp/intel: Add a new Sandybridge HB/IG PCI ID combo.
      drm/i915: Add a new mobile Sandybridge PCI ID.
      drm/i915: Disable the hangcheck reset on Sandybridge until we add support.
      drm/i915: Correct the Sandybridge chipset info structs.
      drm/i915: More s/IS_IRONLAKE/HAS_PCH_SPLIT for Sandybridge.

Jerome Glisse (9):
      drm/radeon/kms: bogus cs recorder utilities
      drm/radeon/kms: r600/r700 command stream checker
      drm/radeon/kms: fix r600/r700 cs checker to avoid double kfree
      drm/radeon/kms: fix indirect buffer management V2
      drm/radeon/kms: fix bo's fence association
      drm/radeon/kms: simplify memory controller setup V2
      drm/radeon/kms: fix R3XX/R4XX memory controller initialization
      drm/radeon/kms: force pinning buffer into visible VRAM
      drm/radeon/kms: initialize set_surface_reg reg for rs600 asic

Jesse Barnes (6):
      drm/i915: add dynamic performance control support for Ironlake
      drm/i915: fix drps disable so unload & re-load works
      drm/i915: provide FBC status in debugfs
      drm/i915: provide self-refresh status in debugfs
      drm/i915: give up on 8xx lid status
      drm/i915: enable/disable LVDS port at DPMS time

Li Peng (2):
      drm/i915: enable memory self refresh on 9xx
      drm/i915: Fix OGLC performance regression on 945

Luca Barbieri (3):
      drm: introduce drm_gem_object_[handle_]unreference_unlocked
      Use drm_gem_object_[handle_]unreference_unlocked where possible
      drm/nouveau: fix missing spin_unlock in failure path

Maarten Maathuis (2):
      drm/ttm: handle OOM in ttm_tt_swapout
      drm/nouveau: protect channel create/destroy and irq handler with a spinlock

Marcin Kościelnicki (2):
      drm/nv50: Implement ctxprog/state generation.
      drm/nouveau: Fix noaccel/nofbaccel option descriptions.

Marcin Slusarz (3):
      drm/nouveau: fix pramdac_table range checking
      drm/nouveau: fix nouveau_i2c_find bounds checking
      drm/nouveau: fix i2ctable bounds checking

Marek Olšák (1):
      drm/radeon/kms: add support for square microtiles on r3xx-r5xx

Matt Turner (2):
      drm/nouveau: use ALIGN instead of open coding it
      drm/radeon: use ALIGN instead of open coding it

Matthew Garrett (1):
      drm/i915: Deobfuscate the render p-state obfuscation

Michel Dänzer (1):
      drm/radeon/kms: Test rdev->bios centrally in combios_get_table_offset().

Owain Ainsworth (1):
      drm/i915: reduce some of the duplication of tiling checking

Pauli Nieminen (5):
      drm/radeon/kms: Create asic structure for r300 pcie cards.
      drm/radeon: Add asic hook for dma copy to r200 cards.
      drm: Add generic multipart buffer.
      drm/radeon: Fix memory allocation failures in the preKMS command stream checking.
      drm/radeon: Fix printf type warning in 64bit system.

Pavel Roskin (1):
      drm/kms: fix spelling of "CLOCK"

Rafał Miłecki (13):
      drm/radeon/kms: add dynamic engine reclocking (V9)
      drm/radeon/kms: don't set pcie lanes for ignored power_state
      drm/radeon/kms: get_power_state early, not when processing IRQ
      drm/radeon/kms: use wait queue (events) for VBLANK sync
      drm/radeon/kms: isolate audio engine management, change fini order
      drm/radeon/kms: accept slightly overclocked power modes
      drm/radeon/kms: simplify picking power state
      drm/radeon/kms: simplify storing current and requested PM mode
      drm/radeon/kms: for downclocking non-mobility check PERFORMANCE state
      drm/radeon/kms: implement reading active PCIE lanes on R600+
      drm/radeon/kms: do not preset audio stuff and start timer when not using audio
      Revert "drm/radeon/kms: disable HDMI audio for now on rv710/rv730"
      drm/radeon/kms: do not disable audio engine twice

Randy Dunlap (1):
      drm/ttm: fix function prototype to match implementation

Zhao Yakui (1):
      drm/i915: Use a dmi quirk to skip a broken SDVO TV output.

Zhenyu Wang (4):
      drm/i915: Keep MCHBAR always enabled
      agp/intel: official names for Pineview and Ironlake
      drm/i915, agp/intel: Fix stolen memory size on Sandybridge
      drm/i915: Add dependency on the intel agp module

 drivers/char/agp/intel-agp.c                    |  123 +-
 drivers/gpu/drm/Makefile                        |    2 +-
 drivers/gpu/drm/drm_buffer.c                    |  184 +
 drivers/gpu/drm/drm_crtc_helper.c               |    6 +-
 drivers/gpu/drm/drm_drv.c                       |   44 +-
 drivers/gpu/drm/drm_edid.c                      |   30 +-
 drivers/gpu/drm/drm_fb_helper.c                 |   26 +-
 drivers/gpu/drm/drm_gem.c                       |   70 +-
 drivers/gpu/drm/i915/i915_debugfs.c             |  253 +-
 drivers/gpu/drm/i915/i915_dma.c                 |  326 +-
 drivers/gpu/drm/i915/i915_drv.c                 |   27 +-
 drivers/gpu/drm/i915/i915_drv.h                 |   69 +-
 drivers/gpu/drm/i915/i915_gem.c                 |  430 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c          |  169 +-
 drivers/gpu/drm/i915/i915_irq.c                 |  313 +-
 drivers/gpu/drm/i915/i915_reg.h                 |  170 +-
 drivers/gpu/drm/i915/i915_suspend.c             |   10 +
 drivers/gpu/drm/i915/intel_bios.c               |    3 +-
 drivers/gpu/drm/i915/intel_crt.c                |   14 +-
 drivers/gpu/drm/i915/intel_display.c            |  216 +-
 drivers/gpu/drm/i915/intel_dp.c                 |    6 +-
 drivers/gpu/drm/i915/intel_drv.h                |    2 +
 drivers/gpu/drm/i915/intel_fb.c                 |    2 +
 drivers/gpu/drm/i915/intel_hdmi.c               |    4 +-
 drivers/gpu/drm/i915/intel_i2c.c                |    2 +-
 drivers/gpu/drm/i915/intel_lvds.c               |   41 +-
 drivers/gpu/drm/i915/intel_overlay.c            |   29 +-
 drivers/gpu/drm/i915/intel_sdvo.c               |   23 +-
 drivers/gpu/drm/nouveau/Makefile                |    2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c          |  160 +-
 drivers/gpu/drm/nouveau/nouveau_bios.c          |  339 +-
 drivers/gpu/drm/nouveau/nouveau_bios.h          |  126 +-
 drivers/gpu/drm/nouveau/nouveau_calc.c          |    4 +-
 drivers/gpu/drm/nouveau/nouveau_channel.c       |   39 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c     |  167 +-
 drivers/gpu/drm/nouveau/nouveau_connector.h     |    3 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c       |   24 +
 drivers/gpu/drm/nouveau/nouveau_display.c       |    7 +-
 drivers/gpu/drm/nouveau/nouveau_dma.c           |  108 +-
 drivers/gpu/drm/nouveau/nouveau_dma.h           |   21 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c           |   13 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h           |   53 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c         |    6 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c           |  508 +-
 drivers/gpu/drm/nouveau/nouveau_hw.c            |    6 +-
 drivers/gpu/drm/nouveau/nouveau_i2c.c           |   10 +-
 drivers/gpu/drm/nouveau/nouveau_irq.c           |    5 +
 drivers/gpu/drm/nouveau/nouveau_notifier.c      |    9 +-
 drivers/gpu/drm/nouveau/nouveau_state.c         |   40 +-
 drivers/gpu/drm/nouveau/nv04_crtc.c             |    4 +-
 drivers/gpu/drm/nouveau/nv04_dac.c              |    8 +-
 drivers/gpu/drm/nouveau/nv04_dfp.c              |    4 +-
 drivers/gpu/drm/nouveau/nv04_display.c          |   49 +-
 drivers/gpu/drm/nouveau/nv04_fbcon.c            |    2 +-
 drivers/gpu/drm/nouveau/nv04_fifo.c             |    5 +
 drivers/gpu/drm/nouveau/nv04_tv.c               |    2 +-
 drivers/gpu/drm/nouveau/nv17_tv.c               |    6 +-
 drivers/gpu/drm/nouveau/nv40_fifo.c             |    5 +
 drivers/gpu/drm/nouveau/nv50_crtc.c             |    4 +-
 drivers/gpu/drm/nouveau/nv50_dac.c              |    4 +-
 drivers/gpu/drm/nouveau/nv50_display.c          |   54 +-
 drivers/gpu/drm/nouveau/nv50_fbcon.c            |    2 +-
 drivers/gpu/drm/nouveau/nv50_fifo.c             |   13 +-
 drivers/gpu/drm/nouveau/nv50_graph.c            |   74 +-
 drivers/gpu/drm/nouveau/nv50_grctx.c            | 2367 ++++++++
 drivers/gpu/drm/nouveau/nv50_instmem.c          |    2 +-
 drivers/gpu/drm/radeon/Makefile                 |    9 +-
 drivers/gpu/drm/radeon/atom.c                   |    4 -
 drivers/gpu/drm/radeon/atombios.h               | 7300 +++++++++++++----------
 drivers/gpu/drm/radeon/atombios_crtc.c          |  456 ++-
 drivers/gpu/drm/radeon/atombios_dp.c            |   64 +-
 drivers/gpu/drm/radeon/avivod.h                 |    2 +
 drivers/gpu/drm/radeon/evergreen.c              |  767 +++
 drivers/gpu/drm/radeon/evergreen_reg.h          |  176 +
 drivers/gpu/drm/radeon/r100.c                   |  176 +-
 drivers/gpu/drm/radeon/r200.c                   |   46 +
 drivers/gpu/drm/radeon/r300.c                   |  157 +-
 drivers/gpu/drm/radeon/r300_cmdbuf.c            |  280 +-
 drivers/gpu/drm/radeon/r300_reg.h               |    2 +
 drivers/gpu/drm/radeon/r420.c                   |   49 +-
 drivers/gpu/drm/radeon/r500_reg.h               |  100 +-
 drivers/gpu/drm/radeon/r520.c                   |   21 +-
 drivers/gpu/drm/radeon/r600.c                   |  190 +-
 drivers/gpu/drm/radeon/r600_audio.c             |   21 +-
 drivers/gpu/drm/radeon/r600_blit.c              |    2 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c          |   17 +-
 drivers/gpu/drm/radeon/r600_blit_shaders.c      |   10 -
 drivers/gpu/drm/radeon/r600_cp.c                |  262 +-
 drivers/gpu/drm/radeon/r600_cs.c                |  831 +++-
 drivers/gpu/drm/radeon/r600d.h                  |  467 ++-
 drivers/gpu/drm/radeon/radeon.h                 |  167 +-
 drivers/gpu/drm/radeon/radeon_agp.c             |    4 +
 drivers/gpu/drm/radeon/radeon_asic.h            |  172 +-
 drivers/gpu/drm/radeon/radeon_atombios.c        |  435 ++-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c    |  257 +
 drivers/gpu/drm/radeon/radeon_bios.c            |   50 +-
 drivers/gpu/drm/radeon/radeon_clocks.c          |   18 +-
 drivers/gpu/drm/radeon/radeon_combios.c         |  290 +-
 drivers/gpu/drm/radeon/radeon_connectors.c      |   20 +-
 drivers/gpu/drm/radeon/radeon_cp.c              |    1 +
 drivers/gpu/drm/radeon/radeon_cs.c              |    7 +-
 drivers/gpu/drm/radeon/radeon_cursor.c          |   50 +-
 drivers/gpu/drm/radeon/radeon_device.c          |  235 +-
 drivers/gpu/drm/radeon/radeon_display.c         |  332 +-
 drivers/gpu/drm/radeon/radeon_drv.c             |   14 +-
 drivers/gpu/drm/radeon/radeon_drv.h             |   46 +-
 drivers/gpu/drm/radeon/radeon_encoders.c        |  354 +-
 drivers/gpu/drm/radeon/radeon_family.h          |    5 +
 drivers/gpu/drm/radeon/radeon_fb.c              |   12 +-
 drivers/gpu/drm/radeon/radeon_gart.c            |   32 +-
 drivers/gpu/drm/radeon/radeon_gem.c             |   36 +-
 drivers/gpu/drm/radeon/radeon_i2c.c             |  768 +++-
 drivers/gpu/drm/radeon/radeon_kms.c             |   27 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c     |   29 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   20 +
 drivers/gpu/drm/radeon/radeon_mode.h            |   55 +-
 drivers/gpu/drm/radeon/radeon_object.c          |    3 +-
 drivers/gpu/drm/radeon/radeon_pm.c              |  399 ++-
 drivers/gpu/drm/radeon/radeon_reg.h             |   50 +-
 drivers/gpu/drm/radeon/radeon_ring.c            |   67 +
 drivers/gpu/drm/radeon/radeon_state.c           |  203 +-
 drivers/gpu/drm/radeon/radeon_test.c            |    2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c             |   12 +-
 drivers/gpu/drm/radeon/reg_srcs/r600            |  837 +++
 drivers/gpu/drm/radeon/rs400.c                  |   39 +-
 drivers/gpu/drm/radeon/rs600.c                  |   56 +-
 drivers/gpu/drm/radeon/rs690.c                  |   41 +-
 drivers/gpu/drm/radeon/rv515.c                  |   21 +-
 drivers/gpu/drm/radeon/rv770.c                  |  259 +-
 drivers/gpu/drm/radeon/rv770d.h                 |    2 +
 drivers/gpu/drm/ttm/ttm_tt.c                    |   18 +-
 drivers/gpu/vga/Kconfig                         |   12 +
 drivers/gpu/vga/Makefile                        |    1 +
 drivers/gpu/vga/vga_switcheroo.c                |  450 ++
 drivers/video/console/fbcon.c                   |   18 +
 drivers/video/fbmem.c                           |    1 -
 include/drm/drmP.h                              |   28 +-
 include/drm/drm_buffer.h                        |  148 +
 include/drm/drm_crtc.h                          |    2 +
 include/drm/drm_edid.h                          |    3 +
 include/drm/drm_pciids.h                        |   36 +
 include/drm/nouveau_drm.h                       |   86 +-
 include/drm/radeon_drm.h                        |    1 +
 include/drm/ttm/ttm_bo_driver.h                 |    2 +-
 include/linux/fb.h                              |    2 +
 include/linux/vga_switcheroo.h                  |   57 +
 146 files changed, 18176 insertions(+), 6374 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_buffer.c
 create mode 100644 drivers/gpu/drm/nouveau/nv50_grctx.c
 create mode 100644 drivers/gpu/drm/radeon/evergreen.c
 create mode 100644 drivers/gpu/drm/radeon/evergreen_reg.h
 create mode 100644 drivers/gpu/drm/radeon/radeon_atpx_handler.c
 create mode 100644 drivers/gpu/drm/radeon/reg_srcs/r600
 create mode 100644 drivers/gpu/vga/vga_switcheroo.c
 create mode 100644 include/drm/drm_buffer.h
 create mode 100644 include/linux/vga_switcheroo.h

Re: [git pull] drm request 3

[Linus Torvalds]

Hmm. What the hell am I supposed to do about

	(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
	(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
	(EE) NOUVEAU(0): 879:

now?

What happened to the whole backwards compatibility thing? I wasn't even 
warned that this breaks existing user space. That makes it impossible to 
_test_ new kernels. Upgrading X and the kernel in lock-step is not a valid 
model, lots of people are just using some random distribution (F12 in my 
case), and you just broke it.

I see the commit that does this was very aware of it:

	commit a1606a9596e54da90ad6209071b357a4c1b0fa82
	Author: Ben Skeggs <bskeggs@redhat.com>
	Date:   Fri Feb 12 10:27:35 2010 +1000

	    drm/nouveau: new gem pushbuf interface, bump to 0.0.16

	    This commit breaks the userspace interface, and requires a new libdrm for
	    nouveau to operate again.

	    The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
	    compatibility purposes are now gone, and replaced with the new ioctl which
	    allows for multiple push buffers to be submitted (necessary for hw index
	    buffers in the nv50 3d driver) and relocations to be applied on any buffer.

	    A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
	    for userspace modesetting have also been removed.

	    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
	    Signed-off-by: Francisco Jerez <currojerez@riseup.net>

but why the hell wasn't I made aware of it before-hand? Quite frankly, I 
probably wouldn't have pulled it.

We can't just go around breaking peoples setups. This driver is, like it 
or not, used by Fedora-12 (and probably other distros). It may say 
"staging", but that doesn't change the fact that it's in production use by 
huge distributions. Flag days aren't acceptable.

		Linus

Re: [git pull] drm request 3

[Matt Turner]

On Thu, Mar 4, 2010 at 1:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.

>From Dave's initial pull request "[git pull] drm merge" from March 1,
he does say

> *NOTE* in case you missed it: this will *break* your nvidia machine, its purely
> intentional. Rawhide should have the libdrm and driver updates necessary.

Matt Turner

Re: [git pull] drm request 3

[Matt Turner]

On Thu, Mar 4, 2010 at 1:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.

>From Dave's initial pull request "[git pull] drm merge" from March 1,
he does say

> *NOTE* in case you missed it: this will *break* your nvidia machine, its purely
> intentional. Rawhide should have the libdrm and driver updates necessary.

Matt Turner

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:18:03 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> Hmm. What the hell am I supposed to do about
> 
> 	(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
> 	(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
> 	(EE) NOUVEAU(0): 879:
> 
> now?
> 
> What happened to the whole backwards compatibility thing? I wasn't even 
> warned that this breaks existing user space. That makes it impossible to 
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid 
> model, lots of people are just using some random distribution (F12 in my 
> case), and you just broke it.
> 
> I see the commit that does this was very aware of it:
> 
> 	commit a1606a9596e54da90ad6209071b357a4c1b0fa82
> 	Author: Ben Skeggs <bskeggs@redhat.com>
> 	Date:   Fri Feb 12 10:27:35 2010 +1000
> 
> 	    drm/nouveau: new gem pushbuf interface, bump to 0.0.16
> 
> 	    This commit breaks the userspace interface, and requires a new libdrm for
> 	    nouveau to operate again.
> 
> 	    The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
> 	    compatibility purposes are now gone, and replaced with the new ioctl which
> 	    allows for multiple push buffers to be submitted (necessary for hw index
> 	    buffers in the nv50 3d driver) and relocations to be applied on any buffer.
> 
> 	    A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
> 	    for userspace modesetting have also been removed.
> 
> 	    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> 	    Signed-off-by: Francisco Jerez <currojerez@riseup.net>
> 
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I 
> probably wouldn't have pulled it.
> 
> We can't just go around breaking peoples setups. This driver is, like it 
> or not, used by Fedora-12 (and probably other distros). It may say 
> "staging", but that doesn't change the fact that it's in production use by 
> huge distributions. Flag days aren't acceptable.

Whoa, so breaking ABI in staging drivers isn't ok?  Lots of other
staging drivers are shipped by distros with compatible userspaces, but I
thought the whole point of staging was to fix up ABIs before they
became mainstream and had backwards compat guarantees, meaning that
breakage was to be expected?

Yes, it sucks, but what else should the nouveau developers have done?
They didn't want to push nouveau into mainline because they weren't
happy with the ABI yet, but it ended up getting pushed anyway as a
staging driver at your request, and now they're stuck?  Sorry this
whole thing is a bit of a wtf...

Yes Dave probably should have mentioned it in his pull request, but
that doesn't seem to be a good reason not to pull imo...

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:18:03 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> Hmm. What the hell am I supposed to do about
> 
> 	(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
> 	(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
> 	(EE) NOUVEAU(0): 879:
> 
> now?
> 
> What happened to the whole backwards compatibility thing? I wasn't even 
> warned that this breaks existing user space. That makes it impossible to 
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid 
> model, lots of people are just using some random distribution (F12 in my 
> case), and you just broke it.
> 
> I see the commit that does this was very aware of it:
> 
> 	commit a1606a9596e54da90ad6209071b357a4c1b0fa82
> 	Author: Ben Skeggs <bskeggs@redhat.com>
> 	Date:   Fri Feb 12 10:27:35 2010 +1000
> 
> 	    drm/nouveau: new gem pushbuf interface, bump to 0.0.16
> 
> 	    This commit breaks the userspace interface, and requires a new libdrm for
> 	    nouveau to operate again.
> 
> 	    The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
> 	    compatibility purposes are now gone, and replaced with the new ioctl which
> 	    allows for multiple push buffers to be submitted (necessary for hw index
> 	    buffers in the nv50 3d driver) and relocations to be applied on any buffer.
> 
> 	    A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
> 	    for userspace modesetting have also been removed.
> 
> 	    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> 	    Signed-off-by: Francisco Jerez <currojerez@riseup.net>
> 
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I 
> probably wouldn't have pulled it.
> 
> We can't just go around breaking peoples setups. This driver is, like it 
> or not, used by Fedora-12 (and probably other distros). It may say 
> "staging", but that doesn't change the fact that it's in production use by 
> huge distributions. Flag days aren't acceptable.

Whoa, so breaking ABI in staging drivers isn't ok?  Lots of other
staging drivers are shipped by distros with compatible userspaces, but I
thought the whole point of staging was to fix up ABIs before they
became mainstream and had backwards compat guarantees, meaning that
breakage was to be expected?

Yes, it sucks, but what else should the nouveau developers have done?
They didn't want to push nouveau into mainline because they weren't
happy with the ABI yet, but it ended up getting pushed anyway as a
staging driver at your request, and now they're stuck?  Sorry this
whole thing is a bit of a wtf...

Yes Dave probably should have mentioned it in his pull request, but
that doesn't seem to be a good reason not to pull imo...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:36:55 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Yes Dave probably should have mentioned it in his pull request, but
> that doesn't seem to be a good reason not to pull imo...

And now I see Dave did mention this, so what gives.  Guidance please.

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:36:55 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Yes Dave probably should have mentioned it in his pull request, but
> that doesn't seem to be a good reason not to pull imo...

And now I see Dave did mention this, so what gives.  Guidance please.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:

> On Thu, 4 Mar 2010 10:36:55 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > Yes Dave probably should have mentioned it in his pull request, but
> > that doesn't seem to be a good reason not to pull imo...
> 
> And now I see Dave did mention this, so what gives.  Guidance please.

Yeah, it's in the first one. My bad. I didn't notice, because that one got 
cancelled for other reasons and never even tested.

That doesn't change the simple basic issue: how are people with Fedora-12 
going to test any kernel out now? And are there libdrm versions that can 
handle _both_ cases, so that people can bisect things? IOW, even if you 
have a new libdrm, will it then work with the _old_ kernel too?

Backwards compatibility is really important.

		Linus

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:

> On Thu, 4 Mar 2010 10:36:55 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > Yes Dave probably should have mentioned it in his pull request, but
> > that doesn't seem to be a good reason not to pull imo...
> 
> And now I see Dave did mention this, so what gives.  Guidance please.

Yeah, it's in the first one. My bad. I didn't notice, because that one got 
cancelled for other reasons and never even tested.

That doesn't change the simple basic issue: how are people with Fedora-12 
going to test any kernel out now? And are there libdrm versions that can 
handle _both_ cases, so that people can bisect things? IOW, even if you 
have a new libdrm, will it then work with the _old_ kernel too?

Backwards compatibility is really important.

		Linus

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:51:20 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> > On Thu, 4 Mar 2010 10:36:55 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > Yes Dave probably should have mentioned it in his pull request, but
> > > that doesn't seem to be a good reason not to pull imo...
> > 
> > And now I see Dave did mention this, so what gives.  Guidance please.
> 
> Yeah, it's in the first one. My bad. I didn't notice, because that one got 
> cancelled for other reasons and never even tested.
> 
> That doesn't change the simple basic issue: how are people with Fedora-12 
> going to test any kernel out now? And are there libdrm versions that can 
> handle _both_ cases, so that people can bisect things? IOW, even if you 
> have a new libdrm, will it then work with the _old_ kernel too?
> 
> Backwards compatibility is really important.

Sure it is.  But OTOH this is very clearly a "use at your own risk"
driver.  Dave and the nouveau guys include the driver in Fedora to get
much needed test coverage, and make sure the latest bits in rawhide
work together.

The "use at your own risk" part is that you get to keep both pieces if
you try to mix and match kernels and userspace until the STAGING
moniker is removed.

If marking the driver as staging doesn't allow them to break ABI when
they need to, then it seems like they'll have no choice but to either
remove the driver from upstream and only submit it when the ABI is
stable, or fork the driver and submit a new one only when the ABI is
stable.  Neither seem particularly attractive.

Of course I'm implicitly trusting their motivation for breaking ABI in
this case, but that was very much a part of the merge discussion so
shouldn't come as a surprise to anyone.

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:51:20 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> > On Thu, 4 Mar 2010 10:36:55 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > Yes Dave probably should have mentioned it in his pull request, but
> > > that doesn't seem to be a good reason not to pull imo...
> > 
> > And now I see Dave did mention this, so what gives.  Guidance please.
> 
> Yeah, it's in the first one. My bad. I didn't notice, because that one got 
> cancelled for other reasons and never even tested.
> 
> That doesn't change the simple basic issue: how are people with Fedora-12 
> going to test any kernel out now? And are there libdrm versions that can 
> handle _both_ cases, so that people can bisect things? IOW, even if you 
> have a new libdrm, will it then work with the _old_ kernel too?
> 
> Backwards compatibility is really important.

Sure it is.  But OTOH this is very clearly a "use at your own risk"
driver.  Dave and the nouveau guys include the driver in Fedora to get
much needed test coverage, and make sure the latest bits in rawhide
work together.

The "use at your own risk" part is that you get to keep both pieces if
you try to mix and match kernels and userspace until the STAGING
moniker is removed.

If marking the driver as staging doesn't allow them to break ABI when
they need to, then it seems like they'll have no choice but to either
remove the driver from upstream and only submit it when the ABI is
stable, or fork the driver and submit a new one only when the ABI is
stable.  Neither seem particularly attractive.

Of course I'm implicitly trusting their motivation for breaking ABI in
this case, but that was very much a part of the merge discussion so
shouldn't come as a surprise to anyone.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> If marking the driver as staging doesn't allow them to break ABI when
> they need to, then it seems like they'll have no choice but to either
> remove the driver from upstream and only submit it when the ABI is
> stable, or fork the driver and submit a new one only when the ABI is
> stable.  Neither seem particularly attractive.

The thing is, they clearly didn't even _try_ to make anything compatible. 
See how all the ioctl numbers were moved around. 

And if you can't make if backwards compatible, at least you should make it 
forwards-compatible. Is it even that? I don't know. I'm kind of afraid it 
isn't. The new libdrm required for it certainly hasn't been pushed to 
Fedora-12. Will it ever be? And if it is, can you still run an old kernel 
on it?

All of these are always possible to do. We've been _very_ good at doing 
them in general. I'm complaining, because let's face it, what else can I 
do?

And btw, I'd complain about breaking backwards compatibility even if it 
wasn't just my own machine. I can pretty much guarantee that I'm not going 
to be the only one hitting this issue.

So practically speaking: what _do_ you suggest we do about all the 
regressions this will cause?

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> If marking the driver as staging doesn't allow them to break ABI when
> they need to, then it seems like they'll have no choice but to either
> remove the driver from upstream and only submit it when the ABI is
> stable, or fork the driver and submit a new one only when the ABI is
> stable.  Neither seem particularly attractive.

The thing is, they clearly didn't even _try_ to make anything compatible. 
See how all the ioctl numbers were moved around. 

And if you can't make if backwards compatible, at least you should make it 
forwards-compatible. Is it even that? I don't know. I'm kind of afraid it 
isn't. The new libdrm required for it certainly hasn't been pushed to 
Fedora-12. Will it ever be? And if it is, can you still run an old kernel 
on it?

All of these are always possible to do. We've been _very_ good at doing 
them in general. I'm complaining, because let's face it, what else can I 
do?

And btw, I'd complain about breaking backwards compatibility even if it 
wasn't just my own machine. I can pretty much guarantee that I'm not going 
to be the only one hitting this issue.

So practically speaking: what _do_ you suggest we do about all the 
regressions this will cause?

			Linus

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> If marking the driver as staging doesn't allow them to break ABI when
>> they need to, then it seems like they'll have no choice but to either
>> remove the driver from upstream and only submit it when the ABI is
>> stable, or fork the driver and submit a new one only when the ABI is
>> stable.  Neither seem particularly attractive.
>
> The thing is, they clearly didn't even _try_ to make anything compatible.
> See how all the ioctl numbers were moved around.
>
> And if you can't make if backwards compatible, at least you should make it
> forwards-compatible. Is it even that? I don't know. I'm kind of afraid it
> isn't. The new libdrm required for it certainly hasn't been pushed to
> Fedora-12. Will it ever be? And if it is, can you still run an old kernel
> on it?
>
> All of these are always possible to do. We've been _very_ good at doing
> them in general. I'm complaining, because let's face it, what else can I
> do?
>
> And btw, I'd complain about breaking backwards compatibility even if it
> wasn't just my own machine. I can pretty much guarantee that I'm not going
> to be the only one hitting this issue.
>
> So practically speaking: what _do_ you suggest we do about all the
> regressions this will cause?

At the moment in Fedora we deal with this for our users, we have dependencies
between userspace and kernel space and we upgrade the bits when they upgrade
the kernels, its a pain in the ass, but its what we accepted we needed
to do to get
nouveau in front of people. We are currently maintain 3 nouveau APIs
across F11, F12
and F13.

The main reason the API was gutted was because it supported lots of
things that weren't
supportable going forward. User modesetting support was completely
removed and this
meant lots of the API was pointless.

Now I can ask Ben if he'd like to try and supply a libdrm that could
in  theory deal
with both as a favour, but I'm not expecting the nouveau project guys
to care, we pretty
much got ourselves into this corner, and we'll pretty much have to get
ourselves out.

The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface
which justs ifdefs around this for now, and in another release or two
we rip all that out.

Of course I can't ask him either of these until normal people who live
in Australia wake
up in 2-3 hrs, as opposed to me who is sitting in the dark trying not
to wake the baby.

Dave.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> At the moment in Fedora we deal with this for our users, we have 
> dependencies between userspace and kernel space and we upgrade the bits 
> when they upgrade the kernels, its a pain in the ass, but its what we 
> accepted we needed to do to get nouveau in front of people. We are 
> currently maintain 3 nouveau APIs across F11, F12 and F13.

Can we try to make it less of a pain in the ass at some other level?

For example, I realize that it's a real pain - both for the kernel _and_ 
for the user space library - to dynamically have to support multiple 
versions of some interface. 

And doing it _statically_ (with a compile option) isn't much better, 
because you end up not only with source code from hell, you still end up 
with the problem of having to compile the libraries and the kernel for the 
same interface, and not being able to mix.

So let's say that we live with an API that changes, where none of the 
binaries (and no single version of the source code either) really support 
anything but _their_ version of the interface.

Why does it then have to be such an effing pain for the _user_?

(And by being such an effing pain for the user, it also becomes indirectly 
a pain for the distribution too - now you have all those nasty 
dependencies where you really cannot mix things up at all, and you can't 
upgrade one piece without upgrading the other).

> Now I can ask Ben if he'd like to try and supply a libdrm that could in 
> theory deal with both as a favour, but I'm not expecting the nouveau 
> project guys to care, we pretty much got ourselves into this corner, and 
> we'll pretty much have to get ourselves out.

Quite frankly, I really don't think that's a wonderful option either. 
Havign dynamic conditionals in code not only makes things worse to 
maintain, they slow things down too, and make code bigger.

So what I'd look for is a sane technical solution to the technical problem 
of "that ABI screwed up". 

And it's not like this is a new issue. We've had this several times 
before. It's called versioning, and the solution tends to pretty much 
_always_ boil down to two cases:

 - don't _ever_ change the ABI in backwards-incompatible ways, and have 
   "feature flags" to say what level of support ther is.

   This is quite common, but it really does require that backwards 
   compatibility. You can add features, but every time you add a feature, 
   you still maintain the old ones _and_ new users need to check the 
   feature flag first (and fall back on the old way of doing things if the 
   new feature isn't there)

   Clearly this one doesn't seem to work for DRM. And quite frankly, I 
   suspect it's at least partly because some DRM people aren't even
   _trying_ - possibly because they aren't even thinking about these kinds 
   of issues.

 - Install multiple versions concurrently, and know they are incompatible, 
   but pick the right one automatically.

   I really don't understand why this wouldn't solve all your distro 
   problems, _and_ solve my kind of user problems too. It's simply not 
   acceptable to just say "ok, X doesn't work". Why aren't the libdrm 
   libraries simply _versioned_?

   IOW, why can't we just have 

	/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
	/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so

   living happily side-by-side? Why can't we just switch between Fedora 
   11, 12 and 13 kernels, and automatically get the right library? The 
   glibc people do it based on hardware features. It's just a "dlopen()" 
   away.

This isn't rocket science. I shouldn't need to complain. I think it would 
make the life of even the _developers_ much easier.

Who was the less-than-rocket-scientist that decided that the right thing 
to do was to "check the kernel DRM version support, and exit with an error 
if it doesn't match"?

See what I'm saying? What I care about is that right now, it's impossible 
to switch kernels on a particular setup. That makes it effectively 
impossible to test new kernels sanely. And that really is a _technical_ 
problem.

Btw, I'm sure there are other approaches too. But I really suspect that it 
should be pretty trivial to change nouveau (and I suspect this has nothing 
nouveau-specific in it - it migth even be the X server itself that does 
the DRM version test) to instead of dying, just doing a dlopen() of the 
right version.

Wouldn't the radeon and intel driver people love to be able to do 
something like that -too-?

Seriously. The current situation is not just crap, it's _stupid_ crap.

		Linus

Re: [git pull] drm request 3

[Dave Airlie]

> Can we try to make it less of a pain in the ass at some other level?
>
> For example, I realize that it's a real pain - both for the kernel _and_
> for the user space library - to dynamically have to support multiple
> versions of some interface.
>
> And doing it _statically_ (with a compile option) isn't much better,
> because you end up not only with source code from hell, you still end up
> with the problem of having to compile the libraries and the kernel for the
> same interface, and not being able to mix.
>
> So let's say that we live with an API that changes, where none of the
> binaries (and no single version of the source code either) really support
> anything but _their_ version of the interface.
>
> Why does it then have to be such an effing pain for the _user_?
>
> (And by being such an effing pain for the user, it also becomes indirectly
> a pain for the distribution too - now you have all those nasty
> dependencies where you really cannot mix things up at all, and you can't
> upgrade one piece without upgrading the other).
>
>> Now I can ask Ben if he'd like to try and supply a libdrm that could in
>> theory deal with both as a favour, but I'm not expecting the nouveau
>> project guys to care, we pretty much got ourselves into this corner, and
>> we'll pretty much have to get ourselves out.
>
> Quite frankly, I really don't think that's a wonderful option either.
> Havign dynamic conditionals in code not only makes things worse to
> maintain, they slow things down too, and make code bigger.
>
> So what I'd look for is a sane technical solution to the technical problem
> of "that ABI screwed up".
>
> And it's not like this is a new issue. We've had this several times
> before. It's called versioning, and the solution tends to pretty much
> _always_ boil down to two cases:
>
>  - don't _ever_ change the ABI in backwards-incompatible ways, and have
>   "feature flags" to say what level of support ther is.
>
>   This is quite common, but it really does require that backwards
>   compatibility. You can add features, but every time you add a feature,
>   you still maintain the old ones _and_ new users need to check the
>   feature flag first (and fall back on the old way of doing things if the
>   new feature isn't there)
>
>   Clearly this one doesn't seem to work for DRM. And quite frankly, I
>   suspect it's at least partly because some DRM people aren't even
>   _trying_ - possibly because they aren't even thinking about these kinds
>   of issues.

We've done this exactly like this since the drm went upstream, I think
there has been one interface incompatible change in the kernel drm since
it was upstream, in i810 back in the XFree86 days. KMS required new config
options since moving the card init into the kernel, was going to break
or be broken
by a userspace driver reiniting that card, and we've retained compatiblity
with older drivers fine.

So you are tarring the whole drm with the interface to one driver
which is clearly
marked as having an unstable ABI. Nouveau is different, they have had no
reason to version or make a stable interface until they could design
an interface
that would expose the features of the hw that they are trying to build
a driver for.
They've also used the timing to drop all support for legacy user modesetting
drivers while they could, before it was deployed on a lot of people's machines
in a lot of places.


>   I really don't understand why this wouldn't solve all your distro
>   problems, _and_ solve my kind of user problems too. It's simply not
>   acceptable to just say "ok, X doesn't work". Why aren't the libdrm
>   libraries simply _versioned_?

This would require redesigning the whole way distros build and distribute
packages. Having to build 4-5 versions of nouveau for each version of Fedora
would be a major increase in overheads for a minimal amount of return.

>
>   IOW, why can't we just have
>
>        /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
>        /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so
>
>   living happily side-by-side? Why can't we just switch between Fedora
>   11, 12 and 13 kernels, and automatically get the right library? The
>   glibc people do it based on hardware features. It's just a "dlopen()"
>   away.
>
> This isn't rocket science. I shouldn't need to complain. I think it would
> make the life of even the _developers_ much easier.
>
> Who was the less-than-rocket-scientist that decided that the right thing
> to do was to "check the kernel DRM version support, and exit with an error
> if it doesn't match"?
>
> See what I'm saying? What I care about is that right now, it's impossible
> to switch kernels on a particular setup. That makes it effectively
> impossible to test new kernels sanely. And that really is a _technical_
> problem.
>
> Btw, I'm sure there are other approaches too. But I really suspect that it
> should be pretty trivial to change nouveau (and I suspect this has nothing
> nouveau-specific in it - it migth even be the X server itself that does
> the DRM version test) to instead of dying, just doing a dlopen() of the
> right version.
>
> Wouldn't the radeon and intel driver people love to be able to do
> something like that -too-?

Speaking as distro maintainer here,

No because we've got versioned interfaces and we are happy to support them
yes it would be nice sometimes to dream about this, but its a major explosion in
the testing matrix. You have to realise the more codepaths a distro ships, the
more codepath it has to keep track off for security issues, for bug fixes, etc.

When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
out it has a security issue? Here's the thing, distros are trying to ship an
OS with a consistent set of packages, not a pick-n-mix.

I'm going to talk to Ben when we both make it to the same place, from a
nouveau point-of-view I'm quite happy what they've done is technically the
correct solution for them, because otherwise you end up with too many
versions of things to support, and you get distros who aren't willing to put
any developer effort into the project, shipping 3 different versions of things,
(this happens with binary drivers, and its a nightmare).

The thing with redesigning the whole stack like you say, its you are optimising
for the wrong use case, this isn't a common case, this is one off
event that we've
been forced into by merging nouveau upstream. I'd rather not optimise
for this case
if we can get away with it.

Dave.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> Speaking as distro maintainer here,
> 
> No because we've got versioned interfaces and we are happy to support them
> yes it would be nice sometimes to dream about this, but its a major explosion in
> the testing matrix. You have to realise the more codepaths a distro ships, the
> more codepath it has to keep track off for security issues, for bug fixes, etc.

I think you're missing the whole point here. There's no new and complex 
"testing matrix". You only ever test the newest version, so there's no 
additional testing.

Here's the "inductive proof":

 - if the version number doesn't change, you aren't doing anything that is 
   at all different from what you already do.

 - if the version number _does_ change, it does so only because you 
   updated both the kernel component and the libdrm component together, 
   and you test them together - exactly like you already do.

So there is absolutely no difference for you. In either case, you only 
ever test paired up versions. If you make a new version, it will never 
_ever_ interact with old versions. There's no new complex testing needed.

The only thing it allows is for you to have multiple kernels installed 
simultaneously - and be able to _use_ them all. Which is something you 
already do.

And which the current model doesn't allow for. You may have three 
different kernels installed, but if libdrm got updated with a version 
change, only one of those kernels will actually _work_.

> When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> out it has a security issue?

Irrelevant and total red herring. You never care about older versions, 
since if people have updated, they are running the newer version.

So the older versions are there purely so that you _can_ have multiple 
different kernels, and so that your _developers_ can compile new kernels 
for older distributions. They aren't relevant for the case you point to: 
if somebody is just doing "yum update", they'll get - and use - the newer 
version anyway.

> Here's the thing, distros are trying to ship an OS with a consistent set 
> of packages, not a pick-n-mix.

But here's the thing: if you expect people to do development, they _need_ 
to be able to mix things. A kernel developer needs to be able to update 
their kernel. And a kernel _tester_ needs to be able to test that kernel.

Seriously: what do you expect me to do right now in my situation?

I'm not going to release a kernel that I can't test. So if I can't get a 
libdrm that works in my F12 environment, I will _have_ to revert that 
patch that you asked me to merge.

Really. Look at it from my standpoint. Look at it from _any_ kernel 
developer standpoint. It would be totally irresponsible of me to release 
2.6.34 without even eating my own dog-food on my own main machine. Can't 
you see that this is obviously true?

So right now, I'm running with that patch reverted on that machine. I 
haven't committed the revert, and quite frankly, I'd really prefer not to. 
But the only way that "not revert" case can really happen is if there is 
some other way for me to have a working machine again.

Think about it. Tell me what the solution is.

		Linus

Re: [git pull] drm request 3

[Ben Skeggs]

On Thu, 2010-03-04 at 16:08 -0800, Linus Torvalds wrote:
> 
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > Speaking as distro maintainer here,
> > 
> > No because we've got versioned interfaces and we are happy to support them
> > yes it would be nice sometimes to dream about this, but its a major explosion in
> > the testing matrix. You have to realise the more codepaths a distro ships, the
> > more codepath it has to keep track off for security issues, for bug fixes, etc.
> 
> I think you're missing the whole point here. There's no new and complex 
> "testing matrix". You only ever test the newest version, so there's no 
> additional testing.
> 
> Here's the "inductive proof":
> 
>  - if the version number doesn't change, you aren't doing anything that is 
>    at all different from what you already do.
> 
>  - if the version number _does_ change, it does so only because you 
>    updated both the kernel component and the libdrm component together, 
>    and you test them together - exactly like you already do.
> 
> So there is absolutely no difference for you. In either case, you only 
> ever test paired up versions. If you make a new version, it will never 
> _ever_ interact with old versions. There's no new complex testing needed.
> 
> The only thing it allows is for you to have multiple kernels installed 
> simultaneously - and be able to _use_ them all. Which is something you 
> already do.
> 
> And which the current model doesn't allow for. You may have three 
> different kernels installed, but if libdrm got updated with a version 
> change, only one of those kernels will actually _work_.
> 
> > When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> > out it has a security issue?
> 
> Irrelevant and total red herring. You never care about older versions, 
> since if people have updated, they are running the newer version.
> 
> So the older versions are there purely so that you _can_ have multiple 
> different kernels, and so that your _developers_ can compile new kernels 
> for older distributions. They aren't relevant for the case you point to: 
> if somebody is just doing "yum update", they'll get - and use - the newer 
> version anyway.
> 
> > Here's the thing, distros are trying to ship an OS with a consistent set 
> > of packages, not a pick-n-mix.
> 
> But here's the thing: if you expect people to do development, they _need_ 
> to be able to mix things. A kernel developer needs to be able to update 
> their kernel. And a kernel _tester_ needs to be able to test that kernel.
Here's the thing.  *You* pushed for nouveau to go into staging before
any of the developers were ready for it.  Two of the big reasons (from
my POV) for not requesting inclusion were the context programs (which
have since been dealt with) and that yes, we have no intention of
keeping crusty APIs around when they aren't what we require.

The idea of staging was to allow for exactly the second problem, so why
are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
expect that for the most part people will be using our packages, which
deal with the ABI issues.

> 
> Seriously: what do you expect me to do right now in my situation?
> 
> I'm not going to release a kernel that I can't test. So if I can't get a 
> libdrm that works in my F12 environment, I will _have_ to revert that 
> patch that you asked me to merge.
The F13 packages *will* work, so long as you're not bisecting back and
forth.

> 
> Really. Look at it from my standpoint. Look at it from _any_ kernel 
> developer standpoint. It would be totally irresponsible of me to release 
> 2.6.34 without even eating my own dog-food on my own main machine. Can't 
> you see that this is obviously true?
With the release of 2.6.34 it'll require people to update userspace
*once*, if they're rolling their own kernels and not using distro
provided packages they should be able to handle that much.

I agree it's a pain to bisect through, really.  But it's far far from
the common use case.

Ben.

> 
> So right now, I'm running with that patch reverted on that machine. I 
> haven't committed the revert, and quite frankly, I'd really prefer not to. 
> But the only way that "not revert" case can really happen is if there is 
> some other way for me to have a working machine again.
> 
> Think about it. Tell me what the solution is.
> 
> 		Linus
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Ben Skeggs]

On Thu, 2010-03-04 at 16:08 -0800, Linus Torvalds wrote:
> 
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > Speaking as distro maintainer here,
> > 
> > No because we've got versioned interfaces and we are happy to support them
> > yes it would be nice sometimes to dream about this, but its a major explosion in
> > the testing matrix. You have to realise the more codepaths a distro ships, the
> > more codepath it has to keep track off for security issues, for bug fixes, etc.
> 
> I think you're missing the whole point here. There's no new and complex 
> "testing matrix". You only ever test the newest version, so there's no 
> additional testing.
> 
> Here's the "inductive proof":
> 
>  - if the version number doesn't change, you aren't doing anything that is 
>    at all different from what you already do.
> 
>  - if the version number _does_ change, it does so only because you 
>    updated both the kernel component and the libdrm component together, 
>    and you test them together - exactly like you already do.
> 
> So there is absolutely no difference for you. In either case, you only 
> ever test paired up versions. If you make a new version, it will never 
> _ever_ interact with old versions. There's no new complex testing needed.
> 
> The only thing it allows is for you to have multiple kernels installed 
> simultaneously - and be able to _use_ them all. Which is something you 
> already do.
> 
> And which the current model doesn't allow for. You may have three 
> different kernels installed, but if libdrm got updated with a version 
> change, only one of those kernels will actually _work_.
> 
> > When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> > out it has a security issue?
> 
> Irrelevant and total red herring. You never care about older versions, 
> since if people have updated, they are running the newer version.
> 
> So the older versions are there purely so that you _can_ have multiple 
> different kernels, and so that your _developers_ can compile new kernels 
> for older distributions. They aren't relevant for the case you point to: 
> if somebody is just doing "yum update", they'll get - and use - the newer 
> version anyway.
> 
> > Here's the thing, distros are trying to ship an OS with a consistent set 
> > of packages, not a pick-n-mix.
> 
> But here's the thing: if you expect people to do development, they _need_ 
> to be able to mix things. A kernel developer needs to be able to update 
> their kernel. And a kernel _tester_ needs to be able to test that kernel.
Here's the thing.  *You* pushed for nouveau to go into staging before
any of the developers were ready for it.  Two of the big reasons (from
my POV) for not requesting inclusion were the context programs (which
have since been dealt with) and that yes, we have no intention of
keeping crusty APIs around when they aren't what we require.

The idea of staging was to allow for exactly the second problem, so why
are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
expect that for the most part people will be using our packages, which
deal with the ABI issues.

> 
> Seriously: what do you expect me to do right now in my situation?
> 
> I'm not going to release a kernel that I can't test. So if I can't get a 
> libdrm that works in my F12 environment, I will _have_ to revert that 
> patch that you asked me to merge.
The F13 packages *will* work, so long as you're not bisecting back and
forth.

> 
> Really. Look at it from my standpoint. Look at it from _any_ kernel 
> developer standpoint. It would be totally irresponsible of me to release 
> 2.6.34 without even eating my own dog-food on my own main machine. Can't 
> you see that this is obviously true?
With the release of 2.6.34 it'll require people to update userspace
*once*, if they're rolling their own kernels and not using distro
provided packages they should be able to handle that much.

I agree it's a pain to bisect through, really.  But it's far far from
the common use case.

Ben.

> 
> So right now, I'm running with that patch reverted on that machine. I 
> haven't committed the revert, and quite frankly, I'd really prefer not to. 
> But the only way that "not revert" case can really happen is if there is 
> some other way for me to have a working machine again.
> 
> Think about it. Tell me what the solution is.
> 
> 		Linus
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Ben Skeggs wrote:
> 
> The idea of staging was to allow for exactly the second problem, so why
> are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
> expect that for the most part people will be using our packages, which
> deal with the ABI issues.

The fact that Fedora ships nouveau is _not_ irrelevant.

That fact was what made it so important to get it merged. The distro rules 
wrt the kernel have been (for _years_ - before nouveau was ever even used 
by Fedora) that whole "upstream first".

I don't understand how you can even call it irrelevant. The very fact that 
Fedora started using Nouveau was - and is - the whole reason for this 
issue. 

> > I'm not going to release a kernel that I can't test. So if I can't get a 
> > libdrm that works in my F12 environment, I will _have_ to revert that 
> > patch that you asked me to merge.
>
> The F13 packages *will* work, so long as you're not bisecting back and
> forth.

How do I install just the F13 libdrm thing, without changing everything 
else? I'm willing to try. We can make it part of the 2.6.34 release notes.

And if we end up having people bisecting back and forth, I will hate that 
f*cking nouveau driver even more.

				Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Ben Skeggs wrote:
> 
> The idea of staging was to allow for exactly the second problem, so why
> are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
> expect that for the most part people will be using our packages, which
> deal with the ABI issues.

The fact that Fedora ships nouveau is _not_ irrelevant.

That fact was what made it so important to get it merged. The distro rules 
wrt the kernel have been (for _years_ - before nouveau was ever even used 
by Fedora) that whole "upstream first".

I don't understand how you can even call it irrelevant. The very fact that 
Fedora started using Nouveau was - and is - the whole reason for this 
issue. 

> > I'm not going to release a kernel that I can't test. So if I can't get a 
> > libdrm that works in my F12 environment, I will _have_ to revert that 
> > patch that you asked me to merge.
>
> The F13 packages *will* work, so long as you're not bisecting back and
> forth.

How do I install just the F13 libdrm thing, without changing everything 
else? I'm willing to try. We can make it part of the 2.6.34 release notes.

And if we end up having people bisecting back and forth, I will hate that 
f*cking nouveau driver even more.

				Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Luc Verhaegen]

On Thu, Mar 04, 2010 at 04:41:19PM -0800, Linus Torvalds wrote:
> 
> 
> > The F13 packages *will* work, so long as you're not bisecting back and
> > forth.
> 
> How do I install just the F13 libdrm thing, without changing everything 
> else? I'm willing to try. We can make it part of the 2.6.34 release notes.
> 
> And if we end up having people bisecting back and forth, I will hate that 
> f*cking nouveau driver even more.
> 
> 				Linus

libdrm is composed of the main libdrm, and several driver specific 
libdrms today (... and libkms, yes).

While the main libdrm is relatively stable, the library specific ones 
move all the time, and there is only one version that is being tracked, 
and that is being bumped all the time. The most recent one:

http://cgit.freedesktop.org/mesa/drm/commit/?id=b5495527

Only drivers depend on the driver specific libdrms.

The xserver is compatible all the way to libdrm 2.3.0, which was tagged 
august 2006. xf86-video- drivers might depend on newer driver specific 
libdrms.

And when the mesa tree is taken apart, when drivers are taken out of it, 
you'll find that its real dependency is also 2.3.0. It's the mesa 
drivers that are responsible for the main mesa dependency on libdrm 
2.4.15.

Luc Verhaegen.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Luc Verhaegen]

On Thu, Mar 04, 2010 at 04:41:19PM -0800, Linus Torvalds wrote:
> 
> 
> > The F13 packages *will* work, so long as you're not bisecting back and
> > forth.
> 
> How do I install just the F13 libdrm thing, without changing everything 
> else? I'm willing to try. We can make it part of the 2.6.34 release notes.
> 
> And if we end up having people bisecting back and forth, I will hate that 
> f*cking nouveau driver even more.
> 
> 				Linus

libdrm is composed of the main libdrm, and several driver specific 
libdrms today (... and libkms, yes).

While the main libdrm is relatively stable, the library specific ones 
move all the time, and there is only one version that is being tracked, 
and that is being bumped all the time. The most recent one:

http://cgit.freedesktop.org/mesa/drm/commit/?id=b5495527

Only drivers depend on the driver specific libdrms.

The xserver is compatible all the way to libdrm 2.3.0, which was tagged 
august 2006. xf86-video- drivers might depend on newer driver specific 
libdrms.

And when the mesa tree is taken apart, when drivers are taken out of it, 
you'll find that its real dependency is also 2.3.0. It's the mesa 
drivers that are responsible for the main mesa dependency on libdrm 
2.4.15.

Luc Verhaegen.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Luc Verhaegen wrote:
> 
> libdrm is composed of the main libdrm, and several driver specific 
> libdrms today (... and libkms, yes).

It's actually not libdrm that is the primary issue, I'm sorry for saying 
that.

It's the nouveau_drv.so thing - the actual X driver. 

Anyway, since I had looked at the libdrm sources, I had most of this on my 
machine anyway, so I've compiled it all, and am going to reboot and see if 
I can make a few symlinks work.

IOW, right now I have this:

   [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
   [root@nehalem drivers]# ll nouveau_drv.so*
   lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
   -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
   -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16

and I'll see if that works (yeah, yeah, I didn't strip the thing, and 
it's compiled with whatever defaults that probably include debugging too, 
so it's huge).

Quite frankly, I still think that I shouldn't have to play these kinds of 
games. I think the versioning should be built in. And I still think that 
"staging" is not an excuse for "it's bad crap, and we don't care"

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Luc Verhaegen wrote:
> 
> libdrm is composed of the main libdrm, and several driver specific 
> libdrms today (... and libkms, yes).

It's actually not libdrm that is the primary issue, I'm sorry for saying 
that.

It's the nouveau_drv.so thing - the actual X driver. 

Anyway, since I had looked at the libdrm sources, I had most of this on my 
machine anyway, so I've compiled it all, and am going to reboot and see if 
I can make a few symlinks work.

IOW, right now I have this:

   [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
   [root@nehalem drivers]# ll nouveau_drv.so*
   lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
   -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
   -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16

and I'll see if that works (yeah, yeah, I didn't strip the thing, and 
it's compiled with whatever defaults that probably include debugging too, 
so it's huge).

Quite frankly, I still think that I shouldn't have to play these kinds of 
games. I think the versioning should be built in. And I still think that 
"staging" is not an excuse for "it's bad crap, and we don't care"

			Linus

Re: [git pull] drm request 3

[Luc Verhaegen]

On Thu, Mar 04, 2010 at 05:08:00PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 5 Mar 2010, Luc Verhaegen wrote:
> > 
> > libdrm is composed of the main libdrm, and several driver specific 
> > libdrms today (... and libkms, yes).
> 
> It's actually not libdrm that is the primary issue, I'm sorry for saying 
> that.
> 
> It's the nouveau_drv.so thing - the actual X driver. 
> 
> Anyway, since I had looked at the libdrm sources, I had most of this on my 
> machine anyway, so I've compiled it all, and am going to reboot and see if 
> I can make a few symlinks work.
> 
> IOW, right now I have this:
> 
>    [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>    [root@nehalem drivers]# ll nouveau_drv.so*
>    lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
>    -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
>    -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16
> 
> and I'll see if that works (yeah, yeah, I didn't strip the thing, and 
> it's compiled with whatever defaults that probably include debugging too, 
> so it's huge).
> 
> Quite frankly, I still think that I shouldn't have to play these kinds of 
> games. I think the versioning should be built in. And I still think that 
> "staging" is not an excuse for "it's bad crap, and we don't care"
> 
> 			Linus

In an ideal world, you shouldn't be forced to update anything except 
some/all of the driver bits.

But the fact that libdrm is lumped together as it is, and that mesa is a 
monolith, forces you to update a more significant portion of your 
system. You have to resort to some serious manual labour to get around 
that atm.

Luc Verhaegen.

Re: [git pull] drm request 3

[Luc Verhaegen]

On Thu, Mar 04, 2010 at 05:08:00PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 5 Mar 2010, Luc Verhaegen wrote:
> > 
> > libdrm is composed of the main libdrm, and several driver specific 
> > libdrms today (... and libkms, yes).
> 
> It's actually not libdrm that is the primary issue, I'm sorry for saying 
> that.
> 
> It's the nouveau_drv.so thing - the actual X driver. 
> 
> Anyway, since I had looked at the libdrm sources, I had most of this on my 
> machine anyway, so I've compiled it all, and am going to reboot and see if 
> I can make a few symlinks work.
> 
> IOW, right now I have this:
> 
>    [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>    [root@nehalem drivers]# ll nouveau_drv.so*
>    lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
>    -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
>    -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16
> 
> and I'll see if that works (yeah, yeah, I didn't strip the thing, and 
> it's compiled with whatever defaults that probably include debugging too, 
> so it's huge).
> 
> Quite frankly, I still think that I shouldn't have to play these kinds of 
> games. I think the versioning should be built in. And I still think that 
> "staging" is not an excuse for "it's bad crap, and we don't care"
> 
> 			Linus

In an ideal world, you shouldn't be forced to update anything except 
some/all of the driver bits.

But the fact that libdrm is lumped together as it is, and that mesa is a 
monolith, forces you to update a more significant portion of your 
system. You have to resort to some serious manual labour to get around 
that atm.

Luc Verhaegen.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Luc Verhaegen wrote:
> 
> In an ideal world, you shouldn't be forced to update anything except 
> some/all of the driver bits.
> 
> But the fact that libdrm is lumped together as it is, and that mesa is a 
> monolith, forces you to update a more significant portion of your 
> system. You have to resort to some serious manual labour to get around 
> that atm.

Ok, that probably explains my messy screen and failure with the above 
simplistic approach - I didn't do the whole mesa thing, I just did the 
drivers.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Luc Verhaegen wrote:
> 
> In an ideal world, you shouldn't be forced to update anything except 
> some/all of the driver bits.
> 
> But the fact that libdrm is lumped together as it is, and that mesa is a 
> monolith, forces you to update a more significant portion of your 
> system. You have to resort to some serious manual labour to get around 
> that atm.

Ok, that probably explains my messy screen and failure with the above 
simplistic approach - I didn't do the whole mesa thing, I just did the 
drivers.

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> Anyway, since I had looked at the libdrm sources, I had most of this on my 
> machine anyway, so I've compiled it all, and am going to reboot and see if 
> I can make a few symlinks work.
> 
> IOW, right now I have this:
> 
>    [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>    [root@nehalem drivers]# ll nouveau_drv.so*
>    lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
>    -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
>    -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16

Naah, I just end up with a really screwed up screen with that. I probably 
did something wrong in the configuration phase or something. I'll look for 
the precompiled ones, and hope they don't have some other odd 
dependencies.

		Linus

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> Anyway, since I had looked at the libdrm sources, I had most of this on my
>> machine anyway, so I've compiled it all, and am going to reboot and see if
>> I can make a few symlinks work.
>>
>> IOW, right now I have this:
>>
>>    [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>>    [root@nehalem drivers]# ll nouveau_drv.so*
>>    lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
>>    -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
>>    -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16
>
> Naah, I just end up with a really screwed up screen with that. I probably
> did something wrong in the configuration phase or something. I'll look for
> the precompiled ones, and hope they don't have some other odd
> dependencies.

Looks like libdrm_nouveau didn't get updated along with nouveau.

We don't have mesa in F12 so that won't matter.

wget http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.18/1.fc13/src/libdrm-2.4.18-1.fc13.src.rpm
rpmbuild --rebuild libdrm-2.4.18-1.fc13.src.rpm

rpm -Uvh ~/rpmbuild/RPMS/libdrm-2.4.18-1.fc13.x86_64.rpm
~/rpmbuild/RPMS/libdrm-devel-2.4.18-1.fc13.x86_64.rpm

wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
rebuild + install.

Dave.

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> Anyway, since I had looked at the libdrm sources, I had most of this on my
>> machine anyway, so I've compiled it all, and am going to reboot and see if
>> I can make a few symlinks work.
>>
>> IOW, right now I have this:
>>
>>    [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>>    [root@nehalem drivers]# ll nouveau_drv.so*
>>    lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
>>    -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
>>    -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16
>
> Naah, I just end up with a really screwed up screen with that. I probably
> did something wrong in the configuration phase or something. I'll look for
> the precompiled ones, and hope they don't have some other odd
> dependencies.

Looks like libdrm_nouveau didn't get updated along with nouveau.

We don't have mesa in F12 so that won't matter.

wget http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.18/1.fc13/src/libdrm-2.4.18-1.fc13.src.rpm
rpmbuild --rebuild libdrm-2.4.18-1.fc13.src.rpm

rpm -Uvh ~/rpmbuild/RPMS/libdrm-2.4.18-1.fc13.x86_64.rpm
~/rpmbuild/RPMS/libdrm-devel-2.4.18-1.fc13.x86_64.rpm

wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
rebuild + install.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
> rebuild + install.

This one doesn't work on F12.

It wants xorg-x11-server-devel > 1.7.99.3-3.

Is there some limited set of rpm's I can get from the f13 archive? 

		Linus

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 5 Mar 2010, Dave Airlie wrote:
>>
>> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
>> rebuild + install.
>
> This one doesn't work on F12.
>
> It wants xorg-x11-server-devel > 1.7.99.3-3.
>
> Is there some limited set of rpm's I can get from the f13 archive?

If by limited you mean the whole X server + udev updates that would work,

if not then:
http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm

That src rpm should be rebuildable on F12, I just removed the requires
on F13 stuff.

Dave.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 5 Mar 2010, Dave Airlie wrote:
>>
>> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
>> rebuild + install.
>
> This one doesn't work on F12.
>
> It wants xorg-x11-server-devel > 1.7.99.3-3.
>
> Is there some limited set of rpm's I can get from the f13 archive?

If by limited you mean the whole X server + udev updates that would work,

if not then:
http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm

That src rpm should be rebuildable on F12, I just removed the requires
on F13 stuff.

Dave.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> if not then:
> http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
> 
> That src rpm should be rebuildable on F12, I just removed the requires
> on F13 stuff.

Well, that wants the new kernel, but I can force it with --nodeps..

I'll reboot and test.

		Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> if not then:
> http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
> 
> That src rpm should be rebuildable on F12, I just removed the requires
> on F13 stuff.

Well, that wants the new kernel, but I can force it with --nodeps..

I'll reboot and test.

		Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > if not then:
> > http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
> > 
> > That src rpm should be rebuildable on F12, I just removed the requires
> > on F13 stuff.
> 
> Well, that wants the new kernel, but I can force it with --nodeps..
> 
> I'll reboot and test.

Bingo. 

Could this be done as a real F12 binary package (maybe call it 
"force-nouveau-0.0.16" or something) for testers to use? I had most of the 
X devel tools set up anyway since I used to build intel drivers from git 
for one of my experimental machines. And I guess most kernel devs can 
generally easily do the rpm build, but I'd hate to lose any more plain 
testers than I absolutely have to.

And it would make it way easier for people to try out their kernel, notice 
that X doesn't work, and then let them know that something like a simple

	yum install force-nouveau-0.0.16

makes it work. Compared to having them install X builds, do a "rpm -Uvh 
--nodeps" etc etc.

Anyway, this at least makes me feel like I don't have to revert that 
commit just to be able to test current -git again. Thanks,

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > if not then:
> > http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
> > 
> > That src rpm should be rebuildable on F12, I just removed the requires
> > on F13 stuff.
> 
> Well, that wants the new kernel, but I can force it with --nodeps..
> 
> I'll reboot and test.

Bingo. 

Could this be done as a real F12 binary package (maybe call it 
"force-nouveau-0.0.16" or something) for testers to use? I had most of the 
X devel tools set up anyway since I used to build intel drivers from git 
for one of my experimental machines. And I guess most kernel devs can 
generally easily do the rpm build, but I'd hate to lose any more plain 
testers than I absolutely have to.

And it would make it way easier for people to try out their kernel, notice 
that X doesn't work, and then let them know that something like a simple

	yum install force-nouveau-0.0.16

makes it work. Compared to having them install X builds, do a "rpm -Uvh 
--nodeps" etc etc.

Anyway, this at least makes me feel like I don't have to revert that 
commit just to be able to test current -git again. Thanks,

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
> rebuild + install.

This one doesn't work on F12.

It wants xorg-x11-server-devel > 1.7.99.3-3.

Is there some limited set of rpm's I can get from the f13 archive? 

		Linus



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> Anyway, since I had looked at the libdrm sources, I had most of this on my 
> machine anyway, so I've compiled it all, and am going to reboot and see if 
> I can make a few symlinks work.
> 
> IOW, right now I have this:
> 
>    [root@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>    [root@nehalem drivers]# ll nouveau_drv.so*
>    lrwxrwxrwx 1 root root      21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16
>    -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
>    -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16

Naah, I just end up with a really screwed up screen with that. I probably 
did something wrong in the configuration phase or something. I'll look for 
the precompiled ones, and hope they don't have some other odd 
dependencies.

		Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Upstream first policy

[Kyle McMartin]

On Thu, Mar 04, 2010 at 04:41:19PM -0800, Linus Torvalds wrote:
> That fact was what made it so important to get it merged. The distro rules 
> wrt the kernel have been (for _years_ - before nouveau was ever even used 
> by Fedora) that whole "upstream first".
> 

As nice as that is, I'm not sure *any* real distro follows it. (Ok,
Gentoo seems to only ship ~100K of diff in their genpatches dir[1],
good on them.)

We *try* to only merge things in Fedora that will be heading upstream
quickly, or are backports from -next. Things occasionally, you know,
don't, like the execshield crap, lirc, and utrace.

Nouveau, you obviously know about, I think Adam merged it into Fedora
for the sole reason of providing a slightly less crap experience for
Nvidia cards prior to G80 where the nv driver got slightly better.
(Though, obviously Nouveau is now compelling for more reasons than just
being able to light up a second head.) This is obviously now more
difficult now that nouveau binds by default on boot with KMS.

It would be /great/ if we had more people cleaning up staging drivers
so that more stuff could go in there. But it seems people are more
interested in re-indenting code than actually fixing things. (I can
understand a certain reticence to this, since it's sometimes hard to fix
real problems in drivers if you can't test it.) I'm not sure what the
latest round of staging changes looks like off hand, but I'm going to
guess that more stuff was punted for unmaintenance than graduated to the
kernel proper by a large factor.

regards, Kyle

I recommend you don't look at Ubuntu, we might have a lot of extra
crud[2] in the kernel if you do. :) (Actually, shockingly less than I
thought, just apparmor, aufs, ndiswrapper are the obvious ones.)

1. http://dev.gentoo.org/~mpagano/genpatches/trunk/2.6.32/
2.
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=tree;f=ubuntu

Re: Upstream first policy

[Linus Torvalds]

On Thu, 4 Mar 2010, Kyle McMartin wrote:
> 
> I recommend you don't look at Ubuntu, we might have a lot of extra
> crud[2] in the kernel if you do. :) (Actually, shockingly less than I
> thought, just apparmor, aufs, ndiswrapper are the obvious ones.)

Ok, so ndiswrapper falls under the "yeah, no" heading.

But apparmor was supposed to be on the "yeah, we'll merge it" path, I 
talked to somebody about it not _that_ long ago. Some of the security 
people object, but they object for all the wrong reasons and I really do 
think that since it's getting used, we really should merge it.

Although there was _some_ noise about Ubuntu trying to move away from it.. 
But that may have been more of the whole FUD thing from the people who for 
some unfathomable reason think that inodes are more important than 
pathnames.

aufs I'll leave at Al's mercy. 

			Linus

Re: [git pull] drm request 3

[Tony Luck]

On Thu, Mar 4, 2010 at 4:41 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> And if we end up having people bisecting back and forth, I will hate that
> f*cking nouveau driver even more.

Would it help to tag the flag day commit? At least that would make it
trivial for bisecters to see whether each step in a bisection contains
the commit or not.

Generalizing that ... perhaps there could be a way to tell git that some
set of tags represent flag days, so it could warn in any bisection if the
set of included flag days changes.

-Tony

Re: [git pull] drm request 3

[Tony Luck]

On Thu, Mar 4, 2010 at 4:41 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> And if we end up having people bisecting back and forth, I will hate that
> f*cking nouveau driver even more.

Would it help to tag the flag day commit? At least that would make it
trivial for bisecters to see whether each step in a bisection contains
the commit or not.

Generalizing that ... perhaps there could be a way to tell git that some
set of tags represent flag days, so it could warn in any bisection if the
set of included flag days changes.

-Tony

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Felipe Contreras]

On Fri, Mar 5, 2010 at 2:41 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, 5 Mar 2010, Ben Skeggs wrote:
>> The F13 packages *will* work, so long as you're not bisecting back and
>> forth.
>
> How do I install just the F13 libdrm thing, without changing everything
> else? I'm willing to try. We can make it part of the 2.6.34 release notes.
>
> And if we end up having people bisecting back and forth, I will hate that
> f*cking nouveau driver even more.

I believe Dave has already explained this to you, but nobody has
mentioned it here.

What you are supposed to do is install the new nouveau driver, which
requires a new libdrm. So, just compile both libdrm, and nouveau, to a
sandbox, say /opt/new-nouveau, and then in /etc/X11/xorg.conf:

Section "Files"
        ModulePath "/opt/new-nouveau/lib/xorg/modules"
        ModulePath "/usr/lib/xorg/modules"
EndSection

That should do it. No frankensteinian F13 packaging stuff, and no mess
with the system's /usr/lib/.

Cheers.

-- 
Felipe Contreras

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Felipe Contreras]

On Fri, Mar 5, 2010 at 2:41 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, 5 Mar 2010, Ben Skeggs wrote:
>> The F13 packages *will* work, so long as you're not bisecting back and
>> forth.
>
> How do I install just the F13 libdrm thing, without changing everything
> else? I'm willing to try. We can make it part of the 2.6.34 release notes.
>
> And if we end up having people bisecting back and forth, I will hate that
> f*cking nouveau driver even more.

I believe Dave has already explained this to you, but nobody has
mentioned it here.

What you are supposed to do is install the new nouveau driver, which
requires a new libdrm. So, just compile both libdrm, and nouveau, to a
sandbox, say /opt/new-nouveau, and then in /etc/X11/xorg.conf:

Section "Files"
        ModulePath "/opt/new-nouveau/lib/xorg/modules"
        ModulePath "/usr/lib/xorg/modules"
EndSection

That should do it. No frankensteinian F13 packaging stuff, and no mess
with the system's /usr/lib/.

Cheers.

-- 
Felipe Contreras

Re: [git pull] drm request 3

[Ingo Molnar]

* Ben Skeggs <skeggsb@gmail.com> wrote:

> > But here's the thing: if you expect people to do development, they _need_ 
> > to be able to mix things. A kernel developer needs to be able to update 
> > their kernel. And a kernel _tester_ needs to be able to test that kernel.
>
> Here's the thing.  *You* pushed for nouveau to go into staging before any of 
> the developers were ready for it.  Two of the big reasons (from my POV) for 
> not requesting inclusion were the context programs (which have since been 
> dealt with) and that yes, we have no intention of keeping crusty APIs around 
> when they aren't what we require.
> 
> The idea of staging was to allow for exactly the second problem, so why are 
> you surprised?  The fact Fedora ships nouveau is irrelevant, we also expect 
> that for the most part people will be using our packages, which deal with 
> the ABI issues.

Here is my experience with the development of various ABIs - and i've been on 
both sides of the fence, i've done 'flag day' ABI changes during development 
myself, and i've done gradual ABI development as well.

One experience i can tell you with 100% certainty: no matter whether a project 
is small or large, simple or complex, whether the old ABI is the ugliest wart 
on this planet or just hit by an unfortunate limitation that needs to be 
eliminated.

The conclusion is crystal clear, breaking an ABI via a "flag day" 
cleanup/feature/etc is:

 - wrong

 - harmful

 - limits the developer base

 - limits the tester base

 - wastes time and effort. (fewer developers/testers means that while _this_ 
   feature was easier to add, all your _future_ features will be a bit harder 
   to do. It compounds up.)

 - so it hurts even the very developer who is most convinced that this was the 
   right thing to do

It's a bad technical decision throughout. It's masochistic and often suicidal 
to just about any project in essence. I've seen projects that did it once and 
died just due to that single act of stupidity. I've seen projects that have 
done it a few times and took the usage hit, limped along with the wounds and 
never grew to the size they could have achieved. I've seen projects that did 
it once, took the hit, learned from it and never did it again.

How many times does DRM want to take that bullet head on?

I have _never_ seen a situation where in hindsight breaking the ABI of a 
widely deployed project could be considered 'good', for just about any sane 
definition of 'good'.

It's really that simple IMO. There's very few unconditional rules in OSS, but 
this is one of them.

	Ingo

Re: [git pull] drm request 3

[Ingo Molnar]

* Ben Skeggs <skeggsb@gmail.com> wrote:

> > But here's the thing: if you expect people to do development, they _need_ 
> > to be able to mix things. A kernel developer needs to be able to update 
> > their kernel. And a kernel _tester_ needs to be able to test that kernel.
>
> Here's the thing.  *You* pushed for nouveau to go into staging before any of 
> the developers were ready for it.  Two of the big reasons (from my POV) for 
> not requesting inclusion were the context programs (which have since been 
> dealt with) and that yes, we have no intention of keeping crusty APIs around 
> when they aren't what we require.
> 
> The idea of staging was to allow for exactly the second problem, so why are 
> you surprised?  The fact Fedora ships nouveau is irrelevant, we also expect 
> that for the most part people will be using our packages, which deal with 
> the ABI issues.

Here is my experience with the development of various ABIs - and i've been on 
both sides of the fence, i've done 'flag day' ABI changes during development 
myself, and i've done gradual ABI development as well.

One experience i can tell you with 100% certainty: no matter whether a project 
is small or large, simple or complex, whether the old ABI is the ugliest wart 
on this planet or just hit by an unfortunate limitation that needs to be 
eliminated.

The conclusion is crystal clear, breaking an ABI via a "flag day" 
cleanup/feature/etc is:

 - wrong

 - harmful

 - limits the developer base

 - limits the tester base

 - wastes time and effort. (fewer developers/testers means that while _this_ 
   feature was easier to add, all your _future_ features will be a bit harder 
   to do. It compounds up.)

 - so it hurts even the very developer who is most convinced that this was the 
   right thing to do

It's a bad technical decision throughout. It's masochistic and often suicidal 
to just about any project in essence. I've seen projects that did it once and 
died just due to that single act of stupidity. I've seen projects that have 
done it a few times and took the usage hit, limped along with the wounds and 
never grew to the size they could have achieved. I've seen projects that did 
it once, took the hit, learned from it and never did it again.

How many times does DRM want to take that bullet head on?

I have _never_ seen a situation where in hindsight breaking the ABI of a 
widely deployed project could be considered 'good', for just about any sane 
definition of 'good'.

It's really that simple IMO. There's very few unconditional rules in OSS, but 
this is one of them.

	Ingo

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Pekka Enberg]

On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> The conclusion is crystal clear, breaking an ABI via a "flag day"
> cleanup/feature/etc is:
>
>  - wrong
>
>  - harmful
>
>  - limits the developer base
>
>  - limits the tester base
>
>  - wastes time and effort. (fewer developers/testers means that while _this_
>   feature was easier to add, all your _future_ features will be a bit harder
>   to do. It compounds up.)
>
>  - so it hurts even the very developer who is most convinced that this was the
>   right thing to do
>
> It's a bad technical decision throughout. It's masochistic and often suicidal
> to just about any project in essence. I've seen projects that did it once and
> died just due to that single act of stupidity. I've seen projects that have
> done it a few times and took the usage hit, limped along with the wounds and
> never grew to the size they could have achieved. I've seen projects that did
> it once, took the hit, learned from it and never did it again.

Agreed. What bothers me in this discussion is that people keep
bringing up the fact that nouveau is mostly developed by volunteers
and thus it doesn't make sense to make sure it's backwards (or
forwards) compatible. But the way I see it, it's the complete
opposite. It's _more_ important to support ABIs for community-driven
efforts because you're relying on people who by definition don't have
time to waste. While the nouveau people might have good intentions,
I'm afraid they might be severely limiting their developer and tester
base because they're not focused on real world problems (like the ones
Linus is seeing).

                         Pekka

Re: [git pull] drm request 3

[Pekka Enberg]

On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> The conclusion is crystal clear, breaking an ABI via a "flag day"
> cleanup/feature/etc is:
>
>  - wrong
>
>  - harmful
>
>  - limits the developer base
>
>  - limits the tester base
>
>  - wastes time and effort. (fewer developers/testers means that while _this_
>   feature was easier to add, all your _future_ features will be a bit harder
>   to do. It compounds up.)
>
>  - so it hurts even the very developer who is most convinced that this was the
>   right thing to do
>
> It's a bad technical decision throughout. It's masochistic and often suicidal
> to just about any project in essence. I've seen projects that did it once and
> died just due to that single act of stupidity. I've seen projects that have
> done it a few times and took the usage hit, limped along with the wounds and
> never grew to the size they could have achieved. I've seen projects that did
> it once, took the hit, learned from it and never did it again.

Agreed. What bothers me in this discussion is that people keep
bringing up the fact that nouveau is mostly developed by volunteers
and thus it doesn't make sense to make sure it's backwards (or
forwards) compatible. But the way I see it, it's the complete
opposite. It's _more_ important to support ABIs for community-driven
efforts because you're relying on people who by definition don't have
time to waste. While the nouveau people might have good intentions,
I'm afraid they might be severely limiting their developer and tester
base because they're not focused on real world problems (like the ones
Linus is seeing).

                         Pekka

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

["C. Bergström"]

Pekka Enberg wrote:
> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>   
>> The conclusion is crystal clear, breaking an ABI via a "flag day"
>> cleanup/feature/etc is:
>>
>>  - wrong
>>
>>  - harmful
>>
>>  - limits the developer base
>>
>>  - limits the tester base
>>
>>  - wastes time and effort. (fewer developers/testers means that while _this_
>>   feature was easier to add, all your _future_ features will be a bit harder
>>   to do. It compounds up.)
>>
>>  - so it hurts even the very developer who is most convinced that this was the
>>   right thing to do
>>
>> It's a bad technical decision throughout. It's masochistic and often suicidal
>> to just about any project in essence. I've seen projects that did it once and
>> died just due to that single act of stupidity. I've seen projects that have
>> done it a few times and took the usage hit, limped along with the wounds and
>> never grew to the size they could have achieved. I've seen projects that did
>> it once, took the hit, learned from it and never did it again.
>>     
>
> Agreed. What bothers me in this discussion is that people keep
> bringing up the fact that nouveau is mostly developed by volunteers
> and thus it doesn't make sense to make sure it's backwards (or
> forwards) compatible. But the way I see it, it's the complete
> opposite. It's _more_ important to support ABIs for community-driven
> efforts because you're relying on people who by definition don't have
> time to waste. While the nouveau people might have good intentions,
> I'm afraid they might be severely limiting their developer and tester
> base because they're not focused on real world problems (like the ones
> Linus is seeing).
staging != stable

Nobody guaranteed a stable API for staging and in fact it was stated 
previously it needed to be changed.  Please lets just get back to work 
and stop declaring the sky is falling.

Re: [git pull] drm request 3

[Ingo Molnar]

* "C. Bergstr?m" <cbergstrom@pathscale.com> wrote:

> Pekka Enberg wrote:
> >On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >>The conclusion is crystal clear, breaking an ABI via a "flag day"
> >>cleanup/feature/etc is:
> >>
> >> - wrong
> >>
> >> - harmful
> >>
> >> - limits the developer base
> >>
> >> - limits the tester base
> >>
> >> - wastes time and effort. (fewer developers/testers means that while _this_
> >>  feature was easier to add, all your _future_ features will be a bit harder
> >>  to do. It compounds up.)
> >>
> >> - so it hurts even the very developer who is most convinced that this was the
> >>  right thing to do
> >>
> >>It's a bad technical decision throughout. It's masochistic and often suicidal
> >>to just about any project in essence. I've seen projects that did it once and
> >>died just due to that single act of stupidity. I've seen projects that have
> >>done it a few times and took the usage hit, limped along with the wounds and
> >>never grew to the size they could have achieved. I've seen projects that did
> >>it once, took the hit, learned from it and never did it again.
> >
> >Agreed. What bothers me in this discussion is that people keep
> >bringing up the fact that nouveau is mostly developed by volunteers
> >and thus it doesn't make sense to make sure it's backwards (or
> >forwards) compatible. But the way I see it, it's the complete
> >opposite. It's _more_ important to support ABIs for community-driven
> >efforts because you're relying on people who by definition don't have
> >time to waste. While the nouveau people might have good intentions,
> >I'm afraid they might be severely limiting their developer and tester
> >base because they're not focused on real world problems (like the ones
> >Linus is seeing).
> staging != stable
> 
> Nobody guaranteed a stable API for staging and in fact it was stated 
> previously it needed to be changed.  Please lets just get back to work and 
> stop declaring the sky is falling.

I dont think you understood the argument.

The (very simple) argument was: no matter how a project is developed, whether 
it's been freshly announced (not even in staging), in staging or been upstream 
for years, breaking ABIs is _technically wrong_.

No ifs and when. A released ABI that is in use cannot be so messy to make it 
worth breaking. You've got users. You've got developers. You've got yourself.

You can still phase it out gradually (and even do that quickly), one or two 
stable releases down the road you can even print out the final ABI removal 
patch on paper, make a bonfire out of it and jump on its ashes in joy, but if 
you are interested in running a successful OSS project then the current ABI is 
sacrosanct.

	Ingo

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Ingo Molnar]

* "C. Bergstr?m" <cbergstrom@pathscale.com> wrote:

> Pekka Enberg wrote:
> >On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >>The conclusion is crystal clear, breaking an ABI via a "flag day"
> >>cleanup/feature/etc is:
> >>
> >> - wrong
> >>
> >> - harmful
> >>
> >> - limits the developer base
> >>
> >> - limits the tester base
> >>
> >> - wastes time and effort. (fewer developers/testers means that while _this_
> >>  feature was easier to add, all your _future_ features will be a bit harder
> >>  to do. It compounds up.)
> >>
> >> - so it hurts even the very developer who is most convinced that this was the
> >>  right thing to do
> >>
> >>It's a bad technical decision throughout. It's masochistic and often suicidal
> >>to just about any project in essence. I've seen projects that did it once and
> >>died just due to that single act of stupidity. I've seen projects that have
> >>done it a few times and took the usage hit, limped along with the wounds and
> >>never grew to the size they could have achieved. I've seen projects that did
> >>it once, took the hit, learned from it and never did it again.
> >
> >Agreed. What bothers me in this discussion is that people keep
> >bringing up the fact that nouveau is mostly developed by volunteers
> >and thus it doesn't make sense to make sure it's backwards (or
> >forwards) compatible. But the way I see it, it's the complete
> >opposite. It's _more_ important to support ABIs for community-driven
> >efforts because you're relying on people who by definition don't have
> >time to waste. While the nouveau people might have good intentions,
> >I'm afraid they might be severely limiting their developer and tester
> >base because they're not focused on real world problems (like the ones
> >Linus is seeing).
> staging != stable
> 
> Nobody guaranteed a stable API for staging and in fact it was stated 
> previously it needed to be changed.  Please lets just get back to work and 
> stop declaring the sky is falling.

I dont think you understood the argument.

The (very simple) argument was: no matter how a project is developed, whether 
it's been freshly announced (not even in staging), in staging or been upstream 
for years, breaking ABIs is _technically wrong_.

No ifs and when. A released ABI that is in use cannot be so messy to make it 
worth breaking. You've got users. You've got developers. You've got yourself.

You can still phase it out gradually (and even do that quickly), one or two 
stable releases down the road you can even print out the final ABI removal 
patch on paper, make a bonfire out of it and jump on its ashes in joy, but if 
you are interested in running a successful OSS project then the current ABI is 
sacrosanct.

	Ingo

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, "C. Bergström" wrote:
>
> staging != stable

This really is being repeated, over and over. But it's irrelevant.

It's irrelevant because it's just a bad _excuse_.

That driver is used in production environments. That's _reality_. The 
whole "staging" thing is nothing more than a meaningless word.

And no, "staging" wasn't why it was merged. The reason it was merged was 
that very same "reality".

So every time somebody mentions staging as an argument, he's missing the 
whole effing point.

It also misses the point that the issues I've tried to bring up 
(bisection, testability) are real _technical_ arguments. Again, waving 
that "staging" flag is just stupid. It has nothing to do with the 
technical arguments, or with the reality of the situation. 

In other words, it's not just an excuse, it's a _meaningless_ excuse. It's 
a red herring. It's irrelevant to the issue.

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, "C. Bergström" wrote:
>
> staging != stable

This really is being repeated, over and over. But it's irrelevant.

It's irrelevant because it's just a bad _excuse_.

That driver is used in production environments. That's _reality_. The 
whole "staging" thing is nothing more than a meaningless word.

And no, "staging" wasn't why it was merged. The reason it was merged was 
that very same "reality".

So every time somebody mentions staging as an argument, he's missing the 
whole effing point.

It also misses the point that the issues I've tried to bring up 
(bisection, testability) are real _technical_ arguments. Again, waving 
that "staging" flag is just stupid. It has nothing to do with the 
technical arguments, or with the reality of the situation. 

In other words, it's not just an excuse, it's a _meaningless_ excuse. It's 
a red herring. It's irrelevant to the issue.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

["C. Bergström"]

Pekka Enberg wrote:
> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>   
>> The conclusion is crystal clear, breaking an ABI via a "flag day"
>> cleanup/feature/etc is:
>>
>>  - wrong
>>
>>  - harmful
>>
>>  - limits the developer base
>>
>>  - limits the tester base
>>
>>  - wastes time and effort. (fewer developers/testers means that while _this_
>>   feature was easier to add, all your _future_ features will be a bit harder
>>   to do. It compounds up.)
>>
>>  - so it hurts even the very developer who is most convinced that this was the
>>   right thing to do
>>
>> It's a bad technical decision throughout. It's masochistic and often suicidal
>> to just about any project in essence. I've seen projects that did it once and
>> died just due to that single act of stupidity. I've seen projects that have
>> done it a few times and took the usage hit, limped along with the wounds and
>> never grew to the size they could have achieved. I've seen projects that did
>> it once, took the hit, learned from it and never did it again.
>>     
>
> Agreed. What bothers me in this discussion is that people keep
> bringing up the fact that nouveau is mostly developed by volunteers
> and thus it doesn't make sense to make sure it's backwards (or
> forwards) compatible. But the way I see it, it's the complete
> opposite. It's _more_ important to support ABIs for community-driven
> efforts because you're relying on people who by definition don't have
> time to waste. While the nouveau people might have good intentions,
> I'm afraid they might be severely limiting their developer and tester
> base because they're not focused on real world problems (like the ones
> Linus is seeing).
staging != stable

Nobody guaranteed a stable API for staging and in fact it was stated 
previously it needed to be changed.  Please lets just get back to work 
and stop declaring the sky is falling.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > The conclusion is crystal clear, breaking an ABI via a "flag day"
> > cleanup/feature/etc is:
> >
> > ?- wrong
> >
> > ?- harmful
> >
> > ?- limits the developer base
> >
> > ?- limits the tester base
> >
> > ?- wastes time and effort. (fewer developers/testers means that while _this_
> > ? feature was easier to add, all your _future_ features will be a bit harder
> > ? to do. It compounds up.)
> >
> > ?- so it hurts even the very developer who is most convinced that this was the
> > ? right thing to do
> >
> > It's a bad technical decision throughout. It's masochistic and often suicidal
> > to just about any project in essence. I've seen projects that did it once and
> > died just due to that single act of stupidity. I've seen projects that have
> > done it a few times and took the usage hit, limped along with the wounds and
> > never grew to the size they could have achieved. I've seen projects that did
> > it once, took the hit, learned from it and never did it again.
> 
> Agreed. What bothers me in this discussion is that people keep bringing up 
> the fact that nouveau is mostly developed by volunteers and thus it doesn't 
> make sense to make sure it's backwards (or forwards) compatible. But the way 
> I see it, it's the complete opposite. It's _more_ important to support ABIs 
> for community-driven efforts because you're relying on people who by 
> definition don't have time to waste. While the nouveau people might have 
> good intentions, I'm afraid they might be severely limiting their developer 
> and tester base because they're not focused on real world problems (like the 
> ones Linus is seeing).

Yeah. I've seen a few other bad arguments as well:

   'exploding test matrix'

This is often the result of _another_ bad technical decision: 
over-modularization.

Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:

 - it's developed by the same tightly knit developer base who often cross
   between these packages. Features often need changes in each component.

 - a developer to be able to do real work has to have the latest sources
   of all these components.

 - a user just uses whatever horizontal version cut the distro did and never
   truly 'mixes' these components as a conscious decision.

 - distros just try to get the latest and most capable but still stable
   version. Desperately so. Often they will create a version mix that was
   never tested by developers in that form. They'll expose users to ABI
   combinations that were never really intended. They have trouble
   bootstrapping and stabilizing those essentially random combinations and
   then have trouble applying stability and security fixes.

The thing is, if development has such characteristics then it's pretty clearly 
not 3-4 separate projects but _one_ abstract project. [*]

So the 'exploding test matrix' is simply the result of: creating ABIs between 
3-4 _artificial components of the same project_ and then going through 
developer hell living with that mistake. [**]

It's a bit as if we split up the kernel into 'microkernel' components, did a 
VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and 
then tried to develop them as separate components.

If we did then then Linux kernel development would slow down massively while 
in reality everyone would _still_ have to have the latest and greatest source 
checked out to do some real development work and to be able to implement 
features that affect the whole kernel ...

Linux would become an epic fail of historic proportions if we ever did that.

	Ingo

[*]  I realize that it's possibly hard for Xorg to merge with mesa and the 
     kernel for license reasons, but my technical observation still stands.

[**] I realize that modularization and many small packages were a clear 
     advantage when we were still all downloading bits via 14.4k modems, but 
     in this day and age of megabit connections that has become a non-issue.
     Rampant over-modularization and the resulting loss of focus on the end
     result (and the resulting explosion of a test matrix) is hurting us _far 
     more_ than the disadvantages of any monolithic could ever hurt. We are 
     seeing the proof of that all day with a 10+ MLOC kernel.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > The conclusion is crystal clear, breaking an ABI via a "flag day"
> > cleanup/feature/etc is:
> >
> > ?- wrong
> >
> > ?- harmful
> >
> > ?- limits the developer base
> >
> > ?- limits the tester base
> >
> > ?- wastes time and effort. (fewer developers/testers means that while _this_
> > ? feature was easier to add, all your _future_ features will be a bit harder
> > ? to do. It compounds up.)
> >
> > ?- so it hurts even the very developer who is most convinced that this was the
> > ? right thing to do
> >
> > It's a bad technical decision throughout. It's masochistic and often suicidal
> > to just about any project in essence. I've seen projects that did it once and
> > died just due to that single act of stupidity. I've seen projects that have
> > done it a few times and took the usage hit, limped along with the wounds and
> > never grew to the size they could have achieved. I've seen projects that did
> > it once, took the hit, learned from it and never did it again.
> 
> Agreed. What bothers me in this discussion is that people keep bringing up 
> the fact that nouveau is mostly developed by volunteers and thus it doesn't 
> make sense to make sure it's backwards (or forwards) compatible. But the way 
> I see it, it's the complete opposite. It's _more_ important to support ABIs 
> for community-driven efforts because you're relying on people who by 
> definition don't have time to waste. While the nouveau people might have 
> good intentions, I'm afraid they might be severely limiting their developer 
> and tester base because they're not focused on real world problems (like the 
> ones Linus is seeing).

Yeah. I've seen a few other bad arguments as well:

   'exploding test matrix'

This is often the result of _another_ bad technical decision: 
over-modularization.

Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:

 - it's developed by the same tightly knit developer base who often cross
   between these packages. Features often need changes in each component.

 - a developer to be able to do real work has to have the latest sources
   of all these components.

 - a user just uses whatever horizontal version cut the distro did and never
   truly 'mixes' these components as a conscious decision.

 - distros just try to get the latest and most capable but still stable
   version. Desperately so. Often they will create a version mix that was
   never tested by developers in that form. They'll expose users to ABI
   combinations that were never really intended. They have trouble
   bootstrapping and stabilizing those essentially random combinations and
   then have trouble applying stability and security fixes.

The thing is, if development has such characteristics then it's pretty clearly 
not 3-4 separate projects but _one_ abstract project. [*]

So the 'exploding test matrix' is simply the result of: creating ABIs between 
3-4 _artificial components of the same project_ and then going through 
developer hell living with that mistake. [**]

It's a bit as if we split up the kernel into 'microkernel' components, did a 
VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and 
then tried to develop them as separate components.

If we did then then Linux kernel development would slow down massively while 
in reality everyone would _still_ have to have the latest and greatest source 
checked out to do some real development work and to be able to implement 
features that affect the whole kernel ...

Linux would become an epic fail of historic proportions if we ever did that.

	Ingo

[*]  I realize that it's possibly hard for Xorg to merge with mesa and the 
     kernel for license reasons, but my technical observation still stands.

[**] I realize that modularization and many small packages were a clear 
     advantage when we were still all downloading bits via 14.4k modems, but 
     in this day and age of megabit connections that has become a non-issue.
     Rampant over-modularization and the resulting loss of focus on the end
     result (and the resulting explosion of a test matrix) is hurting us _far 
     more_ than the disadvantages of any monolithic could ever hurt. We are 
     seeing the proof of that all day with a 10+ MLOC kernel.

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 5:44 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
>> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>> > The conclusion is crystal clear, breaking an ABI via a "flag day"
>> > cleanup/feature/etc is:
>> >
>> > ?- wrong
>> >
>> > ?- harmful
>> >
>> > ?- limits the developer base
>> >
>> > ?- limits the tester base
>> >
>> > ?- wastes time and effort. (fewer developers/testers means that while _this_
>> > ? feature was easier to add, all your _future_ features will be a bit harder
>> > ? to do. It compounds up.)
>> >
>> > ?- so it hurts even the very developer who is most convinced that this was the
>> > ? right thing to do
>> >
>> > It's a bad technical decision throughout. It's masochistic and often suicidal
>> > to just about any project in essence. I've seen projects that did it once and
>> > died just due to that single act of stupidity. I've seen projects that have
>> > done it a few times and took the usage hit, limped along with the wounds and
>> > never grew to the size they could have achieved. I've seen projects that did
>> > it once, took the hit, learned from it and never did it again.
>>
>> Agreed. What bothers me in this discussion is that people keep bringing up
>> the fact that nouveau is mostly developed by volunteers and thus it doesn't
>> make sense to make sure it's backwards (or forwards) compatible. But the way
>> I see it, it's the complete opposite. It's _more_ important to support ABIs
>> for community-driven efforts because you're relying on people who by
>> definition don't have time to waste. While the nouveau people might have
>> good intentions, I'm afraid they might be severely limiting their developer
>> and tester base because they're not focused on real world problems (like the
>> ones Linus is seeing).
>
> Yeah. I've seen a few other bad arguments as well:
>
>   'exploding test matrix'
>
> This is often the result of _another_ bad technical decision:
> over-modularization.
>
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
>
>  - it's developed by the same tightly knit developer base who often cross
>   between these packages. Features often need changes in each component.
>
>  - a developer to be able to do real work has to have the latest sources
>   of all these components.
>
>  - a user just uses whatever horizontal version cut the distro did and never
>   truly 'mixes' these components as a conscious decision.
>
>  - distros just try to get the latest and most capable but still stable
>   version. Desperately so. Often they will create a version mix that was
>   never tested by developers in that form. They'll expose users to ABI
>   combinations that were never really intended. They have trouble
>   bootstrapping and stabilizing those essentially random combinations and
>   then have trouble applying stability and security fixes.
>
> The thing is, if development has such characteristics then it's pretty clearly
> not 3-4 separate projects but _one_ abstract project. [*]
>
> So the 'exploding test matrix' is simply the result of: creating ABIs between
> 3-4 _artificial components of the same project_ and then going through
> developer hell living with that mistake. [**]
>
> It's a bit as if we split up the kernel into 'microkernel' components, did a
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and
> then tried to develop them as separate components.
>
> If we did then then Linux kernel development would slow down massively while
> in reality everyone would _still_ have to have the latest and greatest source
> checked out to do some real development work and to be able to implement
> features that affect the whole kernel ...
>
> Linux would become an epic fail of historic proportions if we ever did that.

The other option that we used to have was out-of-tree kernel modules, that
shipped in X.org along with Mesa all in one big tree. This wasn't satisfactory
and we were pretty much told to put the drm modules into the kernel at
that point,

Other suggestion from Luc has been to stablise drm/mesa/X.org APIs a
lot more and
ship driver sources for all 3 bit separately, but that doesn't seem
workable either,
since the Mesa API is infinitely broad (its effectively OpenGL), and
changes way too
often, as does the kernel API, though the drm component is probably okay.

You'll find groups like Intel are releasing things at fairly similiar
times every quarter
and recommending those groupings for distros to take as tested together.

You also have the BSD options where they just create a base OS system and screw
the whole pick-n-mix decisions.

Dave

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 5:44 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
>> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>> > The conclusion is crystal clear, breaking an ABI via a "flag day"
>> > cleanup/feature/etc is:
>> >
>> > ?- wrong
>> >
>> > ?- harmful
>> >
>> > ?- limits the developer base
>> >
>> > ?- limits the tester base
>> >
>> > ?- wastes time and effort. (fewer developers/testers means that while _this_
>> > ? feature was easier to add, all your _future_ features will be a bit harder
>> > ? to do. It compounds up.)
>> >
>> > ?- so it hurts even the very developer who is most convinced that this was the
>> > ? right thing to do
>> >
>> > It's a bad technical decision throughout. It's masochistic and often suicidal
>> > to just about any project in essence. I've seen projects that did it once and
>> > died just due to that single act of stupidity. I've seen projects that have
>> > done it a few times and took the usage hit, limped along with the wounds and
>> > never grew to the size they could have achieved. I've seen projects that did
>> > it once, took the hit, learned from it and never did it again.
>>
>> Agreed. What bothers me in this discussion is that people keep bringing up
>> the fact that nouveau is mostly developed by volunteers and thus it doesn't
>> make sense to make sure it's backwards (or forwards) compatible. But the way
>> I see it, it's the complete opposite. It's _more_ important to support ABIs
>> for community-driven efforts because you're relying on people who by
>> definition don't have time to waste. While the nouveau people might have
>> good intentions, I'm afraid they might be severely limiting their developer
>> and tester base because they're not focused on real world problems (like the
>> ones Linus is seeing).
>
> Yeah. I've seen a few other bad arguments as well:
>
>   'exploding test matrix'
>
> This is often the result of _another_ bad technical decision:
> over-modularization.
>
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
>
>  - it's developed by the same tightly knit developer base who often cross
>   between these packages. Features often need changes in each component.
>
>  - a developer to be able to do real work has to have the latest sources
>   of all these components.
>
>  - a user just uses whatever horizontal version cut the distro did and never
>   truly 'mixes' these components as a conscious decision.
>
>  - distros just try to get the latest and most capable but still stable
>   version. Desperately so. Often they will create a version mix that was
>   never tested by developers in that form. They'll expose users to ABI
>   combinations that were never really intended. They have trouble
>   bootstrapping and stabilizing those essentially random combinations and
>   then have trouble applying stability and security fixes.
>
> The thing is, if development has such characteristics then it's pretty clearly
> not 3-4 separate projects but _one_ abstract project. [*]
>
> So the 'exploding test matrix' is simply the result of: creating ABIs between
> 3-4 _artificial components of the same project_ and then going through
> developer hell living with that mistake. [**]
>
> It's a bit as if we split up the kernel into 'microkernel' components, did a
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and
> then tried to develop them as separate components.
>
> If we did then then Linux kernel development would slow down massively while
> in reality everyone would _still_ have to have the latest and greatest source
> checked out to do some real development work and to be able to implement
> features that affect the whole kernel ...
>
> Linux would become an epic fail of historic proportions if we ever did that.

The other option that we used to have was out-of-tree kernel modules, that
shipped in X.org along with Mesa all in one big tree. This wasn't satisfactory
and we were pretty much told to put the drm modules into the kernel at
that point,

Other suggestion from Luc has been to stablise drm/mesa/X.org APIs a
lot more and
ship driver sources for all 3 bit separately, but that doesn't seem
workable either,
since the Mesa API is infinitely broad (its effectively OpenGL), and
changes way too
often, as does the kernel API, though the drm component is probably okay.

You'll find groups like Intel are releasing things at fairly similiar
times every quarter
and recommending those groupings for distros to take as tested together.

You also have the BSD options where they just create a base OS system and screw
the whole pick-n-mix decisions.

Dave

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Stephane Marchesin]

On Thu, Mar 4, 2010 at 23:44, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
>> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>> > The conclusion is crystal clear, breaking an ABI via a "flag day"
>> > cleanup/feature/etc is:
>> >
>> > ?- wrong
>> >
>> > ?- harmful
>> >
>> > ?- limits the developer base
>> >
>> > ?- limits the tester base
>> >
>> > ?- wastes time and effort. (fewer developers/testers means that while _this_
>> > ? feature was easier to add, all your _future_ features will be a bit harder
>> > ? to do. It compounds up.)
>> >
>> > ?- so it hurts even the very developer who is most convinced that this was the
>> > ? right thing to do
>> >
>> > It's a bad technical decision throughout. It's masochistic and often suicidal
>> > to just about any project in essence. I've seen projects that did it once and
>> > died just due to that single act of stupidity. I've seen projects that have
>> > done it a few times and took the usage hit, limped along with the wounds and
>> > never grew to the size they could have achieved. I've seen projects that did
>> > it once, took the hit, learned from it and never did it again.
>>
>> Agreed. What bothers me in this discussion is that people keep bringing up
>> the fact that nouveau is mostly developed by volunteers and thus it doesn't
>> make sense to make sure it's backwards (or forwards) compatible. But the way
>> I see it, it's the complete opposite. It's _more_ important to support ABIs
>> for community-driven efforts because you're relying on people who by
>> definition don't have time to waste. While the nouveau people might have
>> good intentions, I'm afraid they might be severely limiting their developer
>> and tester base because they're not focused on real world problems (like the
>> ones Linus is seeing).
>
> Yeah. I've seen a few other bad arguments as well:
>
>   'exploding test matrix'
>
> This is often the result of _another_ bad technical decision:
> over-modularization.
>
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
>
>  - it's developed by the same tightly knit developer base who often cross
>   between these packages. Features often need changes in each component.
>
>  - a developer to be able to do real work has to have the latest sources
>   of all these components.
>
>  - a user just uses whatever horizontal version cut the distro did and never
>   truly 'mixes' these components as a conscious decision.
>
>  - distros just try to get the latest and most capable but still stable
>   version. Desperately so. Often they will create a version mix that was
>   never tested by developers in that form. They'll expose users to ABI
>   combinations that were never really intended. They have trouble
>   bootstrapping and stabilizing those essentially random combinations and
>   then have trouble applying stability and security fixes.
>
> The thing is, if development has such characteristics then it's pretty clearly
> not 3-4 separate projects but _one_ abstract project. [*]
>
> So the 'exploding test matrix' is simply the result of: creating ABIs between
> 3-4 _artificial components of the same project_ and then going through
> developer hell living with that mistake. [**]
>
> It's a bit as if we split up the kernel into 'microkernel' components, did a
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and
> then tried to develop them as separate components.
>
> If we did then then Linux kernel development would slow down massively while
> in reality everyone would _still_ have to have the latest and greatest source
> checked out to do some real development work and to be able to implement
> features that affect the whole kernel ...
>
> Linux would become an epic fail of historic proportions if we ever did that.
>

Yes that is exactly the problem we are facing. And you know what? All
graphic driver devs agree on that, but there is no obvious solution.

Here are the interfaces which are part of this problem:
- drm interface (drm wrappers as seen from the driver, drm ioctls from
the user space)
- X.Org acceleration interface (EXA and friends as seen from the
driver, XRender and friends as seen from the apps)
- Mesa interface (Gallium or mesa driver interface from the driver,
OpenGL seen from the app)

Any solution will involve merging two or more components together to
remove interfaces, so lets observe pairwise what could be merged and
the drawbacks:
- Merge DRM and Mesa drivers. Technically we could do this, but then
what happens when a new OpenGL version/feature comes around? Yes, we
get a new mesa interface. So we're exchanging one interface for
another here. No gain.
- Merge DDX And DRM driver. Same problem as before, whenever 2D
interfaces changes, we have to update the DDX anyway. Again, no gain
in sight.
- Merge Mesa and DDX drivers. This makes sense, and this is where
gallium is going by providing 2D and GL acceleration on top of a
single, common gallium driver. So yes, I have hopes that this one will
happen eventually, at least on non-intel hardware.

In a far away future, I can only hope that all acceleration (2D and
3D) will be done on top of GL only. That'll mean we can remove the DDX
entirely. We've been talking about this for 6 years or so. But as you
know, it's far from the case yet.

Stephane

Re: [git pull] drm request 3

[Stephane Marchesin]

On Thu, Mar 4, 2010 at 23:44, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
>> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
>> > The conclusion is crystal clear, breaking an ABI via a "flag day"
>> > cleanup/feature/etc is:
>> >
>> > ?- wrong
>> >
>> > ?- harmful
>> >
>> > ?- limits the developer base
>> >
>> > ?- limits the tester base
>> >
>> > ?- wastes time and effort. (fewer developers/testers means that while _this_
>> > ? feature was easier to add, all your _future_ features will be a bit harder
>> > ? to do. It compounds up.)
>> >
>> > ?- so it hurts even the very developer who is most convinced that this was the
>> > ? right thing to do
>> >
>> > It's a bad technical decision throughout. It's masochistic and often suicidal
>> > to just about any project in essence. I've seen projects that did it once and
>> > died just due to that single act of stupidity. I've seen projects that have
>> > done it a few times and took the usage hit, limped along with the wounds and
>> > never grew to the size they could have achieved. I've seen projects that did
>> > it once, took the hit, learned from it and never did it again.
>>
>> Agreed. What bothers me in this discussion is that people keep bringing up
>> the fact that nouveau is mostly developed by volunteers and thus it doesn't
>> make sense to make sure it's backwards (or forwards) compatible. But the way
>> I see it, it's the complete opposite. It's _more_ important to support ABIs
>> for community-driven efforts because you're relying on people who by
>> definition don't have time to waste. While the nouveau people might have
>> good intentions, I'm afraid they might be severely limiting their developer
>> and tester base because they're not focused on real world problems (like the
>> ones Linus is seeing).
>
> Yeah. I've seen a few other bad arguments as well:
>
>   'exploding test matrix'
>
> This is often the result of _another_ bad technical decision:
> over-modularization.
>
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
>
>  - it's developed by the same tightly knit developer base who often cross
>   between these packages. Features often need changes in each component.
>
>  - a developer to be able to do real work has to have the latest sources
>   of all these components.
>
>  - a user just uses whatever horizontal version cut the distro did and never
>   truly 'mixes' these components as a conscious decision.
>
>  - distros just try to get the latest and most capable but still stable
>   version. Desperately so. Often they will create a version mix that was
>   never tested by developers in that form. They'll expose users to ABI
>   combinations that were never really intended. They have trouble
>   bootstrapping and stabilizing those essentially random combinations and
>   then have trouble applying stability and security fixes.
>
> The thing is, if development has such characteristics then it's pretty clearly
> not 3-4 separate projects but _one_ abstract project. [*]
>
> So the 'exploding test matrix' is simply the result of: creating ABIs between
> 3-4 _artificial components of the same project_ and then going through
> developer hell living with that mistake. [**]
>
> It's a bit as if we split up the kernel into 'microkernel' components, did a
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and
> then tried to develop them as separate components.
>
> If we did then then Linux kernel development would slow down massively while
> in reality everyone would _still_ have to have the latest and greatest source
> checked out to do some real development work and to be able to implement
> features that affect the whole kernel ...
>
> Linux would become an epic fail of historic proportions if we ever did that.
>

Yes that is exactly the problem we are facing. And you know what? All
graphic driver devs agree on that, but there is no obvious solution.

Here are the interfaces which are part of this problem:
- drm interface (drm wrappers as seen from the driver, drm ioctls from
the user space)
- X.Org acceleration interface (EXA and friends as seen from the
driver, XRender and friends as seen from the apps)
- Mesa interface (Gallium or mesa driver interface from the driver,
OpenGL seen from the app)

Any solution will involve merging two or more components together to
remove interfaces, so lets observe pairwise what could be merged and
the drawbacks:
- Merge DRM and Mesa drivers. Technically we could do this, but then
what happens when a new OpenGL version/feature comes around? Yes, we
get a new mesa interface. So we're exchanging one interface for
another here. No gain.
- Merge DDX And DRM driver. Same problem as before, whenever 2D
interfaces changes, we have to update the DDX anyway. Again, no gain
in sight.
- Merge Mesa and DDX drivers. This makes sense, and this is where
gallium is going by providing 2D and GL acceleration on top of a
single, common gallium driver. So yes, I have hopes that this one will
happen eventually, at least on non-intel hardware.

In a far away future, I can only hope that all acceleration (2D and
3D) will be done on top of GL only. That'll mean we can remove the DDX
entirely. We've been talking about this for 6 years or so. But as you
know, it's far from the case yet.

Stephane

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Making Xorg easier to test (was Re: [git pull] drm request 3)

[Carlos R. Mafra]

On Fri  5.Mar'10 at  8:44:07 +0100, Ingo Molnar wrote:
> 
> Yeah. I've seen a few other bad arguments as well:
> 
>    'exploding test matrix'
> 
> This is often the result of _another_ bad technical decision: 
> over-modularization.
> 
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:

I agree 100% with this!

I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because
it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install 
and I am ready to test the bleeding edge kernel. 
And everytime I complained about something breaking it got fixed.

Really, testing the linux kernel is a hobby for me because it is easy.

Whereas everytime I wanted to do that with Xorg it was such a pain that
I want to keep away from that mess.
 
>  - it's developed by the same tightly knit developer base who often cross
>    between these packages. Features often need changes in each component.
> 
>  - a developer to be able to do real work has to have the latest sources
>    of all these components.
> 
>  - a user just uses whatever horizontal version cut the distro did and never
>    truly 'mixes' these components as a conscious decision.

True!

Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
maintainers and keeping the whole thing tied up? Why can't it mimic the
'make menuconfig' way of selecting what to compile to have the guarantee that 
the whole thing will simply work nicely together?

If this could be done for the kernel (which from my user POV seems much more
complicated), I guess it could be done with Xorg. And Linux would have
more Xorg testers and be better as a whole.

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 8627 bytes --]

On Fri, 05 Mar 2010 11:00:30 +0100, "Carlos R. Mafra" said:

> Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> maintainers and keeping the whole thing tied up? Why can't it mimic the
> 'make menuconfig' way of selecting what to compile to have the guarantee that
> the whole thing will simply work nicely together?

Feel free to do so.  Note that you'll hit 2 problems:

1) In the kernel, the sysadmin can almost always get away with saying
"I have no XYZ devices" or "I only have ext4 filesystems" or similar choices,
and have the resulting kernel still support basically all the syscalls
(unless you start going into CONFIG_EMBEDDED and doing some *major* surgury).
Over on the X side of the fence, there aren't as many options that don't
involve dropping major chunks of the functionality.  You *sure* that nothing
on your system depends on the XRandR extension? ;)

2) Lately, the X server is *already* highly modular and different components
built from different source trees.  Note that the base X server is only about
half the size of the kernel RPM - there really isn't much left to trim out of
the base server anymore.

ncftp ...velopment/source/SRPMS > dir kern* xorg*
-rw-r--r--    1 263      263     66965350   Feb 26 18:03   kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm
-rw-r--r--    1 263      263        44300   Feb 27 01:39   xorg-sgml-doctools-1.1.1-4.fc12.src.rpm
-rw-r--r--    2 263      263      2229508   Feb 11 02:23   xorg-x11-apps-7.4-10.fc13.src.rpm
-rw-r--r--    1 263      263      8250097   Feb 27 00:06   xorg-x11-docs-1.3-6.fc12.src.rpm
-rw-r--r--    1 263      263         9718   Feb 27 03:27   xorg-x11-drivers-7.3-13.fc12.src.rpm
-rw-r--r--    2 263      263       263291   Feb  5 21:40   xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm
-rw-r--r--    2 263      263       271426   Feb  5 23:03   xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm
-rw-r--r--    1 263      263       293991   Feb 27 01:02   xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm
-rw-r--r--    2 263      263       247603   Feb  5 19:49   xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm
-rw-r--r--    1 263      263       273849   Feb 26 20:22   xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm
-rw-r--r--    1 263      263       475771   Feb 19 00:50   xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm
-rw-r--r--    1 263      263       354400   Feb 27 01:17   xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm
-rw-r--r--    2 263      263       296790   Feb  5 16:10   xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm
-rw-r--r--    2 263      263       257700   Feb  5 19:48   xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       260227   Feb  5 16:26   xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm
-rw-r--r--    2 263      263       537577   Feb  5 21:59   xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm
-rw-r--r--    2 263      263       254313   Feb  9 13:19   xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm
-rw-r--r--    1 263      263       252387   Feb 17 05:13   xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm
-rw-r--r--    2 263      263       608480   Feb  5 23:07   xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm
-rw-r--r--    2 263      263       361698   Feb  5 21:40   xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm
-rw-r--r--    2 263      263       244962   Feb  9 13:48   xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       289677   Feb  5 22:38   xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       281904   Feb  5 20:33   xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm
-rw-r--r--    1 263      263       978993   Feb 12 07:15   xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       305926   Feb  5 19:26   xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm
-rw-r--r--    2 263      263       296974   Feb  5 19:22   xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       492204   Feb  5 20:02   xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm
-rw-r--r--    2 263      263       427579   Feb  5 20:39   xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm
-rw-r--r--    2 263      263       318263   Feb  9 13:52   xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       254590   Feb  5 20:17   xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm
-rw-r--r--    2 263      263       290495   Feb  5 22:02   xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm
-rw-r--r--    2 263      263        91334   Feb 18 16:59   xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
-rw-r--r--    2 263      263       449803   Feb  9 12:19   xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm
-rw-r--r--    2 263      263       475028   Feb  9 12:26   xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm
-rw-r--r--    2 263      263       248668   Feb  9 12:27   xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm
-rw-r--r--    2 263      263       280184   Feb  5 22:08   xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm
-rw-r--r--    2 263      263       424771   Feb  5 19:36   xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm
-rw-r--r--    2 263      263       746854   Feb 11 02:43   xorg-x11-drv-radeonhd-1.3.0-5.4.20100210git.fc13.src.rpm
-rw-r--r--    2 263      263       323181   Feb  5 20:32   xorg-x11-drv-rendition-4.2.2-5.fc13.src.rpm
-rw-r--r--    2 263      263       285445   Feb  5 20:21   xorg-x11-drv-s3-0.6.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       308304   Feb  9 12:44   xorg-x11-drv-s3virge-1.10.4-2.fc13.src.rpm
-rw-r--r--    2 263      263       336582   Feb  5 18:39   xorg-x11-drv-savage-2.3.1-2.fc13.src.rpm
-rw-r--r--    2 263      263       587339   Feb  5 20:09   xorg-x11-drv-siliconmotion-1.7.3-3.20100122.fc13.src.rpm
-rw-r--r--    2 263      263       651516   Feb  5 16:33   xorg-x11-drv-sis-0.10.2-2.fc13.src.rpm
-rw-r--r--    2 263      263       329764   Feb  5 19:46   xorg-x11-drv-sisusb-0.9.3-2.fc13.src.rpm
-rw-r--r--    1 263      263       316085   Feb 18 23:34   xorg-x11-drv-synaptics-1.2.1-4.fc14.src.rpm
-rw-r--r--    2 263      263       298619   Feb  5 20:35   xorg-x11-drv-tdfx-1.4.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       305737   Feb  5 19:56   xorg-x11-drv-trident-1.3.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       292468   Feb  5 22:28   xorg-x11-drv-tseng-1.2.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       250893   Feb  5 21:17   xorg-x11-drv-v4l-0.2.0-4.fc13.1.src.rpm
-rw-r--r--    2 263      263       259661   Feb  5 16:27   xorg-x11-drv-vesa-2.2.1-2.fc13.src.rpm
-rw-r--r--    1 263      263       281386   Feb 12 06:37   xorg-x11-drv-vmmouse-12.6.6-1.fc13.src.rpm
-rw-r--r--    2 263      263       288560   Feb  9 13:16   xorg-x11-drv-vmware-10.16.7-3.fc13.src.rpm
-rw-r--r--    2 263      263       255811   Feb  5 22:30   xorg-x11-drv-void-1.3.0-5.fc13.src.rpm
-rw-r--r--    2 263      263       268147   Feb  5 21:35   xorg-x11-drv-voodoo-1.2.3-2.fc13.src.rpm
-rw-r--r--    1 263      263      2356579   Mar  4 00:05   xorg-x11-drv-wacom-0.10.4-5.20100219.fc14.src.rpm
-rw-r--r--    2 263      263       521166   Feb  5 22:42   xorg-x11-font-utils-7.2-11.fc13.src.rpm
-rw-r--r--    1 263      263     10315388   Feb 27 00:41   xorg-x11-fonts-7.2-9.fc12.src.rpm
-rw-r--r--    2 263      263      2165779   Feb 25 21:56   xorg-x11-proto-devel-7.4-36.fc13.src.rpm
-rw-r--r--    1 263      263       371754   Feb 26 20:39   xorg-x11-resutils-7.1-9.fc12.src.rpm
-rw-r--r--    1 263      263     35493506   Mar  4 05:51   xorg-x11-server-1.7.99.901-10.20100304.fc14.src.rpm
-rw-r--r--    2 263      263      1418431   Feb  5 16:50   xorg-x11-server-utils-7.4-15.fc13.src.rpm
-rw-r--r--    2 263      263       247211   Feb 12 05:41   xorg-x11-twm-1.0.3-6.fc13.src.rpm
-rw-r--r--    2 263      263        66840   Feb  9 12:03   xorg-x11-util-macros-1.5.0-1.fc13.src.rpm
-rw-r--r--    2 263      263       900166   Feb  9 11:40   xorg-x11-utils-7.4-9.fc13.src.rpm
-rw-r--r--    1 263      263       123367   Feb 27 03:05   xorg-x11-xauth-1.0.2-7.fc12.src.rpm
-rw-r--r--    2 263      263       108420   Feb  5 20:51   xorg-x11-xbitmaps-1.1.0-1.fc13.src.rpm
-rw-r--r--    1 263      263       415159   Feb 20 21:12   xorg-x11-xdm-1.1.6-16.fc13.src.rpm
-rw-r--r--    1 263      263       481668   Feb 27 02:56   xorg-x11-xfs-1.0.5-6.fc12.src.rpm
-rw-r--r--    1 263      263       282714   Feb 26 22:00   xorg-x11-xfwp-1.0.1-10.fc12.src.rpm
-rw-r--r--    1 263      263       153187   Feb 27 10:54   xorg-x11-xinit-1.0.9-15.fc14.src.rpm
-rw-r--r--    2 263      263       681572   Feb  5 16:57   xorg-x11-xkb-utils-7.4-7.fc13.src.rpm
-rw-r--r--    2 263      263       308671   Feb 11 02:35   xorg-x11-xsm-1.0.2-13.fc13.src.rpm
-rw-r--r--    1 263      263       110396   Feb 27 01:45   xorg-x11-xtrans-devel-1.2.2-4.fc12.src.rpm


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 8627 bytes --]

On Fri, 05 Mar 2010 11:00:30 +0100, "Carlos R. Mafra" said:

> Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> maintainers and keeping the whole thing tied up? Why can't it mimic the
> 'make menuconfig' way of selecting what to compile to have the guarantee that
> the whole thing will simply work nicely together?

Feel free to do so.  Note that you'll hit 2 problems:

1) In the kernel, the sysadmin can almost always get away with saying
"I have no XYZ devices" or "I only have ext4 filesystems" or similar choices,
and have the resulting kernel still support basically all the syscalls
(unless you start going into CONFIG_EMBEDDED and doing some *major* surgury).
Over on the X side of the fence, there aren't as many options that don't
involve dropping major chunks of the functionality.  You *sure* that nothing
on your system depends on the XRandR extension? ;)

2) Lately, the X server is *already* highly modular and different components
built from different source trees.  Note that the base X server is only about
half the size of the kernel RPM - there really isn't much left to trim out of
the base server anymore.

ncftp ...velopment/source/SRPMS > dir kern* xorg*
-rw-r--r--    1 263      263     66965350   Feb 26 18:03   kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm
-rw-r--r--    1 263      263        44300   Feb 27 01:39   xorg-sgml-doctools-1.1.1-4.fc12.src.rpm
-rw-r--r--    2 263      263      2229508   Feb 11 02:23   xorg-x11-apps-7.4-10.fc13.src.rpm
-rw-r--r--    1 263      263      8250097   Feb 27 00:06   xorg-x11-docs-1.3-6.fc12.src.rpm
-rw-r--r--    1 263      263         9718   Feb 27 03:27   xorg-x11-drivers-7.3-13.fc12.src.rpm
-rw-r--r--    2 263      263       263291   Feb  5 21:40   xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm
-rw-r--r--    2 263      263       271426   Feb  5 23:03   xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm
-rw-r--r--    1 263      263       293991   Feb 27 01:02   xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm
-rw-r--r--    2 263      263       247603   Feb  5 19:49   xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm
-rw-r--r--    1 263      263       273849   Feb 26 20:22   xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm
-rw-r--r--    1 263      263       475771   Feb 19 00:50   xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm
-rw-r--r--    1 263      263       354400   Feb 27 01:17   xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm
-rw-r--r--    2 263      263       296790   Feb  5 16:10   xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm
-rw-r--r--    2 263      263       257700   Feb  5 19:48   xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       260227   Feb  5 16:26   xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm
-rw-r--r--    2 263      263       537577   Feb  5 21:59   xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm
-rw-r--r--    2 263      263       254313   Feb  9 13:19   xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm
-rw-r--r--    1 263      263       252387   Feb 17 05:13   xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm
-rw-r--r--    2 263      263       608480   Feb  5 23:07   xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm
-rw-r--r--    2 263      263       361698   Feb  5 21:40   xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm
-rw-r--r--    2 263      263       244962   Feb  9 13:48   xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       289677   Feb  5 22:38   xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       281904   Feb  5 20:33   xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm
-rw-r--r--    1 263      263       978993   Feb 12 07:15   xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       305926   Feb  5 19:26   xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm
-rw-r--r--    2 263      263       296974   Feb  5 19:22   xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       492204   Feb  5 20:02   xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm
-rw-r--r--    2 263      263       427579   Feb  5 20:39   xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm
-rw-r--r--    2 263      263       318263   Feb  9 13:52   xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm
-rw-r--r--    2 263      263       254590   Feb  5 20:17   xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm
-rw-r--r--    2 263      263       290495   Feb  5 22:02   xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm
-rw-r--r--    2 263      263        91334   Feb 18 16:59   xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
-rw-r--r--    2 263      263       449803   Feb  9 12:19   xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm
-rw-r--r--    2 263      263       475028   Feb  9 12:26   xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm
-rw-r--r--    2 263      263       248668   Feb  9 12:27   xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm
-rw-r--r--    2 263      263       280184   Feb  5 22:08   xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm
-rw-r--r--    2 263      263       424771   Feb  5 19:36   xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm
-rw-r--r--    2 263      263       746854   Feb 11 02:43   xorg-x11-drv-radeonhd-1.3.0-5.4.20100210git.fc13.src.rpm
-rw-r--r--    2 263      263       323181   Feb  5 20:32   xorg-x11-drv-rendition-4.2.2-5.fc13.src.rpm
-rw-r--r--    2 263      263       285445   Feb  5 20:21   xorg-x11-drv-s3-0.6.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       308304   Feb  9 12:44   xorg-x11-drv-s3virge-1.10.4-2.fc13.src.rpm
-rw-r--r--    2 263      263       336582   Feb  5 18:39   xorg-x11-drv-savage-2.3.1-2.fc13.src.rpm
-rw-r--r--    2 263      263       587339   Feb  5 20:09   xorg-x11-drv-siliconmotion-1.7.3-3.20100122.fc13.src.rpm
-rw-r--r--    2 263      263       651516   Feb  5 16:33   xorg-x11-drv-sis-0.10.2-2.fc13.src.rpm
-rw-r--r--    2 263      263       329764   Feb  5 19:46   xorg-x11-drv-sisusb-0.9.3-2.fc13.src.rpm
-rw-r--r--    1 263      263       316085   Feb 18 23:34   xorg-x11-drv-synaptics-1.2.1-4.fc14.src.rpm
-rw-r--r--    2 263      263       298619   Feb  5 20:35   xorg-x11-drv-tdfx-1.4.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       305737   Feb  5 19:56   xorg-x11-drv-trident-1.3.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       292468   Feb  5 22:28   xorg-x11-drv-tseng-1.2.3-2.fc13.src.rpm
-rw-r--r--    2 263      263       250893   Feb  5 21:17   xorg-x11-drv-v4l-0.2.0-4.fc13.1.src.rpm
-rw-r--r--    2 263      263       259661   Feb  5 16:27   xorg-x11-drv-vesa-2.2.1-2.fc13.src.rpm
-rw-r--r--    1 263      263       281386   Feb 12 06:37   xorg-x11-drv-vmmouse-12.6.6-1.fc13.src.rpm
-rw-r--r--    2 263      263       288560   Feb  9 13:16   xorg-x11-drv-vmware-10.16.7-3.fc13.src.rpm
-rw-r--r--    2 263      263       255811   Feb  5 22:30   xorg-x11-drv-void-1.3.0-5.fc13.src.rpm
-rw-r--r--    2 263      263       268147   Feb  5 21:35   xorg-x11-drv-voodoo-1.2.3-2.fc13.src.rpm
-rw-r--r--    1 263      263      2356579   Mar  4 00:05   xorg-x11-drv-wacom-0.10.4-5.20100219.fc14.src.rpm
-rw-r--r--    2 263      263       521166   Feb  5 22:42   xorg-x11-font-utils-7.2-11.fc13.src.rpm
-rw-r--r--    1 263      263     10315388   Feb 27 00:41   xorg-x11-fonts-7.2-9.fc12.src.rpm
-rw-r--r--    2 263      263      2165779   Feb 25 21:56   xorg-x11-proto-devel-7.4-36.fc13.src.rpm
-rw-r--r--    1 263      263       371754   Feb 26 20:39   xorg-x11-resutils-7.1-9.fc12.src.rpm
-rw-r--r--    1 263      263     35493506   Mar  4 05:51   xorg-x11-server-1.7.99.901-10.20100304.fc14.src.rpm
-rw-r--r--    2 263      263      1418431   Feb  5 16:50   xorg-x11-server-utils-7.4-15.fc13.src.rpm
-rw-r--r--    2 263      263       247211   Feb 12 05:41   xorg-x11-twm-1.0.3-6.fc13.src.rpm
-rw-r--r--    2 263      263        66840   Feb  9 12:03   xorg-x11-util-macros-1.5.0-1.fc13.src.rpm
-rw-r--r--    2 263      263       900166   Feb  9 11:40   xorg-x11-utils-7.4-9.fc13.src.rpm
-rw-r--r--    1 263      263       123367   Feb 27 03:05   xorg-x11-xauth-1.0.2-7.fc12.src.rpm
-rw-r--r--    2 263      263       108420   Feb  5 20:51   xorg-x11-xbitmaps-1.1.0-1.fc13.src.rpm
-rw-r--r--    1 263      263       415159   Feb 20 21:12   xorg-x11-xdm-1.1.6-16.fc13.src.rpm
-rw-r--r--    1 263      263       481668   Feb 27 02:56   xorg-x11-xfs-1.0.5-6.fc12.src.rpm
-rw-r--r--    1 263      263       282714   Feb 26 22:00   xorg-x11-xfwp-1.0.1-10.fc12.src.rpm
-rw-r--r--    1 263      263       153187   Feb 27 10:54   xorg-x11-xinit-1.0.9-15.fc14.src.rpm
-rw-r--r--    2 263      263       681572   Feb  5 16:57   xorg-x11-xkb-utils-7.4-7.fc13.src.rpm
-rw-r--r--    2 263      263       308671   Feb 11 02:35   xorg-x11-xsm-1.0.2-13.fc13.src.rpm
-rw-r--r--    1 263      263       110396   Feb 27 01:45   xorg-x11-xtrans-devel-1.2.2-4.fc12.src.rpm


[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Matt Turner]

On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
> Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> maintainers and keeping the whole thing tied up? Why can't it mimic the
> 'make menuconfig' way of selecting what to compile to have the guarantee that
> the whole thing will simply work nicely together?

You must not follow X development at all. His name is Keith Packard.

Matt Turner

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote:
> On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
> > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> > maintainers and keeping the whole thing tied up? Why can't it mimic the
> > 'make menuconfig' way of selecting what to compile to have the guarantee that
> > the whole thing will simply work nicely together?
> 
> You must not follow X development at all. His name is Keith Packard.

Except that if you look at X lately, you'll realise that we do not have
the resources to even come close to being able to do this properly.  We
struggle to support what we have already today, and we've still been
hoping to create a real API, instead of the sad joke that is
/usr/include/xorg/*.h, for the last few years.  But we don't have enough
people (or at least enough people who aren't busy with the other parts
of their day jobs, or kids, or burnout, or whatever) to do it.

I understand that you guys are upset about this, so maybe you'd like to
donate, say, 10% of your developer base to help out? That'd be pretty
ace.

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Making Xorg easier to test

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 17:41:43 +0200

> I understand that you guys are upset about this, so maybe you'd like to
> donate, say, 10% of your developer base to help out? That'd be pretty
> ace.

You have to support less than %10 of the amount of hardware we have to
support.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 17:41:43 +0200

> I understand that you guys are upset about this, so maybe you'd like to
> donate, say, 10% of your developer base to help out? That'd be pretty
> ace.

You have to support less than %10 of the amount of hardware we have to
support.

Re: Making Xorg easier to test

[Alan Cox]

On Fri, 05 Mar 2010 07:49:32 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Daniel Stone <daniel@fooishbar.org>
> Date: Fri, 5 Mar 2010 17:41:43 +0200
> 
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
> 
> You have to support less than %10 of the amount of hardware we have to
> support.

If we believe the changelogs including X.org userspace then they also have
a good deal less than 10% of the contributors.

Alan

Re: Making Xorg easier to test

[Alan Cox]

On Fri, 05 Mar 2010 07:49:32 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Daniel Stone <daniel@fooishbar.org>
> Date: Fri, 5 Mar 2010 17:41:43 +0200
> 
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
> 
> You have to support less than %10 of the amount of hardware we have to
> support.

If we believe the changelogs including X.org userspace then they also have
a good deal less than 10% of the contributors.

Alan

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Fri, Mar 05, 2010 at 07:49:32AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
> 
> You have to support less than %10 of the amount of hardware we have to
> support.

With a great deal less than 10% of the number of developers.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Making Xorg easier to test

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 424 bytes --]

On Fri, Mar 05, 2010 at 07:49:32AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
> 
> You have to support less than %10 of the amount of hardware we have to
> support.

With a great deal less than 10% of the number of developers.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Making Xorg easier to test

[Xavier Bestel]

On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> Date: Fri, 5 Mar 2010 17:41:43 +0200
> 
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
> 
> You have to support less than %10 of the amount of hardware we have to
> support.

You can't compare a network card and a GPU. The latter is way more
complex to code for.

	Xav

Re: Making Xorg easier to test

[David Miller]

From: Xavier Bestel <xavier.bestel@free.fr>
Date: Fri, 05 Mar 2010 18:50:24 +0100

> On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
>> From: Daniel Stone <daniel@fooishbar.org>
>> Date: Fri, 5 Mar 2010 17:41:43 +0200
>> 
>> > I understand that you guys are upset about this, so maybe you'd like to
>> > donate, say, 10% of your developer base to help out? That'd be pretty
>> > ace.
>> 
>> You have to support less than %10 of the amount of hardware we have to
>> support.
> 
> You can't compare a network card and a GPU. The latter is way more
> complex to code for.

I wasn't talking specifically about network cards.  But if you want
specific examples...

How about the x86 or parisc cpu, and all their derivatives, are those
complex enough for you? :-)

I've worked on OpenGL capable grapics card drivers of various
vintages, and I honestly don't think there is anything in there more
complex than what we have to deal with in the kernel.

Re: Making Xorg easier to test

[Jesse Barnes]

On Fri, 05 Mar 2010 09:54:06 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Xavier Bestel <xavier.bestel@free.fr>
> Date: Fri, 05 Mar 2010 18:50:24 +0100
> 
> > On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
> >> From: Daniel Stone <daniel@fooishbar.org>
> >> Date: Fri, 5 Mar 2010 17:41:43 +0200
> >> 
> >> > I understand that you guys are upset about this, so maybe you'd like to
> >> > donate, say, 10% of your developer base to help out? That'd be pretty
> >> > ace.
> >> 
> >> You have to support less than %10 of the amount of hardware we have to
> >> support.
> > 
> > You can't compare a network card and a GPU. The latter is way more
> > complex to code for.
> 
> I wasn't talking specifically about network cards.  But if you want
> specific examples...
> 
> How about the x86 or parisc cpu, and all their derivatives, are those
> complex enough for you? :-)
> 
> I've worked on OpenGL capable grapics card drivers of various
> vintages, and I honestly don't think there is anything in there more
> complex than what we have to deal with in the kernel.

I think you must be saying this for the sake of argument.  The
complexity lies not in the programming interfaces exposed by the device
(those indeed are complex, more so than some CPUs, less so than
others).  The complexity lies in the fact that those interfaces change
from revision to revision, and even between boards sharing the same
chip.  And more than that, the interfaces exposed to applications are
spread across many software components, some of which send commands to
the hardware directly.  The problem Linus ran into is directly related
to this fact, because it involved the interfaces between a few of these
components.

So from that perspective, the graphics stack is the most complex one in
Linux by a long shot.  It's even worse than if we had STREAMS
networking with a ton of different modules up in userspace messing with
protocol. :)

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Making Xorg easier to test

[David Miller]

From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri, 5 Mar 2010 10:02:44 -0800

> So from that perspective, the graphics stack is the most complex one in
> Linux by a long shot.  It's even worse than if we had STREAMS
> networking with a ton of different modules up in userspace messing with
> protocol. :)

Maybe :-)

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test

[David Miller]

From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri, 5 Mar 2010 10:02:44 -0800

> So from that perspective, the graphics stack is the most complex one in
> Linux by a long shot.  It's even worse than if we had STREAMS
> networking with a ton of different modules up in userspace messing with
> protocol. :)

Maybe :-)

Re: Making Xorg easier to test

[Jesse Barnes]

On Fri, 05 Mar 2010 09:54:06 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Xavier Bestel <xavier.bestel@free.fr>
> Date: Fri, 05 Mar 2010 18:50:24 +0100
> 
> > On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
> >> From: Daniel Stone <daniel@fooishbar.org>
> >> Date: Fri, 5 Mar 2010 17:41:43 +0200
> >> 
> >> > I understand that you guys are upset about this, so maybe you'd like to
> >> > donate, say, 10% of your developer base to help out? That'd be pretty
> >> > ace.
> >> 
> >> You have to support less than %10 of the amount of hardware we have to
> >> support.
> > 
> > You can't compare a network card and a GPU. The latter is way more
> > complex to code for.
> 
> I wasn't talking specifically about network cards.  But if you want
> specific examples...
> 
> How about the x86 or parisc cpu, and all their derivatives, are those
> complex enough for you? :-)
> 
> I've worked on OpenGL capable grapics card drivers of various
> vintages, and I honestly don't think there is anything in there more
> complex than what we have to deal with in the kernel.

I think you must be saying this for the sake of argument.  The
complexity lies not in the programming interfaces exposed by the device
(those indeed are complex, more so than some CPUs, less so than
others).  The complexity lies in the fact that those interfaces change
from revision to revision, and even between boards sharing the same
chip.  And more than that, the interfaces exposed to applications are
spread across many software components, some of which send commands to
the hardware directly.  The problem Linus ran into is directly related
to this fact, because it involved the interfaces between a few of these
components.

So from that perspective, the graphics stack is the most complex one in
Linux by a long shot.  It's even worse than if we had STREAMS
networking with a ton of different modules up in userspace messing with
protocol. :)

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test

[David Miller]

From: Xavier Bestel <xavier.bestel@free.fr>
Date: Fri, 05 Mar 2010 18:50:24 +0100

> On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
>> From: Daniel Stone <daniel@fooishbar.org>
>> Date: Fri, 5 Mar 2010 17:41:43 +0200
>> 
>> > I understand that you guys are upset about this, so maybe you'd like to
>> > donate, say, 10% of your developer base to help out? That'd be pretty
>> > ace.
>> 
>> You have to support less than %10 of the amount of hardware we have to
>> support.
> 
> You can't compare a network card and a GPU. The latter is way more
> complex to code for.

I wasn't talking specifically about network cards.  But if you want
specific examples...

How about the x86 or parisc cpu, and all their derivatives, are those
complex enough for you? :-)

I've worked on OpenGL capable grapics card drivers of various
vintages, and I honestly don't think there is anything in there more
complex than what we have to deal with in the kernel.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test

[Xavier Bestel]

On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> Date: Fri, 5 Mar 2010 17:41:43 +0200
> 
> > I understand that you guys are upset about this, so maybe you'd like to
> > donate, say, 10% of your developer base to help out? That'd be pretty
> > ace.
> 
> You have to support less than %10 of the amount of hardware we have to
> support.

You can't compare a network card and a GPU. The latter is way more
complex to code for.

	Xav


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote:
> On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
> > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> > maintainers and keeping the whole thing tied up? Why can't it mimic the
> > 'make menuconfig' way of selecting what to compile to have the guarantee that
> > the whole thing will simply work nicely together?
> 
> You must not follow X development at all. His name is Keith Packard.

Except that if you look at X lately, you'll realise that we do not have
the resources to even come close to being able to do this properly.  We
struggle to support what we have already today, and we've still been
hoping to create a real API, instead of the sad joke that is
/usr/include/xorg/*.h, for the last few years.  But we don't have enough
people (or at least enough people who aren't busy with the other parts
of their day jobs, or kids, or burnout, or whatever) to do it.

I understand that you guys are upset about this, so maybe you'd like to
donate, say, 10% of your developer base to help out? That'd be pretty
ace.

Cheers,
Daniel

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Matt Turner]

On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
> Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> maintainers and keeping the whole thing tied up? Why can't it mimic the
> 'make menuconfig' way of selecting what to compile to have the guarantee that
> the whole thing will simply work nicely together?

You must not follow X development at all. His name is Keith Packard.

Matt Turner

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Linus Torvalds]

On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
> 
> Whereas everytime I wanted to do that with Xorg it was such a pain that
> I want to keep away from that mess.

Actually, take it from me: Xorg is _pleasant_ to test these days.

Ok, so that's partly compared to the mess it _used_ to be, but it's really 
night and day. The whole build system was so incredibly baroque and heavy 
that you really had to understand it deeply if you wanted to do anything 
fancy.

And the non-fancy alternative was to just build the whole thing, which 
took _hours_ even on fast machines because the build system overhead was 
near-infinite (I dunno, maybe parallel builds could be made to work, but 
it took more brain-power than I could ever put into it).

These days, there's a few dependencies you need to know about (I do agree 
that from a user perspective the thing might have been made a bit _too_ 
modular) but they are generally fairly trivial, and there are scripts to 
download all the drivers and misc utilities needed.

And the modularization often works: you can often (but by no means always; 
it does require that the other parts are "close enough" and that there 
haven't been any major changes) just have the source code to the one 
driver you care about, and recompile and install just that _single_ 
driver.

I've done it. It's becautiful when it works. And it's a major pain when 
you notice it didn't work, and you needed to get the whole server and 
libdrm trees after all, and now you're not replacing single files any 
more and have little idea what it will stomp on in your distro.

So it really is very convenient when it works. And X doesn't have 
thousands of drivers like the kernel (maybe 10-15 that people care about 
at all, and about three or four that actually really matter), and there 
are seldom huge changes that affect them all, so the modularization 
doesn't turn totally crazy.

So I can see where the Xorg people really like their new modular world. It 
does work, it's _sooo_ much better than the mess it used to be, and the 
problems are fairly manageable when they do happen. 

The modular approach really works very well when there aren't lots of 
interactions between the modules, and when the modules are few enough that 
it isn't a total disaster (imagine doing a change that requires changes to 
all drivers in Xorg, vs doing a change that requires changes to all 
drivers in the kernel - the modular approach simply wouldn't work for the 
latter case, because you'd spend all your time just chasing down external 
users).

That said, the _one_ thing I really wish could be done would be to make it 
easier to install things side-by-side - and with the modularization, you 
really do want to do it module-by-module. One of the things that makes it 
so easy to test the kernel is that when you install one kernel, that 
doesn't affect the others, and you can go back-and-forth in testing. 
That's really important, because it makes testing trivial and non-scary 
even in the presense of issues that makes the new version unusable.

				Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Linus Torvalds]

On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
> 
> Whereas everytime I wanted to do that with Xorg it was such a pain that
> I want to keep away from that mess.

Actually, take it from me: Xorg is _pleasant_ to test these days.

Ok, so that's partly compared to the mess it _used_ to be, but it's really 
night and day. The whole build system was so incredibly baroque and heavy 
that you really had to understand it deeply if you wanted to do anything 
fancy.

And the non-fancy alternative was to just build the whole thing, which 
took _hours_ even on fast machines because the build system overhead was 
near-infinite (I dunno, maybe parallel builds could be made to work, but 
it took more brain-power than I could ever put into it).

These days, there's a few dependencies you need to know about (I do agree 
that from a user perspective the thing might have been made a bit _too_ 
modular) but they are generally fairly trivial, and there are scripts to 
download all the drivers and misc utilities needed.

And the modularization often works: you can often (but by no means always; 
it does require that the other parts are "close enough" and that there 
haven't been any major changes) just have the source code to the one 
driver you care about, and recompile and install just that _single_ 
driver.

I've done it. It's becautiful when it works. And it's a major pain when 
you notice it didn't work, and you needed to get the whole server and 
libdrm trees after all, and now you're not replacing single files any 
more and have little idea what it will stomp on in your distro.

So it really is very convenient when it works. And X doesn't have 
thousands of drivers like the kernel (maybe 10-15 that people care about 
at all, and about three or four that actually really matter), and there 
are seldom huge changes that affect them all, so the modularization 
doesn't turn totally crazy.

So I can see where the Xorg people really like their new modular world. It 
does work, it's _sooo_ much better than the mess it used to be, and the 
problems are fairly manageable when they do happen. 

The modular approach really works very well when there aren't lots of 
interactions between the modules, and when the modules are few enough that 
it isn't a total disaster (imagine doing a change that requires changes to 
all drivers in Xorg, vs doing a change that requires changes to all 
drivers in the kernel - the modular approach simply wouldn't work for the 
latter case, because you'd spend all your time just chasing down external 
users).

That said, the _one_ thing I really wish could be done would be to make it 
easier to install things side-by-side - and with the modularization, you 
really do want to do it module-by-module. One of the things that makes it 
so easy to test the kernel is that when you install one kernel, that 
doesn't affect the others, and you can go back-and-forth in testing. 
That's really important, because it makes testing trivial and non-scary 
even in the presense of issues that makes the new version unusable.

				Linus

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Hi,

On Fri, Mar 05, 2010 at 07:53:46AM -0800, Linus Torvalds wrote:
> These days, there's a few dependencies you need to know about (I do agree 
> that from a user perspective the thing might have been made a bit _too_ 
> modular)

Indeed, no argument here.

> That said, the _one_ thing I really wish could be done would be to make it 
> easier to install things side-by-side - and with the modularization, you 
> really do want to do it module-by-module. One of the things that makes it 
> so easy to test the kernel is that when you install one kernel, that 
> doesn't affect the others, and you can go back-and-forth in testing. 
> That's really important, because it makes testing trivial and non-scary 
> even in the presense of issues that makes the new version unusable.

FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
the usual approach is to install your new server + drivers into a
separate prefix.

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Linus Torvalds]

On Fri, 5 Mar 2010, Daniel Stone wrote:
> 
> FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
> the usual approach is to install your new server + drivers into a
> separate prefix.

The thing is, Xorg has - and I think for _very_ good reasons - deprecated 
using xorg.conf at all. So most people don't even have one (I certainly 
don't), and wouldn't know how to create one in the first place.

And yeah, I used to happily edit timing lines and make up non-standard 
modes for my monitor, but I have to admit that I never _ever_ want to 
touch that file ever again. Last time I tried to, it was to set DPI to be 
something sane, but these days X gets even that right automatically, and 
no longer does the insane "set DPY by size of the screen" thing any more.

And I think all of the reasons xorg.conf is basically being deprecated are 
valid for this case too. Switching between kernels is - in this case, due 
to the whole API change - effectively the same as switching the graphics 
card in the machine, but without even the ability to _name_ the cards and 
share a xorg.conf for the two cases (not that I think that you could do 
different ModulePath's per display anyway).

So yeah, you could "switch between kernels, start out in init 3, edit 
xorg.conf appropriately, switch to init 5", but once you start doing that, 
you might as well just switch a symlink around instead - it's easier.

So I don't think xorg.conf is a help.

				Linus

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Daniel Stone]

On Fri, Mar 05, 2010 at 08:30:38AM -0800, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Daniel Stone wrote:
> > FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
> > the usual approach is to install your new server + drivers into a
> > separate prefix.
> 
> The thing is, Xorg has - and I think for _very_ good reasons - deprecated 
> using xorg.conf at all. So most people don't even have one (I certainly 
> don't), and wouldn't know how to create one in the first place.

Most people don't know how to bisect the kernel, either. :)

xorg.conf hasn't at all been deprecated, beyond autoconf and
xorg.conf.d.  The goal was to ensure that no-one needed an xorg.conf _by
default_, which I can quite safely say we've since achieved, but
xorg.conf(.d) remains as the way to tell the server your non-default
requirements.

Anyway, badly OT here, so.

Cheers,
Daniel

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Daniel Stone]

On Fri, Mar 05, 2010 at 08:30:38AM -0800, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Daniel Stone wrote:
> > FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
> > the usual approach is to install your new server + drivers into a
> > separate prefix.
> 
> The thing is, Xorg has - and I think for _very_ good reasons - deprecated 
> using xorg.conf at all. So most people don't even have one (I certainly 
> don't), and wouldn't know how to create one in the first place.

Most people don't know how to bisect the kernel, either. :)

xorg.conf hasn't at all been deprecated, beyond autoconf and
xorg.conf.d.  The goal was to ensure that no-one needed an xorg.conf _by
default_, which I can quite safely say we've since achieved, but
xorg.conf(.d) remains as the way to tell the server your non-default
requirements.

Anyway, badly OT here, so.

Cheers,
Daniel

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Linus Torvalds]

On Fri, 5 Mar 2010, Daniel Stone wrote:
> 
> FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
> the usual approach is to install your new server + drivers into a
> separate prefix.

The thing is, Xorg has - and I think for _very_ good reasons - deprecated 
using xorg.conf at all. So most people don't even have one (I certainly 
don't), and wouldn't know how to create one in the first place.

And yeah, I used to happily edit timing lines and make up non-standard 
modes for my monitor, but I have to admit that I never _ever_ want to 
touch that file ever again. Last time I tried to, it was to set DPI to be 
something sane, but these days X gets even that right automatically, and 
no longer does the insane "set DPY by size of the screen" thing any more.

And I think all of the reasons xorg.conf is basically being deprecated are 
valid for this case too. Switching between kernels is - in this case, due 
to the whole API change - effectively the same as switching the graphics 
card in the machine, but without even the ability to _name_ the cards and 
share a xorg.conf for the two cases (not that I think that you could do 
different ModulePath's per display anyway).

So yeah, you could "switch between kernels, start out in init 3, edit 
xorg.conf appropriately, switch to init 5", but once you start doing that, 
you might as well just switch a symlink around instead - it's easier.

So I don't think xorg.conf is a help.

				Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 973 bytes --]

Hi,

On Fri, Mar 05, 2010 at 07:53:46AM -0800, Linus Torvalds wrote:
> These days, there's a few dependencies you need to know about (I do agree 
> that from a user perspective the thing might have been made a bit _too_ 
> modular)

Indeed, no argument here.

> That said, the _one_ thing I really wish could be done would be to make it 
> easier to install things side-by-side - and with the modularization, you 
> really do want to do it module-by-module. One of the things that makes it 
> so easy to test the kernel is that when you install one kernel, that 
> doesn't affect the others, and you can go back-and-forth in testing. 
> That's really important, because it makes testing trivial and non-scary 
> even in the presense of issues that makes the new version unusable.

FWIW, Option "ModulePath" in xorg.conf lets you more or less do this;
the usual approach is to install your new server + drivers into a
separate prefix.

Cheers,
Daniel

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Jesse Barnes]

On Fri, 5 Mar 2010 07:53:46 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
> > 
> > Whereas everytime I wanted to do that with Xorg it was such a pain that
> > I want to keep away from that mess.
> 
> Actually, take it from me: Xorg is _pleasant_ to test these days.
> 
> Ok, so that's partly compared to the mess it _used_ to be, but it's really 
> night and day. The whole build system was so incredibly baroque and heavy 
> that you really had to understand it deeply if you wanted to do anything 
> fancy.
> 
> And the non-fancy alternative was to just build the whole thing, which 
> took _hours_ even on fast machines because the build system overhead was 
> near-infinite (I dunno, maybe parallel builds could be made to work, but 
> it took more brain-power than I could ever put into it).
> 
> These days, there's a few dependencies you need to know about (I do agree 
> that from a user perspective the thing might have been made a bit _too_ 
> modular) but they are generally fairly trivial, and there are scripts to 
> download all the drivers and misc utilities needed.

Just FYI for those following this thread; testing the server and 3D
drivers really isn't too much trouble these days, you can even install
everything into a separate path (I usually choose /opt-gfx-test); you
just need to build libdrm, mesa, xserver and your video driver (along
with an input driver or tw) in that order.  Then just startx
-- /opt/gfx-test/bin/Xorg and put something reasonable in .xinitrc.

Full instructions at http://wiki.x.org/wiki/Development/BuildingX.

--
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Jesse Barnes]

On Fri, 5 Mar 2010 07:53:46 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
> > 
> > Whereas everytime I wanted to do that with Xorg it was such a pain that
> > I want to keep away from that mess.
> 
> Actually, take it from me: Xorg is _pleasant_ to test these days.
> 
> Ok, so that's partly compared to the mess it _used_ to be, but it's really 
> night and day. The whole build system was so incredibly baroque and heavy 
> that you really had to understand it deeply if you wanted to do anything 
> fancy.
> 
> And the non-fancy alternative was to just build the whole thing, which 
> took _hours_ even on fast machines because the build system overhead was 
> near-infinite (I dunno, maybe parallel builds could be made to work, but 
> it took more brain-power than I could ever put into it).
> 
> These days, there's a few dependencies you need to know about (I do agree 
> that from a user perspective the thing might have been made a bit _too_ 
> modular) but they are generally fairly trivial, and there are scripts to 
> download all the drivers and misc utilities needed.

Just FYI for those following this thread; testing the server and 3D
drivers really isn't too much trouble these days, you can even install
everything into a separate path (I usually choose /opt-gfx-test); you
just need to build libdrm, mesa, xserver and your video driver (along
with an input driver or tw) in that order.  Then just startx
-- /opt/gfx-test/bin/Xorg and put something reasonable in .xinitrc.

Full instructions at http://wiki.x.org/wiki/Development/BuildingX.

--
Jesse Barnes, Intel Open Source Technology Center

Making Xorg easier to test (was Re: [git pull] drm request 3)

[Carlos R. Mafra]

On Fri  5.Mar'10 at  8:44:07 +0100, Ingo Molnar wrote:
> 
> Yeah. I've seen a few other bad arguments as well:
> 
>    'exploding test matrix'
> 
> This is often the result of _another_ bad technical decision: 
> over-modularization.
> 
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:

I agree 100% with this!

I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because
it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install 
and I am ready to test the bleeding edge kernel. 
And everytime I complained about something breaking it got fixed.

Really, testing the linux kernel is a hobby for me because it is easy.

Whereas everytime I wanted to do that with Xorg it was such a pain that
I want to keep away from that mess.
 
>  - it's developed by the same tightly knit developer base who often cross
>    between these packages. Features often need changes in each component.
> 
>  - a developer to be able to do real work has to have the latest sources
>    of all these components.
> 
>  - a user just uses whatever horizontal version cut the distro did and never
>    truly 'mixes' these components as a conscious decision.

True!

Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
maintainers and keeping the whole thing tied up? Why can't it mimic the
'make menuconfig' way of selecting what to compile to have the guarantee that 
the whole thing will simply work nicely together?

If this could be done for the kernel (which from my user POV seems much more
complicated), I guess it could be done with Xorg. And Linux would have
more Xorg testers and be better as a whole.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Luc Verhaegen]

On Fri, Mar 05, 2010 at 08:44:07AM +0100, Ingo Molnar wrote:
> 
> Yeah. I've seen a few other bad arguments as well:
> 
>    'exploding test matrix'
> 
> This is often the result of _another_ bad technical decision: 
> over-modularization.
> 
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
> 
>  - it's developed by the same tightly knit developer base who often cross
>    between these packages. Features often need changes in each component.
> 
>  - a developer to be able to do real work has to have the latest sources
>    of all these components.
> 
>  - a user just uses whatever horizontal version cut the distro did and never
>    truly 'mixes' these components as a conscious decision.
> 
>  - distros just try to get the latest and most capable but still stable
>    version. Desperately so. Often they will create a version mix that was
>    never tested by developers in that form. They'll expose users to ABI
>    combinations that were never really intended. They have trouble
>    bootstrapping and stabilizing those essentially random combinations and
>    then have trouble applying stability and security fixes.
> 
> The thing is, if development has such characteristics then it's pretty clearly 
> not 3-4 separate projects but _one_ abstract project. [*]
> 
> So the 'exploding test matrix' is simply the result of: creating ABIs between 
> 3-4 _artificial components of the same project_ and then going through 
> developer hell living with that mistake. [**]
> 
> It's a bit as if we split up the kernel into 'microkernel' components, did a 
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and 
> then tried to develop them as separate components.
> 
> If we did then then Linux kernel development would slow down massively while 
> in reality everyone would _still_ have to have the latest and greatest source 
> checked out to do some real development work and to be able to implement 
> features that affect the whole kernel ...
> 
> Linux would become an epic fail of historic proportions if we ever did that.
> 
> 	Ingo
> 
> [*]  I realize that it's possibly hard for Xorg to merge with mesa and the 
>      kernel for license reasons, but my technical observation still stands.
> 
> [**] I realize that modularization and many small packages were a clear 
>      advantage when we were still all downloading bits via 14.4k modems, but 
>      in this day and age of megabit connections that has become a non-issue.
>      Rampant over-modularization and the resulting loss of focus on the end
>      result (and the resulting explosion of a test matrix) is hurting us _far 
>      more_ than the disadvantages of any monolithic could ever hurt. We are 
>      seeing the proof of that all day with a 10+ MLOC kernel.

Tying kernel, libdrm, X and mesa together 1-1 is not going to help
anybody. When thinking along the same line of your reasoning, the answer 
is unifying graphics driver stacks, which requires increased 
modularization (in libdrm and mesa): one big abstract project.

All of X.org, libdrm, drm, mesa/dri, mesa/gallium, all have relatively 
stable interfaces as they are supposed to support multiple (from 3 
(libdrm) to ~50 (Xorg)) drivers. It's driver internal interfaces that 
are highly volatile, as it is easy to adjust all parts inside the same 
graphics driver stack, especially since the same developers know all 
these parts and it supports the same hw.

On top, graphics driver are special, they are as complex and diverse as 
the hardware. So, graphics driver stacks can currently have up to 7-8 
pieces spread everywhere: kernel drm driver, firmware, libdrm driver, 
Xorg driver, 2 mesa drivers, 1-2 media acceleration libraries. All 
spreading inherently unstable interfaces everywhere.

Graphics drivers will always be complex, and buggy and unstable, but we 
should try to encapsulate some of that mess in a way that makes sense.

I had a talk on FOSDEM about this which was very "warmly" received by 
some; the slides are here 
http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1

Luc Verhaegen.

Re: [git pull] drm request 3

[Luc Verhaegen]

On Fri, Mar 05, 2010 at 08:44:07AM +0100, Ingo Molnar wrote:
> 
> Yeah. I've seen a few other bad arguments as well:
> 
>    'exploding test matrix'
> 
> This is often the result of _another_ bad technical decision: 
> over-modularization.
> 
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
> 
>  - it's developed by the same tightly knit developer base who often cross
>    between these packages. Features often need changes in each component.
> 
>  - a developer to be able to do real work has to have the latest sources
>    of all these components.
> 
>  - a user just uses whatever horizontal version cut the distro did and never
>    truly 'mixes' these components as a conscious decision.
> 
>  - distros just try to get the latest and most capable but still stable
>    version. Desperately so. Often they will create a version mix that was
>    never tested by developers in that form. They'll expose users to ABI
>    combinations that were never really intended. They have trouble
>    bootstrapping and stabilizing those essentially random combinations and
>    then have trouble applying stability and security fixes.
> 
> The thing is, if development has such characteristics then it's pretty clearly 
> not 3-4 separate projects but _one_ abstract project. [*]
> 
> So the 'exploding test matrix' is simply the result of: creating ABIs between 
> 3-4 _artificial components of the same project_ and then going through 
> developer hell living with that mistake. [**]
> 
> It's a bit as if we split up the kernel into 'microkernel' components, did a 
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and 
> then tried to develop them as separate components.
> 
> If we did then then Linux kernel development would slow down massively while 
> in reality everyone would _still_ have to have the latest and greatest source 
> checked out to do some real development work and to be able to implement 
> features that affect the whole kernel ...
> 
> Linux would become an epic fail of historic proportions if we ever did that.
> 
> 	Ingo
> 
> [*]  I realize that it's possibly hard for Xorg to merge with mesa and the 
>      kernel for license reasons, but my technical observation still stands.
> 
> [**] I realize that modularization and many small packages were a clear 
>      advantage when we were still all downloading bits via 14.4k modems, but 
>      in this day and age of megabit connections that has become a non-issue.
>      Rampant over-modularization and the resulting loss of focus on the end
>      result (and the resulting explosion of a test matrix) is hurting us _far 
>      more_ than the disadvantages of any monolithic could ever hurt. We are 
>      seeing the proof of that all day with a 10+ MLOC kernel.

Tying kernel, libdrm, X and mesa together 1-1 is not going to help
anybody. When thinking along the same line of your reasoning, the answer 
is unifying graphics driver stacks, which requires increased 
modularization (in libdrm and mesa): one big abstract project.

All of X.org, libdrm, drm, mesa/dri, mesa/gallium, all have relatively 
stable interfaces as they are supposed to support multiple (from 3 
(libdrm) to ~50 (Xorg)) drivers. It's driver internal interfaces that 
are highly volatile, as it is easy to adjust all parts inside the same 
graphics driver stack, especially since the same developers know all 
these parts and it supports the same hw.

On top, graphics driver are special, they are as complex and diverse as 
the hardware. So, graphics driver stacks can currently have up to 7-8 
pieces spread everywhere: kernel drm driver, firmware, libdrm driver, 
Xorg driver, 2 mesa drivers, 1-2 media acceleration libraries. All 
spreading inherently unstable interfaces everywhere.

Graphics drivers will always be complex, and buggy and unstable, but we 
should try to encapsulate some of that mess in a way that makes sense.

I had a talk on FOSDEM about this which was very "warmly" received by 
some; the slides are here 
http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1

Luc Verhaegen.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Fri, 5 Mar 2010 08:44:07 +0100
Ingo Molnar <mingo@elte.hu> wrote:
> It's a bit as if we split up the kernel into 'microkernel' components, did a 
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and 
> then tried to develop them as separate components.
> 
> If we did then then Linux kernel development would slow down massively while 
> in reality everyone would _still_ have to have the latest and greatest source 
> checked out to do some real development work and to be able to implement 
> features that affect the whole kernel ...
> 
> Linux would become an epic fail of historic proportions if we ever did that.

This is a very good point, and something we've been wrestling with in
the gfx community.  Awhile back we separated the X drivers from the X
core; I feel this was a mistake for the reasons you mention above.
It's just plain harder to fix issues when you have to rev the ABI with
every change, make sure both the old/new and new/old combinations work,
and generally improve things like we do inside of Linux.

> [*]  I realize that it's possibly hard for Xorg to merge with mesa and the 
>      kernel for license reasons, but my technical observation still stands.

No we don't need to merge them fortunately.  With GEM and KMS we've
pushed two major bits of functionality into the kernel; bits that were
badly split between all portions of the stack before.  With EGL, we can
push a lot of what X did into Mesa.  There are even some projects to
make a very thin X driver or separate display server sit directly on
top of Mesa + EGL, unifying things further.  So I really think things
are getting better here, not worse (the nouveau issue here aside).

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Fri, 5 Mar 2010 08:44:07 +0100
Ingo Molnar <mingo@elte.hu> wrote:
> It's a bit as if we split up the kernel into 'microkernel' components, did a 
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and 
> then tried to develop them as separate components.
> 
> If we did then then Linux kernel development would slow down massively while 
> in reality everyone would _still_ have to have the latest and greatest source 
> checked out to do some real development work and to be able to implement 
> features that affect the whole kernel ...
> 
> Linux would become an epic fail of historic proportions if we ever did that.

This is a very good point, and something we've been wrestling with in
the gfx community.  Awhile back we separated the X drivers from the X
core; I feel this was a mistake for the reasons you mention above.
It's just plain harder to fix issues when you have to rev the ABI with
every change, make sure both the old/new and new/old combinations work,
and generally improve things like we do inside of Linux.

> [*]  I realize that it's possibly hard for Xorg to merge with mesa and the 
>      kernel for license reasons, but my technical observation still stands.

No we don't need to merge them fortunately.  With GEM and KMS we've
pushed two major bits of functionality into the kernel; bits that were
badly split between all portions of the stack before.  With EGL, we can
push a lot of what X did into Mesa.  There are even some projects to
make a very thin X driver or separate display server sit directly on
top of Mesa + EGL, unifying things further.  So I really think things
are getting better here, not worse (the nouveau issue here aside).

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Alan Cox]

> The conclusion is crystal clear, breaking an ABI via a "flag day" 
> cleanup/feature/etc is:

Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
junk that is in there being cleaned up it would be *insane* to keep their
old APIs

See there's a bigger offence than breaking an ABI - its called not RTFM.

Alan

Re: [git pull] drm request 3

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 12:38:34 +0000

>> The conclusion is crystal clear, breaking an ABI via a "flag day" 
>> cleanup/feature/etc is:
> 
> Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
> junk that is in there being cleaned up it would be *insane* to keep their
> old APIs
> 
> See there's a bigger offence than breaking an ABI - its called not RTFM.

All of this RTFM and what directory the noveau driver is sitting in is
entirely irrelevant Alan.

If it effects such a large number of people, which this noveau thing
does, it's entirely relevant to everyone.  And the way it's breaking
and making kernel development difficult for so many people matters to
us.

It's about the tester base, and this breakage shrinks the tester base
considerably.

Or do you want the kernel tested by less people?

Re: [git pull] drm request 3

[Mike Galbraith]

On Fri, 2010-03-05 at 06:37 -0800, David Miller wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Fri, 5 Mar 2010 12:38:34 +0000
> 
> >> The conclusion is crystal clear, breaking an ABI via a "flag day" 
> >> cleanup/feature/etc is:
> > 
> > Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
> > junk that is in there being cleaned up it would be *insane* to keep their
> > old APIs
> > 
> > See there's a bigger offence than breaking an ABI - its called not RTFM.
> 
> All of this RTFM and what directory the noveau driver is sitting in is
> entirely irrelevant Alan.
> 
> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone.  And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.
> 
> It's about the tester base, and this breakage shrinks the tester base
> considerably.
> 
> Or do you want the kernel tested by less people?

On the bright side, all this hubbub sends a very positive message to the
noveau development crew.  Folks, your work is important.  I'd be proud
as a peacock :)

	-Mike


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Mike Galbraith]

On Fri, 2010-03-05 at 06:37 -0800, David Miller wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Fri, 5 Mar 2010 12:38:34 +0000
> 
> >> The conclusion is crystal clear, breaking an ABI via a "flag day" 
> >> cleanup/feature/etc is:
> > 
> > Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
> > junk that is in there being cleaned up it would be *insane* to keep their
> > old APIs
> > 
> > See there's a bigger offence than breaking an ABI - its called not RTFM.
> 
> All of this RTFM and what directory the noveau driver is sitting in is
> entirely irrelevant Alan.
> 
> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone.  And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.
> 
> It's about the tester base, and this breakage shrinks the tester base
> considerably.
> 
> Or do you want the kernel tested by less people?

On the bright side, all this hubbub sends a very positive message to the
noveau development crew.  Folks, your work is important.  I'd be proud
as a peacock :)

	-Mike

Re: [git pull] drm request 3

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> On the bright side, all this hubbub sends a very positive message to the 
> noveau development crew.  Folks, your work is important.  I'd be proud as a 
> peacock :)

Heh, most definitely so!

Noveau really is a game-changer i think, it's a big break-through for Xorg 
IMO.

For the first time in Linux history we support 90%+ of graphics hardware in a 
more or less acceptable way. That is a big deal really and the xorg/drm folks 
should be proud of that accomplishment.

It solves the nvidia.ko mess to a large degree and moves all these things into 
an actionable technical domain. I'm so much happier to argue with OSS folks 
who write this code than having to look at nvidia.ko tainted kernel crash 
logs.

	Ingo

Re: [git pull] drm request 3

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> On the bright side, all this hubbub sends a very positive message to the 
> noveau development crew.  Folks, your work is important.  I'd be proud as a 
> peacock :)

Heh, most definitely so!

Noveau really is a game-changer i think, it's a big break-through for Xorg 
IMO.

For the first time in Linux history we support 90%+ of graphics hardware in a 
more or less acceptable way. That is a big deal really and the xorg/drm folks 
should be proud of that accomplishment.

It solves the nvidia.ko mess to a large degree and moves all these things into 
an actionable technical domain. I'm so much happier to argue with OSS folks 
who write this code than having to look at nvidia.ko tainted kernel crash 
logs.

	Ingo

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone.  And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.
> 
> It's about the tester base, and this breakage shrinks the tester base
> considerably.
> 
> Or do you want the kernel tested by less people?

I think you miss a bigger picture ?

If Fedora hadn't merged it then it wouldn't have gotten to the state of
usability it had. If Fedora hadn't merged it then several hundred
thousand users wouldn't have had useful working machines.

So - do you want Linux used by a lot less people, and to have no Nvidia
driver ?

See - its all about viewpoints. Do you think screaming at people who did
no wrong increases the kernel developer and testing base ? No I thought
not.

To be honest the big thing I object to here is certain people who
should know better behaving like small children. Not just in the sense of
throwing their toys around because mummy didn't buy them the right
sweetie but in not thinking about how other people see the problem and
their actions.

- Fedora merged the stuff to make it work and to improve life for lots of
  users. Good intent, rational logical behaviour

- Linus asked for it to be merged and was warned about the ABI. He did
  that for good, sound reasons.

- The developers accepted the merge to staging so they could fix the ABI
  later, they made that clear - again all good sound intentions

- The ABI change and clean up was done - again good sound intentions,
  rational behaviour

- Linus then threw a tantrum. He's right there are issues about how user
  migration should be handled but he didn't need to go screaming at the
  DRM people (not their fault), Fedora (who had good sensible goals in
  what they did) or the Nouveau people (who told him what was going on
  well in advance and did exactly what was asked of them before)

Firstly he's being hypocritical (he keeps saying he doesn't want to
control distributions, he even refused to allow ext2 to be merged *until*
Red Hat shipped it), he was told clearly, and staging is for unfixed ABIs.
Secondly he's shouting at people who all did a right thing, which only
produces bad feelings.

All that was needed was a

"Hey guys, I know its in staging but this is going to be a problem, can
 we either fix back compatibility or have some kind of migration policy
 and the tools so I can test it - otherwise I can't merge this"

No blaming, no tantrums, no judgemental comments from a single viewpoint.
A collection of good intentions produced a problem. It happens all the
time, screaming and blaming may be how politicians sometimes behave but we
can surely do better ?

Alan

Re: [git pull] drm request 3

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 15:09:34 +0000

> I think you miss a bigger picture ?
> 
> If Fedora hadn't merged it then it wouldn't have gotten to the state of
> usability it had. If Fedora hadn't merged it then several hundred
> thousand users wouldn't have had useful working machines.

I think Fedora were right to merge it, and I think it was proper to
merge it into the upstream kernel.

But I also think the large size of that userbase should have been
respected by "doing the right thing" here, and that means not making
it so hard for Fedora users to use upstream kernels out of the box.

Making the "sandbox" claim cuts both ways Alan.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 15:09:34 +0000

> I think you miss a bigger picture ?
> 
> If Fedora hadn't merged it then it wouldn't have gotten to the state of
> usability it had. If Fedora hadn't merged it then several hundred
> thousand users wouldn't have had useful working machines.

I think Fedora were right to merge it, and I think it was proper to
merge it into the upstream kernel.

But I also think the large size of that userbase should have been
respected by "doing the right thing" here, and that means not making
it so hard for Fedora users to use upstream kernels out of the box.

Making the "sandbox" claim cuts both ways Alan.

Re: [git pull] drm request 3

[Alan Cox]

> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone.  And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.
> 
> It's about the tester base, and this breakage shrinks the tester base
> considerably.
> 
> Or do you want the kernel tested by less people?

I think you miss a bigger picture ?

If Fedora hadn't merged it then it wouldn't have gotten to the state of
usability it had. If Fedora hadn't merged it then several hundred
thousand users wouldn't have had useful working machines.

So - do you want Linux used by a lot less people, and to have no Nvidia
driver ?

See - its all about viewpoints. Do you think screaming at people who did
no wrong increases the kernel developer and testing base ? No I thought
not.

To be honest the big thing I object to here is certain people who
should know better behaving like small children. Not just in the sense of
throwing their toys around because mummy didn't buy them the right
sweetie but in not thinking about how other people see the problem and
their actions.

- Fedora merged the stuff to make it work and to improve life for lots of
  users. Good intent, rational logical behaviour

- Linus asked for it to be merged and was warned about the ABI. He did
  that for good, sound reasons.

- The developers accepted the merge to staging so they could fix the ABI
  later, they made that clear - again all good sound intentions

- The ABI change and clean up was done - again good sound intentions,
  rational behaviour

- Linus then threw a tantrum. He's right there are issues about how user
  migration should be handled but he didn't need to go screaming at the
  DRM people (not their fault), Fedora (who had good sensible goals in
  what they did) or the Nouveau people (who told him what was going on
  well in advance and did exactly what was asked of them before)

Firstly he's being hypocritical (he keeps saying he doesn't want to
control distributions, he even refused to allow ext2 to be merged *until*
Red Hat shipped it), he was told clearly, and staging is for unfixed ABIs.
Secondly he's shouting at people who all did a right thing, which only
produces bad feelings.

All that was needed was a

"Hey guys, I know its in staging but this is going to be a problem, can
 we either fix back compatibility or have some kind of migration policy
 and the tools so I can test it - otherwise I can't merge this"

No blaming, no tantrums, no judgemental comments from a single viewpoint.
A collection of good intentions produced a problem. It happens all the
time, screaming and blaming may be how politicians sometimes behave but we
can surely do better ?

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone.  And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.

Maybe the lesson to be learned from all this is, 'if the developers
don't want something merged because they're not ready and forsee huge
problems in the future, actually listen to them instead of blindly
ramming it in regardless'? But maybe that's just me.

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] drm request 3

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 557 bytes --]

On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
> If it effects such a large number of people, which this noveau thing
> does, it's entirely relevant to everyone.  And the way it's breaking
> and making kernel development difficult for so many people matters to
> us.

Maybe the lesson to be learned from all this is, 'if the developers
don't want something merged because they're not ready and forsee huge
problems in the future, actually listen to them instead of blindly
ramming it in regardless'? But maybe that's just me.

Cheers,
Daniel

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 17:17:54 +0200

> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>> If it effects such a large number of people, which this noveau thing
>> does, it's entirely relevant to everyone.  And the way it's breaking
>> and making kernel development difficult for so many people matters to
>> us.
> 
> Maybe the lesson to be learned from all this is, 'if the developers
> don't want something merged because they're not ready and forsee huge
> problems in the future, actually listen to them instead of blindly
> ramming it in regardless'? But maybe that's just me.

That's doesn't work, and it never will.

First of all, if we didn't merge the driver Fedora users wouldn't be
able to test the upstream kernel at all.

And if you think things through, there is one and onle one set of
actions that would have made things work properly.

And that's merge the driver upstream and not break user visible APIs.

In fact, I argue that the moment nouveau went into Fedora and
was turned on by default, the interfaces needed to be frozen.

Consider if it didn't go upstream and I want to do upstream
kernel development, ok so I patch the noveau-of-the-moment into
my upstream tree.

Six months and 10 DRM library updates later I go back and try to boot
that kernel.  And it's not going to work.

So if the user visible APIs are changed in any set of situations
(upstream merged, not upstream merged, etc.) things can end up
breaking.

Ergo, you simply can't sanely do it at all.  You have to have
a compatability story when you change these things.

Personally I wouldn't have ever committed to that "user visible APIs
can break cause it's in -stable."  Because that's complete garbage.


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 17:17:54 +0200

> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>> If it effects such a large number of people, which this noveau thing
>> does, it's entirely relevant to everyone.  And the way it's breaking
>> and making kernel development difficult for so many people matters to
>> us.
> 
> Maybe the lesson to be learned from all this is, 'if the developers
> don't want something merged because they're not ready and forsee huge
> problems in the future, actually listen to them instead of blindly
> ramming it in regardless'? But maybe that's just me.

That's doesn't work, and it never will.

First of all, if we didn't merge the driver Fedora users wouldn't be
able to test the upstream kernel at all.

And if you think things through, there is one and onle one set of
actions that would have made things work properly.

And that's merge the driver upstream and not break user visible APIs.

In fact, I argue that the moment nouveau went into Fedora and
was turned on by default, the interfaces needed to be frozen.

Consider if it didn't go upstream and I want to do upstream
kernel development, ok so I patch the noveau-of-the-moment into
my upstream tree.

Six months and 10 DRM library updates later I go back and try to boot
that kernel.  And it's not going to work.

So if the user visible APIs are changed in any set of situations
(upstream merged, not upstream merged, etc.) things can end up
breaking.

Ergo, you simply can't sanely do it at all.  You have to have
a compatability story when you change these things.

Personally I wouldn't have ever committed to that "user visible APIs
can break cause it's in -stable."  Because that's complete garbage.

Re: [git pull] drm request 3

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 3233 bytes --]

Hi,

On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
> >> If it effects such a large number of people, which this noveau thing
> >> does, it's entirely relevant to everyone.  And the way it's breaking
> >> and making kernel development difficult for so many people matters to
> >> us.
> > 
> > Maybe the lesson to be learned from all this is, 'if the developers
> > don't want something merged because they're not ready and forsee huge
> > problems in the future, actually listen to them instead of blindly
> > ramming it in regardless'? But maybe that's just me.
> 
> That's doesn't work, and it never will.
> 
> First of all, if we didn't merge the driver Fedora users wouldn't be
> able to test the upstream kernel at all.
> 
> And if you think things through, there is one and onle one set of
> actions that would have made things work properly.
> 
> And that's merge the driver upstream and not break user visible APIs.

Ah, argument by assertion.  That's my most favourite thing to deal with
on a Friday evening.

Wait, did I say 'most'? I meant least.

> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

That's a matter for the Fedora kernel team; for better or worse, they
made the choices they did, which included going through all the relevant
pain to support this.  They didn't consider it suitable for upstream
because they didn't think everyone else should be forced to endure that
pain.

Now it's upstream and everyone's being forced to deal with it.  Great.

> Consider if it didn't go upstream and I want to do upstream
> kernel development, ok so I patch the noveau-of-the-moment into
> my upstream tree.
> 
> Six months and 10 DRM library updates later I go back and try to boot
> that kernel.  And it's not going to work.

nouveau isn't going to work, no.  vesa and nv remain unaffected; it's
not like it's some kind of catastrophic failure whereby booting it eats
your disk and gropes your sister-in-law.

> So if the user visible APIs are changed in any set of situations
> (upstream merged, not upstream merged, etc.) things can end up
> breaking.

Correct!

> Ergo, you simply can't sanely do it at all.  You have to have
> a compatability story when you change these things.

You cannot sanely do it at all in an upstream kernel, no.

> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable."  Because that's complete garbage.

I guess you mean staging here; either way, that's a matter for you guys
to deal with.  I guess the upshot here is 'if you merge something
against the developers' wishes by screaming at them until they comply,
they repeatedly tell you that it's not API-stable, you merge it, and it
changes API, then joke's on you'.  If the result of this ridiculous mess
is that anything merged to staging is never allowed to change userspace
ABI ever, then great.  As I said, it's really not my problem.

Either way, fuck it, it's Friday.  To the pub.

Cheers,
Daniel

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

Hi,

On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
> >> If it effects such a large number of people, which this noveau thing
> >> does, it's entirely relevant to everyone.  And the way it's breaking
> >> and making kernel development difficult for so many people matters to
> >> us.
> > 
> > Maybe the lesson to be learned from all this is, 'if the developers
> > don't want something merged because they're not ready and forsee huge
> > problems in the future, actually listen to them instead of blindly
> > ramming it in regardless'? But maybe that's just me.
> 
> That's doesn't work, and it never will.
> 
> First of all, if we didn't merge the driver Fedora users wouldn't be
> able to test the upstream kernel at all.
> 
> And if you think things through, there is one and onle one set of
> actions that would have made things work properly.
> 
> And that's merge the driver upstream and not break user visible APIs.

Ah, argument by assertion.  That's my most favourite thing to deal with
on a Friday evening.

Wait, did I say 'most'? I meant least.

> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

That's a matter for the Fedora kernel team; for better or worse, they
made the choices they did, which included going through all the relevant
pain to support this.  They didn't consider it suitable for upstream
because they didn't think everyone else should be forced to endure that
pain.

Now it's upstream and everyone's being forced to deal with it.  Great.

> Consider if it didn't go upstream and I want to do upstream
> kernel development, ok so I patch the noveau-of-the-moment into
> my upstream tree.
> 
> Six months and 10 DRM library updates later I go back and try to boot
> that kernel.  And it's not going to work.

nouveau isn't going to work, no.  vesa and nv remain unaffected; it's
not like it's some kind of catastrophic failure whereby booting it eats
your disk and gropes your sister-in-law.

> So if the user visible APIs are changed in any set of situations
> (upstream merged, not upstream merged, etc.) things can end up
> breaking.

Correct!

> Ergo, you simply can't sanely do it at all.  You have to have
> a compatability story when you change these things.

You cannot sanely do it at all in an upstream kernel, no.

> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable."  Because that's complete garbage.

I guess you mean staging here; either way, that's a matter for you guys
to deal with.  I guess the upshot here is 'if you merge something
against the developers' wishes by screaming at them until they comply,
they repeatedly tell you that it's not API-stable, you merge it, and it
changes API, then joke's on you'.  If the result of this ridiculous mess
is that anything merged to staging is never allowed to change userspace
ABI ever, then great.  As I said, it's really not my problem.

Either way, fuck it, it's Friday.  To the pub.

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] drm request 3

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 17:40:09 +0200

> On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
>> In fact, I argue that the moment nouveau went into Fedora and
>> was turned on by default, the interfaces needed to be frozen.
> 
> That's a matter for the Fedora kernel team; for better or worse, they
> made the choices they did, which included going through all the relevant
> pain to support this.  They didn't consider it suitable for upstream
> because they didn't think everyone else should be forced to endure that
> pain.

By not merging it upstream the pain is larger not smaller.

It's enabled by default, so you therefore can't test upstream kernels
by default.

And as I showed already, even if you jump through the hoops to make it
work (building noveau from out of tree in the upstream kernel) you'll
end up getting screwed when the API changes anyways.

Using VESA or whatever else you've suggested is just not a reasonable
alternative.

You can't unleash something like this on a userbase of this magnitude
and then throw your hands up in the air and say "I'm not willing to
support this in a reasonable way."

We're better than that.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 17:40:09 +0200

> On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
>> In fact, I argue that the moment nouveau went into Fedora and
>> was turned on by default, the interfaces needed to be frozen.
> 
> That's a matter for the Fedora kernel team; for better or worse, they
> made the choices they did, which included going through all the relevant
> pain to support this.  They didn't consider it suitable for upstream
> because they didn't think everyone else should be forced to endure that
> pain.

By not merging it upstream the pain is larger not smaller.

It's enabled by default, so you therefore can't test upstream kernels
by default.

And as I showed already, even if you jump through the hoops to make it
work (building noveau from out of tree in the upstream kernel) you'll
end up getting screwed when the API changes anyways.

Using VESA or whatever else you've suggested is just not a reasonable
alternative.

You can't unleash something like this on a userbase of this magnitude
and then throw your hands up in the air and say "I'm not willing to
support this in a reasonable way."

We're better than that.

Re: [git pull] drm request 3

[Alan Cox]

> You can't unleash something like this on a userbase of this magnitude
> and then throw your hands up in the air and say "I'm not willing to
> support this in a reasonable way."

Not to belabour the obvious - they didn't. Linus ordered them to merge it.

> We're better than that.

If you consider the problem is with the Fedora kernel team decision to
merge it into Fedora in the first place, perhaps you should have an
internal Red Hat discussion about it with the people who made that
decision - who I suspect see it differently. Either way the Nouveau
developers don't control Fedora packaging policy, in fact the GPL licence
specially ensures the control is not theirs.

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> You can't unleash something like this on a userbase of this magnitude
> and then throw your hands up in the air and say "I'm not willing to
> support this in a reasonable way."

Not to belabour the obvious - they didn't. Linus ordered them to merge it.

> We're better than that.

If you consider the problem is with the Fedora kernel team decision to
merge it into Fedora in the first place, perhaps you should have an
internal Red Hat discussion about it with the people who made that
decision - who I suspect see it differently. Either way the Nouveau
developers don't control Fedora packaging policy, in fact the GPL licence
specially ensures the control is not theirs.

Alan

Re: [git pull] drm request 3

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 16:02:17 +0000

>> You can't unleash something like this on a userbase of this magnitude
>> and then throw your hands up in the air and say "I'm not willing to
>> support this in a reasonable way."
> 
> Not to belabour the obvious - they didn't. Linus ordered them to merge it.

And I'm arguing not merging it upstream would be like saying
the same thing.

>> We're better than that.
> 
> If you consider the problem is with the Fedora kernel team decision to
> merge it into Fedora in the first place

For the second time Alan, I don't.

I think Fedora should have merged it.

I think it should be upstream.

And I think the API bustage needs to be avoided.


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 16:02:17 +0000

>> You can't unleash something like this on a userbase of this magnitude
>> and then throw your hands up in the air and say "I'm not willing to
>> support this in a reasonable way."
> 
> Not to belabour the obvious - they didn't. Linus ordered them to merge it.

And I'm arguing not merging it upstream would be like saying
the same thing.

>> We're better than that.
> 
> If you consider the problem is with the Fedora kernel team decision to
> merge it into Fedora in the first place

For the second time Alan, I don't.

I think Fedora should have merged it.

I think it should be upstream.

And I think the API bustage needs to be avoided.

Re: [git pull] drm request 3

[Younes Manton]

On Fri, Mar 5, 2010 at 11:05 AM, David Miller <davem@davemloft.net> wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Fri, 5 Mar 2010 16:02:17 +0000
>
>>> You can't unleash something like this on a userbase of this magnitude
>>> and then throw your hands up in the air and say "I'm not willing to
>>> support this in a reasonable way."
>>
>> Not to belabour the obvious - they didn't. Linus ordered them to merge it.
>
> And I'm arguing not merging it upstream would be like saying
> the same thing.
>

No, it's not like saying the same thing. Not merging it upstream is
saying "we're not willing to support this in a reasonable way *at this
time*."

Re: [git pull] drm request 3

[Younes Manton]

On Fri, Mar 5, 2010 at 11:05 AM, David Miller <davem@davemloft.net> wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Fri, 5 Mar 2010 16:02:17 +0000
>
>>> You can't unleash something like this on a userbase of this magnitude
>>> and then throw your hands up in the air and say "I'm not willing to
>>> support this in a reasonable way."
>>
>> Not to belabour the obvious - they didn't. Linus ordered them to merge it.
>
> And I'm arguing not merging it upstream would be like saying
> the same thing.
>

No, it's not like saying the same thing. Not merging it upstream is
saying "we're not willing to support this in a reasonable way *at this
time*."

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:

> > You can't unleash something like this on a userbase of this magnitude
> > and then throw your hands up in the air and say "I'm not willing to
> > support this in a reasonable way."
> 
> Not to belabour the obvious - they didn't. Linus ordered them to merge it.

Alan, you're ignoring reality.

This problem existed *before* nouveau was merged.

In fact, it was *worse* back then.

How hard is that to understand?

And yes, I do actually know. Because I used nouveau for a year before it 
was merged. You had to use a different version of drm too, so you couldn't 
even just compile the nouveau tree and install just the nouveau driver 
(and keep the other drivers from the main tree).

So the watershed moment was _never_ the "Linus merged it". The watershed 
moment was always "Fedora started shipping it". That's when the problems 
with a standard upstream kernel started.

Why is that so hard for people to understand?

			Linus

Re: [git pull] drm request 3

[Alan Cox]

> So the watershed moment was _never_ the "Linus merged it". The watershed 
> moment was always "Fedora started shipping it". That's when the problems 
> with a standard upstream kernel started.
> 
> Why is that so hard for people to understand?

So why are you screaming at the DRM and Nouveau people about the
breakage ? That's the bit I really don't understand.

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> So the watershed moment was _never_ the "Linus merged it". The watershed 
> moment was always "Fedora started shipping it". That's when the problems 
> with a standard upstream kernel started.
> 
> Why is that so hard for people to understand?

So why are you screaming at the DRM and Nouveau people about the
breakage ? That's the bit I really don't understand.

Alan

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:

> > So the watershed moment was _never_ the "Linus merged it". The watershed 
> > moment was always "Fedora started shipping it". That's when the problems 
> > with a standard upstream kernel started.
> > 
> > Why is that so hard for people to understand?
> 
> So why are you screaming at the DRM and Nouveau people about the
> breakage ? That's the bit I really don't understand.

Umm. You _really_ haven't been following, have you?

Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The 
guy who is, as far as I know, effectively in charge of that whole 
integration. Yeah, I realize that there are other people (Kyle?) involved, 
and maybe Dave isn't as central as I think he is, but I learnt from last 
time that the nouveau guys don't seem to care.

And I would like to say that yes, Dave really helped me. He got me a 
working setup again. I thank you, Dave. It means I don't have to revert 
the thing, and we can hopefully make progress.

That said, I do think that the Fedora people _should_ have been the ones 
to catch this as a problem, and pushed back a bit on the Nouveau people 
even before it got to me. For all the reasons I've mentioned.

Even if you need to change the interface, I've actually looked at the 
patch in question (have you, Alan?), and I got the very strong feeling 
that it _could_ have been done without breaking compatibility so 
completely and utterly, and making it so apparently intentionally hard to 
have a driver that can handle both the old and the new.

IOW, maybe it would have required a new nouveau_drv etc, but with a 
slightly less hack-and-slash approach, maybe the new one could have 
supported the old interfaces enough to at least limp along.

For example, breaking DRM so that 3D doesn't work, but you still get basic 
2D acceleration - that's _way_ more acceptable, and is likely to need a 
much smaller subset of the whole DRI functionality. It looks like nobody 
even tried.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:

> > So the watershed moment was _never_ the "Linus merged it". The watershed 
> > moment was always "Fedora started shipping it". That's when the problems 
> > with a standard upstream kernel started.
> > 
> > Why is that so hard for people to understand?
> 
> So why are you screaming at the DRM and Nouveau people about the
> breakage ? That's the bit I really don't understand.

Umm. You _really_ haven't been following, have you?

Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The 
guy who is, as far as I know, effectively in charge of that whole 
integration. Yeah, I realize that there are other people (Kyle?) involved, 
and maybe Dave isn't as central as I think he is, but I learnt from last 
time that the nouveau guys don't seem to care.

And I would like to say that yes, Dave really helped me. He got me a 
working setup again. I thank you, Dave. It means I don't have to revert 
the thing, and we can hopefully make progress.

That said, I do think that the Fedora people _should_ have been the ones 
to catch this as a problem, and pushed back a bit on the Nouveau people 
even before it got to me. For all the reasons I've mentioned.

Even if you need to change the interface, I've actually looked at the 
patch in question (have you, Alan?), and I got the very strong feeling 
that it _could_ have been done without breaking compatibility so 
completely and utterly, and making it so apparently intentionally hard to 
have a driver that can handle both the old and the new.

IOW, maybe it would have required a new nouveau_drv etc, but with a 
slightly less hack-and-slash approach, maybe the new one could have 
supported the old interfaces enough to at least limp along.

For example, breaking DRM so that 3D doesn't work, but you still get basic 
2D acceleration - that's _way_ more acceptable, and is likely to need a 
much smaller subset of the whole DRI functionality. It looks like nobody 
even tried.

			Linus

Re: [git pull] drm request 3

[Alan Cox]

> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The 
> guy who is, as far as I know, effectively in charge of that whole 
> integration. Yeah, I realize that there are other people (Kyle?) involved, 
> and maybe Dave isn't as central as I think he is, but I learnt from last 
> time that the nouveau guys don't seem to care.

Ok "screamed about" is perhaps better wording. Why should the Nouveau
guys care ? You've forced their hand, you've demanded stuff they
said they didn't want to do and then you've bitched about things they
said they would do. Actually I think they've been quite restrained. I'd
probably have proposed a licence change to make it only work on FreeBSD
and Solaris given that treatment ;)

> Even if you need to change the interface, I've actually looked at the 
> patch in question (have you, Alan?),

Yes but I read it somewhat differently.

Someone who never made a commitment to stability decided to do the
logical thing. They deleted all the old broken interfaces, they cleaned
up their ioctls numbering and they tided up afterwards. I read it as the
action of someone who simply doesnt acknowledge that you have a right to
control their development and is continuing to work in the way they
intended.

You can only see it as malicious if you assume they ever had some reason
to keep compatibility or had promised it somewhere. Quite the reverse
happened, and they never asked to be upstream in the first place.


	"But the fact is, at least from my standpoint, I'd really
	hope that anything I had written would be used in ways I asked
	people to"
				- Linus Torvalds, 2004

Re: [git pull] drm request 3

["C. Bergström"]

Alan Cox wrote:
>> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The 
>> guy who is, as far as I know, effectively in charge of that whole 
>> integration. Yeah, I realize that there are other people (Kyle?) involved, 
>> and maybe Dave isn't as central as I think he is, but I learnt from last 
>> time that the nouveau guys don't seem to care.
>>     
>
> Ok "screamed about" is perhaps better wording. Why should the Nouveau
> guys care ? You've forced their hand, you've demanded stuff they
> said they didn't want to do and then you've bitched about things they
> said they would do. Actually I think they've been quite restrained. I'd
> probably have proposed a licence change to make it only work on FreeBSD
> and Solaris given that treatment ;)
>   
Our OpenSolaris port isn't done yet.. ;)

Oh.. and I hope you won't mind if we break the API in doing so.. *cough*

/me hides

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[tytso]

On Fri, Mar 05, 2010 at 05:04:14PM +0000, Alan Cox wrote:
> You can only see it as malicious if you assume they ever had some reason
> to keep compatibility or had promised it somewhere. Quite the reverse
> happened, and they never asked to be upstream in the first place.

The reason why this thread is inspiring so much traffic is because
it's fundamentally about community norms.  There are plenty of things
that are not illegal, but which are at the same time anti-social.

For example, there are all sorts of rules, if you are a researcher,
about experimenting on human subjects.  Many of those restrictions
aren't codified in law, but if you violate them, other researches will
say that you are a bad person, a bad researcher, and refuse to
associate with you.  And you might well lose your funding in the
future --- but it's not illegal.

If we are only talking about obligations under the GPL, sure, no one
violated copyright licenses.  But what *did* happen is someone
basically said, "I want to experiment on a whole bunch of users, but I
don't want to spend the effort to do things in the right way.  I want
to take short cuts; I don't want to worry about the fact that it will
be impossible to test kernels without pulling Frankenstein
combinations of patches between Fedora 13 and Fedora 12."  It's much
like people who drill oil in the Artic Ocean, but use single-hulled
tankers and then leave so much toxic spillage in their wake, but then
say, "hey, the regulations said what we did was O.K. Go away; don't
bother us."


Distro's that want to have a good reputation need to have a higher
standard than, "hey, it's allowed by the GPL."  And maybe if we are
sinking to the point where people are going to use "stable means ABI
breakages are allowed", we need to change the rules, since people want
to quote rules as opposed to just being good community members.  If
you want lots of testers, then you need to be treat the testers, and
the other developers in our development community with respect.

I think the real problem was that Fedora and the Neauveu community are
acting incredibly selfishly.  They only care about their narrow point
of view, and don't care about the pain they are inflicting on the
kernel development process and other kernel developers.  This is
_legal_.  It is, however, anti-social.

       		   	     	     		- Ted

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[tytso]

On Fri, Mar 05, 2010 at 05:04:14PM +0000, Alan Cox wrote:
> You can only see it as malicious if you assume they ever had some reason
> to keep compatibility or had promised it somewhere. Quite the reverse
> happened, and they never asked to be upstream in the first place.

The reason why this thread is inspiring so much traffic is because
it's fundamentally about community norms.  There are plenty of things
that are not illegal, but which are at the same time anti-social.

For example, there are all sorts of rules, if you are a researcher,
about experimenting on human subjects.  Many of those restrictions
aren't codified in law, but if you violate them, other researches will
say that you are a bad person, a bad researcher, and refuse to
associate with you.  And you might well lose your funding in the
future --- but it's not illegal.

If we are only talking about obligations under the GPL, sure, no one
violated copyright licenses.  But what *did* happen is someone
basically said, "I want to experiment on a whole bunch of users, but I
don't want to spend the effort to do things in the right way.  I want
to take short cuts; I don't want to worry about the fact that it will
be impossible to test kernels without pulling Frankenstein
combinations of patches between Fedora 13 and Fedora 12."  It's much
like people who drill oil in the Artic Ocean, but use single-hulled
tankers and then leave so much toxic spillage in their wake, but then
say, "hey, the regulations said what we did was O.K. Go away; don't
bother us."


Distro's that want to have a good reputation need to have a higher
standard than, "hey, it's allowed by the GPL."  And maybe if we are
sinking to the point where people are going to use "stable means ABI
breakages are allowed", we need to change the rules, since people want
to quote rules as opposed to just being good community members.  If
you want lots of testers, then you need to be treat the testers, and
the other developers in our development community with respect.

I think the real problem was that Fedora and the Neauveu community are
acting incredibly selfishly.  They only care about their narrow point
of view, and don't care about the pain they are inflicting on the
kernel development process and other kernel developers.  This is
_legal_.  It is, however, anti-social.

       		   	     	     		- Ted

Re: [git pull] drm request 3

[Garry Hurley]

[-- Attachment #1.1: Type: text/plain, Size: 939 bytes --]

>
> Distro's that want to have a good reputation need to have a higher
> standard than, "hey, it's allowed by the GPL."  And maybe if we are
> sinking to the point where people are going to use "stable means ABI
> breakages are allowed", we need to change the rules, since people want
> to quote rules as opposed to just being good community members.  If
> you want lots of testers, then you need to be treat the testers, and
> the other developers in our development community with respect.
>
> I think the real problem was that Fedora and the Neauveu community are
> acting incredibly selfishly.  They only care about their narrow point
> of view, and don't care about the pain they are inflicting on the
> kernel development process and other kernel developers.  This is
> _legal_.  It is, however, anti-social.
>
>                                                - Ted
>
> And people wonder why I stubbornly stick with Slackware Linux.

[-- Attachment #1.2: Type: text/html, Size: 1229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Alan Cox]

> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The 
> guy who is, as far as I know, effectively in charge of that whole 
> integration. Yeah, I realize that there are other people (Kyle?) involved, 
> and maybe Dave isn't as central as I think he is, but I learnt from last 
> time that the nouveau guys don't seem to care.

Ok "screamed about" is perhaps better wording. Why should the Nouveau
guys care ? You've forced their hand, you've demanded stuff they
said they didn't want to do and then you've bitched about things they
said they would do. Actually I think they've been quite restrained. I'd
probably have proposed a licence change to make it only work on FreeBSD
and Solaris given that treatment ;)

> Even if you need to change the interface, I've actually looked at the 
> patch in question (have you, Alan?),

Yes but I read it somewhat differently.

Someone who never made a commitment to stability decided to do the
logical thing. They deleted all the old broken interfaces, they cleaned
up their ioctls numbering and they tided up afterwards. I read it as the
action of someone who simply doesnt acknowledge that you have a right to
control their development and is continuing to work in the way they
intended.

You can only see it as malicious if you assume they ever had some reason
to keep compatibility or had promised it somewhere. Quite the reverse
happened, and they never asked to be upstream in the first place.


	"But the fact is, at least from my standpoint, I'd really
	hope that anything I had written would be used in ways I asked
	people to"
				- Linus Torvalds, 2004




------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:

> > You can't unleash something like this on a userbase of this magnitude
> > and then throw your hands up in the air and say "I'm not willing to
> > support this in a reasonable way."
> 
> Not to belabour the obvious - they didn't. Linus ordered them to merge it.

Alan, you're ignoring reality.

This problem existed *before* nouveau was merged.

In fact, it was *worse* back then.

How hard is that to understand?

And yes, I do actually know. Because I used nouveau for a year before it 
was merged. You had to use a different version of drm too, so you couldn't 
even just compile the nouveau tree and install just the nouveau driver 
(and keep the other drivers from the main tree).

So the watershed moment was _never_ the "Linus merged it". The watershed 
moment was always "Fedora started shipping it". That's when the problems 
with a standard upstream kernel started.

Why is that so hard for people to understand?

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Fri, Mar 05, 2010 at 07:48:35AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> > On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> >> In fact, I argue that the moment nouveau went into Fedora and
> >> was turned on by default, the interfaces needed to be frozen.
> > 
> > That's a matter for the Fedora kernel team; for better or worse, they
> > made the choices they did, which included going through all the relevant
> > pain to support this.  They didn't consider it suitable for upstream
> > because they didn't think everyone else should be forced to endure that
> > pain.
> 
> By not merging it upstream the pain is larger not smaller.
> 
> It's enabled by default, so you therefore can't test upstream kernels
> by default.

'That's a matter for the Fedora kernel team'.

> And as I showed already, even if you jump through the hoops to make it
> work (building noveau from out of tree in the upstream kernel) you'll
> end up getting screwed when the API changes anyways.

So you're saying that there's no way to develop any reasonable body of
code for the Linux kernel without committing to keeping your ABI
absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
that worked really well for Xlib.

> Using VESA or whatever else you've suggested is just not a reasonable
> alternative.
> 
> You can't unleash something like this on a userbase of this magnitude
> and then throw your hands up in the air and say "I'm not willing to
> support this in a reasonable way."
> 
> We're better than that.

Your opinion on what constitutes reasonable support is not universal,
absolute truth.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] drm request 3

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 18:04:34 +0200

> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

read() still works the same way it did 30 years ago last time I
checked.

Re: [git pull] drm request 3

[Alan Cox]

On Fri, 05 Mar 2010 08:06:26 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Daniel Stone <daniel@fooishbar.org>
> Date: Fri, 5 Mar 2010 18:04:34 +0200
> 
> > So you're saying that there's no way to develop any reasonable body of
> > code for the Linux kernel without committing to keeping your ABI
> > absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> > that worked really well for Xlib.
> 
> read() still works the same way it did 30 years ago last time I
> checked.

Thats disingenous as read() is a method not an interface. It's also wrong
because read() and write() behaviour has changed in various ways and old
code broke because of it in subtle ways. Keeping the same method behaviour
would have required things like new versions of read() for 64bit files,
nonblocking, mandlocks, NFS, networking, etc all of which changed the
core read() behaviour. I've yet to see anyone meaningfully argue it was
the wrong thing to do.

Alan

Re: [git pull] drm request 3

[Jerome Glisse]

On Fri, Mar 05, 2010 at 04:31:29PM +0000, Alan Cox wrote:
> On Fri, 05 Mar 2010 08:06:26 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Daniel Stone <daniel@fooishbar.org>
> > Date: Fri, 5 Mar 2010 18:04:34 +0200
> > 
> > > So you're saying that there's no way to develop any reasonable body of
> > > code for the Linux kernel without committing to keeping your ABI
> > > absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> > > that worked really well for Xlib.
> > 
> > read() still works the same way it did 30 years ago last time I
> > checked.
> 
> Thats disingenous as read() is a method not an interface. It's also wrong
> because read() and write() behaviour has changed in various ways and old
> code broke because of it in subtle ways. Keeping the same method behaviour
> would have required things like new versions of read() for 64bit files,
> nonblocking, mandlocks, NFS, networking, etc all of which changed the
> core read() behaviour. I've yet to see anyone meaningfully argue it was
> the wrong thing to do.
> 
> Alan
> 

Also GPU API is way more complex than any others kernel API
(at least to my knowledge) and you can't know if the API you
have is the good one until you have a fully working & fast
3D driver ... and that takes either a lot of time with
a lot of people.

Cheers,
Jerome

Re: [git pull] drm request 3

[Jerome Glisse]

On Fri, Mar 05, 2010 at 04:31:29PM +0000, Alan Cox wrote:
> On Fri, 05 Mar 2010 08:06:26 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Daniel Stone <daniel@fooishbar.org>
> > Date: Fri, 5 Mar 2010 18:04:34 +0200
> > 
> > > So you're saying that there's no way to develop any reasonable body of
> > > code for the Linux kernel without committing to keeping your ABI
> > > absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> > > that worked really well for Xlib.
> > 
> > read() still works the same way it did 30 years ago last time I
> > checked.
> 
> Thats disingenous as read() is a method not an interface. It's also wrong
> because read() and write() behaviour has changed in various ways and old
> code broke because of it in subtle ways. Keeping the same method behaviour
> would have required things like new versions of read() for 64bit files,
> nonblocking, mandlocks, NFS, networking, etc all of which changed the
> core read() behaviour. I've yet to see anyone meaningfully argue it was
> the wrong thing to do.
> 
> Alan
> 

Also GPU API is way more complex than any others kernel API
(at least to my knowledge) and you can't know if the API you
have is the good one until you have a fully working & fast
3D driver ... and that takes either a lot of time with
a lot of people.

Cheers,
Jerome

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

On Fri, 05 Mar 2010 08:06:26 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Daniel Stone <daniel@fooishbar.org>
> Date: Fri, 5 Mar 2010 18:04:34 +0200
> 
> > So you're saying that there's no way to develop any reasonable body of
> > code for the Linux kernel without committing to keeping your ABI
> > absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> > that worked really well for Xlib.
> 
> read() still works the same way it did 30 years ago last time I
> checked.

Thats disingenous as read() is a method not an interface. It's also wrong
because read() and write() behaviour has changed in various ways and old
code broke because of it in subtle ways. Keeping the same method behaviour
would have required things like new versions of read() for 64bit files,
nonblocking, mandlocks, NFS, networking, etc all of which changed the
core read() behaviour. I've yet to see anyone meaningfully argue it was
the wrong thing to do.

Alan



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[David Miller]

From: Daniel Stone <daniel@fooishbar.org>
Date: Fri, 5 Mar 2010 18:04:34 +0200

> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

read() still works the same way it did 30 years ago last time I
checked.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[tytso]

On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote:
> 
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

No, that's not what people are saying.  What people are saying is,
"avoid flag days".  Deprecate things over a 6-12 month time period.
We have lots of really good interfaces for doing that.

You say you don't want to do that?  Then keep it to your self and
don't get it dropped into popular distributions like Fedora or Ubuntu.
You want a larger pool of testers?  Great!  The price you need to pay
for that is to be able to do some kind of of ABI versioning so that
you don't have "drop dead flag days".

If you don't want to be a good citizen, then prepared to have people
call you out for, well, not being a good OSS citizen.

     	     	  	    	    	 - Ted

Re: [git pull] drm request 3

[Corbin Simpson]

On Fri, Mar 5, 2010 at 8:46 AM,  <tytso@mit.edu> wrote:
> On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote:
>>
>> So you're saying that there's no way to develop any reasonable body of
>> code for the Linux kernel without committing to keeping your ABI
>> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
>> that worked really well for Xlib.
>
> No, that's not what people are saying.  What people are saying is,
> "avoid flag days".  Deprecate things over a 6-12 month time period.
> We have lots of really good interfaces for doing that.
>
> You say you don't want to do that?  Then keep it to your self and
> don't get it dropped into popular distributions like Fedora or Ubuntu.
> You want a larger pool of testers?  Great!  The price you need to pay
> for that is to be able to do some kind of of ABI versioning so that
> you don't have "drop dead flag days".
>
> If you don't want to be a good citizen, then prepared to have people
> call you out for, well, not being a good OSS citizen.

I was trying my hardest to not say anything, but...

Nouveau isn't an official Xorg project. It hasn't been added to the
jhbuild list for auto-checkout, it doesn't get tinderbox time
(admittedly a function of being part of the jhbuild) and I don't think
it's on the katamari list, so it's never been shipped as part of an
Xorg release. It is only in mainline under the staging rules; drivers
come and go from staging under fairly lax rules.

Fedora ships this stuff because they're actively developing it and
enjoy deploying half-broken things to users in the vain hope that it
magically won't break. I can't count the number of kittens eaten by
Fedora systems I've used. (It is kind of sad that Fedora's still the
best distro about not deploying broken stuff but still remaining
up-to-date.) Tellingly, it doesn't look like this interface change has
been deployed to stable Fedora, just Rawhide.

The Ubuntu people don't talk to us as much as they should. Seeing how
badly they biffed Radeon and Intel KMS deployment, it's hard for me to
believe that deploying Nouveau went smoothly. I don't have much more
personal experience; my work computer has an HD 3450 in it now instead
of the old GeForce, and that's my only Ubuntu box.

If distros want to run weird experiments on their users, let them!
Sure, sometimes bad things happen, but sometimes good things happen
too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
Plymouth, the list goes on and on.

If the problem here is actually that a distro is deploying a staging
driver and picking up the pieces themselves, then just say it. This
whole thing with flag days, deprecation, interface changes, etc.
hinges on the idea that the code being deprecated was stable, usable,
and widely deployed, but it wasn't and isn't.

That said... Code probably is moving too fast inside nouveau. There is
a bit of a wall to go through to get new patches upstream, which one
would hope would inspire some developer restraint. intel and radeon
both still have most (if not all) of the legacy code needed by ancient
userspaces, and both DDX drivers are doing multiple-branch releases to
keep old userspace interfaces alive for people unable to update their
kernels. It might be useful for the nouveau guys to really seriously
consider code before it leaves their trees and enters mainline;
writing code that you won't commit to is quite lame for the obvious
reasons, but also for some unobvious reasons, e.g. it makes you look
like you don't actually know what you're doing and would rather just
keep reinventing wheels without justifying and testing your design
choices. (This is also why I was not exactly pleased with the
suggestion of retooling all of the r600 userspace over a change to the
CS system; we just spent the better part of a year moving everything
over to CS!)

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<MostAwesomeDude@gmail.com>

Re: [git pull] drm request 3

[Corbin Simpson]

On Fri, Mar 5, 2010 at 8:46 AM,  <tytso@mit.edu> wrote:
> On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote:
>>
>> So you're saying that there's no way to develop any reasonable body of
>> code for the Linux kernel without committing to keeping your ABI
>> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
>> that worked really well for Xlib.
>
> No, that's not what people are saying.  What people are saying is,
> "avoid flag days".  Deprecate things over a 6-12 month time period.
> We have lots of really good interfaces for doing that.
>
> You say you don't want to do that?  Then keep it to your self and
> don't get it dropped into popular distributions like Fedora or Ubuntu.
> You want a larger pool of testers?  Great!  The price you need to pay
> for that is to be able to do some kind of of ABI versioning so that
> you don't have "drop dead flag days".
>
> If you don't want to be a good citizen, then prepared to have people
> call you out for, well, not being a good OSS citizen.

I was trying my hardest to not say anything, but...

Nouveau isn't an official Xorg project. It hasn't been added to the
jhbuild list for auto-checkout, it doesn't get tinderbox time
(admittedly a function of being part of the jhbuild) and I don't think
it's on the katamari list, so it's never been shipped as part of an
Xorg release. It is only in mainline under the staging rules; drivers
come and go from staging under fairly lax rules.

Fedora ships this stuff because they're actively developing it and
enjoy deploying half-broken things to users in the vain hope that it
magically won't break. I can't count the number of kittens eaten by
Fedora systems I've used. (It is kind of sad that Fedora's still the
best distro about not deploying broken stuff but still remaining
up-to-date.) Tellingly, it doesn't look like this interface change has
been deployed to stable Fedora, just Rawhide.

The Ubuntu people don't talk to us as much as they should. Seeing how
badly they biffed Radeon and Intel KMS deployment, it's hard for me to
believe that deploying Nouveau went smoothly. I don't have much more
personal experience; my work computer has an HD 3450 in it now instead
of the old GeForce, and that's my only Ubuntu box.

If distros want to run weird experiments on their users, let them!
Sure, sometimes bad things happen, but sometimes good things happen
too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
Plymouth, the list goes on and on.

If the problem here is actually that a distro is deploying a staging
driver and picking up the pieces themselves, then just say it. This
whole thing with flag days, deprecation, interface changes, etc.
hinges on the idea that the code being deprecated was stable, usable,
and widely deployed, but it wasn't and isn't.

That said... Code probably is moving too fast inside nouveau. There is
a bit of a wall to go through to get new patches upstream, which one
would hope would inspire some developer restraint. intel and radeon
both still have most (if not all) of the legacy code needed by ancient
userspaces, and both DDX drivers are doing multiple-branch releases to
keep old userspace interfaces alive for people unable to update their
kernels. It might be useful for the nouveau guys to really seriously
consider code before it leaves their trees and enters mainline;
writing code that you won't commit to is quite lame for the obvious
reasons, but also for some unobvious reasons, e.g. it makes you look
like you don't actually know what you're doing and would rather just
keep reinventing wheels without justifying and testing your design
choices. (This is also why I was not exactly pleased with the
suggestion of retooling all of the r600 userspace over a change to the
CS system; we just spent the better part of a year moving everything
over to CS!)

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<MostAwesomeDude@gmail.com>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Corbin Simpson]

On Fri, Mar 5, 2010 at 11:38 AM, Corbin Simpson
<mostawesomedude@gmail.com> wrote:
> I was trying my hardest to not say anything, but...
>
> [blah blah Fedora blah Ubuntu blah staging blah blah]
>
> That said... Code probably is moving too fast inside nouveau. There is
> a bit of a wall to go through to get new patches upstream, which one
> would hope would inspire some developer restraint. intel and radeon
> both still have most (if not all) of the legacy code needed by ancient
> userspaces, and both DDX drivers are doing multiple-branch releases to
> keep old userspace interfaces alive for people unable to update their
> kernels. It might be useful for the nouveau guys to really seriously
> consider code before it leaves their trees and enters mainline;
> writing code that you won't commit to is quite lame for the obvious
> reasons, but also for some unobvious reasons, e.g. it makes you look
> like you don't actually know what you're doing and would rather just
> keep reinventing wheels without justifying and testing your design
> choices. (This is also why I was not exactly pleased with the
> suggestion of retooling all of the r600 userspace over a change to the
> CS system; we just spent the better part of a year moving everything
> over to CS!)

Strike this paragraph. After talking with the nouveau guys again, I
don't think they were doing anything out of the ordinary for staging
drivers. Frustrating, sure, but not anything worth a 200-post flame
war.

Also, I am a tool, don't know what I'm talking about, not actually a
nouveau dev, etc.

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<MostAwesomeDude@gmail.com>

Re: [git pull] drm request 3

[Corbin Simpson]

On Fri, Mar 5, 2010 at 11:38 AM, Corbin Simpson
<mostawesomedude@gmail.com> wrote:
> I was trying my hardest to not say anything, but...
>
> [blah blah Fedora blah Ubuntu blah staging blah blah]
>
> That said... Code probably is moving too fast inside nouveau. There is
> a bit of a wall to go through to get new patches upstream, which one
> would hope would inspire some developer restraint. intel and radeon
> both still have most (if not all) of the legacy code needed by ancient
> userspaces, and both DDX drivers are doing multiple-branch releases to
> keep old userspace interfaces alive for people unable to update their
> kernels. It might be useful for the nouveau guys to really seriously
> consider code before it leaves their trees and enters mainline;
> writing code that you won't commit to is quite lame for the obvious
> reasons, but also for some unobvious reasons, e.g. it makes you look
> like you don't actually know what you're doing and would rather just
> keep reinventing wheels without justifying and testing your design
> choices. (This is also why I was not exactly pleased with the
> suggestion of retooling all of the r600 userspace over a change to the
> CS system; we just spent the better part of a year moving everything
> over to CS!)

Strike this paragraph. After talking with the nouveau guys again, I
don't think they were doing anything out of the ordinary for staging
drivers. Frustrating, sure, but not anything worth a 200-post flame
war.

Also, I am a tool, don't know what I'm talking about, not actually a
nouveau dev, etc.

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<MostAwesomeDude@gmail.com>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[tytso]

On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote:
> If distros want to run weird experiments on their users, let them!
> Sure, sometimes bad things happen, but sometimes good things happen
> too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
> Plymouth, the list goes on and on.

So what distro would you recommend for people who want to do kernel
development, do kernel testing, and do kernel bisects to help us find
bugs?

Are you basically saying, "Kernel people shouldn't use Fedora"?  So
what should we use instead?

						- Ted

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[tytso]

On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote:
> If distros want to run weird experiments on their users, let them!
> Sure, sometimes bad things happen, but sometimes good things happen
> too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
> Plymouth, the list goes on and on.

So what distro would you recommend for people who want to do kernel
development, do kernel testing, and do kernel bisects to help us find
bugs?

Are you basically saying, "Kernel people shouldn't use Fedora"?  So
what should we use instead?

						- Ted

Re: [git pull] drm request 3

[Corbin Simpson]

[-- Attachment #1.1: Type: text/plain, Size: 1091 bytes --]

Strawman, mostly because all distros suck, the less patches you apply the
less likely things are to work, LFS is the most fragile thing out there,
etc. Hurp derp.

If you need a feature not in the distro, and it is needed because you have
installed something not in the distro or not new enough, you will have to go
get it yourself. If you want a bleeding X, you should be prepared to build
bleeding DDX and Mesa. If you want a new kernel FS, you probably need a
newer e2fsprogs or xfsprogs. If you want new kernel DRM, you will need a new
libdrm.

That process is relatively distro-agnostic.

Posting from a mobile, pardon my terseness. ~ C.

On Mar 5, 2010 1:51 PM, <tytso@mit.edu> wrote:

On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote:
> If distros want to run weird exper...
So what distro would you recommend for people who want to do kernel
development, do kernel testing, and do kernel bisects to help us find
bugs?

Are you basically saying, "Kernel people shouldn't use Fedora"?  So
what should we use instead?

                                               - Ted

[-- Attachment #1.2: Type: text/html, Size: 1313 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2010-03-05 22:51 schrieb tytso@mit.edu:
> On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote:
>> If distros want to run weird experiments on their users, let them!
>> Sure, sometimes bad things happen, but sometimes good things happen
>> too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
>> Plymouth, the list goes on and on.
> 
> So what distro would you recommend for people who want to do kernel
> development, do kernel testing, and do kernel bisects to help us find
> bugs?
> 
> Are you basically saying, "Kernel people shouldn't use Fedora"?  So
> what should we use instead?

It's been "Kernel people shouldn't use Nvidia" ever since I started
tinkering with device drivers for Linux. Of course there's hope that
nouveau will one day change that, but we're obviously not quite there yet.

Jm2c
Tilman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuRmMIACgkQQ3+did9BuFvPcgCfesxRGK/XabLxAEY143aDYwdN
Z7EAnjAbZKyUutNfzl9enda05vJLSRDV
=e26J
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2010-03-05 22:51 schrieb tytso@mit.edu:
> On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote:
>> If distros want to run weird experiments on their users, let them!
>> Sure, sometimes bad things happen, but sometimes good things happen
>> too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut,
>> Plymouth, the list goes on and on.
> 
> So what distro would you recommend for people who want to do kernel
> development, do kernel testing, and do kernel bisects to help us find
> bugs?
> 
> Are you basically saying, "Kernel people shouldn't use Fedora"?  So
> what should we use instead?

It's been "Kernel people shouldn't use Nvidia" ever since I started
tinkering with device drivers for Linux. Of course there's hope that
nouveau will one day change that, but we're obviously not quite there yet.

Jm2c
Tilman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuRmMIACgkQQ3+did9BuFvPcgCfesxRGK/XabLxAEY143aDYwdN
Z7EAnjAbZKyUutNfzl9enda05vJLSRDV
=e26J
-----END PGP SIGNATURE-----

Re: [git pull] drm request 3

[tytso]

On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote:
> 
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

No, that's not what people are saying.  What people are saying is,
"avoid flag days".  Deprecate things over a 6-12 month time period.
We have lots of really good interfaces for doing that.

You say you don't want to do that?  Then keep it to your self and
don't get it dropped into popular distributions like Fedora or Ubuntu.
You want a larger pool of testers?  Great!  The price you need to pay
for that is to be able to do some kind of of ABI versioning so that
you don't have "drop dead flag days".

If you don't want to be a good citizen, then prepared to have people
call you out for, well, not being a good OSS citizen.

     	     	  	    	    	 - Ted

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Daniel Stone wrote:
> 
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever?

I think that's what David ended up saying, but I think he is being _too_ 
strict.

It's not how we've done other things either. We've changed ABI's over time 
many times. And we've even had complete breakage of old tools (although 
that is very much reserved for system tools, not regular applications: I 
think we've been almost religious about "normal" apps not breaking, 
unless there was some really overriding reason like security that forced 
us to really remove some interface).

But most of the changes have been extending things, leaving the old 
interfaces around (often as wrappers around the new internal world order, 
sometimes by effectively having actual duplicated code).

And then the old interface is maintained for quite a while (sometimes 
decades, often years, and generally at least for several kernel versions 
so that people have time to upgrade, and a distro can generally pick a 
newer kernel without having to change anything else).

Sometimes we've done things that really end up requiring new tools. It's 
pretty rare, but it does happen. It happens a lot more for "esoteric" 
things that aren't every-day-in-your-face (I've seen at least _one_ mutter 
about "sysfs" in this thread ;) and might break something like a 
temperature sensor, for example.

So the machine might _work_ and you could go for days without even 
noticing, but you might have some very specific functionality missing. 
Maybe your power meter doesn't work, or maybe you need to upgrade your 
kernel profiler to get good profiles again. Things like that.

I suspect you as an X person know this very well, in fact. X itself has 
carried along a _lot_ of cruft exactly like this, that you guys have been 
removing only in the last few years - sometimes after decades of it being 
there. The whole switch to modern font handling is an obvious example of a 
_major_ fundamental feature change like that.

So in general, what the kernel strives for is that very kind of "the old 
model will still work - but it might be slow and emulated on top of a new 
way of dong things, and not get a lot of attention any more".

And sometimes, there's really no good way of maintaining two interfaces at 
the kernel level, and then you have the downstream tools that have to 
learn to pick either the old or the new one, so that the tool still works 
regardless.

And again, the old code _eventually_ bitrots or gets cleaned up, but what 
you really really want to avoid is to have a flag-day when you switch from 
one to the other, and you can't switch between adjacent versions of the 
kernel. 

In the 2.4.x/2.6.x split, for example, we did have system tools that 
needed to be upgraded if you came from a 2.4.x environment. You can still 
see signs of that in the kernel tree: we have that whole 
Documentation/Changes file that _still_ remains in our tree, even though 
it's purely historical.

But if you look at that Documentation/Changes file, I don't think there is 
_any_ flag-day issue except for the removal of "devfs". People _still_ 
talk about devfs in hushed tones. Everything else is about having to 
upgrade system tools _before_ upgrading the kernel (iow, they still worked 
on 2.4.x, but you needed recent enough versions of them to compile and run 
a 2.6.x kernel).

In other words, it wasn't a "flag day" (apart from the already mentioned 
devfs users, and possibly something else I can't think of). It was an 
upgrade, yes, and it required some other things to be recent, but you 
could go back-and-forth between kernels if you had to.

(Of course, it's now many years since that, so maybe my rose-colored 
glasses makes me forget the pain involved. And I obviously personally 
never made the whole 2.4.x -> 2.6.x jump, since I'd been running the 
development kernels in between. So maybe I forgot some painful part).

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Daniel Stone wrote:
> 
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever?

I think that's what David ended up saying, but I think he is being _too_ 
strict.

It's not how we've done other things either. We've changed ABI's over time 
many times. And we've even had complete breakage of old tools (although 
that is very much reserved for system tools, not regular applications: I 
think we've been almost religious about "normal" apps not breaking, 
unless there was some really overriding reason like security that forced 
us to really remove some interface).

But most of the changes have been extending things, leaving the old 
interfaces around (often as wrappers around the new internal world order, 
sometimes by effectively having actual duplicated code).

And then the old interface is maintained for quite a while (sometimes 
decades, often years, and generally at least for several kernel versions 
so that people have time to upgrade, and a distro can generally pick a 
newer kernel without having to change anything else).

Sometimes we've done things that really end up requiring new tools. It's 
pretty rare, but it does happen. It happens a lot more for "esoteric" 
things that aren't every-day-in-your-face (I've seen at least _one_ mutter 
about "sysfs" in this thread ;) and might break something like a 
temperature sensor, for example.

So the machine might _work_ and you could go for days without even 
noticing, but you might have some very specific functionality missing. 
Maybe your power meter doesn't work, or maybe you need to upgrade your 
kernel profiler to get good profiles again. Things like that.

I suspect you as an X person know this very well, in fact. X itself has 
carried along a _lot_ of cruft exactly like this, that you guys have been 
removing only in the last few years - sometimes after decades of it being 
there. The whole switch to modern font handling is an obvious example of a 
_major_ fundamental feature change like that.

So in general, what the kernel strives for is that very kind of "the old 
model will still work - but it might be slow and emulated on top of a new 
way of dong things, and not get a lot of attention any more".

And sometimes, there's really no good way of maintaining two interfaces at 
the kernel level, and then you have the downstream tools that have to 
learn to pick either the old or the new one, so that the tool still works 
regardless.

And again, the old code _eventually_ bitrots or gets cleaned up, but what 
you really really want to avoid is to have a flag-day when you switch from 
one to the other, and you can't switch between adjacent versions of the 
kernel. 

In the 2.4.x/2.6.x split, for example, we did have system tools that 
needed to be upgraded if you came from a 2.4.x environment. You can still 
see signs of that in the kernel tree: we have that whole 
Documentation/Changes file that _still_ remains in our tree, even though 
it's purely historical.

But if you look at that Documentation/Changes file, I don't think there is 
_any_ flag-day issue except for the removal of "devfs". People _still_ 
talk about devfs in hushed tones. Everything else is about having to 
upgrade system tools _before_ upgrading the kernel (iow, they still worked 
on 2.4.x, but you needed recent enough versions of them to compile and run 
a 2.6.x kernel).

In other words, it wasn't a "flag day" (apart from the already mentioned 
devfs users, and possibly something else I can't think of). It was an 
upgrade, yes, and it required some other things to be recent, but you 
could go back-and-forth between kernels if you had to.

(Of course, it's now many years since that, so maybe my rose-colored 
glasses makes me forget the pain involved. And I obviously personally 
never made the whole 2.4.x -> 2.6.x jump, since I'd been running the 
development kernels in between. So maybe I forgot some painful part).

			Linus

Re: [git pull] drm request 3

[Dale Farnsworth]

> read() still works the same way it did 30 years ago last time I
> checked.

seek() doesn't.  :)

-Dale

Re: [git pull] drm request 3

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Fri, 05 Mar 2010 18:04:34 +0200, Daniel Stone said:

> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

Amen to that.  I can remember the X10.4->X11 conversion in 1987. And a heck of
a lot of source-level stability since then (even with the libX11 getting redone
with libxcb under it. 23 years and still going strong is one hell of a good run
for an ABI.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [git pull] drm request 3

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 557 bytes --]

On Fri, 05 Mar 2010 18:04:34 +0200, Daniel Stone said:

> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

Amen to that.  I can remember the X10.4->X11 conversion in 1987. And a heck of
a lot of source-level stability since then (even with the libX11 getting redone
with libxcb under it. 23 years and still going strong is one hell of a good run
for an ABI.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 1688 bytes --]

On Fri, Mar 05, 2010 at 07:48:35AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@fooishbar.org>
> > On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> >> In fact, I argue that the moment nouveau went into Fedora and
> >> was turned on by default, the interfaces needed to be frozen.
> > 
> > That's a matter for the Fedora kernel team; for better or worse, they
> > made the choices they did, which included going through all the relevant
> > pain to support this.  They didn't consider it suitable for upstream
> > because they didn't think everyone else should be forced to endure that
> > pain.
> 
> By not merging it upstream the pain is larger not smaller.
> 
> It's enabled by default, so you therefore can't test upstream kernels
> by default.

'That's a matter for the Fedora kernel team'.

> And as I showed already, even if you jump through the hoops to make it
> work (building noveau from out of tree in the upstream kernel) you'll
> end up getting screwed when the API changes anyways.

So you're saying that there's no way to develop any reasonable body of
code for the Linux kernel without committing to keeping your ABI
absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
that worked really well for Xlib.

> Using VESA or whatever else you've suggested is just not a reasonable
> alternative.
> 
> You can't unleash something like this on a userbase of this magnitude
> and then throw your hands up in the air and say "I'm not willing to
> support this in a reasonable way."
> 
> We're better than that.

Your opinion on what constitutes reasonable support is not universal,
absolute truth.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Luca Barbieri]

It seems to me that Linus' technical argument is indeed being mostly ignored.

While breaking the ABI is unfortunate, the real problem that Linus
complained about is that you can't install several userspace versions
side-by-side.

This means that if you install your new kernel and userspace, reboot,
and find the new kernel doesn't work for some reason, you can't just
go back to the old kernel and have working X, because you just
replaced userspace with a version that no longer works with the kernel
that worked correctly.

This is even worse for distributions that want to upgrade the kernel,
because each kernel package would need to have a Depends on the exact
userspace package version.
Thus, the package manager would remove the older kernel when the new
one is installed (since they depend on different versions of the same
userspace package).
If the new kernel somehow doesn't work, the user is totally screwed
and must reboot from a live CD.

As pointed out, in this case, it is relatively easy to solve by adding
a version number to libdrm-nouveau, the X driver and the DRI drivers.
X will then have to load the correct driver and give Mesa the DRI
driver name with the correct version appended.

It may be a good idea to do this before the new nouveau ABI gets
shipped in released distributions, and with a generic mechanisms that
can be used by all X/drm drivers.

Workarounds are possible, such as replacing /usr/bin/X with a script
that loads the correct version, or using X over /dev/fb0 (which should
work fine with any DRM KMS driver, and any non-DRI framebuffer), but
they shouldn't be needed.

BTW, the nVidia proprietary driver also ties the kernel and userspace
version in this way, and is actually worse because it replaces the X
libglx.so, breaking all other drivers.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Luca Barbieri]

It seems to me that Linus' technical argument is indeed being mostly ignored.

While breaking the ABI is unfortunate, the real problem that Linus
complained about is that you can't install several userspace versions
side-by-side.

This means that if you install your new kernel and userspace, reboot,
and find the new kernel doesn't work for some reason, you can't just
go back to the old kernel and have working X, because you just
replaced userspace with a version that no longer works with the kernel
that worked correctly.

This is even worse for distributions that want to upgrade the kernel,
because each kernel package would need to have a Depends on the exact
userspace package version.
Thus, the package manager would remove the older kernel when the new
one is installed (since they depend on different versions of the same
userspace package).
If the new kernel somehow doesn't work, the user is totally screwed
and must reboot from a live CD.

As pointed out, in this case, it is relatively easy to solve by adding
a version number to libdrm-nouveau, the X driver and the DRI drivers.
X will then have to load the correct driver and give Mesa the DRI
driver name with the correct version appended.

It may be a good idea to do this before the new nouveau ABI gets
shipped in released distributions, and with a generic mechanisms that
can be used by all X/drm drivers.

Workarounds are possible, such as replacing /usr/bin/X with a script
that loads the correct version, or using X over /dev/fb0 (which should
work fine with any DRM KMS driver, and any non-DRI framebuffer), but
they shouldn't be needed.

BTW, the nVidia proprietary driver also ties the kernel and userspace
version in this way, and is actually worse because it replaces the X
libglx.so, breaking all other drivers.

Re: [git pull] drm request 3

[Alan Cox]

On Fri, 5 Mar 2010 16:56:10 +0100
Luca Barbieri <luca.barbieri@gmail.com> wrote:

> It seems to me that Linus' technical argument is indeed being mostly ignored.
> 
> While breaking the ABI is unfortunate, the real problem that Linus
> complained about is that you can't install several userspace versions
> side-by-side.

I think you need to be clearer about that. Your distribution packaging
may not support that out of the box. There are a variety of ways to do
almsot all of this including having entire parallel X installs for
development work.

All the X builds are modular, all the modular builds support --prefix=
with their autogen script. ld.so supports LD_LIBRARY_PATH and the shells
support PATH variables.

You can replace all or almost any part of X quite easily. There is also a
mechanism for versioning within DRM for a lot of stuff, and drivers use
flags to make it work nicely except for devel code (which is what Nouveau
is)

The fundamental problem you can't solve by versioning though is the exact
one here. A new kernel that requires version X of a driver won't help if
the newest version you have is X - 1.

Yeah perhaps Fedora should have pushed an update that was smart enough to
handle the Nouveau old/new ABI before the patch went upstream. Hindsight
is an exact science.

Alan

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

On Fri, 5 Mar 2010 16:56:10 +0100
Luca Barbieri <luca.barbieri@gmail.com> wrote:

> It seems to me that Linus' technical argument is indeed being mostly ignored.
> 
> While breaking the ABI is unfortunate, the real problem that Linus
> complained about is that you can't install several userspace versions
> side-by-side.

I think you need to be clearer about that. Your distribution packaging
may not support that out of the box. There are a variety of ways to do
almsot all of this including having entire parallel X installs for
development work.

All the X builds are modular, all the modular builds support --prefix=
with their autogen script. ld.so supports LD_LIBRARY_PATH and the shells
support PATH variables.

You can replace all or almost any part of X quite easily. There is also a
mechanism for versioning within DRM for a lot of stuff, and drivers use
flags to make it work nicely except for devel code (which is what Nouveau
is)

The fundamental problem you can't solve by versioning though is the exact
one here. A new kernel that requires version X of a driver won't help if
the newest version you have is X - 1.

Yeah perhaps Fedora should have pushed an update that was smart enough to
handle the Nouveau old/new ABI before the patch went upstream. Hindsight
is an exact science.

Alan

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:
> 
> Yeah perhaps Fedora should have pushed an update that was smart enough to
> handle the Nouveau old/new ABI before the patch went upstream. Hindsight
> is an exact science.

Alan - it seems you're missing the whole point.

The thing I objected to, in the VERY BEGINNING in this thread, i the fact 
that the thing was done in such a way that it's basically impossible to 
support the old/new ABI at all! Let me quote that second email:

 "That commit seems to _on_purpose_ try to avoid at all cost being 
  compatible. It not only removes some old entry-points, it literally 
  re-numbers all the ioctl numbers as it does so, apparently entirely in 
  order to just make it difficult to have some libdrm that can handle both 
  versions."

So it's not a "before the patch went upstream" issue. The same issue 
exists _after_ the patch went upstream.

The way this was done, it's apparently basically impossible for the Fedora 
people to push out packaged that support both the old and the new kernel.

Alan, if this had been done in a way that allowed that whole old/new ABI 
that you mention to work, I wouldn't have been complaining so much!

In other words - I've not been complaining about updating the ABI. I've 
been complaining about doing it in such a way that it's near impossible to 
go back-and-forth, because the very thing you suggest was made way way 
harder than it should be.

		Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:
> 
> Yeah perhaps Fedora should have pushed an update that was smart enough to
> handle the Nouveau old/new ABI before the patch went upstream. Hindsight
> is an exact science.

Alan - it seems you're missing the whole point.

The thing I objected to, in the VERY BEGINNING in this thread, i the fact 
that the thing was done in such a way that it's basically impossible to 
support the old/new ABI at all! Let me quote that second email:

 "That commit seems to _on_purpose_ try to avoid at all cost being 
  compatible. It not only removes some old entry-points, it literally 
  re-numbers all the ioctl numbers as it does so, apparently entirely in 
  order to just make it difficult to have some libdrm that can handle both 
  versions."

So it's not a "before the patch went upstream" issue. The same issue 
exists _after_ the patch went upstream.

The way this was done, it's apparently basically impossible for the Fedora 
people to push out packaged that support both the old and the new kernel.

Alan, if this had been done in a way that allowed that whole old/new ABI 
that you mention to work, I wouldn't have been complaining so much!

In other words - I've not been complaining about updating the ABI. I've 
been complaining about doing it in such a way that it's near impossible to 
go back-and-forth, because the very thing you suggest was made way way 
harder than it should be.

		Linus

Re: [git pull] drm request 3

[Alan Cox]

> The thing I objected to, in the VERY BEGINNING in this thread, i the fact 
> that the thing was done in such a way that it's basically impossible to 
> support the old/new ABI at all! 

What did you expect them to do. They said when you first forced a merge
that they would do this. They have no contract that I am aware of to
deliver you compatibility, in fact quite the reverse they said they
wouldn't be.

Then you attribute to malice what was done as a cleanup by people
who've pointedly never to commited to a constant API yet

 "That commit seems to _on_purpose_ try to avoid at all cost being 
  compatible."

Great way to make friends.

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> The thing I objected to, in the VERY BEGINNING in this thread, i the fact 
> that the thing was done in such a way that it's basically impossible to 
> support the old/new ABI at all! 

What did you expect them to do. They said when you first forced a merge
that they would do this. They have no contract that I am aware of to
deliver you compatibility, in fact quite the reverse they said they
wouldn't be.

Then you attribute to malice what was done as a cleanup by people
who've pointedly never to commited to a constant API yet

 "That commit seems to _on_purpose_ try to avoid at all cost being 
  compatible."

Great way to make friends.

Alan

Re: [git pull] drm request 3

[Felipe Contreras]

On Fri, Mar 5, 2010 at 6:19 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact
> that the thing was done in such a way that it's basically impossible to
> support the old/new ABI at all!

[...]

> The way this was done, it's apparently basically impossible for the Fedora
> people to push out packaged that support both the old and the new kernel.

The reason why the nouveau people wanted to leave the driver in
staging is because they wanted to leave open the option of reshuffling
the API. The Fedora guys integrated this stuff on their own risk, and
linux (because of your pressure), also did. At no point in time
nouveau guys agreed to freeze the API.

Now they have done precisely what was expected; there's no surprise there.

The surprise seems to be that you thought (for some reason), that
reshuffling the API wouldn't break the old (or current in F12)
user-space code. Now, how exactly do you think that could have been
achieved? Even if you have both nouveau_drv-0.0.15.so, and
nouveau_drv-0.0.16.so... What piece of could would choose one rather
than the other? There has never been such a piece of code.

If there was no compatibility code for API re-shuffling, and API
re-shuffling was expected, the resulting breakage was doomed to
happen.

Finally, at least it's possible to compile the radeon driver without
support for DRM, so perhaps nouveau (and other drivers), should check
the kernel drm version at run-time instead, and fall-back to non-drm
mode when the version is not compatible. I think that's a sensible
approach, although that might require a considerable amount of code.
However, that's something to consider for the future, as your current
libdrm/nouveau is not prepared to handle  the DRM API re-shuffle that
_must_ happen.

Cheers.

-- 
Felipe Contreras

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Felipe Contreras]

On Fri, Mar 5, 2010 at 6:19 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact
> that the thing was done in such a way that it's basically impossible to
> support the old/new ABI at all!

[...]

> The way this was done, it's apparently basically impossible for the Fedora
> people to push out packaged that support both the old and the new kernel.

The reason why the nouveau people wanted to leave the driver in
staging is because they wanted to leave open the option of reshuffling
the API. The Fedora guys integrated this stuff on their own risk, and
linux (because of your pressure), also did. At no point in time
nouveau guys agreed to freeze the API.

Now they have done precisely what was expected; there's no surprise there.

The surprise seems to be that you thought (for some reason), that
reshuffling the API wouldn't break the old (or current in F12)
user-space code. Now, how exactly do you think that could have been
achieved? Even if you have both nouveau_drv-0.0.15.so, and
nouveau_drv-0.0.16.so... What piece of could would choose one rather
than the other? There has never been such a piece of code.

If there was no compatibility code for API re-shuffling, and API
re-shuffling was expected, the resulting breakage was doomed to
happen.

Finally, at least it's possible to compile the radeon driver without
support for DRM, so perhaps nouveau (and other drivers), should check
the kernel drm version at run-time instead, and fall-back to non-drm
mode when the version is not compatible. I think that's a sensible
approach, although that might require a considerable amount of code.
However, that's something to consider for the future, as your current
libdrm/nouveau is not prepared to handle  the DRM API re-shuffle that
_must_ happen.

Cheers.

-- 
Felipe Contreras

Re: [git pull] drm request 3

[Luca Barbieri]

> I think you need to be clearer about that. Your distribution packaging
> may not support that out of the box. There are a variety of ways to do
> almsot all of this including having entire parallel X installs for
> development work.

Sure, but each user must manually find out how to setup that, and
create and test the setup himself (or happen to use a distribution
that somehow eases that, if any exist).

I think that Linus has a good point in saying that this should be
provided by default.
And ideally not just by the distribution, but upstream, so that people
wanting to test bleeding edge DRM drivers (not necessarily just
nouveau) can do so more easily, and beable to go back to their working
setup by rebooting should something go wrong.

> The fundamental problem you can't solve by versioning though is the exact
> one here. A new kernel that requires version X of a driver won't help if
> the newest version you have is X - 1.

Yes, but the fact that you can't have both X - 1 and X at the same
time makes it worse, since for instance bisecting won't just work.

> Yeah perhaps Fedora should have pushed an update that was smart enough to
> handle the Nouveau old/new ABI before the patch went upstream. Hindsight
> is an exact science.

Well, yes, but it can still be implemented in time for the next
distribution releases and the lesson can be learned for similar future
situations.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Luca Barbieri]

> I think you need to be clearer about that. Your distribution packaging
> may not support that out of the box. There are a variety of ways to do
> almsot all of this including having entire parallel X installs for
> development work.

Sure, but each user must manually find out how to setup that, and
create and test the setup himself (or happen to use a distribution
that somehow eases that, if any exist).

I think that Linus has a good point in saying that this should be
provided by default.
And ideally not just by the distribution, but upstream, so that people
wanting to test bleeding edge DRM drivers (not necessarily just
nouveau) can do so more easily, and beable to go back to their working
setup by rebooting should something go wrong.

> The fundamental problem you can't solve by versioning though is the exact
> one here. A new kernel that requires version X of a driver won't help if
> the newest version you have is X - 1.

Yes, but the fact that you can't have both X - 1 and X at the same
time makes it worse, since for instance bisecting won't just work.

> Yeah perhaps Fedora should have pushed an update that was smart enough to
> handle the Nouveau old/new ABI before the patch went upstream. Hindsight
> is an exact science.

Well, yes, but it can still be implemented in time for the next
distribution releases and the lesson can be learned for similar future
situations.

Re: [git pull] drm request 3

[Alan Cox]

> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable."  Because that's complete garbage

Staging has to have the no API rules. Read some of the stuff in there to
understand why or apply about 30 seconds of thought to what it would mean
to you.

There are staging drivers using old wireless layers. If you say that no
API can be broken from staging then you will have to put the old wireless
compatibility into your network code forever. Does that fill you with
joy, light and happiness ?

Whether nouveau should ever have gone into staging is a different
question.

I don't personally think its all as clear cut as it might seem. Quite a
few distributions ship whacky wireless drivers with old API's as the
choice is that or nothing. They manage the user expectation and they deal
with the drivers moving from one wireless stack to the other and
mostly successfully hide it in userspace.

The differences here appear to be
- Having no video is more annoying than having no wireless
- Userspace failed to hide it (so maybe its not a kernel ABI problem but
  a failure to anticipate the need for versioned libdrm and the
  importance in some eyes of supporting the kernel.org kernel - which
  like it or not is a corner case for distro *users*).
- The box it broke happened to belong to Linus

but that doesn't really require tantrums or fingerpointing to fix,
particularly when its only the combination of a set of decisions and
misunderstandings by Linus, Fedora and the Nouveau developers together
that combined to create the mess.

Alan

Re: [git pull] drm request 3

[Alan Cox]

> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable."  Because that's complete garbage

Staging has to have the no API rules. Read some of the stuff in there to
understand why or apply about 30 seconds of thought to what it would mean
to you.

There are staging drivers using old wireless layers. If you say that no
API can be broken from staging then you will have to put the old wireless
compatibility into your network code forever. Does that fill you with
joy, light and happiness ?

Whether nouveau should ever have gone into staging is a different
question.

I don't personally think its all as clear cut as it might seem. Quite a
few distributions ship whacky wireless drivers with old API's as the
choice is that or nothing. They manage the user expectation and they deal
with the drivers moving from one wireless stack to the other and
mostly successfully hide it in userspace.

The differences here appear to be
- Having no video is more annoying than having no wireless
- Userspace failed to hide it (so maybe its not a kernel ABI problem but
  a failure to anticipate the need for versioned libdrm and the
  importance in some eyes of supporting the kernel.org kernel - which
  like it or not is a corner case for distro *users*).
- The box it broke happened to belong to Linus

but that doesn't really require tantrums or fingerpointing to fix,
particularly when its only the combination of a set of decisions and
misunderstandings by Linus, Fedora and the Nouveau developers together
that combined to create the mess.

Alan



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, David Miller wrote:
> 
> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

Now, I agree that that would have been the optimal setup from a testing an 
user standpoint, but I think it's a bit too strong.

Things don't need to be "frozen", but flag-days need to be avoided. The 
problem with flag-days is not so much that they need new support code: 
downloading a new version of something like X is not a huge issue. But 
flag-days work both ways: it's not just that you have to download a new 
version, it's that you can't go _back_ either - not even a little bit.

For example, I can now test my new kernel, but if it turns out that there 
are problems with it, I'm now officially screwed. I can't go back and rely 
on even the stable distro kernel, like I'm used to ("ok, that _really_ 
didn't work, but happily I didn't remove the distro kernel, so I'll just 
reboot with that"). And I certainly can't bisect without major problems.

And Fedora can't install the new libraries, because they won't work with 
their own old kernels either. So it effectively causes a version freeze: 
it looks like F12 will simply _never_ be able to support a 2.6.34 kernel, 
because if they do that, then everybody who gets the new packages (and has 
a nvidia graphics card) will now be stuck.

So flag-days really are bad. They're bad for users, they're bad for 
distributions, and they're eventually bad for developers too because now 
they lose a lot of every-day testing. Some day, F13 will come out, and the 
_only_ testing all the new code ever got was the (relatively small) 
rawhide community, and the kernel crazies who did things manually.

But even if you can't guarantee backwards compatibility, if you avoid the 
flag-day, and can have a new version of the environment that can handle 
both the old and the new model, you _could_ install that on F12 (before 
switching kernels), and not be in that effective version-freeze.

Yeah, you'll still have a dependency chain, but it will be a one-way one, 
so you're not stuck. As long as you have the newest vesion of whatever 
libraries or support, you can go back-and-forth and test development 
systems.

And we do that for the kernel in many other respects. We require that you 
have a "recent enough" compiler, for example. So there are already lots of 
those one-way dependencies where we're not infinitely backwards compatible 
with user space, but we've been pretty good at not having flag-days.

				Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, David Miller wrote:
> 
> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

Now, I agree that that would have been the optimal setup from a testing an 
user standpoint, but I think it's a bit too strong.

Things don't need to be "frozen", but flag-days need to be avoided. The 
problem with flag-days is not so much that they need new support code: 
downloading a new version of something like X is not a huge issue. But 
flag-days work both ways: it's not just that you have to download a new 
version, it's that you can't go _back_ either - not even a little bit.

For example, I can now test my new kernel, but if it turns out that there 
are problems with it, I'm now officially screwed. I can't go back and rely 
on even the stable distro kernel, like I'm used to ("ok, that _really_ 
didn't work, but happily I didn't remove the distro kernel, so I'll just 
reboot with that"). And I certainly can't bisect without major problems.

And Fedora can't install the new libraries, because they won't work with 
their own old kernels either. So it effectively causes a version freeze: 
it looks like F12 will simply _never_ be able to support a 2.6.34 kernel, 
because if they do that, then everybody who gets the new packages (and has 
a nvidia graphics card) will now be stuck.

So flag-days really are bad. They're bad for users, they're bad for 
distributions, and they're eventually bad for developers too because now 
they lose a lot of every-day testing. Some day, F13 will come out, and the 
_only_ testing all the new code ever got was the (relatively small) 
rawhide community, and the kernel crazies who did things manually.

But even if you can't guarantee backwards compatibility, if you avoid the 
flag-day, and can have a new version of the environment that can handle 
both the old and the new model, you _could_ install that on F12 (before 
switching kernels), and not be in that effective version-freeze.

Yeah, you'll still have a dependency chain, but it will be a one-way one, 
so you're not stuck. As long as you have the newest vesion of whatever 
libraries or support, you can go back-and-forth and test development 
systems.

And we do that for the kernel in many other respects. We require that you 
have a "recent enough" compiler, for example. So there are already lots of 
those one-way dependencies where we're not infinitely backwards compatible 
with user space, but we've been pretty good at not having flag-days.

				Linus

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/05/2010 10:17 AM, Daniel Stone wrote:
> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>> If it effects such a large number of people, which this noveau thing
>> does, it's entirely relevant to everyone.  And the way it's breaking
>> and making kernel development difficult for so many people matters to
>> us.
>
> Maybe the lesson to be learned from all this is, 'if the developers
> don't want something merged because they're not ready and forsee huge
> problems in the future, actually listen to them instead of blindly
> ramming it in regardless'? But maybe that's just me.

That particular horse left the barn when Fedora shipped nouveau in a 
stable release, not when Linus merged it into his tree.

	Jeff

Re: [git pull] drm request 3

[Justin P. mattock]

On 03/05/2010 09:42 AM, Jeff Garzik wrote:
> On 03/05/2010 10:17 AM, Daniel Stone wrote:
>> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>>> If it effects such a large number of people, which this noveau thing
>>> does, it's entirely relevant to everyone. And the way it's breaking
>>> and making kernel development difficult for so many people matters to
>>> us.
>>
>> Maybe the lesson to be learned from all this is, 'if the developers
>> don't want something merged because they're not ready and forsee huge
>> problems in the future, actually listen to them instead of blindly
>> ramming it in regardless'? But maybe that's just me.
>
> That particular horse left the barn when Fedora shipped nouveau in a
> stable release, not when Linus merged it into his tree.
>
> Jeff
>
>
>
> --
> 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/
>


stopped me in my tracks i.g.
in order to install using the livecd
requires brain surgery.
(for me that's fine, but for an average business
person/s forget it).

Justin P. Mattock

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Justin P. mattock]

On 03/05/2010 09:42 AM, Jeff Garzik wrote:
> On 03/05/2010 10:17 AM, Daniel Stone wrote:
>> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>>> If it effects such a large number of people, which this noveau thing
>>> does, it's entirely relevant to everyone. And the way it's breaking
>>> and making kernel development difficult for so many people matters to
>>> us.
>>
>> Maybe the lesson to be learned from all this is, 'if the developers
>> don't want something merged because they're not ready and forsee huge
>> problems in the future, actually listen to them instead of blindly
>> ramming it in regardless'? But maybe that's just me.
>
> That particular horse left the barn when Fedora shipped nouveau in a
> stable release, not when Linus merged it into his tree.
>
> Jeff
>
>
>
> --
> 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/
>


stopped me in my tracks i.g.
in order to install using the livecd
requires brain surgery.
(for me that's fine, but for an average business
person/s forget it).

Justin P. Mattock

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/05/2010 10:17 AM, Daniel Stone wrote:
> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>> If it effects such a large number of people, which this noveau thing
>> does, it's entirely relevant to everyone.  And the way it's breaking
>> and making kernel development difficult for so many people matters to
>> us.
>
> Maybe the lesson to be learned from all this is, 'if the developers
> don't want something merged because they're not ready and forsee huge
> problems in the future, actually listen to them instead of blindly
> ramming it in regardless'? But maybe that's just me.

That particular horse left the barn when Fedora shipped nouveau in a 
stable release, not when Linus merged it into his tree.

	Jeff




------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 12:38:34 +0000

>> The conclusion is crystal clear, breaking an ABI via a "flag day" 
>> cleanup/feature/etc is:
> 
> Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
> junk that is in there being cleaned up it would be *insane* to keep their
> old APIs
> 
> See there's a bigger offence than breaking an ABI - its called not RTFM.

All of this RTFM and what directory the noveau driver is sitting in is
entirely irrelevant Alan.

If it effects such a large number of people, which this noveau thing
does, it's entirely relevant to everyone.  And the way it's breaking
and making kernel development difficult for so many people matters to
us.

It's about the tester base, and this breakage shrinks the tester base
considerably.

Or do you want the kernel tested by less people?

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> The conclusion is crystal clear, breaking an ABI via a "flag day" 
> cleanup/feature/etc is:

Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
junk that is in there being cleaned up it would be *insane* to keep their
old APIs

See there's a bigger offence than breaking an ABI - its called not RTFM.

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> Speaking as distro maintainer here,
> 
> No because we've got versioned interfaces and we are happy to support them
> yes it would be nice sometimes to dream about this, but its a major explosion in
> the testing matrix. You have to realise the more codepaths a distro ships, the
> more codepath it has to keep track off for security issues, for bug fixes, etc.

I think you're missing the whole point here. There's no new and complex 
"testing matrix". You only ever test the newest version, so there's no 
additional testing.

Here's the "inductive proof":

 - if the version number doesn't change, you aren't doing anything that is 
   at all different from what you already do.

 - if the version number _does_ change, it does so only because you 
   updated both the kernel component and the libdrm component together, 
   and you test them together - exactly like you already do.

So there is absolutely no difference for you. In either case, you only 
ever test paired up versions. If you make a new version, it will never 
_ever_ interact with old versions. There's no new complex testing needed.

The only thing it allows is for you to have multiple kernels installed 
simultaneously - and be able to _use_ them all. Which is something you 
already do.

And which the current model doesn't allow for. You may have three 
different kernels installed, but if libdrm got updated with a version 
change, only one of those kernels will actually _work_.

> When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> out it has a security issue?

Irrelevant and total red herring. You never care about older versions, 
since if people have updated, they are running the newer version.

So the older versions are there purely so that you _can_ have multiple 
different kernels, and so that your _developers_ can compile new kernels 
for older distributions. They aren't relevant for the case you point to: 
if somebody is just doing "yum update", they'll get - and use - the newer 
version anyway.

> Here's the thing, distros are trying to ship an OS with a consistent set 
> of packages, not a pick-n-mix.

But here's the thing: if you expect people to do development, they _need_ 
to be able to mix things. A kernel developer needs to be able to update 
their kernel. And a kernel _tester_ needs to be able to test that kernel.

Seriously: what do you expect me to do right now in my situation?

I'm not going to release a kernel that I can't test. So if I can't get a 
libdrm that works in my F12 environment, I will _have_ to revert that 
patch that you asked me to merge.

Really. Look at it from my standpoint. Look at it from _any_ kernel 
developer standpoint. It would be totally irresponsible of me to release 
2.6.34 without even eating my own dog-food on my own main machine. Can't 
you see that this is obviously true?

So right now, I'm running with that patch reverted on that machine. I 
haven't committed the revert, and quite frankly, I'd really prefer not to. 
But the only way that "not revert" case can really happen is if there is 
some other way for me to have a working machine again.

Think about it. Tell me what the solution is.

		Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Dave Airlie]

> Can we try to make it less of a pain in the ass at some other level?
>
> For example, I realize that it's a real pain - both for the kernel _and_
> for the user space library - to dynamically have to support multiple
> versions of some interface.
>
> And doing it _statically_ (with a compile option) isn't much better,
> because you end up not only with source code from hell, you still end up
> with the problem of having to compile the libraries and the kernel for the
> same interface, and not being able to mix.
>
> So let's say that we live with an API that changes, where none of the
> binaries (and no single version of the source code either) really support
> anything but _their_ version of the interface.
>
> Why does it then have to be such an effing pain for the _user_?
>
> (And by being such an effing pain for the user, it also becomes indirectly
> a pain for the distribution too - now you have all those nasty
> dependencies where you really cannot mix things up at all, and you can't
> upgrade one piece without upgrading the other).
>
>> Now I can ask Ben if he'd like to try and supply a libdrm that could in
>> theory deal with both as a favour, but I'm not expecting the nouveau
>> project guys to care, we pretty much got ourselves into this corner, and
>> we'll pretty much have to get ourselves out.
>
> Quite frankly, I really don't think that's a wonderful option either.
> Havign dynamic conditionals in code not only makes things worse to
> maintain, they slow things down too, and make code bigger.
>
> So what I'd look for is a sane technical solution to the technical problem
> of "that ABI screwed up".
>
> And it's not like this is a new issue. We've had this several times
> before. It's called versioning, and the solution tends to pretty much
> _always_ boil down to two cases:
>
>  - don't _ever_ change the ABI in backwards-incompatible ways, and have
>   "feature flags" to say what level of support ther is.
>
>   This is quite common, but it really does require that backwards
>   compatibility. You can add features, but every time you add a feature,
>   you still maintain the old ones _and_ new users need to check the
>   feature flag first (and fall back on the old way of doing things if the
>   new feature isn't there)
>
>   Clearly this one doesn't seem to work for DRM. And quite frankly, I
>   suspect it's at least partly because some DRM people aren't even
>   _trying_ - possibly because they aren't even thinking about these kinds
>   of issues.

We've done this exactly like this since the drm went upstream, I think
there has been one interface incompatible change in the kernel drm since
it was upstream, in i810 back in the XFree86 days. KMS required new config
options since moving the card init into the kernel, was going to break
or be broken
by a userspace driver reiniting that card, and we've retained compatiblity
with older drivers fine.

So you are tarring the whole drm with the interface to one driver
which is clearly
marked as having an unstable ABI. Nouveau is different, they have had no
reason to version or make a stable interface until they could design
an interface
that would expose the features of the hw that they are trying to build
a driver for.
They've also used the timing to drop all support for legacy user modesetting
drivers while they could, before it was deployed on a lot of people's machines
in a lot of places.


>   I really don't understand why this wouldn't solve all your distro
>   problems, _and_ solve my kind of user problems too. It's simply not
>   acceptable to just say "ok, X doesn't work". Why aren't the libdrm
>   libraries simply _versioned_?

This would require redesigning the whole way distros build and distribute
packages. Having to build 4-5 versions of nouveau for each version of Fedora
would be a major increase in overheads for a minimal amount of return.

>
>   IOW, why can't we just have
>
>        /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
>        /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so
>
>   living happily side-by-side? Why can't we just switch between Fedora
>   11, 12 and 13 kernels, and automatically get the right library? The
>   glibc people do it based on hardware features. It's just a "dlopen()"
>   away.
>
> This isn't rocket science. I shouldn't need to complain. I think it would
> make the life of even the _developers_ much easier.
>
> Who was the less-than-rocket-scientist that decided that the right thing
> to do was to "check the kernel DRM version support, and exit with an error
> if it doesn't match"?
>
> See what I'm saying? What I care about is that right now, it's impossible
> to switch kernels on a particular setup. That makes it effectively
> impossible to test new kernels sanely. And that really is a _technical_
> problem.
>
> Btw, I'm sure there are other approaches too. But I really suspect that it
> should be pretty trivial to change nouveau (and I suspect this has nothing
> nouveau-specific in it - it migth even be the X server itself that does
> the DRM version test) to instead of dying, just doing a dlopen() of the
> right version.
>
> Wouldn't the radeon and intel driver people love to be able to do
> something like that -too-?

Speaking as distro maintainer here,

No because we've got versioned interfaces and we are happy to support them
yes it would be nice sometimes to dream about this, but its a major explosion in
the testing matrix. You have to realise the more codepaths a distro ships, the
more codepath it has to keep track off for security issues, for bug fixes, etc.

When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
out it has a security issue? Here's the thing, distros are trying to ship an
OS with a consistent set of packages, not a pick-n-mix.

I'm going to talk to Ben when we both make it to the same place, from a
nouveau point-of-view I'm quite happy what they've done is technically the
correct solution for them, because otherwise you end up with too many
versions of things to support, and you get distros who aren't willing to put
any developer effort into the project, shipping 3 different versions of things,
(this happens with binary drivers, and its a nightmare).

The thing with redesigning the whole stack like you say, its you are optimising
for the wrong use case, this isn't a common case, this is one off
event that we've
been forced into by merging nouveau upstream. I'd rather not optimise
for this case
if we can get away with it.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> If marking the driver as staging doesn't allow them to break ABI when
>> they need to, then it seems like they'll have no choice but to either
>> remove the driver from upstream and only submit it when the ABI is
>> stable, or fork the driver and submit a new one only when the ABI is
>> stable.  Neither seem particularly attractive.
>
> The thing is, they clearly didn't even _try_ to make anything compatible.
> See how all the ioctl numbers were moved around.
>
> And if you can't make if backwards compatible, at least you should make it
> forwards-compatible. Is it even that? I don't know. I'm kind of afraid it
> isn't. The new libdrm required for it certainly hasn't been pushed to
> Fedora-12. Will it ever be? And if it is, can you still run an old kernel
> on it?
>
> All of these are always possible to do. We've been _very_ good at doing
> them in general. I'm complaining, because let's face it, what else can I
> do?
>
> And btw, I'd complain about breaking backwards compatibility even if it
> wasn't just my own machine. I can pretty much guarantee that I'm not going
> to be the only one hitting this issue.
>
> So practically speaking: what _do_ you suggest we do about all the
> regressions this will cause?

At the moment in Fedora we deal with this for our users, we have dependencies
between userspace and kernel space and we upgrade the bits when they upgrade
the kernels, its a pain in the ass, but its what we accepted we needed
to do to get
nouveau in front of people. We are currently maintain 3 nouveau APIs
across F11, F12
and F13.

The main reason the API was gutted was because it supported lots of
things that weren't
supportable going forward. User modesetting support was completely
removed and this
meant lots of the API was pointless.

Now I can ask Ben if he'd like to try and supply a libdrm that could
in  theory deal
with both as a favour, but I'm not expecting the nouveau project guys
to care, we pretty
much got ourselves into this corner, and we'll pretty much have to get
ourselves out.

The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface
which justs ifdefs around this for now, and in another release or two
we rip all that out.

Of course I can't ask him either of these until normal people who live
in Australia wake
up in 2-3 hrs, as opposed to me who is sitting in the dark trying not
to wake the baby.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 11:08:07 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The thing is, they clearly didn't even _try_ to make anything compatible. 
> See how all the ioctl numbers were moved around. 
> 
> And if you can't make if backwards compatible, at least you should make it 
> forwards-compatible. Is it even that? I don't know. I'm kind of afraid it 
> isn't. The new libdrm required for it certainly hasn't been pushed to 
> Fedora-12. Will it ever be? And if it is, can you still run an old kernel 
> on it?

Sure, but both kinds of compat come at a cost, a potentially large one
in this case, so why take it on before absolutely necessary?  I know
you can see both sides of this...

> And btw, I'd complain about breaking backwards compatibility even if it 
> wasn't just my own machine. I can pretty much guarantee that I'm not going 
> to be the only one hitting this issue.

Right, but OTOH it's a development driver.  If you're running Fedora,
things will work as long as you stick to the distro packages.  And if
you're building your own kernels, you ought to be taking care with
staging drivers, right?

> So practically speaking: what _do_ you suggest we do about all the 
> regressions this will cause?

Before this thread I thought the policy was "let people muddle through"
with staging drivers until their staging status is cleared.  If that's
not the case, then really what's the point of staging?  I'm sure there
are other examples of this type of breakage in staging drivers, though
admittedly nouveau is probably the biggest in terms of user interest.

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 11:08:07 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The thing is, they clearly didn't even _try_ to make anything compatible. 
> See how all the ioctl numbers were moved around. 
> 
> And if you can't make if backwards compatible, at least you should make it 
> forwards-compatible. Is it even that? I don't know. I'm kind of afraid it 
> isn't. The new libdrm required for it certainly hasn't been pushed to 
> Fedora-12. Will it ever be? And if it is, can you still run an old kernel 
> on it?

Sure, but both kinds of compat come at a cost, a potentially large one
in this case, so why take it on before absolutely necessary?  I know
you can see both sides of this...

> And btw, I'd complain about breaking backwards compatibility even if it 
> wasn't just my own machine. I can pretty much guarantee that I'm not going 
> to be the only one hitting this issue.

Right, but OTOH it's a development driver.  If you're running Fedora,
things will work as long as you stick to the distro packages.  And if
you're building your own kernels, you ought to be taking care with
staging drivers, right?

> So practically speaking: what _do_ you suggest we do about all the 
> regressions this will cause?

Before this thread I thought the policy was "let people muddle through"
with staging drivers until their staging status is cleared.  If that's
not the case, then really what's the point of staging?  I'm sure there
are other examples of this type of breakage in staging drivers, though
admittedly nouveau is probably the biggest in terms of user interest.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 10:51:20AM -0800, Linus Torvalds wrote:

> That doesn't change the simple basic issue: how are people with Fedora-12 
> going to test any kernel out now? And are there libdrm versions that can 
> handle _both_ cases, so that people can bisect things? IOW, even if you 
> have a new libdrm, will it then work with the _old_ kernel too?

F-12 continues to ship the -nv driver, which will work fine with any 
kernel version as long as nouveau is disabled.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 10:51:20AM -0800, Linus Torvalds wrote:

> That doesn't change the simple basic issue: how are people with Fedora-12 
> going to test any kernel out now? And are there libdrm versions that can 
> handle _both_ cases, so that people can bisect things? IOW, even if you 
> have a new libdrm, will it then work with the _old_ kernel too?

F-12 continues to ship the -nv driver, which will work fine with any 
kernel version as long as nouveau is disabled.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> Whoa, so breaking ABI in staging drivers isn't ok?  Lots of other
> staging drivers are shipped by distros with compatible userspaces, but I
> thought the whole point of staging was to fix up ABIs before they
> became mainstream and had backwards compat guarantees, meaning that
> breakage was to be expected?

If the staging driver isn't in common use, who cares?

But this is a major driver, used by a major subsystem in a major 
distribution.

It's not like Fedora-12 is some odd case. And it's not like nVidia 
graphics is unusual.

Face it, nouveau is "staging" only in name.

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> Whoa, so breaking ABI in staging drivers isn't ok?  Lots of other
> staging drivers are shipped by distros with compatible userspaces, but I
> thought the whole point of staging was to fix up ABIs before they
> became mainstream and had backwards compat guarantees, meaning that
> breakage was to be expected?

If the staging driver isn't in common use, who cares?

But this is a major driver, used by a major subsystem in a major 
distribution.

It's not like Fedora-12 is some odd case. And it's not like nVidia 
graphics is unusual.

Face it, nouveau is "staging" only in name.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> I see the commit that does this was very aware of it:
> 
> 	commit a1606a9596e54da90ad6209071b357a4c1b0fa82
> 	Author: Ben Skeggs <bskeggs@redhat.com>
> 	Date:   Fri Feb 12 10:27:35 2010 +1000
> 
> 	    drm/nouveau: new gem pushbuf interface, bump to 0.0.16
> 
> 	    This commit breaks the userspace interface, and requires a new libdrm for
> 	    nouveau to operate again.

Quite frankly, the more I look at that commit, the worse it looks.

That commit seems to _on_purpose_ try to avoid at all cost being 
compatible. It not only removes some old entry-points, it literally 
re-numbers all the ioctl numbers as it does so, apparently entirely in 
order to just make it difficult to have some libdrm that can handle both 
versions.

This all means that I literally cannot test the current -git tree. 

I suspect I have to revert it. 

Or is there a version of X that can handle _both_ the 0.0.15 and the 
0.0.16 interfaces?

That's absolutely required - so that it's not a flag-day any more to 
upgrade the kernel, and so that people (including very much me) can test 
and bisect other things without having to worry about basic functionality 
coming and going as you bisect things,

			Linus

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> I see the commit that does this was very aware of it:
> 
> 	commit a1606a9596e54da90ad6209071b357a4c1b0fa82
> 	Author: Ben Skeggs <bskeggs@redhat.com>
> 	Date:   Fri Feb 12 10:27:35 2010 +1000
> 
> 	    drm/nouveau: new gem pushbuf interface, bump to 0.0.16
> 
> 	    This commit breaks the userspace interface, and requires a new libdrm for
> 	    nouveau to operate again.

Quite frankly, the more I look at that commit, the worse it looks.

That commit seems to _on_purpose_ try to avoid at all cost being 
compatible. It not only removes some old entry-points, it literally 
re-numbers all the ioctl numbers as it does so, apparently entirely in 
order to just make it difficult to have some libdrm that can handle both 
versions.

This all means that I literally cannot test the current -git tree. 

I suspect I have to revert it. 

Or is there a version of X that can handle _both_ the 0.0.15 and the 
0.0.16 interfaces?

That's absolutely required - so that it's not a flag-day any more to 
upgrade the kernel, and so that people (including very much me) can test 
and bisect other things without having to worry about basic functionality 
coming and going as you bisect things,

			Linus

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 10:43:30AM -0800, Linus Torvalds wrote:

> Or is there a version of X that can handle _both_ the 0.0.15 and the 
> 0.0.16 interfaces?

When you asked that nouveau was merged, people explicitly told you that 
the reason it hadn't been was because the interface was unstable and 
userspace would break. You asked that it be merged anyway, and now 
you're unhappy because the interface has changed and userspace has 
broken?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
>
> When you asked that nouveau was merged, people explicitly told you that 
> the reason it hadn't been was because the interface was unstable and 
> userspace would break. You asked that it be merged anyway, and now 
> you're unhappy because the interface has changed and userspace has 
> broken?

How hard is it to understand basic kernel development rules? 

Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People 
can hide behind all the "staging" and "I asked for it" things they like, 
but that doesn't change simple basic facts: distros should make sure 
drivers get merged up-stream, and people end up depending on them.

Btw, I'm hoping some of this pain goes away for me, because I expect to 
get rid of the shitty nVidia card reasonably soon. The fact that my main 
box had a power supply that literally _required_ a power-sucking-piece- 
of-sh*t-graphics card has been painful to me.

But none of that changes my basic objections. I didn't ask for nouveau to 
be merged as staging - I asked it to be merged because a major distro uses 
it.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
>
> When you asked that nouveau was merged, people explicitly told you that 
> the reason it hadn't been was because the interface was unstable and 
> userspace would break. You asked that it be merged anyway, and now 
> you're unhappy because the interface has changed and userspace has 
> broken?

How hard is it to understand basic kernel development rules? 

Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People 
can hide behind all the "staging" and "I asked for it" things they like, 
but that doesn't change simple basic facts: distros should make sure 
drivers get merged up-stream, and people end up depending on them.

Btw, I'm hoping some of this pain goes away for me, because I expect to 
get rid of the shitty nVidia card reasonably soon. The fact that my main 
box had a power supply that literally _required_ a power-sucking-piece- 
of-sh*t-graphics card has been painful to me.

But none of that changes my basic objections. I didn't ask for nouveau to 
be merged as staging - I asked it to be merged because a major distro uses 
it.

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> But none of that changes my basic objections. I didn't ask for nouveau to 
> be merged as staging - I asked it to be merged because a major distro uses 
> it.

Put another way: the issue of whether _I_ happen to see this personally or 
not is kind of irrelevant. We need testers for development kernels. And 
any time we make that hard, we lose. That's really fundamental.

The reason distributions should push their drivers upstream, and have a 
"upstream first" model in the first place is not because of _my_ hardware. 
It's because of the fundamental fact that if people can't test upstream 
kernels (because they don't work like the distro kernel does), we end up 
in a situations where people can't sanely test current git.

And that model simply doesn't work from a development standpoint. If you 
make it basically impossible for people to upgrade kernels, and if you 
take away their ability to bisect bugs, you're going to cause the quality 
of development to go down.

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> But none of that changes my basic objections. I didn't ask for nouveau to 
> be merged as staging - I asked it to be merged because a major distro uses 
> it.

Put another way: the issue of whether _I_ happen to see this personally or 
not is kind of irrelevant. We need testers for development kernels. And 
any time we make that hard, we lose. That's really fundamental.

The reason distributions should push their drivers upstream, and have a 
"upstream first" model in the first place is not because of _my_ hardware. 
It's because of the fundamental fact that if people can't test upstream 
kernels (because they don't work like the distro kernel does), we end up 
in a situations where people can't sanely test current git.

And that model simply doesn't work from a development standpoint. If you 
make it basically impossible for people to upgrade kernels, and if you 
take away their ability to bisect bugs, you're going to cause the quality 
of development to go down.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 10:55:57AM -0800, Linus Torvalds wrote:
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
> >
> > When you asked that nouveau was merged, people explicitly told you that 
> > the reason it hadn't been was because the interface was unstable and 
> > userspace would break. You asked that it be merged anyway, and now 
> > you're unhappy because the interface has changed and userspace has 
> > broken?
> 
> How hard is it to understand basic kernel development rules? 
> 
> Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People 
> can hide behind all the "staging" and "I asked for it" things they like, 
> but that doesn't change simple basic facts: distros should make sure 
> drivers get merged up-stream, and people end up depending on them.

It takes a long time to work out exactly what kind of userspace 
interface you need when the hardware you're dealing with is entirely 
undocumented. The reason it's been shipped in Fedora is that it needs to 
be in front of actual users in order to get any testing at all, and we 
have the manpower to ensure that the dependencies are consistent. But 
most nouveau development isn't handled inside Red Hat, and we're in no 
position to dictate terms to the volunteers who are spending their spare 
time trying to write a useful driver.

> Btw, I'm hoping some of this pain goes away for me, because I expect to 
> get rid of the shitty nVidia card reasonably soon. The fact that my main 
> box had a power supply that literally _required_ a power-sucking-piece- 
> of-sh*t-graphics card has been painful to me.

You'd have hit similar issues if you'd been using Radeon KMS over the 
past couple of releases...

> But none of that changes my basic objections. I didn't ask for nouveau to 
> be merged as staging - I asked it to be merged because a major distro uses 
> it.

It was merged as staging because the interface is unstable, which is 
consistent with staging's Kconfig:

"Please note that these drivers are under heavy development, may or may 
not work, and may contain userspace interfaces that most likely will be 
changed in the near future."

If you'd made it clear that you wanted the interface to be stable 
before it got merged, I suspect that it simply wouldn't have been merged 
until the interface was stable.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 10:55:57AM -0800, Linus Torvalds wrote:
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
> >
> > When you asked that nouveau was merged, people explicitly told you that 
> > the reason it hadn't been was because the interface was unstable and 
> > userspace would break. You asked that it be merged anyway, and now 
> > you're unhappy because the interface has changed and userspace has 
> > broken?
> 
> How hard is it to understand basic kernel development rules? 
> 
> Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People 
> can hide behind all the "staging" and "I asked for it" things they like, 
> but that doesn't change simple basic facts: distros should make sure 
> drivers get merged up-stream, and people end up depending on them.

It takes a long time to work out exactly what kind of userspace 
interface you need when the hardware you're dealing with is entirely 
undocumented. The reason it's been shipped in Fedora is that it needs to 
be in front of actual users in order to get any testing at all, and we 
have the manpower to ensure that the dependencies are consistent. But 
most nouveau development isn't handled inside Red Hat, and we're in no 
position to dictate terms to the volunteers who are spending their spare 
time trying to write a useful driver.

> Btw, I'm hoping some of this pain goes away for me, because I expect to 
> get rid of the shitty nVidia card reasonably soon. The fact that my main 
> box had a power supply that literally _required_ a power-sucking-piece- 
> of-sh*t-graphics card has been painful to me.

You'd have hit similar issues if you'd been using Radeon KMS over the 
past couple of releases...

> But none of that changes my basic objections. I didn't ask for nouveau to 
> be merged as staging - I asked it to be merged because a major distro uses 
> it.

It was merged as staging because the interface is unstable, which is 
consistent with staging's Kconfig:

"Please note that these drivers are under heavy development, may or may 
not work, and may contain userspace interfaces that most likely will be 
changed in the near future."

If you'd made it clear that you wanted the interface to be stable 
before it got merged, I suspect that it simply wouldn't have been merged 
until the interface was stable.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
> 
> If you'd made it clear that you wanted the interface to be stable 
> before it got merged, I suspect that it simply wouldn't have been merged 
> until the interface was stable.

What kind of excuse is that? It's "we did bad things, but if we didn't do 
those bad things, we'd have done _other_ bad things"?

Two wrong choices don't make a right.

Nobody has even answered me whether this is _forwards_compatible. It 
clearly isn't backwards-compatible. IOW, is there _any_ way to move 
back-and-forth over that commit, even if I can find a new libdrm?

IOW, we know we have a problem here. But what's the solution? I know I can 
revert it (I tried, I'm running that kernel now, nouveau works). That's 
not a good solution, I know. But can you offer me a _better_ one? One that 
doesn't involve "upgrade all the way to rawhide, and lose the ability to 
bisect anything, or run plain 2.6.33".

So yes, I'm complaining. But I at least have mentioned one solution. You, 
in contast, are just making excuses with no solutions.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
> 
> If you'd made it clear that you wanted the interface to be stable 
> before it got merged, I suspect that it simply wouldn't have been merged 
> until the interface was stable.

What kind of excuse is that? It's "we did bad things, but if we didn't do 
those bad things, we'd have done _other_ bad things"?

Two wrong choices don't make a right.

Nobody has even answered me whether this is _forwards_compatible. It 
clearly isn't backwards-compatible. IOW, is there _any_ way to move 
back-and-forth over that commit, even if I can find a new libdrm?

IOW, we know we have a problem here. But what's the solution? I know I can 
revert it (I tried, I'm running that kernel now, nouveau works). That's 
not a good solution, I know. But can you offer me a _better_ one? One that 
doesn't involve "upgrade all the way to rawhide, and lose the ability to 
bisect anything, or run plain 2.6.33".

So yes, I'm complaining. But I at least have mentioned one solution. You, 
in contast, are just making excuses with no solutions.

			Linus

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 11:14:11AM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
> > 
> > If you'd made it clear that you wanted the interface to be stable 
> > before it got merged, I suspect that it simply wouldn't have been merged 
> > until the interface was stable.
> 
> What kind of excuse is that? It's "we did bad things, but if we didn't do 
> those bad things, we'd have done _other_ bad things"?
> 
> Two wrong choices don't make a right.
> 
> Nobody has even answered me whether this is _forwards_compatible. It 
> clearly isn't backwards-compatible. IOW, is there _any_ way to move 
> back-and-forth over that commit, even if I can find a new libdrm?

Judging by 
http://cgit.freedesktop.org/mesa/drm/commit/?id=b496c63143e9a4ca02011582329bce2df99d9b7c 
, no. And if you're unhappy with that, don't use the driver. You enabled 
an option that's *documented* as potentially breaking between kernel 
releases, having been told that this was likely to happen, and now 
you're complaining?

> IOW, we know we have a problem here. But what's the solution? I know I can 
> revert it (I tried, I'm running that kernel now, nouveau works). That's 
> not a good solution, I know. But can you offer me a _better_ one? One that 
> doesn't involve "upgrade all the way to rawhide, and lose the ability to 
> bisect anything, or run plain 2.6.33".

Running -nv ought to be an option.

> So yes, I'm complaining. But I at least have mentioned one solution. You, 
> in contast, are just making excuses with no solutions.

You're asking volunteers who didn't ask for their driver to be merged to 
perform more work in order to support users they didn't ask for.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
> 
> You're asking volunteers who didn't ask for their driver to be merged to 
> perform more work in order to support users they didn't ask for.

And _you_ are making excuses for BAD TECHNICAL DECISIONS!

Come on! How hard is it to admit that that the change was done badly? How 
hard is it to admit that this isn't a political issue, it's about pure 
technology. There are good ways of doing things, and there are way sof 
doing things badly. 

I'm pointing to real _technical_ problems with how this was done. I'm 
talking about how this hurts testing, and how we've been able to handle 
things in other cases (with versioning, and forwards- or backwards- 
compatibility) without this kind of crap.

If you can't handle backwards compatibility - fine. But I get the very 
strong feeling that people didn't even _think_ about trying to be at least 
forwards-compatible, and I'm getting the _very_ strong feeling that you 
are making excuses for bad technology.

Is there some model of versioning inside X _except_ for the "it won't 
work" kind of thing? Can we fix this going forward, so that you can have 
_real_ versioning (ie multiple installed versions of a libdrm, the way you 
can have concurrently multiple installed versions of glibc?)

IOW, we have a real technical problem here. Are you just going to continue 
to make excuses about it?

			Linus

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 11:41:22AM -0800, Linus Torvalds wrote:

> Is there some model of versioning inside X _except_ for the "it won't 
> work" kind of thing? Can we fix this going forward, so that you can have 
> _real_ versioning (ie multiple installed versions of a libdrm, the way you 
> can have concurrently multiple installed versions of glibc?)

There isn't. I don't think there's any intrinsic difficulty in doing so, 
other than the buildsystems and X's own unstable driver API.

> IOW, we have a real technical problem here. Are you just going to continue 
> to make excuses about it?

I'm not questioning the fact that it would be preferable to provide 
compatibility. But that compatibility doesn't come for free - someone 
has to implement it, and when your developer base is almost entirely 
made up of people who are doing this because they find it fun and 
interesting rather than because they're paid to, who's going to do it 
and what functionality is going to be delayed as a result?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 11:41:22AM -0800, Linus Torvalds wrote:

> Is there some model of versioning inside X _except_ for the "it won't 
> work" kind of thing? Can we fix this going forward, so that you can have 
> _real_ versioning (ie multiple installed versions of a libdrm, the way you 
> can have concurrently multiple installed versions of glibc?)

There isn't. I don't think there's any intrinsic difficulty in doing so, 
other than the buildsystems and X's own unstable driver API.

> IOW, we have a real technical problem here. Are you just going to continue 
> to make excuses about it?

I'm not questioning the fact that it would be preferable to provide 
compatibility. But that compatibility doesn't come for free - someone 
has to implement it, and when your developer base is almost entirely 
made up of people who are doing this because they find it fun and 
interesting rather than because they're paid to, who's going to do it 
and what functionality is going to be delayed as a result?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
> 
> > IOW, we have a real technical problem here. Are you just going to continue 
> > to make excuses about it?
> 
> I'm not questioning the fact that it would be preferable to provide 
> compatibility. But that compatibility doesn't come for free - someone 
> has to implement it, and when your developer base is almost entirely 
> made up of people who are doing this because they find it fun and 
> interesting rather than because they're paid to, who's going to do it 
> and what functionality is going to be delayed as a result?

The thing is, I violently disagree with your basic premise.

The way things are done now, that developer base actually just makes 
things _harder_ for themselves. They may not be aware that they do so, and 
they may _think_ that it's easier to just ignore versioning, but they are 
wrong.

And I say that from personal experience. Doing incompatible changes in any 
code base makes everything harder. It results in users staying on old 
versions that you _know_ you don't want to support, but because of the 
incompatible change, they can't sanely upgrade. 

Seriously. 

So I bet we could do that "wrapper nouveau.so" that literally just does 
the "get version, and dlopen the _real_ nouveau-<version>.so".

Quite frankly, I don't know the XAA interfaces (or whatever they are in X 
these days), but somebody who does know them should be able to cook up 
such a wrapper in five minutes (and then spend a day testing it because of 
some silly bug, but whatever..)

Do you seriously think that that wouldn't make life easier EVEN FOR THOSE 
DEVELOPERS that you claim to speak up for?

			Linus

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 12:07:19PM -0800, Linus Torvalds wrote:

> Do you seriously think that that wouldn't make life easier EVEN FOR THOSE 
> DEVELOPERS that you claim to speak up for?

Compared to dealing with Mesa's build system? I honestly wouldn't want 
to say. But you're right that pushing the job of supporting multiple 
interfaces out to userspace would be much more tractable here.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 12:07:19PM -0800, Linus Torvalds wrote:

> Do you seriously think that that wouldn't make life easier EVEN FOR THOSE 
> DEVELOPERS that you claim to speak up for?

Compared to dealing with Mesa's build system? I honestly wouldn't want 
to say. But you're right that pushing the job of supporting multiple 
interfaces out to userspace would be much more tractable here.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] drm request 3

[Stephane Marchesin]

On Thu, Mar 4, 2010 at 12:07, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
>>
>> > IOW, we have a real technical problem here. Are you just going to continue
>> > to make excuses about it?
>>
>> I'm not questioning the fact that it would be preferable to provide
>> compatibility. But that compatibility doesn't come for free - someone
>> has to implement it, and when your developer base is almost entirely
>> made up of people who are doing this because they find it fun and
>> interesting rather than because they're paid to, who's going to do it
>> and what functionality is going to be delayed as a result?
>
> The thing is, I violently disagree with your basic premise.
>
> The way things are done now, that developer base actually just makes
> things _harder_ for themselves. They may not be aware that they do so, and
> they may _think_ that it's easier to just ignore versioning, but they are
> wrong.
>
> And I say that from personal experience. Doing incompatible changes in any
> code base makes everything harder. It results in users staying on old
> versions that you _know_ you don't want to support, but because of the
> incompatible change, they can't sanely upgrade.
>
> Seriously.
>
> So I bet we could do that "wrapper nouveau.so" that literally just does
> the "get version, and dlopen the _real_ nouveau-<version>.so".
>
> Quite frankly, I don't know the XAA interfaces (or whatever they are in X
> these days), but somebody who does know them should be able to cook up
> such a wrapper in five minutes (and then spend a day testing it because of
> some silly bug, but whatever..)
>
> Do you seriously think that that wouldn't make life easier EVEN FOR THOSE
> DEVELOPERS that you claim to speak up for?
>

No. It makes our lives much more complicated.

I've worked on the radeon driver before and about half my time was
spent just checking compatibility with multiple kernel/user space
combinations. You have to handle all possible combinations of
DRM+DDX+Mesa drivers, and that gets hairy real quick. Then for nouveau
I decided not to bother until interfaces were stable enough, and I
think all developers agree on that.

I suggest you think about the "do not break user space interfaces"
principle from a graphics developer point of view and what that means
for the user space code. For example, you could take a look at the
radeon DDX or Mesa drivers, which do implement compatibility. In the
long run this leads to little gems like this:
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r200/r200_state.c#n2148
Obviously even though there is some form of compatibility, not all
user space/kernel combinations are tested.

In short, the "don't break user space interfaces" principle is making
user space code quality worse for everyone. And it makes our lives as
graphics developers pretty miserable actually

Stephane

Re: [git pull] drm request 3

[Stephane Marchesin]

On Thu, Mar 4, 2010 at 12:07, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
>>
>> > IOW, we have a real technical problem here. Are you just going to continue
>> > to make excuses about it?
>>
>> I'm not questioning the fact that it would be preferable to provide
>> compatibility. But that compatibility doesn't come for free - someone
>> has to implement it, and when your developer base is almost entirely
>> made up of people who are doing this because they find it fun and
>> interesting rather than because they're paid to, who's going to do it
>> and what functionality is going to be delayed as a result?
>
> The thing is, I violently disagree with your basic premise.
>
> The way things are done now, that developer base actually just makes
> things _harder_ for themselves. They may not be aware that they do so, and
> they may _think_ that it's easier to just ignore versioning, but they are
> wrong.
>
> And I say that from personal experience. Doing incompatible changes in any
> code base makes everything harder. It results in users staying on old
> versions that you _know_ you don't want to support, but because of the
> incompatible change, they can't sanely upgrade.
>
> Seriously.
>
> So I bet we could do that "wrapper nouveau.so" that literally just does
> the "get version, and dlopen the _real_ nouveau-<version>.so".
>
> Quite frankly, I don't know the XAA interfaces (or whatever they are in X
> these days), but somebody who does know them should be able to cook up
> such a wrapper in five minutes (and then spend a day testing it because of
> some silly bug, but whatever..)
>
> Do you seriously think that that wouldn't make life easier EVEN FOR THOSE
> DEVELOPERS that you claim to speak up for?
>

No. It makes our lives much more complicated.

I've worked on the radeon driver before and about half my time was
spent just checking compatibility with multiple kernel/user space
combinations. You have to handle all possible combinations of
DRM+DDX+Mesa drivers, and that gets hairy real quick. Then for nouveau
I decided not to bother until interfaces were stable enough, and I
think all developers agree on that.

I suggest you think about the "do not break user space interfaces"
principle from a graphics developer point of view and what that means
for the user space code. For example, you could take a look at the
radeon DDX or Mesa drivers, which do implement compatibility. In the
long run this leads to little gems like this:
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r200/r200_state.c#n2148
Obviously even though there is some form of compatibility, not all
user space/kernel combinations are tested.

In short, the "don't break user space interfaces" principle is making
user space code quality worse for everyone. And it makes our lives as
graphics developers pretty miserable actually

Stephane

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Stephane Marchesin wrote:
> 
> In short, the "don't break user space interfaces" principle is making
> user space code quality worse for everyone. And it makes our lives as
> graphics developers pretty miserable actually

And _my_ point is that if you did a half-way decent job on versioning, you 
wouldn't be in the crappy situation you are now.

For chissake, the DRM versioning model is a total disaster. The reason you 
can never ever break user space interfaces is exactly because when you 
break them, X stops working.

What I suggested is to _keep_ a working model across different versions, 
so that you can get out of the rat-hole you are in now (and the rat-hole 
you put your users into, and the distributions).

It's simply _not_ acceptable to tie the X server and the kernel version so 
tightly together as the crazy DRM model does right now. It's not all that 
different from us requiring people to install a new glibc every once in a 
while, just because we added a new filesystem. Everybody understands that 
that would be totally insane.

Why does the X community not understand simple library versioning?

			Linus

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 8:54 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Stephane Marchesin wrote:
>>
>> In short, the "don't break user space interfaces" principle is making
>> user space code quality worse for everyone. And it makes our lives as
>> graphics developers pretty miserable actually
>
> And _my_ point is that if you did a half-way decent job on versioning, you
> wouldn't be in the crappy situation you are now.
>
> For chissake, the DRM versioning model is a total disaster. The reason you
> can never ever break user space interfaces is exactly because when you
> break them, X stops working.

Stop aligning DRM versioning with nouveau versioning. This isn't a generic
problem with DRM, we've supported versioning interfaces for years and
have broken them maybe once.

> What I suggested is to _keep_ a working model across different versions,
> so that you can get out of the rat-hole you are in now (and the rat-hole
> you put your users into, and the distributions).
>
> It's simply _not_ acceptable to tie the X server and the kernel version so
> tightly together as the crazy DRM model does right now. It's not all that
> different from us requiring people to install a new glibc every once in a
> while, just because we added a new filesystem. Everybody understands that
> that would be totally insane.
>
> Why does the X community not understand simple library versioning?

Its nouveau project not X not DRM, stop generalising the situation.

Dave.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> Its nouveau project not X not DRM, stop generalising the situation.

Is it really just nouveau? I've not looked, but I bet the intel driver and 
the radeon driver have _exactly_ the same "oh, I'm the wrong version, I 
will now kill myself" behavior.

I certainly seem to remember some similar issues with the intel driver 
long long ago.

What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? 
Would it try to handle it gracefully? Or are we in the same situation that 
the intel driver guys can never fix anything fundamental without doing a 
whole flag day?

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> Its nouveau project not X not DRM, stop generalising the situation.

Is it really just nouveau? I've not looked, but I bet the intel driver and 
the radeon driver have _exactly_ the same "oh, I'm the wrong version, I 
will now kill myself" behavior.

I certainly seem to remember some similar issues with the intel driver 
long long ago.

What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? 
Would it try to handle it gracefully? Or are we in the same situation that 
the intel driver guys can never fix anything fundamental without doing a 
whole flag day?

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Michel Dänzer]

On Thu, 2010-03-04 at 15:19 -0800, Linus Torvalds wrote: 
> 
> What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? 

Nothing. :) Only the major version is supposed to signify outright
incompatibility, the minor version signifies backwards compatibility
within the same major version, and the patchlevel has no impact on the
interface. All the other drivers are basically following this, only
nouveau is abusing the patchlevel as a major version for reasons beyond
me.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [git pull] drm request 3

[Michel Dänzer]

On Thu, 2010-03-04 at 15:19 -0800, Linus Torvalds wrote: 
> 
> What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? 

Nothing. :) Only the major version is supposed to signify outright
incompatibility, the minor version signifies backwards compatibility
within the same major version, and the patchlevel has no impact on the
interface. All the other drivers are basically following this, only
nouveau is abusing the patchlevel as a major version for reasons beyond
me.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> Is it really just nouveau? I've not looked, but I bet the intel driver and 
> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I 
> will now kill myself" behavior.

Ok, I cloned the drm tree just to see, and it does seem like it's just 
nouveau that does that whole thing. At least from a quick grep of 
drmGetVersion() calls.

> I certainly seem to remember some similar issues with the intel driver 
> long long ago.

.. but Jesse tells me that it's using feature masks etc, so maybe my 
recollection is about unrelated issues.

So yeah, nouveau seems to "special". Although somebody already said that 
if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon 
driver just doesn't check the version number, and fails in different ways.

		Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> Is it really just nouveau? I've not looked, but I bet the intel driver and 
> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I 
> will now kill myself" behavior.

Ok, I cloned the drm tree just to see, and it does seem like it's just 
nouveau that does that whole thing. At least from a quick grep of 
drmGetVersion() calls.

> I certainly seem to remember some similar issues with the intel driver 
> long long ago.

.. but Jesse tells me that it's using feature masks etc, so maybe my 
recollection is about unrelated issues.

So yeah, nouveau seems to "special". Although somebody already said that 
if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon 
driver just doesn't check the version number, and fails in different ways.

		Linus

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Linus Torvalds wrote:
>>
>> Is it really just nouveau? I've not looked, but I bet the intel driver and
>> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
>> will now kill myself" behavior.
>
> Ok, I cloned the drm tree just to see, and it does seem like it's just
> nouveau that does that whole thing. At least from a quick grep of
> drmGetVersion() calls.
>
>> I certainly seem to remember some similar issues with the intel driver
>> long long ago.
>
> .. but Jesse tells me that it's using feature masks etc, so maybe my
> recollection is about unrelated issues.
>
> So yeah, nouveau seems to "special". Although somebody already said that
> if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon
> driver just doesn't check the version number, and fails in different ways.
>

As I mentioned earlier we had one issue with i810 about 7-8 years ago, before
I was here, someone changed the i810_drm.h api incompatibly in XFree86.
This was one of the things that led to having a proper policy.

For radeon while we were developing the KMS feature in staging we
changed the API
once or twice, while we were developing KMS in Fedora we changed it at least
4 times, we shipped Intel KMS in F9 with a completly different API and
just dealt
with it, since upstreaming changed the API completely.

The staging API changes were mostly to fix things that userspace did
that made it
possible to trample over other X users memory. This meant you had to bump the
userspace that was doing the evil thing by mistake.

Once we removed KMS from staging, we stabilised all APIs and behaviour
(its not just the API, internal command stream checking for security issues).

Since then we made one change to the CS behaviour in a backwards compatible
manner so that old userspaces wouldn't die, but you couldn't abuse the
hole they had relied on.

I'm not saying it doesn't happen in other drivers from time to time,
but when it does
its treated as regression, for nouveau and STAGING that isn't what the Nouveau
project (which Stephane mostly speaks for) seems to want at this stage.

Dave.

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Linus Torvalds wrote:
>>
>> Is it really just nouveau? I've not looked, but I bet the intel driver and
>> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
>> will now kill myself" behavior.
>
> Ok, I cloned the drm tree just to see, and it does seem like it's just
> nouveau that does that whole thing. At least from a quick grep of
> drmGetVersion() calls.
>
>> I certainly seem to remember some similar issues with the intel driver
>> long long ago.
>
> .. but Jesse tells me that it's using feature masks etc, so maybe my
> recollection is about unrelated issues.
>
> So yeah, nouveau seems to "special". Although somebody already said that
> if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon
> driver just doesn't check the version number, and fails in different ways.
>

As I mentioned earlier we had one issue with i810 about 7-8 years ago, before
I was here, someone changed the i810_drm.h api incompatibly in XFree86.
This was one of the things that led to having a proper policy.

For radeon while we were developing the KMS feature in staging we
changed the API
once or twice, while we were developing KMS in Fedora we changed it at least
4 times, we shipped Intel KMS in F9 with a completly different API and
just dealt
with it, since upstreaming changed the API completely.

The staging API changes were mostly to fix things that userspace did
that made it
possible to trample over other X users memory. This meant you had to bump the
userspace that was doing the evil thing by mistake.

Once we removed KMS from staging, we stabilised all APIs and behaviour
(its not just the API, internal command stream checking for security issues).

Since then we made one change to the CS behaviour in a backwards compatible
manner so that old userspaces wouldn't die, but you couldn't abuse the
hole they had relied on.

I'm not saying it doesn't happen in other drivers from time to time,
but when it does
its treated as regression, for nouveau and STAGING that isn't what the Nouveau
project (which Stephane mostly speaks for) seems to want at this stage.

Dave.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> I'm not saying it doesn't happen in other drivers from time to time, but 
> when it does its treated as regression, for nouveau and STAGING that 
> isn't what the Nouveau project (which Stephane mostly speaks for) seems 
> to want at this stage.

The problem with "at this stage" is that the stage has apparently been 
on-going for several years. 

Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
it to be a _major_ pain to have that whole hardcoded "X and kernel must 
always change in lockstep".

And the sad part is, it would be so nice if the X server would just dlopen 
the right thing automatically, so that the low-level driver wouldn't even 
need to care. It already does the whole "discover which driver to load" 
part, wouldn't it be nice if that code had automatic versioning too, and 
then a low-level driver really wouldn't have to care, everything would 
automatically do the right thing just when the version changes.

Of course, the distro would still have to make all the different versions 
of libdrm available to users, but now updating one wouldn't screw over the 
others. So if you had a known-good setup with nouveau-0.0.15, you could 
install a nouveau-0.0.16 thing and _know_ that it won't affect that 
previous install at all.

And yeah, I realize that those version numbers are "wrong". Normal library 
versioning rules about patchlevel not changing semantics are obviously 
broken here. But maybe the rules could even try to first start with the 
exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" 
load, then a "driver-x.so" load and finally a "driver.so" load.

But I guess that nothing even does that drmGetVersion() until the nouveau 
driver has already been loaded. Which kind of forces the low-level drivers 
to do any such versioning on their own. 

But wouldn't it be nice if something like this was done at a higher level, 
so that the drivers really wouldn't even need to care?

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> I'm not saying it doesn't happen in other drivers from time to time, but 
> when it does its treated as regression, for nouveau and STAGING that 
> isn't what the Nouveau project (which Stephane mostly speaks for) seems 
> to want at this stage.

The problem with "at this stage" is that the stage has apparently been 
on-going for several years. 

Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
it to be a _major_ pain to have that whole hardcoded "X and kernel must 
always change in lockstep".

And the sad part is, it would be so nice if the X server would just dlopen 
the right thing automatically, so that the low-level driver wouldn't even 
need to care. It already does the whole "discover which driver to load" 
part, wouldn't it be nice if that code had automatic versioning too, and 
then a low-level driver really wouldn't have to care, everything would 
automatically do the right thing just when the version changes.

Of course, the distro would still have to make all the different versions 
of libdrm available to users, but now updating one wouldn't screw over the 
others. So if you had a known-good setup with nouveau-0.0.15, you could 
install a nouveau-0.0.16 thing and _know_ that it won't affect that 
previous install at all.

And yeah, I realize that those version numbers are "wrong". Normal library 
versioning rules about patchlevel not changing semantics are obviously 
broken here. But maybe the rules could even try to first start with the 
exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" 
load, then a "driver-x.so" load and finally a "driver.so" load.

But I guess that nothing even does that drmGetVersion() until the nouveau 
driver has already been loaded. Which kind of forces the low-level drivers 
to do any such versioning on their own. 

But wouldn't it be nice if something like this was done at a higher level, 
so that the drivers really wouldn't even need to care?

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Ed Tomlinson]

On Thursday 04 March 2010 18:53:32 Linus Torvalds wrote:
> 
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > I'm not saying it doesn't happen in other drivers from time to time, but 
> > when it does its treated as regression, for nouveau and STAGING that 
> > isn't what the Nouveau project (which Stephane mostly speaks for) seems 
> > to want at this stage.
> 
> The problem with "at this stage" is that the stage has apparently been 
> on-going for several years. 
> 
> Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
> you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
> it to be a _major_ pain to have that whole hardcoded "X and kernel must 
> always change in lockstep".
> 
> And the sad part is, it would be so nice if the X server would just dlopen 
> the right thing automatically, so that the low-level driver wouldn't even 
> need to care. It already does the whole "discover which driver to load" 
> part, wouldn't it be nice if that code had automatic versioning too, and 
> then a low-level driver really wouldn't have to care, everything would 
> automatically do the right thing just when the version changes.
> 
> Of course, the distro would still have to make all the different versions 
> of libdrm available to users, but now updating one wouldn't screw over the 
> others. So if you had a known-good setup with nouveau-0.0.15, you could 
> install a nouveau-0.0.16 thing and _know_ that it won't affect that 
> previous install at all.
> 
> And yeah, I realize that those version numbers are "wrong". Normal library 
> versioning rules about patchlevel not changing semantics are obviously 
> broken here. But maybe the rules could even try to first start with the 
> exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" 
> load, then a "driver-x.so" load and finally a "driver.so" load.
> 
> But I guess that nothing even does that drmGetVersion() until the nouveau 
> driver has already been loaded. Which kind of forces the low-level drivers 
> to do any such versioning on their own. 
> 
> But wouldn't it be nice if something like this was done at a higher level, 
> so that the drivers really wouldn't even need to care?

Why not support a _minimal_ ABI that will always let X start with nouveau?
Having X working does not mean that all forms of acceleration have to 
work too.  If X starts, even if is slow, users can easily check logs which
should have a message saying 'ABI change - upgrade your ...'.

Thoughts?
Ed Tomlinson

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Ed Tomlinson]

On Thursday 04 March 2010 18:53:32 Linus Torvalds wrote:
> 
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > I'm not saying it doesn't happen in other drivers from time to time, but 
> > when it does its treated as regression, for nouveau and STAGING that 
> > isn't what the Nouveau project (which Stephane mostly speaks for) seems 
> > to want at this stage.
> 
> The problem with "at this stage" is that the stage has apparently been 
> on-going for several years. 
> 
> Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
> you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
> it to be a _major_ pain to have that whole hardcoded "X and kernel must 
> always change in lockstep".
> 
> And the sad part is, it would be so nice if the X server would just dlopen 
> the right thing automatically, so that the low-level driver wouldn't even 
> need to care. It already does the whole "discover which driver to load" 
> part, wouldn't it be nice if that code had automatic versioning too, and 
> then a low-level driver really wouldn't have to care, everything would 
> automatically do the right thing just when the version changes.
> 
> Of course, the distro would still have to make all the different versions 
> of libdrm available to users, but now updating one wouldn't screw over the 
> others. So if you had a known-good setup with nouveau-0.0.15, you could 
> install a nouveau-0.0.16 thing and _know_ that it won't affect that 
> previous install at all.
> 
> And yeah, I realize that those version numbers are "wrong". Normal library 
> versioning rules about patchlevel not changing semantics are obviously 
> broken here. But maybe the rules could even try to first start with the 
> exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" 
> load, then a "driver-x.so" load and finally a "driver.so" load.
> 
> But I guess that nothing even does that drmGetVersion() until the nouveau 
> driver has already been loaded. Which kind of forces the low-level drivers 
> to do any such versioning on their own. 
> 
> But wouldn't it be nice if something like this was done at a higher level, 
> so that the drivers really wouldn't even need to care?

Why not support a _minimal_ ABI that will always let X start with nouveau?
Having X working does not mean that all forms of acceleration have to 
work too.  If X starts, even if is slow, users can easily check logs which
should have a message saying 'ABI change - upgrade your ...'.

Thoughts?
Ed Tomlinson

Re: [git pull] drm request 3

[Kyle McMartin]

On Thu, Mar 04, 2010 at 03:53:32PM -0800, Linus Torvalds wrote:
> Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
> you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
> it to be a _major_ pain to have that whole hardcoded "X and kernel must 
> always change in lockstep".
> 

Frankly, I completely agree with you. This kind of shit makes it
extremely difficult for users to run, say, 2.6.33 on F-12 without us
doing a backport. Thankfully Ben takes care of that for me, usually,
by keeping nouveau up to date with upstream in the various Fedora's, but
it's still a set of shackles that I'm pretty sure none of us want. (Not
only that, but it means if you update, you may need to do a full reboot
before you can start X again, which is pretty disappointing.)

For example, right now, Fedora 11's 2.6.30 kernel has nouveau 12, with
nouveau 12 userspace. For Fedora 11's 2.6.32 kernel, instead of updating
the userspace stuff, I forward ported the old DRM entirely, bringing
with it whatever bugs it had, simply because DRM is such a nightmare.

It's already impossible to run Fedora 13's 2.6.33 kernel on 12 since Ben
put the nouveau git changes for the new ABI in there already. So we'll
have to drop those from the F-13 2.6.33 for the F-12 2.6.33...

This situation /sucks/ for users. Personally, I think we committed to a
stable update ABI when nouveau got a MODULE_DEVICE_TABLE and started
binding by default. But hey, I'm just the kernel maintainer, and I
didn't pipe up then, which was my mistake. If we're going to ram
something at users by default, we should at least try to guarantee that
they'll be able to restart X and have things continue to work.

That said, whether you think it's a lame excuse or not, staging was
clearly labelled as buyer beware.

I'm personally sorry that you got burned by nouveau on Fedora both these
times, but we're really just trying to help, and not hinder things.
(Maybe I should commit a patch to rip out the module aliases for
nouveau, but I suspect I'd have more people screaming for blood that
way. Sigh.)

regards, Kyle

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Kyle McMartin]

On Thu, Mar 04, 2010 at 03:53:32PM -0800, Linus Torvalds wrote:
> Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
> you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
> it to be a _major_ pain to have that whole hardcoded "X and kernel must 
> always change in lockstep".
> 

Frankly, I completely agree with you. This kind of shit makes it
extremely difficult for users to run, say, 2.6.33 on F-12 without us
doing a backport. Thankfully Ben takes care of that for me, usually,
by keeping nouveau up to date with upstream in the various Fedora's, but
it's still a set of shackles that I'm pretty sure none of us want. (Not
only that, but it means if you update, you may need to do a full reboot
before you can start X again, which is pretty disappointing.)

For example, right now, Fedora 11's 2.6.30 kernel has nouveau 12, with
nouveau 12 userspace. For Fedora 11's 2.6.32 kernel, instead of updating
the userspace stuff, I forward ported the old DRM entirely, bringing
with it whatever bugs it had, simply because DRM is such a nightmare.

It's already impossible to run Fedora 13's 2.6.33 kernel on 12 since Ben
put the nouveau git changes for the new ABI in there already. So we'll
have to drop those from the F-13 2.6.33 for the F-12 2.6.33...

This situation /sucks/ for users. Personally, I think we committed to a
stable update ABI when nouveau got a MODULE_DEVICE_TABLE and started
binding by default. But hey, I'm just the kernel maintainer, and I
didn't pipe up then, which was my mistake. If we're going to ram
something at users by default, we should at least try to guarantee that
they'll be able to restart X and have things continue to work.

That said, whether you think it's a lame excuse or not, staging was
clearly labelled as buyer beware.

I'm personally sorry that you got burned by nouveau on Fedora both these
times, but we're really just trying to help, and not hinder things.
(Maybe I should commit a patch to rip out the module aliases for
nouveau, but I suspect I'd have more people screaming for blood that
way. Sigh.)

regards, Kyle

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> Its nouveau project not X not DRM, stop generalising the situation.
>
> Is it really just nouveau? I've not looked, but I bet the intel driver and
> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
> will now kill myself" behavior.
>
> I certainly seem to remember some similar issues with the intel driver
> long long ago.
>
> What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver?
> Would it try to handle it gracefully? Or are we in the same situation that
> the intel driver guys can never fix anything fundamental without doing a
> whole flag day?

Patchlevel never changed in intel, but if you changed the MINOR back to 1 then
shit would break, exactly like any userspace shared library.

It'll fall over in userspace, because userspace has minimum versioning
requirements
same as if you change all the udev interfaces back 6 years nothing
boots anymore,
or you remove the wireless interfaces or xattrs from ext3. I thin

The standard DRM versioning interface is

MAJOR - don't change this ever except for second coming. Radeon KMS
is the only driver to have bumped this interface version, and we still
support the 1.0.0
if you turn off modesetting. Mach64 bumped it once but we never
upstreamed either
version.

MINOR - optionally bump this when you add a new API, new feature, new chipset,
now we generally just add a new GETPARAM, which the userspace can check for and
do the correct thing.

PATCHLEVEL - ideally bump this for small non-user visible changes, in practice
nobody touches this ever. Nouveau have "abused" this to provide pre
1.0.0 version
number, when they release version 1.0.0 they are expected to follow standard drm
versioning rules.

Now just like in userspace, if you add features to the minor number,
userspace driver
will come to depend on these features being there. If you dropped the
intel minor
to 1.1 it would crap itself all over the place, same as if you
starting trying to ship glibc2.0
on a glibc2.1 distro. We have never worried about new userspaces
running on really
old kernels, because generally 3-4 years has been good enough for distros.

This is a nouveau problem not a drm problem.

Dave.

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> Its nouveau project not X not DRM, stop generalising the situation.
>
> Is it really just nouveau? I've not looked, but I bet the intel driver and
> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
> will now kill myself" behavior.
>
> I certainly seem to remember some similar issues with the intel driver
> long long ago.
>
> What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver?
> Would it try to handle it gracefully? Or are we in the same situation that
> the intel driver guys can never fix anything fundamental without doing a
> whole flag day?

Patchlevel never changed in intel, but if you changed the MINOR back to 1 then
shit would break, exactly like any userspace shared library.

It'll fall over in userspace, because userspace has minimum versioning
requirements
same as if you change all the udev interfaces back 6 years nothing
boots anymore,
or you remove the wireless interfaces or xattrs from ext3. I thin

The standard DRM versioning interface is

MAJOR - don't change this ever except for second coming. Radeon KMS
is the only driver to have bumped this interface version, and we still
support the 1.0.0
if you turn off modesetting. Mach64 bumped it once but we never
upstreamed either
version.

MINOR - optionally bump this when you add a new API, new feature, new chipset,
now we generally just add a new GETPARAM, which the userspace can check for and
do the correct thing.

PATCHLEVEL - ideally bump this for small non-user visible changes, in practice
nobody touches this ever. Nouveau have "abused" this to provide pre
1.0.0 version
number, when they release version 1.0.0 they are expected to follow standard drm
versioning rules.

Now just like in userspace, if you add features to the minor number,
userspace driver
will come to depend on these features being there. If you dropped the
intel minor
to 1.1 it would crap itself all over the place, same as if you
starting trying to ship glibc2.0
on a glibc2.1 distro. We have never worried about new userspaces
running on really
old kernels, because generally 3-4 years has been good enough for distros.

This is a nouveau problem not a drm problem.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Dave Airlie]

On Fri, Mar 5, 2010 at 8:54 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Stephane Marchesin wrote:
>>
>> In short, the "don't break user space interfaces" principle is making
>> user space code quality worse for everyone. And it makes our lives as
>> graphics developers pretty miserable actually
>
> And _my_ point is that if you did a half-way decent job on versioning, you
> wouldn't be in the crappy situation you are now.
>
> For chissake, the DRM versioning model is a total disaster. The reason you
> can never ever break user space interfaces is exactly because when you
> break them, X stops working.

Stop aligning DRM versioning with nouveau versioning. This isn't a generic
problem with DRM, we've supported versioning interfaces for years and
have broken them maybe once.

> What I suggested is to _keep_ a working model across different versions,
> so that you can get out of the rat-hole you are in now (and the rat-hole
> you put your users into, and the distributions).
>
> It's simply _not_ acceptable to tie the X server and the kernel version so
> tightly together as the crazy DRM model does right now. It's not all that
> different from us requiring people to install a new glibc every once in a
> while, just because we added a new filesystem. Everybody understands that
> that would be totally insane.
>
> Why does the X community not understand simple library versioning?

Its nouveau project not X not DRM, stop generalising the situation.

Dave.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 14:54:03 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Stephane Marchesin wrote:
> > 
> > In short, the "don't break user space interfaces" principle is making
> > user space code quality worse for everyone. And it makes our lives as
> > graphics developers pretty miserable actually
> 
> And _my_ point is that if you did a half-way decent job on versioning, you 
> wouldn't be in the crappy situation you are now.
> 
> For chissake, the DRM versioning model is a total disaster. The reason you 
> can never ever break user space interfaces is exactly because when you 
> break them, X stops working.
> 
> What I suggested is to _keep_ a working model across different versions, 
> so that you can get out of the rat-hole you are in now (and the rat-hole 
> you put your users into, and the distributions).
> 
> It's simply _not_ acceptable to tie the X server and the kernel version so 
> tightly together as the crazy DRM model does right now. It's not all that 
> different from us requiring people to install a new glibc every once in a 
> while, just because we added a new filesystem. Everybody understands that 
> that would be totally insane.
> 
> Why does the X community not understand simple library versioning?

We use versioning on the Intel side, but in the form of feature flags
as new things are added (we've had a handful since GEM was added in
2.6.28).  It's a pain to handle the various code paths, but no more so
than having lots of separate library versions to support.  That would
be nice from one perspective, but it would only save work if we
abandoned the old versions quickly and kept a big shared component
between library versions.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 14:54:03 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Stephane Marchesin wrote:
> > 
> > In short, the "don't break user space interfaces" principle is making
> > user space code quality worse for everyone. And it makes our lives as
> > graphics developers pretty miserable actually
> 
> And _my_ point is that if you did a half-way decent job on versioning, you 
> wouldn't be in the crappy situation you are now.
> 
> For chissake, the DRM versioning model is a total disaster. The reason you 
> can never ever break user space interfaces is exactly because when you 
> break them, X stops working.
> 
> What I suggested is to _keep_ a working model across different versions, 
> so that you can get out of the rat-hole you are in now (and the rat-hole 
> you put your users into, and the distributions).
> 
> It's simply _not_ acceptable to tie the X server and the kernel version so 
> tightly together as the crazy DRM model does right now. It's not all that 
> different from us requiring people to install a new glibc every once in a 
> while, just because we added a new filesystem. Everybody understands that 
> that would be totally insane.
> 
> Why does the X community not understand simple library versioning?

We use versioning on the Intel side, but in the form of feature flags
as new things are added (we've had a handful since GEM was added in
2.6.28).  It's a pain to handle the various code paths, but no more so
than having lots of separate library versions to support.  That would
be nice from one perspective, but it would only save work if we
abandoned the old versions quickly and kept a big shared component
between library versions.

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> Why does the X community not understand simple library versioning?

Why does Linus Torvalds not understand the Kconfig of his own staging
directory ?

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> Why does the X community not understand simple library versioning?

Why does Linus Torvalds not understand the Kconfig of his own staging
directory ?

Alan

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Stephane Marchesin wrote:
> 
> In short, the "don't break user space interfaces" principle is making
> user space code quality worse for everyone. And it makes our lives as
> graphics developers pretty miserable actually

And _my_ point is that if you did a half-way decent job on versioning, you 
wouldn't be in the crappy situation you are now.

For chissake, the DRM versioning model is a total disaster. The reason you 
can never ever break user space interfaces is exactly because when you 
break them, X stops working.

What I suggested is to _keep_ a working model across different versions, 
so that you can get out of the rat-hole you are in now (and the rat-hole 
you put your users into, and the distributions).

It's simply _not_ acceptable to tie the X server and the kernel version so 
tightly together as the crazy DRM model does right now. It's not all that 
different from us requiring people to install a new glibc every once in a 
while, just because we added a new filesystem. Everybody understands that 
that would be totally insane.

Why does the X community not understand simple library versioning?

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
> 
> You're asking volunteers who didn't ask for their driver to be merged to 
> perform more work in order to support users they didn't ask for.

And _you_ are making excuses for BAD TECHNICAL DECISIONS!

Come on! How hard is it to admit that that the change was done badly? How 
hard is it to admit that this isn't a political issue, it's about pure 
technology. There are good ways of doing things, and there are way sof 
doing things badly. 

I'm pointing to real _technical_ problems with how this was done. I'm 
talking about how this hurts testing, and how we've been able to handle 
things in other cases (with versioning, and forwards- or backwards- 
compatibility) without this kind of crap.

If you can't handle backwards compatibility - fine. But I get the very 
strong feeling that people didn't even _think_ about trying to be at least 
forwards-compatible, and I'm getting the _very_ strong feeling that you 
are making excuses for bad technology.

Is there some model of versioning inside X _except_ for the "it won't 
work" kind of thing? Can we fix this going forward, so that you can have 
_real_ versioning (ie multiple installed versions of a libdrm, the way you 
can have concurrently multiple installed versions of glibc?)

IOW, we have a real technical problem here. Are you just going to continue 
to make excuses about it?

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 11:14:11AM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
> > 
> > If you'd made it clear that you wanted the interface to be stable 
> > before it got merged, I suspect that it simply wouldn't have been merged 
> > until the interface was stable.
> 
> What kind of excuse is that? It's "we did bad things, but if we didn't do 
> those bad things, we'd have done _other_ bad things"?
> 
> Two wrong choices don't make a right.
> 
> Nobody has even answered me whether this is _forwards_compatible. It 
> clearly isn't backwards-compatible. IOW, is there _any_ way to move 
> back-and-forth over that commit, even if I can find a new libdrm?

Judging by 
http://cgit.freedesktop.org/mesa/drm/commit/?id=b496c63143e9a4ca02011582329bce2df99d9b7c 
, no. And if you're unhappy with that, don't use the driver. You enabled 
an option that's *documented* as potentially breaking between kernel 
releases, having been told that this was likely to happen, and now 
you're complaining?

> IOW, we know we have a problem here. But what's the solution? I know I can 
> revert it (I tried, I'm running that kernel now, nouveau works). That's 
> not a good solution, I know. But can you offer me a _better_ one? One that 
> doesn't involve "upgrade all the way to rawhide, and lose the ability to 
> bisect anything, or run plain 2.6.33".

Running -nv ought to be an option.

> So yes, I'm complaining. But I at least have mentioned one solution. You, 
> in contast, are just making excuses with no solutions.

You're asking volunteers who didn't ask for their driver to be merged to 
perform more work in order to support users they didn't ask for.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
> > If you'd made it clear that you wanted the interface to be stable 
> > before it got merged, I suspect that it simply wouldn't have been merged 
> > until the interface was stable.
> 
> What kind of excuse is that? It's "we did bad things, but if we didn't do 
> those bad things, we'd have done _other_ bad things"?
> 
> Two wrong choices don't make a right.

So unmerge it.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 505 bytes --]

On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
> > If you'd made it clear that you wanted the interface to be stable 
> > before it got merged, I suspect that it simply wouldn't have been merged 
> > until the interface was stable.
> 
> What kind of excuse is that? It's "we did bad things, but if we didn't do 
> those bad things, we'd have done _other_ bad things"?
> 
> Two wrong choices don't make a right.

So unmerge it.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Adam Jackson wrote:

> On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
> > On Thu, 4 Mar 2010, Matthew Garrett wrote:
> > > If you'd made it clear that you wanted the interface to be stable 
> > > before it got merged, I suspect that it simply wouldn't have been merged 
> > > until the interface was stable.
> > 
> > What kind of excuse is that? It's "we did bad things, but if we didn't do 
> > those bad things, we'd have done _other_ bad things"?
> > 
> > Two wrong choices don't make a right.
> 
> So unmerge it.

That's what I told people I can do (I'd just revert that commit).

I can do that. But it's not very productive, is it? What about the people 
who _do_ want to run the rawhide tree?

Seriously - what's wrong with my suggestion to just version things 
properly? What's wrong with _fixing_ a stupid technical problem? What's 
wrong with people that you can't see that there are actual _solutions_ to 
the f*cking mess that is the current situation?

I can solve it for my own use, and I already stated so. But while kernel 
developers should be scratching their own itches, a kernel developer that 
can't see past his own small sandbox is pretty damn worthless. We do need 
to fix this - and I'm bringing it up and complaining about it, because the 
nouveau people have _not_ done anything remotely sane. 

The current situation causes problems for people. Anybody who disputes 
that is in denial. Can somebody come up with a _better_ solution than the 
one I suggested? Feel free to do so, but in the meantime, I have to say 
that your reply and that of Matthew and others have been totally 
pointless, and making excuses rather than trying to actually face the fact 
that there is a problem.

So man up, guys. Face the problem, rather than say "well, it's staging", 
or "well, we can revert it". Neither of those really solve anything in the 
short run _or_ the long run.

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Adam Jackson wrote:

> On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
> > On Thu, 4 Mar 2010, Matthew Garrett wrote:
> > > If you'd made it clear that you wanted the interface to be stable 
> > > before it got merged, I suspect that it simply wouldn't have been merged 
> > > until the interface was stable.
> > 
> > What kind of excuse is that? It's "we did bad things, but if we didn't do 
> > those bad things, we'd have done _other_ bad things"?
> > 
> > Two wrong choices don't make a right.
> 
> So unmerge it.

That's what I told people I can do (I'd just revert that commit).

I can do that. But it's not very productive, is it? What about the people 
who _do_ want to run the rawhide tree?

Seriously - what's wrong with my suggestion to just version things 
properly? What's wrong with _fixing_ a stupid technical problem? What's 
wrong with people that you can't see that there are actual _solutions_ to 
the f*cking mess that is the current situation?

I can solve it for my own use, and I already stated so. But while kernel 
developers should be scratching their own itches, a kernel developer that 
can't see past his own small sandbox is pretty damn worthless. We do need 
to fix this - and I'm bringing it up and complaining about it, because the 
nouveau people have _not_ done anything remotely sane. 

The current situation causes problems for people. Anybody who disputes 
that is in denial. Can somebody come up with a _better_ solution than the 
one I suggested? Feel free to do so, but in the meantime, I have to say 
that your reply and that of Matthew and others have been totally 
pointless, and making excuses rather than trying to actually face the fact 
that there is a problem.

So man up, guys. Face the problem, rather than say "well, it's staging", 
or "well, we can revert it". Neither of those really solve anything in the 
short run _or_ the long run.

			Linus

Re: [git pull] drm request 3

[Stephane Marchesin]

On Thu, Mar 4, 2010 at 15:03, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Adam Jackson wrote:
>
>> On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote:
>> > On Thu, 4 Mar 2010, Matthew Garrett wrote:
>> > > If you'd made it clear that you wanted the interface to be stable
>> > > before it got merged, I suspect that it simply wouldn't have been merged
>> > > until the interface was stable.
>> >
>> > What kind of excuse is that? It's "we did bad things, but if we didn't do
>> > those bad things, we'd have done _other_ bad things"?
>> >
>> > Two wrong choices don't make a right.
>>
>> So unmerge it.
>
> That's what I told people I can do (I'd just revert that commit).
>
> I can do that. But it's not very productive, is it? What about the people
> who _do_ want to run the rawhide tree?
>
> Seriously - what's wrong with my suggestion to just version things
> properly? What's wrong with _fixing_ a stupid technical problem? What's
> wrong with people that you can't see that there are actual _solutions_ to
> the f*cking mess that is the current situation?
>
> I can solve it for my own use, and I already stated so. But while kernel
> developers should be scratching their own itches, a kernel developer that
> can't see past his own small sandbox is pretty damn worthless. We do need
> to fix this - and I'm bringing it up and complaining about it, because the
> nouveau people have _not_ done anything remotely sane.
>

Again, if we thought the DRM interfaces were good to begin with, we'd
have submitted the driver for inclusion. But that's not the case so
the we didn't submit the DRM. Whoever did gets to cope with the
issues.

Good luck,
Stephane

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Stephane Marchesin]

On Thu, Mar 4, 2010 at 15:03, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Adam Jackson wrote:
>
>> On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote:
>> > On Thu, 4 Mar 2010, Matthew Garrett wrote:
>> > > If you'd made it clear that you wanted the interface to be stable
>> > > before it got merged, I suspect that it simply wouldn't have been merged
>> > > until the interface was stable.
>> >
>> > What kind of excuse is that? It's "we did bad things, but if we didn't do
>> > those bad things, we'd have done _other_ bad things"?
>> >
>> > Two wrong choices don't make a right.
>>
>> So unmerge it.
>
> That's what I told people I can do (I'd just revert that commit).
>
> I can do that. But it's not very productive, is it? What about the people
> who _do_ want to run the rawhide tree?
>
> Seriously - what's wrong with my suggestion to just version things
> properly? What's wrong with _fixing_ a stupid technical problem? What's
> wrong with people that you can't see that there are actual _solutions_ to
> the f*cking mess that is the current situation?
>
> I can solve it for my own use, and I already stated so. But while kernel
> developers should be scratching their own itches, a kernel developer that
> can't see past his own small sandbox is pretty damn worthless. We do need
> to fix this - and I'm bringing it up and complaining about it, because the
> nouveau people have _not_ done anything remotely sane.
>

Again, if we thought the DRM interfaces were good to begin with, we'd
have submitted the driver for inclusion. But that's not the case so
the we didn't submit the DRM. Whoever did gets to cope with the
issues.

Good luck,
Stephane

Re: [git pull] drm request 3

[Alan Cox]

> So man up, guys. Face the problem, rather than say "well, it's staging", 
> or "well, we can revert it". Neither of those really solve anything in the 
> short run _or_ the long run.

Linus stop and think for a minute instead. Maybe a timeline would help


		Nouveau development starts
		People ship highly experimental stuff for testers
		Code gets to the "works but really needs a clean up point"

		Linus demands it is merged
		Linus gets it merged as staging

		Developers start doing the cleanup

		Linus throws a tantrum because they did the cleanup after
		merge


*YOU* forced the early merge (rightly or wrongly)
*YOU* effectively created the API break problem

So blaming other people is quite out of order.

Alan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> So man up, guys. Face the problem, rather than say "well, it's staging", 
> or "well, we can revert it". Neither of those really solve anything in the 
> short run _or_ the long run.

Linus stop and think for a minute instead. Maybe a timeline would help


		Nouveau development starts
		People ship highly experimental stuff for testers
		Code gets to the "works but really needs a clean up point"

		Linus demands it is merged
		Linus gets it merged as staging

		Developers start doing the cleanup

		Linus throws a tantrum because they did the cleanup after
		merge


*YOU* forced the early merge (rightly or wrongly)
*YOU* effectively created the API break problem

So blaming other people is quite out of order.

Alan

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote:
> On Thu, 4 Mar 2010, Adam Jackson wrote:
> > On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
> > > Two wrong choices don't make a right.
> > 
> > So unmerge it.
> 
> That's what I told people I can do (I'd just revert that commit).

Read it more strongly: drop nouveau from your tree entirely.

Don't give me any "not a solution" nonsense about that.  The problem is
entirely that your expectations for interface stability [1] in your tree
do not match nouveau's development model and will not for the forseeable
future.  Yes, they should htfu and version interfaces like real men.
But they're not going to, so either enforce your rule or don't.

[1] - apparently ignorable when it's inconvenient, but let's not turn
this into a sysfs argument.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 842 bytes --]

On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote:
> On Thu, 4 Mar 2010, Adam Jackson wrote:
> > On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
> > > Two wrong choices don't make a right.
> > 
> > So unmerge it.
> 
> That's what I told people I can do (I'd just revert that commit).

Read it more strongly: drop nouveau from your tree entirely.

Don't give me any "not a solution" nonsense about that.  The problem is
entirely that your expectations for interface stability [1] in your tree
do not match nouveau's development model and will not for the forseeable
future.  Yes, they should htfu and version interfaces like real men.
But they're not going to, so either enforce your rule or don't.

[1] - apparently ignorable when it's inconvenient, but let's not turn
this into a sysfs argument.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> "Please note that these drivers are under heavy development, may or may
> not work, and may contain userspace interfaces that most likely will be
> changed in the near future."

Shipping it as the default Fedora driver for NVIDIA hardware makes that 
text largely irrelevant.

Jesse said
> Dave and the nouveau guys include the driver in Fedora to get
> much needed test coverage, and make sure the latest bits in rawhide
> work together.

but when it is the default driver, it is the default _production_ driver 
for Fedora users, in an official, stable Fedora release.

And the alternative?  You said
> F-12 continues to ship the -nv driver, which will work fine with any
> kernel version as long as nouveau is disabled.

FAIL.  I actually tried that.  Have you?  Do you think it is remotely 
easy for a technically component, non-Xorg-hacker type to accomplish?

I attempted to use the non-default 'nv' driver just before nouveau was 
merged into upstream/staging, because I wanted a development kernel that 
actually worked on my Fedora-based devel boxes.  It was a complete 
exercise in frustration, requiring at least one bugzilla bug report, and 
ultimately resulted in failure.

I gave up and waiting for Linus to merge nouveau, which instantly made 
my life a lot easier :)

Kernel hacking on Fedora, my own dogfood, has become increasingly 
cumbersome because of all these graphics issues.  Sometimes it's just 
easier to test a modern kernel on an ancient distro, sadly.

	Jeff

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: 
> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> > F-12 continues to ship the -nv driver, which will work fine with any
> > kernel version as long as nouveau is disabled.
> 
> FAIL.  I actually tried that.  Have you?  Do you think it is remotely 
> easy for a technically component, non-Xorg-hacker type to accomplish?

# cat << EOF > /etc/X11/xorg.conf
Section "Device"
    Identifier "Card0"
    Driver "nv"
EndSection
EOF
# sed -i 's/\<kernel\>.*/& nouveau.modeset=0/g' /etc/grub.conf
# telinit 6

HTH.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/04/2010 05:18 PM, Adam Jackson wrote:
> On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote:
>> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
>>> F-12 continues to ship the -nv driver, which will work fine with any
>>> kernel version as long as nouveau is disabled.
>>
>> FAIL.  I actually tried that.  Have you?  Do you think it is remotely
>> easy for a technically component, non-Xorg-hacker type to accomplish?
>
> # cat<<  EOF>  /etc/X11/xorg.conf
> Section "Device"
>      Identifier "Card0"
>      Driver "nv"
> EndSection
> EOF

Already tried that, and other suggested variations thereof.

Did not work on F11 or F12 with
05:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GX2 
(rev a2)


> # sed -i 's/\<kernel\>.*/&  nouveau.modeset=0/g' /etc/grub.conf

Never tried this part.

	Jeff

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1077 bytes --]

On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote:

> > # sed -i 's/\<kernel\>.*/&  nouveau.modeset=0/g' /etc/grub.conf
> 
> Never tried this part.

The bug I'm assuming you're referring to is

https://bugzilla.redhat.com/show_bug.cgi?id=519298

in which you merely remove the nouveau userspace component, and in which
I can't tell if you built nouveau into the kernel or not, but I assume
you didn't based on your previous post.  The X server does only try the
one driver before falling back to vesa, which is a bug in the fallback
logic I suppose.  I've (blindly) fixed that for F13 now.

However, the log in that bug only shows you using the built-in
autoconfig logic, and not an xorg.conf file.  So, given you were talking
about a kernel without nouveau, I am left to assume one of:

- you didn't try writing an xorg.conf fragment
- you did, and it didn't work anyway

The latter case is entirely plausible, as nv is not the sort of driver
that gets a lot of love, but I'm not aware of any open bugs about gf9800
in particular in nv.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote:

> > # sed -i 's/\<kernel\>.*/&  nouveau.modeset=0/g' /etc/grub.conf
> 
> Never tried this part.

The bug I'm assuming you're referring to is

https://bugzilla.redhat.com/show_bug.cgi?id=519298

in which you merely remove the nouveau userspace component, and in which
I can't tell if you built nouveau into the kernel or not, but I assume
you didn't based on your previous post.  The X server does only try the
one driver before falling back to vesa, which is a bug in the fallback
logic I suppose.  I've (blindly) fixed that for F13 now.

However, the log in that bug only shows you using the built-in
autoconfig logic, and not an xorg.conf file.  So, given you were talking
about a kernel without nouveau, I am left to assume one of:

- you didn't try writing an xorg.conf fragment
- you did, and it didn't work anyway

The latter case is entirely plausible, as nv is not the sort of driver
that gets a lot of love, but I'm not aware of any open bugs about gf9800
in particular in nv.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/04/2010 05:59 PM, Adam Jackson wrote:
> On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote:
>
>>> # sed -i 's/\<kernel\>.*/&   nouveau.modeset=0/g' /etc/grub.conf
>>
>> Never tried this part.
>
> The bug I'm assuming you're referring to is
>
> https://bugzilla.redhat.com/show_bug.cgi?id=519298
>
> in which you merely remove the nouveau userspace component, and in which
> I can't tell if you built nouveau into the kernel or not, but I assume
> you didn't based on your previous post.  The X server does only try the
> one driver before falling back to vesa, which is a bug in the fallback
> logic I suppose.  I've (blindly) fixed that for F13 now.

Thanks.  Can this be put into F12 too?


> However, the log in that bug only shows you using the built-in
> autoconfig logic, and not an xorg.conf file.  So, given you were talking
> about a kernel without nouveau, I am left to assume one of:
>
> - you didn't try writing an xorg.conf fragment
> - you did, and it didn't work anyway
>
> The latter case is entirely plausible, as nv is not the sort of driver
> that gets a lot of love, but I'm not aware of any open bugs about gf9800
> in particular in nv.

The latter...  would modeset in grub interfere, perhaps?

	Jeff



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/04/2010 05:59 PM, Adam Jackson wrote:
> On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote:
>
>>> # sed -i 's/\<kernel\>.*/&   nouveau.modeset=0/g' /etc/grub.conf
>>
>> Never tried this part.
>
> The bug I'm assuming you're referring to is
>
> https://bugzilla.redhat.com/show_bug.cgi?id=519298
>
> in which you merely remove the nouveau userspace component, and in which
> I can't tell if you built nouveau into the kernel or not, but I assume
> you didn't based on your previous post.  The X server does only try the
> one driver before falling back to vesa, which is a bug in the fallback
> logic I suppose.  I've (blindly) fixed that for F13 now.

Thanks.  Can this be put into F12 too?


> However, the log in that bug only shows you using the built-in
> autoconfig logic, and not an xorg.conf file.  So, given you were talking
> about a kernel without nouveau, I am left to assume one of:
>
> - you didn't try writing an xorg.conf fragment
> - you did, and it didn't work anyway
>
> The latter case is entirely plausible, as nv is not the sort of driver
> that gets a lot of love, but I'm not aware of any open bugs about gf9800
> in particular in nv.

The latter...  would modeset in grub interfere, perhaps?

	Jeff

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1247 bytes --]

On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote:
> On 03/04/2010 05:59 PM, Adam Jackson wrote:
> > in which you merely remove the nouveau userspace component, and in which
> > I can't tell if you built nouveau into the kernel or not, but I assume
> > you didn't based on your previous post.  The X server does only try the
> > one driver before falling back to vesa, which is a bug in the fallback
> > logic I suppose.  I've (blindly) fixed that for F13 now.
> 
> Thanks.  Can this be put into F12 too?

Sure, why not.

> > - you didn't try writing an xorg.conf fragment
> > - you did, and it didn't work anyway
> >
> > The latter case is entirely plausible, as nv is not the sort of driver
> > that gets a lot of love, but I'm not aware of any open bugs about gf9800
> > in particular in nv.
> 
> The latter...  would modeset in grub interfere, perhaps?

It's not going to do anything if you didn't build a KMS driver.  It's
just a kcmdline option like any other; if there's no module to honor it,
then it doesn't do anything.  grub doesn't have any particular KMS
awareness.

I'm really going to have to see an X log and dmesg from the failure mode
when actually using nv to diagnose this any further.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote:
> On 03/04/2010 05:59 PM, Adam Jackson wrote:
> > in which you merely remove the nouveau userspace component, and in which
> > I can't tell if you built nouveau into the kernel or not, but I assume
> > you didn't based on your previous post.  The X server does only try the
> > one driver before falling back to vesa, which is a bug in the fallback
> > logic I suppose.  I've (blindly) fixed that for F13 now.
> 
> Thanks.  Can this be put into F12 too?

Sure, why not.

> > - you didn't try writing an xorg.conf fragment
> > - you did, and it didn't work anyway
> >
> > The latter case is entirely plausible, as nv is not the sort of driver
> > that gets a lot of love, but I'm not aware of any open bugs about gf9800
> > in particular in nv.
> 
> The latter...  would modeset in grub interfere, perhaps?

It's not going to do anything if you didn't build a KMS driver.  It's
just a kcmdline option like any other; if there's no module to honor it,
then it doesn't do anything.  grub doesn't have any particular KMS
awareness.

I'm really going to have to see an X log and dmesg from the failure mode
when actually using nv to diagnose this any further.

- ajax

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/04/2010 05:18 PM, Adam Jackson wrote:
> On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote:
>> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
>>> F-12 continues to ship the -nv driver, which will work fine with any
>>> kernel version as long as nouveau is disabled.
>>
>> FAIL.  I actually tried that.  Have you?  Do you think it is remotely
>> easy for a technically component, non-Xorg-hacker type to accomplish?
>
> # cat<<  EOF>  /etc/X11/xorg.conf
> Section "Device"
>      Identifier "Card0"
>      Driver "nv"
> EndSection
> EOF

Already tried that, and other suggested variations thereof.

Did not work on F11 or F12 with
05:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GX2 
(rev a2)


> # sed -i 's/\<kernel\>.*/&  nouveau.modeset=0/g' /etc/grub.conf

Never tried this part.

	Jeff



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 591 bytes --]

On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: 
> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> > F-12 continues to ship the -nv driver, which will work fine with any
> > kernel version as long as nouveau is disabled.
> 
> FAIL.  I actually tried that.  Have you?  Do you think it is remotely 
> easy for a technically component, non-Xorg-hacker type to accomplish?

# cat << EOF > /etc/X11/xorg.conf
Section "Device"
    Identifier "Card0"
    Driver "nv"
EndSection
EOF
# sed -i 's/\<kernel\>.*/& nouveau.modeset=0/g' /etc/grub.conf
# telinit 6

HTH.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Robert Hancock]

On 03/04/2010 01:32 PM, Jeff Garzik wrote:
> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
>> "Please note that these drivers are under heavy development, may or may
>> not work, and may contain userspace interfaces that most likely will be
>> changed in the near future."
>
> Shipping it as the default Fedora driver for NVIDIA hardware makes that
> text largely irrelevant.

Indeed, that text isn't really reconcilable with the fact that the 
driver is being used by default in a stable distro release. (Why do 
people keep forgetting the whole "upstream development" thing?)

>
> Jesse said
>> Dave and the nouveau guys include the driver in Fedora to get
>> much needed test coverage, and make sure the latest bits in rawhide
>> work together.
>
> but when it is the default driver, it is the default _production_ driver
> for Fedora users, in an official, stable Fedora release.
>
> And the alternative? You said
>> F-12 continues to ship the -nv driver, which will work fine with any
>> kernel version as long as nouveau is disabled.
>
> FAIL. I actually tried that. Have you? Do you think it is remotely easy
> for a technically component, non-Xorg-hacker type to accomplish?
>
> I attempted to use the non-default 'nv' driver just before nouveau was
> merged into upstream/staging, because I wanted a development kernel that
> actually worked on my Fedora-based devel boxes. It was a complete
> exercise in frustration, requiring at least one bugzilla bug report, and
> ultimately resulted in failure.

Advising people to use nv is pretty much a joke IMHO, it's barely above 
VESA in some ways. People would be more likely to use the nvidia binary 
driver than that contraption..

Aside from the fact that running nouveau on this machine would drive me 
crazy (there's no fan speed control implemented so the GPU fan screams 
away at maximum speed), the other big reason I can't use it is that at 
least until quite recently it couldn't work with upstream kernels. 
Unfortunately, changes like this will being that problem back..

So at this point the nvidia binary driver is the most practical solution 
that actually meets my needs, sadly enough..

>
> I gave up and waiting for Linus to merge nouveau, which instantly made
> my life a lot easier :)
>
> Kernel hacking on Fedora, my own dogfood, has become increasingly
> cumbersome because of all these graphics issues. Sometimes it's just
> easier to test a modern kernel on an ancient distro, sadly.
>
> Jeff
>
>
>


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Robert Hancock]

On 03/04/2010 01:32 PM, Jeff Garzik wrote:
> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
>> "Please note that these drivers are under heavy development, may or may
>> not work, and may contain userspace interfaces that most likely will be
>> changed in the near future."
>
> Shipping it as the default Fedora driver for NVIDIA hardware makes that
> text largely irrelevant.

Indeed, that text isn't really reconcilable with the fact that the 
driver is being used by default in a stable distro release. (Why do 
people keep forgetting the whole "upstream development" thing?)

>
> Jesse said
>> Dave and the nouveau guys include the driver in Fedora to get
>> much needed test coverage, and make sure the latest bits in rawhide
>> work together.
>
> but when it is the default driver, it is the default _production_ driver
> for Fedora users, in an official, stable Fedora release.
>
> And the alternative? You said
>> F-12 continues to ship the -nv driver, which will work fine with any
>> kernel version as long as nouveau is disabled.
>
> FAIL. I actually tried that. Have you? Do you think it is remotely easy
> for a technically component, non-Xorg-hacker type to accomplish?
>
> I attempted to use the non-default 'nv' driver just before nouveau was
> merged into upstream/staging, because I wanted a development kernel that
> actually worked on my Fedora-based devel boxes. It was a complete
> exercise in frustration, requiring at least one bugzilla bug report, and
> ultimately resulted in failure.

Advising people to use nv is pretty much a joke IMHO, it's barely above 
VESA in some ways. People would be more likely to use the nvidia binary 
driver than that contraption..

Aside from the fact that running nouveau on this machine would drive me 
crazy (there's no fan speed control implemented so the GPU fan screams 
away at maximum speed), the other big reason I can't use it is that at 
least until quite recently it couldn't work with upstream kernels. 
Unfortunately, changes like this will being that problem back..

So at this point the nvidia binary driver is the most practical solution 
that actually meets my needs, sadly enough..

>
> I gave up and waiting for Linus to merge nouveau, which instantly made
> my life a lot easier :)
>
> Kernel hacking on Fedora, my own dogfood, has become increasingly
> cumbersome because of all these graphics issues. Sometimes it's just
> easier to test a modern kernel on an ancient distro, sadly.
>
> Jeff
>
>
>

Re: [git pull] drm request 3

[Alan Cox]

On Thu, 04 Mar 2010 14:32:02 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> > "Please note that these drivers are under heavy development, may or may
> > not work, and may contain userspace interfaces that most likely will be
> > changed in the near future."
> 
> Shipping it as the default Fedora driver for NVIDIA hardware makes that 
> text largely irrelevant.

Why ? Fedora isn't special, Fedora is just a distribution that uses the
Linux kernel. If Fedora turns on staging drivers then Fedora has to
accept that stuff breaks and manage that expectation with its users.
Staging is not and has not been API stable. If staging is going to be API
stable then it it useless and may as well be deleted.

In this case Linus is just a random Fedora user having a distro problem.
I don't even see what it has to do with linux-kernel. The libdrm problem
and difficulty using Fedora libdrm with current upstream kernel is a
Fedora problem not a kernel problem.

The kernel staging tree is unstable for API. Whether thats the Nouveau
guys breaking Fedora, submissions to network drivers breaking/removing
bogus APIs in stuff being cleaned up - whatever then thats how the cookie
crumbles. DRM has just made it all horribly more visible because the
libdrm/kernel stuff has such a complex and closely tied interface.

Serious discussion point perhaps should be: is the libdrm so close to the
kernel it ought to be in the same git tree ? Alternatively does it need
to be easier to have multiple Nouveau libdrms autoselected according to
the kernel side versioning. ELF library versioning is not rocket science
and both the old and new libraries exist and can be installed so all the
bits are present except for the wrapper to load the right sublibrary yes ?

Alan

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

On Thu, 04 Mar 2010 14:32:02 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> > "Please note that these drivers are under heavy development, may or may
> > not work, and may contain userspace interfaces that most likely will be
> > changed in the near future."
> 
> Shipping it as the default Fedora driver for NVIDIA hardware makes that 
> text largely irrelevant.

Why ? Fedora isn't special, Fedora is just a distribution that uses the
Linux kernel. If Fedora turns on staging drivers then Fedora has to
accept that stuff breaks and manage that expectation with its users.
Staging is not and has not been API stable. If staging is going to be API
stable then it it useless and may as well be deleted.

In this case Linus is just a random Fedora user having a distro problem.
I don't even see what it has to do with linux-kernel. The libdrm problem
and difficulty using Fedora libdrm with current upstream kernel is a
Fedora problem not a kernel problem.

The kernel staging tree is unstable for API. Whether thats the Nouveau
guys breaking Fedora, submissions to network drivers breaking/removing
bogus APIs in stuff being cleaned up - whatever then thats how the cookie
crumbles. DRM has just made it all horribly more visible because the
libdrm/kernel stuff has such a complex and closely tied interface.

Serious discussion point perhaps should be: is the libdrm so close to the
kernel it ought to be in the same git tree ? Alternatively does it need
to be easier to have multiple Nouveau libdrms autoselected according to
the kernel side versioning. ELF library versioning is not rocket science
and both the old and new libraries exist and can be installed so all the
bits are present except for the wrapper to load the right sublibrary yes ?

Alan

Re: [git pull] drm request 3

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

On Fri, 5 Mar 2010 12:21:29 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Serious discussion point perhaps should be: is the libdrm so close to the
> kernel it ought to be in the same git tree ? Alternatively does it need
> to be easier to have multiple Nouveau libdrms autoselected according to
> the kernel side versioning. ELF library versioning is not rocket science
> and both the old and new libraries exist and can be installed so all the
> bits are present except for the wrapper to load the right sublibrary yes ?

That *would* make versioning impossible.

To make the difficulty of improving ABI at the moment concrete, I just
got done merging the patches for execbuf2 in userland and enabling i915
texture tiling.  This was a 3% performance win in one test I was looking
at, and 1% in another -- less than hoped, but important nonetheless
(there are other cases that should see 30% or so wins hopefully).  The
patches got written back in July, and revved several times as they broke
various combinations of compatibility.  At the point that I merged eb2
to the kernel for 2.6.33, it wasn't *really* tested -- the userland side
was broken all to hell it looked like, but at least it wasn't regressing
execbuf1 any more, right?  I spent this week getting userland working,
including a new libdrm release (already obsolete because a bug in the
libdrm violated what the ABI between libdrm <-> msea was supposed to
be).  So overall, I'd say that we spent about a month of developer time
at least between jbarnes, ickle, and myself, on extending the execbuf
interface to add a flag saying "dear kernel, please don't do this bit of
work on this buffer, because I don't need it and it makes things slow."

This is not that bad for Intel folks.  We're paid to hack on it, and can
justify spending ridiculous amounts of time for small wins.  I actually
enjoy this.

Right now all the userland -- whether it's Mesa, xf86-video-intel,
libva, cairo-drm, stand-alone DRM testcases, etc., gets to move to the
new libdrm API, declare its dependency in PKG_CHECK_MODULES, and hand
that new flag to libdrm as if the kernel supported the new interface.
Inside libdrm, it looks at the kernel version and uses the new interface
or old as appropriate.  The ugly versioning stuff stays in one
easy-to-review 5kloc component, and the complicated 50kloc driver
components get to pretend they have a fancy new kernel.

But if libdrm's in the kernel, all those userland components no longer
get to rely on the version of libdrm, because distros will ship
whatever's with the kernel they're using and our userland does have to
work on (relatively recent) distros.  Each of those userland components
would have to grow a compatibility layer to work with whatever kernel
libdrm is available, passing the flag in the new API or using the old
API.  Userland would even buggier for having to replicate all that logic
everywhere, and we probably wouldn't have execbuf2 landed yet.

Well, OK.  What I'd really do instead is make the kernel libdrm be a
thin ioctl wrapper, and build a librealdrm that does what libdrm does
today.  But I don't think that's what you were suggesting.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] drm request 3

[Luca Barbieri]

> So overall, I'd say that we spent about a month of developer time
> at least between jbarnes, ickle, and myself, on extending the execbuf
> interface to add a flag saying "dear kernel, please don't do this bit of
> work on this buffer, because I don't need it and it makes things slow."

Perhaps then, we should break ABI compatibility _more_ often to speed
up development, but also have awesome mechanisms to make it painless
for the user.

Such as:
1. Automatic side by side userspace installation, as Linus proposed
2. Kernel "make install" refusing to proceed if it finds that
userspace is not updated, and giving instructions on how to update
userspace
3. Distributions packaging the new ABI X/Mesa drivers and libdrm even
for stable distributions
4. Kernel "make install" offering to automatically install said
distribution packages if it detects a supported distribution
5. Ability to drop new versions of drivers/gpu/drm in an older kernel
tree and have it compile (within reasonable limits)

In particular, for people with (slightly) old kernels, it should be
much easier to make updated DRM trees still work with older kernels,
than attempting to make updated userspace work with older kernel
modules.
This also actually gives them the benefits of the new code.

And for people with really old kernels, it's not different from any
other hardware device, which requires a kernel upgrade to have better
support.

Then, for instance, Linus would just have seen the following upon
running make install:
This kernel requires the Nouveau userspace version 0.0.16, which you
don't have installed.
Fedora 12 has been detected.
Invoke yum to install the <rpmnames> RPMs required for it? [y/n]
_or_
Ubuntu 9.10 has been detected
Invoke apt-get to install the <debnames> packages required for it? [y/n]

If the user says no, or the distribution is unknown, instructions on
how to download and compile the source would be presented.

Once you setup this system, you can freely break the ABI with no
significant user discomfort by just raising the version number.
This also potentially applies to stuff other than DRM (e.g. perf, kvm,
iptables, udev, filesystem-specific tools/APIs, various device
configuration systems, and so on).

The really stable APIs/ABIs should not be the (undocumented) kernel
ones, but Xlib and OpenGL, which actually have formal specifications.
Perhaps eventually Gallium could join them as a stable API closer to
the hardware, but that's a long way off.

Re: [git pull] drm request 3

[Luca Barbieri]

> So overall, I'd say that we spent about a month of developer time
> at least between jbarnes, ickle, and myself, on extending the execbuf
> interface to add a flag saying "dear kernel, please don't do this bit of
> work on this buffer, because I don't need it and it makes things slow."

Perhaps then, we should break ABI compatibility _more_ often to speed
up development, but also have awesome mechanisms to make it painless
for the user.

Such as:
1. Automatic side by side userspace installation, as Linus proposed
2. Kernel "make install" refusing to proceed if it finds that
userspace is not updated, and giving instructions on how to update
userspace
3. Distributions packaging the new ABI X/Mesa drivers and libdrm even
for stable distributions
4. Kernel "make install" offering to automatically install said
distribution packages if it detects a supported distribution
5. Ability to drop new versions of drivers/gpu/drm in an older kernel
tree and have it compile (within reasonable limits)

In particular, for people with (slightly) old kernels, it should be
much easier to make updated DRM trees still work with older kernels,
than attempting to make updated userspace work with older kernel
modules.
This also actually gives them the benefits of the new code.

And for people with really old kernels, it's not different from any
other hardware device, which requires a kernel upgrade to have better
support.

Then, for instance, Linus would just have seen the following upon
running make install:
This kernel requires the Nouveau userspace version 0.0.16, which you
don't have installed.
Fedora 12 has been detected.
Invoke yum to install the <rpmnames> RPMs required for it? [y/n]
_or_
Ubuntu 9.10 has been detected
Invoke apt-get to install the <debnames> packages required for it? [y/n]

If the user says no, or the distribution is unknown, instructions on
how to download and compile the source would be presented.

Once you setup this system, you can freely break the ABI with no
significant user discomfort by just raising the version number.
This also potentially applies to stuff other than DRM (e.g. perf, kvm,
iptables, udev, filesystem-specific tools/APIs, various device
configuration systems, and so on).

The really stable APIs/ABIs should not be the (undocumented) kernel
ones, but Xlib and OpenGL, which actually have formal specifications.
Perhaps eventually Gallium could join them as a stable API closer to
the hardware, but that's a long way off.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 3163 bytes --]

On Fri, 5 Mar 2010 12:21:29 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Serious discussion point perhaps should be: is the libdrm so close to the
> kernel it ought to be in the same git tree ? Alternatively does it need
> to be easier to have multiple Nouveau libdrms autoselected according to
> the kernel side versioning. ELF library versioning is not rocket science
> and both the old and new libraries exist and can be installed so all the
> bits are present except for the wrapper to load the right sublibrary yes ?

That *would* make versioning impossible.

To make the difficulty of improving ABI at the moment concrete, I just
got done merging the patches for execbuf2 in userland and enabling i915
texture tiling.  This was a 3% performance win in one test I was looking
at, and 1% in another -- less than hoped, but important nonetheless
(there are other cases that should see 30% or so wins hopefully).  The
patches got written back in July, and revved several times as they broke
various combinations of compatibility.  At the point that I merged eb2
to the kernel for 2.6.33, it wasn't *really* tested -- the userland side
was broken all to hell it looked like, but at least it wasn't regressing
execbuf1 any more, right?  I spent this week getting userland working,
including a new libdrm release (already obsolete because a bug in the
libdrm violated what the ABI between libdrm <-> msea was supposed to
be).  So overall, I'd say that we spent about a month of developer time
at least between jbarnes, ickle, and myself, on extending the execbuf
interface to add a flag saying "dear kernel, please don't do this bit of
work on this buffer, because I don't need it and it makes things slow."

This is not that bad for Intel folks.  We're paid to hack on it, and can
justify spending ridiculous amounts of time for small wins.  I actually
enjoy this.

Right now all the userland -- whether it's Mesa, xf86-video-intel,
libva, cairo-drm, stand-alone DRM testcases, etc., gets to move to the
new libdrm API, declare its dependency in PKG_CHECK_MODULES, and hand
that new flag to libdrm as if the kernel supported the new interface.
Inside libdrm, it looks at the kernel version and uses the new interface
or old as appropriate.  The ugly versioning stuff stays in one
easy-to-review 5kloc component, and the complicated 50kloc driver
components get to pretend they have a fancy new kernel.

But if libdrm's in the kernel, all those userland components no longer
get to rely on the version of libdrm, because distros will ship
whatever's with the kernel they're using and our userland does have to
work on (relatively recent) distros.  Each of those userland components
would have to grow a compatibility layer to work with whatever kernel
libdrm is available, passing the flag in the new API or using the old
API.  Userland would even buggier for having to replicate all that logic
everywhere, and we probably wouldn't have execbuf2 landed yet.

Well, OK.  What I'd really do instead is make the kernel libdrm be a
thin ioctl wrapper, and build a librealdrm that does what libdrm does
today.  But I don't think that's what you were suggesting.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Jeff Garzik]

On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> "Please note that these drivers are under heavy development, may or may
> not work, and may contain userspace interfaces that most likely will be
> changed in the near future."

Shipping it as the default Fedora driver for NVIDIA hardware makes that 
text largely irrelevant.

Jesse said
> Dave and the nouveau guys include the driver in Fedora to get
> much needed test coverage, and make sure the latest bits in rawhide
> work together.

but when it is the default driver, it is the default _production_ driver 
for Fedora users, in an official, stable Fedora release.

And the alternative?  You said
> F-12 continues to ship the -nv driver, which will work fine with any
> kernel version as long as nouveau is disabled.

FAIL.  I actually tried that.  Have you?  Do you think it is remotely 
easy for a technically component, non-Xorg-hacker type to accomplish?

I attempted to use the non-default 'nv' driver just before nouveau was 
merged into upstream/staging, because I wanted a development kernel that 
actually worked on my Fedora-based devel boxes.  It was a complete 
exercise in frustration, requiring at least one bugzilla bug report, and 
ultimately resulted in failure.

I gave up and waiting for Linus to merge nouveau, which instantly made 
my life a lot easier :)

Kernel hacking on Fedora, my own dogfood, has become increasingly 
cumbersome because of all these graphics issues.  Sometimes it's just 
easier to test a modern kernel on an ancient distro, sadly.

	Jeff




------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Matthew Garrett]

On Thu, Mar 04, 2010 at 10:43:30AM -0800, Linus Torvalds wrote:

> Or is there a version of X that can handle _both_ the 0.0.15 and the 
> 0.0.16 interfaces?

When you asked that nouveau was merged, people explicitly told you that 
the reason it hadn't been was because the interface was unstable and 
userspace would break. You asked that it be merged anyway, and now 
you're unhappy because the interface has changed and userspace has 
broken?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

Hi,

On Thu, 2010-03-04 at 10:43 -0800, Linus Torvalds wrote:
> it difficult to have some libdrm that can handle both 
> versions.

You shouldn't expect, by now, upgrade drm kernel without update libdrm
or at least recompile libdrm.
So when you saw a error message "driver nouveau 0.0.n+1 and have 0.0.n"
is completely right. 
Is not a perfect world, but as talked on xorg mailing list, some time
ago, we do not have resources to test it in all versions.
Is better focus on just one combination.

Best regards, 
-- 
Sérgio M. B.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3159 bytes --]

Re: [git pull] drm request 3

[Linus Torvalds]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
> 
> You shouldn't expect, by now, upgrade drm kernel without update libdrm
> or at least recompile libdrm.

Why?

Why shouldn't I expect that? I already outlined exactly _how_ it could be 
done.

Why are people saying that technology has to suck?

> So when you saw a error message "driver nouveau 0.0.n+1 and have 0.0.n"
> is completely right. 

No. It's _not_ right. The code knows what is wrong. Considering it a fatal 
error is _stupid_ and bad technology, when it could have just fixed it.

> Is not a perfect world, but as talked on xorg mailing list, some time
> ago, we do not have resources to test it in all versions.
> Is better focus on just one combination.

This is not about "testing all versions". It's fine to have just one 
combination. But why the hell doesn't it _load_ that one combination 
instead of just dying?

IOW, there is a check for a version. It could - instead of dying - just 
dlopen() the right version instead. 

Why are people making excuses for bad programming and bad technology? 

			Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
> 
> You shouldn't expect, by now, upgrade drm kernel without update libdrm
> or at least recompile libdrm.

Why?

Why shouldn't I expect that? I already outlined exactly _how_ it could be 
done.

Why are people saying that technology has to suck?

> So when you saw a error message "driver nouveau 0.0.n+1 and have 0.0.n"
> is completely right. 

No. It's _not_ right. The code knows what is wrong. Considering it a fatal 
error is _stupid_ and bad technology, when it could have just fixed it.

> Is not a perfect world, but as talked on xorg mailing list, some time
> ago, we do not have resources to test it in all versions.
> Is better focus on just one combination.

This is not about "testing all versions". It's fine to have just one 
combination. But why the hell doesn't it _load_ that one combination 
instead of just dying?

IOW, there is a check for a version. It could - instead of dying - just 
dlopen() the right version instead. 

Why are people making excuses for bad programming and bad technology? 

			Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> Why are people making excuses for bad programming and bad technology?

Is not bad technology is new technology, the API have to change faster ,
unless you want wait 2 years until get "stable" .  


-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3293 bytes --]

Re: [git pull] drm request 3

[Sergio Monteiro Basto]

[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]

On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> Why are people making excuses for bad programming and bad technology?

Is not bad technology is new technology, the API have to change faster ,
unless you want wait 2 years until get "stable" .  


-- 
Sérgio M. B.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3293 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:

> On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> > Why are people making excuses for bad programming and bad technology?
> 
> Is not bad technology is new technology, the API have to change faster ,
> unless you want wait 2 years until get "stable" .  

F*ck me, but people are being dense.

With my suggestion, people could change the API _more_, because it 
wouldn't be as painful.

This is not about "change the ABI or not". This is about "since you change 
the ABI, do it _well_, so that it doesn't hurt people as much".

		Linus

Re: [git pull] drm request 3

[Linus Torvalds]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:

> On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> > Why are people making excuses for bad programming and bad technology?
> 
> Is not bad technology is new technology, the API have to change faster ,
> unless you want wait 2 years until get "stable" .  

F*ck me, but people are being dense.

With my suggestion, people could change the API _more_, because it 
wouldn't be as painful.

This is not about "change the ABI or not". This is about "since you change 
the ABI, do it _well_, so that it doesn't hurt people as much".

		Linus

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[tytso]

On Sat, Mar 06, 2010 at 11:28:16AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
> 
> > On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> > > Why are people making excuses for bad programming and bad technology?
> > 
> > Is not bad technology is new technology, the API have to change faster ,
> > unless you want wait 2 years until get "stable" .  
> 
> F*ck me, but people are being dense.

Nah, they're just being lazy, selfish b*stards, that's all.  :-(

They want the benefits of lots of testers, without wanting to be
courteous to those testers.

						- Ted

Re: [git pull] drm request 3

[tytso]

On Sat, Mar 06, 2010 at 11:28:16AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
> 
> > On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> > > Why are people making excuses for bad programming and bad technology?
> > 
> > Is not bad technology is new technology, the API have to change faster ,
> > unless you want wait 2 years until get "stable" .  
> 
> F*ck me, but people are being dense.

Nah, they're just being lazy, selfish b*stards, that's all.  :-(

They want the benefits of lots of testers, without wanting to be
courteous to those testers.

						- Ted

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> They want the benefits of lots of testers, without wanting to be
> courteous to those testers.

Except for the small rather important detail that the Nouveau developers
didn't ask for it to be merged in the first place.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Alan Cox]

> They want the benefits of lots of testers, without wanting to be
> courteous to those testers.

Except for the small rather important detail that the Nouveau developers
didn't ask for it to be merged in the first place.

Re: [git pull] drm request 3

[tytso]

On Sat, Mar 06, 2010 at 08:52:35PM +0000, Alan Cox wrote:
> > They want the benefits of lots of testers, without wanting to be
> > courteous to those testers.
> 
> Except for the small rather important detail that the Nouveau developers
> didn't ask for it to be merged in the first place.
> 

*Someone* on the Red Hat/Fedora team made the decision to make it
available on a very popular distribution to get more testing.  And
they did it without putting in the necessary versioning so that kernel
testers could test upstream kernels.  That, in my book, is an
anti-social thing to do.  Fedora isn't alone, of course; Ubuntu does
this as well, and worse yet, with proprietary binary drivers.  But
just because Ubuntu does something worse, doesn't mean that Fedora
should get a free pass for what they did.

						- Ted

Re: [git pull] drm request 3

[tytso]

On Sat, Mar 06, 2010 at 08:52:35PM +0000, Alan Cox wrote:
> > They want the benefits of lots of testers, without wanting to be
> > courteous to those testers.
> 
> Except for the small rather important detail that the Nouveau developers
> didn't ask for it to be merged in the first place.
> 

*Someone* on the Red Hat/Fedora team made the decision to make it
available on a very popular distribution to get more testing.  And
they did it without putting in the necessary versioning so that kernel
testers could test upstream kernels.  That, in my book, is an
anti-social thing to do.  Fedora isn't alone, of course; Ubuntu does
this as well, and worse yet, with proprietary binary drivers.  But
just because Ubuntu does something worse, doesn't mean that Fedora
should get a free pass for what they did.

						- Ted

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Maarten Maathuis]

On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> Hmm. What the hell am I supposed to do about
>
>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>        (EE) NOUVEAU(0): 879:
>
> now?
>
> What happened to the whole backwards compatibility thing? I wasn't even
> warned that this breaks existing user space. That makes it impossible to
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
> model, lots of people are just using some random distribution (F12 in my
> case), and you just broke it.
>
> I see the commit that does this was very aware of it:
>
>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>        Author: Ben Skeggs <bskeggs@redhat.com>
>        Date:   Fri Feb 12 10:27:35 2010 +1000
>
>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>
>            This commit breaks the userspace interface, and requires a new libdrm for
>            nouveau to operate again.
>
>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>            compatibility purposes are now gone, and replaced with the new ioctl which
>            allows for multiple push buffers to be submitted (necessary for hw index
>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>
>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>            for userspace modesetting have also been removed.
>
>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.
>
> We can't just go around breaking peoples setups. This driver is, like it
> or not, used by Fedora-12 (and probably other distros). It may say
> "staging", but that doesn't change the fact that it's in production use by
> huge distributions. Flag days aren't acceptable.
>
>                Linus
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

What i'm about to say is my personal opinion, not that of nouveau as a
whole (not even sure if such a thing exists).

1. We are in staging because our abi isn't final yet.
2. We (already) adjusted our way of working to ensure we have a usable
and proper codebase by the time we are ready for mainline.
3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree).
4. You are forcing red hat to force something on the rest of us.
5. I for one am happy we keep a clean api.
6. We keep an internal kernel tree that is tested to some degree (in
this case the abi break was in there for a few weeks iirc) none of the
developers asked for a revert.
7. Everyone (users, distros) are (or should) be aware of the nature of
this driver, our userspace interface is experimental for that very
reason.
8. Experience has tought me that in the case of nouveau, if a
developer isn't using a codepath it will bitrot.

So please, also take into consideration that this project isn't solely
made by red hat and it's usually the other people that get to keep the
pieces.

Sincerely,

Maarten Maathuis.

Re: [git pull] drm request 3

[Maarten Maathuis]

On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> Hmm. What the hell am I supposed to do about
>
>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>        (EE) NOUVEAU(0): 879:
>
> now?
>
> What happened to the whole backwards compatibility thing? I wasn't even
> warned that this breaks existing user space. That makes it impossible to
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
> model, lots of people are just using some random distribution (F12 in my
> case), and you just broke it.
>
> I see the commit that does this was very aware of it:
>
>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>        Author: Ben Skeggs <bskeggs@redhat.com>
>        Date:   Fri Feb 12 10:27:35 2010 +1000
>
>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>
>            This commit breaks the userspace interface, and requires a new libdrm for
>            nouveau to operate again.
>
>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>            compatibility purposes are now gone, and replaced with the new ioctl which
>            allows for multiple push buffers to be submitted (necessary for hw index
>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>
>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>            for userspace modesetting have also been removed.
>
>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.
>
> We can't just go around breaking peoples setups. This driver is, like it
> or not, used by Fedora-12 (and probably other distros). It may say
> "staging", but that doesn't change the fact that it's in production use by
> huge distributions. Flag days aren't acceptable.
>
>                Linus
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

What i'm about to say is my personal opinion, not that of nouveau as a
whole (not even sure if such a thing exists).

1. We are in staging because our abi isn't final yet.
2. We (already) adjusted our way of working to ensure we have a usable
and proper codebase by the time we are ready for mainline.
3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree).
4. You are forcing red hat to force something on the rest of us.
5. I for one am happy we keep a clean api.
6. We keep an internal kernel tree that is tested to some degree (in
this case the abi break was in there for a few weeks iirc) none of the
developers asked for a revert.
7. Everyone (users, distros) are (or should) be aware of the nature of
this driver, our userspace interface is experimental for that very
reason.
8. Experience has tought me that in the case of nouveau, if a
developer isn't using a codepath it will bitrot.

So please, also take into consideration that this project isn't solely
made by red hat and it's usually the other people that get to keep the
pieces.

Sincerely,

Maarten Maathuis.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Maarten Maathuis]

On Thu, Mar 4, 2010 at 10:21 PM, Maarten Maathuis <madman2003@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>>
>> Hmm. What the hell am I supposed to do about
>>
>>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>>        (EE) NOUVEAU(0): 879:
>>
>> now?
>>
>> What happened to the whole backwards compatibility thing? I wasn't even
>> warned that this breaks existing user space. That makes it impossible to
>> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
>> model, lots of people are just using some random distribution (F12 in my
>> case), and you just broke it.
>>
>> I see the commit that does this was very aware of it:
>>
>>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>>        Author: Ben Skeggs <bskeggs@redhat.com>
>>        Date:   Fri Feb 12 10:27:35 2010 +1000
>>
>>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>>
>>            This commit breaks the userspace interface, and requires a new libdrm for
>>            nouveau to operate again.
>>
>>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>>            compatibility purposes are now gone, and replaced with the new ioctl which
>>            allows for multiple push buffers to be submitted (necessary for hw index
>>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>>
>>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>>            for userspace modesetting have also been removed.
>>
>>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>>
>> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
>> probably wouldn't have pulled it.
>>
>> We can't just go around breaking peoples setups. This driver is, like it
>> or not, used by Fedora-12 (and probably other distros). It may say
>> "staging", but that doesn't change the fact that it's in production use by
>> huge distributions. Flag days aren't acceptable.
>>
>>                Linus
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> --
>> _______________________________________________
>> Dri-devel mailing list
>> Dri-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>>
>
> What i'm about to say is my personal opinion, not that of nouveau as a
> whole (not even sure if such a thing exists).
>
> 1. We are in staging because our abi isn't final yet.
> 2. We (already) adjusted our way of working to ensure we have a usable
> and proper codebase by the time we are ready for mainline.
> 3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree).
> 4. You are forcing red hat to force something on the rest of us.
> 5. I for one am happy we keep a clean api.
> 6. We keep an internal kernel tree that is tested to some degree (in
> this case the abi break was in there for a few weeks iirc) none of the
> developers asked for a revert.

Point 6 is iirc, someone can correct me if this is not the case.

> 7. Everyone (users, distros) are (or should) be aware of the nature of
> this driver, our userspace interface is experimental for that very
> reason.
> 8. Experience has tought me that in the case of nouveau, if a
> developer isn't using a codepath it will bitrot.
>
> So please, also take into consideration that this project isn't solely
> made by red hat and it's usually the other people that get to keep the
> pieces.
>
> Sincerely,
>
> Maarten Maathuis.
>

Re: [git pull] drm request 3

[Maarten Maathuis]

On Thu, Mar 4, 2010 at 10:21 PM, Maarten Maathuis <madman2003@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>>
>> Hmm. What the hell am I supposed to do about
>>
>>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>>        (EE) NOUVEAU(0): 879:
>>
>> now?
>>
>> What happened to the whole backwards compatibility thing? I wasn't even
>> warned that this breaks existing user space. That makes it impossible to
>> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
>> model, lots of people are just using some random distribution (F12 in my
>> case), and you just broke it.
>>
>> I see the commit that does this was very aware of it:
>>
>>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>>        Author: Ben Skeggs <bskeggs@redhat.com>
>>        Date:   Fri Feb 12 10:27:35 2010 +1000
>>
>>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>>
>>            This commit breaks the userspace interface, and requires a new libdrm for
>>            nouveau to operate again.
>>
>>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>>            compatibility purposes are now gone, and replaced with the new ioctl which
>>            allows for multiple push buffers to be submitted (necessary for hw index
>>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>>
>>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>>            for userspace modesetting have also been removed.
>>
>>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>>
>> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
>> probably wouldn't have pulled it.
>>
>> We can't just go around breaking peoples setups. This driver is, like it
>> or not, used by Fedora-12 (and probably other distros). It may say
>> "staging", but that doesn't change the fact that it's in production use by
>> huge distributions. Flag days aren't acceptable.
>>
>>                Linus
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> --
>> _______________________________________________
>> Dri-devel mailing list
>> Dri-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>>
>
> What i'm about to say is my personal opinion, not that of nouveau as a
> whole (not even sure if such a thing exists).
>
> 1. We are in staging because our abi isn't final yet.
> 2. We (already) adjusted our way of working to ensure we have a usable
> and proper codebase by the time we are ready for mainline.
> 3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree).
> 4. You are forcing red hat to force something on the rest of us.
> 5. I for one am happy we keep a clean api.
> 6. We keep an internal kernel tree that is tested to some degree (in
> this case the abi break was in there for a few weeks iirc) none of the
> developers asked for a revert.

Point 6 is iirc, someone can correct me if this is not the case.

> 7. Everyone (users, distros) are (or should) be aware of the nature of
> this driver, our userspace interface is experimental for that very
> reason.
> 8. Experience has tought me that in the case of nouveau, if a
> developer isn't using a codepath it will bitrot.
>
> So please, also take into consideration that this project isn't solely
> made by red hat and it's usually the other people that get to keep the
> pieces.
>
> Sincerely,
>
> Maarten Maathuis.
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Maarten Maathuis]

On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> Hmm. What the hell am I supposed to do about
>
>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>        (EE) NOUVEAU(0): 879:
>
> now?

You can update your userspace components. No compatibility is offered
between versions in any direction.

>
> What happened to the whole backwards compatibility thing? I wasn't even
> warned that this breaks existing user space. That makes it impossible to
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
> model, lots of people are just using some random distribution (F12 in my
> case), and you just broke it.
>
> I see the commit that does this was very aware of it:
>
>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>        Author: Ben Skeggs <bskeggs@redhat.com>
>        Date:   Fri Feb 12 10:27:35 2010 +1000
>
>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>
>            This commit breaks the userspace interface, and requires a new libdrm for
>            nouveau to operate again.
>
>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>            compatibility purposes are now gone, and replaced with the new ioctl which
>            allows for multiple push buffers to be submitted (necessary for hw index
>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>
>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>            for userspace modesetting have also been removed.
>
>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.
>
> We can't just go around breaking peoples setups. This driver is, like it
> or not, used by Fedora-12 (and probably other distros). It may say
> "staging", but that doesn't change the fact that it's in production use by
> huge distributions. Flag days aren't acceptable.
>
>                Linus
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Maarten Maathuis]

On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> Hmm. What the hell am I supposed to do about
>
>        (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
>        (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
>        (EE) NOUVEAU(0): 879:
>
> now?

You can update your userspace components. No compatibility is offered
between versions in any direction.

>
> What happened to the whole backwards compatibility thing? I wasn't even
> warned that this breaks existing user space. That makes it impossible to
> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid
> model, lots of people are just using some random distribution (F12 in my
> case), and you just broke it.
>
> I see the commit that does this was very aware of it:
>
>        commit a1606a9596e54da90ad6209071b357a4c1b0fa82
>        Author: Ben Skeggs <bskeggs@redhat.com>
>        Date:   Fri Feb 12 10:27:35 2010 +1000
>
>            drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>
>            This commit breaks the userspace interface, and requires a new libdrm for
>            nouveau to operate again.
>
>            The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
>            compatibility purposes are now gone, and replaced with the new ioctl which
>            allows for multiple push buffers to be submitted (necessary for hw index
>            buffers in the nv50 3d driver) and relocations to be applied on any buffer.
>
>            A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
>            for userspace modesetting have also been removed.
>
>            Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>            Signed-off-by: Francisco Jerez <currojerez@riseup.net>
>
> but why the hell wasn't I made aware of it before-hand? Quite frankly, I
> probably wouldn't have pulled it.
>
> We can't just go around breaking peoples setups. This driver is, like it
> or not, used by Fedora-12 (and probably other distros). It may say
> "staging", but that doesn't change the fact that it's in production use by
> huge distributions. Flag days aren't acceptable.
>
>                Linus
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Re: [git pull] drm request 3

[Linus Torvalds]

Hmm. What the hell am I supposed to do about

	(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
	(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
	(EE) NOUVEAU(0): 879:

now?

What happened to the whole backwards compatibility thing? I wasn't even 
warned that this breaks existing user space. That makes it impossible to 
_test_ new kernels. Upgrading X and the kernel in lock-step is not a valid 
model, lots of people are just using some random distribution (F12 in my 
case), and you just broke it.

I see the commit that does this was very aware of it:

	commit a1606a9596e54da90ad6209071b357a4c1b0fa82
	Author: Ben Skeggs <bskeggs@redhat.com>
	Date:   Fri Feb 12 10:27:35 2010 +1000

	    drm/nouveau: new gem pushbuf interface, bump to 0.0.16

	    This commit breaks the userspace interface, and requires a new libdrm for
	    nouveau to operate again.

	    The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
	    compatibility purposes are now gone, and replaced with the new ioctl which
	    allows for multiple push buffers to be submitted (necessary for hw index
	    buffers in the nv50 3d driver) and relocations to be applied on any buffer.

	    A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed
	    for userspace modesetting have also been removed.

	    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
	    Signed-off-by: Francisco Jerez <currojerez@riseup.net>

but why the hell wasn't I made aware of it before-hand? Quite frankly, I 
probably wouldn't have pulled it.

We can't just go around breaking peoples setups. This driver is, like it 
or not, used by Fedora-12 (and probably other distros). It may say 
"staging", but that doesn't change the fact that it's in production use by 
huge distributions. Flag days aren't acceptable.

		Linus

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Jonas Ritz]

guys...

Some stages of development of software requires the change API.

fx. the initial phase or clean up phase.

The use of software (or development of dependent software) requires a 
predictable API.

To do both effectively, the community needs to invent a tool that keeps 
track of what version userspace code the kernel needs, and a formalized 
directory structure for staging/oldies code.

[git pull] drm request 3

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 20039 bytes --]


Fixes for default y + CONFIG_STAGING + CONFIG_DRM_NOUVEAU enabled.

Dave.

The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
  Linus Torvalds (1):
        Linux 2.6.33

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

Alex Deucher (34):
      drm/radeon/kms: add radeon i2c algo
      drm/radeon/kms: add support for hw i2c on r1xx-r5xx
      drm/radeon/kms: add workaround for rn50/rv100 servers
      drm/radeon/kms: add support for hardcoded edids in rom (v2)
      drm/radeon/kms: clean up some low-hanging magic numbers
      drm/radeon/kms: rework pll algo selection
      drm/radeon/kms: add pll quirk for toshiba laptop panel
      drm/radeon/kms/atom: clean up spread spectrum code
      drm/radeon/kms/atom: add a helper function to get the radeon connector priv
      drm/radeon/kms/r600: reduce gpu cache flushing
      drm/radeon/kms: consolidate crtc count in rdev
      drm/radeon/kms: add functions to get current pcie lanes
      drm/radeon/kms: pull power mode info from bios tables (v3)
      drm/radeon/kms: add a power state type based on power state flags
      drm/radeon/kms: add code to select power state
      drm/radeon/kms: use power states for dynamic reclocking
      drm/radeon/kms: dynclks fixes
      drm/radeon/kms: take the pm mutex when using hw i2c
      drm/radeon/kms: update atombios.h to latest upstream.
      drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx)
      drm/radeon/kms: fix prescale calculations
      drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE
      drm/radeon/kms/evergreen: fix multi-head
      drm/radeon/kms/evergreen: adapt to i2c changes
      drm/radeon/r600: fix warnings in CS checker
      drm/radeon/kms: add LVDS pll quirk for Dell Studio 15
      drm/radeon/kms: remove HDP flushes from fence emit (v2)
      drm/radeon/kms: remove unused r600_gart_clear_page
      drm/radeon/rv740: fix backend setup
      drm/radeon: fixes for r6xx/r7xx gfx init
      drm/radeon/kms/evergreen: fix typo in cursor code
      drm/radeon/kms: update new pll algo
      drm/radeon/kms/atom: fix shr/shl ops
      drm/radeon: fix typo in Makefile

Andy Shevchenko (1):
      drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi()

Ben Skeggs (17):
      drm/nv50: switch to indirect push buffer controls
      drm/nouveau: remove PUSHBUF_CAL macro
      drm/nv50: make pushbuf dma object cover entire vm
      drm/nouveau: new gem pushbuf interface, bump to 0.0.16
      drm/nouveau: allow retrieval of vbios image from debugfs
      drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table
      drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table
      drm/nouveau: merge nvbios and nouveau_bios_info
      drm/nouveau: reorganise bios header, add dcb connector type enums
      drm/nouveau: parse dcb gpio/connector tables after encoders
      drm/nouveau: check for known dcb connector types
      drm/nouveau: construct a connector table for cards that lack a real one
      drm/nouveau: use dcb connector table for creating drm connectors
      drm/nv50: enable hpd on any connector we know the gpio line for
      drm/nouveau: use dcb connector types throughout the driver
      drm/nouveau: support version 0x20 displayport tables
      drm/nouveau: report unknown connector state if lid closed

Chris Wilson (2):
      drm/i915: Replace open-coded eviction in i915_gem_idle()
      drm/i915: Record batch buffer following GPU error

Daniel Vetter (11):
      drm/i915: overlay: nuke readback to flush wc caches
      drm/i915: overlay: drop superflous gpu flushes
      drm/i915: move a gtt flush to the correct place
      drm/i915: blow away userspace mappings before fence change
      drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code
      drm/i915: fixup active list locking in object_unbind
      drm/i915: extract fence stealing code
      drm/i915: ensure lru ordering of fence_list
      drm/i915: reuse i915_gpu_idle helper
      drm/i915: clean-up i915_gem_flush_gpu_write_domain
      drm/i915: check for multiple write domains in pin_and_relocate

Dave Airlie (23):
      drm/radeon/kms: switch all KMS driver ioctls to unlocked.
      drm/radeon/kms: use udelay for short delays
      drm: switch all GEM/KMS ioctls to unlocked ioctl status.
      drm/kms: fix fb_changed = true else statement
      drm/radeon/kms: check for valid PCI bios and not OF rom
      drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page
      drm/radeon/kms: flush HDP cache on GART table updates.
      [rfc] drm/radeon/kms: pm debugging check for vbl.
      Merge remote branch 'korg/drm-core-next' into drm-next-stage
      Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
      fb: for framebuffer handover don't exit the loop early.
      Merge remote branch 'korg/drm-radeon-testing' into drm-next-stage
      Merge remote branch 'korg/drm-core-next' into drm-next-stage
      Merge remote branch 'nouveau/for-airlied' into drm-next-stage
      Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
      drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond
      Merge branch 'drm-radeon-testing' of /ssd/git/drm-radeon-next into drm-next-stage
      vga_switcheroo: initial implementation (v15)
      Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage
      drm/radeon/kms: bump the KMS version number for square tiling support.
      vga_switcheroo: fix build on platforms with no ACPI
      drm/nouveau: fix *staging* driver build with switcheroo off.
      vga_switcheroo: disable default y by new rules.

Eric Anholt (13):
      drm/i915: Don't reserve compatibility fence regs in KMS mode.
      agp/intel: Add support for Sandybridge.
      drm/i915: Add initial bits for VGA modesetting bringup on Sandybridge.
      drm/i915: Set up fence registers on sandybridge.
      drm/i915: Fix sandybridge status page setup.
      agp/intel: Use a non-reserved value for the cache field of the PTEs.
      drm/i915: Disable the surface tile swizzling on Sandybridge.
      drm/i915: Correct locking in the modesetting failure path, fixing a BUG_ON.
      agp/intel: Add a new Sandybridge HB/IG PCI ID combo.
      drm/i915: Add a new mobile Sandybridge PCI ID.
      drm/i915: Disable the hangcheck reset on Sandybridge until we add support.
      drm/i915: Correct the Sandybridge chipset info structs.
      drm/i915: More s/IS_IRONLAKE/HAS_PCH_SPLIT for Sandybridge.

Jerome Glisse (9):
      drm/radeon/kms: bogus cs recorder utilities
      drm/radeon/kms: r600/r700 command stream checker
      drm/radeon/kms: fix r600/r700 cs checker to avoid double kfree
      drm/radeon/kms: fix indirect buffer management V2
      drm/radeon/kms: fix bo's fence association
      drm/radeon/kms: simplify memory controller setup V2
      drm/radeon/kms: fix R3XX/R4XX memory controller initialization
      drm/radeon/kms: force pinning buffer into visible VRAM
      drm/radeon/kms: initialize set_surface_reg reg for rs600 asic

Jesse Barnes (6):
      drm/i915: add dynamic performance control support for Ironlake
      drm/i915: fix drps disable so unload & re-load works
      drm/i915: provide FBC status in debugfs
      drm/i915: provide self-refresh status in debugfs
      drm/i915: give up on 8xx lid status
      drm/i915: enable/disable LVDS port at DPMS time

Li Peng (2):
      drm/i915: enable memory self refresh on 9xx
      drm/i915: Fix OGLC performance regression on 945

Luca Barbieri (3):
      drm: introduce drm_gem_object_[handle_]unreference_unlocked
      Use drm_gem_object_[handle_]unreference_unlocked where possible
      drm/nouveau: fix missing spin_unlock in failure path

Maarten Maathuis (2):
      drm/ttm: handle OOM in ttm_tt_swapout
      drm/nouveau: protect channel create/destroy and irq handler with a spinlock

Marcin Kościelnicki (2):
      drm/nv50: Implement ctxprog/state generation.
      drm/nouveau: Fix noaccel/nofbaccel option descriptions.

Marcin Slusarz (3):
      drm/nouveau: fix pramdac_table range checking
      drm/nouveau: fix nouveau_i2c_find bounds checking
      drm/nouveau: fix i2ctable bounds checking

Marek Olšák (1):
      drm/radeon/kms: add support for square microtiles on r3xx-r5xx

Matt Turner (2):
      drm/nouveau: use ALIGN instead of open coding it
      drm/radeon: use ALIGN instead of open coding it

Matthew Garrett (1):
      drm/i915: Deobfuscate the render p-state obfuscation

Michel Dänzer (1):
      drm/radeon/kms: Test rdev->bios centrally in combios_get_table_offset().

Owain Ainsworth (1):
      drm/i915: reduce some of the duplication of tiling checking

Pauli Nieminen (5):
      drm/radeon/kms: Create asic structure for r300 pcie cards.
      drm/radeon: Add asic hook for dma copy to r200 cards.
      drm: Add generic multipart buffer.
      drm/radeon: Fix memory allocation failures in the preKMS command stream checking.
      drm/radeon: Fix printf type warning in 64bit system.

Pavel Roskin (1):
      drm/kms: fix spelling of "CLOCK"

Rafał Miłecki (13):
      drm/radeon/kms: add dynamic engine reclocking (V9)
      drm/radeon/kms: don't set pcie lanes for ignored power_state
      drm/radeon/kms: get_power_state early, not when processing IRQ
      drm/radeon/kms: use wait queue (events) for VBLANK sync
      drm/radeon/kms: isolate audio engine management, change fini order
      drm/radeon/kms: accept slightly overclocked power modes
      drm/radeon/kms: simplify picking power state
      drm/radeon/kms: simplify storing current and requested PM mode
      drm/radeon/kms: for downclocking non-mobility check PERFORMANCE state
      drm/radeon/kms: implement reading active PCIE lanes on R600+
      drm/radeon/kms: do not preset audio stuff and start timer when not using audio
      Revert "drm/radeon/kms: disable HDMI audio for now on rv710/rv730"
      drm/radeon/kms: do not disable audio engine twice

Randy Dunlap (1):
      drm/ttm: fix function prototype to match implementation

Zhao Yakui (1):
      drm/i915: Use a dmi quirk to skip a broken SDVO TV output.

Zhenyu Wang (4):
      drm/i915: Keep MCHBAR always enabled
      agp/intel: official names for Pineview and Ironlake
      drm/i915, agp/intel: Fix stolen memory size on Sandybridge
      drm/i915: Add dependency on the intel agp module

 drivers/char/agp/intel-agp.c                    |  123 +-
 drivers/gpu/drm/Makefile                        |    2 +-
 drivers/gpu/drm/drm_buffer.c                    |  184 +
 drivers/gpu/drm/drm_crtc_helper.c               |    6 +-
 drivers/gpu/drm/drm_drv.c                       |   44 +-
 drivers/gpu/drm/drm_edid.c                      |   30 +-
 drivers/gpu/drm/drm_fb_helper.c                 |   26 +-
 drivers/gpu/drm/drm_gem.c                       |   70 +-
 drivers/gpu/drm/i915/i915_debugfs.c             |  253 +-
 drivers/gpu/drm/i915/i915_dma.c                 |  326 +-
 drivers/gpu/drm/i915/i915_drv.c                 |   27 +-
 drivers/gpu/drm/i915/i915_drv.h                 |   69 +-
 drivers/gpu/drm/i915/i915_gem.c                 |  430 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c          |  169 +-
 drivers/gpu/drm/i915/i915_irq.c                 |  313 +-
 drivers/gpu/drm/i915/i915_reg.h                 |  170 +-
 drivers/gpu/drm/i915/i915_suspend.c             |   10 +
 drivers/gpu/drm/i915/intel_bios.c               |    3 +-
 drivers/gpu/drm/i915/intel_crt.c                |   14 +-
 drivers/gpu/drm/i915/intel_display.c            |  216 +-
 drivers/gpu/drm/i915/intel_dp.c                 |    6 +-
 drivers/gpu/drm/i915/intel_drv.h                |    2 +
 drivers/gpu/drm/i915/intel_fb.c                 |    2 +
 drivers/gpu/drm/i915/intel_hdmi.c               |    4 +-
 drivers/gpu/drm/i915/intel_i2c.c                |    2 +-
 drivers/gpu/drm/i915/intel_lvds.c               |   41 +-
 drivers/gpu/drm/i915/intel_overlay.c            |   29 +-
 drivers/gpu/drm/i915/intel_sdvo.c               |   23 +-
 drivers/gpu/drm/nouveau/Makefile                |    2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c          |  160 +-
 drivers/gpu/drm/nouveau/nouveau_bios.c          |  339 +-
 drivers/gpu/drm/nouveau/nouveau_bios.h          |  126 +-
 drivers/gpu/drm/nouveau/nouveau_calc.c          |    4 +-
 drivers/gpu/drm/nouveau/nouveau_channel.c       |   39 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c     |  167 +-
 drivers/gpu/drm/nouveau/nouveau_connector.h     |    3 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c       |   24 +
 drivers/gpu/drm/nouveau/nouveau_display.c       |    7 +-
 drivers/gpu/drm/nouveau/nouveau_dma.c           |  108 +-
 drivers/gpu/drm/nouveau/nouveau_dma.h           |   21 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c           |   13 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h           |   53 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c         |    6 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c           |  508 +-
 drivers/gpu/drm/nouveau/nouveau_hw.c            |    6 +-
 drivers/gpu/drm/nouveau/nouveau_i2c.c           |   10 +-
 drivers/gpu/drm/nouveau/nouveau_irq.c           |    5 +
 drivers/gpu/drm/nouveau/nouveau_notifier.c      |    9 +-
 drivers/gpu/drm/nouveau/nouveau_state.c         |   40 +-
 drivers/gpu/drm/nouveau/nv04_crtc.c             |    4 +-
 drivers/gpu/drm/nouveau/nv04_dac.c              |    8 +-
 drivers/gpu/drm/nouveau/nv04_dfp.c              |    4 +-
 drivers/gpu/drm/nouveau/nv04_display.c          |   49 +-
 drivers/gpu/drm/nouveau/nv04_fbcon.c            |    2 +-
 drivers/gpu/drm/nouveau/nv04_fifo.c             |    5 +
 drivers/gpu/drm/nouveau/nv04_tv.c               |    2 +-
 drivers/gpu/drm/nouveau/nv17_tv.c               |    6 +-
 drivers/gpu/drm/nouveau/nv40_fifo.c             |    5 +
 drivers/gpu/drm/nouveau/nv50_crtc.c             |    4 +-
 drivers/gpu/drm/nouveau/nv50_dac.c              |    4 +-
 drivers/gpu/drm/nouveau/nv50_display.c          |   54 +-
 drivers/gpu/drm/nouveau/nv50_fbcon.c            |    2 +-
 drivers/gpu/drm/nouveau/nv50_fifo.c             |   13 +-
 drivers/gpu/drm/nouveau/nv50_graph.c            |   74 +-
 drivers/gpu/drm/nouveau/nv50_grctx.c            | 2367 ++++++++
 drivers/gpu/drm/nouveau/nv50_instmem.c          |    2 +-
 drivers/gpu/drm/radeon/Makefile                 |    9 +-
 drivers/gpu/drm/radeon/atom.c                   |    4 -
 drivers/gpu/drm/radeon/atombios.h               | 7300 +++++++++++++----------
 drivers/gpu/drm/radeon/atombios_crtc.c          |  456 ++-
 drivers/gpu/drm/radeon/atombios_dp.c            |   64 +-
 drivers/gpu/drm/radeon/avivod.h                 |    2 +
 drivers/gpu/drm/radeon/evergreen.c              |  767 +++
 drivers/gpu/drm/radeon/evergreen_reg.h          |  176 +
 drivers/gpu/drm/radeon/r100.c                   |  176 +-
 drivers/gpu/drm/radeon/r200.c                   |   46 +
 drivers/gpu/drm/radeon/r300.c                   |  157 +-
 drivers/gpu/drm/radeon/r300_cmdbuf.c            |  280 +-
 drivers/gpu/drm/radeon/r300_reg.h               |    2 +
 drivers/gpu/drm/radeon/r420.c                   |   49 +-
 drivers/gpu/drm/radeon/r500_reg.h               |  100 +-
 drivers/gpu/drm/radeon/r520.c                   |   21 +-
 drivers/gpu/drm/radeon/r600.c                   |  190 +-
 drivers/gpu/drm/radeon/r600_audio.c             |   21 +-
 drivers/gpu/drm/radeon/r600_blit.c              |    2 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c          |   17 +-
 drivers/gpu/drm/radeon/r600_blit_shaders.c      |   10 -
 drivers/gpu/drm/radeon/r600_cp.c                |  262 +-
 drivers/gpu/drm/radeon/r600_cs.c                |  831 +++-
 drivers/gpu/drm/radeon/r600d.h                  |  467 ++-
 drivers/gpu/drm/radeon/radeon.h                 |  167 +-
 drivers/gpu/drm/radeon/radeon_agp.c             |    4 +
 drivers/gpu/drm/radeon/radeon_asic.h            |  172 +-
 drivers/gpu/drm/radeon/radeon_atombios.c        |  435 ++-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c    |  257 +
 drivers/gpu/drm/radeon/radeon_bios.c            |   50 +-
 drivers/gpu/drm/radeon/radeon_clocks.c          |   18 +-
 drivers/gpu/drm/radeon/radeon_combios.c         |  290 +-
 drivers/gpu/drm/radeon/radeon_connectors.c      |   20 +-
 drivers/gpu/drm/radeon/radeon_cp.c              |    1 +
 drivers/gpu/drm/radeon/radeon_cs.c              |    7 +-
 drivers/gpu/drm/radeon/radeon_cursor.c          |   50 +-
 drivers/gpu/drm/radeon/radeon_device.c          |  235 +-
 drivers/gpu/drm/radeon/radeon_display.c         |  332 +-
 drivers/gpu/drm/radeon/radeon_drv.c             |   14 +-
 drivers/gpu/drm/radeon/radeon_drv.h             |   46 +-
 drivers/gpu/drm/radeon/radeon_encoders.c        |  354 +-
 drivers/gpu/drm/radeon/radeon_family.h          |    5 +
 drivers/gpu/drm/radeon/radeon_fb.c              |   12 +-
 drivers/gpu/drm/radeon/radeon_gart.c            |   32 +-
 drivers/gpu/drm/radeon/radeon_gem.c             |   36 +-
 drivers/gpu/drm/radeon/radeon_i2c.c             |  768 +++-
 drivers/gpu/drm/radeon/radeon_kms.c             |   27 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c     |   29 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   20 +
 drivers/gpu/drm/radeon/radeon_mode.h            |   55 +-
 drivers/gpu/drm/radeon/radeon_object.c          |    3 +-
 drivers/gpu/drm/radeon/radeon_pm.c              |  399 ++-
 drivers/gpu/drm/radeon/radeon_reg.h             |   50 +-
 drivers/gpu/drm/radeon/radeon_ring.c            |   67 +
 drivers/gpu/drm/radeon/radeon_state.c           |  203 +-
 drivers/gpu/drm/radeon/radeon_test.c            |    2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c             |   12 +-
 drivers/gpu/drm/radeon/reg_srcs/r600            |  837 +++
 drivers/gpu/drm/radeon/rs400.c                  |   39 +-
 drivers/gpu/drm/radeon/rs600.c                  |   56 +-
 drivers/gpu/drm/radeon/rs690.c                  |   41 +-
 drivers/gpu/drm/radeon/rv515.c                  |   21 +-
 drivers/gpu/drm/radeon/rv770.c                  |  259 +-
 drivers/gpu/drm/radeon/rv770d.h                 |    2 +
 drivers/gpu/drm/ttm/ttm_tt.c                    |   18 +-
 drivers/gpu/vga/Kconfig                         |   12 +
 drivers/gpu/vga/Makefile                        |    1 +
 drivers/gpu/vga/vga_switcheroo.c                |  450 ++
 drivers/video/console/fbcon.c                   |   18 +
 drivers/video/fbmem.c                           |    1 -
 include/drm/drmP.h                              |   28 +-
 include/drm/drm_buffer.h                        |  148 +
 include/drm/drm_crtc.h                          |    2 +
 include/drm/drm_edid.h                          |    3 +
 include/drm/drm_pciids.h                        |   36 +
 include/drm/nouveau_drm.h                       |   86 +-
 include/drm/radeon_drm.h                        |    1 +
 include/drm/ttm/ttm_bo_driver.h                 |    2 +-
 include/linux/fb.h                              |    2 +
 include/linux/vga_switcheroo.h                  |   57 +
 146 files changed, 18176 insertions(+), 6374 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_buffer.c
 create mode 100644 drivers/gpu/drm/nouveau/nv50_grctx.c
 create mode 100644 drivers/gpu/drm/radeon/evergreen.c
 create mode 100644 drivers/gpu/drm/radeon/evergreen_reg.h
 create mode 100644 drivers/gpu/drm/radeon/radeon_atpx_handler.c
 create mode 100644 drivers/gpu/drm/radeon/reg_srcs/r600
 create mode 100644 drivers/gpu/vga/vga_switcheroo.c
 create mode 100644 include/drm/drm_buffer.h
 create mode 100644 include/linux/vga_switcheroo.h

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel