Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-09 Thread Ben Cooksley


> On May 4, 2017, 12:40 p.m., Albert Astals Cid wrote:
> > Lamarque, you broke the build.
> 
> Lamarque Souza wrote:
> Fixed. Thanks for the quick report about the broken build and sorry for 
> not adding all files to the commit.
> 
> Ben Cooksley wrote:
> This patch broke the MSVC build and will be reverted shortly. 
> Please see 
> https://build-sandbox.kde.org/job/Frameworks%20solid%20kf5-qt5%20WindowsQt5.7/2/consoleText
>  for the build log.
> 
> Lamarque Souza wrote:
> Well, the simpler solution is removing all those #if, #include and #error 
> clauses (lines 31 oto 39 of autotests/solidudisks2test.cpp), they are not 
> required. I do not have a MSVC machine with frameworks installed to test that 
> now. I will test that after next frameworks release.
> 
> KJ Tsanaktsidis wrote:
> They're needed to actually find the right header file to include for 
> these macros on the various BSD's I think. Actually I think we should just 
> disable this test for windows, this feature is totally meaningless on 
> windows. Another hacky option is to code in the fallback macros (including 
> makedev) in solidudisks2test.cpp in the same way they are defined in 
> udisksblock.cpp, which will probably make that test compile and "work". It 
> wouldn't really be testing anything on windows though.
> 
> The original reason I put the #error case in that test was to make sure 
> we found out if there was some platform that was supposed to be supported 
> that didn't have these macros in any of the places I looked for them. I guess 
> we found out.

If you post a revised patch i'm happy to test it on the Windows CI setup.


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103182
---


On May 4, 2017, 12:32 p.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated May 4, 2017, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-07 Thread KJ Tsanaktsidis


> On May 4, 2017, 12:40 p.m., Albert Astals Cid wrote:
> > Lamarque, you broke the build.
> 
> Lamarque Souza wrote:
> Fixed. Thanks for the quick report about the broken build and sorry for 
> not adding all files to the commit.
> 
> Ben Cooksley wrote:
> This patch broke the MSVC build and will be reverted shortly. 
> Please see 
> https://build-sandbox.kde.org/job/Frameworks%20solid%20kf5-qt5%20WindowsQt5.7/2/consoleText
>  for the build log.
> 
> Lamarque Souza wrote:
> Well, the simpler solution is removing all those #if, #include and #error 
> clauses (lines 31 oto 39 of autotests/solidudisks2test.cpp), they are not 
> required. I do not have a MSVC machine with frameworks installed to test that 
> now. I will test that after next frameworks release.

They're needed to actually find the right header file to include for these 
macros on the various BSD's I think. Actually I think we should just disable 
this test for windows, this feature is totally meaningless on windows. Another 
hacky option is to code in the fallback macros (including makedev) in 
solidudisks2test.cpp in the same way they are defined in udisksblock.cpp, which 
will probably make that test compile and "work". It wouldn't really be testing 
anything on windows though.

The original reason I put the #error case in that test was to make sure we 
found out if there was some platform that was supposed to be supported that 
didn't have these macros in any of the places I looked for them. I guess we 
found out.


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103182
---


On May 4, 2017, 12:32 p.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated May 4, 2017, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-07 Thread Lamarque Souza


> On May 4, 2017, 12:40 p.m., Albert Astals Cid wrote:
> > Lamarque, you broke the build.
> 
> Lamarque Souza wrote:
> Fixed. Thanks for the quick report about the broken build and sorry for 
> not adding all files to the commit.
> 
> Ben Cooksley wrote:
> This patch broke the MSVC build and will be reverted shortly. 
> Please see 
> https://build-sandbox.kde.org/job/Frameworks%20solid%20kf5-qt5%20WindowsQt5.7/2/consoleText
>  for the build log.

Well, the simpler solution is removing all those #if, #include and #error 
clauses (lines 31 oto 39 of autotests/solidudisks2test.cpp), they are not 
required. I do not have a MSVC machine with frameworks installed to test that 
now. I will test that after next frameworks release.


- Lamarque


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103182
---


On May 4, 2017, 12:32 p.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated May 4, 2017, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-06 Thread Ben Cooksley


> On May 4, 2017, 12:40 p.m., Albert Astals Cid wrote:
> > Lamarque, you broke the build.
> 
> Lamarque Souza wrote:
> Fixed. Thanks for the quick report about the broken build and sorry for 
> not adding all files to the commit.

