Date:	Mon, 3 Jan 2011 21:33:15 +0100
From:	Sedat Dilek <sedat.dilek@...glemail.com>
To:	Pekka Paalanen <pq@....fi>
Cc:	Dave Airlie <airlied@...il.com>,
	Michel Dänzer <michel@...nzer.net>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	DRI <dri-devel@...ts.freedesktop.org>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH] drm: Remove DRIVER_DATE and CORE_DATE

2011/1/3 Pekka Paalanen <pq@....fi>:
> On Wed, 22 Dec 2010 10:51:26 +0100
> Sedat Dilek <sedat.dilek@...glemail.com> wrote:
>
>> DRIVER_DATE is not maintained or upgraded on changes in many drm
>> drivers.
>>
>> For example radeon has one DRIVER_DATE for User and Kernel
>> ModeSetting driver, this makes no sense as UMS and KMS driver
>> have different versions. And of course this all increases
>> maintenance, too. For radeon it is enough to bump
>> {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
>> {KMS_}DRIVER_PATCHLEVEL defines.
>>
>> Furthermore, I also removed CORE_DATE.
>>
>> With radeon-KMS my dmesg looks now like this:
>>
>> [   12.328937] [drm] Initialized drm 1.1.0
>> [   13.144019] [drm] Initialized radeon 2.8.0 for 0000:01:00.0 on
>> minor 0
>>
>> Signed-off-by: Sedat Dilek <sedat.dilek@...il.com>
>>
>> Note: Tested with radeon RV250 (KMS) and linux-next
>> (next-20101221).
> ...
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c
>> index bb17057..50abca3 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drv.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
>> @@ -416,11 +416,6 @@ static struct drm_driver driver = {
>>
>>       .name = DRIVER_NAME,
>>       .desc = DRIVER_DESC,
>> -#ifdef GIT_REVISION
>> -     .date = GIT_REVISION,
>> -#else
>> -     .date = DRIVER_DATE,
>> -#endif
>>       .major = DRIVER_MAJOR,
>>       .minor = DRIVER_MINOR,
>>       .patchlevel = DRIVER_PATCHLEVEL,
>
> Just a reminder, why this hunk was there in the first place:
> it is quite usual for the Nouveau DRM to be compiled out-of-tree,
> from different kernel git sources than the hosting kernel.
> This was an attempt to record in the kernel log which exact
> revision is being used. GIT_REVISION is defined by the Makefile
> that is recommended to be used for out-of-tree building.
>
> I didn't check if this patch has been accepted, but I believe
> maintaining differences between nouveau/linux-2.6 and upstream
> kernel trees is a burden.
>
> Is there a better way to add revision information to an
> out-of-tree built kernel module?
> Or maybe this is not useful at all?
>
>
> Cheers.
>
> --
> Pekka Paalanen
> http://www.iki.fi/pq/
>

Happy new 2011 to you all (and I apologize for my rants in the next few lines)!

[ NOTE: The mentionned patch is not complete, requires further
removals also in libdrm and a rebuild of the ddx. ]

I have a new patchset (as series and as a single patch) to remove
driver-date and core-date from kernel-drm and one patch to do so for
libdrm (see attachments).

This stuff is tested and running (while I am writing to you) with
linux-next (next-20101231), a cleaned-up libdrm-2.4.23 and a rebuilt
ati/radeon ddx.

But works-for-me means not these patches work fine with other kernels,
libdrm or ddx than in my development environment.
So, please feel free to test them and give feedback (best is dri-devel
mailing-list).

( If desired I can resend the patchset/patch(es) to dri-devel ML - in
a discussion thread such patches go down. )

[ Instructions ]

1. Rebuild kernel with my kernel-drm patchset
2. Jump to the new kernel
3. Rebuild libdrm with my libdrm-patch (be aware you have the
correct/cleanedp-up drm.h)
4. Rebuild your ddx (in my case xf86-video-ati) against new libdrm

Note:
Another reason for me to get rid of the driver-date stuff: It is not
checked for example in the ddx (but for major|minor|patchlevel
versions).
BTW, my mesa and xserver are from official Debian/experimental.

Unfortunately, diverse emails of me have been unanswered to update the
driver-date for radeon (for a collection of mine see [1],[2],[3]).

I cannot speak for nouveau in kernel-drm, but the GIT version stuff
was not clear to me.
>From my POV it is the only driver having such extra-stuff and sorry
for this, it can also go to /dev/nirvana.

The version related informations for drm-core seems also not to be
lovely maintained.
How long do we see 1.1.0 as version? For ages?

Did you know about interface-version?
You found the places for DRM_IF_*?
No, this is not a riddle or quiz-show, just have a look into
<include/drm/drm_core.h>.
The IF-version (currently: v1.4) is in <drivers/gpu/drm/drm_ioctl.c>
and you will find there comments which "document" it, see
drm_setversion():
...
                        /*
                         * Version 1.1 includes tying of DRM to specific device
                         * Version 1.4 has proper PCI domain support
                         */
...

Why the hell aren't those version mumbo-jumbos "well" documented?
By "well" I mean not deeply hided in the source-code.
I remember this version mumbo-jumbo should be in the first lines of
the driver's c-file, maintained as a history of changes.

And for the god's sake if you use hardcoded date-strings - Europeans
like me still get confused by 01/11/2010 (is it 01-Nov-2010 or
11-Jan-2010?) - why don't you use a clear 10-Oct-2010 (here:
drm-vblank-timestamping):

$ dmesg | grep vblank
[   10.359312] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   10.359349] [drm] Driver supports precise vblank timestamp query.

