On Wednesday July 9, maan@xxxxxxxxxxxxxxx wrote:
> > If you are keen to do some more tidying up, I would really love it if
> > all internal values that are currently stored as 'K' would instead be
> > stored as sectors.
> > So for example with update_size, we could make the value that is
> > passed in be a number of sectors, get rid of those divisions.
>
> Of course the size unit exported to user space programs via sysfs must
> not change. So if we change update_size() as you propose, the division
> has to be done in the size_store() instead, which calls update_size()
> with a value obtained from sysfs.
Correct - the unit exported to userspace must not change.
We could conceivably make it fractional though.
100.5
for 201 sectors.
size_store would do a multiplication:
err = update_size(mddev, size*2);
size_show would do a division:
return sprintf(page, "%llu\n", mddev->size/2);
or conceivably
return sprintf(page, "%llu%s\n", mddev->size/2,
(mddev->size&1) ? ".5":"");
>
> Therefore I think it's impossible to completely get rid of the
> divisions/multiplications without breaking user space, but it might
> still be worth to change the internal representations.
Exactly how I see it.
>
> I will have a look at it, but I might need some further advice.
>
> > BTW your patches arrive without a valid "To" field. The Date is odd
> > too.
>
> They were generated by git-format-patch and then bounced to the
> list. The date is "correct" in the sense that I checked them in back
> then. I'll see that subsequent patches have a proper date and a valid
> "To" field.
The date wasn't a problem, it just seemed odd. Your explanation makes
perfect sense.
I think you are "supposed" to use
git-send-mail --to linux-raid@xxxxxxxxxxxxxxx ...
to send the mail. That sticks in a "To:". Without the "To:" is have
to edit the headers to reply to the list (which isn't a big problem).
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
