* [PATCH 0/4]Add FUSE: File system in Userspace
@ 2013-05-30 9:01 Hongxu Jia
2013-05-30 9:01 ` [PATCH 1/4] fuse: import recipe from meta-oe Hongxu Jia
` (4 more replies)
0 siblings, 5 replies; 16+ messages in thread
From: Hongxu Jia @ 2013-05-30 9:01 UTC (permalink / raw)
To: openembedded-core
Add fuse to oe-core and let target system could support
`ntfs' and `exfat' filesystems.
Test Case
*Steps
1, preparation
1 target: e-menlow
2 usb sticks: one for boot and install, another for filesystem test.
2, config
conf/local.conf:
247 MACHINE ?= "emenlow-noemgd"
247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils"
conf/bblayers.conf:
8 BBLAYERS ?= " \
9 /home/jiahongxu/yocto/poky/meta \
10 /home/jiahongxu/yocto/poky/meta-yocto \
11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \
12 /home/jiahongxu/yocto/poky/meta-intel \
13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \
3, build image
bitbake core-image-sato
4, load image to emenlow
Test Case TC-2927: boot and install from usb
5, open a terminal/ssh of e-menlow
Test Case TC-2955: remote access by ssh
6, make exfat filesystem on the testing usb storage
1) plug usb stick into e-menlow
2) execute `mkfs.exfat /dev/sdc1'
7, test usb stick with exfat filesystem is accessible
Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files
8, make ntfs filesystem on the testing usb storage
1) plug usb stick into e-menlow, if mounted, invoke `umount /dev/sdc1' first.
2) execute `mkfs.ntfs -f /dev/sdc1'
9, test usb stick with ntfs filesystem is accessible
Test Case TC-2947: usb mount
Test Case TC-2948: usb read files
Test Case TC-2949: usb umount
Test Case TC-2950: usb write files
*Expected Results:
1, build image success
2, make exfat filesystem success
root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1
mkexfatfs 1.0.1
Creating... done.
Flushing... done.
File system created successfully.
3, make ntfs filesystem success
root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1
Cluster size has been automatically set to 4096 bytes.
Creating NTFS volume structures.
mkntfs completed successfully. Have a nice day.
4, While the usb's filesystem type is exfat or ntfs, system can mount
plugged usb automatically, read files from usb, write files to usb and
unmout usb automatically.
[YOCTO #4178]
The following changes since commit 350c36fcd97e8ef223b91e548d39c346c1c4cb29:
bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib hongxu/support-fuse
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse
Hongxu Jia (4):
fuse: import recipe from meta-oe
ntfs-3g-ntfsprogs:import and update recipe from meta-oe
fuse-exfat: add version 1.0.1
exfat-utils: add version 1.0.1
meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++
meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++
meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++
.../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++
meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++
.../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++
6 files changed, 206 insertions(+)
create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb
create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb
create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch
create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch
create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb
create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
--
1.7.10.4
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH 1/4] fuse: import recipe from meta-oe 2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia @ 2013-05-30 9:01 ` Hongxu Jia 2013-05-30 9:01 ` [PATCH 2/4] ntfs-3g-ntfsprogs:import and update " Hongxu Jia ` (3 subsequent siblings) 4 siblings, 0 replies; 16+ messages in thread From: Hongxu Jia @ 2013-05-30 9:01 UTC (permalink / raw) To: openembedded-core add version 2.9.2 This recipes is required by ntfs-3g-ntfsprogs and exfat. [YOCTO #4178] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> --- meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ 3 files changed, 118 insertions(+) create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb diff --git a/meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch b/meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch new file mode 100644 index 0000000..180f544 --- /dev/null +++ b/meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch @@ -0,0 +1,20 @@ +Upstream-Status: Submitted + +Signed-off-by: Riku Voipio <riku.voipio@linaro.org> + +--- a/include/fuse_kernel.h ++++ b/include/fuse_kernel.h +@@ -88,12 +88,7 @@ + #ifndef _LINUX_FUSE_H + #define _LINUX_FUSE_H + +-#include <sys/types.h> +-#define __u64 uint64_t +-#define __s64 int64_t +-#define __u32 uint32_t +-#define __s32 int32_t +-#define __u16 uint16_t ++#include <linux/types.h> + + /* + * Version negotiation: diff --git a/meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch b/meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch new file mode 100644 index 0000000..8ee97df --- /dev/null +++ b/meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch @@ -0,0 +1,60 @@ +Index: fuse-2.8.6/lib/fuse.c +=================================================================== +--- fuse-2.8.6.orig/lib/fuse.c 2011-09-13 00:23:14.000000000 -0700 ++++ fuse-2.8.6/lib/fuse.c 2011-10-19 09:20:27.537099939 -0700 +@@ -3947,11 +3947,11 @@ + 11); + } + +-FUSE_SYMVER(".symver fuse_exited,__fuse_exited@"); +-FUSE_SYMVER(".symver fuse_process_cmd,__fuse_process_cmd@"); +-FUSE_SYMVER(".symver fuse_read_cmd,__fuse_read_cmd@"); +-FUSE_SYMVER(".symver fuse_set_getcontext_func,__fuse_set_getcontext_func@"); +-FUSE_SYMVER(".symver fuse_new_compat2,fuse_new@"); ++FUSE_SYMVER(".symver fuse_exited,__fuse_exited@FUSE_UNVERSIONED"); ++FUSE_SYMVER(".symver fuse_process_cmd,__fuse_process_cmd@FUSE_UNVERSIONED"); ++FUSE_SYMVER(".symver fuse_read_cmd,__fuse_read_cmd@FUSE_UNVERSIONED"); ++FUSE_SYMVER(".symver fuse_set_getcontext_func,__fuse_set_getcontext_func@FUSE_UNVERSIONED"); ++FUSE_SYMVER(".symver fuse_new_compat2,fuse_new@FUSE_UNVERSIONED"); + FUSE_SYMVER(".symver fuse_new_compat22,fuse_new@FUSE_2.2"); + + #endif /* __FreeBSD__ */ +Index: fuse-2.8.6/lib/fuse_mt.c +=================================================================== +--- fuse-2.8.6.orig/lib/fuse_mt.c 2011-09-13 00:23:14.000000000 -0700 ++++ fuse-2.8.6/lib/fuse_mt.c 2011-10-19 09:20:27.537099939 -0700 +@@ -113,4 +113,4 @@ + return fuse_session_loop_mt(fuse_get_session(f)); + } + +-FUSE_SYMVER(".symver fuse_loop_mt_proc,__fuse_loop_mt@"); ++FUSE_SYMVER(".symver fuse_loop_mt_proc,__fuse_loop_mt@FUSE_UNVERSIONED"); +Index: fuse-2.8.6/lib/fuse_versionscript +=================================================================== +--- fuse-2.8.6.orig/lib/fuse_versionscript 2011-09-13 00:23:14.000000000 -0700 ++++ fuse-2.8.6/lib/fuse_versionscript 2011-10-19 09:20:27.541099939 -0700 +@@ -1,3 +1,6 @@ ++FUSE_UNVERSIONED { ++}; ++ + FUSE_2.2 { + global: + fuse_destroy; +Index: fuse-2.8.6/lib/helper.c +=================================================================== +--- fuse-2.8.6.orig/lib/helper.c 2011-09-13 00:23:14.000000000 -0700 ++++ fuse-2.8.6/lib/helper.c 2011-10-19 09:20:27.541099939 -0700 +@@ -409,10 +409,10 @@ + return fuse_mount_compat22(mountpoint, NULL); + } + +-FUSE_SYMVER(".symver fuse_setup_compat2,__fuse_setup@"); ++FUSE_SYMVER(".symver fuse_setup_compat2,__fuse_setup@FUSE_UNVERSIONED"); + FUSE_SYMVER(".symver fuse_setup_compat22,fuse_setup@FUSE_2.2"); +-FUSE_SYMVER(".symver fuse_teardown,__fuse_teardown@"); +-FUSE_SYMVER(".symver fuse_main_compat2,fuse_main@"); ++FUSE_SYMVER(".symver fuse_teardown,__fuse_teardown@FUSE_UNVERSIONED"); ++FUSE_SYMVER(".symver fuse_main_compat2,fuse_main@FUSE_UNVERSIONED"); + FUSE_SYMVER(".symver fuse_main_real_compat22,fuse_main_real@FUSE_2.2"); + + #endif /* __FreeBSD__ */ diff --git a/meta/recipes-support/fuse/fuse_2.9.2.bb b/meta/recipes-support/fuse/fuse_2.9.2.bb new file mode 100644 index 0000000..5d7cdfd --- /dev/null +++ b/meta/recipes-support/fuse/fuse_2.9.2.bb @@ -0,0 +1,38 @@ +DESCRIPTION = "With FUSE it is possible to implement a fully functional filesystem in a userspace program" +HOMEPAGE = "http://fuse.sf.net" +SECTION = "libs" +LICENSE = "GPLv2 & LGPLv2" +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ + file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c" + +SRC_URI = "${SOURCEFORGE_MIRROR}/fuse/fuse-${PV}.tar.gz \ + file://gold-unversioned-symbol.patch \ + file://aarch64.patch \ +" +SRC_URI[md5sum] = "7d80d0dc9cc2b9199a0c53787c151205" +SRC_URI[sha256sum] = "81a728fb3f87da33063068735e2fb7e2cd89df207d32687d3d3278385279cefc" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--disable-kernel-module" + +PACKAGES =+ "fuse-utils-dbg fuse-utils libulockmgr libulockmgr-dev libulockmgr-dbg" + +RRECOMMENDS_${PN} = "kernel-module-fuse" + +FILES_${PN} += "${libdir}/libfuse.so.*" +FILES_${PN}-dev += "${libdir}/libfuse*.la" + +FILES_libulockmgr = "${libdir}/libulockmgr.so.*" +FILES_libulockmgr-dev += "${libdir}/libulock*.la" +FILES_libulockmgr-dbg += "${libdir}/.debug/libulock*" + +# Forbid auto-renaming to libfuse-utils +FILES_fuse-utils = "${bindir} ${base_sbindir}" +FILES_fuse-utils-dbg = "${bindir}/.debug ${base_sbindir}/.debug" +DEBIAN_NOAUTONAME_fuse-utils = "1" +DEBIAN_NOAUTONAME_fuse-utils-dbg = "1" + +do_install_append() { + rm -rf ${D}${base_prefix}/dev +} -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 2/4] ntfs-3g-ntfsprogs:import and update recipe from meta-oe 2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia 2013-05-30 9:01 ` [PATCH 1/4] fuse: import recipe from meta-oe Hongxu Jia @ 2013-05-30 9:01 ` Hongxu Jia 2013-05-30 9:01 ` [PATCH 3/4] fuse-exfat: add version 1.0.1 Hongxu Jia ` (2 subsequent siblings) 4 siblings, 0 replies; 16+ messages in thread From: Hongxu Jia @ 2013-05-30 9:01 UTC (permalink / raw) To: openembedded-core Import version 2011.4.12 from meta-oe and update to version 2013.1.13. This recipe is a merge of ntfs-3g and ntfsprogs [YOCTO #4178] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> --- .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 ++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb diff --git a/meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb b/meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb new file mode 100644 index 0000000..0067cb2 --- /dev/null +++ b/meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb @@ -0,0 +1,33 @@ +DESCRIPTION = "The NTFS-3G driver is an open source, freely available NTFS driver for Linux with read and write support." +HOMEPAGE = "http://www.ntfs-3g.org/" +DEPENDS = "fuse libgcrypt" +PROVIDES = "ntfsprogs ntfs-3g" +LICENSE = "GPLv2 & LGPLv2" +LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ + file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a" + +SRC_URI = "http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz" +S = "${WORKDIR}/ntfs-3g_ntfsprogs-${PV}" + +SRC_URI[md5sum] = "2d6fb47ddf62b51733227126fe9227fe" +SRC_URI[sha256sum] = "4b383f0074a3ab7683339d1f18222b107aaeb4983db119292c43c2b275cefb27" + +inherit autotools + +# required or it calls ldconfig at install step +EXTRA_OEMAKE = "LDCONFIG=echo" + +PACKAGES =+ "ntfs-3g ntfsprogs libntfs-3g" + +FILES_ntfs-3g = "${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* ${base_sbindir}/mount.ntfs" +RDEPENDS_ntfs-3g += "fuse util-linux-mount" + +FILES_ntfsprogs = "${base_sbindir}/* ${bindir}/* ${sbindir}/*" +FILES_libntfs-3g = "${libdir}/*${SOLIBS}" + +do_install_append() { + # Standard mount will execute the program /sbin/mount.TYPE + # when called. Add the symbolic to let mount could find ntfs. + ln -sf mount.ntfs-3g ${D}/${base_sbindir}/mount.ntfs +} + -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 3/4] fuse-exfat: add version 1.0.1 2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia 2013-05-30 9:01 ` [PATCH 1/4] fuse: import recipe from meta-oe Hongxu Jia 2013-05-30 9:01 ` [PATCH 2/4] ntfs-3g-ntfsprogs:import and update " Hongxu Jia @ 2013-05-30 9:01 ` Hongxu Jia 2013-05-30 9:01 ` [PATCH 4/4] exfat-utils: " Hongxu Jia 2013-05-30 9:18 ` [PATCH 0/4]Add FUSE: File system in Userspace Jack Mitchell 4 siblings, 0 replies; 16+ messages in thread From: Hongxu Jia @ 2013-05-30 9:01 UTC (permalink / raw) To: openembedded-core The fuse-exfat is read and write exFAT driver for FUSE [YOCTO #4178] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> --- meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 ++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb diff --git a/meta/recipes-support/exfat/fuse-exfat_1.0.1.bb b/meta/recipes-support/exfat/fuse-exfat_1.0.1.bb new file mode 100644 index 0000000..d29dc0a --- /dev/null +++ b/meta/recipes-support/exfat/fuse-exfat_1.0.1.bb @@ -0,0 +1,26 @@ +SUMMARY = "read and write exFAT driver for FUSE" +DESCRIPTION = "fuse-exfat is a read and write driver implementing the \ +extended file allocation table as a filesystem in userspace. A mounthelper \ +is provided unter the name mount.exfat-fuse. \ +" +HOMEPAGE = "http://code.google.com/p/exfat/" +SECTION = "universe/otherosfs" +LICENSE = "GPLv3" +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" +SRC_URI = "${DEBIAN_MIRROR}/main/f/fuse-exfat/fuse-exfat_${PV}.orig.tar.gz \ +" +DEPENDS = "fuse virtual/libc" +RDEPENDS_${PN} += "util-linux-mount" + +inherit scons + +SRC_URI[md5sum] = "7988a5111841593231f20af22153362d" +SRC_URI[sha256sum] = "12ac1ba1b7d4343bef64e7898176705a41cfe3b5a7a179e28549d242e2854758" + +EXTRA_OESCONS = " \ + DESTDIR=${D}/${base_sbindir} \ +" + +do_install_prepend() { + install -d ${D}/${base_sbindir} +} -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 4/4] exfat-utils: add version 1.0.1 2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia ` (2 preceding siblings ...) 2013-05-30 9:01 ` [PATCH 3/4] fuse-exfat: add version 1.0.1 Hongxu Jia @ 2013-05-30 9:01 ` Hongxu Jia 2013-05-30 9:18 ` [PATCH 0/4]Add FUSE: File system in Userspace Jack Mitchell 4 siblings, 0 replies; 16+ messages in thread From: Hongxu Jia @ 2013-05-30 9:01 UTC (permalink / raw) To: openembedded-core The utilities to create, check, label and dump exFAT filesystem [YOCTO #4178] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> --- meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 +++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb diff --git a/meta/recipes-support/exfat/exfat-utils_1.0.1.bb b/meta/recipes-support/exfat/exfat-utils_1.0.1.bb new file mode 100644 index 0000000..a5a314f --- /dev/null +++ b/meta/recipes-support/exfat/exfat-utils_1.0.1.bb @@ -0,0 +1,29 @@ +SUMMARY = "utilities to create, check, label and dump exFAT filesystem" +DESCRIPTION = "Utilities to manage extended file allocation table filesystem. \ +This package provides tools to create, check and label the filesystem. It \ +contains \ + - dumpexfat to dump properties of the filesystem \ + - exfatfsck / fsck.exfat to report errors found on a exFAT filesystem \ + - exfatlabel to label a exFAT filesystem \ + - mkexfatfs / mkfs.exfat to create a exFAT filesystem. \ +" +HOMEPAGE = "http://code.google.com/p/exfat/" +SECTION = "universe/otherosfs" +LICENSE = "GPLv3" +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" +SRC_URI = "${DEBIAN_MIRROR}/main/e/exfat-utils/exfat-utils_${PV}.orig.tar.gz \ +" +DEPENDS = "virtual/libc" + +inherit scons + +SRC_URI[md5sum] = "e592130829d0bf61fa5e3cd1c759d329" +SRC_URI[sha256sum] = "eeacedca1878065dc3886674ae39cd51149c37bd7d6d7e9325c971a1d1acdab3" + +EXTRA_OESCONS = " \ + DESTDIR=${D}/${base_sbindir} \ +" + +do_install_prepend() { + install -d ${D}/${base_sbindir} +} -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia ` (3 preceding siblings ...) 2013-05-30 9:01 ` [PATCH 4/4] exfat-utils: " Hongxu Jia @ 2013-05-30 9:18 ` Jack Mitchell 2013-05-30 10:38 ` Paul Eggleton 2013-05-30 12:17 ` Mark Hatle 4 siblings, 2 replies; 16+ messages in thread From: Jack Mitchell @ 2013-05-30 9:18 UTC (permalink / raw) To: openembedded-core On 30/05/13 10:01, Hongxu Jia wrote: > Add fuse to oe-core and let target system could support > `ntfs' and `exfat' filesystems. > > Test Case > > *Steps > 1, preparation > 1 target: e-menlow > 2 usb sticks: one for boot and install, another for filesystem test. > > 2, config > conf/local.conf: > 247 MACHINE ?= "emenlow-noemgd" > 247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils" > > conf/bblayers.conf: > 8 BBLAYERS ?= " \ > 9 /home/jiahongxu/yocto/poky/meta \ > 10 /home/jiahongxu/yocto/poky/meta-yocto \ > 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ > 12 /home/jiahongxu/yocto/poky/meta-intel \ > 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \ > > 3, build image > bitbake core-image-sato > > 4, load image to emenlow > Test Case TC-2927: boot and install from usb > > 5, open a terminal/ssh of e-menlow > Test Case TC-2955: remote access by ssh > > 6, make exfat filesystem on the testing usb storage > 1) plug usb stick into e-menlow > 2) execute `mkfs.exfat /dev/sdc1' > > 7, test usb stick with exfat filesystem is accessible > Test Case TC-2947: usb mount > Test Case TC-2948: usb read files > Test Case TC-2949: usb umount > Test Case TC-2950: usb write files > > 8, make ntfs filesystem on the testing usb storage > 1) plug usb stick into e-menlow, if mounted, invoke `umount /dev/sdc1' first. > 2) execute `mkfs.ntfs -f /dev/sdc1' > > 9, test usb stick with ntfs filesystem is accessible > Test Case TC-2947: usb mount > Test Case TC-2948: usb read files > Test Case TC-2949: usb umount > Test Case TC-2950: usb write files > > *Expected Results: > 1, build image success > > 2, make exfat filesystem success > root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 > mkexfatfs 1.0.1 > Creating... done. > Flushing... done. > File system created successfully. > > 3, make ntfs filesystem success > root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 > Cluster size has been automatically set to 4096 bytes. > Creating NTFS volume structures. > mkntfs completed successfully. Have a nice day. > > 4, While the usb's filesystem type is exfat or ntfs, system can mount > plugged usb automatically, read files from usb, write files to usb and > unmout usb automatically. > > [YOCTO #4178] > > The following changes since commit 350c36fcd97e8ef223b91e548d39c346c1c4cb29: > > bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300) > > are available in the git repository at: > > git://git.pokylinux.org/poky-contrib hongxu/support-fuse > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse > > Hongxu Jia (4): > fuse: import recipe from meta-oe > ntfs-3g-ntfsprogs:import and update recipe from meta-oe > fuse-exfat: add version 1.0.1 > exfat-utils: add version 1.0.1 > > meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ > meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ > meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ > .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ > meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ > .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ > 6 files changed, 206 insertions(+) > create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb > create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb > create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch > create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch > create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb > create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb > Without trying to be difficult, is oe-core really the place to support and spend effort ensuring NTFS/exFAT formatted drives are supported? Could these improvements not stay in meta-oe? I don't really see support for essentially propriety filesystems as a core feature of a Linux build. Shout up if I'm talking nonsense, just my 2p. -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 9:18 ` [PATCH 0/4]Add FUSE: File system in Userspace Jack Mitchell @ 2013-05-30 10:38 ` Paul Eggleton 2013-05-30 12:17 ` Mark Hatle 1 sibling, 0 replies; 16+ messages in thread From: Paul Eggleton @ 2013-05-30 10:38 UTC (permalink / raw) To: openembedded-core, ml On Thursday 30 May 2013 10:18:56 Jack Mitchell wrote: > On 30/05/13 10:01, Hongxu Jia wrote: > > Add fuse to oe-core and let target system could support > > `ntfs' and `exfat' filesystems. > > > > Test Case > > > > *Steps > > 1, preparation > > 1 target: e-menlow > > 2 usb sticks: one for boot and install, another for filesystem test. > > > > 2, config > > conf/local.conf: > > 247 MACHINE ?= "emenlow-noemgd" > > 247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils" > > > > conf/bblayers.conf: > > 8 BBLAYERS ?= " \ > > 9 /home/jiahongxu/yocto/poky/meta \ > > > > 10 /home/jiahongxu/yocto/poky/meta-yocto \ > > 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ > > 12 /home/jiahongxu/yocto/poky/meta-intel \ > > 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \ > > > > 3, build image > > bitbake core-image-sato > > > > 4, load image to emenlow > > Test Case TC-2927: boot and install from usb > > > > 5, open a terminal/ssh of e-menlow > > Test Case TC-2955: remote access by ssh > > > > 6, make exfat filesystem on the testing usb storage > > 1) plug usb stick into e-menlow > > 2) execute `mkfs.exfat /dev/sdc1' > > > > 7, test usb stick with exfat filesystem is accessible > > Test Case TC-2947: usb mount > > Test Case TC-2948: usb read files > > Test Case TC-2949: usb umount > > Test Case TC-2950: usb write files > > > > 8, make ntfs filesystem on the testing usb storage > > 1) plug usb stick into e-menlow, if mounted, invoke `umount /dev/sdc1' > > first. 2) execute `mkfs.ntfs -f /dev/sdc1' > > > > 9, test usb stick with ntfs filesystem is accessible > > Test Case TC-2947: usb mount > > Test Case TC-2948: usb read files > > Test Case TC-2949: usb umount > > Test Case TC-2950: usb write files > > > > *Expected Results: > > 1, build image success > > > > 2, make exfat filesystem success > > root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 > > mkexfatfs 1.0.1 > > Creating... done. > > Flushing... done. > > File system created successfully. > > > > 3, make ntfs filesystem success > > root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 > > Cluster size has been automatically set to 4096 bytes. > > Creating NTFS volume structures. > > mkntfs completed successfully. Have a nice day. > > > > 4, While the usb's filesystem type is exfat or ntfs, system can mount > > plugged usb automatically, read files from usb, write files to usb and > > unmout usb automatically. > > > > [YOCTO #4178] > > > > The following changes since commit 350c36fcd97e8ef223b91e548d39c346c1c4cb29: > > bitbake: test/fetch: Allow the conditional network tests to work under > > python 2.6 (2013-05-17 12:42:08 +0300)> > > are available in the git repository at: > > git://git.pokylinux.org/poky-contrib hongxu/support-fuse > > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fu > > se > > > > Hongxu Jia (4): > > fuse: import recipe from meta-oe > > ntfs-3g-ntfsprogs:import and update recipe from meta-oe > > fuse-exfat: add version 1.0.1 > > exfat-utils: add version 1.0.1 > > > > meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ > > meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ > > meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ > > .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 > > ++++++++++++++++++++ meta/recipes-support/fuse/fuse_2.9.2.bb > > | 38 +++++++++++++ .../ntfs-3g-ntfsprogs_2013.1.13.bb > > | 33 +++++++++++ 6 files changed, 206 insertions(+) > > create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb > > create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb > > create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch > > create mode 100644 > > meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch > > create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb > > create mode 100644 > > meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb > > Without trying to be difficult, is oe-core really the place to support > and spend effort ensuring NTFS/exFAT formatted drives are supported? > > Could these improvements not stay in meta-oe? I don't really see support > for essentially propriety filesystems as a core feature of a Linux build. > > Shout up if I'm talking nonsense, just my 2p. That was also my comment on the bug report, FWIW: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4178 Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 9:18 ` [PATCH 0/4]Add FUSE: File system in Userspace Jack Mitchell 2013-05-30 10:38 ` Paul Eggleton @ 2013-05-30 12:17 ` Mark Hatle 2013-05-30 12:58 ` Philip Balister 1 sibling, 1 reply; 16+ messages in thread From: Mark Hatle @ 2013-05-30 12:17 UTC (permalink / raw) To: openembedded-core On 5/30/13 4:18 AM, Jack Mitchell wrote: > > On 30/05/13 10:01, Hongxu Jia wrote: >> Add fuse to oe-core and let target system could support >> `ntfs' and `exfat' filesystems. >> >> Test Case >> >> *Steps >> 1, preparation >> 1 target: e-menlow >> 2 usb sticks: one for boot and install, another for filesystem test. >> >> 2, config >> conf/local.conf: >> 247 MACHINE ?= "emenlow-noemgd" >> 247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils" >> >> conf/bblayers.conf: >> 8 BBLAYERS ?= " \ >> 9 /home/jiahongxu/yocto/poky/meta \ >> 10 /home/jiahongxu/yocto/poky/meta-yocto \ >> 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ >> 12 /home/jiahongxu/yocto/poky/meta-intel \ >> 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \ >> >> 3, build image >> bitbake core-image-sato >> >> 4, load image to emenlow >> Test Case TC-2927: boot and install from usb >> >> 5, open a terminal/ssh of e-menlow >> Test Case TC-2955: remote access by ssh >> >> 6, make exfat filesystem on the testing usb storage >> 1) plug usb stick into e-menlow >> 2) execute `mkfs.exfat /dev/sdc1' >> >> 7, test usb stick with exfat filesystem is accessible >> Test Case TC-2947: usb mount >> Test Case TC-2948: usb read files >> Test Case TC-2949: usb umount >> Test Case TC-2950: usb write files >> >> 8, make ntfs filesystem on the testing usb storage >> 1) plug usb stick into e-menlow, if mounted, invoke `umount /dev/sdc1' first. >> 2) execute `mkfs.ntfs -f /dev/sdc1' >> >> 9, test usb stick with ntfs filesystem is accessible >> Test Case TC-2947: usb mount >> Test Case TC-2948: usb read files >> Test Case TC-2949: usb umount >> Test Case TC-2950: usb write files >> >> *Expected Results: >> 1, build image success >> >> 2, make exfat filesystem success >> root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 >> mkexfatfs 1.0.1 >> Creating... done. >> Flushing... done. >> File system created successfully. >> >> 3, make ntfs filesystem success >> root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 >> Cluster size has been automatically set to 4096 bytes. >> Creating NTFS volume structures. >> mkntfs completed successfully. Have a nice day. >> >> 4, While the usb's filesystem type is exfat or ntfs, system can mount >> plugged usb automatically, read files from usb, write files to usb and >> unmout usb automatically. >> >> [YOCTO #4178] >> >> The following changes since commit 350c36fcd97e8ef223b91e548d39c346c1c4cb29: >> >> bitbake: test/fetch: Allow the conditional network tests to work under python 2.6 (2013-05-17 12:42:08 +0300) >> >> are available in the git repository at: >> >> git://git.pokylinux.org/poky-contrib hongxu/support-fuse >> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse >> >> Hongxu Jia (4): >> fuse: import recipe from meta-oe >> ntfs-3g-ntfsprogs:import and update recipe from meta-oe >> fuse-exfat: add version 1.0.1 >> exfat-utils: add version 1.0.1 >> >> meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ >> meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ >> meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ >> .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 ++++++++++++++++++++ >> meta/recipes-support/fuse/fuse_2.9.2.bb | 38 +++++++++++++ >> .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ >> 6 files changed, 206 insertions(+) >> create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb >> create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb >> create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch >> create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch >> create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb >> create mode 100644 meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb >> > > Without trying to be difficult, is oe-core really the place to support > and spend effort ensuring NTFS/exFAT formatted drives are supported? The basis of this work comes from pretty much all SD/MicroSD cards, most consumer USB hard disks, etc being preformatted as NTFS/exFAT. When building a consumer device the designers often want to just use FUSE out of the box so they don't have to work on adding the functionality themselves. meta-oe is often times too much stuff in one bundle to just included in a project. The developers I work with prefer a smaller load of packages, primarily oe-core + whatever they need. It makes it easier to support and easier to prevent problems from being introduced by feature creep. > Could these improvements not stay in meta-oe? I don't really see support > for essentially propriety filesystems as a core feature of a Linux build. Yes they could, but then it forces more people to copy the recipes out of meta-oe. I myself am mixed on if fuse belongs on oe-core or not. I can see the argument both ways on including it or rejecting it. However, I'm getting more and more commercial requests for FUSE to be part of the main system. > Shout up if I'm talking nonsense, just my 2p. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 12:17 ` Mark Hatle @ 2013-05-30 12:58 ` Philip Balister 2013-05-30 15:49 ` Mark Hatle 0 siblings, 1 reply; 16+ messages in thread From: Philip Balister @ 2013-05-30 12:58 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On 05/30/2013 08:17 AM, Mark Hatle wrote: > On 5/30/13 4:18 AM, Jack Mitchell wrote: >> >> On 30/05/13 10:01, Hongxu Jia wrote: >>> Add fuse to oe-core and let target system could support >>> `ntfs' and `exfat' filesystems. >>> >>> Test Case >>> >>> *Steps >>> 1, preparation >>> 1 target: e-menlow >>> 2 usb sticks: one for boot and install, another for filesystem test. >>> >>> 2, config >>> conf/local.conf: >>> 247 MACHINE ?= "emenlow-noemgd" >>> 247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils" >>> >>> conf/bblayers.conf: >>> 8 BBLAYERS ?= " \ >>> 9 /home/jiahongxu/yocto/poky/meta \ >>> 10 /home/jiahongxu/yocto/poky/meta-yocto \ >>> 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ >>> 12 /home/jiahongxu/yocto/poky/meta-intel \ >>> 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \ >>> >>> 3, build image >>> bitbake core-image-sato >>> >>> 4, load image to emenlow >>> Test Case TC-2927: boot and install from usb >>> >>> 5, open a terminal/ssh of e-menlow >>> Test Case TC-2955: remote access by ssh >>> >>> 6, make exfat filesystem on the testing usb storage >>> 1) plug usb stick into e-menlow >>> 2) execute `mkfs.exfat /dev/sdc1' >>> >>> 7, test usb stick with exfat filesystem is accessible >>> Test Case TC-2947: usb mount >>> Test Case TC-2948: usb read files >>> Test Case TC-2949: usb umount >>> Test Case TC-2950: usb write files >>> >>> 8, make ntfs filesystem on the testing usb storage >>> 1) plug usb stick into e-menlow, if mounted, invoke `umount >>> /dev/sdc1' first. >>> 2) execute `mkfs.ntfs -f /dev/sdc1' >>> >>> 9, test usb stick with ntfs filesystem is accessible >>> Test Case TC-2947: usb mount >>> Test Case TC-2948: usb read files >>> Test Case TC-2949: usb umount >>> Test Case TC-2950: usb write files >>> >>> *Expected Results: >>> 1, build image success >>> >>> 2, make exfat filesystem success >>> root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 >>> mkexfatfs 1.0.1 >>> Creating... done. >>> Flushing... done. >>> File system created successfully. >>> >>> 3, make ntfs filesystem success >>> root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 >>> Cluster size has been automatically set to 4096 bytes. >>> Creating NTFS volume structures. >>> mkntfs completed successfully. Have a nice day. >>> >>> 4, While the usb's filesystem type is exfat or ntfs, system can mount >>> plugged usb automatically, read files from usb, write files to usb and >>> unmout usb automatically. >>> >>> [YOCTO #4178] >>> >>> The following changes since commit >>> 350c36fcd97e8ef223b91e548d39c346c1c4cb29: >>> >>> bitbake: test/fetch: Allow the conditional network tests to work >>> under python 2.6 (2013-05-17 12:42:08 +0300) >>> >>> are available in the git repository at: >>> >>> git://git.pokylinux.org/poky-contrib hongxu/support-fuse >>> >>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse >>> >>> >>> Hongxu Jia (4): >>> fuse: import recipe from meta-oe >>> ntfs-3g-ntfsprogs:import and update recipe from meta-oe >>> fuse-exfat: add version 1.0.1 >>> exfat-utils: add version 1.0.1 >>> >>> meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ >>> meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ >>> meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ >>> .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 >>> ++++++++++++++++++++ >>> meta/recipes-support/fuse/fuse_2.9.2.bb | 38 >>> +++++++++++++ >>> .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ >>> 6 files changed, 206 insertions(+) >>> create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb >>> create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb >>> create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch >>> create mode 100644 >>> meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch >>> create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb >>> create mode 100644 >>> meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb >>> >> >> Without trying to be difficult, is oe-core really the place to support >> and spend effort ensuring NTFS/exFAT formatted drives are supported? > > The basis of this work comes from pretty much all SD/MicroSD cards, most > consumer USB hard disks, etc being preformatted as NTFS/exFAT. When > building a consumer device the designers often want to just use FUSE out > of the box so they don't have to work on adding the functionality > themselves. > > meta-oe is often times too much stuff in one bundle to just included in > a project. The developers I work with prefer a smaller load of > packages, primarily oe-core + whatever they need. It makes it easier to > support and easier to prevent problems from being introduced by feature > creep. If there are issues using meta-oe for a few recipes, we need to identify these issues and fix them. If we do not advocate for the layer model, we risk creeping slowly back to the monolithic OE of days gone by. Philip > >> Could these improvements not stay in meta-oe? I don't really see support >> for essentially propriety filesystems as a core feature of a Linux build. > > Yes they could, but then it forces more people to copy the recipes out > of meta-oe. > > I myself am mixed on if fuse belongs on oe-core or not. I can see the > argument both ways on including it or rejecting it. However, I'm > getting more and more commercial requests for FUSE to be part of the > main system. > >> Shout up if I'm talking nonsense, just my 2p. >> > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 12:58 ` Philip Balister @ 2013-05-30 15:49 ` Mark Hatle 2013-05-30 16:13 ` Phil Blundell 2013-05-30 16:56 ` Khem Raj 0 siblings, 2 replies; 16+ messages in thread From: Mark Hatle @ 2013-05-30 15:49 UTC (permalink / raw) To: Philip Balister; +Cc: openembedded-core On 5/30/13 7:58 AM, Philip Balister wrote: > On 05/30/2013 08:17 AM, Mark Hatle wrote: >> On 5/30/13 4:18 AM, Jack Mitchell wrote: >>> >>> On 30/05/13 10:01, Hongxu Jia wrote: >>>> Add fuse to oe-core and let target system could support >>>> `ntfs' and `exfat' filesystems. >>>> >>>> Test Case >>>> >>>> *Steps >>>> 1, preparation >>>> 1 target: e-menlow >>>> 2 usb sticks: one for boot and install, another for filesystem test. >>>> >>>> 2, config >>>> conf/local.conf: >>>> 247 MACHINE ?= "emenlow-noemgd" >>>> 247 IMAGE_INSTALL_append = " ntfs-3g ntfsprogs fuse-exfat exfat-utils" >>>> >>>> conf/bblayers.conf: >>>> 8 BBLAYERS ?= " \ >>>> 9 /home/jiahongxu/yocto/poky/meta \ >>>> 10 /home/jiahongxu/yocto/poky/meta-yocto \ >>>> 11 /home/jiahongxu/yocto/poky/meta-yocto-bsp \ >>>> 12 /home/jiahongxu/yocto/poky/meta-intel \ >>>> 13 /home/jiahongxu/yocto/poky/meta-intel/meta-emenlow \ >>>> >>>> 3, build image >>>> bitbake core-image-sato >>>> >>>> 4, load image to emenlow >>>> Test Case TC-2927: boot and install from usb >>>> >>>> 5, open a terminal/ssh of e-menlow >>>> Test Case TC-2955: remote access by ssh >>>> >>>> 6, make exfat filesystem on the testing usb storage >>>> 1) plug usb stick into e-menlow >>>> 2) execute `mkfs.exfat /dev/sdc1' >>>> >>>> 7, test usb stick with exfat filesystem is accessible >>>> Test Case TC-2947: usb mount >>>> Test Case TC-2948: usb read files >>>> Test Case TC-2949: usb umount >>>> Test Case TC-2950: usb write files >>>> >>>> 8, make ntfs filesystem on the testing usb storage >>>> 1) plug usb stick into e-menlow, if mounted, invoke `umount >>>> /dev/sdc1' first. >>>> 2) execute `mkfs.ntfs -f /dev/sdc1' >>>> >>>> 9, test usb stick with ntfs filesystem is accessible >>>> Test Case TC-2947: usb mount >>>> Test Case TC-2948: usb read files >>>> Test Case TC-2949: usb umount >>>> Test Case TC-2950: usb write files >>>> >>>> *Expected Results: >>>> 1, build image success >>>> >>>> 2, make exfat filesystem success >>>> root@emenlow-noemgd:~# mkfs.exfat /dev/sdc1 >>>> mkexfatfs 1.0.1 >>>> Creating... done. >>>> Flushing... done. >>>> File system created successfully. >>>> >>>> 3, make ntfs filesystem success >>>> root@emenlow-noemgd:~# mkfs.ntfs -f /dev/sdc1 >>>> Cluster size has been automatically set to 4096 bytes. >>>> Creating NTFS volume structures. >>>> mkntfs completed successfully. Have a nice day. >>>> >>>> 4, While the usb's filesystem type is exfat or ntfs, system can mount >>>> plugged usb automatically, read files from usb, write files to usb and >>>> unmout usb automatically. >>>> >>>> [YOCTO #4178] >>>> >>>> The following changes since commit >>>> 350c36fcd97e8ef223b91e548d39c346c1c4cb29: >>>> >>>> bitbake: test/fetch: Allow the conditional network tests to work >>>> under python 2.6 (2013-05-17 12:42:08 +0300) >>>> >>>> are available in the git repository at: >>>> >>>> git://git.pokylinux.org/poky-contrib hongxu/support-fuse >>>> >>>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/support-fuse >>>> >>>> >>>> Hongxu Jia (4): >>>> fuse: import recipe from meta-oe >>>> ntfs-3g-ntfsprogs:import and update recipe from meta-oe >>>> fuse-exfat: add version 1.0.1 >>>> exfat-utils: add version 1.0.1 >>>> >>>> meta/recipes-support/exfat/exfat-utils_1.0.1.bb | 29 ++++++++++ >>>> meta/recipes-support/exfat/fuse-exfat_1.0.1.bb | 26 +++++++++ >>>> meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch | 20 +++++++ >>>> .../fuse/fuse-2.9.2/gold-unversioned-symbol.patch | 60 >>>> ++++++++++++++++++++ >>>> meta/recipes-support/fuse/fuse_2.9.2.bb | 38 >>>> +++++++++++++ >>>> .../ntfs-3g-ntfsprogs_2013.1.13.bb | 33 +++++++++++ >>>> 6 files changed, 206 insertions(+) >>>> create mode 100644 meta/recipes-support/exfat/exfat-utils_1.0.1.bb >>>> create mode 100644 meta/recipes-support/exfat/fuse-exfat_1.0.1.bb >>>> create mode 100644 meta/recipes-support/fuse/fuse-2.9.2/aarch64.patch >>>> create mode 100644 >>>> meta/recipes-support/fuse/fuse-2.9.2/gold-unversioned-symbol.patch >>>> create mode 100644 meta/recipes-support/fuse/fuse_2.9.2.bb >>>> create mode 100644 >>>> meta/recipes-support/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb >>>> >>> >>> Without trying to be difficult, is oe-core really the place to support >>> and spend effort ensuring NTFS/exFAT formatted drives are supported? >> >> The basis of this work comes from pretty much all SD/MicroSD cards, most >> consumer USB hard disks, etc being preformatted as NTFS/exFAT. When >> building a consumer device the designers often want to just use FUSE out >> of the box so they don't have to work on adding the functionality >> themselves. >> >> meta-oe is often times too much stuff in one bundle to just included in >> a project. The developers I work with prefer a smaller load of >> packages, primarily oe-core + whatever they need. It makes it easier to >> support and easier to prevent problems from being introduced by feature >> creep. > > If there are issues using meta-oe for a few recipes, we need to identify > these issues and fix them. The issue isn't that it's a few bad recipes, the issue is that meta-oe is a collection of software that doesn't fit anywhere else. (I'm speaking specifically of meta-oe, -not- meta-openembedded which has multiple layers in it.) It's easy for me to justify meta-gnome, if I need gnome.. meta-multimedia, if I need multimedia, etc.. but meta-oe has no single purpose, it's just the place where stuff is put when it doesn't fit anywhere else -- or someone is experimenting with new code. It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should really be in one of the other meta-openembedded layers (or even other project layers). But my customers are not willing to bring in 413 packages just for '1' package they might need out of the set. (Similarly, we don't just "bring in" meta-openembedded either.. we break out the layers so only the ones we're willing to support, and our customers need are provided to them.) There is no such thing as an "unsupported" package when you are a commercial vendor. > If we do not advocate for the layer model, we risk creeping slowly back > to the monolithic OE of days gone by. It's not the layer model that is the issue, it's that meta-oe has no single purpose other then to house things that aren't somewhere else. What I (speaking as a vendor and my customer advocate) want is oe-core to contain the base software that most devices may need. Then individual layers to add capabilities above and beyond that. (Capabilities may be things like BSPs, networking, multimedia, gnome, kde, distributions, etc.) > Philip > >> >>> Could these improvements not stay in meta-oe? I don't really see support >>> for essentially propriety filesystems as a core feature of a Linux build. >> >> Yes they could, but then it forces more people to copy the recipes out >> of meta-oe. >> >> I myself am mixed on if fuse belongs on oe-core or not. I can see the >> argument both ways on including it or rejecting it. However, I'm >> getting more and more commercial requests for FUSE to be part of the >> main system. >> >>> Shout up if I'm talking nonsense, just my 2p. >>> >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 15:49 ` Mark Hatle @ 2013-05-30 16:13 ` Phil Blundell 2013-05-30 16:18 ` Mark Hatle 2013-05-30 16:56 ` Khem Raj 1 sibling, 1 reply; 16+ messages in thread From: Phil Blundell @ 2013-05-30 16:13 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On Thu, 2013-05-30 at 10:49 -0500, Mark Hatle wrote: > It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should > really be in one of the other meta-openembedded layers (or even other project > layers). But my customers are not willing to bring in 413 packages just for '1' > package they might need out of the set. > > (Similarly, we don't just "bring in" meta-openembedded either.. we break out the > layers so only the ones we're willing to support, and our customers need are > provided to them.) There is no such thing as an "unsupported" package when you > are a commercial vendor. I'm not entirely sure what you mean by "bring in" in this context or what the underlying rationale for your reluctance is. But some general comments: It's entirely possible to have a copy of meta-oe on hand and only include a subset of the recipes in the parse. You can do that either by adding the layer and then BBMASKing out everything you don't want, or by not adding the layer as such but just admit individual recipes by adding them to BBFILES specifically. Either of those approaches would avoid the risk of accidentally introducing dependencies on recipes from meta-oe without realising that this is what you are doing. Also, I think the toxicity of meta-oe nowadays is much less than it used to be (thanks mostly to excellent work by Paul in cleaning up the .bbappends and overlapping recipes) and, as far as I know, the act of including meta-oe in your layer list no longer leads to the sort of random changes to recipe versions and behaviour that you might have gotten burned by in the past. So if your previous experience is from some time ago then you might want to give it another try. p. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 16:13 ` Phil Blundell @ 2013-05-30 16:18 ` Mark Hatle 2013-06-03 11:20 ` Philip Balister 0 siblings, 1 reply; 16+ messages in thread From: Mark Hatle @ 2013-05-30 16:18 UTC (permalink / raw) To: Phil Blundell; +Cc: openembedded-core On 5/30/13 11:13 AM, Phil Blundell wrote: > On Thu, 2013-05-30 at 10:49 -0500, Mark Hatle wrote: >> It has 413 recipes (and 2 bbappends). Of the 413, likely many of those should >> really be in one of the other meta-openembedded layers (or even other project >> layers). But my customers are not willing to bring in 413 packages just for '1' >> package they might need out of the set. >> >> (Similarly, we don't just "bring in" meta-openembedded either.. we break out the >> layers so only the ones we're willing to support, and our customers need are >> provided to them.) There is no such thing as an "unsupported" package when you >> are a commercial vendor. > > I'm not entirely sure what you mean by "bring in" in this context or > what the underlying rationale for your reluctance is. But some general > comments: Support and testing.. if the recipe is there we have to support it, if we don't ship it to our customers -- they are free to source it themselves, but it's clear that we didn't test and don't support it. We provide it, customers expect us to support it. We're not willing to support meta-oe due to the number of recipes in it. oe-core, meta-yocto, meta-networking, meta-selinux, meta-webserver, and others we do use, test and provide to our customer. > It's entirely possible to have a copy of meta-oe on hand and only > include a subset of the recipes in the parse. You can do that either by > adding the layer and then BBMASKing out everything you don't want, or by > not adding the layer as such but just admit individual recipes by adding > them to BBFILES specifically. Either of those approaches would avoid > the risk of accidentally introducing dependencies on recipes from > meta-oe without realising that this is what you are doing. > > Also, I think the toxicity of meta-oe nowadays is much less than it used > to be (thanks mostly to excellent work by Paul in cleaning up I agree, it's significantly better now. I do use meta-oe from time to time on personal projects... > the .bbappends and overlapping recipes) and, as far as I know, the act > of including meta-oe in your layer list no longer leads to the sort of > random changes to recipe versions and behaviour that you might have > gotten burned by in the past. So if your previous experience is from > some time ago then you might want to give it another try. > > p. > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 16:18 ` Mark Hatle @ 2013-06-03 11:20 ` Philip Balister 2013-06-03 14:22 ` Mark Hatle 0 siblings, 1 reply; 16+ messages in thread From: Philip Balister @ 2013-06-03 11:20 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On 05/30/2013 12:18 PM, Mark Hatle wrote: > On 5/30/13 11:13 AM, Phil Blundell wrote: >> On Thu, 2013-05-30 at 10:49 -0500, Mark Hatle wrote: >>> It has 413 recipes (and 2 bbappends). Of the 413, likely many of >>> those should >>> really be in one of the other meta-openembedded layers (or even other >>> project >>> layers). But my customers are not willing to bring in 413 packages >>> just for '1' >>> package they might need out of the set. >>> >>> (Similarly, we don't just "bring in" meta-openembedded either.. we >>> break out the >>> layers so only the ones we're willing to support, and our customers >>> need are >>> provided to them.) There is no such thing as an "unsupported" >>> package when you >>> are a commercial vendor. >> >> I'm not entirely sure what you mean by "bring in" in this context or >> what the underlying rationale for your reluctance is. But some general >> comments: > > Support and testing.. if the recipe is there we have to support it, if > we don't ship it to our customers -- they are free to source it > themselves, but it's clear that we didn't test and don't support it. > > We provide it, customers expect us to support it. We're not willing to > support meta-oe due to the number of recipes in it. oe-core, > meta-yocto, meta-networking, meta-selinux, meta-webserver, and others we > do use, test and provide to our customer. Does this mean we should look at splitting meta-oe into more layers? Or is this issue unique to Wind River? At some point, the layer dependencies get out of hand. Philip > >> It's entirely possible to have a copy of meta-oe on hand and only >> include a subset of the recipes in the parse. You can do that either by >> adding the layer and then BBMASKing out everything you don't want, or by >> not adding the layer as such but just admit individual recipes by adding >> them to BBFILES specifically. Either of those approaches would avoid >> the risk of accidentally introducing dependencies on recipes from >> meta-oe without realising that this is what you are doing. >> >> Also, I think the toxicity of meta-oe nowadays is much less than it used >> to be (thanks mostly to excellent work by Paul in cleaning up > > I agree, it's significantly better now. I do use meta-oe from time to > time on personal projects... > >> the .bbappends and overlapping recipes) and, as far as I know, the act >> of including meta-oe in your layer list no longer leads to the sort of >> random changes to recipe versions and behaviour that you might have >> gotten burned by in the past. So if your previous experience is from >> some time ago then you might want to give it another try. >> >> p. >> >> > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-06-03 11:20 ` Philip Balister @ 2013-06-03 14:22 ` Mark Hatle 0 siblings, 0 replies; 16+ messages in thread From: Mark Hatle @ 2013-06-03 14:22 UTC (permalink / raw) To: Philip Balister; +Cc: openembedded-core On 6/3/13 6:20 AM, Philip Balister wrote: > On 05/30/2013 12:18 PM, Mark Hatle wrote: >> On 5/30/13 11:13 AM, Phil Blundell wrote: >>> On Thu, 2013-05-30 at 10:49 -0500, Mark Hatle wrote: >>>> It has 413 recipes (and 2 bbappends). Of the 413, likely many of >>>> those should >>>> really be in one of the other meta-openembedded layers (or even other >>>> project >>>> layers). But my customers are not willing to bring in 413 packages >>>> just for '1' >>>> package they might need out of the set. >>>> >>>> (Similarly, we don't just "bring in" meta-openembedded either.. we >>>> break out the >>>> layers so only the ones we're willing to support, and our customers >>>> need are >>>> provided to them.) There is no such thing as an "unsupported" >>>> package when you >>>> are a commercial vendor. >>> >>> I'm not entirely sure what you mean by "bring in" in this context or >>> what the underlying rationale for your reluctance is. But some general >>> comments: >> >> Support and testing.. if the recipe is there we have to support it, if >> we don't ship it to our customers -- they are free to source it >> themselves, but it's clear that we didn't test and don't support it. >> >> We provide it, customers expect us to support it. We're not willing to >> support meta-oe due to the number of recipes in it. oe-core, >> meta-yocto, meta-networking, meta-selinux, meta-webserver, and others we >> do use, test and provide to our customer. > > Does this mean we should look at splitting meta-oe into more layers? Or > is this issue unique to Wind River? I think there is merit in looking at the contents of meta-oe over time and splitting them up into functional units. However, at this point I don't have any direct suggestions as to what those units would be. > At some point, the layer dependencies get out of hand. Yes they do. The number of layers and contents of them also have to be reevaluated over time. What makes sense for one release may drastically change in the future and we have to be willing to adapt to the changing configurations. I think for the most part the sublayers within meta-openembedded are at roughly the right level. It's the general "meta-oe" that is the issue for us. (Too many things we're not willing to support.) --Mark > Philip > >> >>> It's entirely possible to have a copy of meta-oe on hand and only >>> include a subset of the recipes in the parse. You can do that either by >>> adding the layer and then BBMASKing out everything you don't want, or by >>> not adding the layer as such but just admit individual recipes by adding >>> them to BBFILES specifically. Either of those approaches would avoid >>> the risk of accidentally introducing dependencies on recipes from >>> meta-oe without realising that this is what you are doing. >>> >>> Also, I think the toxicity of meta-oe nowadays is much less than it used >>> to be (thanks mostly to excellent work by Paul in cleaning up >> >> I agree, it's significantly better now. I do use meta-oe from time to >> time on personal projects... >> >>> the .bbappends and overlapping recipes) and, as far as I know, the act >>> of including meta-oe in your layer list no longer leads to the sort of >>> random changes to recipe versions and behaviour that you might have >>> gotten burned by in the past. So if your previous experience is from >>> some time ago then you might want to give it another try. >>> >>> p. >>> >>> >> >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 15:49 ` Mark Hatle 2013-05-30 16:13 ` Phil Blundell @ 2013-05-30 16:56 ` Khem Raj 2013-05-30 16:59 ` Mark Hatle 1 sibling, 1 reply; 16+ messages in thread From: Khem Raj @ 2013-05-30 16:56 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On May 30, 2013, at 8:49 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > The issue isn't that it's a few bad recipes, the issue is that meta-oe is a collection of software that doesn't fit anywhere else. (I'm speaking specifically of meta-oe, -not- meta-openembedded which has multiple layers in it.) OK I see that you are not supporting meta-oe in your commercial product but are in need of bits and pieces from it I would suggest to poach the recipes and keep them in your own supported layer if you do not wish to support meta-oe and It would be nice if you fed back any bug fixes or changes. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 0/4]Add FUSE: File system in Userspace 2013-05-30 16:56 ` Khem Raj @ 2013-05-30 16:59 ` Mark Hatle 0 siblings, 0 replies; 16+ messages in thread From: Mark Hatle @ 2013-05-30 16:59 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On 5/30/13 11:56 AM, Khem Raj wrote: > > On May 30, 2013, at 8:49 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > >> The issue isn't that it's a few bad recipes, the issue is that meta-oe is a collection of software that doesn't fit anywhere else. (I'm speaking specifically of meta-oe, -not- meta-openembedded which has multiple layers in it.) > > OK I see that you are not supporting meta-oe in your commercial product but are in need of bits and pieces from it I would suggest to poach the recipes and keep them in your own supported layer if you do not wish to support meta-oe and It would be nice if you fed back any bug fixes or changes. > Just to be clear, this is exactly what we are doing, and intend to do. Pick pieces as needed from meta-oe, submit fixes/uprevs back to meta-oe for those pieces. If we see a more general need we will submit them to oe-core as well, if they're not accepted, then they go back to meta-oe. --Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-06-03 14:22 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-30 9:01 [PATCH 0/4]Add FUSE: File system in Userspace Hongxu Jia 2013-05-30 9:01 ` [PATCH 1/4] fuse: import recipe from meta-oe Hongxu Jia 2013-05-30 9:01 ` [PATCH 2/4] ntfs-3g-ntfsprogs:import and update " Hongxu Jia 2013-05-30 9:01 ` [PATCH 3/4] fuse-exfat: add version 1.0.1 Hongxu Jia 2013-05-30 9:01 ` [PATCH 4/4] exfat-utils: " Hongxu Jia 2013-05-30 9:18 ` [PATCH 0/4]Add FUSE: File system in Userspace Jack Mitchell 2013-05-30 10:38 ` Paul Eggleton 2013-05-30 12:17 ` Mark Hatle 2013-05-30 12:58 ` Philip Balister 2013-05-30 15:49 ` Mark Hatle 2013-05-30 16:13 ` Phil Blundell 2013-05-30 16:18 ` Mark Hatle 2013-06-03 11:20 ` Philip Balister 2013-06-03 14:22 ` Mark Hatle 2013-05-30 16:56 ` Khem Raj 2013-05-30 16:59 ` Mark Hatle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox