Skip to content
This repository has been archived by the owner on Apr 2, 2024. It is now read-only.

get_block_size: if we can't get from ioctl, try from os.stat() #16

Merged
merged 1 commit into from May 22, 2016

Conversation

kad
Copy link
Member

@kad kad commented May 21, 2016

Under some conditions, ioctl FIGETBSZ can't return real value.
We can try to use fallback via os.stat() to get block size.

Closes #15

Signed-off-by: Alexander D. Kanevskiy kad@kad.name

Under some conditions, ioctl FIGETBSZ can't return real value.
We can try to use fallback via os.stat() to get block size.

Closes intel#15

Signed-off-by: Alexander D. Kanevskiy <kad@kad.name>
@codecov-io
Copy link

Current coverage is 65.39%

Merging #16 into master will decrease coverage by 0.15%

@@             master        #16   diff @@
==========================================
  Files             5          5          
  Lines           988        994     +6   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            648        650     +2   
- Misses          340        344     +4   
  Partials          0          0          

Powered by Codecov. Last updated by 8d78acc...30ff24b

@kad kad merged commit a929607 into intel:master May 22, 2016
return struct.unpack('I', binary_data)[0]
bsize = struct.unpack('I', binary_data)[0]
if not bsize:
import os
Copy link
Contributor

@dedekind dedekind May 24, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to be consistent about where standard modules are imported. I think most of the code imports everything at the beginning, and there may be some exceptions when it comes to some rare/special modules, which are imported inside functions. But stuff like 'os' would always be imported at the beginning. I personally think it is better this way.

But if you prefer "on-demand" import, it is better to change it globablly, rather than doing introducing inconsistent patterns and making the code less clean in general.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point. I'll refactor imports in BmapHelpers.py

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In PR #19

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants