[git pull] drm request 3
Dave Airlie
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
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 <bsk...@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 <bsk...@redhat.com>
Signed-off-by: Francisco Jerez <curro...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Barnes
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
Matt Turner
<torv...@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
Jesse Barnes
Jesse Barnes <jba...@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.
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 <bsk...@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 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
Matthew Garrett
> 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 | mj...@srcf.ucam.org
Jesse Barnes
Linus Torvalds <torv...@linux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Jesse Barnes wrote:
>
> > On Thu, 4 Mar 2010 10:36:55 -0800
> > Jesse Barnes <jba...@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.
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
Linus Torvalds
On Thu, 4 Mar 2010, Jesse Barnes wrote:
> On Thu, 4 Mar 2010 10:36:55 -0800
> Jesse Barnes <jba...@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
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 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
Matthew Garrett
> 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 | mj...@srcf.ucam.org
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
Matthew Garrett
> 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 | mj...@srcf.ucam.org
Matthew Garrett
>
>
> 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 | mj...@srcf.ucam.org
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.
Jeff Garzik
> "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
Jesse Barnes
Linus Torvalds <torv...@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
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
Matthew Garrett
> 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 | mj...@srcf.ucam.org
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
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
Matthew Garrett
> 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 | mj...@srcf.ucam.org
Stephane Marchesin
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
Maarten Maathuis
> 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-...@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.
Maarten Maathuis
<torv...@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.
Maarten Maathuis
Point 6 is iirc, someone can correct me if this is not the case.
Adam Jackson
> 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
Dave Airlie
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.
Adam Jackson
> 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
Jeff Garzik
> 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.
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
Adam Jackson
> > # 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
Linus Torvalds
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.
Dave Airlie
<torv...@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.
Jesse Barnes
Linus Torvalds <torv...@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
Stephane Marchesin
<torv...@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
Dave Airlie
>> Its nouveau project not X not DRM, stop generalising the situation.
>
> 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.
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
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
Michel Dänzer
>
> 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
Dave Airlie
<torv...@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.
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
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
Ed Tomlinson
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
Kyle McMartin
> 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
Ben Skeggs
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-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
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
Luc Verhaegen
>
>
> > 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.
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
Kyle McMartin
> 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
Luc Verhaegen
>
>
> 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.
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
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 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
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.
Robert Hancock
> 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
Tony Luck
<torv...@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
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
Dave Airlie
<torv...@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.
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
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,
Ingo Molnar
* Ben Skeggs <ske...@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
Pekka Enberg
> 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
"C. Bergström"
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.
Ingo Molnar
* Pekka Enberg <pen...@cs.helsinki.fi> wrote:
> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mi...@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.
Ingo Molnar
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
Dave Airlie
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
Stephane Marchesin
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
Carlos R. Mafra
>
> 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.
Jeff Garzik
> 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
Alan Cox
Jeff Garzik <je...@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
Alan Cox
Why does Linus Torvalds not understand the Kconfig of his own staging
directory ?
Alan Cox
> 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 Cox
> 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
Valdis.K...@vt.edu
> 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
Luc Verhaegen
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.
David Miller
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?
Mike Galbraith
> From: Alan Cox <al...@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
Alan Cox
> 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
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
David Miller
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.
Matt Turner
> 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
David Miller
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.
Daniel Stone
> On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crma...@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
David Miller
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.
Daniel Stone
> 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
Daniel Stone
On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> From: Daniel Stone <dan...@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
Alan Cox
> 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
David Miller
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.
Adam Jackson
> 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 gf980
0
> > 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
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
Luca Barbieri
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.
David Miller
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.
Daniel Stone
> From: Daniel Stone <dan...@fooishbar.org>
> >> 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.
Alan Cox
David Miller <da...@davemloft.net> wrote:
> From: Daniel Stone <dan...@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
Daniel Stone
> From: Daniel Stone <dan...@fooishbar.org>
> > 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.
David Miller
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.