From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, jens.axboe@oracle.com
Subject: Re: Re: [PATCH v2] dm: add topology support
Date: Wed, 10 Jun 2009 13:58:45 -0400 [thread overview]
Message-ID: <yq1ocsw55t6.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20090610140028.GD25088@redhat.com> (Mike Snitzer's message of "Wed, 10 Jun 2009 10:00:29 -0400")
>>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
Mike> So the question: is _not_ using the blk_queue_*() setters
Mike> perfectly fine? Given that DM has always _not_ used them the
Mike> quick answer is "seems fine".
Mike> But I need to dig a bit more to understand if the additional logic
Mike> in the blk_queue_*() setters is something DM shouldn't be
Mike> circumventing.
The original intent was that drivers like DM and MD would seed their
limits using the blk_queue* calls before adding any component devices.
blk_stack_limits() would then scale accordingly for every new device
added.
Is there any reason in particular that this approach wouldn't work for
DM? I.e. set defaults ahead of time instead of doing it upon table
completion using check_for_valid_limits()?
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2009-06-10 17:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 5:14 [PATCH v2] dm: add topology support Mike Snitzer
2009-06-10 6:51 ` Martin K. Petersen
2009-06-10 14:00 ` Mike Snitzer
2009-06-10 14:36 ` Alasdair G Kergon
2009-06-10 17:58 ` Martin K. Petersen [this message]
2009-06-10 21:12 ` Mike Snitzer
2009-06-10 22:06 ` Martin K. Petersen
2009-06-10 23:08 ` Alasdair G Kergon
2009-06-11 2:21 ` Martin K. Petersen
2009-06-11 9:43 ` Alasdair G Kergon
2009-06-12 4:58 ` block: Introduce helper to reset queue limits to default values Martin K. Petersen
2009-06-15 14:56 ` Mike Snitzer
2009-06-15 18:44 ` Jens Axboe
2009-06-12 4:17 ` [PATCH v2] dm: add topology support Mike Snitzer
2009-06-12 8:45 ` Alasdair G Kergon
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=yq1ocsw55t6.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.