On 8/23/17 3:14 PM, Darrick J. Wong wrote:
> On Tue, Aug 22, 2017 at 09:13:03PM -0500, Eric Sandeen wrote:
>> On 8/22/17 8:01 PM, Dave Chinner wrote:
>>> On Tue, Aug 22, 2017 at 04:12:48PM -0500, Eric Sandeen wrote:
>>>> Blocksize and sectorsize are unique in that they must
>>>> be provided, unlike every other suffix which can be
>>>> calculated from constants.
>>>>
>>>> Nothing protects against unspecified block & sector size,
>>>> so catch it if it happens and return a parsing error.
>>>>
>>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
>>>> ---
>>>>
>>>> diff --git a/libxcmd/input.c b/libxcmd/input.c
>>>> index 7a69dc1..7b86225 100644
>>>> --- a/libxcmd/input.c
>>>> +++ b/libxcmd/input.c
>>>> @@ -330,8 +330,12 @@ cvtnum(
>>>> c = tolower(*sp);
>>>> switch (c) {
>>>> case 'b':
>>>> + if (!blocksize)
>>>> + return -1LL;
>>>> return i * blocksize;
>>>> case 's':
>>>> + if (!sectorsize)
>>>> + return -1LL;
>>>> return i * sectorsize;
>>>> case 'k':
>>>> return KILOBYTES(i);
>>>
>>> With this you could have mkfs call the generic function, too.
>>
>> Yep, or at least closer; mkfs does a printf and usage()/exit()
>> and it indicates a user error (most likely)
>>
>> in libxcmd/xfs_io it's more of a programming error, with no
>> printf to the user at least today... so would need a little more
>> finessing.
>
> This series looks mostly fine to me, but I'm wondering if io_cvtnum
> should be promoted so that mkfs/spaceman/quota/etc can take advantage of
> it too?
I thought about that, but it relies on the global var "file" that io uses,
which seems a bit unique to io, no?
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
