Randy Dunlap wrote:
>> Hmm.. yes.. a library routine would be nice!
>
> you mean something like lib/cmdline.c::memparse() ?
>
Excellent, one of the reasons to love Linux (there's already
code) :-)
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
On Mon, 09 Jul 2007 21:44:31 -0700 Balbir Singh wrote:
> Peter Zijlstra wrote:
> > On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
> >
> >> I am not a CLUI expert, but rounding off bytes will something that
> >> the administrators will probably complain about. Since we manage
> >> the cont
Peter Zijlstra wrote:
> On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
>
>> I am not a CLUI expert, but rounding off bytes will something that
>> the administrators will probably complain about. Since we manage
>> the controller memory in pages, it might be the easiest unit to use.
>> The
On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
> I am not a CLUI expert, but rounding off bytes will something that
> the administrators will probably complain about. Since we manage
> the controller memory in pages, it might be the easiest unit to use.
> The output is totally different ma
Balbir Singh wrote:
> Kirill Korotaev wrote:
>
>>Paul Menage wrote:
>>
>>>On 6/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>>
>>>
The problem with input in bytes is that the user will have to ensure
that the input is
a multiple of page size, which implies that she would need to us
Kirill Korotaev wrote:
> Paul Menage wrote:
>> On 6/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>>> The problem with input in bytes is that the user will have to ensure
>>> that the input is
>>> a multiple of page size, which implies that she would need to use the
>>> calculator every time.
Paul Menage wrote:
> On 6/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>>The problem with input in bytes is that the user will have to ensure
>>that the input is
>>a multiple of page size, which implies that she would need to use the
>>calculator every time.
>>
>
>
> Having input in bytes s
Paul Menage wrote:
> On 6/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>> The problem with input in bytes is that the user will have to ensure
>> that the input is
>> a multiple of page size, which implies that she would need to use the
>> calculator every time.
>>
>
> Having input in bytes
On 6/22/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
The problem with input in bytes is that the user will have to ensure
that the input is
a multiple of page size, which implies that she would need to use the
calculator every time.
Having input in bytes seems pretty natural to me. Why not ju
On 6/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
On 6/21/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>
> Nothing wrong, but currently they are shown in "natural" points, i.e. in
> those that the controller accounts them in. For RSS controller the natural
> point is "page", but auto-convertin
On 6/21/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
Nothing wrong, but currently they are shown in "natural" points, i.e. in
those that the controller accounts them in. For RSS controller the natural
point is "page", but auto-converting them from pages to bytes is wrong, as
not all the contro
Paul Menage wrote:
> On 6/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>>
>> Display the current usage and limit in a more user friendly manner.
>> Number
>> of pages can be confusing if the page size is different. Some systems
>> can choose a page size of 64KB.
>
> I'm not sure that's such a
On 6/20/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Display the current usage and limit in a more user friendly manner. Number
of pages can be confusing if the page size is different. Some systems
can choose a page size of 64KB.
I'm not sure that's such a great idea. "Human-friendly"
represen
Display the current usage and limit in a more user friendly manner. Number
of pages can be confusing if the page size is different. Some systems
can choose a page size of 64KB.
NOTE: Values shown in MB and GB could be rounded off.
Sample display
:~ # cat /container/rss_limit
17179869183 (GB),
14 matches
Mail list logo
