[v2,3/3] fs/rawimg: new rootfs target

Rootfs target to call the new mkrawimg package.

Signed-off-by: Karoly Kasza <kaszak@gmail.com>
---

Changes v1 -> v2:
  - Removed script into new mkrawimg package.

 fs/Config.in        |    1 +
 fs/rawimg/Config.in |   15 +++++++++++++++
 fs/rawimg/rawimg.mk |   13 +++++++++++++
 3 files changed, 29 insertions(+)
 create mode 100644 fs/rawimg/Config.in
 create mode 100644 fs/rawimg/rawimg.mk

Karoly, All,

On 2014-12-09 17:03 +0100, Karoly Kasza spake thusly:
> Rootfs target to call the new mkrawimg package.

We (Peter, Thomas P., Samuel and I) discussed your patch during the
Patchwork cleanup session yesterday. We came up to the following
conclusion.

We believe this is trying to cover a very specific use-case, and should
better be done in a post-image script.

Basically, we believe that Buildroot should not try to be too smart
about the filesystem generation. We offer a set of options to build
basic filesystem images for basic use-cases, as a mean to get
kick-started more easily and for simple systems.

However, more complex filesystem layouts ought to be outside the scope
of what Buildroot should try to automate, given the unlimited
combinations that may exist.

We are however willing to add host packages that provide the tools
required for generating various filesystems or manipulating various
partition types (some of them are already present in the "Host
utilities" sub-menu) and delegate to the user to provide one or more
post-image scripts that can use those tools and assemble the required
filesystem and/or disk images from the rootfs.tar tarball.

Another point in the conclusion was that we should provide some sample
post-image scripts that users can have a look at to see how to write
their own.

As an aside, I add a personal note that was not discussed yesterday: we
should document in the manual all of the above.

As a consequence, we've marked your two patches as Rejected on
Patchwork:
  - [2/3] package/mkrawimg: new package
  - [3/3] fs/rawimg: new rootfs target

Thank you for your numerous contributions so far, they are much
appreciated! :-)

Regards,
Yann E. MORIN.

> Signed-off-by: Karoly Kasza <kaszak@gmail.com>
> ---
> 
> Changes v1 -> v2:
>   - Removed script into new mkrawimg package.
> 
>  fs/Config.in        |    1 +
>  fs/rawimg/Config.in |   15 +++++++++++++++
>  fs/rawimg/rawimg.mk |   13 +++++++++++++
>  3 files changed, 29 insertions(+)
>  create mode 100644 fs/rawimg/Config.in
>  create mode 100644 fs/rawimg/rawimg.mk
> 
> diff --git a/fs/Config.in b/fs/Config.in
> index 5853113..36961db 100644
> --- a/fs/Config.in
> +++ b/fs/Config.in
> @@ -8,6 +8,7 @@ source "fs/initramfs/Config.in"
>  source "fs/iso9660/Config.in"
>  source "fs/jffs2/Config.in"
>  source "fs/romfs/Config.in"
> +source "fs/rawimg/Config.in"
>  source "fs/squashfs/Config.in"
>  source "fs/tar/Config.in"
>  source "fs/ubifs/Config.in"
> diff --git a/fs/rawimg/Config.in b/fs/rawimg/Config.in
> new file mode 100644
> index 0000000..68b518e
> --- /dev/null
> +++ b/fs/rawimg/Config.in
> @@ -0,0 +1,15 @@
> +config BR2_TARGET_ROOTFS_RAWIMG
> +	bool "raw disk image"
> +	depends on BR2_i386 || BR2_x86_64
> +	depends on BR2_LINUX_KERNEL
> +	select BR2_PACKAGE_HOST_MKRAWIMG
> +	select BR2_LINUX_KERNEL_INSTALL_TARGET
> +	select BR2_TARGET_ROOTFS_EXT2
> +	help
> +	  Build a bootable raw disk image, that can be booted in a VM (e.g. QEMU),
> +	  or directly written to disk. Creates a valid partition table with MBR,
> +	  and one primary ext* partition.
> +
> +comment "raw disk image needs a Linux kernel to be built"
> +	depends on BR2_i386 || BR2_x86_64
> +	depends on !BR2_LINUX_KERNEL
> diff --git a/fs/rawimg/rawimg.mk b/fs/rawimg/rawimg.mk
> new file mode 100644
> index 0000000..c0a720d
> --- /dev/null
> +++ b/fs/rawimg/rawimg.mk
> @@ -0,0 +1,13 @@
> +################################################################################
> +#
> +# Build the raw disk image
> +#
> +################################################################################
> +
> +ROOTFS_RAWIMG_DEPENDENCIES = rootfs-ext2 host-mkrawimg
> +
> +define ROOTFS_RAWIMG_CMD
> +	PATH=$(BR_PATH) mkrawimg $(BINARIES_DIR) $@
> +endef
> +
> +$(eval $(call ROOTFS_TARGET,rawimg))
> -- 
> 1.7.10.4
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Hi Yann, list,

We believe this is trying to cover a very specific use-case, and should
> better be done in a post-image script.
>
> Basically, we believe that Buildroot should not try to be too smart
> about the filesystem generation. We offer a set of options to build
> basic filesystem images for basic use-cases, as a mean to get
> kick-started more easily and for simple systems.
>
However, more complex filesystem layouts ought to be outside the scope
> of what Buildroot should try to automate, given the unlimited
> combinations that may exist.
>
OK

Another point in the conclusion was that we should provide some sample
> post-image scripts that users can have a look at to see how to write
> their own.
>

Should I just create a mock-up of this script into the support/scripts
directory or so?
By the way, the build-ext3-img script does something very similar, but
needs root privileges. It also creates a vmx file but no vmdk conversion is
involved, so I think it is broken.

As an aside, I add a personal note that was not discussed yesterday: we
> should document in the manual all of the above.
>
You are right - just the manual seems to follow the development of BR with
some delay :)

Some explanation from my perspective regarding this patch:

I am building BR for various VMs. I use VMware (that's why I sent in
openvmtools obviously), QEMU, KVM and various Cloud providers based on KVM.
I think that BR has a great potential in purpose built VMs (vApps), because
of a few reasons:

- the user is completely in control what runs in his/her VM, this adds
security
- the current VM model is one App per one VM - for which BR is a good
choice as it contains no bloatware like a general purpose Linux distro
- it is sparing with the resources, which means two things: greater VM
density and lower pay-per-go costs in case of hosted VMs (like in Google
Cloud's payment model)

So I started this series, and planned to add at least 2 other
functionalities later:
- build as an OVA file (with the use of host-qemu's "qemu-img convert"
command)
- build directly for Google Cloud Compute Engine, which is a special KVM
(thus QEMU) image

If you guys think, that this could be a fair use-case for BR, I would be
happy to continue to provide patches or post build scripts for at least
these VM formats.

Best regards,
Karoly