Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Le 14/03/2017 à 06:38, Masahiro Yamada a écrit : > Ni Nicolas, > > > 2017-03-14 1:57 GMT+09:00 Nicolas Dichtel : >>> BTW, this series does not apply cleanly. >>> >>> If you could rebase it onto v4.11-rc1 tag, >>> it would be helpful. >> You really want this on top of 4.11-rc1 or the last linus tag, ie v4.11-rc2? >> > > Basically, I queue up patches based on -rc1 tag > unless there is a particular reason for otherwise. Ok, thank you for the explanation. > > If it is based on -rc1, will it cause conflicts with Linus tree? I will check and let you know in the v10 submission. Thank you, Nicolas
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Ni Nicolas, 2017-03-14 1:57 GMT+09:00 Nicolas Dichtel : >> BTW, this series does not apply cleanly. >> >> If you could rebase it onto v4.11-rc1 tag, >> it would be helpful. > You really want this on top of 4.11-rc1 or the last linus tag, ie v4.11-rc2? > Basically, I queue up patches based on -rc1 tag unless there is a particular reason for otherwise. If it is based on -rc1, will it cause conflicts with Linus tree? -- Best Regards Masahiro Yamada
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Le 11/03/2017 à 06:43, Masahiro Yamada a écrit : [snip] > > I will take care of this. Thank you. > > > >> kbuild tree has not been updated since two months (4.10-rc1) :/ > > Michal's tree is not active these days. Ok, I didn't know that. > Going forward, I will queue up Kbuild patches in my repository. > > > > BTW, this series does not apply cleanly. > > If you could rebase it onto v4.11-rc1 tag, > it would be helpful. You really want this on top of 4.11-rc1 or the last linus tag, ie v4.11-rc2? Regards, Nicolas
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Hi Nicolas, 2017-03-11 1:34 GMT+09:00 Nicolas Dichtel : > Le 02/03/2017 à 17:56, Nicolas Dichtel a écrit : >> Patches #1 and #2 are just cleanup: some exported headers were still under >> a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was >> not under an uapi directory. >> After these three patches, all exported headers are under an uapi directory: >> path #4 stops searching files in non uapi directories. >> The patch #5 was spotted by code review: there is no in-tree user of this >> functionality. >> Patch #6 fixes some warnings/errors reported by 0-day tests. >> Patch #7 to #9 fix some errors when the corresponding files are included by >> userland. >> Patches #10 and #11 remove the need to list explicitly headers. Now all files >> under an uapi directory are exported. >> >> This series has been tested with a 'make headers_install' on x86 and a >> 'make headers_install_all'. I've checked the result of both commands. >> >> This patch is built against linus tree. If I must rebase it against the >> kbuild >> tree, just tell me. >> Michal, is this series going through your tree? > Still waiting to know who may take this series in its tree ;-) I will take care of this. > kbuild tree has not been updated since two months (4.10-rc1) :/ Michal's tree is not active these days. Going forward, I will queue up Kbuild patches in my repository. BTW, this series does not apply cleanly. If you could rebase it onto v4.11-rc1 tag, it would be helpful. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Le 02/03/2017 à 17:56, Nicolas Dichtel a écrit : > Patches #1 and #2 are just cleanup: some exported headers were still under > a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was > not under an uapi directory. > After these three patches, all exported headers are under an uapi directory: > path #4 stops searching files in non uapi directories. > The patch #5 was spotted by code review: there is no in-tree user of this > functionality. > Patch #6 fixes some warnings/errors reported by 0-day tests. > Patch #7 to #9 fix some errors when the corresponding files are included by > userland. > Patches #10 and #11 remove the need to list explicitly headers. Now all files > under an uapi directory are exported. > > This series has been tested with a 'make headers_install' on x86 and a > 'make headers_install_all'. I've checked the result of both commands. > > This patch is built against linus tree. If I must rebase it against the kbuild > tree, just tell me. > Michal, is this series going through your tree? Still waiting to know who may take this series in its tree ;-) kbuild tree has not been updated since two months (4.10-rc1) :/ Regards, Nicolas
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Le 02/03/2017 à 17:56, Nicolas Dichtel a écrit : > Patches #1 and #2 are just cleanup: some exported headers were still under > a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was > not under an uapi directory. > After these three patches, all exported headers are under an uapi directory: > path #4 stops searching files in non uapi directories. > The patch #5 was spotted by code review: there is no in-tree user of this > functionality. > Patch #6 fixes some warnings/errors reported by 0-day tests. > Patch #7 to #9 fix some errors when the corresponding files are included by > userland. > Patches #10 and #11 remove the need to list explicitly headers. Now all files > under an uapi directory are exported. > > This series has been tested with a 'make headers_install' on x86 and a > 'make headers_install_all'. I've checked the result of both commands. > > This patch is built against linus tree. If I must rebase it against the kbuild > tree, just tell me. > Michal, is this series going through your tree? I'm a bit pushy on this, but it would be nice to get this series in before the rc1. In fact, it would certainly be better to have this living some times in -next, but it would probably generate a lot of conflicts in linux-next. OTOH those conflicts would be easy to solve. Regards, Nicolas
[PATCH v9 00/11] uapi: export all headers under uapi directories
Patches #1 and #2 are just cleanup: some exported headers were still under a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was not under an uapi directory. After these three patches, all exported headers are under an uapi directory: path #4 stops searching files in non uapi directories. The patch #5 was spotted by code review: there is no in-tree user of this functionality. Patch #6 fixes some warnings/errors reported by 0-day tests. Patch #7 to #9 fix some errors when the corresponding files are included by userland. Patches #10 and #11 remove the need to list explicitly headers. Now all files under an uapi directory are exported. This series has been tested with a 'make headers_install' on x86 and a 'make headers_install_all'. I've checked the result of both commands. This patch is built against linus tree. If I must rebase it against the kbuild tree, just tell me. Michal, is this series going through your tree? v8 -> v9: - rebase on top of linus tree - patch #8: add include/uapi/linux/crypto.h v7 -> v8: - rebase on top of linus tree - add patch #7, #8 and #9 v6 -> v7: - rebase on top of linus tree - patch #7: remove autogenerated files from the list in the commit log v5 -> v6: - patch #6: remove change of include/uapi/linux/media.h - patch #7: fix hdr export when 'make O=' is used (look for genhdr files in the right directory) - patch #8: fix 'make headers_check' v4 -> v5: - patch #3: get back to v3 (don't export msr-index.h) - patch #6: new in this version - patch #7: fix compilation by introducing header-n v3 -> v4: - first patch has been included - patch #4: get back to v2 and remove arch/x86/include/asm/msr-index.h v2 -> v3: - patch #1: remove arch/arm/include/asm/types.h - patch #2: remove arch/h8300/include/asm/bitsperlong.h - patch #3: remove arch/nios2/include/uapi/asm/setup.h - patch #4: don't export msr-index.h - patch #5: fix a typo: s/unput-files3-name/input-files3-name - patch #6: no change - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y - add patch #8 v1 -> v2: - add patch #1 to #6 - patch #7: remove use of header-y Comments are welcomed, Nicolas
