LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Valdis.Kletnieks@vt.edu
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
Ken Chen <kenchen@google.com>, Tomas M <tomas@slax.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] remove artificial software max_loop limit
Date: Sat, 07 Apr 2007 12:34:14 -0400 [thread overview]
Message-ID: <4617C806.2030304@tmr.com> (raw)
In-Reply-To: <11158.1175962732@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> On Fri, 06 Apr 2007 16:33:32 EDT, Bill Davidsen said:
>
>> Jan Engelhardt wrote:
>>
>
>
>>> Who cares if the user specifies max_loop=8 but still is able to open up
>>> /dev/loop8, loop9, etc.? max_loop=X basically meant (at least to me)
>>> "have at least X" loops ready.
>>>
>>>
>> You have just come up with a really good reason not to do unlimited
>> loops.
>>
>
> That, and I'd expect the intuitive name for "have at least N ready" to
> be 'min_loop=N'. 'max_loop=N' means (to me, at least) "If I ask for N+1,
> something has obviously gone very wrong, so please shoot my process before
> it gets worse".
>
> Maybe what's needed is *both* a max_ and min_ parameter?
>
I think that max_loop is a sufficient statement of the highest number of
devices needed, and can reasonably interpreted as both "I may need this
many" and "I won't legitimately want more."
As I recall memory is allocated as the device is set up, so unless you
want to use the max memory at boot, "just in case," the minimum won't be
guaranteed anyway. Something else could eat memory.
In practice I think asking for way too many is more common than not
being able to get to the max. It may happen but it's a corner case, and
status is returned.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2007-04-07 16:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 7:53 Ken Chen
2007-03-30 8:48 ` Ken Chen
2007-03-30 9:07 ` Jan Engelhardt
2007-03-30 9:25 ` Ken Chen
2007-03-30 16:16 ` Jan Engelhardt
2007-03-30 21:15 ` Andrew Morton
2007-03-30 22:06 ` Ken Chen
2007-03-30 22:50 ` Andrew Morton
2007-03-31 17:07 ` Greg KH
2007-03-31 17:41 ` Andrew Morton
2007-04-01 4:16 ` Ken Chen
2007-04-04 10:31 ` Tomas M
2007-04-04 18:47 ` Andrew Morton
2007-04-01 16:53 ` Tomas M
2007-04-01 16:57 ` Tomas M
2007-04-01 18:10 ` Ken Chen
2007-04-01 19:06 ` Jan Engelhardt
2007-04-06 20:33 ` Bill Davidsen
2007-04-07 16:18 ` Valdis.Kletnieks
2007-04-07 16:34 ` Bill Davidsen [this message]
2007-03-30 21:46 ` Andrew Morton
2007-03-30 21:52 ` Jan Engelhardt
2007-04-01 9:16 devzero
2007-04-01 10:53 devzero
2007-04-01 18:03 ` Ken Chen
2007-04-01 19:00 ` Jeff Dike
2007-04-01 18:36 devzero
2007-04-01 18:43 ` Kyle Moffett
2007-04-01 18:54 devzero
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4617C806.2030304@tmr.com \
--to=davidsen@tmr.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=jengelh@linux01.gwdg.de \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tomas@slax.org \
--subject='Re: [patch] remove artificial software max_loop limit' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).