Ported from DragonFlyBSD, but this target had originally existed in
Linux kernel. See below for details.
https://www.kernel.org/doc/Documentation/device-mapper/delay.txt
Due to "tick" in hz(9) not working (which results in dmdlthread spinning
forever in _submit_queue() without dp extracted from delayed list
and queued into submit list), this hasn't been hooked to dm.kmod yet.
taken-from: DragonFlyBSD
Ported from DragonFlyBSD, but this target had originally existed in
Linux kernel. See below for details.
https://www.kernel.org/doc/Documentation/device-mapper/dm-flakey.txt
Due to two technical issues, this hasn't been hooked to dm.kmod yet.
1) "tick" in hz(9) not working.
2) Unable to use ->b_private in nestiobuf callback when it's already
used for mbp (see HAS_BUF_PRIV2).
taken-from: DragonFlyBSD
Since ->info() (counter part of ->table() in the original dm design
in Linux kernel in .status where both INFO and TABLE are optional)
is an optional handler, make ->table() optional as well. Some
targets don't have anything to do in ->table() just as in ->info().
taken-from: DragonFlyBSD
As mentioned in "dm: Don't try to implement "status" as subset of "table"",
dm-stripe in NetBSD doesn't have correct "status" output format.
Implement ->info() to sync with Linux kernel.
Note that num_error for stripe device isn't implemented yet.
taken-from: DragonFlyBSD
Retrieving device dependencies doesn't need to be target specific.
The reason it currently needs ->deps() is because dm core doesn't
have data structure that allows table to walk through target's
underlying devices. Add struct dm_mapping to be able to do this,
and remove ->deps()'s from targets which basically do the same thing.
=====(A) before this commit
table
| [dm core]
-------------------------------------------------------
| pdev pdev pdev [dm targets]
v ^ ^ ^
target----/---------/---------/
(void*)
=====(B) this commit
table---->mapping-->mapping-->mapping-->...
| | | |
| v v v [dm core]
-------------------------------------------------------
| pdev pdev pdev [dm targets]
v ^ ^ ^
target----/---------/---------/
(void*)
taken-from: DragonFlyBSD
and make a caller assume secsize 0 if ->secsize not present.
This allows a dummy function to be removed which was added in
"dm: Add dummy target ->sync()/->secsize() to prevent panic on modload(8)".
Since now that dm targets in NetBSD have ->info() for "status",
->status() should be renamed to ->table() for "table",
given how dm target status was originally designed in Linux kernel.
taken-from: DragonFlyBSD
Having assertions here causes panic if target is missing anything
as shown in "dm: Add dummy target ->sync()/->secsize() to prevent panic on modload(8)".
Instead just return EINVAL if a handler(s) isn't implemented.
taken-from: DragonFlyBSD
For aggregates of multiple disks we use the largest sector size from
all disks. For standard power-of-2 sizes this is the same as the least
common multiple. We still require proper alignment of the targets in
the mapping table.
ok by haad@
pointer to dm_target_t because that is the only part of dm which know real
block device. disk_ioctl_switch parses whole device table and for every
entry it calls particular sync routine which propagates DIOCCACHESYNC
to real disk.
While I was here implement some KNF fixes and remove unneeded symbols from
dm.h.
Problem reported on port-xen@ by Hugo Silva.
allocated with length DM_MAX_PARAMS_SIZE and released with strlen + 1 size.
Disable KM_NOSLEEP allocation because we do not need them here there is
nothing critical in ioctl part of dm driver.
Bug reported by jak@.
linear can be loaded as module. Module is not loaded when there is target
with similar name already. Zero and error targets aresimple examples how
can be all future targets written to support dynamic loading. Target can't
be unloaded until there is at least one user.
the base NetBSD system. It uses Linux LVM2 tools and our BSD licensed
device-mapper driver.
The device-mapper driver can be used to create virtual block devices which
maps virtual blocks to real with target mapping called target. Currently
these targets are available a linear, zero, error and a snapshot (this is
work in progress and doesn't work yet).
The lvm2tools adds lvm and dmsetup binary to based system, where the lvm
tool is used to manage and administer whole LVM and the dmestup is used to
communicate iwith device-mapper kernel driver. With these tools also
a libdevmapper library is instaled to the base system.
Building of tools and driver is currently disable and can be enabled with
MKLVM=yes in mk.conf. I will add sets lists and rc.d script soon.
Oked by agc@ and cube@.
thorpej