deal with driver version numbers sensibly and consistently

davidker / unisys

Master repository for new changes to drivers/staging/unisys and drivers/visorbus

Other

2 stars 1 forks source link

deal with driver version numbers sensibly and consistently #71

Closed selltc closed 7 years ago

selltc commented 8 years ago

See KanBoard-1375.

We currently have a hokey way of dealing with driver versions, via include/version.h defining "VERSION", then having MODULE_VERSION(VERSION) in each driver. This all made sense when the guest driver package was integrated with the rest of s-Par, but makes NO sense in the upstream drivers.

We should:

Decide how we want to assign version numbers, and when we want to change them. I think it would almost-certainly be WRONG to use any version numbers that even RESEMBLED s-Par versions.
We at least want to simplify include/version.h, and possibly just eliminate it entirely, and have instead a unique version number for each driver.
Optionally, have a pr_debug() or pr_info() in each driver's init function, which would identify the driver and version in some consistent way.

selltc commented 8 years ago

staging-next based patches for this are on githubissue#71-upstream-next, indicated via the links above. These patches are all checkpatch-clean and regression test cleanly. I'm going to wait until Monday to move this Kanboard item into the ready-for-inspection column.

selltc commented 8 years ago

for-later based patches for this are on githubissue-71-for-later-selltc-20160613, indicated via the links above. These patches are all checkpatch-clean and regression test cleanly. Note that the for-later versions of the patches have a "2" in the most-significant node of the version string, as compared to a "1" for the staging-next versions. I figure that adding interrupt support is a good reason to increase the major version number.

selltc commented 8 years ago

We deliberately have NOT put these patches into for-later yet. What David and I decided to do was to completely remove the versioning stuff from staging-next, then re-do this set of patches to add them back to for-later in a cleaner way. This has the greatest chance of making Greg happy (or at least NOT grumpy).

jaftrain commented 8 years ago

I have refactored these patches in githubissue-71-for-later branch to sit on top of GitHub Issue 90 Branch

jaftrain commented 7 years ago

I have refactored the patches in githubissue-71-for-later branch addressing @selltc and @davidker comments

selltc commented 7 years ago

Those patches look great to me Jon. Thanks.

davidker commented 7 years ago

They are in for-later so I'm closing this.