From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] aufs: initial release (selects aufs-utils)
Date: Sun, 23 Nov 2014 21:54:15 +0100 [thread overview]
Message-ID: <20141123215415.5cc12226@free-electrons.com> (raw)
In-Reply-To: <1406576065-20263-2-git-send-email-mail@steffenhoenig.com>
Hello Steffen,
Sorry for the very late feedback about your patches. Are you still
interested in getting aufs merged in Buildroot?
On Mon, 28 Jul 2014 21:34:25 +0200, steffenhoenig wrote:
> diff --git a/package/aufs/Config.in b/package/aufs/Config.in
> new file mode 100644
> index 0000000..e7842bd
> --- /dev/null
> +++ b/package/aufs/Config.in
> @@ -0,0 +1,36 @@
> +config BR2_PACKAGE_AUFS
> + bool "aufs"
> + select BR2_PACKAGE_AUFS_UTILS
Why do you select BR2_PACKAGE_AUFS_UTILS here? My understanding is that
the dependency is the other way around: you cannot build aufs-utils
until the aufs package has installed the aufs_type.h header file.
> + help
> + Aufs3 -- advanced multi layered unification filesystem version 3.x
> +
> +comment "aufs needs a Linux kernel to be built"
> + depends on !BR2_LINUX_KERNEL
So there should be a "depends on BR2_LINUX_KERNEL" under the main aufs
config option, above.
> +
> +if BR2_PACKAGE_AUFS
> +
> +choice
> + prompt "version"
> +
> +config BR2_PACKAGE_AUFS_LATEST_VERSION
> + bool "aufs3.15"
> +
> +config BR2_PACKAGE_AUFS_CUSTOM_VERSION
> + bool "custom version"
> + help
> + This option allows to use a specific aufs kernel patch set
> +
> + Note: you need to insert the version string like aufs3.12, aufs3.9, ...
> +
> +endchoice
> +
> +config BR2_PACKAGE_AUFS_CUSTOM_VERSION_VALUE
> + string ""
> + depends on BR2_PACKAGE_AUFS_CUSTOM_VERSION
> +
> +config BR2_PACKAGE_AUFS_VERSION
> + string
> + default "aufs3.15" if BR2_PACKAGE_AUFS_LATEST_VERSION
> + default BR2_PACKAGE_AUFS_CUSTOM_VERSION_VALUE \
> + if BR2_PACKAGE_AUFS_CUSTOM_VERSION
> +endif
I don't think this complexity is necessary. Having a "latest" version
for aufs doesn't make a lot of sense, because nobody wants the "latest"
version: everybody wants a version that matches the kernel version
being used.
So I believe, you can replace that by a single "string" config option:
config BR2_PACKAGE_AUFS_VERSION
string "version"
help
Specify aufs3.9, aufs3.13, aufs3.17 or any other existing
aufs version.
> +AUFS_VERSION = $(call qstrip,$(BR2_PACKAGE_AUFS_VERSION))
> +AUFS_LICENCSE = GPLv2
LICENSE.
> +AUFS_LICENSE_FILES = COPYING
> +
> +AUFS_SITE = http://git.code.sf.net/p/aufs/aufs3-standalone
> +AUFS_SITE_METHOD = git
> +
> +AUFS_DEPENDENCIES = linux
> +AUFS_INSTALL_STAGING = YES
> +
> +AUFS_PATCHES = kbuild base mmap standalone
> +
> +define AUFS_BUILD_CMDS
> + $(foreach p,$(AUFS_PATCHES),./support/scripts/apply-patches.sh $(LINUX_DIR) $(@D) *$(p).patch;)
This cannot work, because AUFS_BUILD_CMDS will be executed *after* the
Linux kernel has been built. So it's too late to patch the kernel.
Since aufs needs to patch the kernel, you'll have to handle it as a
"Linux kernel extension", taking example on what we've done for RTAI in
linux/linux-ext-rtai.mk. I can help with this, but before doing too
much work, I'd like to make sure you are still interested in aufs.
> + $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KDIR=$(LINUX_DIR) aufs.ko
> +endef
> +
> +define AUFS_INSTALL_STAGING_CMDS
> + $(MAKE) -C $(LINUX_DIR) $(LINUX_MAKE_FLAGS) -f scripts/Makefile.host \
> + scripts/unifdef
Why?
> + $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KDIR=$(LINUX_DIR) usr/include/linux/aufs_type.h
This should be part of AUFS_BUILD_CMDS.
> + $(INSTALL) -p -m 0644 $(@D)/usr/include/linux/aufs_type.h \
> + $(STAGING_DIR)/usr/include/linux
> +endef
> +
> +define AUFS_INSTALL_TARGET_CMDS
> + $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KDIR=$(LINUX_DIR) install
> +endef
> +
> +$(eval $(generic-package))
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-11-23 20:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 19:34 [Buildroot] [PATCH 1/2] aufs-utils: initial release steffenhoenig
2014-07-28 19:34 ` [Buildroot] [PATCH 2/2] aufs: initial release (selects aufs-utils) steffenhoenig
2014-11-23 20:54 ` Thomas Petazzoni [this message]
2014-11-23 21:00 ` [Buildroot] [PATCH 1/2] aufs-utils: initial release Thomas Petazzoni
2015-01-02 16:24 ` Thomas Petazzoni
[not found] <1406575604-19545-1-git-send-email-mail@steffenhoenig.com>
2014-07-28 19:26 ` [Buildroot] [PATCH 2/2] aufs: initial release (selects aufs-utils) steffenhoenig
2014-07-28 19:49 ` Thomas De Schampheleire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141123215415.5cc12226@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox