Now that we have a major backport of DRM in the kernel we want to be able
to clearly identify the version carried programatically. In particular
we want this information available in the boot dmesg and in the apport
data collected.

The following patches augment the /proc/version_signature to expose the
full official build version number in the Makefile. The value in this
file is already emitted during early boot into dmesg. This allows
the -rcN release candidate number or stable release version to be exposed
in the default case. By manually augmenting the EXTRAVERSION with our
DRM backport information we also can expose that as required.

In this case we set the EXTRAVERSION to '.9+drm33.0' indicating that we
have 2.6.32.9 stable update applied plus the drm33 at the release version.
The .0 will increment to match 2.6.33.y stable updates as they are applied.

-apw

Andy Whitcroft (2):
UBUNTU: expose the kernel EXTRAVERSION in dmesg and
/proc/version_signature
UBUNTU: record the drm version in EXTRAVERSION

Makefile | 2 +-
debian/rules.d/0-common-vars.mk | 3 +++
debian/rules.d/2-binary-arch.mk | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Sounds like a sensible place to track the versions.

Acked-by: Stefan Bader <stefan.bader@canonical.com>

Andy Whitcroft wrote:
> Now that we have a major backport of DRM in the kernel we want to be able
> to clearly identify the version carried programatically. In particular
> we want this information available in the boot dmesg and in the apport
> data collected.
>
> The following patches augment the /proc/version_signature to expose the
> full official build version number in the Makefile. The value in this
> file is already emitted during early boot into dmesg. This allows
> the -rcN release candidate number or stable release version to be exposed
> in the default case. By manually augmenting the EXTRAVERSION with our
> DRM backport information we also can expose that as required.
>
> In this case we set the EXTRAVERSION to '.9+drm33.0' indicating that we
> have 2.6.32.9 stable update applied plus the drm33 at the release version.
> The .0 will increment to match 2.6.33.y stable updates as they are applied.
>
> -apw
>
> Andy Whitcroft (2):
> UBUNTU: expose the kernel EXTRAVERSION in dmesg and
> /proc/version_signature
> UBUNTU: record the drm version in EXTRAVERSION
>
> Makefile | 2 +-
> debian/rules.d/0-common-vars.mk | 3 +++
> debian/rules.d/2-binary-arch.mk | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
>


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On 10 Mar 15, Andy Whitcroft wrote:
> Now that we have a major backport of DRM in the kernel we want to be able
> to clearly identify the version carried programatically. In particular
> we want this information available in the boot dmesg and in the apport
> data collected.
>
> The following patches augment the /proc/version_signature to expose the
> full official build version number in the Makefile. The value in this
> file is already emitted during early boot into dmesg. This allows
> the -rcN release candidate number or stable release version to be exposed
> in the default case. By manually augmenting the EXTRAVERSION with our
> DRM backport information we also can expose that as required.
>
> In this case we set the EXTRAVERSION to '.9+drm33.0' indicating that we
> have 2.6.32.9 stable update applied plus the drm33 at the release version.
> The .0 will increment to match 2.6.33.y stable updates as they are applied.
>
> -apw
>
> Andy Whitcroft (2):
> UBUNTU: expose the kernel EXTRAVERSION in dmesg and
> /proc/version_signature
> UBUNTU: record the drm version in EXTRAVERSION
>
> Makefile | 2 +-
> debian/rules.d/0-common-vars.mk | 3 +++
> debian/rules.d/2-binary-arch.mk | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)

Sounds like a good idea. This will produce a conflict with each stable update
though, correct?

Acked-by: Amit Kucheria <amit.kucheria@canonical.com>

--
----------------------------------------------------------------------
Amit Kucheria, Kernel Engineer || amit.kucheria@canonical.com
----------------------------------------------------------------------

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Mon, Mar 15, 2010 at 02:29:06PM +0200, Amit Kucheria wrote:
> On 10 Mar 15, Andy Whitcroft wrote:
> > Now that we have a major backport of DRM in the kernel we want to be able
> > to clearly identify the version carried programatically. In particular
> > we want this information available in the boot dmesg and in the apport
> > data collected.
> >
> > The following patches augment the /proc/version_signature to expose the
> > full official build version number in the Makefile. The value in this
> > file is already emitted during early boot into dmesg. This allows
> > the -rcN release candidate number or stable release version to be exposed
> > in the default case. By manually augmenting the EXTRAVERSION with our
> > DRM backport information we also can expose that as required.
> >
> > In this case we set the EXTRAVERSION to '.9+drm33.0' indicating that we
> > have 2.6.32.9 stable update applied plus the drm33 at the release version.
> > The .0 will increment to match 2.6.33.y stable updates as they are applied.
> >
> > -apw
> >
> > Andy Whitcroft (2):
> > UBUNTU: expose the kernel EXTRAVERSION in dmesg and
> > /proc/version_signature
> > UBUNTU: record the drm version in EXTRAVERSION
> >
> > Makefile | 2 +-
> > debian/rules.d/0-common-vars.mk | 3 +++
> > debian/rules.d/2-binary-arch.mk | 2 +-
> > 3 files changed, 5 insertions(+), 2 deletions(-)
>
> Sounds like a good idea. This will produce a conflict with each stable update
> though, correct?
>
> Acked-by: Amit Kucheria <amit.kucheria@canonical.com>

Yes it will that, for the Linux 2.6.32.y update. That will help to
remind us to update the drm number too.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On 03/15/2010 04:48 AM, Andy Whitcroft wrote:
> Now that we have a major backport of DRM in the kernel we want to be able
> to clearly identify the version carried programatically. In particular
> we want this information available in the boot dmesg and in the apport
> data collected.
>
> The following patches augment the /proc/version_signature to expose the
> full official build version number in the Makefile. The value in this
> file is already emitted during early boot into dmesg. This allows
> the -rcN release candidate number or stable release version to be exposed
> in the default case. By manually augmenting the EXTRAVERSION with our
> DRM backport information we also can expose that as required.
>
> In this case we set the EXTRAVERSION to '.9+drm33.0' indicating that we
> have 2.6.32.9 stable update applied plus the drm33 at the release version.
> The .0 will increment to match 2.6.33.y stable updates as they are applied.
>
> -apw
>
> Andy Whitcroft (2):
> UBUNTU: expose the kernel EXTRAVERSION in dmesg and
> /proc/version_signature
> UBUNTU: record the drm version in EXTRAVERSION
>
> Makefile | 2 +-
> debian/rules.d/0-common-vars.mk | 3 +++
> debian/rules.d/2-binary-arch.mk | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
>

There have been cases in the past when not all stable updates have been
applied, so it might be a bit disingenuous to advertise a stable updates
realese number. That being said, I'm still in favor since its going to
be pretty close. Keeping track of the DRM release state is also gonna be
a pain. Is the plan to watch for any .33 stable kernel updates that
affect DRM and update the DRM version number accordingly, e.g. drm33.x ?

Acked-by: Tim Gardner <tim.gardner@canonical.com>

--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Mon, Mar 15, 2010 at 06:55:15AM -0600, Tim Gardner wrote:

> There have been cases in the past when not all stable updates have
> been applied, so it might be a bit disingenuous to advertise a
> stable updates realese number. That being said, I'm still in favor
> since its going to be pretty close. Keeping track of the DRM release
> state is also gonna be a pain. Is the plan to watch for any .33
> stable kernel updates that affect DRM and update the DRM version
> number accordingly, e.g. drm33.x ?
>
> Acked-by: Tim Gardner <tim.gardner@canonical.com>

Yeah the plan is that the drm33.y would match the v2.6.33.y tree we are
tracking and pulling drm updates only from.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team