Re: [OE-core] [PATCH] cryptodev: Fix build errors with v4.11

2018-01-29 Thread Daniel Schultz
ah sorry, I checked rocko-next instead of next! Thanks for applying. Can 
you also backport this patch to rocko, please?


Daniel

On 01/28/2018 11:21 AM, Richard Purdie wrote:

On Fri, 2018-01-26 at 17:41 +0100, Daniel Schultz wrote:

Commit message from the included patch:
"Linux kernel has added -Werror=designated-init around 4.11
(c834f0e8a8b)
triggering build errors with gcc 5 and 6 (but not with gcc 4)"

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f0d69774afb27ffc62bf353465fba145e70cb85a

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
Acked-by: California Sullivan <california.l.sulli...@intel.com>
---
  .../cryptodev/cryptodev-module_1.9.bb  |  1 +
  .../0001-ioctl.c-Fix-build-with-linux-4.13.patch   | 49
++
  2 files changed, 50 insertions(+)
  create mode 100644 meta/recipes-kernel/cryptodev/files/0001-ioctl.c-
Fix-build-with-linux-4.13.patch

This merged 10 days ago:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1e5e38f1e7f09dd12a24e62142da747c760ce0c3

?

Cheers,

Richrd


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

- Entwicklung -
Tel.:   +49 6131 92 21 457
d.schu...@phytec.de
www.phytec.de

Sie finden uns auch auf: Facebook, LinkedIn, Xing, YouTube

PHYTEC Messtechnik GmbH | Robert-Koch-Str. 39 | 55129 Mainz, Germany
Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber |
Handelsregister Mainz HRB 4656 | Finanzamt Mainz-Mitte | St.Nr. 266500608,
DE 149059855
This E-Mail may contain confidential or privileged information. If you are
not the intended recipient (or have received this E-Mail in error) please
notify the sender immediately and destroy this E-Mail. Any unauthorized
copying, disclosure or distribution of the material in this E-Mail is
strictly forbidden.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] cryptodev: Fix build errors with v4.11

2018-01-26 Thread Daniel Schultz
Commit message from the included patch:
"Linux kernel has added -Werror=designated-init around 4.11 (c834f0e8a8b)
triggering build errors with gcc 5 and 6 (but not with gcc 4)"

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f0d69774afb27ffc62bf353465fba145e70cb85a

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
Acked-by: California Sullivan <california.l.sulli...@intel.com>
---
 .../cryptodev/cryptodev-module_1.9.bb  |  1 +
 .../0001-ioctl.c-Fix-build-with-linux-4.13.patch   | 49 ++
 2 files changed, 50 insertions(+)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
index 552eb6a..ed6d0ec 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
@@ -9,6 +9,7 @@ DEPENDS += "cryptodev-linux"
 
 SRC_URI += " \
 file://0001-Disable-installing-header-file-provided-by-another-p.patch \
+file://0001-ioctl.c-Fix-build-with-linux-4.13.patch \
 "
 
 EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
new file mode 100644
index 000..a41efac
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
@@ -0,0 +1,49 @@
+From f0d69774afb27ffc62bf353465fba145e70cb85a Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Mon, 4 Sep 2017 11:05:08 +0200
+Subject: [PATCH] ioctl.c: Fix build with linux 4.13
+
+git/ioctl.c:1127:3: error: positional initialization of field in 'struct' 
declared with 'designated_init' attribute [-Werror=designated-init]
+   {0, },
+^
+note: (near initialization for 'verbosity_ctl_dir[1]')
+git/ioctl.c:1136:3: error: positional initialization of field in 'struct' 
declared with 'designated_init' attribute [-Werror=designated-init]
+   {0, },
+^
+
+Linux kernel has added -Werror=designated-init around 4.11 (c834f0e8a8b)
+triggering build errors with gcc 5 and 6 (but not with gcc 4)
+
+Upstream-Status: Backport
+
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Signed-off-by: Cristian Stoica <cristian.sto...@nxp.com>
+---
+ ioctl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/ioctl.c b/ioctl.c
+index 0385203..8d4a162 100644
+--- a/ioctl.c
 b/ioctl.c
+@@ -1124,7 +1124,7 @@ static struct ctl_table verbosity_ctl_dir[] = {
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+-  {0, },
++  {},
+ };
+ 
+ static struct ctl_table verbosity_ctl_root[] = {
+@@ -1133,7 +1133,7 @@ static struct ctl_table verbosity_ctl_root[] = {
+   .mode   = 0555,
+   .child  = verbosity_ctl_dir,
+   },
+-  {0, },
++  {},
+ };
+ static struct ctl_table_header *verbosity_sysctl_header;
+ static int __init init_cryptodev(void)
+-- 
+2.7.4
+
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [RFC] cryptodev: Fix build errors with v4.11

2018-01-05 Thread Daniel Schultz

Cryptodev only breaks with 4.13 and 4.14.
4.12 builds successfully with and without this patch.

