Re: [dm-devel] [PATCH 5/7] Move the declaration of mpath_mx_alloc_len to a header file
On Thu, 2017-05-18 at 16:00 -0500, Benjamin Marzinski wrote:
> On Thu, May 18, 2017 at 08:36:10PM +, Bart Van Assche wrote:
> > On Thu, 2017-05-18 at 15:06 -0500, Benjamin Marzinski wrote:
> > > On Wed, May 17, 2017 at 08:43:07AM -0700, Bart Van Assche wrote:
> > > > This allows the compiler to verify consistency of declaration and
> > > > definition.
> > > > Signed-off-by: Bart Van Assche
> > > > ---
> > > > libmpathpersist/mpath_persist.h | 3 +++
> > > > mpathpersist/main.c | 1 -
> > > > multipathd/main.c | 2 --
> > > > 3 files changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libmpathpersist/mpath_persist.h
> > > > b/libmpathpersist/mpath_persist.h
> > > > index 79de5b5b..3faa8c9e 100644
> > > > --- a/libmpathpersist/mpath_persist.h
> > > > +++ b/libmpathpersist/mpath_persist.h
> > > > @@ -81,6 +81,9 @@ extern "C" {
> > > >
> > > >
> > > >
> > > > +extern unsigned int mpath_mx_alloc_len;
> > > > +
> > > > +
> > > >
> > > > struct prin_readdescr
> > > > {
> > > > diff --git a/mpathpersist/main.c b/mpathpersist/main.c
> > > > index 2e0aba3c..9de52b98 100644
> > > > --- a/mpathpersist/main.c
> > > > +++ b/mpathpersist/main.c
> > > > @@ -40,7 +40,6 @@ void mpath_print_transport_id(struct prin_fulldescr
> > > > *fdesc);
> > > > int construct_transportid(const char * inp, struct transportid
> > > > transid[], int num_transportids);
> > > >
> > > > int logsink;
> > > > -unsigned int mpath_mx_alloc_len;
> > > > struct config *multipath_conf;
> > > >
> > > > struct config *get_multipath_config(void)
> > > > diff --git a/multipathd/main.c b/multipathd/main.c
> > > > index b167cb4c..81c76cab 100644
> > > > --- a/multipathd/main.c
> > > > +++ b/multipathd/main.c
> > > > @@ -104,8 +104,6 @@ struct mpath_event_param
> > > > struct multipath *mpp;
> > > > };
> > > >
> > > > -unsigned int mpath_mx_alloc_len;
> > > > -
> > > > int logsink;
> > > > int verbosity;
> > > > int bindings_read_only;
> > >
> > > I get why you did this, but I'm not totally happy with where the extern
> > > declaration is. libmpathpersist is actually a public library, unlike
> > > libmultipath, and mpath_persist.h is that header for that library. As
> > > such, I'd rather not add things to it that users aren't supposed to mess
> > > with. So, is your intention to let users set the max alloc length. If
> > > so, we should probably give them a function, or at the very least some
> > > comments telling them what this variable does. If we only want the
> > > mpathpersist program to be able to change this, then we probably
> > > should probably put the declaration in a different header file, perhaps
> > > mpath_pr_ioctl.c. Now that I'm looking at this, I see that this option
> > > (-l) isn't even documented in the mpathpersist manpage. So right now
> > > this seems likely a completely unused feature. I guess since it exists,
> > > I'd lean towards actually documenting it and putting it in the
> > > libmpathpersist API in a more useful way.
> >
> > (changed top-posting into bottom-posting)
> >
> > Hello Ben,
> >
> > It was not my intention to make the mpath_mx_alloc_len variable accessible
> > to users of the libmpathpersist library. From what I can see in
> > libmpathpersist/Makefile the only public header file of the libmpathpersist
> > library is mpath_persist.h. Would you agree to move that declaration into
> > mpathpr.h?
>
> Sure
Hello Ben,
When I tried to implement what I proposed I noticed that there is already a user
of the libmpathpersist library that modifies the mpath_mx_alloc_len variable,
namely the mpathpersist executable. So what I proposed is not possible because
it
would break the build of the mpathpersist executable.
Bart.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH] multipath-tools:Prioritizer based on a time-delay algorithm
Hi Benjamin,
Thank you very much for your comments.
Please find my replys and the up-to-date patch.
Best regards!
>
> First, one overall question. We have dynamic path selectors available to
> deal with paths that are just simply slower that other paths, but can
> still be used together. Is there specific hardware or a specific setup
> where this isn't good enough and we really need to seperate these paths
> into different pathgroups, but we can't find out deterministically how
> the groups should be set up? It just seems like there could be a less
> hacky solution to this problem, but perhaps there are some situations
> where this is truly the best option. I'm just wondering what those are.1. In
> the Storage-Backup environment of HyperCluster，includs one storage array near
to the host and one remote storage array, and the two storage arrays have the
same hardware.
The same LUN is writed or readed by the two storage arrays.
However, usually, the average latency of the paths of the remote storage array
is much higher than the
near storage array's.
apparently, the prioritizer can be a good automatic solution.
And the current selectors don't solve it, IOs will send to the paths of the
remote storage array, IOPS will be influenced unavoidably.
2. In the environment of single storage array, the prioritizer can
automatically separate the paths who's latency is much higher,
IOs will not send to this paths.
But the current selectors don't solve this problem, IOPS will be influenced
unavoidably.
>> +
>> +/* interval_unit_str and interval_unit_type keep the same assignment
>> sequence */
>> +static const char interval_unit_str[][MAX_CHAR_SIZE] = {
>> +CHAR_USEC, CHAR_MSEC, CHAR_SEC
>
> This is a nit, but for constant strings, could you please use "char
> *var" instead of "char var[]", to be consistent with the rest of the
> multipath code.
Thanks, as the following patch.
>> +if ((args == NULL) || (interval == NULL)
>> +|| (consnum == NULL) || (type == NULL))
>> +return 0;
>> +
>> +/* int type */
>> +if ((size < 1) || (size > MAX_CHAR_SIZE-1))
>> +return 0;
>
> You should probably have log messages for these error returns.
Thanks, as the following patch.
>> +
>> +memcpy(source, args, size+1);
>> +if (strstr(source, vertica) == NULL)
>> +return 0;
>> +
>> +*type = get_interval_type(source, typestr);
>> +if (*type == INTERVAL_INVALID)
>> +{
>> +condlog(0, "delay_interval type is invalid");
>> +return 0;
>> +}
>
> I'm confused here. How do you get to use the default interval. Shouldn't
> you accept "20s|" and "|30" and as valid inputs that use the defaults
> for the part they don't specify.
OK，the default arguments value is removed. If get inputs failed, return default
priority "0".
As the following patch.
>
>> +tokenbefore = strtok(source, vertica);
>> +tokenafter = strtok(NULL, vertica);
>> +typestr[1] = '\0';
>> +tokenbefore = strtok(tokenbefore, typestr);
>> +if ((tokenbefore == NULL) || (tokenafter == NULL))
>> +return 0;
>> +
>> +tmp = tokenbefore;
>> +while (*tmp != '\0')
>> +if (!isdigit(*tmp++))
>> +{
>> +condlog(0, "delay_interval string include invalid char");
>> +return 0;
>> +}
>> +
>> +tmp = tokenafter;
>> +while (*tmp != '\0')
>> +if (!isdigit(*tmp++))
>> +{
>> +condlog(0, "cons_num string include invalid char");
>> +return 0;
>> +}
>> +
>> +*interval = atoi(tokenbefore);
>
> Why do you keep track of the type and the interval seperately? Can't you
> just find out the type, and use that to multiply the interval once you
> read it, and then just use that value, instead of keeping track of two
> values across multiple functions?
Thanks, as the following patch.
>> +
>> +if (pp->fd < 0)
>> +return -PRIO_NO_INFORMATION;
>> +
>> +if (get_delay_pref_arg(args, &delay_interval, &cons_num, &type) == 0)
>> +{
>> +condlog(3, "%s: get delay arg fail", pp->dev);
>
> Why use the word "fail" in this message? Not setting prio_args to get
> the defaults seems like a perfectly valid choice.
The defaults are not used. Insteadly, return default priority "0". See below.
>> diff --git a/libmultipath/prioritizers/delayedpath.h
>> b/libmultipath/prioritizers/delayedpath.h
>> new file mode 100644
>> index 000..d8213e9
>> --- /dev/null
>> +++ b/libmultipath/prioritizers/delayedpath.h
>> @@ -0,0 +1,17 @@
>> +#ifndef _DELAYEDPATH_H
>> +#define _DELAYEDPATH_H
>> +
>> +#define PRIO_DELAYED_PATH "delayedpath"
>
> In order for the rest of the code to refer to this prioritizer, this
> define should be in prio.h with the other prioritizer names, and as long
> as delayedpath.c includes prio.h, there's no need to put it in
> delayedpath.h.
OK, as the following patch.
>
>> +
>> +#define PRIO_NO_INFORMATION 5
>
> The rest of the multipath code only cares i
Re: [dm-devel] [PATCH] multipath-tools:Prioritizer based on a time-delay algorithm
Hello Martin,
Firstly, thank you very much for your comments.
And find my replys and the up-to-date patch.
Best regards!
> Please think about the name once again. Maybe you should call it
> "io_latency" or "path_latency" instead of "delayedpath"?
OK, as the following patch.
>
> Hm, I can't see a lot of difference in the parsing code wrt the
> previous version. IMO it's still non-straightforward and hard to
> comprehend. Maybe I didn't express myself clearly enough. Here is how
> I'd code this:
>
> 1. Verify that the string starts with a digit. Error if it does not.
> 2. Parse the delay interval using strtoul().
> 3. The "end" pointer of strtoul() points to the unit, which has to be
> "s", "ms" or "us". Verify, and set the unit accordingly.
> 4. Verify that the next character is '|', and that it's followed by a
> digit.
> 5. Parse the number with strtoul()
> 6. Verify that there's no garbage at the end of the string.
Thank you , as the following patch.
>
> Please follow the https://en.wikipedia.org/wiki/Robustness_principle.
> If a user enters "1500ms" here, the parsing will silently fail, and
> with it the whole prio algorithm. This will cause user confusion.
> Please don't do this
Thank you , as the following patch.
>
> However please consider lowering the upper bound, I kind of doubt that
> 1000 IOs will finish quickly. More often than not, a lot of paths will
> appear at the same time (e.g. if a port of a storage array is enabled)
> and we'll have to send 1000 IOs to each one.
>
OK, the upper bound lower to 200, as the following patch.
>> +while (temp-- > 0)
>> +{
>> +(void)clock_gettime(CLOCK_MONOTONIC, &tv);
>> +before = timeval_to_us(&tv);
>> +
>> +if (do_readsector0(pp->fd, timeout) == 2)
>> +{
>> +condlog(0, "%s: path down", pp->dev);
>> +return -1;
>> +}
>> +
>> +(void)clock_gettime(CLOCK_MONOTONIC, &tv);
>> +after = timeval_to_us(&tv);
>> +
>> +delay = after - before;
>> +
>> +min = (min <= delay) ? min : delay;
>> +max = (max >= delay) ? max : delay;
>> +
>> +toldelay += delay;
>> +}
>> +
>> +toldelay -= min + max;
>
> Why are you doing this? If you want to discard "extreme" values, this
> is probably not sufficient. If cons == 3, this will have the effect to
> use a single measurement rather than an average, is that intended?
>
> Btw, as you are doing statistics here anyway, you may want to calculate
> the estimate of the standard deviation and warn the user if the
> delay_interval is smaller than, say, 2 * standard deviation.
>
> Please consider printing a message with the measured value at debug
> level 3 or higher.
OK, as the following patch.
>> "%N:%R:%n:%r"\fR. For example: 0x200100e08ba0aea0:0x210100e08ba0aea0:.*:.*
>> , .*:.*:iqn.2009-10.com.redhat.msp.lab.ask-06:.*
>> .RE
>> .TP 12
>> +.I delayed
>
> should be "delayedpath" here?
OK, as the following patch.
>
>> +Needs a value of the form
>> +\fI""\fR
>> +.RS
>> +.TP 8
>> +.I delay_interval
>> +The interval values of average IO-time-delay between two different
>> neighbour ranks of path priority, used to partition different
>> priority ranks.
>
> It might be good to give an example here, like this:
>
> "If delay_interval=10ms, the paths will be grouped in priority groups
> with path latency 0-10ms, 10-20ms, 20-30ms, etc."
OK, as the following patch.>
---
>From 58d718fdd34550bd9c4a32c6e9a87099c1e45a9f Mon Sep 17 00:00:00 2001
From: Yang Feng
Date: Fri, 19 May 2017 16:09:07 +0800
Subject: [PATCH] libmultipath/prioritizers: Prioritizer for device mapper
multipath, where the corresponding priority
values of specific paths are provided by a latency algorithm. And the latency
algorithm is dependent on the following
arguments(latency_interval and io_num). The principle of the algorithm is
illustrated as follows:
1. By sending a certain number "cons_num" of read IOs to the current path
continuously, the IOs' average latency can be calculated.
2. According to the average latency of each path and the weight value
"latency_interval", the priority "rc" of each path can be provided.
latency_interval latency_interval latency_interval
latency_interval
|--|--|--|...|--|
| priority rank 1 | priority rank 2 | priority rank 3 |...|
priority rank x |
|--|--|--|...|--|
Priority Rank Partitioning
---
libmultipath/prioritizers/Makefile | 6 +-
libmultipath/prioritizers/path_latency.c | 271 +++
multipath/multipath.conf.5 | 18 ++
3 files changed, 294 insertions(+), 1 deletion(-)
create mode 100644 libmultipath/prioritizers/path_latency.c
diff --git a/libmultip
Re: [dm-devel] [PATCH 12/15] block: merge blk_types.h into bio.h
On Thu, May 18, 2017 at 02:25:52PM +, Bart Van Assche wrote: > On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote: > > We've cleaned up our headers sufficiently that we don't need this split > > anymore. > > Hello Christoph, > > Request-based drivers need the structure definitions from and > the type definitions from but do not need the definition > of > struct bio. Have you considered to remove #include from file > include/linux/blkdev.h? Do you think that would help to reduce the kernel > build > time? Most block drivers end up needing bio.h anyway. But I can skip this part of the series for now. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dedicated error codes for the block layer
On Thu, May 18, 2017 at 04:55:08PM +0200, David Sterba wrote: > JFYI, the patches 13 and 15 are missing, not in linux-btrfs mailbox and > patchwork web. Does not look like a delay, maybe vger refused them > completely. They still haven't made it to linux-block and linux-btrfs, but they did make it to dm-devel, which is not host on vger. I also have a git tree here: git://git.infradead.org/users/hch/block.git block-errors Gitweb: http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/block-errors -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH v8 0/2] dm: boot a mapped device without an initramfs
Dear all, So here is a new version of the patches to be reviewed, this time as suggested by Alasdair the patches are reworked to match with the new dmsetup bootformat feature [1]. These patches are not reviewed yet but the format was discussed in the IRC and was suggested to send the kernel patches in parallel. Changes since v7: - Fix build error due commit e516db4f67 (dm ioctl: add a new DM_DEV_ARM_POLL ioctl) Changes since v6: - Add a new function to issue the equivalent of a DM ioctl programatically. - Use the new ioctl interface to create the devices. - Use a comma-delimited and semi-colon delimited dmsetup-like commands. Changes since v5: - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html [1] https://www.redhat.com/archives/linux-lvm/2017-May/msg00047.html Wating for your feedback, Enric Balletbo i Serra (1): dm ioctl: add a device mapper ioctl function. Will Drewry (1): init: add support to directly boot to a mapped device Documentation/admin-guide/kernel-parameters.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 3 + Documentation/device-mapper/dm-boot.txt | 65 drivers/md/dm-ioctl.c | 50 +++ include/linux/device-mapper.h | 6 + init/Makefile | 1 + init/do_mounts.c| 1 + init/do_mounts.h| 10 + init/do_mounts_dm.c | 459 9 files changed, 596 insertions(+) create mode 100644 Documentation/device-mapper/dm-boot.txt create mode 100644 init/do_mounts_dm.c -- 2.9.3 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH v8 2/2] dm ioctl: add a device mapper ioctl function.
Add a dm_ioctl_cmd to issue the equivalent of a DM ioctl call in kernel.
Signed-off-by: Enric Balletbo i Serra
---
drivers/md/dm-ioctl.c | 50 +++
include/linux/device-mapper.h | 6 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index d45c681..033e31d 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -2011,3 +2011,53 @@ int dm_copy_name_and_uuid(struct mapped_device *md, char
*name, char *uuid)
return r;
}
+
+/**
+ * dm_ioctl_cmd - Device mapper ioctl's
+ * @command: ioctl command
+ * @param: Pointer to device mapped ioctl struct
+ */
+int dm_ioctl_cmd(uint command, struct dm_ioctl *param)
+{
+ int r = 0;
+ int ioctl_flags;
+ unsigned int cmd;
+ ioctl_fn fn = NULL;
+ size_t input_param_size;
+ struct file *filp = NULL;
+
+ if (_IOC_TYPE(command) != DM_IOCTL)
+ return -ENOTTY;
+
+ /* DM_DEV_ARM_POLL is not supported */
+ if (command == DM_DEV_ARM_POLL)
+ return -EINVAL;
+
+ cmd = _IOC_NR(command);
+
+ /*
+* Nothing more to do for the version command.
+*/
+ if (cmd == DM_VERSION_CMD)
+ return 0;
+
+ fn = lookup_ioctl(cmd, &ioctl_flags);
+ if (!fn) {
+ DMWARN("dm_ioctl: unknown command 0x%x", command);
+ return -ENOTTY;
+ }
+
+ input_param_size = param->data_size;
+ r = validate_params(cmd, param);
+ if (r)
+ return r;
+
+ param->data_size = sizeof(*param);
+ r = fn(filp, param, input_param_size);
+
+ if (unlikely(param->flags & DM_BUFFER_FULL_FLAG) &&
+ unlikely(ioctl_flags & IOCTL_FLAGS_NO_PARAMS))
+ DMERR("ioctl %d tried to output some data but has
IOCTL_FLAGS_NO_PARAMS set", cmd);
+
+ return r;
+}
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index f4c639c..f81ba42 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
struct dm_dev;
struct dm_target;
@@ -446,6 +447,11 @@ int dm_noflush_suspending(struct dm_target *ti);
void dm_accept_partial_bio(struct bio *bio, unsigned n_sectors);
union map_info *dm_get_rq_mapinfo(struct request *rq);
+/*
+ * Device mapper ioctl function.
+ */
+int dm_ioctl_cmd(unsigned int command, struct dm_ioctl *param);
+
struct queue_limits *dm_get_queue_limits(struct mapped_device *md);
/*
--
2.9.3
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH v8 1/2] init: add support to directly boot to a mapped device
From: Will Drewry Add a dm= kernel parameter modeled after the md= parameter from do_mounts_md. It allows for device-mapper targets to be configured at boot time for use early in the boot process (as the root device or otherwise). Signed-off-by: Will Drewry Signed-off-by: Kees Cook [rework to use dm_ioctl calls] Signed-off-by: Enric Balletbo i Serra --- Documentation/admin-guide/kernel-parameters.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 3 + Documentation/device-mapper/dm-boot.txt | 65 init/Makefile | 1 + init/do_mounts.c| 1 + init/do_mounts.h| 10 + init/do_mounts_dm.c | 459 7 files changed, 540 insertions(+) create mode 100644 Documentation/device-mapper/dm-boot.txt create mode 100644 init/do_mounts_dm.c diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index d76ab39..5301f45 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -92,6 +92,7 @@ parameter is applicable:: BLACKFIN Blackfin architecture is enabled. CLK Common clock infrastructure is enabled. CMA Contiguous Memory Area support is enabled. + DM Device mapper support is enabled. DRM Direct Rendering Management support is enabled. DYNAMIC_DEBUG Build in debug messages and enable them at runtime EDD BIOS Enhanced Disk Drive Services (EDD) is enabled diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f85bfe0..0ea65c2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -829,6 +829,9 @@ dis_ucode_ldr [X86] Disable the microcode loader. + dm= [DM] Allows early creation of a device-mapper device. + See Documentation/device-mapper/boot.txt. + dma_debug=off If the kernel is compiled with DMA_API_DEBUG support, this option disables the debugging code at boot. diff --git a/Documentation/device-mapper/dm-boot.txt b/Documentation/device-mapper/dm-boot.txt new file mode 100644 index 000..50f08ec --- /dev/null +++ b/Documentation/device-mapper/dm-boot.txt @@ -0,0 +1,65 @@ +Boot time creation of mapped devices + + +It is possible to configure a device mapper device to act as the root +device for your system in two ways. + +The first is to build an initial ramdisk which boots to a minimal +userspace which configures the device, then pivot_root(8) in to it. + +The second is to possible when the device-mapper and any targets are +compiled into the kernel (not a module), one or more device-mappers may +be created and used as the root device at boot time with the parameters +given with the boot line dm=... + +The format is specified as a simple string of data separated by commas and +optionally semi-colons, where: + - a comma is used to separate fields like name, uuid, flags and table (specifies + one device) + - a semi-colon is used to separate devices. + +So the format will look like this: + + dm=,,,[,+][;,,,[,+]]+ + +Where, + ::= The device name. + ::= ---- | "" +::= "ro" | "rw" +::= + ::= "verity" | "bootcache" | ... + +The dm line may be as normal when using the dmsetup tool when using the +--bootformat argument. + +Unless renamed by udev, the device node created will be dm-0 as the +first minor number for the device-mapper is used during early creation. + +Examples + +An example of booting to a linear array made up of user-mode linux block +devices: + + dm="lroot,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \ + root=/dev/dm-0 + +This will boot to a rw dm-linear target of 8192 sectors split across two +block devices identified by their major:minor numbers. After boot, udev +will rename this target to /dev/mapper/lroot (depending on the rules). +No uuid was assigned. + +An example of multiple device-mappers, with the dm="..." contents shown +here split on multiple lines for readability: + +vboot,,ro, + 0 1768000 bootcache +aa55b119-2a47-8c45-946a-5ac57765011f+1 +76e9be054b15884a9fa85973e9cb274c93afadb6 +1768000 10 23 2; +vroot,,ro, + 0 1740800 verity 254:0 254:0 1740800 sha1 +76e9be054b15884a9fa85973e9cb274c93afadb6 +5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe; +vram,,rw, + 0 32768 linear 1:0 0, + 32768 32768 linear 1:1 0 diff --git a/init/Makefile b/init/Makefile index c4fb455..30424d7 100644 --- a/init/Makefile +++ b/init/Makefile @@ -20,6 +20,7 @@ mounts-y
Re: [dm-devel] [PATCH v7 0/2] dm: boot a mapped device without an initramfs
Hi, 2017-05-18 18:29 GMT+02:00 Enric Balletbo i Serra : > Dear all, > > So here is a new version of the patches to be reviewed, this time as > suggested by Alasdair the patches are reworked to match with the new > dmsetup bootformat feature [1]. These patches are not reviewed yet but > the format was discussed in the IRC and was suggested to send the > kernel patches in parallel. > > Changes since v6: > - Add a new function to issue the equivalent of a DM ioctl programatically. > - Use the new ioctl interface to create the devices. > - Use a comma-delimited and semi-colon delimited dmsetup-like commands. > > Changes since v5: > - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html > > [1] https://www.redhat.com/archives/linux-lvm/2017-May/msg00047.html > > Wating for your feedback, > > Enric Balletbo i Serra (1): > dm ioctl: add a device mapper ioctl function. > > Will Drewry (1): > init: add support to directly boot to a mapped device > > Documentation/admin-guide/kernel-parameters.rst | 1 + > Documentation/admin-guide/kernel-parameters.txt | 3 + > Documentation/device-mapper/dm-boot.txt | 65 > drivers/md/dm-ioctl.c | 45 +++ > include/linux/device-mapper.h | 6 + > init/Makefile | 1 + > init/do_mounts.c| 1 + > init/do_mounts.h| 10 + > init/do_mounts_dm.c | 459 > > 9 files changed, 591 insertions(+) > create mode 100644 Documentation/device-mapper/dm-boot.txt > create mode 100644 init/do_mounts_dm.c > > -- > 2.9.3 > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel Rebasing the patches against current linux-next I just noticied that there is a build error due commit commit e516db4f676ac88c7c7f698f8047178e8accc3b8 Author: Mikulas Patocka Date: Fri May 5 11:12:52 2017 -0700 dm ioctl: add a new DM_DEV_ARM_POLL ioctl So I'll send v8 to fix this. Best regards, Enric -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
