linux-kernel - RE: [PATCH 1/2] Staging: hv: Add proper versioning to HV drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8AFC7968D54FB448A30D8F38F259C56212E8831E@TK5EX14MBXC118.redmond.corp.microsoft.com>
Date:	Thu, 11 Feb 2010 22:15:08 +0000
From:	Hank Janssen <hjanssen@...rosoft.com>
To:	Greg KH <gregkh@...e.de>
CC:	"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>
Subject: RE: [PATCH 1/2] Staging: hv: Add proper versioning to HV drivers

>>  
>> -static const char VersionDate[] = __DATE__;
>> -static const char VersionTime[] = __TIME__;
>> -static const char VersionDesc[] = "Version 2.0";
>> +static const char hv_build_date[] = __DATE__;
>> +static const char hv_build_time[] = __TIME__;
>
>This should not be needed at all, as it make absolutely no sense.

You know, you are actually right. This is leftover from when the drivers
Where standalone (before we submitted them to mainline) when customers
Build the drivers on site themselves. It helped them to know when they
Build it.

>> +/*
>> + * We use the same version numbering for all Hyper-V modules.
>> + */
>> +#define HV_DRV_VERSION           "3.0.0"
>
>Is this really needed?  Now that the code is in the kernel tree,
>shouldn't you be tracking this based on kernel release version (like 90%
>of the drivers are tracked), or is there some requirement for a version
>number?
>
>And what decides when this number is changed?  What does it "mean"?
>What is it tracking?

The definition of the versioning for us is as follows;

Field	Description	Resolution
1	Major Number 	Changes for these scenarios;
				1.	When a new version of Windows Hyper-V 
					is released.
				2.	A Major change has occurred in the 
					Linux IC's. 
				(For example the merge for the first time 
				into the kernel) Every time the Major Number 
				changes, the Minor Number and Revision number 
				are reset to 0.
2	Minor Number	Changes when new functionality is added 
				to the Linux IC's that is not a bug fix. 
				If new functionality is added to the IC's 
				that is in effect also a bug fix (in the case 
				of SMP). The new functionality will override 
				the need for changing the Revision number. 
				Every time the Minor Number changes, the 
				Revision number will be reset to 0.
				For example, The current version is on;
						3.0.4
				And SMP is added, which fixes a problem as 
				well. The new versioning will become;
						3.1.0
3	Revision		Every time a bug fix or code change is 
				done that is not a Minor or Major number 
				change, this field increases by 1.

We have had issues in the past trying to piece together what customers
Where running.

The importance of the versioning numbering like this will go away over
Time once we have the code cleaned up and have additional functionality
In a staged manner. For now we are still trying to catch up.

Would you like me to re-roll the patch to remove the DATE/TIME stuff
And add the explanation for versioning as comments to the code?

Thanks,

Hank.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/