Daniel

On 01/05/2018 04:59 PM, Daniel Schultz wrote:

Hi,

On 01/05/2018 04:25 PM, Richard Purdie wrote:

On Fri, 2018-01-05 at 15:37 +0100, Daniel Schultz wrote:

Commit message from the included patch:
"Linux kernel has added -Werror=designated-init around 4.11
(c834f0e8a8b)
triggering build errors with gcc 5 and 6 (but not with gcc 4)"

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f0d69774afb27ffc62bf353465fba145e70cb85a

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>

I'm a little puzzled. Which release is this against? We're using
kernels newer than 4.11 so why aren't things breaking?

I use rocko and a v4.14 kernel.

Your right. The kernel patch was accepted in march.
I will build again with v4.12 and 13.



--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

- Entwicklung -
Tel.:   +49 6131 92 21 457
d.schu...@phytec.de
www.phytec.de

Sie finden uns auch auf: Facebook, LinkedIn, Xing, YouTube

PHYTEC Messtechnik GmbH | Robert-Koch-Str. 39 | 55129 Mainz, Germany
Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber |
Handelsregister Mainz HRB 4656 | Finanzamt Mainz-Mitte | St.Nr. 266500608,
DE 149059855
This E-Mail may contain confidential or privileged information. If you are
not the intended recipient (or have received this E-Mail in error) please
notify the sender immediately and destroy this E-Mail. Any unauthorized
copying, disclosure or distribution of the material in this E-Mail is
strictly forbidden.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [RFC] cryptodev: Fix build errors with v4.11

2018-01-05 Thread Daniel Schultz

Hi,

On 01/05/2018 04:25 PM, Richard Purdie wrote:

On Fri, 2018-01-05 at 15:37 +0100, Daniel Schultz wrote:

Commit message from the included patch:
"Linux kernel has added -Werror=designated-init around 4.11
(c834f0e8a8b)
triggering build errors with gcc 5 and 6 (but not with gcc 4)"

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f0d69774afb27ffc62bf353465fba145e70cb85a

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>

I'm a little puzzled. Which release is this against? We're using
kernels newer than 4.11 so why aren't things breaking?

I use rocko and a v4.14 kernel.

Your right. The kernel patch was accepted in march.
I will build again with v4.12 and 13.

--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [RFC] cryptodev: Fix build errors with v4.11

2018-01-05 Thread Daniel Schultz
Commit message from the included patch:
"Linux kernel has added -Werror=designated-init around 4.11 (c834f0e8a8b)
triggering build errors with gcc 5 and 6 (but not with gcc 4)"

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f0d69774afb27ffc62bf353465fba145e70cb85a

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 .../cryptodev/cryptodev-module_1.9.bb  |  1 +
 .../0001-ioctl.c-Fix-build-with-linux-4.13.patch   | 49 ++
 2 files changed, 50 insertions(+)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
index 552eb6a..ed6d0ec 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
@@ -9,6 +9,7 @@ DEPENDS += "cryptodev-linux"
 
 SRC_URI += " \
 file://0001-Disable-installing-header-file-provided-by-another-p.patch \
+file://0001-ioctl.c-Fix-build-with-linux-4.13.patch \
 "
 
 EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
new file mode 100644
index 000..a41efac
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
@@ -0,0 +1,49 @@
+From f0d69774afb27ffc62bf353465fba145e70cb85a Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Mon, 4 Sep 2017 11:05:08 +0200
+Subject: [PATCH] ioctl.c: Fix build with linux 4.13
+
+git/ioctl.c:1127:3: error: positional initialization of field in 'struct' 
declared with 'designated_init' attribute [-Werror=designated-init]
+   {0, },
+^
+note: (near initialization for 'verbosity_ctl_dir[1]')
+git/ioctl.c:1136:3: error: positional initialization of field in 'struct' 
declared with 'designated_init' attribute [-Werror=designated-init]
+   {0, },
+^
+
+Linux kernel has added -Werror=designated-init around 4.11 (c834f0e8a8b)
+triggering build errors with gcc 5 and 6 (but not with gcc 4)
+
+Upstream-Status: Backport
+
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Signed-off-by: Cristian Stoica <cristian.sto...@nxp.com>
+---
+ ioctl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/ioctl.c b/ioctl.c
+index 0385203..8d4a162 100644
+--- a/ioctl.c
 b/ioctl.c
+@@ -1124,7 +1124,7 @@ static struct ctl_table verbosity_ctl_dir[] = {
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+-  {0, },
++  {},
+ };
+ 
+ static struct ctl_table verbosity_ctl_root[] = {
+@@ -1133,7 +1133,7 @@ static struct ctl_table verbosity_ctl_root[] = {
+   .mode   = 0555,
+   .child  = verbosity_ctl_dir,
+   },
+-  {0, },
++  {},
+ };
+ static struct ctl_table_header *verbosity_sysctl_header;
+ static int __init init_cryptodev(void)
+-- 
+2.7.4
+
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH morty] e2fsprogs: Fix wrong error code after optimization

