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.
Thanks,
Oded
On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay oded.gabbay@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:
- I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
I created a very simple scheme of numbering so we could track releases.
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
- 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
On Fri, Oct 9, 2015 at 7:46 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay oded.gabbay@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:
- I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
I created a very simple scheme of numbering so we could track releases.
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
- 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
Hi Oded,
Looking at it now...
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@gmail.com wrote:
On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay oded.gabbay@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:
- I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
I created a very simple scheme of numbering so we could track releases.
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
- 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
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 ?
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 ?
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...
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@gmail.com wrote:
On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay oded.gabbay@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:
- I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
I created a very simple scheme of numbering so we could track releases.
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
- 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
On Sun, Oct 18, 2015 at 1:14 PM, Bridgman, John John.Bridgman@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=e8a6286922e9add2d34ca29fd2b3...
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@gmail.com wrote:
On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay oded.gabbay@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:
- I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
I created a very simple scheme of numbering so we could track releases.
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
- 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,
OdedJohn, any comment from you ? If not, I assume I can go ahead.
Oded
Thanks Oded. Just to be clear I wasn't talking about getting rid of the include folder, just the include/linux subfolder. ________________________________________ From: Oded Gabbay [oded.gabbay@gmail.com] Sent: October 18, 2015 6:51 AM To: Bridgman, John Cc: Maling list - DRI developers; Alex Deucher Subject: Re: [hsakmt] hsakmt organization and formal releases
On Sun, Oct 18, 2015 at 1:14 PM, Bridgman, John John.Bridgman@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=e8a6286922e9add2d34ca29fd2b3...
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@gmail.com wrote:
On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay oded.gabbay@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:
- I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
I created a very simple scheme of numbering so we could track releases.
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
- 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,
OdedJohn, any comment from you ? If not, I assume I can go ahead.
Oded
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Bridgman, John -
Oded Gabbay