Also for drm-vblank-timestamping:
Is your Rev and date still valid, where is it documented? Source-code?

In general, do you see drm-related docs in Documentation directory of
the linux-kernel (see [3] for linux-next)?
Why?

Did you had a look at the author's names in the diverse header and
c-files in the kernel-drm tree?
Maintained or not maintained, this is here the question :-)?

It is a logical and correct consequence to remove such version crap if
it is not 1. properly documented or 2. well maintained.
As an example see linux-wireless mailing-list and the removal of
module-version of ath5k-driver (see [5],[6]).

When you want to throw off the date-related stuff completely from the
whole(!) kernel-drm tree, you have to do appropriate removals in
libdrm.

The only argument I can understand is a breakage of the drm ABI.
Anyway, the world won't stop turning by these changes.
Now, there is a reason to bump the core-version with driver-date and
core-date removal :-)?

diff --git a/include/drm/drm_core.h b/include/drm/drm_core.h
index 1485f3f..d54449e 100644
--- a/include/drm/drm_core.h
+++ b/include/drm/drm_core.h
@@ -29,5 +29,5 @@
 #define DRM_IF_MINOR   4

 #define CORE_MAJOR     1
-#define CORE_MINOR     1
+#define CORE_MINOR     2
 #define CORE_PATCHLEVEL 0

Aaargh, where shall I document this core-version bump?
In the git commit? As usual: Documentation is seen as a punishment for coders?

Dear developers, if you don't maintain your drivers with version *and
date*, then please kill the latter.

Last but not least:
Is there an official recommendation (written down docs) about how to
maintain driver documentation?
An excellent example of a driver or even for a sub-tree of the kernel.
Thanks in advance.

With this email I want to call the attention of the drm developers to
my removal request.
As you know the kernel got rid also of the firmware stuff (it took some time).

Speaking as an end-user, I did all efforts to change the circumstance
by pointing to the problem in IRC and MLs.
"Laziness" is not an argument to me.
RIP driver-date and core-date (I won't drop a tear for you).

Regards,
- Sedat -

[1] http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg00117.html
[2] http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg00121.html
[3] http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg00125.html
[4] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree;f=Documentation
[5] http://marc.info/?t=129134950900001&r=1&w=4
[6] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=b7555ec7c604f2f00e432579dac29df5ce525433

View attachment "0001-drm-Remove-DRIVER_DATE-from-drm-drivers.patch" of type "text/x-diff" (11442 bytes)

View attachment "0002-drm-Remove-CORE_DATE-from-drm-core-and-drm-sysfs.patch" of type "text/x-diff" (1214 bytes)

View attachment "0003-drm-Fix-DRM_INFO-after-DRIVER_DATE-CORE_DATE-removal.patch" of type "text/x-diff" (2181 bytes)

View attachment "0004-drm-Remove-date_len-and-date-from-drm_version.patch" of type "text/x-diff" (1478 bytes)

View attachment "drm-driverdate-coredate-removal.patch" of type "text/x-diff" (14885 bytes)

View attachment "0001-libdrm-Remove-driver-date-from-drm-version-calls.patch" of type "text/x-diff" (4759 bytes)

Powered by blists - more mailing lists