2017-04-05 Thread Daniel Schultz
fsck.ext will return an error code of 1 if a file systems was checked
and successfully repaired. Even when an optimization was performed it
will return this error code.

This patch will change the error code to 0 if only optimizations had
changed the file systems.

The reason for this patch is a question I asked at the ext4 ML:
http://www.spinics.net/lists/linux-ext4/msg55700.html

Backport from git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
Based on commit bf9f3b6d5b10d19218b4ed904c12b22e36ec57dd

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 ...-with-exit-status-0-if-no-errors-were-fix.patch | 285 +
 meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb  |   1 +
 2 files changed, 286 insertions(+)
 create mode 100644 
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch

diff --git 
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
new file mode 100644
index 000..44f3888
--- /dev/null
+++ 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
@@ -0,0 +1,285 @@
+From b9bb77a0dd712f06b262a12766972b99cd801269 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <ty...@mit.edu>
+Date: Thu, 16 Feb 2017 22:02:35 -0500
+Subject: [PATCH] e2fsck: exit with exit status 0 if no errors were fixed
+
+Previously, e2fsck would exit with a status code of 1 even though the
+only changes that it made to the file system were various
+optimziations and not fixing file system corruption.  Since the man
+page states that an exit status of 1 means "file system errors
+corrupted", fix e2fsck to return an exit status of 0.
+
+Upstream-Status: Backport
+
+Signed-off-by: Theodore Ts'o <ty...@mit.edu>
+Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
+
+Conflicts:
+   e2fsck/e2fsck.conf.5.in
+---
+ e2fsck/e2fsck.conf.5.in | 34 +
+ e2fsck/journal.c|  1 +
+ e2fsck/problem.c|  8 ---
+ e2fsck/problemP.h   |  1 +
+ e2fsck/unix.c   | 20 +
+ tests/f_collapse_extent_tree/expect.1   |  2 +-
+ tests/f_compress_extent_tree_level/expect.1 |  2 +-
+ tests/f_convert_bmap/expect.1   |  2 +-
+ tests/f_convert_bmap_and_extent/expect.1|  2 +-
+ tests/f_extent_htree/expect.1   |  2 +-
+ tests/f_jnl_errno/expect.1  |  2 +-
+ tests/f_journal/expect.1|  2 +-
+ tests/f_orphan/expect.1 |  2 +-
+ tests/f_orphan_extents_inode/expect.1   |  2 +-
+ tests/f_rehash_dir/expect.1 |  2 +-
+ tests/f_unsorted_EAs/expect.1   |  2 +-
+ 16 files changed, 68 insertions(+), 18 deletions(-)
+
+diff --git a/e2fsck/e2fsck.conf.5.in b/e2fsck/e2fsck.conf.5.in
+index 1f80a04..6a205ce 100644
+--- a/e2fsck/e2fsck.conf.5.in
 b/e2fsck/e2fsck.conf.5.in
+@@ -326,6 +326,40 @@ defaults to true.
+ This relation controls whether or not the scratch file directory is used
+ instead of an in-memory data structure when tracking inode counts.  It
+ defaults to true.
++.TP
++.I not_a_fix
++This boolean option, it set to true, marks the problem as
++one where if the user gives permission to make the requested change,
++it does not mean that the file system had a problem which has since
++been fixed.  This is used for requests to optimize the file system's
++data structure, such as pruning an extent tree.
++@TDB_MAN_COMMENT@.SH THE [scratch_files] STANZA
++@TDB_MAN_COMMENT@The following relations are defined in the
++@TDB_MAN_COMMENT@.I [scratch_files]
++@TDB_MAN_COMMENT@stanza.
++@TDB_MAN_COMMENT@.TP
++@TDB_MAN_COMMENT@.I directory
++@TDB_MAN_COMMENT@If the directory named by this relation exists and is
++@TDB_MAN_COMMENT@writeable, then e2fsck will attempt to use this
++@TDB_MAN_COMMENT@directory to store scratch files instead of using
++@TDB_MAN_COMMENT@in-memory data structures.
++@TDB_MAN_COMMENT@.TP
++@TDB_MAN_COMMENT@.I numdirs_threshold
++@TDB_MAN_COMMENT@If this relation is set, then in-memory data structures
++@TDB_MAN_COMMENT@be used if the number of directories in the filesystem
++@TDB_MAN_COMMENT@are fewer than amount specified.
++@TDB_MAN_COMMENT@.TP
++@TDB_MAN_COMMENT@.I dirinfo
++@TDB_MAN_COMMENT@This relation controls whether or not the scratch file
++@TDB_MAN_COMMENT@directory is used instead of an in-memory data
++@TDB_MAN_COMMENT@structure for directory information.  It defaults to
++@TDB_MAN_COMMENT@true.
++@TDB_MAN_COMMENT@.TP
++@TDB_MAN_COMMENT@.I icount
++@TDB_MAN_COMMENT@This relation controls whether or not the scratch file
++@TDB_MAN_COMMENT@directory is used instead of an in-memory data
++@TDB_MAN_COMMENT@structure when t

