Bug 663745

No, that's _way_ too unstable for us to take at this point in time.

If you need this, then I suggest that you wait 3 months till it is in the .38 stable kernel, which will show up in Tumbleweed.

But for us to add this to our .37 kernel seems to be a very big effort, without much benefit at the moment.

(In reply to comment #1)
> No, that's _way_ too unstable for us to take at this point in time.
> 

I disagree:
I have used stable openSUSE, Kernel:HEAD and home:jobermayr (latest DRM code) for ~ 1 1/2 years. The only problems I have experienced during this time were crashes at an early point when openSUSE Kernel developers changed something in code. (see some bug reports or reports on mailing list)

> If you need this, then I suggest that you wait 3 months till it is in the .38
> stable kernel, which will show up in Tumbleweed.
> 

I do not think it is a good idea having a new system like AMD Fusion, Intel Sandy Brigde or a new graphic card supported by this commit and you cannot use it by default because openSUSE's kernel maintainers didn't pull and test a ~ 3 month old thing (at openSUSE 11.4 release time).

And note:
"13:53 #nouveau: < shining^> 'It's still way too much for a production system' - who said nouveau was ready for a production system ?"
(see: http://people.freedesktop.org/~cbrill/dri-log//dri-devel-2010-10-18.log)

> But for us to add this to our .37 kernel seems to be a very big effort, without
> much benefit at the moment.

I vote for including it since there are ~ 2 months left for testing.
If there are to much regressions it can also be removed before RC ...

You are asking us to blindly accept 390+ patches to our kernel tree, which is
not ok.

Supporting Sandy Bridge is a separate issue, and one that I think we already do, have you tested it out on the latest hardware?

Same goes for AMD Fusion, do you have test results for this?

We will be glad to entertain backporting _specific_ patches for _specific_ issues, especially for new hardware enablement that are also upstream.  Please
point out the ones that you feel are needed and we will consider them.  But
open new bug reports for them please, this one really is to vague.

Then please backport at least this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecf7ace9a8450303a987aa8364e53860cd50e554

It only provides an additional symbol which I need to build the DRM modules against Kernel:HEAD and Factory ...

(In reply to comment #4)
> Then please backport at least this commit:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecf7ace9a8450303a987aa8364e53860cd50e554
> 
> It only provides an additional symbol which I need to build the DRM modules
> against Kernel:HEAD and Factory ...

Factory kernel is now at 38-rc2. So you don't need this anymore, right?

AFAIK there have been always some users who have used Factory together with my packages (without Kernel:HEAD).
Since it does not change any other things (only provides one additional symbol) the backport is highly recommended.

Maybe we can also deliver 11.4 with my optional drm-radeon package (other name?) which is Dave Airlie's repository (maintainer of drivers/gpu).
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-fixes

Advanced users/enthusiasts can then easily use latest graphic stack ...

I would create a merge request for you but since you disabled it on gitorious.org ...

But I assume openSUSE is not as open as officials propagate all time ...

Reopen it ...

I don't understand what do you want from us here. Kernel:HEAD is constantly submitted to the factory. So with the next submission, it will be 38-rc2 (or later) which already contains the commit you mention.

I think, there is no problem to backport the commit to 11.4. But you can easily have the function as a part of your package, can't you?

Nope. Kernel:openSUSE-11.4 (2.6.37) will be base for next release:
http://lists.opensuse.org/opensuse-kernel/2011-01/msg00112.html

So I want this:

> Then please backport at least this commit:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecf7ace9a8450303a987aa8364e53860cd50e554
>
> It only provides an additional symbol which I need to build the DRM modules
> against Kernel:HEAD and Factory ...

-> Now I need it only for Factory ...

and this:

> Maybe we can also deliver 11.4 with my optional drm-radeon package (other
name?) which is Dave Airlie's repository (maintainer of drivers/gpu).
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-fixes

-> This package provides the latest drm code ...

But maybe some people speak another language than English here ...

(In reply to comment #9)
> Nope. Kernel:openSUSE-11.4 (2.6.37) will be base for next release:
> http://lists.opensuse.org/opensuse-kernel/2011-01/msg00112.html

In c#4 you want the commit for k:head and factory only, so why you mention 11.4 now?

> > Then please backport at least this commit:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecf7ace9a8450303a987aa8364e53860cd50e554
> >
> > It only provides an additional symbol which I need to build the DRM modules
> > against Kernel:HEAD and Factory ...
> 
> -> Now I need it only for Factory ...

I already wrote factory will contain what is in the kernel:head after some time (after somebody creates a submit request and it is accepted). This happens constantly.

> and this:
> 
> > Maybe we can also deliver 11.4 with my optional drm-radeon package (other
> name?) which is Dave Airlie's repository (maintainer of drivers/gpu).
> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-fixes
> 
> -> This package provides the latest drm code ...

Fine, if you want the 11.4 kernel to contain the commit too, that's something we can consider. In the meantime, before the decision is made and the change propagates, you can define the function in your package locally (you have everything needed exported).

(In reply to comment #10)
[...]
> > and this:
> > 
> > > Maybe we can also deliver 11.4 with my optional drm-radeon package (other
> > name?) which is Dave Airlie's repository (maintainer of drivers/gpu).
> > > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-fixes
> > 
> > -> This package provides the latest drm code ...
> 
> Fine, if you want the 11.4 kernel to contain the commit too, that's something
> we can consider. In the meantime, before the decision is made and the change
> propagates, you can define the function in your package locally (you have
> everything needed exported).

openSUSE:Factory is base for openSUSE:11.4 until it will be copied to openSUSE:11.4.
openSUSE:11.4 does not contain any packages:
https://build.opensuse.org/project/packages?package=&project=openSUSE%3A11.4

So I do not understand why you think openSUSE 11.4 is branched (copied from openSUSE:Factory). I also cannot find such a message on mailing lists.

Maybe there are hidden processes by Novell employees ...

(In reply to comment #11)
> So I do not understand why you think openSUSE 11.4 is branched (copied from
> openSUSE:Factory). I also cannot find such a message on mailing lists.

I don't _think_ it is, I _know_ that. Dunno if there are any messages anywhere or whatever, but in the git, it is definitely branched already. Master branch is for factory and k:head (2.6.38-rc2), 11.4 is for 11.4 (2.6.37).

(In reply to comment #10)
[...]
> Fine, if you want the 11.4 kernel to contain the commit too, that's something
> we can consider. In the meantime, before the decision is made and the change
> propagates, you can define the function in your package locally (you have
> everything needed exported).

Just for your information:

Waiting until a deadline has lapsed is also a possibility to make a decision ...

In Germany we call this way: "Erledigung durch Zeitablauf." - "Execution by the use of time lapse."

For me it seems you want to go this way ...

Ok, I'll make the decision then.

No, if you want this kref function, put it in your module instead of in the
main kernel tree.  If it's in the kernel package, we have to maintain it
and handle support for it for the next couple of years, and I, as the kref author
do not want to do that, as we have enough other things to worry about supporting
and maintaining over time.

So please just put it in your kmp and all will be good.

(In reply to comment #14)
[...]
> No, if you want this kref function, put it in your module instead of in the
> main kernel tree.  [...]
> 
> So please just put it in your kmp and all will be good.

[...]
CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/drivers/gpu/stub/poulsbo.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/crc-ccitt.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/crc16.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/crc-itu-t.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/crc7.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/ts_kmp.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/ts_bm.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/ts_fsm.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/cpu-notifier-error-inject.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/lru_cache.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/reed_solomon/reed_solomon.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/zlib_deflate/deflate.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/zlib_deflate/deftree.o
  CC [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/zlib_deflate/deflate_syms.o
  LD [M]  /usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/lib/zlib_deflate/zlib_deflate.o
  Building modules, stage 2.
  MODPOST 22 modules
WARNING: "kref_sub" [/usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default/drivers/gpu/drm/ttm/ttm.ko] undefined!
[...]

(see: https://build.opensuse.org/package/rawlog?arch=i586&package=drm-intel&project=home%3Ajobermayr&repository=openSUSE_Factory_Snapshot)

You see I compile the lib/ dir but it doesn't compile kref.c. So please tell me what I must change:

+ cp -r drivers/ lib/ obj/default/
+ echo 'obj-y += drivers/ lib/'
+ echo 'obj-y += char/ gpu/'
+ echo 'obj-y += agp/'
+ make -C /usr/src/linux-obj/i586/default modules M=/usr/src/packages/BUILD/drm-intel-20110202/drm-all/obj/default CONFIG_DRM_RADEON_KMS=n CONFIG_DRM_RADEON=n CONFIG_DRM_R128=n CONFIG_DRM_NOUVEAU_BACKLIGHT=n CONFIG_DRM_NOUVEAU_KMS=n CONFIG_DRM_NOUVEAU=n CONFIG_DRM_NOUVEAU_DEBUG=n CONFIG_DRM_I2C_CH7006=n CONFIG_DRM_TTM=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_STUB_POULSBO=m CONFIG_DRM_TDFX=n CONFIG_DRM_MGA=n CONFIG_DRM_SIS=n CONFIG_DRM_SAVAGE=n CONFIG_DRM_VMWGFX=n CONFIG_DRM_VIA=n CONFIG_AGP_ALI=n CONFIG_AGP_ATI=n CONFIG_AGP_AMD=n CONFIG_AGP_AMD64=n CONFIG_AGP_ALPHA_CORE=n CONFIG_AGP_EFFICEON=n CONFIG_AGP_HP_ZX1=n CONFIG_AGP_PARISC=n CONFIG_AGP_I460=m CONFIG_AGP_INTEL=m CONFIG_AGP_NVIDIA=n CONFIG_AGP_SGI_TIOCA=n CONFIG_AGP_SIS=n CONFIG_AGP_SWORKS=n CONFIG_AGP_UNINORTH=n CONFIG_AGP_VIA=n CONFIG_RAID6_PQ=n 'CC=gcc -I/usr/src/packages/BUILD/drm-intel-20110202/drm-all/include/linux -I/usr/src/packages/BUILD/drm-intel-20110202/drm-all/include/drm -I/usr/src/packages/BUILD/drm-intel-20110202/drm-all/include'

You need to add the new kref function to your patches/files you build, don't
try to modify the existing kref.c file in the kernel source, that's not going
to work at all, as you can see.

Anyway, you might want to take this to the opensuse-kernel list for further
questions as it's easier to discuss there instead of here in bugzilla.  Please
leave this bug closed as the issue is now resolved.