This patch broke the MSVC build and will be reverted shortly. 
Please see 
https://build-sandbox.kde.org/job/Frameworks%20solid%20kf5-qt5%20WindowsQt5.7/2/consoleText
 for the build log.


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103182
---


On May 4, 2017, 12:32 p.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated May 4, 2017, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-04 Thread Lamarque Souza


> On May 4, 2017, 12:40 p.m., Albert Astals Cid wrote:
> > Lamarque, you broke the build.

Fixed. Thanks for the quick report about the broken build and sorry for not 
adding all files to the commit.


- Lamarque


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103182
---


On May 4, 2017, 12:32 p.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated May 4, 2017, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-04 Thread Albert Astals Cid

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103182
---



Lamarque, you broke the build.

- Albert Astals Cid


On May 4, 2017, 12:32 p.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated May 4, 2017, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-04 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

(Updated May 4, 2017, 12:32 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 3c1e1648a94c474c9270e203e9462285cd5d0619 by Lamarque V. 
Souza on behalf of Konstantinos Tsanaktsidis to branch master.


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-05-04 Thread KJ Tsanaktsidis


> On April 28, 2017, 1:28 p.m., Lamarque Souza wrote:
> > Ship It!
> 
> KJ Tsanaktsidis wrote:
> Great - thanks for your help and for bearing with my rusty C++! What 
> happens now? I'm waiting on this patch to land for another patch I submitted 
> a while ago: https://git.reviewboard.kde.org/r/130084/
> 
> Lamarque Souza wrote:
> Well, if you do not have a developer account I can commit the patch for 
> you. In order to do that I need your real name and email address to add them 
> to the commit's header.

Nope - I don't have a developer account. Real name is Konstantinos Tsanaktsidis 



- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103148
---


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-29 Thread Lamarque Souza


> On April 28, 2017, 1:28 p.m., Lamarque Souza wrote:
> > Ship It!
> 
> KJ Tsanaktsidis wrote:
> Great - thanks for your help and for bearing with my rusty C++! What 
> happens now? I'm waiting on this patch to land for another patch I submitted 
> a while ago: https://git.reviewboard.kde.org/r/130084/

Well, if you do not have a developer account I can commit the patch for you. In 
order to do that I need your real name and email address to add them to the 
commit's header.


- Lamarque


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103148
---


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-29 Thread KJ Tsanaktsidis


> On April 28, 2017, 1:28 p.m., Lamarque Souza wrote:
> > Ship It!

Great - thanks for your help and for bearing with my rusty C++! What happens 
now? I'm waiting on this patch to land for another patch I submitted a while 
ago: https://git.reviewboard.kde.org/r/130084/


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103148
---


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-28 Thread Lamarque Souza

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103148
---


Ship it!




Ship It!

- Lamarque Souza


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-24 Thread KJ Tsanaktsidis


> On April 22, 2017, 10:27 a.m., Lamarque Souza wrote:
> > autotests/CMakeLists.txt, line 66
> > 
> >
> > CMake's developers recommend using else() instead of 
> > else(). The  part used to be required with cmake 
> > 2.6.x, that is not true with cmake 3.x that we use nowadays.
> 
> KJ Tsanaktsidis wrote:
> I'm not sure I understand here - elseif() needs to have the expression to 
> match to enter the elseif() block? In any case I've gone ahead and deleted 
> this because I worked out a cleaner way to do this using cmake generator 
> expressions.
> 
> Lamarque Souza wrote:
> Oh sorry, I did a mistake. I thought it wase a else(). The expression is 
> required for elseif(), the old code was correct. You can revert to the old 
> code, which require less lines of code. Sorry again.

Actually it was not quite correct - it was defining `HAVE_XXX_MAJOR_MINOR=1` 
for when the header was found, but not `HAVE_XXX_MAJOR_MINOR=0` when it wasn't. 
It worked on Linux because `sys/sysmacros.h` was first, but I don't think it 
would work on most BSD's which have it in `sys/types.h` (the `#if 
HAVE_SYSMACROS_MAJOR_MINOR` check wouldn't compile). This version of it sets 
each `HAVE_XXX` macro to either 1 or 0 on all platforms.


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103087
---


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-23 Thread Lamarque Souza


> On April 22, 2017, 10:27 a.m., Lamarque Souza wrote:
> > autotests/CMakeLists.txt, line 66
> > 
> >
> > CMake's developers recommend using else() instead of 
> > else(). The  part used to be required with cmake 
> > 2.6.x, that is not true with cmake 3.x that we use nowadays.
> 
> KJ Tsanaktsidis wrote:
> I'm not sure I understand here - elseif() needs to have the expression to 
> match to enter the elseif() block? In any case I've gone ahead and deleted 
> this because I worked out a cleaner way to do this using cmake generator 
> expressions.

Oh sorry, I did a mistake. I thought it wase a else(). The expression is 
required for elseif(), the old code was correct. You can revert to the old 
code, which require less lines of code. Sorry again.


- Lamarque


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103087
---


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-23 Thread KJ Tsanaktsidis


> On April 22, 2017, 10:27 a.m., Lamarque Souza wrote:
> > autotests/CMakeLists.txt, line 66
> > 
> >
> > CMake's developers recommend using else() instead of 
> > else(). The  part used to be required with cmake 
> > 2.6.x, that is not true with cmake 3.x that we use nowadays.

I'm not sure I understand here - elseif() needs to have the expression to match 
to enter the elseif() block? In any case I've gone ahead and deleted this 
because I worked out a cleaner way to do this using cmake generator expressions.


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103087
---


On April 23, 2017, 9:56 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 23, 2017, 9:56 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-23 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

(Updated April 23, 2017, 9:56 a.m.)


Review request for KDE Frameworks.


Changes
---

* Fix definition style of const-returning functions
* Replace if()..elseif()...else() CMake macros with a clearer control flow


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs (updated)
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-22 Thread Lamarque Souza

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103087
---


Fix it, then Ship it!





autotests/CMakeLists.txt (line 66)


CMake's developers recommend using else() instead of else(). 
The  part used to be required with cmake 2.6.x, that is not true 
with cmake 3.x that we use nowadays.



autotests/CMakeLists.txt (line 68)


Here too.



autotests/fakeUdisks2.h (line 37)


Code style: the & also goes next to the method's name instead of the return 
type.



autotests/fakeUdisks2.cpp (line 29)


Here too.



src/solid/devices/backends/udisks2/CMakeLists.txt (line 32)


elseif() instead of elseif()



src/solid/devices/backends/udisks2/CMakeLists.txt (line 35)


Here too.


- Lamarque Souza


On April 22, 2017, 12:38 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 22, 2017, 12:38 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-21 Thread KJ Tsanaktsidis


> On April 20, 2017, 4:19 p.m., Lamarque Souza wrote:
> > autotests/fakeUdisks2.h, line 35
> > 
> >
> > It is common practice to pass QString parameters QString as const &:
> > 
> > FakeUdisks2BlockDevice(QObject *parent, const  device, quint64 
> > device_number);

Sorry - you've probably noticed by now but my C++ is pretty rusty... (no pun 
intended)


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103071
---


On April 22, 2017, 12:38 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 22, 2017, 12:38 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-21 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

(Updated April 22, 2017, 12:38 a.m.)


Review request for KDE Frameworks.


Changes
---

Pass strings as const where possible


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs (updated)
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-20 Thread Lamarque Souza

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103071
---




autotests/fakeUdisks2.h (line 35)


It is common practice to pass QString parameters QString as const &:

FakeUdisks2BlockDevice(QObject *parent, const  device, quint64 
device_number);


- Lamarque Souza


On April 20, 2017, 8:49 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 20, 2017, 8:49 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-20 Thread KJ Tsanaktsidis


> On April 19, 2017, 11:28 a.m., Lamarque Souza wrote:
> > autotests/solidudisks2test.cpp, line 78
> > 
> >
> > I think registering to systemBus only works if you are root or has the 
> > right permissions in dbus' configuration. Have you tested this unit test 
> > when running as normal user?

Actually it's not registering to the real system bus. The 
`QTEST_GUILESS_MAIN_SYSTEM_DBUS` macro sets up a new session bus and sets the 
`DBUS_SYSTEM_BUS_ADDRESS` environment variable to point to that bus, faking the 
real system bus out. The test definitely works as non root. This is the same 
strategy used by the solidfreedesktoptest tests.


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103067
---


On April 20, 2017, 8:49 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 20, 2017, 8:49 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-20 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

(Updated April 20, 2017, 8:49 a.m.)


Review request for KDE Frameworks.


Changes
---

Add my name to license header
Fix style of pointer declarations


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs (updated)
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-19 Thread Lamarque Souza

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103067
---




autotests/fakeUdisks2.h (line 2)


You should use this file's author name(s). If you are the author then it is 
your name and email address.



autotests/fakeUdisks2.h (line 35)


Use const QString  and the * goes to the variable, not the type in 
our code style, like this:

FakeUdisks2BlockDevice(QObject *parent, const QString , quint64 
device_number);



autotests/fakeUdisks2.cpp (line 2)


Your name?



autotests/solidudisks2test.cpp (line 78)


I think registering to systemBus only works if you are root or has the 
right permissions in dbus' configuration. Have you tested this unit test when 
running as normal user?



autotests/solidudisks2test.cpp (line 96)


Code style: remove the extra whitespace at the end of the line.


- Lamarque Souza


On April 19, 2017, 11:05 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 19, 2017, 11:05 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-19 Thread KJ Tsanaktsidis


> On April 18, 2017, 9:45 p.m., Lamarque Souza wrote:
> > src/solid/devices/backends/udisks2/udisksblock.cpp, line 31
> > 
> >
> > Usually we use uppper case for macros. That would also save some lines 
> > in this patch.
> > 
> > nitpik: add spaces around >>, like you did for & in the line below.
> 
> KJ Tsanaktsidis wrote:
> Thanks for the review.
> 
> * I would use upper case, but the macro is defined in `sys/sysmacros.h` 
> and `sys/types.h` in lowercase. See 
> https://code.woboq.org/userspace/glibc/misc/sys/sysmacros.h.html.
> * I'm happy enough to fix the formatting issue with `>>`.
> * I'm also halfway through writing a testcase for this - the udisks2 
> stuff is untested so I figured it would be worth going through the motion and 
> setting up the test framework for it even just for this to make adding 
> further test coverage useful. I'll add that to this patch when I finish it 
> either tonight or tomorrow.

OK - I've addressed the formatting issue and added a testcase. Also the link in 
my comment above is wrong because it has a trailing full-stop - should be 
https://code.woboq.org/userspace/glibc/misc/sys/sysmacros.h.html


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103063
---


On April 19, 2017, 11:05 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 19, 2017, 11:05 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
>   autotests/fakeUdisks2.h PRE-CREATION 
>   autotests/fakeUdisks2.cpp PRE-CREATION 
>   autotests/solidudisks2test.cpp PRE-CREATION 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-19 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

(Updated April 19, 2017, 11:05 a.m.)


Review request for KDE Frameworks.


Changes
---

Fix trailing whitespace


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs (updated)
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-19 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

(Updated April 19, 2017, 11:03 a.m.)


Review request for KDE Frameworks.


Changes
---

Added a test case
Fixed formatting of major macro definition


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs (updated)
-

  autotests/CMakeLists.txt 54adeea62b954b9169b37f1eab8fa3e215fafafa 
  autotests/fakeUdisks2.h PRE-CREATION 
  autotests/fakeUdisks2.cpp PRE-CREATION 
  autotests/solidudisks2test.cpp PRE-CREATION 
  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-19 Thread KJ Tsanaktsidis


> On April 18, 2017, 9:45 p.m., Lamarque Souza wrote:
> > src/solid/devices/backends/udisks2/udisksblock.cpp, line 31
> > 
> >
> > Usually we use uppper case for macros. That would also save some lines 
> > in this patch.
> > 
> > nitpik: add spaces around >>, like you did for & in the line below.

Thanks for the review.

* I would use upper case, but the macro is defined in `sys/sysmacros.h` and 
`sys/types.h` in lowercase. See 
https://code.woboq.org/userspace/glibc/misc/sys/sysmacros.h.html.
* I'm happy enough to fix the formatting issue with `>>`.
* I'm also halfway through writing a testcase for this - the udisks2 stuff is 
untested so I figured it would be worth going through the motion and setting up 
the test framework for it even just for this to make adding further test 
coverage useful. I'll add that to this patch when I finish it either tonight or 
tomorrow.


- KJ


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103063
---


On April 17, 2017, 8:42 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 17, 2017, 8:42 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Re: Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-18 Thread Lamarque Souza

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103063
---




src/solid/devices/backends/udisks2/udisksblock.cpp (line 31)


Usually we use uppper case for macros. That would also save some lines in 
this patch.

nitpik: add spaces around >>, like you did for & in the line below.


- Lamarque Souza


On April 17, 2017, 8:42 a.m., KJ Tsanaktsidis wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/130090/
> ---
> 
> (Updated April 17, 2017, 8:42 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> Previously, udesksblock.cpp was attempting to find a definition for
> major/minor on Linux in  by checking Q_OS_LINUX before
> importing the header. Q_OS_LINUX is however only set when
> qsystemdetection.h is included, and the macro was being checked first.
> 
> Even had this check worked, it would still be wrong. On a modern version
> of the userspace linux-headers,  includes definitions for
> major and minor that assume each is limited to 8 bits and that dev_t is
> 16 bits. This is no longer true anymore; on Linux, major numbers can be
> up to 12 bits at present and minor numbers up to 20. Calling these
> macros with dev_t values > 2^16 would give incorrect results.
> 
> Because the Q_OS_LINUX check failed, a fallback version of the macros
> were defined for use on all platforms. The code is allegedly copied from
> kdev_t.h, except it is copied from the *kernel* version of the header,
> not the userspace version. Linux internally uses a different
> representation of dev_t than it exposes to userspace - the kernelspace
> version is 20 bits of minor/12 bits of major contiguously, but the
> userspace version packs the bits in a different order to maintain
> compatability with old 16-bit device numbers. Thus, this code also does
> not work for dev_t values > 2^16.
> 
> To fix this, we add CMake rules to search for a system-provided
> definition of the major/minor macros - on various systems, these can be
> in a few different places. As a fallback, we assume old-style 16-bit
> dev_t (although I suspect that is only used for Windows, where
> major/minor numbers are pretty meaningless anyway).
> 
> 
> Diffs
> -
> 
>   src/solid/devices/backends/udisks2/CMakeLists.txt 
> 34390064af29ace07cbb3470945be098cc606d04 
>   src/solid/devices/backends/udisks2/udisksblock.cpp 
> 0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 
> 
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
> 
> 
> Testing
> ---
> 
> I've written a little snippet to iterate through block devices, print their 
> major/minor number, and their device properties. It was previously 
> incorrectly labeling all my disks with major 0 and minor == device_number 
> (since it was using the first 20 bits for the minor). It now correctly 
> identifies their major/minor number.
> 
> 
> Thanks,
> 
> KJ Tsanaktsidis
> 
>



Review Request 130090: Fix incorrect definition of major(3)/minor(3) macros

2017-04-17 Thread KJ Tsanaktsidis

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/
---

Review request for KDE Frameworks.


Repository: solid


Description
---

Previously, udesksblock.cpp was attempting to find a definition for
major/minor on Linux in  by checking Q_OS_LINUX before
importing the header. Q_OS_LINUX is however only set when
qsystemdetection.h is included, and the macro was being checked first.

Even had this check worked, it would still be wrong. On a modern version
of the userspace linux-headers,  includes definitions for
major and minor that assume each is limited to 8 bits and that dev_t is
16 bits. This is no longer true anymore; on Linux, major numbers can be
up to 12 bits at present and minor numbers up to 20. Calling these
macros with dev_t values > 2^16 would give incorrect results.

Because the Q_OS_LINUX check failed, a fallback version of the macros
were defined for use on all platforms. The code is allegedly copied from
kdev_t.h, except it is copied from the *kernel* version of the header,
not the userspace version. Linux internally uses a different
representation of dev_t than it exposes to userspace - the kernelspace
version is 20 bits of minor/12 bits of major contiguously, but the
userspace version packs the bits in a different order to maintain
compatability with old 16-bit device numbers. Thus, this code also does
not work for dev_t values > 2^16.

To fix this, we add CMake rules to search for a system-provided
definition of the major/minor macros - on various systems, these can be
in a few different places. As a fallback, we assume old-style 16-bit
dev_t (although I suspect that is only used for Windows, where
major/minor numbers are pretty meaningless anyway).


Diffs
-

  src/solid/devices/backends/udisks2/CMakeLists.txt 
34390064af29ace07cbb3470945be098cc606d04 
  src/solid/devices/backends/udisks2/udisksblock.cpp 
0622ec77fcf670a2005d34b7a6c31ca8b53a18d8 

Diff: https://git.reviewboard.kde.org/r/130090/diff/


Testing
---

I've written a little snippet to iterate through block devices, print their 
major/minor number, and their device properties. It was previously incorrectly 
labeling all my disks with major 0 and minor == device_number (since it was 
using the first 20 bits for the minor). It now correctly identifies their 
major/minor number.


Thanks,

KJ Tsanaktsidis