On Sun, Oct 18, 2015 at 1:14 PM, Bridgman, John <John.Bridgman at amd.com> wrote: > Hi Oded, > > Looks good. We now have a nice automated build/test system running internally, > I imagine automake/autoconf should be able to fit OK into that (although I > guess > it might trigger the usual religious war about build tools :)) > > re: #2, IIRC we used to do the even/odd numbering on minor not micro, is that > a deliberate change ? > Actually, the whole version numbering in hsakmt is confusing... Up until now, there were:
1. HSAKMT_VERSION_MAJOR/HSAKMT_VERSION_MINOR in hsakmttypes.h. I have no idea for what those defines are used - probably left-overs from windows thunk design. Maybe Paul knows. 2. KFD_IOCTL_MAJOR_VERSION/KFD_IOCTL_MINOR_VERSION in kfd_ioctl.h. That's left-overs from the time we returned those defines to the HSA RT layer. Now, we get those from the amdkfd using an IOCTL call. It allows the HSA RT to know the features that amdkfd provides. I think there were discussions of replacing them with some bitmask field, but I don't know the current status. Therefore, I didn't want to rely on any of the above, so I created a new system in configure.ac that will be used just to provide numbers for the sake of releases, as the two existing methods don't change according to releases. In my scheme, major will be used for ABI breakage and/or when minor gets to big numbers, minor for important releases and micro for differentiating between a released version and in-development version. e.g. 1.0.4 - released version 1.0.5 - version in development. 1.0.6 - next released version. 1.0.7 - next version in development. 1.1.0 - next important/big release 1.1.1 - development tree after the release > I'm sure I'll get questions about the hsakmt/hsakmt folder structure but if > you > get rid of the src folder not sure what would be better. Just curious, why > not keep > build files at top level then have src/include folders underneath ? > This folder structure is standard when using autoconf tools. So you have a root folder, i.e. hsakmt, then you have the folder which contains sources (and headers), which is the same name. You can have other folders at this level, for "tests", "docs", etc. Also, folders are created automatically at this level, e.g. autom4te.cache Under the "second" hsakmt folder, you have your project sources, in any structure you want. The resulting build outputs (objects, libraries, etc.) are included in those folders and in hidden .deps, .libs folders. They are ignored using .gitignore files. I did it according to the pixman library which I now also maintain. Initially, I even deleted the include folder, but I returned it to make the change less radical for you (see below). > That include/linux folder has been bugging me for a while so we'll probably > get > rid of it at some point. Don't remember the history so unless someone else > does... > The reason for the include folder is to map it directly to the internal source control tool you use, so that it can be shared between windows and linux development. The reason for include/linux is to separate linux-only files from windows-only files. As I said above, I have no problem removing these, but I feared it might be too radical for you... If you want to see how it will look like without the include folder, check out http://cgit.freedesktop.org/amd/hsakmt/tree/?id=e8a6286922e9add2d34ca29fd2b3c6b3ace35f69 Thanks, Oded > Everything else looks good. Thanks !! > ________________________________________ > Original Message > From: Oded Gabbay > Sent: Sunday, October 18, 2015 2:39 AM > To: Bridgman, John > Cc: Maling list - DRI developers; Alex Deucher > Subject: Re: [hsakmt] hsakmt organization and formal releases > > > On Fri, Oct 9, 2015 at 7:46 PM, Alex Deucher <alexdeucher at gmail.com> wrote: >> On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay <oded.gabbay at gmail.com> wrote: >>> Hi, >>> >>> I had some time during the recent local holidays, so I thought I >>> improve the hsakmt library in terms of releases: >>> >>> 1. I added automake/autoconf files to standardize the package to be >>> created using configure/make/make install. >>> >>> 2. I created a very simple scheme of numbering so we could track releases. >>> >>> 3. I created a git repository under freedesktop.org amd's folder that >>> will hold hsakmt code (instead of using my private git repo). You can >>> clone the new repo from: git://anongit.freedesktop.org/amd/hsakmt >>> >>> 4. I created two new sub-components in freedesktop.org bugzilla, under >>> DRI, for hsakmt and amdkfd, so bugs can be filed correctly. >>> >>> As part of point 1, I rearranged the layout of the source files a bit, >>> although I kept the formation of the include files so it would be easy >>> to use inside AMD :) >>> >>> I would like to get (positive) feedback on this, and then I will >>> create the first official release and also F22, F23 and F24 (rawhide) >>> rpm packages that will be part of the distribution. >>> >>> As a reminder, this repository will be used to manage only the >>> upstream version of hsakmt. Private/non-yet-upstreamed releases of AMD >>> are done in GitHub. >> >> Looks good to me! thanks, >> >> Alex >> >>> >>> Thanks, >>> >>> Oded > > John, any comment from you ? > If not, I assume I can go ahead. > > Oded