[OE-core] [PATCH morty v3] wic: partition: Run fsck on EXT file systems

2017-04-03 Thread Daniel Schultz
Mkfs may create EXT file systems which can only be optimized by fsck
and not by itself, e.g. directory optimization (in Pass 3A).

To prevent those optimizations during runtime, it will be performed after
the creation of an EXT file system.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
Changes:
v3: Added 'test' to avoid build failures with missing e2fsprogs backport

 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..ec3aa66 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -pvfD %s || [ $? -le 3 ]" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH morty v2] wic: partition: Run fsck on EXT file systems

2017-04-03 Thread Daniel Schultz

Hi,

Am 31.03.2017 um 19:14 schrieb Khem Raj:



On 3/31/17 5:51 AM, Daniel Schultz wrote:

Mkfs may create EXT file systems which can only be optimized by fsck
and not by itself, e.g. directory optimization (in Pass 3A).

To prevent those optimizations during runtime, it will be performed after
the creation of an EXT file system.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..152eb7b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)

+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+


is this required on master too ? if yes I would suggest to propose it
for master and then do a backport.



Yes, it's already on master. If I would backport it, I also have to 
backport a patch for e2fsprogs.

Since the new release is very close I would prefer this patch.


 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """





--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH morty v2] wic: partition: Run fsck on EXT file systems

2017-03-31 Thread Daniel Schultz
Mkfs may create EXT file systems which can only be optimized by fsck
and not by itself, e.g. directory optimization (in Pass 3A).

To prevent those optimizations during runtime, it will be performed after
the creation of an EXT file system.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..152eb7b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH morty] wic: partition: Add fsck to avoid corrupt EXT file systems

2017-03-30 Thread Daniel Schultz
This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..152eb7b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] wic: partition: Update fsck parameters

2017-03-30 Thread Daniel Schultz
These parameters are copied from the ext image class.

-D will let fsck perform further directory optimizations
-v might be helpful for debugging purpose

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/partition.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 8e32afc..93b9b16 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -286,7 +286,7 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
-mkfs_cmd = "fsck.%s -fy %s" % (self.fstype, rootfs)
+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-27 Thread Daniel Schultz

Hi Enrico,

Am 24.03.2017 um 15:01 schrieb Enrico Joerns:

Hi Daniel,

On 03/24/2017 02:34 PM, Daniel Schultz wrote:

Hi Enrico,

I have sent fixes for the same problem on Monday.
These include a fix of the wrong return code after optimizations (now it
returns 0) and an fsck execution after the creation of EXT partitions.

The patch which is identical to yours wasn't applied so far, the other
ones were.


ouh, we should have checked that before, but we did not assume that
someone would have posted a fix for this relatively old behavior during
the last days. Reality disabused us... Anyway, good to see that we are
not the only one that stumbled across this issue ;)

But, there is another difference between our patches. We use `-pvfD`,
while you use `-fy` as an fsck.extN option.

I would expect `-p` to be sufficient for letting fsck perform minor
optimizations. If you use `-y` instead, fsck will fix also real issues.
This is not what it should do here, even if it will return 1 afterwards.
If the file system was created with errors I guess we should let the
image creation fail without further touching the ext4.

-D will let fsck perform further directory optimizations
-v might be helpful for debugging purpose


Yes, that's better. I will them also apply to the WIC tools.

Do you think the test expression is still needed?
My opinion is, that it will obfuscate the return code of fsck to either 
true or false. This could confuse other people. What do you think?


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] image_types: perform fsck on created ext image

2017-03-24 Thread Daniel Schultz

Hi Enrico,

I have sent fixes for the same problem on Monday.
These include a fix of the wrong return code after optimizations (now it 
returns 0) and an fsck execution after the creation of EXT partitions.


The patch which is identical to yours wasn't applied so far, the other 
ones were.


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

Am 24.03.2017 um 12:15 schrieb Enrico Jorns:

When performing a file system check, the image created with mkfs will
trigger Pass 3A ('Optimizing directories') which turns the file system
into state "changed" (EXT2_FLAG_CHANGED).

This will let fsck request a reboot by setting the return code flag "2".

The result of this is that each ext-image built with oe-core will
trigger a reboot during the first time an fsck is triggered.

A common case where this might occur is when fsck detects having
a future superblock write time. This always happens when booting a
newly created ext4 rootfs with a target that does not have a recent time
set.

This patch moves the initial fsck run that performs the optimization
from the target to the host system and thus prevents the target from
performing an avoidable reboot.

Signed-off-by: Enrico Jorns <e...@pengutronix.de>
Signed-off-by: Ulrich Ölmann <u...@pengutronix.de>
---
 meta/classes/image_types.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 1ce8334e3a..52d3af0cc1 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -66,6 +66,8 @@ oe_mkext234fs () {
# Create a sparse image block
dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024
mkfs.$fstype -F $extra_imagecmd 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
+   # Error codes 0-3 indicate successfull operation of fsck (no errors or 
errors corrected)
+   fsck.$fstype -pvfD 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype || [ $? -le 3 ]
 }

 IMAGE_CMD_ext2 = "oe_mkext234fs ext2 ${EXTRA_IMAGECMD}"



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 3/3] meta: images: Add fsck to avoid corrupt EXT file systems

2017-03-20 Thread Daniel Schultz

Am 20.03.2017 um 13:26 schrieb Burton, Ross:


On 20 March 2017 at 12:18, Daniel Schultz <d.schu...@phytec.de
<mailto:d.schu...@phytec.de>> wrote:

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.


Doesn't mkfs returns an exit code if it wasn't successful?


Yes, but it seems like mkfs can't handle everything.

"The htree (hash tree) indexes directory entries by hash to speed up
random directory accesses.  e2fsck can regenerate the indices, but the
rest of e2fsprogs cannot create or maintain them."
[http://www.spinics.net/lists/linux-ext4/msg55702.html]

Currently, our boards have to reboot, because fsck exits with an error 
code of 1 at the first boot.



Ross


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 3/3] meta: images: Add fsck to avoid corrupt EXT file systems

2017-03-20 Thread Daniel Schultz
This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 meta/classes/image_types.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index d2eb99d..66c643d 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -74,6 +74,7 @@ oe_mkext234fs () {
# Create a sparse image block
dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024
mkfs.$fstype -F $extra_imagecmd 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
+   fsck.$fstype -fy 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype
 }
 
 IMAGE_CMD_ext2 = "oe_mkext234fs ext2 ${EXTRA_IMAGECMD}"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/3] e2fsprogs: Fix wrong error code after optimization

2017-03-20 Thread Daniel Schultz
fsck.ext will return an error code of 1 if a file systems was checked
and successfully repaired. Even when an optimization was performed it
will return this error code.

This patch will change the error code to 0 if only optimizations had
changed the file systems.

The reason for this patch is a question I asked at the ext4 ML:
http://www.spinics.net/lists/linux-ext4/msg55700.html

Backport from git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
Based on commit bf9f3b6d5b10d19218b4ed904c12b22e36ec57dd

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 ...-with-exit-status-0-if-no-errors-were-fix.patch | 255 +
 .../recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb |   1 +
 2 files changed, 256 insertions(+)
 create mode 100644 
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch

diff --git 
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
new file mode 100644
index 000..1d17520
--- /dev/null
+++ 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
@@ -0,0 +1,255 @@
+From bf9f3b6d5b10d19218b4ed904c12b22e36ec57dd Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <ty...@mit.edu>
+Date: Thu, 16 Feb 2017 22:02:35 -0500
+Subject: [PATCH] e2fsck: exit with exit status 0 if no errors were fixed
+
+Previously, e2fsck would exit with a status code of 1 even though the
+only changes that it made to the file system were various
+optimziations and not fixing file system corruption.  Since the man
+page states that an exit status of 1 means "file system errors
+corrupted", fix e2fsck to return an exit status of 0.
+
+Upstream-Status: Backport
+
+Signed-off-by: Theodore Ts'o <ty...@mit.edu>
+Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
+---
+ e2fsck/e2fsck.conf.5.in |  7 +++
+ e2fsck/journal.c|  1 +
+ e2fsck/problem.c|  8 +---
+ e2fsck/problemP.h   |  1 +
+ e2fsck/unix.c   | 20 
+ tests/f_collapse_extent_tree/expect.1   |  2 +-
+ tests/f_compress_extent_tree_level/expect.1 |  2 +-
+ tests/f_convert_bmap/expect.1   |  2 +-
+ tests/f_convert_bmap_and_extent/expect.1|  2 +-
+ tests/f_extent_htree/expect.1   |  2 +-
+ tests/f_jnl_errno/expect.1  |  2 +-
+ tests/f_journal/expect.1|  2 +-
+ tests/f_orphan/expect.1 |  2 +-
+ tests/f_orphan_extents_inode/expect.1   |  2 +-
+ tests/f_rehash_dir/expect.1 |  2 +-
+ tests/f_unsorted_EAs/expect.1   |  2 +-
+ 16 files changed, 41 insertions(+), 18 deletions(-)
+
+diff --git a/e2fsck/e2fsck.conf.5.in b/e2fsck/e2fsck.conf.5.in
+index 1848bdb..0bfc76a 100644
+--- a/e2fsck/e2fsck.conf.5.in
 b/e2fsck/e2fsck.conf.5.in
+@@ -303,6 +303,13 @@ of 'should this problem be fixed?'.  The
+ option even overrides the
+ .B -y
+ option given on the command-line (just for the specific problem, of course).
++.TP
++.I not_a_fix
++This boolean option, it set to true, marks the problem as
++one where if the user gives permission to make the requested change,
++it does not mean that the file system had a problem which has since
++been fixed.  This is used for requests to optimize the file system's
++data structure, such as pruning an extent tree.
+ @TDB_MAN_COMMENT@.SH THE [scratch_files] STANZA
+ @TDB_MAN_COMMENT@The following relations are defined in the
+ @TDB_MAN_COMMENT@.I [scratch_files]
+diff --git a/e2fsck/journal.c b/e2fsck/journal.c
+index 46fe7b4..c4f58f1 100644
+--- a/e2fsck/journal.c
 b/e2fsck/journal.c
+@@ -572,6 +572,7 @@ static void clear_v2_journal_fields(journal_t *journal)
+   if (!fix_problem(ctx, PR_0_CLEAR_V2_JOURNAL, ))
+   return;
+ 
++  ctx->flags |= E2F_FLAG_PROBLEMS_FIXED;
+   memset(((char *) journal->j_superblock) + V1_SB_SIZE, 0,
+  ctx->fs->blocksize-V1_SB_SIZE);
+   mark_buffer_dirty(journal->j_sb_buffer);
+diff --git a/e2fsck/problem.c b/e2fsck/problem.c
+index 34a671e..4b25069 100644
+--- a/e2fsck/problem.c
 b/e2fsck/problem.c
+@@ -1276,12 +1276,12 @@ static struct e2fsck_problem problem_table[] = {
+   /* Inode extent tree could be shorter */
+   { PR_1E_CAN_COLLAPSE_EXTENT_TREE,
+ N_("@i %i @x tree (at level %b) could be shorter.  "),
+-PROMPT_FIX, PR_NO_OK | PR_PREEN_NO | PR_PREEN_OK },
++PROMPT_FIX, PR_NO_OK | PR_PREEN_NO | PR_PREEN_OK | PR_NOT_A_FIX },
+ 
+   /* Inode extent tree could be narrower */
+   { PR_1E_CAN_NARROW_EXTENT_TREE,
+ N_("@i %i @x tree (at level %b) could be narrower.  "),
+-PROMPT_FIX, P

[OE-core] [PATCH 2/3] wic: partition.py: Add fsck to avoid corrupt EXT file systems

2017-03-20 Thread Daniel Schultz
This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 6ef8d7f..8e32afc 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -286,6 +286,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -fy %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Create more than one image with WIC

2017-03-13 Thread Daniel Schultz



Am 08.03.2017 um 14:43 schrieb Ed Bartosh:

On Wed, Mar 08, 2017 at 02:41:10PM +0100, Gary Thomas wrote:

On 2017-03-08 11:57, Ed Bartosh wrote:

On Wed, Mar 08, 2017 at 10:44:21AM +0100, Daniel Schultz wrote:

Hi,

I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks)
and added them to the local.conf.

When I build the image only the first wks in WKS_FILES will be used
by WIC and the second will be ignored. Is it possible to build two
images in one build?



I don't think it's possible to build more than one image for the same
type. wic is not an exception here.


Includes of the wks files in local.conf:
WKS_FILES_ti33x = "am335x-sdimage.wks am335x-emmc.wks "


WKS_FILES variable is to provide possible wks files to use. First one found will
be used to produce an image.


Would it work to add/define this variable in the corresponding *image*.bb recipe
rather than local.conf?


Yes, it would if image recipe is unique, i.e. images of the same type
can be produced for different recipes.

But isn't wic different to other images like e.g. ext? I agree that 
there are other images that need only build once, but wic images can 
contain these and therefore act as a wrapper.


Do I have misunderstood the design of wic?

I mean MMC and EMMC are very similar, but different in the bootloader 
and it would be a overhead to create an extra image for all EMMC images.


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz


WKS_FILES makes sense to set only if there are multiple wks files that
can be used to produce an image. The most obvious use case is using
multiple layers with different wks files in each and specifying all of
them in WKS_FILES.

If this is not the case then setting WKS_FILE is enough.

--
Regards,
Ed




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Create more than one image with WIC

2017-03-08 Thread Daniel Schultz

Hi,

I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks) and 
added them to the local.conf.


When I build the image only the first wks in WKS_FILES will be used by 
WIC and the second will be ignored. Is it possible to build two images 
in one build?


Includes of the wks files in local.conf:
WKS_FILES_ti33x = "am335x-sdimage.wks am335x-emmc.wks "

--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] wic: filemap: Fixed spared_copy skip

2017-03-07 Thread Daniel Schultz
This patches removes the empty space in front of the copied file which
was skipped. Without this reduction it's not possible to place a
partition with rawcopy and skip parameter on a desired alignment.

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/filemap.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
index f3240ba..162603e 100644
--- a/scripts/lib/wic/filemap.py
+++ b/scripts/lib/wic/filemap.py
@@ -543,9 +543,9 @@ def sparse_copy(src_fname, dst_fname, offset=0, skip=0):
 end = (last + 1) * fmap.block_size
 
 if start < skip < end:
-start = skip
-
-fmap._f_image.seek(start, os.SEEK_SET)
+fmap._f_image.seek(skip, os.SEEK_SET)
+else:
+fmap._f_image.seek(start, os.SEEK_SET)
 dst_file.seek(offset + start, os.SEEK_SET)
 
 chunk_size = 1024 * 1024
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/2] wic: plugins: rawcopy: Fixed wrong variable type

2017-03-07 Thread Daniel Schultz
Without the int() function this variable will be a string. This will led
to a error in Filemap on line 545 due wrong types.

> [...]
>   File
> ".../poky/scripts/lib/wic/filemap.py", line 545, in sparse_copy
> if start < skip < end:
> TypeError: unorderable types: int() < str()

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 scripts/lib/wic/plugins/source/rawcopy.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/source/rawcopy.py 
b/scripts/lib/wic/plugins/source/rawcopy.py
index 5bd22fd..618dd44 100644
--- a/scripts/lib/wic/plugins/source/rawcopy.py
+++ b/scripts/lib/wic/plugins/source/rawcopy.py
@@ -71,7 +71,7 @@ class RawCopyPlugin(SourcePlugin):
 dst = os.path.join(cr_workdir, "%s.%s" % (source_params['file'], 
part.lineno))
 
 if 'skip' in source_params:
-sparse_copy(src, dst, skip=source_params['skip'])
+sparse_copy(src, dst, skip=int(source_params['skip']))
 else:
 sparse_copy(src, dst)
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v3] cryptodev: Fix changed mm interface in Kernel 4.9

2017-01-26 Thread Daniel Schultz
The memory management interface has changed in Kernel 4.9.

This patch adds a patch which fixes the paramter of the function call.

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f126e4837e6334d0464540995df7426fedf6b175

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 meta/recipes-kernel/cryptodev/cryptodev.inc|  3 +-
 ...st-to-another-change-in-the-user-page-API.patch | 40 ++
 2 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index 160ab30..6241238 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 SRC_URI = 
"http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz \
file://06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch \
-   file://cb186f682679383e8b5806240927903730ce85d9.patch"
+   file://cb186f682679383e8b5806240927903730ce85d9.patch \
+   file://0001-Adjust-to-another-change-in-the-user-page-API.patch"
 
 SRC_URI[md5sum] = "02644cc4cd02301e0b503a332eb2f0b5"
 SRC_URI[sha256sum] = 
"67fabde9fb67b286a96c4f45b594b0eccd0f761b495705c18f2ae9461b831376"
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
new file mode 100644
index 000..fb75278
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
@@ -0,0 +1,40 @@
+From f126e4837e6334d0464540995df7426fedf6b175 Mon Sep 17 00:00:00 2001
+From: Michael Weiser <michael.wei...@gmx.de>
+Date: Fri, 11 Nov 2016 18:09:32 +0100
+Subject: [PATCH] Adjust to another change in the user page API
+
+4.9.0 will replace the write and force flags of get_user_pages_remote()
+with a gup_flags parameter[1]. Distinguish the two APIs based on kernel
+version we're compiling for.
+
+[1] 
https://github.com/torvalds/linux/commit/9beae1ea89305a9667ceaab6d0bf46a045ad71e7
+
+Upstream-Status: Backport
+
+Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
+---
+ zc.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/zc.c b/zc.c
+index a97b49f..e766ee3 100644
+--- a/zc.c
 b/zc.c
+@@ -65,7 +65,13 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int 
write,
+   ret = get_user_pages(
+ #endif
+   task, mm,
+-  (unsigned long)addr, pgcount, write, 0, pg, NULL);
++  (unsigned long)addr, pgcount,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0))
++  write ? FOLL_WRITE : 0,
++#else
++  write, 0,
++#endif
++  pg, NULL);
+   up_read(>mmap_sem);
+   if (ret != pgcount)
+   return -EINVAL;
+-- 
+1.9.1
+
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] cryptodev: Fix changed mm interface in Kernel 4.9

2017-01-26 Thread Daniel Schultz
The memory management interface has changed in Kernel 4.9.

This patch adds a patch which fixes the paramter of the function call.

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f126e4837e6334d0464540995df7426fedf6b175

Upstream-Status: Backport

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 meta/recipes-kernel/cryptodev/cryptodev.inc|  3 +-
 ...st-to-another-change-in-the-user-page-API.patch | 38 ++
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index 160ab30..6241238 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 SRC_URI = 
"http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz \
file://06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch \
-   file://cb186f682679383e8b5806240927903730ce85d9.patch"
+   file://cb186f682679383e8b5806240927903730ce85d9.patch \
+   file://0001-Adjust-to-another-change-in-the-user-page-API.patch"
 
 SRC_URI[md5sum] = "02644cc4cd02301e0b503a332eb2f0b5"
 SRC_URI[sha256sum] = 
"67fabde9fb67b286a96c4f45b594b0eccd0f761b495705c18f2ae9461b831376"
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
new file mode 100644
index 000..c001b6f
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
@@ -0,0 +1,38 @@
+From f126e4837e6334d0464540995df7426fedf6b175 Mon Sep 17 00:00:00 2001
+From: Michael Weiser <michael.wei...@gmx.de>
+Date: Fri, 11 Nov 2016 18:09:32 +0100
+Subject: [PATCH] Adjust to another change in the user page API
+
+4.9.0 will replace the write and force flags of get_user_pages_remote()
+with a gup_flags parameter[1]. Distinguish the two APIs based on kernel
+version we're compiling for.
+
+[1] 
https://github.com/torvalds/linux/commit/9beae1ea89305a9667ceaab6d0bf46a045ad71e7
+
+Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
+---
+ zc.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/zc.c b/zc.c
+index a97b49f..e766ee3 100644
+--- a/zc.c
 b/zc.c
+@@ -65,7 +65,13 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int 
write,
+   ret = get_user_pages(
+ #endif
+   task, mm,
+-  (unsigned long)addr, pgcount, write, 0, pg, NULL);
++  (unsigned long)addr, pgcount,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0))
++  write ? FOLL_WRITE : 0,
++#else
++  write, 0,
++#endif
++  pg, NULL);
+   up_read(>mmap_sem);
+   if (ret != pgcount)
+   return -EINVAL;
+-- 
+1.9.1
+
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for cryptodev: Fix changed mm interface in Kernel 4.9

2017-01-25 Thread Daniel Schultz

I have backported this patch and I won't add the signed-off by myself.
How should I proceed?

Am 25.01.2017 um 16:23 schrieb Patchwork:

== Series Details ==

Series: cryptodev: Fix changed mm interface in Kernel 4.9
Revision: 1
URL   : https://patchwork.openembedded.org/series/4970/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence]
  Suggested fixSign off the added patch file 
(meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch)

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence]
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
 (possible values: Pending, Submitted, Accepted, Backport, Denied, Inappropriate)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe



--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] cryptodev: Fix changed mm interface in Kernel 4.9

2017-01-25 Thread Daniel Schultz
The memory management interface has changed in Kernel 4.9.

This patch adds a patch which fixes the paramter of the function call.

Backport from https://github.com/cryptodev-linux/cryptodev-linux
Based on commit f126e4837e6334d0464540995df7426fedf6b175

Signed-off-by: Daniel Schultz <d.schu...@phytec.de>
---
 meta/recipes-kernel/cryptodev/cryptodev.inc|  3 +-
 ...st-to-another-change-in-the-user-page-API.patch | 36 ++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index 160ab30..6241238 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 SRC_URI = 
"http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz \
file://06d6b560c6e45dc317dae47c74706fa43f4a31d8.patch \
-   file://cb186f682679383e8b5806240927903730ce85d9.patch"
+   file://cb186f682679383e8b5806240927903730ce85d9.patch \
+   file://0001-Adjust-to-another-change-in-the-user-page-API.patch"
 
 SRC_URI[md5sum] = "02644cc4cd02301e0b503a332eb2f0b5"
 SRC_URI[sha256sum] = 
"67fabde9fb67b286a96c4f45b594b0eccd0f761b495705c18f2ae9461b831376"
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
new file mode 100644
index 000..8a544ff
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Adjust-to-another-change-in-the-user-page-API.patch
@@ -0,0 +1,36 @@
+From f126e4837e6334d0464540995df7426fedf6b175 Mon Sep 17 00:00:00 2001
+From: Michael Weiser <michael.wei...@gmx.de>
+Date: Fri, 11 Nov 2016 18:09:32 +0100
+Subject: [PATCH] Adjust to another change in the user page API
+
+4.9.0 will replace the write and force flags of get_user_pages_remote()
+with a gup_flags parameter[1]. Distinguish the two APIs based on kernel
+version we're compiling for.
+
+[1] 
https://github.com/torvalds/linux/commit/9beae1ea89305a9667ceaab6d0bf46a045ad71e7
+---
+ zc.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/zc.c b/zc.c
+index a97b49f..e766ee3 100644
+--- a/zc.c
 b/zc.c
+@@ -65,7 +65,13 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int 
write,
+   ret = get_user_pages(
+ #endif
+   task, mm,
+-  (unsigned long)addr, pgcount, write, 0, pg, NULL);
++  (unsigned long)addr, pgcount,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0))
++  write ? FOLL_WRITE : 0,
++#else
++  write, 0,
++#endif
++  pg, NULL);
+   up_read(>mmap_sem);
+   if (ret != pgcount)
+   return -EINVAL;
+-- 
+1.9.1
+
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core