* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: Andrea Arcangeli @ 2011-10-31 18:44 UTC (permalink / raw)
To: John Stoffel
Cc: Dan Magenheimer, Johannes Weiner, Pekka Enberg, Cyclonus J,
Sasha Levin, Christoph Hellwig, David Rientjes, Linus Torvalds,
linux-mm, LKML, Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge,
Seth Jennings, ngupta, Chris Mason, JBeulich, Dave Hansen,
Jonathan Corbet
In-Reply-To: <20138.62532.493295.522948@quad.stoffel.home>
On Fri, Oct 28, 2011 at 02:28:20PM -0400, John Stoffel wrote:
> and service. How would TM benefit me? I don't use Xen, don't want to
> play with it honestly because I'm busy enough as it is, and I just
> don't see the hard benefits.
If you used Xen tmem would be more or less the equivalent of
cache=writethrough/writeback. For us tmem is the linux host pagecache
running on the baremetal in short. But at least when we vmexit for a
read we read 128-512k of it (depending on if=virtio or others and
guest kernel readahead decision), not just a fixed absolutely worst
case 4k unit like tmem would do...
Without tmem Xen can only work like KVM cache=off.
If at least it would drop us a copy, but no, it still does the bounce
buffer, so I'd rather bounce in the host kernel function
file_read_actor than in some superflous (as far as KVM is concerned)
tmem code, plus we normally read orders of magnitude more than 4k in
each vmexit, so our default cache=writeback/writethroguh may already
be more efficient than if we'd use tmem for that.
We could only consider for swap compression but for swap compression
I've no idea why we still need to do a copy, instead of just
compressing from userland page in zerocopy (worst case using any
mechanism introduced to provide stable pages).
And when host linux pagecache will go hugepage we'll get a >4k copy in
one go while tmem bounce will still be stuck at 4k...
^ permalink raw reply
* Re: Flicker-free boot in DRM
From: Keith Packard @ 2011-10-31 18:45 UTC (permalink / raw)
To: Jesse Barnes; +Cc: drivers, Intel
In-Reply-To: <20111031095726.242ddeeb@jbarnes-desktop>
[-- Attachment #1.1: Type: text/plain, Size: 699 bytes --]
On Mon, 31 Oct 2011 09:57:26 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Easier to just copy the contents out of the current framebuffer into a
> new one before flipping to the new buffer.
I'm not excited about doing the copy, but I don't see a better plan --
we want to be able to use stolen memory for other things, but we can't
do that while scanout is happening.
> I think that's already possible if we don't use the helper function for
> mode setting.
I'd like to avoid duplicating all of that logic down in every driver, of
course, so finding a simple way to give the driver a bit more control
seems like a reasonable compromise.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: Andrea Arcangeli @ 2011-10-31 18:44 UTC (permalink / raw)
To: John Stoffel
Cc: Dan Magenheimer, Johannes Weiner, Pekka Enberg, Cyclonus J,
Sasha Levin, Christoph Hellwig, David Rientjes, Linus Torvalds,
linux-mm, LKML, Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge,
Seth Jennings, ngupta, Chris Mason, JBeulich, Dave Hansen,
Jonathan Corbet
In-Reply-To: <20138.62532.493295.522948@quad.stoffel.home>
On Fri, Oct 28, 2011 at 02:28:20PM -0400, John Stoffel wrote:
> and service. How would TM benefit me? I don't use Xen, don't want to
> play with it honestly because I'm busy enough as it is, and I just
> don't see the hard benefits.
If you used Xen tmem would be more or less the equivalent of
cache=writethrough/writeback. For us tmem is the linux host pagecache
running on the baremetal in short. But at least when we vmexit for a
read we read 128-512k of it (depending on if=virtio or others and
guest kernel readahead decision), not just a fixed absolutely worst
case 4k unit like tmem would do...
Without tmem Xen can only work like KVM cache=off.
If at least it would drop us a copy, but no, it still does the bounce
buffer, so I'd rather bounce in the host kernel function
file_read_actor than in some superflous (as far as KVM is concerned)
tmem code, plus we normally read orders of magnitude more than 4k in
each vmexit, so our default cache=writeback/writethroguh may already
be more efficient than if we'd use tmem for that.
We could only consider for swap compression but for swap compression
I've no idea why we still need to do a copy, instead of just
compressing from userland page in zerocopy (worst case using any
mechanism introduced to provide stable pages).
And when host linux pagecache will go hugepage we'll get a >4k copy in
one go while tmem bounce will still be stuck at 4k...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support
From: Vladimir Zapolskiy @ 2011-10-31 18:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAEDE0B.7090201@aribaud.net>
Hi Albert,
On 31.10.2011 19:42, Albert ARIBAUD wrote:
> Hi Vladimir,
>
> Le 24/10/2011 01:04, Vladimir Zapolskiy a ?crit :
>> Hi Albert,
>>
>> On 22.10.2011 02:31, Albert ARIBAUD wrote:
>>> Hi Vladimir,
>>>
>>> Le 18/10/2011 17:55, Vladimir Zapolskiy a ?crit :
>>>> This change adds initial support for NXP LPC32x0 SoC series.
>>>>
>>>> Signed-off-by: Vladimir Zapolskiy<vz@mleia.com>
>>>> ---
>>>> Changes from v2 to v3:
>>>> * checkpatch.pl reports zero errors and warnings
>>>>
>>>> Changes from v1 to v2:
>>>> * BIT(n) and SBF(s, v) macro are not used anymore
>>>> * removed NS16550 and 14-clock UART definitions from uart.h
>>>> * added devices.c file, which contains standard UART preinitialization
>>>> routine
>>>> * added get_serial_clock() function, it returns actual frequency of
>>>> UART clock
>>>> * __udelay() realization is simplified, no need of interrupt handling
>>>
>>> As it stands, this is dead code until some board uses it; I imagine you
>>> have board waiting for this support. Can you submit the SoC and board
>>> code as a patch set? This way, it will be obvious for all that the SoC
>>> code in this patch has actual use.
>>
>> you're right, I have a board to make support for. However I presume that
>> U-boot maintainers won't be happy to include a board with
>> CONFIG_ENV_IS_NOWHERE, and unfortunately flash driver isn't yet ready
>> for publishing.
>
> CONFIG_ENV_IS_NOWHERE is the board( maintainer)'s business.
>
> Ditto for the FLASH driver, if it is not required for use of the board
> (e.g., if U-Boot can fire up and does not need the FLASH to boot an OS,
> then a broken FLASH driver is an inconvenience, not a showstopper).
I've added CFI flash support to the board, however the environment is
supposed to be stored in NAND flash, and that requires some more LPC32XX
specific stuff to be developed for U-boot soon (basically that's NAND
controller and DMA drivers).
>> I'd like to get an advice, if you think that weakly supported but
>> working U-boot on the board has chances to be included to arm-next I can
>> send the patchset right now for review, otherwise I'll spend some time
>> (one week approximately) to finish NAND driver.
>
> IMO, the acceptable state of a board is the board maintainer's affair,
> with a bare minimum that U-Boot must be able to play its role as a
> bootloader.
>
It's done in my understanding. Hopefully some more addons still should
be implemented, and I'd like to concentrate on them being assured that
the SoC and basic board support are pulled in.
> Anyway, since that is for next, not master, and since you think you can
> add the missing support far before the next merge window, I suggest you
> complete board support and add it to V4.
>
The initial board support was done and published a week ago, please
check http://lists.denx.de/pipermail/u-boot/2011-October/106991.html
And that's my expression of willing to become a board maintainer, sorry
it hasn't been included to the board changeset originally -
http://lists.denx.de/pipermail/u-boot/2011-October/107069.html
I'd like to encourage you to check that the board specific compilation
has zero warnings and checkpatch.pl output is clean.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: Flicker-free boot in DRM
From: Keith Packard @ 2011-10-31 18:43 UTC (permalink / raw)
To: Adam Jackson; +Cc: drivers, Intel
In-Reply-To: <4EAED35A.4040307@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 482 bytes --]
On Mon, 31 Oct 2011 12:56:58 -0400, Adam Jackson <ajax@redhat.com> wrote:
> Yeah, it won't be precise. That's why there's PLL search code at all,
> and why it has a fuzz factor for finding "good enough".
Right, so we'll need a similar fuzz factor when deciding whether we
actually need to flip modes or not. Makes me concerned that we'll be
effectively ignoring minor changes in the mode, which will make tweaking
dot clocks impossible.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Qemu-devel] [PATCH v3 1/4] Add basic version of bridge helper
From: Corey Bryant @ 2011-10-31 18:36 UTC (permalink / raw)
To: qemu-devel; +Cc: aliguori, rmarwah
In-Reply-To: <1320086191-23641-1-git-send-email-coreyb@linux.vnet.ibm.com>
This patch adds a helper that can be used to create a tap device attached to
a bridge device. Since this helper is minimal in what it does, it can be
given CAP_NET_ADMIN which allows qemu to avoid running as root while still
satisfying the majority of what users tend to want to do with tap devices.
The way this all works is that qemu launches this helper passing a bridge
name and the name of an inherited file descriptor. The descriptor is one
end of a socketpair() of domain sockets. This domain socket is used to
transmit a file descriptor of the opened tap device from the helper to qemu.
The helper can then exit and let qemu use the tap device.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
---
Makefile | 12 +++-
configure | 1 +
qemu-bridge-helper.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 228 insertions(+), 2 deletions(-)
create mode 100644 qemu-bridge-helper.c
diff --git a/Makefile b/Makefile
index ba8d738..46b6838 100644
--- a/Makefile
+++ b/Makefile
@@ -35,6 +35,8 @@ $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
LIBS+=-lz $(LIBS_TOOLS)
+HELPERS-$(CONFIG_LINUX) = qemu-bridge-helper$(EXESUF)
+
ifdef BUILD_DOCS
DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 QMP/qmp-commands.txt
else
@@ -75,7 +77,7 @@ defconfig:
-include config-all-devices.mak
-build-all: $(DOCS) $(TOOLS) recurse-all
+build-all: $(DOCS) $(TOOLS) $(HELPERS-y) recurse-all
config-host.h: config-host.h-timestamp
config-host.h-timestamp: config-host.mak
@@ -153,6 +155,8 @@ qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y)
qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y)
qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y)
+qemu-bridge-helper$(EXESUF): qemu-bridge-helper.o
+
qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx
$(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > $@," GEN $@")
@@ -219,7 +223,7 @@ clean:
# avoid old build problems by removing potentially incorrect old files
rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h
rm -f qemu-options.def
- rm -f *.o *.d *.a *.lo $(TOOLS) qemu-ga TAGS cscope.* *.pod *~ */*~
+ rm -f *.o *.d *.a *.lo $(TOOLS) $(HELPERS-y) qemu-ga TAGS cscope.* *.pod *~ */*~
rm -Rf .libs
rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d
rm -f qemu-img-cmds.h
@@ -287,6 +291,10 @@ install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig
ifneq ($(TOOLS),)
$(INSTALL_PROG) $(STRIP_OPT) $(TOOLS) "$(DESTDIR)$(bindir)"
endif
+ifneq ($(HELPERS-y),)
+ $(INSTALL_DIR) "$(DESTDIR)$(libexecdir)"
+ $(INSTALL_PROG) $(STRIP_OPT) $(HELPERS-y) "$(DESTDIR)$(libexecdir)"
+endif
ifneq ($(BLOBS),)
$(INSTALL_DIR) "$(DESTDIR)$(datadir)"
set -e; for x in $(BLOBS); do \
diff --git a/configure b/configure
index a6cf6d6..94c89a7 100755
--- a/configure
+++ b/configure
@@ -2795,6 +2795,7 @@ echo "datadir=$datadir" >> $config_host_mak
echo "sysconfdir=$sysconfdir" >> $config_host_mak
echo "docdir=$docdir" >> $config_host_mak
echo "confdir=$confdir" >> $config_host_mak
+echo "libexecdir=\${prefix}/libexec" >> $config_host_mak
case "$cpu" in
i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32)
diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
new file mode 100644
index 0000000..803681d
--- /dev/null
+++ b/qemu-bridge-helper.c
@@ -0,0 +1,217 @@
+/*
+ * QEMU Bridge Helper
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * Anthony Liguori <aliguori@us.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "config-host.h"
+
+#include <stdio.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <string.h>
+#include <stdlib.h>
+#include <ctype.h>
+
+#include <sys/types.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+#include <sys/un.h>
+#include <sys/prctl.h>
+
+#include <net/if.h>
+
+#include <linux/sockios.h>
+
+#include "net/tap-linux.h"
+
+static int has_vnet_hdr(int fd)
+{
+ unsigned int features = 0;
+ struct ifreq ifreq;
+
+ if (ioctl(fd, TUNGETFEATURES, &features) == -1) {
+ return -errno;
+ }
+
+ if (!(features & IFF_VNET_HDR)) {
+ return -ENOTSUP;
+ }
+
+ if (ioctl(fd, TUNGETIFF, &ifreq) != -1 || errno != EBADFD) {
+ return -ENOTSUP;
+ }
+
+ return 1;
+}
+
+static void prep_ifreq(struct ifreq *ifr, const char *ifname)
+{
+ memset(ifr, 0, sizeof(*ifr));
+ snprintf(ifr->ifr_name, IFNAMSIZ, "%s", ifname);
+}
+
+static int send_fd(int c, int fd)
+{
+ char msgbuf[CMSG_SPACE(sizeof(fd))];
+ struct msghdr msg = {
+ .msg_control = msgbuf,
+ .msg_controllen = sizeof(msgbuf),
+ };
+ struct cmsghdr *cmsg;
+ struct iovec iov;
+ char req[1] = { 0x00 };
+
+ cmsg = CMSG_FIRSTHDR(&msg);
+ cmsg->cmsg_level = SOL_SOCKET;
+ cmsg->cmsg_type = SCM_RIGHTS;
+ cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
+ msg.msg_controllen = cmsg->cmsg_len;
+
+ iov.iov_base = req;
+ iov.iov_len = sizeof(req);
+
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+ memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd));
+
+ return sendmsg(c, &msg, 0);
+}
+
+int main(int argc, char **argv)
+{
+ struct ifreq ifr;
+ int fd, ctlfd, unixfd;
+ int use_vnet = 0;
+ int mtu;
+ const char *bridge;
+ char iface[IFNAMSIZ];
+ int index;
+ int ret = 0;
+
+ /* parse arguments */
+ if (argc < 3 || argc > 4) {
+ fprintf(stderr, "Usage: %s [--use-vnet] BRIDGE FD\n", argv[0]);
+ return 1;
+ }
+
+ index = 1;
+ if (strcmp(argv[index], "--use-vnet") == 0) {
+ use_vnet = 1;
+ index++;
+ if (argc == 3) {
+ fprintf(stderr, "invalid number of arguments\n");
+ return -1;
+ }
+ }
+
+ bridge = argv[index++];
+ unixfd = atoi(argv[index++]);
+
+ /* open a socket to use to control the network interfaces */
+ ctlfd = socket(AF_INET, SOCK_STREAM, 0);
+ if (ctlfd == -1) {
+ fprintf(stderr, "failed to open control socket\n");
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* open the tap device */
+ fd = open("/dev/net/tun", O_RDWR);
+ if (fd == -1) {
+ fprintf(stderr, "failed to open /dev/net/tun\n");
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* request a tap device, disable PI, and add vnet header support if
+ * requested and it's available. */
+ prep_ifreq(&ifr, "tap%d");
+ ifr.ifr_flags = IFF_TAP|IFF_NO_PI;
+ if (use_vnet && has_vnet_hdr(fd)) {
+ ifr.ifr_flags |= IFF_VNET_HDR;
+ }
+
+ if (ioctl(fd, TUNSETIFF, &ifr) == -1) {
+ fprintf(stderr, "failed to create tun device\n");
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* save tap device name */
+ snprintf(iface, sizeof(iface), "%s", ifr.ifr_name);
+
+ /* get the mtu of the bridge */
+ prep_ifreq(&ifr, bridge);
+ if (ioctl(ctlfd, SIOCGIFMTU, &ifr) == -1) {
+ fprintf(stderr, "failed to get mtu of bridge `%s'\n", bridge);
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* save mtu */
+ mtu = ifr.ifr_mtu;
+
+ /* set the mtu of the interface based on the bridge */
+ prep_ifreq(&ifr, iface);
+ ifr.ifr_mtu = mtu;
+ if (ioctl(ctlfd, SIOCSIFMTU, &ifr) == -1) {
+ fprintf(stderr, "failed to set mtu of device `%s' to %d\n",
+ iface, mtu);
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* add the interface to the bridge */
+ prep_ifreq(&ifr, bridge);
+ ifr.ifr_ifindex = if_nametoindex(iface);
+
+ if (ioctl(ctlfd, SIOCBRADDIF, &ifr) == -1) {
+ fprintf(stderr, "failed to add interface `%s' to bridge `%s'\n",
+ iface, bridge);
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* bring the interface up */
+ prep_ifreq(&ifr, iface);
+ if (ioctl(ctlfd, SIOCGIFFLAGS, &ifr) == -1) {
+ fprintf(stderr, "failed to get interface flags for `%s'\n", iface);
+ ret = -errno;
+ goto cleanup;
+ }
+
+ ifr.ifr_flags |= IFF_UP;
+ if (ioctl(ctlfd, SIOCSIFFLAGS, &ifr) == -1) {
+ fprintf(stderr, "failed to set bring up interface `%s'\n", iface);
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* write fd to the domain socket */
+ if (send_fd(unixfd, fd) == -1) {
+ fprintf(stderr, "failed to write fd to unix socket\n");
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* ... */
+
+ /* profit! */
+
+cleanup:
+
+ close(fd);
+
+ close(ctlfd);
+
+ return ret;
+}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 3/3 v3.1] ARM: S3C64XX: Correct reservation of GPIOs for CPU module on Cragganmore
From: Mark Brown @ 2011-10-31 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320086573-21184-1-git-send-email-broonie@opensource.wolfsonmicro.com>
The gpio_base for the PMIC on the CPU module was being incorrectly set to
be the same as that for the CODEC causing the two GPIO drivers to collide.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/mach-crag6410.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 3903d86..03eb475 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -74,6 +74,7 @@
#define PCA935X_GPIO_BASE GPIO_BOARD_START
#define CODEC_GPIO_BASE (GPIO_BOARD_START + 8)
#define GLENFARCLAS_PMIC_GPIO_BASE (GPIO_BOARD_START + 16)
+#define BANFF_PMIC_GPIO_BASE (GLENFARCLAS_PMIC_GPIO_BASE + 16)
/* serial port setup */
@@ -509,7 +510,7 @@ static struct wm831x_touch_pdata touch_pdata __initdata = {
static struct wm831x_pdata crag_pmic_pdata __initdata = {
.wm831x_num = 1,
.irq_base = BANFF_PMIC_IRQ_BASE,
- .gpio_base = GPIO_BOARD_START + 8,
+ .gpio_base = BANFF_PMIC_GPIO_BASE,
.soft_shutdown = true,
.backup = &banff_backup_pdata,
--
1.7.7.1
^ permalink raw reply related
* [PATCH 2/3 v3.1] ARM: SAMSUNG: Fix GPIO space reservation for S3C64xx platforms
From: Mark Brown @ 2011-10-31 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320086573-21184-1-git-send-email-broonie@opensource.wolfsonmicro.com>
The conversion to use SAMSUNG_GPIO_EXTRA rather than S3C24XX_GPIO_EXTRA
broke a number of S3C64xx boards which had been using the symbols provided
to reserve a range of GPIOs for board specific use. Fix this by adding
equivalent symbols for the new shared driver and updating the relevant
boards to use the new symbols.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/Kconfig | 6 +++---
arch/arm/plat-samsung/Kconfig | 8 ++++++++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 5552e04..4d8c489 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -188,7 +188,7 @@ config SMDK6410_WM1190_EV1
depends on MACH_SMDK6410
select REGULATOR
select REGULATOR_WM8350
- select S3C24XX_GPIO_EXTRA64
+ select SAMSUNG_GPIO_EXTRA64
select MFD_WM8350_I2C
select MFD_WM8350_CONFIG_MODE_0
select MFD_WM8350_CONFIG_MODE_3
@@ -206,7 +206,7 @@ config SMDK6410_WM1192_EV1
depends on MACH_SMDK6410
select REGULATOR
select REGULATOR_WM831X
- select S3C24XX_GPIO_EXTRA64
+ select SAMSUNG_GPIO_EXTRA64
select MFD_WM831X
select MFD_WM831X_I2C
help
@@ -287,7 +287,7 @@ config MACH_WLF_CRAGG_6410
select S3C_DEV_WDT
select S3C_DEV_RTC
select S3C64XX_DEV_SPI
- select S3C24XX_GPIO_EXTRA128
+ select SAMSUNG_GPIO_EXTRA128
select I2C
help
Machine support for the Wolfson Cragganmore S3C6410 variant.
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 313eb26..bb0af66 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -88,12 +88,20 @@ config S5P_GPIO_DRVSTR
config SAMSUNG_GPIO_EXTRA
int "Number of additional GPIO pins"
+ default 128 if SAMSUNG_GPIO_EXTRA128
+ default 64 if SAMSUNG_GPIO_EXTRA64
default 0
help
Use additional GPIO space in addition to the GPIO's the SOC
provides. This allows expanding the GPIO space for use with
GPIO expanders.
+config SAMSUNG_GPIO_EXTRA64
+ bool
+
+config SAMSUNG_GPIO_EXTRA128
+ bool
+
config S3C_GPIO_SPACE
int "Space between gpio banks"
default 0
--
1.7.7.1
^ permalink raw reply related
* [PATCH 1/3 v3.1] ARM: S3C64XX: Update for conversion to SAMSUNG_GPIO_EXTRA
From: Mark Brown @ 2011-10-31 18:42 UTC (permalink / raw)
To: linux-arm-kernel
The conversion of the S3C64XX GPIOs to the generic Samsung GPIOs mean that
rather than using the previous S3C24XX_GPIO_EXTRA configuration the driver
now uses SAMSUNG_GPIO_EXTRA.
Since SAMSUNG_GPIO_EXTRA requires the arch to include the extra space in
ARCH_NR_GPIOs add it on to BOARD_NR_GPIOs (in case boards are relying on
the existing reservation).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/include/mach/gpio.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/include/mach/gpio.h b/arch/arm/mach-s3c64xx/include/mach/gpio.h
index 6e34c2f..090c497 100644
--- a/arch/arm/mach-s3c64xx/include/mach/gpio.h
+++ b/arch/arm/mach-s3c64xx/include/mach/gpio.h
@@ -88,6 +88,6 @@ enum s3c_gpio_number {
/* define the number of gpios we need to the one after the GPQ() range */
#define GPIO_BOARD_START (S3C64XX_GPQ(S3C64XX_GPIO_Q_NR) + 1)
-#define BOARD_NR_GPIOS 16
+#define BOARD_NR_GPIOS (16 + CONFIG_SAMSUNG_GPIO_EXTRA)
#define ARCH_NR_GPIOS (GPIO_BOARD_START + BOARD_NR_GPIOS)
--
1.7.7.1
^ permalink raw reply related
* Re: yocto Digest, Vol 13, Issue 54
From: Mike Tsukerman @ 2011-10-31 18:42 UTC (permalink / raw)
To: yocto
In-Reply-To: <mailman.205.1320085760.2193.yocto@yoctoproject.org>
[-- Attachment #1: Type: text/plain, Size: 19782 bytes --]
On Mon, Oct 31, 2011 at 10:29 PM, <yocto-request@yoctoproject.org> wrote:
> Send yocto mailing list submissions to
> yocto@yoctoproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
> yocto-request@yoctoproject.org
>
> You can reach the person managing the list at
> yocto-owner@yoctoproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
>
>
> Today's Topics:
>
> 1. Re: any objection to adding a PREMIRRORS section to the QS
> guide? (Robert P. J. Day)
> 2. Re: root paths in packages (McClintock Matthew-B29882)
> 3. Re: [PATCH 1/2] meta-romley: Fix BSP description in
> romley.conf (Bodke, Kishore K)
> 4. Re: [PATCH 2/2] meta-romley: change references to sugarbay in
> linux-yocto-rt_3.0.bbappend (Bodke, Kishore K)
> 5. Re: root paths in packages (Mark Hatle)
> 6. Re: what's the proper value for BB_NUMBER_THREADS? (Mark Hatle)
> 7. Re: what's the proper value for BB_NUMBER_THREADS?
> (Robert P. J. Day)
> 8. Re: what's the proper value for BB_NUMBER_THREADS? (Gary Thomas)
> 9. Re: root paths in packages (McClintock Matthew-B29882)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Oct 2011 12:01:26 -0400 (EDT)
> From: "Robert P. J. Day" <rpjday@crashcourse.ca>
> To: "Rifenbark, Scott M" <scott.m.rifenbark@intel.com>
> Cc: Yocto discussion list <yocto@yoctoproject.org>
> Subject: Re: [yocto] any objection to adding a PREMIRRORS section to
> the QS guide?
> Message-ID:
> <alpine.DEB.2.02.1110311150440.7448@localhost6.localdomain6>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Mon, 31 Oct 2011, Rifenbark, Scott M wrote:
>
> > Robert,
> >
> > We do have a question addressed in the Yocto Project Reference
> > Manual that talks about premirrors and how Poky finds stuff. See
> > the H.24 section of the manual
> >
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
> .
> > Maybe this information is a bit too buried to be useful. I could
> > specifically reference that FAQ entry from within the QS in the same
> > area that I mention the other "useful" items to consider in the
> > local.conf file, such as BB_NUMBER_THREADS, etc.
> >
> > Scott
>
> i know about the PREMIRRORS stuff in the poky reference manual -- i
> was just toying with the idea that knowing how PREMIRRORS works would
> be useful, even for a beginner.
>
> perhaps i'm not using it properly, but in my case, it's handy since
> i have a downloads directory of nothing but tarballs that i've been
> accumulating over the last while that i've used for openembedded and
> other projects. i'm using PREMIRRORS_prepend to take advantage of all
> that content to avoid any unnecessary downloading. and every time i
> *do* end up downloading a newer version of a tarball that i didn't
> have, i copy it to that central downloads directory for the next time.
> does that make sense? and, as i said, even beginners should be able
> to appreciate taking advantage of local content they may have
> collected for other reasons.
>
> in any event, i have some different ideas for the design of a
> beginner's guide i plan on using in some of my own presentations, so i
> don't have to inflict all of my ideas on everyone else.
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 31 Oct 2011 16:32:23 +0000
> From: McClintock Matthew-B29882 <B29882@freescale.com>
> To: Mike Tsukerman <miketsukerman@gmail.com>
> Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
> Subject: Re: [yocto] root paths in packages
> Message-ID:
> <CAEsOVNd18cWS5JeaxHMLTR9-pr+65bb4s=qc7H_6Prq1PpTzbw@mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Mon, Oct 31, 2011 at 5:57 AM, Mike Tsukerman <miketsukerman@gmail.com>
> wrote:
> > Hello,
> > I've build rpm packages and met some interesting things.
> > In the rpm all scripts and files include root paths from machine that
> i've
> > build on.
> > how can i change that?
>
> Which package? Can you give some examples?
>
> -M
>
> - Hide quoted text -
On Mon, Oct 31, 2011 at 10:26 PM, McClintock Matthew-B29882 <
B29882@freescale.com> wrote:
> On Mon, Oct 31, 2011 at 11:40 AM, Mike Tsukerman
> <miketsukerman@gmail.com> wrote:
>
What commands did you run to generate this rpm? What file is this in?
> Usually the shebang should be updated to remove any references to
> build environment but it looks like it's still referencing perl-native
> from the build environment.
>
> Is this script used on the target machine or just during the build
> process? It might not be explicitly required.
>
>
I've run MACHINE=beagleboard bitbake world. Then i get a lot of rpms in
armv7a-vfp-neon folder.
I have an igep0020 board, and core-image-minimal-dev running on it. I use
these rpm's on the board.
And as expected dpkg is not working before i found that it includes these
paths.
But all other rpm's have the same problems - in INSTALL and UPGRADE scripts
i've found root paths.
rpm --nosignature -ivh
/media/mdev/yocto/poky/build/tmp/deploy/rpm/armv7a-vfp-neon/zip-dev-3.0-r0.armv7a.rpm
>
> ------------------------------
>
> Message: 3
> Date: Mon, 31 Oct 2011 10:01:06 -0700
> From: "Bodke, Kishore K" <kishore.k.bodke@intel.com>
> To: "Zanussi, Tom" <tom.zanussi@intel.com>, "yocto@yoctoproject.org"
> <yocto@yoctoproject.org>
> Subject: Re: [yocto] [PATCH 1/2] meta-romley: Fix BSP description in
> romley.conf
> Message-ID:
> <
> 4BD43A85686FC34D819098DB1C3999D9018F70901D@orsmsx502.amr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Acked-by: Kishore Bodke <Kishore.k.bodke@intel.com>
>
> Thanks
> Kishore.
>
> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:
> yocto-bounces@yoctoproject.org] On Behalf Of tom.zanussi@intel.com
> Sent: Friday, October 28, 2011 7:00 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] [PATCH 1/2] meta-romley: Fix BSP description in
> romley.conf
>
> From: Tom Zanussi <tom.zanussi@intel.com>
>
> The description still had a reference to Sugar Bay; this changes it to
> Romley.
>
> Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> ---
> meta-romley/conf/machine/romley.conf | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta-romley/conf/machine/romley.conf
> b/meta-romley/conf/machine/romley.conf
> index 38bd17a..2dcb5db 100644
> --- a/meta-romley/conf/machine/romley.conf
> +++ b/meta-romley/conf/machine/romley.conf
> @@ -1,7 +1,7 @@
> #@TYPE: Machine
> #@NAME: romley
>
> -#@DESCRIPTION: Machine configuration for Sugar Bay systems
> +#@DESCRIPTION: Machine configuration for Romley systems
> # i.e. Sandy Bridge + Patsburg Chipset
>
> require conf/machine/include/tune-x86_64.inc
> --
> 1.7.0.4
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 31 Oct 2011 10:03:47 -0700
> From: "Bodke, Kishore K" <kishore.k.bodke@intel.com>
> To: "Zanussi, Tom" <tom.zanussi@intel.com>, "yocto@yoctoproject.org"
> <yocto@yoctoproject.org>
> Subject: Re: [yocto] [PATCH 2/2] meta-romley: change references to
> sugarbay in linux-yocto-rt_3.0.bbappend
> Message-ID:
> <
> 4BD43A85686FC34D819098DB1C3999D9018F709021@orsmsx502.amr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Acked-by: Kishore Bodke <Kishore.k.bodke@intel.com>
>
> Thanks
> Kishore.
>
> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:
> yocto-bounces@yoctoproject.org] On Behalf Of tom.zanussi@intel.com
> Sent: Friday, October 28, 2011 7:00 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] [PATCH 2/2] meta-romley: change references to sugarbay in
> linux-yocto-rt_3.0.bbappend
>
> From: Tom Zanussi <tom.zanussi@intel.com>
>
> There are still references to sugarbay in linux-yocto-rt_3.0.bbappend;
> this changes them to romley.
>
> Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> ---
> .../linux/linux-yocto-rt_3.0.bbappend | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
> b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
> index d630dc4..1551ccf 100644
> --- a/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
> +++ b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
> @@ -3,6 +3,6 @@ COMPATIBLE_MACHINE_romley = "romley"
> KMACHINE_romley = "romley"
>
> # Update the following to use a different BSP branch or meta SRCREV
> -#KBRANCH_sugarbay = "yocto/standard/preempt-rt/base"
> -#SRCREV_machine_pn-linux-yocto-rt_sugarbay ?= XXXX
> -#SRCREV_meta_pn-linux-yocto-rt_sugarbay ?= XXXX
> +#KBRANCH_romley = "yocto/standard/preempt-rt/base"
> +#SRCREV_machine_pn-linux-yocto-rt_romley ?= XXXX
> +#SRCREV_meta_pn-linux-yocto-rt_romley ?= XXXX
> --
> 1.7.0.4
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 31 Oct 2011 12:12:08 -0500
> From: Mark Hatle <mark.hatle@windriver.com>
> To: <yocto@yoctoproject.org>
> Subject: Re: [yocto] root paths in packages
> Message-ID: <4EAED6E8.3080800@windriver.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 10/31/11 5:57 AM, Mike Tsukerman wrote:
> > Hello,
> >
> > I've build rpm packages and met some interesting things.
> > In the rpm all scripts and files include root paths from machine that
> i've build on.
> > how can i change that?
>
> Examples of the problem are definitely needed. There are some cases where
> embedded paths simply refer to the place on the disk a source file or
> similar
> came from during the build. Depending on where these references are, they
> may
> be considered safe and acceptable. However, in most places something like
> this
> would be considered an error.
>
> --Mark
>
> > --
> > Best regards, Mike Tsukerman
> >
> > jabber: miketsukerman@gmail.com <mailto:miketsukerman@gmail.com>
> > jabber: warzon@jabnet.org <mailto:warzon@jabnet.org>
> > skype: w_a_r_z_o_n
> >
> >
> >
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 31 Oct 2011 12:15:28 -0500
> From: Mark Hatle <mark.hatle@windriver.com>
> To: <yocto@yoctoproject.org>
> Subject: Re: [yocto] what's the proper value for BB_NUMBER_THREADS?
> Message-ID: <4EAED7B0.4050909@windriver.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 10/30/11 11:15 AM, Robert P. J. Day wrote:
> > On Sun, 30 Oct 2011, Christian Gagneraud wrote:
> >
> >> On 30/10/11 15:32, Robert P. J. Day wrote:
> >>>
> >>> all the docs recommend twice the number of cores (AFAICT), yet the
> >>> template local.conf file suggests that, for a quad core, the value of
> >>> 4 would be appropriate. shouldn't that say 8? same with
> >>> PARALLEL_MAKE?
> >>
> >> Hi Robert,
> >>
> >> The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
> >> and x1.5 for PARALLEL_MAKE.
> >
> > if that's the case, anyone object to my submitting a patch to
> > update local.conf.sample appropriately?
> >
> > rday
> >
>
> I agree the manual and local.conf files should match. The issue seems to
> be
> that the perfect values are subjective. Things like memory, disk speed,
> chipset
> latency, and of course processor speed/cores all affect the optimal
> setting.
> But we do need a consistent rule of thumb.. I myself usually use x2 for
> both
> THREADS and MAKE.
>
> --Mark
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 31 Oct 2011 13:25:03 -0400 (EDT)
> From: "Robert P. J. Day" <rpjday@crashcourse.ca>
> To: Mark Hatle <mark.hatle@windriver.com>
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] what's the proper value for BB_NUMBER_THREADS?
> Message-ID:
> <alpine.DEB.2.02.1110311323050.8545@localhost6.localdomain6>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Mon, 31 Oct 2011, Mark Hatle wrote:
>
> > On 10/30/11 11:15 AM, Robert P. J. Day wrote:
> > > On Sun, 30 Oct 2011, Christian Gagneraud wrote:
> > >
> > >> On 30/10/11 15:32, Robert P. J. Day wrote:
> > >>>
> > >>> all the docs recommend twice the number of cores (AFAICT), yet the
> > >>> template local.conf file suggests that, for a quad core, the value of
> > >>> 4 would be appropriate. shouldn't that say 8? same with
> > >>> PARALLEL_MAKE?
> > >>
> > >> Hi Robert,
> > >>
> > >> The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
> > >> and x1.5 for PARALLEL_MAKE.
> > >
> > > if that's the case, anyone object to my submitting a patch to
> > > update local.conf.sample appropriately?
> > >
> > > rday
> > >
> >
> > I agree the manual and local.conf files should match. The issue
> > seems to be that the perfect values are subjective. Things like
> > memory, disk speed, chipset latency, and of course processor
> > speed/cores all affect the optimal setting. But we do need a
> > consistent rule of thumb.. I myself usually use x2 for both THREADS
> > and MAKE.
>
> that's what i would normally use, assuming that having an overly
> high value for either of those settings can't possibly hurt. if
> that's the consensus, i can adjust the references to say 2x everywhere
> that i know of. just let me know.
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 31 Oct 2011 11:39:06 -0600
> From: Gary Thomas <gary@mlbassoc.com>
> To: "Robert P. J. Day" <rpjday@crashcourse.ca>
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] what's the proper value for BB_NUMBER_THREADS?
> Message-ID: <4EAEDD3A.9070601@mlbassoc.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2011-10-31 11:25, Robert P. J. Day wrote:
> > On Mon, 31 Oct 2011, Mark Hatle wrote:
> >
> >> On 10/30/11 11:15 AM, Robert P. J. Day wrote:
> >>> On Sun, 30 Oct 2011, Christian Gagneraud wrote:
> >>>
> >>>> On 30/10/11 15:32, Robert P. J. Day wrote:
> >>>>>
> >>>>> all the docs recommend twice the number of cores (AFAICT), yet
> the
> >>>>> template local.conf file suggests that, for a quad core, the value of
> >>>>> 4 would be appropriate. shouldn't that say 8? same with
> >>>>> PARALLEL_MAKE?
> >>>>
> >>>> Hi Robert,
> >>>>
> >>>> The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
> >>>> and x1.5 for PARALLEL_MAKE.
> >>>
> >>> if that's the case, anyone object to my submitting a patch to
> >>> update local.conf.sample appropriately?
> >>>
> >>> rday
> >>>
> >>
> >> I agree the manual and local.conf files should match. The issue
> >> seems to be that the perfect values are subjective. Things like
> >> memory, disk speed, chipset latency, and of course processor
> >> speed/cores all affect the optimal setting. But we do need a
> >> consistent rule of thumb.. I myself usually use x2 for both THREADS
> >> and MAKE.
> >
> > that's what i would normally use, assuming that having an overly
> > high value for either of those settings can't possibly hurt. if
> > that's the consensus, i can adjust the references to say 2x everywhere
> > that i know of. just let me know.
>
> Look back in the archives - I think it was Richard that did a fairly
> extensive study of this and he (whoever it was) found that there were
> saturation points and trying to get beyond them had a negative impact.
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 31 Oct 2011 18:27:27 +0000
> From: McClintock Matthew-B29882 <B29882@freescale.com>
> To: Mike Tsukerman <miketsukerman@gmail.com>
> Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
> Subject: Re: [yocto] root paths in packages
> Message-ID:
> <CAEsOVNeP_tPvsB0BEX2tLXK=sEHP1=NSSEPEX4GVwMiAwr2-_Q@mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Mon, Oct 31, 2011 at 11:40 AM, Mike Tsukerman
> <miketsukerman@gmail.com> wrote:
> > I'am using upstream release from git repository.
> > my building path is /media/mdev/yocto/poky/build/.
> > For example dpkg rpm package for armv7 neon. But it's the same for ?all
> > other packages. This cause many many errors and faults.
> > i've attached to the letter screenshot with example.
> > On Mon, Oct 31, 2011 at 8:32 PM, McClintock Matthew-B29882
> > <B29882@freescale.com> wrote:
> >>
> >> On Mon, Oct 31, 2011 at 5:57 AM, Mike Tsukerman <
> miketsukerman@gmail.com>
> >> wrote:
> >> > Hello,
> >> > I've build rpm packages and met some interesting things.
> >> > In the rpm all scripts and files include root paths from machine that
> >> > i've
> >> > build on.
> >> > how can i change that?
>
> Mike,
>
> You need to reply all to include the mailing list.
>
> What commands did you run to generate this rpm? What file is this in?
> Usually the shebang should be updated to remove any references to
> build environment but it looks like it's still referencing perl-native
> from the build environment.
>
> Is this script used on the target machine or just during the build
> process? It might not be explicitly required.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: example.png
> Type: image/png
> Size: 162063 bytes
> Desc: example.png
> URL: <
> http://lists.yoctoproject.org/pipermail/yocto/attachments/20111031/af29d2b9/attachment.png
> >
>
> ------------------------------
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> End of yocto Digest, Vol 13, Issue 54
> *************************************
>
--
Best regards, Mike Tsukerman
jabber: miketsukerman@gmail.com
jabber: warzon@jabnet.org
skype: w_a_r_z_o_n
[-- Attachment #2: Type: text/html, Size: 28485 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Trond Myklebust @ 2011-10-31 18:39 UTC (permalink / raw)
To: Jim Rees; +Cc: Benny Halevy, Peng Tao, linux-nfs, Peng Tao, nfsv4 list
In-Reply-To: <20111031183131.GA1925@umich.edu>
On Mon, 2011-10-31 at 14:31 -0400, Jim Rees wrote:
> Trond Myklebust wrote:
>
> I don't necessarily disagree with what you are saying, but I have yet to
> see a single server side implementation of CB_RECALL_ANY, let alone any
> numbers that indicate performance or responsiveness problems resulting
> from our existing client-side implementation.
>
> I therefore find it hard to understand why optimising this particular
> code is such a high priority, or why a patch that is adding per-file
> layoutreturns to initiate_bulk_draining() is going to help anything at
> all.
>
> Testing between the linux block layout client and the EMC block layout
> server revealed a deadlock when the server had handed out some number of
> layouts and couldn't hand out any more. So now the EMC block layout server
> implements CB_RECALL_ANY. So yes, this solves a real world problem, and
> yes, there is a server that implements this.
>
> We had some discussions at the time, and I don't remember if those were on
> the linux-nfs list or in some other forum. We decided that the client was
> in the best position to decide which layouts were no longer needed, so we
> needed some way for the server to tell the client to return some layouts
> without specifying which ones. CB_RECALL_ANY seemed custom-made for this
> purpose, so we used it.
>
> I don't think it would be appropriate for the server to recall all layouts
> when it only needs some of them back.
As I said previously: the current client implementation deals with
CB_RECALL_ANY by calling initiate_file_draining(), which forgets _all_
layouts. If that is what we want to continue to use, then sending
layoutreturn with LAYOUTRETURN4_ALL is appropriate.
Otherwise, please fix the client to be more selective (in which case
LAYOUTRETURN4_FILE may be more appropriate) and please remember to
provide performance numbers to justify the need for optimisation.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: [PATCH] echo: fix octal escaping with \1...\7
From: Mike Frysinger @ 2011-10-31 18:39 UTC (permalink / raw)
To: Eric Blake; +Cc: Herbert Xu, dash, bug-libtool
In-Reply-To: <4EAE9ECB.4040607@redhat.com>
[-- Attachment #1: Type: Text/Plain, Size: 3245 bytes --]
On Monday 31 October 2011 09:12:43 Eric Blake wrote:
> On 10/30/2011 10:23 PM, Mike Frysinger wrote:
> > On Sunday 30 October 2011 23:41:58 Herbert Xu wrote:
> >> Mike Frysinger wrote:
> >>> POSIX states that octal escape sequences should take the form \0num
> >>> when using echo. dash however additionally treats \num as an octal
> >>> sequence. This breaks some packages (like libtool) who attempt to
> >>> use strings with these escape sequences via variables to execute sed
> >>> (since sed ends up getting passed a byte instead of a literal \1).
>
> That's a bug in libtool for using "echo '\1'" and expecting sane
> behavior. Can you provide more details on this libtool bug, so we can
> get it fixed in libtool? Or perhaps it has already been fixed in modern
> libtool, and you are just encountering it in an older version?
i plan on digging through the relevant packages and posting patches where
applicable. i might be wrong about the libtool side, but do know of at least
one ax m4 file using it (which is what started this rat hole in the first
place). but i consider that a parallel issue :).
> >> OK this is a bit of problem. From our conversation I had the
> >> impression that you were referring to the lack of support of
> >> escape codes, rather than unwanted support.
> >>
> >> If it was the former I could easily add it if POSIX said so,
> >> however, as this is an existing feature there may well be scripts
> >> out there that depend on it. So removing it is not an option
> >> unless it is explicitly forbidden by POSIX.
> >
> > i'm not seeing how this jives with dash's goal. if it intends to be a
> > fast/small POSIX compliant shell while punting (almost) all the rest,
> > then why carry additional functionality that POSIX doesn't even mention
> > in passing ? this isn't "documented but optional extended
> > functionality", but rather the realm of "anything goes". otherwise we
> > approach the same realm that dash was created to avoid -- carrying lots
> > of cruft that slow things down because scripts use it rather than POSIX
> > mandating it.
> >
> > as a comparison, bash/ksh/tcsh/zsh/busybox[ash] all behave the way my
> > patch updates dash to operate ... i would test more shells, but these
> > tend to be the standards that everyone compares against. i can't see
> > people writing scripts that only work under dash either.
> >
> >> In any case, scripts that rely on escape codes like this are
> >> simply broken and should either be fixed to use printf or just
> >> run with #!/bin/bash.
> >
> > they're relying on these escape codes not being interpreted as escape
> > codes (which every other shell appears to do), not the other way around
>
> Scripts that rely on a certain interpretation of "echo '\1'" are broken
> regardless of how dash behaves;
sure, i'm not arguing that logic
> but that said, since POSIX doesn't
> require dash's current behavior, and since the proposed patch makes dash
> both smaller and more like other shells in treating it as an extension
> that means a literal 1 rather than an octal escape, I would be in favor
> of making the change in dash.
right, that's what i'm going for
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [Qemu-devel] [PATCH v3 0/4] -net bridge: rootless bridge support for qemu
From: Corey Bryant @ 2011-10-31 18:36 UTC (permalink / raw)
To: qemu-devel; +Cc: aliguori, rmarwah
With qemu it is possible to run a guest from an unprivileged user but if
we wanted to communicate with the outside world we had to switch
to root.
We address this problem by introducing a new network backend and a new
network option for -net tap. This is less flexible when compared to
existing -net tap options because it relies on a helper with elevated
privileges to do the heavy lifting of allocating and attaching a tap
device to a bridge. We use a special purpose helper because we don't
want to elevate the privileges of more generic tools like brctl.
Qemu can be run with the default network helper as follows (in these cases
attaching the tap device to the default br0 bridge):
qemu -hda linux.img -net bridge -net nic
or:
qemu -hda linux.img -net tap,helper=/usr/local/libexec/qemu-bridge-helper -net nic
The default helper uses it's own ACL mechanism for access control, but
future network helpers could be developed, for example, to support PolicyKit
for access control.
More details are included in individual patches. The helper is broken into
a series of patches to improve reviewabilty.
v2:
- Updated signed-off-by's
- Updated author's email
- Set default bridge to br0
- Added -net bridge
- Updated ACL example
- Moved from libcap to libcap-ng
- Fail helper when libcap-ng not configured
v3:
- Use simple queue to store ACLs
- Added goto cleanup to helper's main
- Allow helper execution if libcap-ng not configured
- Completed static analysis and memory analysis on helper
Corey Bryant (4):
Add basic version of bridge helper
Add access control support to qemu bridge helper
Add cap reduction support to enable use as SUID
Add support for net bridge
Makefile | 12 ++-
configure | 37 +++++
net.c | 29 ++++-
net.h | 3 +
net/tap.c | 190 +++++++++++++++++++++++-
net/tap.h | 3 +
qemu-bridge-helper.c | 406 ++++++++++++++++++++++++++++++++++++++++++++++++++
qemu-options.hx | 73 ++++++++--
8 files changed, 730 insertions(+), 23 deletions(-)
create mode 100644 qemu-bridge-helper.c
--
1.7.3.4
^ permalink raw reply
* [Buildroot] [Bug 4429] buildroot 2011.08 does not build on Ubuntu 11.10
From: Michael S. Zick @ 2011-10-31 18:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110311053.39727.minimod@morethan.org>
On Mon October 31 2011, Michael S. Zick wrote:
> I may not find (or be able to spot) anything at all;
> other than my disk drives can do a lot of I/O.
> ;-)
>
Nothing obvious jumps out at me.
(which means nothing, really)
Post or attach to the bug report your .config files.
Will see if I can duplicate the problem between 11.04 and 11.10
Mike
^ permalink raw reply
* [PATCH] xenstored: Fix processing of zero-length messages
From: Daniel De Graaf @ 2011-10-31 18:38 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
When a message with zero length is sent to xenstore, the body of the
message was not processed until the socket or ring had more data to
read; this will cause deadlocks if the requestor is waiting on a
response to continue.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
tools/xenstore/xenstored_core.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 5d308ca..9e6c2c7 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1297,7 +1297,6 @@ static void handle_input(struct connection *conn)
goto bad_client;
in->used = 0;
in->inhdr = false;
- return;
}
bytes = conn->read(conn, in->buffer + in->used,
--
1.7.6.4
^ permalink raw reply related
* Re: [4/4] powerpc/booke: Re-organize debug code
From: Jimi Xenidis @ 2011-10-31 18:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <137546DC-1F2C-4623-B96F-5F9FFB9498F9@kernel.crashing.org>
On Oct 31, 2011, at 9:21 AM, Kumar Gala wrote:
>=20
> On Oct 28, 2011, at 2:37 PM, Jimi Xenidis wrote:
>=20
>>=20
>> On Oct 5, 2011, at 9:53 PM, Kumar Gala wrote:
>>=20
>>> * set_dabr/do_dabr are no longer used when CNFIG_PPC_ADV_DEBUG_REGS =
is set
>>> refactor code a bit such that we only build the dabr code for
>>> !CONFIG_PPC_ADV_DEBUG_REGS and removed some =
CONFIG_PPC_ADV_DEBUG_REGS
>>> code in set_dabr that would never get built.
>>>=20
>>> * Move do_send_trap into traps.c as its only used there
>>>=20
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>=20
>>> ---
>>> arch/powerpc/include/asm/system.h | 5 +--
>>> arch/powerpc/kernel/process.c | 97 =
+++++++++++++-----------------------
>>> arch/powerpc/kernel/traps.c | 17 +++++++
>>> 3 files changed, 53 insertions(+), 66 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/include/asm/system.h =
b/arch/powerpc/include/asm/system.h
>>> index e30a13d..1dc5d9c 100644
>>> --- a/arch/powerpc/include/asm/system.h
>>> +++ b/arch/powerpc/include/asm/system.h
>>> @@ -111,11 +111,8 @@ static inline int debugger_dabr_match(struct =
pt_regs *regs) { return 0; }
>>> static inline int debugger_fault_handler(struct pt_regs *regs) { =
return 0; }
>>> #endif
>>>=20
>>> +#ifndef CONFIG_PPC_ADV_DEBUG_REGS
>>> extern int set_dabr(unsigned long dabr);
>>> -#ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>> -extern void do_send_trap(struct pt_regs *regs, unsigned long =
address,
>>> - unsigned long error_code, int signal_code, int =
brkpt);
>>> -#else
>>=20
>>=20
>> This part of the patch breaks xmon.c
>> Naively I simply wrapped the xmon call:
>>=20
>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>> index f08836a..b5911b2 100644
>> --- a/arch/powerpc/xmon/xmon.c
>> +++ b/arch/powerpc/xmon/xmon.c
>> @@ -738,8 +738,10 @@ static void insert_bpts(void)
>>=20
>> static void insert_cpu_bpts(void)
>> {
>> +#ifndef CONFIG_PPC_ADV_DEBUG_REGS
>> if (dabr.enabled)
>> set_dabr(dabr.address | (dabr.enabled & 7));
>> +#endif
>> if (iabr && cpu_has_feature(CPU_FTR_IABR))
>> mtspr(SPRN_IABR, iabr->address
>> | (iabr->enabled & (BP_IABR|BP_IABR_TE)));
>> @@ -767,7 +769,9 @@ static void remove_bpts(void)
>>=20
>> static void remove_cpu_bpts(void)
>> {
>> +#ifndef CONFIG_PPC_ADV_DEBUG_REGS
>> set_dabr(0);
>> +#endif
>> if (cpu_has_feature(CPU_FTR_IABR))
>> mtspr(SPRN_IABR, 0);
>> }
>=20
> Shouldn't all of these functions be #ifndef'd out as we don't support =
cpu_bpts on book-e parts in xmon code today?
Well I guess this is one for benh, because I would have expected xmon to =
test and call ppc_md.dabr.
Actually, should everyone be doing that?
-jx
>=20
>>=20
>> -JX
>>=20
>>=20
>>> extern void do_dabr(struct pt_regs *regs, unsigned long address,
>>> unsigned long error_code);
>>> #endif
>>> diff --git a/arch/powerpc/kernel/process.c =
b/arch/powerpc/kernel/process.c
>>> index 269a309..989e574 100644
>>> --- a/arch/powerpc/kernel/process.c
>>> +++ b/arch/powerpc/kernel/process.c
>>> @@ -251,50 +251,6 @@ void discard_lazy_cpu_state(void)
>>> #endif /* CONFIG_SMP */
>>>=20
>>> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>> -void do_send_trap(struct pt_regs *regs, unsigned long address,
>>> - unsigned long error_code, int signal_code, int =
breakpt)
>>> -{
>>> - siginfo_t info;
>>> -
>>> - if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
>>> - 11, SIGSEGV) =3D=3D NOTIFY_STOP)
>>> - return;
>>> -
>>> - /* Deliver the signal to userspace */
>>> - info.si_signo =3D SIGTRAP;
>>> - info.si_errno =3D breakpt; /* breakpoint or watchpoint id =
*/
>>> - info.si_code =3D signal_code;
>>> - info.si_addr =3D (void __user *)address;
>>> - force_sig_info(SIGTRAP, &info, current);
>>> -}
>>> -#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
>>> -void do_dabr(struct pt_regs *regs, unsigned long address,
>>> - unsigned long error_code)
>>> -{
>>> - siginfo_t info;
>>> -
>>> - if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
>>> - 11, SIGSEGV) =3D=3D NOTIFY_STOP)
>>> - return;
>>> -
>>> - if (debugger_dabr_match(regs))
>>> - return;
>>> -
>>> - /* Clear the DABR */
>>> - set_dabr(0);
>>> -
>>> - /* Deliver the signal to userspace */
>>> - info.si_signo =3D SIGTRAP;
>>> - info.si_errno =3D 0;
>>> - info.si_code =3D TRAP_HWBKPT;
>>> - info.si_addr =3D (void __user *)address;
>>> - force_sig_info(SIGTRAP, &info, current);
>>> -}
>>> -#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
>>> -
>>> -static DEFINE_PER_CPU(unsigned long, current_dabr);
>>> -
>>> -#ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>> /*
>>> * Set the debug registers back to their default "safe" values.
>>> */
>>> @@ -357,16 +313,7 @@ static void switch_booke_debug_regs(struct =
thread_struct *new_thread)
>>> prime_debug_regs(new_thread);
>>> }
>>> #else /* !CONFIG_PPC_ADV_DEBUG_REGS */
>>> -#ifndef CONFIG_HAVE_HW_BREAKPOINT
>>> -static void set_debug_reg_defaults(struct thread_struct *thread)
>>> -{
>>> - if (thread->dabr) {
>>> - thread->dabr =3D 0;
>>> - set_dabr(0);
>>> - }
>>> -}
>>> -#endif /* !CONFIG_HAVE_HW_BREAKPOINT */
>>> -#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
>>> +static DEFINE_PER_CPU(unsigned long, current_dabr);
>>>=20
>>> int set_dabr(unsigned long dabr)
>>> {
>>> @@ -376,19 +323,45 @@ int set_dabr(unsigned long dabr)
>>> return ppc_md.set_dabr(dabr);
>>>=20
>>> /* XXX should we have a CPU_FTR_HAS_DABR ? */
>>> -#ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>> - mtspr(SPRN_DAC1, dabr);
>>> -#ifdef CONFIG_PPC_47x
>>> - isync();
>>> -#endif
>>> -#elif defined(CONFIG_PPC_BOOK3S)
>>> mtspr(SPRN_DABR, dabr);
>>> -#endif
>>> -
>>>=20
>>> return 0;
>>> }
>>>=20
>>> +void do_dabr(struct pt_regs *regs, unsigned long address,
>>> + unsigned long error_code)
>>> +{
>>> + siginfo_t info;
>>> +
>>> + if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
>>> + 11, SIGSEGV) =3D=3D NOTIFY_STOP)
>>> + return;
>>> +
>>> + if (debugger_dabr_match(regs))
>>> + return;
>>> +
>>> + /* Clear the DABR */
>>> + set_dabr(0);
>>> +
>>> + /* Deliver the signal to userspace */
>>> + info.si_signo =3D SIGTRAP;
>>> + info.si_errno =3D 0;
>>> + info.si_code =3D TRAP_HWBKPT;
>>> + info.si_addr =3D (void __user *)address;
>>> + force_sig_info(SIGTRAP, &info, current);
>>> +}
>>> +
>>> +#ifndef CONFIG_HAVE_HW_BREAKPOINT
>>> +static void set_debug_reg_defaults(struct thread_struct *thread)
>>> +{
>>> + if (thread->dabr) {
>>> + thread->dabr =3D 0;
>>> + set_dabr(0);
>>> + }
>>> +}
>>> +#endif /* !CONFIG_HAVE_HW_BREAKPOINT */
>>> +#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
>>> +
>>> #ifdef CONFIG_PPC64
>>> DEFINE_PER_CPU(struct cpu_usage, cpu_usage_array);
>>> #endif
>>> diff --git a/arch/powerpc/kernel/traps.c =
b/arch/powerpc/kernel/traps.c
>>> index db733d3..edc1108 100644
>>> --- a/arch/powerpc/kernel/traps.c
>>> +++ b/arch/powerpc/kernel/traps.c
>>> @@ -1184,6 +1184,23 @@ void SoftwareEmulation(struct pt_regs *regs)
>>> #endif /* CONFIG_8xx */
>>>=20
>>> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>> +static void do_send_trap(struct pt_regs *regs, unsigned long =
address,
>>> + unsigned long error_code, int signal_code, int =
breakpt)
>>> +{
>>> + siginfo_t info;
>>> +
>>> + if (notify_die(DIE_DABR_MATCH, "dabr_match", regs, error_code,
>>> + 11, SIGSEGV) =3D=3D NOTIFY_STOP)
>>> + return;
>>> +
>>> + /* Deliver the signal to userspace */
>>> + info.si_signo =3D SIGTRAP;
>>> + info.si_errno =3D breakpt; /* breakpoint or watchpoint id =
*/
>>> + info.si_code =3D signal_code;
>>> + info.si_addr =3D (void __user *)address;
>>> + force_sig_info(SIGTRAP, &info, current);
>>> +}
>>> +
>>> static void handle_debug(struct pt_regs *regs, unsigned long =
debug_status)
>>> {
>>> int changed =3D 0;
>=20
^ permalink raw reply
* [Qemu-devel] [PATCH v3 4/4] Add support for net bridge
From: Corey Bryant @ 2011-10-31 18:36 UTC (permalink / raw)
To: qemu-devel; +Cc: aliguori, rmarwah
In-Reply-To: <1320086191-23641-1-git-send-email-coreyb@linux.vnet.ibm.com>
The most common use of -net tap is to connect a tap device to a bridge. This
requires the use of a script and running qemu as root in order to allocate a
tap device to pass to the script.
This model is great for portability and flexibility but it's incredibly
difficult to eliminate the need to run qemu as root. The only really viable
mechanism is to use tunctl to create a tap device, attach it to a bridge as
root, and then hand that tap device to qemu. The problem with this mechanism
is that it requires administrator intervention whenever a user wants to create
a guest.
By essentially writing a helper that implements the most common qemu-ifup
script that can be safely given cap_net_admin, we can dramatically simplify
things for non-privileged users. We still support existing -net tap options
as a mechanism for advanced users and backwards compatibility.
Currently, this is very Linux centric but there's really no reason why it
couldn't be extended for other Unixes.
A typical invocation would be:
qemu linux.img -net bridge -net nic,model=virtio
or:
qemu linux.img -net tap,helper=/usr/local/libexec/qemu-bridge-helper
-net nic,model=virtio
The default bridge that we attach to is br0. The thinking is that a distro
could preconfigure such an interface to allow out-of-the-box bridged networking.
Alternatively, if a user wants to use a different bridge, they can say:
qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio
or:
qemu linux.img -net tap,helper=/usr/local/libexec/qemu-bridge-helper,br=qemubr0
-net nic,model=virtio
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
---
configure | 2 +
net.c | 29 ++++++++-
net.h | 3 +
net/tap.c | 190 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
net/tap.h | 3 +
qemu-options.hx | 73 +++++++++++++++++----
6 files changed, 279 insertions(+), 21 deletions(-)
diff --git a/configure b/configure
index 4e49b4b..7a5240b 100755
--- a/configure
+++ b/configure
@@ -2827,6 +2827,8 @@ echo "sysconfdir=$sysconfdir" >> $config_host_mak
echo "docdir=$docdir" >> $config_host_mak
echo "confdir=$confdir" >> $config_host_mak
echo "libexecdir=\${prefix}/libexec" >> $config_host_mak
+echo "CONFIG_QEMU_SHAREDIR=\"$prefix$datasuffix\"" >> $config_host_mak
+echo "CONFIG_QEMU_HELPERDIR=\"$prefix/libexec\"" >> $config_host_mak
case "$cpu" in
i386|x86_64|alpha|cris|hppa|ia64|lm32|m68k|microblaze|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64|unicore32)
diff --git a/net.c b/net.c
index d05930c..2dcb2d4 100644
--- a/net.c
+++ b/net.c
@@ -956,6 +956,14 @@ static const struct {
.type = QEMU_OPT_STRING,
.help = "script to shut down the interface",
}, {
+ .name = "br",
+ .type = QEMU_OPT_STRING,
+ .help = "bridge name",
+ }, {
+ .name = "helper",
+ .type = QEMU_OPT_STRING,
+ .help = "command to execute to configure bridge",
+ }, {
.name = "sndbuf",
.type = QEMU_OPT_SIZE,
.help = "send buffer limit"
@@ -1053,6 +1061,23 @@ static const struct {
{ /* end of list */ }
},
},
+ [NET_CLIENT_TYPE_BRIDGE] = {
+ .type = "bridge",
+ .init = net_init_bridge,
+ .desc = {
+ NET_COMMON_PARAMS_DESC,
+ {
+ .name = "br",
+ .type = QEMU_OPT_STRING,
+ .help = "bridge name",
+ }, {
+ .name = "helper",
+ .type = QEMU_OPT_STRING,
+ .help = "command to execute to configure bridge",
+ },
+ { /* end of list */ }
+ },
+ },
};
int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
@@ -1075,7 +1100,8 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
#ifdef CONFIG_VDE
strcmp(type, "vde") != 0 &&
#endif
- strcmp(type, "socket") != 0) {
+ strcmp(type, "socket") != 0 &&
+ strcmp(type, "bridge") != 0) {
qerror_report(QERR_INVALID_PARAMETER_VALUE, "type",
"a netdev backend type");
return -1;
@@ -1145,6 +1171,7 @@ static int net_host_check_device(const char *device)
#ifdef CONFIG_VDE
,"vde"
#endif
+ , "bridge"
};
for (i = 0; i < sizeof(valid_param_list) / sizeof(char *); i++) {
if (!strncmp(valid_param_list[i], device,
diff --git a/net.h b/net.h
index 9f633f8..d1340ad 100644
--- a/net.h
+++ b/net.h
@@ -36,6 +36,7 @@ typedef enum {
NET_CLIENT_TYPE_SOCKET,
NET_CLIENT_TYPE_VDE,
NET_CLIENT_TYPE_DUMP,
+ NET_CLIENT_TYPE_BRIDGE,
NET_CLIENT_TYPE_MAX
} net_client_type;
@@ -174,6 +175,8 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data);
#define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
#define DEFAULT_NETWORK_DOWN_SCRIPT "/etc/qemu-ifdown"
+#define DEFAULT_BRIDGE_HELPER CONFIG_QEMU_HELPERDIR "/qemu-bridge-helper"
+#define DEFAULT_BRIDGE_INTERFACE "br0"
void qdev_set_nic_properties(DeviceState *dev, NICInfo *nd);
diff --git a/net/tap.c b/net/tap.c
index 1f26dc9..be9be27 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -388,6 +388,143 @@ static int launch_script(const char *setup_script, const char *ifname, int fd)
return -1;
}
+static int recv_fd(int c)
+{
+ int fd;
+ uint8_t msgbuf[CMSG_SPACE(sizeof(fd))];
+ struct msghdr msg = {
+ .msg_control = msgbuf,
+ .msg_controllen = sizeof(msgbuf),
+ };
+ struct cmsghdr *cmsg;
+ struct iovec iov;
+ uint8_t req[1];
+ ssize_t len;
+
+ cmsg = CMSG_FIRSTHDR(&msg);
+ cmsg->cmsg_level = SOL_SOCKET;
+ cmsg->cmsg_type = SCM_RIGHTS;
+ cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
+ msg.msg_controllen = cmsg->cmsg_len;
+
+ iov.iov_base = req;
+ iov.iov_len = sizeof(req);
+
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+
+ len = recvmsg(c, &msg, 0);
+ if (len > 0) {
+ memcpy(&fd, CMSG_DATA(cmsg), sizeof(fd));
+ return fd;
+ }
+
+ return len;
+}
+
+static int net_bridge_run_helper(const char *helper, const char *bridge)
+{
+ sigset_t oldmask, mask;
+ int pid, status;
+ char *args[5];
+ char **parg;
+ int sv[2];
+
+ sigemptyset(&mask);
+ sigaddset(&mask, SIGCHLD);
+ sigprocmask(SIG_BLOCK, &mask, &oldmask);
+
+ if (socketpair(PF_UNIX, SOCK_STREAM, 0, sv) == -1) {
+ return -1;
+ }
+
+ /* try to launch bridge helper */
+ pid = fork();
+ if (pid == 0) {
+ int open_max = sysconf(_SC_OPEN_MAX), i;
+ char buf[32];
+
+ snprintf(buf, sizeof(buf), "%d", sv[1]);
+
+ for (i = 0; i < open_max; i++) {
+ if (i != STDIN_FILENO &&
+ i != STDOUT_FILENO &&
+ i != STDERR_FILENO &&
+ i != sv[1]) {
+ close(i);
+ }
+ }
+ parg = args;
+ *parg++ = (char *)helper;
+ *parg++ = (char *)"--use-vnet";
+ *parg++ = (char *)bridge;
+ *parg++ = buf;
+ *parg++ = NULL;
+ execv(helper, args);
+ _exit(1);
+ } else if (pid > 0) {
+ int fd;
+
+ close(sv[1]);
+
+ do {
+ fd = recv_fd(sv[0]);
+ } while (fd == -1 && errno == EINTR);
+
+ close(sv[0]);
+
+ while (waitpid(pid, &status, 0) != pid) {
+ /* loop */
+ }
+ sigprocmask(SIG_SETMASK, &oldmask, NULL);
+ if (fd < 0) {
+ fprintf(stderr, "failed to recv file descriptor\n");
+ return -1;
+ }
+
+ if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
+ return fd;
+ }
+ }
+ fprintf(stderr, "failed to launch bridge helper\n");
+ return -1;
+}
+
+int net_init_bridge(QemuOpts *opts, Monitor *mon, const char *name,
+ VLANState *vlan)
+{
+ TAPState *s;
+ int fd, vnet_hdr;
+
+ if (!qemu_opt_get(opts, "br")) {
+ qemu_opt_set(opts, "br", DEFAULT_BRIDGE_INTERFACE);
+ }
+ if (!qemu_opt_get(opts, "helper")) {
+ qemu_opt_set(opts, "helper", DEFAULT_BRIDGE_HELPER);
+ }
+
+ fd = net_bridge_run_helper(qemu_opt_get(opts, "helper"),
+ qemu_opt_get(opts, "br"));
+ if (fd == -1) {
+ return -1;
+ }
+
+ fcntl(fd, F_SETFL, O_NONBLOCK);
+
+ vnet_hdr = tap_probe_vnet_hdr(fd);
+
+ s = net_tap_fd_init(vlan, "bridge", name, fd, vnet_hdr);
+ if (!s) {
+ close(fd);
+ return -1;
+ }
+
+ snprintf(s->nc.info_str, sizeof(s->nc.info_str),
+ "br=%s", qemu_opt_get(opts, "br"));
+
+ return 0;
+}
+
static int net_tap_init(QemuOpts *opts, int *vnet_hdr)
{
int fd, vnet_hdr_required;
@@ -433,8 +570,11 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
if (qemu_opt_get(opts, "ifname") ||
qemu_opt_get(opts, "script") ||
qemu_opt_get(opts, "downscript") ||
- qemu_opt_get(opts, "vnet_hdr")) {
- error_report("ifname=, script=, downscript= and vnet_hdr= is invalid with fd=");
+ qemu_opt_get(opts, "vnet_hdr") ||
+ qemu_opt_get(opts, "br") ||
+ qemu_opt_get(opts, "helper")) {
+ error_report("ifname=, script=, downscript=, vnet_hdr=,"
+ "br= and helper= are invalid with fd=");
return -1;
}
@@ -446,7 +586,40 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
fcntl(fd, F_SETFL, O_NONBLOCK);
vnet_hdr = tap_probe_vnet_hdr(fd);
+ } else if (qemu_opt_get(opts, "helper")) {
+ if (qemu_opt_get(opts, "ifname") ||
+ qemu_opt_get(opts, "script") ||
+ qemu_opt_get(opts, "downscript")) {
+ error_report("ifname=, script= and downscript="
+ "are invalid with helper=");
+ return -1;
+ }
+
+ if (!qemu_opt_get(opts, "br")) {
+ qemu_opt_set(opts, "br", DEFAULT_BRIDGE_INTERFACE);
+ }
+
+ fd = net_bridge_run_helper(qemu_opt_get(opts, "helper"),
+ qemu_opt_get(opts, "br"));
+ if (fd == -1) {
+ return -1;
+ }
+
+ fcntl(fd, F_SETFL, O_NONBLOCK);
+
+ vnet_hdr = tap_probe_vnet_hdr(fd);
+
+ s = net_tap_fd_init(vlan, "bridge", name, fd, vnet_hdr);
+ if (!s) {
+ close(fd);
+ return -1;
+ }
} else {
+ if (qemu_opt_get(opts, "br")) {
+ error_report("br= is invalid with script=");
+ return -1;
+ }
+
if (!qemu_opt_get(opts, "script")) {
qemu_opt_set(opts, "script", DEFAULT_NETWORK_SCRIPT);
}
@@ -459,12 +632,12 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
if (fd == -1) {
return -1;
}
- }
- s = net_tap_fd_init(vlan, "tap", name, fd, vnet_hdr);
- if (!s) {
- close(fd);
- return -1;
+ s = net_tap_fd_init(vlan, "tap", name, fd, vnet_hdr);
+ if (!s) {
+ close(fd);
+ return -1;
+ }
}
if (tap_set_sndbuf(s->fd, opts) < 0) {
@@ -473,6 +646,9 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
if (qemu_opt_get(opts, "fd")) {
snprintf(s->nc.info_str, sizeof(s->nc.info_str), "fd=%d", fd);
+ } else if (qemu_opt_get(opts, "helper")) {
+ snprintf(s->nc.info_str, sizeof(s->nc.info_str),
+ "br=%s", qemu_opt_get(opts, "br"));
} else {
const char *ifname, *script, *downscript;
diff --git a/net/tap.h b/net/tap.h
index e44bd2b..56c591f 100644
--- a/net/tap.h
+++ b/net/tap.h
@@ -57,4 +57,7 @@ int tap_get_fd(VLANClientState *vc);
struct vhost_net;
struct vhost_net *tap_get_vhost_net(VLANClientState *vc);
+int net_init_bridge(QemuOpts *opts, Monitor *mon, const char *name,
+ VLANState *vlan);
+
#endif /* QEMU_NET_TAP_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..4899c20 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1197,11 +1197,14 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
"-net tap[,vlan=n][,name=str],ifname=name\n"
" connect the host TAP network interface to VLAN 'n'\n"
#else
- "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]\n"
- " connect the host TAP network interface to VLAN 'n' and use the\n"
- " network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
- " and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
+ "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]\n"
+ " connect the host TAP network interface to VLAN 'n' \n"
+ " use network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
+ " to configure it and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
+ " to deconfigure it\n"
" use '[down]script=no' to disable script execution\n"
+ " use network helper 'helper' (default=" DEFAULT_BRIDGE_HELPER ") and\n"
+ " bridge 'br' (default=" DEFAULT_BRIDGE_INTERFACE ") to configure it\n"
" use 'fd=h' to connect to an already opened TAP interface\n"
" use 'sndbuf=nbytes' to limit the size of the send buffer (the\n"
" default is disabled 'sndbuf=0' to enable flow control set 'sndbuf=1048576')\n"
@@ -1211,6 +1214,10 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
" (only has effect for virtio guests which use MSIX)\n"
" use vhostforce=on to force vhost on for non-MSIX virtio guests\n"
" use 'vhostfd=h' to connect to an already opened vhost net device\n"
+ "-net bridge[,vlan=n][,name=str][,br=bridge][,helper=helper]\n"
+ " connects a host TAP network interface to a host bridge device 'br'\n"
+ " (default=" DEFAULT_BRIDGE_INTERFACE ") using the program 'helper'\n"
+ " (default=" DEFAULT_BRIDGE_HELPER ")\n"
#endif
"-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]\n"
" connect the vlan 'n' to another VLAN using a socket connection\n"
@@ -1370,26 +1377,66 @@ processed and applied to -net user. Mixing them with the new configuration
syntax gives undefined results. Their use for new applications is discouraged
as they will be removed from future versions.
-@item -net tap[,vlan=@var{n}][,name=@var{name}][,fd=@var{h}][,ifname=@var{name}] [,script=@var{file}][,downscript=@var{dfile}]
-Connect the host TAP network interface @var{name} to VLAN @var{n}, use
-the network script @var{file} to configure it and the network script
+@item -net tap[,vlan=@var{n}][,name=@var{name}][,fd=@var{h}][,ifname=@var{name}][,script=@var{file}][,downscript=@var{dfile}][,br=@var{bridge}][,helper=@var{helper}]
+Connect the host TAP network interface @var{name} to VLAN @var{n}.
+
+Use the network script @var{file} to configure it and the network script
@var{dfile} to deconfigure it. If @var{name} is not provided, the OS
-automatically provides one. @option{fd}=@var{h} can be used to specify
-the handle of an already opened host TAP interface. The default network
-configure script is @file{/etc/qemu-ifup} and the default network
-deconfigure script is @file{/etc/qemu-ifdown}. Use @option{script=no}
-or @option{downscript=no} to disable script execution. Example:
+automatically provides one. The default network configure script is
+@file{/etc/qemu-ifup} and the default network deconfigure script is
+@file{/etc/qemu-ifdown}. Use @option{script=no} or @option{downscript=no}
+to disable script execution.
+
+If running QEMU as an unprivileged user, use the network helper
+@var{helper} to configure the TAP interface. The default network
+helper executable is @file{/usr/local/libexec/qemu-bridge-helper}
+and the default bridge device is @file{br0}.
+
+@option{fd}=@var{h} can be used to specify the handle of an already
+opened host TAP interface.
+
+Examples:
@example
+#launch a QEMU instance with the default network script
qemu linux.img -net nic -net tap
@end example
-More complicated example (two NICs, each one connected to a TAP device)
@example
+#launch a QEMU instance with two NICs, each one connected
+#to a TAP device
qemu linux.img -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 \
-net nic,vlan=1 -net tap,vlan=1,ifname=tap1
@end example
+@example
+#launch a QEMU instance with the default network helper to
+#connect a TAP device to bridge br0
+qemu linux.img -net nic -net tap,helper=/usr/local/libexec/qemu-bridge-helper
+@end example
+
+@item -net bridge[,vlan=@var{n}][,name=@var{name}][,br=@var{bridge}][,helper=@var{helper}]
+Connect a host TAP network interface to a host bridge device.
+
+Use the network helper @var{helper} to configure the TAP interface and
+attach it to the bridge. The default network helper executable is
+@file{/usr/local/libexec/qemu-bridge-helper} and the default bridge
+device is @file{br0}.
+
+Examples:
+
+@example
+#launch a QEMU instance with the default network helper to
+#connect a TAP device to bridge br0
+qemu linux.img -net bridge -net nic,model=virtio
+@end example
+
+@example
+#launch a QEMU instance with the default network helper to
+#connect a TAP device to bridge qemubr0
+qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio
+@end example
+
@item -net socket[,vlan=@var{n}][,name=@var{name}][,fd=@var{h}] [,listen=[@var{host}]:@var{port}][,connect=@var{host}:@var{port}]
Connect the VLAN @var{n} to a remote VLAN in another QEMU virtual
--
1.7.3.4
^ permalink raw reply related
* [Qemu-devel] [PATCH v3 2/4] Add access control support to qemu bridge helper
From: Corey Bryant @ 2011-10-31 18:36 UTC (permalink / raw)
To: qemu-devel; +Cc: aliguori, rmarwah
In-Reply-To: <1320086191-23641-1-git-send-email-coreyb@linux.vnet.ibm.com>
We go to great lengths to restrict ourselves to just cap_net_admin as an OS
enforced security mechanism. However, we further restrict what we allow users
to do to simply adding a tap device to a bridge interface by virtue of the fact
that this is the only functionality we expose.
This is not good enough though. An administrator is likely to want to restrict
the bridges that an unprivileged user can access, in particular, to restrict
an unprivileged user from putting a guest on what should be isolated networks.
This patch implements an ACL mechanism that is enforced by qemu-bridge-helper.
The ACLs are fairly simple whitelist/blacklist mechanisms with a wildcard of
'all'. All users are blacklisted by default, and deny takes precedence over
allow.
An interesting feature of this ACL mechanism is that you can include external
ACL files. The main reason to support this is so that you can set different
file system permissions on those external ACL files. This allows an
administrator to implement rather sophisticated ACL policies based on
user/group policies via the file system.
As an example:
/etc/qemu/bridge.conf root:qemu 0640
allow br0
include /etc/qemu/alice.conf
include /etc/qemu/bob.conf
include /etc/qemu/charlie.conf
/etc/qemu/alice.conf root:alice 0640
allow br1
/etc/qemu/bob.conf root:bob 0640
allow br2
/etc/qemu/charlie.conf root:charlie 0640
deny all
This ACL pattern allows any user in the qemu group to get a tap device
connected to br0 (which is bridged to the physical network).
Users in the alice group can additionally get a tap device connected to br1.
This allows br1 to act as a private bridge for the alice group.
Users in the bob group can additionally get a tap device connected to br2.
This allows br2 to act as a private bridge for the bob group.
Users in the charlie group cannot get a tap device connected to any bridge.
Under no circumstance can the bob group get access to br1 or can the alice
group get access to br2. And under no cicumstance can the charlie group
get access to any bridge.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
---
qemu-bridge-helper.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 153 insertions(+), 0 deletions(-)
diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
index 803681d..4deead7 100644
--- a/qemu-bridge-helper.c
+++ b/qemu-bridge-helper.c
@@ -20,6 +20,7 @@
#include <string.h>
#include <stdlib.h>
#include <ctype.h>
+#include <glib.h>
#include <sys/types.h>
#include <sys/ioctl.h>
@@ -31,8 +32,110 @@
#include <linux/sockios.h>
+#include "qemu-queue.h"
+
#include "net/tap-linux.h"
+#define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
+
+enum {
+ ACL_ALLOW = 0,
+ ACL_ALLOW_ALL,
+ ACL_DENY,
+ ACL_DENY_ALL,
+};
+
+typedef struct ACLRule {
+ int type;
+ char iface[IFNAMSIZ];
+ QSIMPLEQ_ENTRY(ACLRule) entry;
+} ACLRule;
+
+typedef QSIMPLEQ_HEAD(ACLList, ACLRule) ACLList;
+
+static int parse_acl_file(const char *filename, ACLList *acl_list)
+{
+ FILE *f;
+ char line[4096];
+ ACLRule *acl_rule;
+
+ f = fopen(filename, "r");
+ if (f == NULL) {
+ return -1;
+ }
+
+ while (fgets(line, sizeof(line), f) != NULL) {
+ char *ptr = line;
+ char *cmd, *arg, *argend;
+
+ while (isspace(*ptr)) {
+ ptr++;
+ }
+
+ /* skip comments and empty lines */
+ if (*ptr == '#' || *ptr == 0) {
+ continue;
+ }
+
+ cmd = ptr;
+ arg = strchr(cmd, ' ');
+ if (arg == NULL) {
+ arg = strchr(cmd, '\t');
+ }
+
+ if (arg == NULL) {
+ fprintf(stderr, "Invalid config line:\n %s\n", line);
+ fclose(f);
+ errno = EINVAL;
+ return -1;
+ }
+
+ *arg = 0;
+ arg++;
+ while (isspace(*arg)) {
+ arg++;
+ }
+
+ argend = arg + strlen(arg);
+ while (arg != argend && isspace(*(argend - 1))) {
+ argend--;
+ }
+ *argend = 0;
+
+ if (strcmp(cmd, "deny") == 0) {
+ acl_rule = g_malloc(sizeof(*acl_rule));
+ if (strcmp(arg, "all") == 0) {
+ acl_rule->type = ACL_DENY_ALL;
+ } else {
+ acl_rule->type = ACL_DENY;
+ snprintf(acl_rule->iface, IFNAMSIZ, "%s", arg);
+ }
+ QSIMPLEQ_INSERT_TAIL(acl_list, acl_rule, entry);
+ } else if (strcmp(cmd, "allow") == 0) {
+ acl_rule = g_malloc(sizeof(*acl_rule));
+ if (strcmp(arg, "all") == 0) {
+ acl_rule->type = ACL_ALLOW_ALL;
+ } else {
+ acl_rule->type = ACL_ALLOW;
+ snprintf(acl_rule->iface, IFNAMSIZ, "%s", arg);
+ }
+ QSIMPLEQ_INSERT_TAIL(acl_list, acl_rule, entry);
+ } else if (strcmp(cmd, "include") == 0) {
+ /* ignore errors */
+ parse_acl_file(arg, acl_list);
+ } else {
+ fprintf(stderr, "Unknown command `%s'\n", cmd);
+ fclose(f);
+ errno = EINVAL;
+ return -1;
+ }
+ }
+
+ fclose(f);
+
+ return 0;
+}
+
static int has_vnet_hdr(int fd)
{
unsigned int features = 0;
@@ -95,6 +198,9 @@ int main(int argc, char **argv)
const char *bridge;
char iface[IFNAMSIZ];
int index;
+ ACLRule *acl_rule;
+ ACLList acl_list;
+ int access_allowed, access_denied;
int ret = 0;
/* parse arguments */
@@ -116,6 +222,48 @@ int main(int argc, char **argv)
bridge = argv[index++];
unixfd = atoi(argv[index++]);
+ /* parse default acl file */
+ QSIMPLEQ_INIT(&acl_list);
+ if (parse_acl_file(DEFAULT_ACL_FILE, &acl_list) == -1) {
+ fprintf(stderr, "failed to parse default acl file `%s'\n",
+ DEFAULT_ACL_FILE);
+ ret = -errno;
+ goto cleanup;
+ }
+
+ /* validate bridge against acl -- default policy is to deny
+ * according acl policy if we have a deny and allow both
+ * then deny should always win over allow
+ */
+ access_allowed = 0;
+ access_denied = 0;
+ QSIMPLEQ_FOREACH(acl_rule, &acl_list, entry) {
+ switch (acl_rule->type) {
+ case ACL_ALLOW_ALL:
+ access_allowed = 1;
+ break;
+ case ACL_ALLOW:
+ if (strcmp(bridge, acl_rule->iface) == 0) {
+ access_allowed = 1;
+ }
+ break;
+ case ACL_DENY_ALL:
+ access_denied = 1;
+ break;
+ case ACL_DENY:
+ if (strcmp(bridge, acl_rule->iface) == 0) {
+ access_denied = 1;
+ }
+ break;
+ }
+ }
+
+ if ((access_allowed == 0) || (access_denied == 1)) {
+ fprintf(stderr, "access denied by acl file\n");
+ ret = -EPERM;
+ goto cleanup;
+ }
+
/* open a socket to use to control the network interfaces */
ctlfd = socket(AF_INET, SOCK_STREAM, 0);
if (ctlfd == -1) {
@@ -213,5 +361,10 @@ cleanup:
close(ctlfd);
+ while ((acl_rule = QSIMPLEQ_FIRST(&acl_list)) != NULL) {
+ QSIMPLEQ_REMOVE_HEAD(&acl_list, entry);
+ g_free(acl_rule);
+ }
+
return ret;
}
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Marek Vasut @ 2011-10-31 18:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319464779-23571-1-git-send-email-swarren@nvidia.com>
> The legacy uImage format includes an absolute load and entry-
> point address. When presented with a uImage in memory that
> isn't loaded at the address in the image's load address,
> U-Boot will relocate the image to its address in the header.
>
> Some payloads can actually be loaded and used at any arbitrary
> address. An example is an ARM Linux kernel zImage file. This
> is useful when sharing a single zImage across multiple boards
> with different memory layouts, or U-Boot builds with different
> ${load_addr} since sharing a single absolute load address may
> not be possible.
>
> With this config option enabled, an image header may contain a
> load address of -1/0xffffffff. This indicates the image can
> operate at any load address, and U-Boot will avoid automtically
> copying it anywhere. In this case, the entry-point field is
> specified relative to the start of the image payload.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Wolfgang,
>
> This is an much simpler and less invasive alternative to my previous
> IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
>
> u-boot.bin sizes for Tegra Seaboard without/with this config option on:
>
> text data bss dec hex filename
> 165858 3565 217016 386439 5e587 ./u-boot
>
> with:
>
> text data bss dec hex filename
> 165950 3565 217012 386527 5e5df ./u-boot
>
[...]
This one doesn't apply on top of current u-boot master
^ permalink raw reply
* Re: [1/4] powerpc: Revert show_regs() define for readability
From: Jimi Xenidis @ 2011-10-31 18:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev list
In-Reply-To: <F8FBC967-70A0-47F4-9BB8-3E16CCEC6565@kernel.crashing.org>
On Oct 31, 2011, at 9:18 AM, Kumar Gala wrote:
>=20
> On Oct 28, 2011, at 2:40 PM, Jimi Xenidis wrote:
>=20
>>=20
>> On Oct 5, 2011, at 9:53 PM, Kumar Gala wrote:
>>=20
>>> We had an existing ifdef for 4xx & BOOKE processors that got changed =
to
>>> CONFIG_PPC_ADV_DEBUG_REGS. The define has nothing to do with
>>> CONFIG_PPC_ADV_DEBUG_REGS. The define really should be:
>>>=20
>>> #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
>>>=20
>>> and not
>>>=20
>>> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>>=20
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>=20
>>> ---
>>> arch/powerpc/kernel/process.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/kernel/process.c =
b/arch/powerpc/kernel/process.c
>>> index 8f53954..a1b5981 100644
>>> --- a/arch/powerpc/kernel/process.c
>>> +++ b/arch/powerpc/kernel/process.c
>>> @@ -657,7 +657,7 @@ void show_regs(struct pt_regs * regs)
>>> if ((regs->trap !=3D 0xc00) && cpu_has_feature(CPU_FTR_CFAR))
>>> printk("CFAR: "REG"\n", regs->orig_gpr3);
>>> if (trap =3D=3D 0x300 || trap =3D=3D 0x600)
>>> -#ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>> +#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
>>> printk("DEAR: "REG", ESR: "REG"\n", regs->dar, =
regs->dsisr);
>>=20
>> I'll be needing "|| defined(CONFIG_PPC_BOOK3E)" added to this please.
>> -jx
>=20
> Under what platform is CONFIG_PPC_BOOK3E set and CONFIG_BOOKE is not?
this was a grep typo on my part. sorry.
-jx
>=20
> - k
>=20
^ permalink raw reply
* Re: [PATCH 00/16] more mac68k fixes and cleanup
From: Geert Uytterhoeven @ 2011-10-31 18:35 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k
In-Reply-To: <20111023141108.856998818@telegraphics.com.au>
Hi Finn,
On Sun, Oct 23, 2011 at 16:11, Finn Thain <fthain@telegraphics.com.au> wrote:
> It would be good if this whole series passes through the m68k tree.
OK, I'll apply all of them.
But several of them will have to go in via other maintainers' trees,
or get acked.
> I suppose that after all of the renaming recently this series will need
> to be rebased (?)
"git am" is smart enough to detect that drivers/net/ got restructured.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: Andrea Arcangeli @ 2011-10-31 18:34 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Johannes Weiner, Pekka Enberg, Cyclonus J, Sasha Levin,
Christoph Hellwig, David Rientjes, Linus Torvalds, linux-mm, LKML,
Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge, Seth Jennings,
ngupta, Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet,
Hugh Dickins
In-Reply-To: <b86860d2-3aac-4edd-b460-bd95cb1103e6@default>
On Fri, Oct 28, 2011 at 10:07:12AM -0700, Dan Magenheimer wrote:
> First, there are several companies and several unaffiliated kernel
> developers contributing here, building on top of frontswap. I happen
> to be spearheading it, and my company is backing me up. (It
> might be more appropriate to note that much of the resistance comes
> from people of your company... but please let's keep our open-source
> developer hats on and have a technical discussion rather than one
> which pleases our respective corporate overlords.)
Fair enough to want an independent review but I'd be interesting to
also know how many of the several companies and unaffiliated kernel
developers are contributing to it that aren't using tmem with
Xen. Obviously bounce buffers 4k vmexits are still faster than
Xen-paravirt-I/O on disk platter...
Note, Hugh is working for another company... and they're using cgroups
not KVM nor Xen, so I suggests he'd be a fair reviewer from a non-virt
standpoint, if he hopefully has the time to weight in.
However keep in mind if we'd see something that can allow KVM to run
even faster, we'd be quite silly in not taking advantage of it too, to
beat our own SPECvirt record. The whole design idea of KVM (unlike
Xen) is to reuse the kernel improvements as much as possible so when
the guest runs faster the hypervisor also runs faster with the exact
same code. Problem a vmexit doing a bounce buffer every 4k doesn't mix
well into SPECvirt in my view and that probably is what has kept us
from making any attempt to use tmem API anywhere.
^ permalink raw reply
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: Andrea Arcangeli @ 2011-10-31 18:34 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Johannes Weiner, Pekka Enberg, Cyclonus J, Sasha Levin,
Christoph Hellwig, David Rientjes, Linus Torvalds, linux-mm, LKML,
Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge, Seth Jennings,
ngupta, Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet,
Hugh Dickins
In-Reply-To: <b86860d2-3aac-4edd-b460-bd95cb1103e6@default>
On Fri, Oct 28, 2011 at 10:07:12AM -0700, Dan Magenheimer wrote:
> First, there are several companies and several unaffiliated kernel
> developers contributing here, building on top of frontswap. I happen
> to be spearheading it, and my company is backing me up. (It
> might be more appropriate to note that much of the resistance comes
> from people of your company... but please let's keep our open-source
> developer hats on and have a technical discussion rather than one
> which pleases our respective corporate overlords.)
Fair enough to want an independent review but I'd be interesting to
also know how many of the several companies and unaffiliated kernel
developers are contributing to it that aren't using tmem with
Xen. Obviously bounce buffers 4k vmexits are still faster than
Xen-paravirt-I/O on disk platter...
Note, Hugh is working for another company... and they're using cgroups
not KVM nor Xen, so I suggests he'd be a fair reviewer from a non-virt
standpoint, if he hopefully has the time to weight in.
However keep in mind if we'd see something that can allow KVM to run
even faster, we'd be quite silly in not taking advantage of it too, to
beat our own SPECvirt record. The whole design idea of KVM (unlike
Xen) is to reuse the kernel improvements as much as possible so when
the guest runs faster the hypervisor also runs faster with the exact
same code. Problem a vmexit doing a bounce buffer every 4k doesn't mix
well into SPECvirt in my view and that probably is what has kept us
from making any attempt to use tmem API anywhere.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] Stop mce-inject writing to mce_chrdev_ops
From: tony.luck @ 2011-10-31 18:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Arjan van de Ven
Arjan would like to make struct file_operations const, but mce-inject
directly writes to the mce_chrdev_ops to install its write handler.
In an ideal world mce-inject would have its own character device, but
we have a sizable legacy of test scripts that hardwire "/dev/mcelog",
so it would be painful to switch to a separate device now. Instead,
this patch switches to a stub function in the mce code, with a
registration helper that mce-inject can call when it is loaded.
Note that this would also allow for a sane process to allow mce-inject
to be unloaded again (with an unregister function, and appropriate
module_{get,put}() calls), but that is left for potential future patches.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index c9321f3..22cc0eb 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -201,7 +201,10 @@ int mce_notify_irq(void);
void mce_notify_process(void);
DECLARE_PER_CPU(struct mce, injectm);
-extern struct file_operations mce_chrdev_ops;
+
+extern void register_mce_write_hook(ssize_t (*)(struct file *filp,
+ const char __user *ubuf,
+ size_t usize, loff_t *off));
/*
* Exception handler
diff --git a/arch/x86/kernel/cpu/mcheck/mce-inject.c b/arch/x86/kernel/cpu/mcheck/mce-inject.c
index 0ed633c..a18c2c8 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-inject.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-inject.c
@@ -215,7 +215,7 @@ static int inject_init(void)
if (!alloc_cpumask_var(&mce_inject_cpumask, GFP_KERNEL))
return -ENOMEM;
printk(KERN_INFO "Machine check injector initialized\n");
- mce_chrdev_ops.write = mce_write;
+ register_mce_write_hook(mce_write);
register_die_notifier(&mce_raise_nb);
return 0;
}
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 08363b0..e24468d 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1628,16 +1628,35 @@ static long mce_chrdev_ioctl(struct file *f, unsigned int cmd,
}
}
+static ssize_t (*mce_write)(struct file *filp, const char __user *ubuf,
+ size_t usize, loff_t *off);
+
+void register_mce_write_hook(ssize_t (*fn)(struct file *filp, const char __user *ubuf,
+ size_t usize, loff_t *off))
+{
+ mce_write = fn;
+}
+EXPORT_SYMBOL_GPL(register_mce_write_hook);
+
+ssize_t mce_chrdev_write(struct file *filp, const char __user *ubuf,
+ size_t usize, loff_t *off)
+{
+ if (mce_write)
+ return mce_write(filp, ubuf, usize, off);
+ else
+ return -ENODEV;
+}
+
/* Modified in mce-inject.c, so not static or const */
struct file_operations mce_chrdev_ops = {
.open = mce_chrdev_open,
.release = mce_chrdev_release,
.read = mce_chrdev_read,
+ .write = mce_chrdev_write,
.poll = mce_chrdev_poll,
.unlocked_ioctl = mce_chrdev_ioctl,
.llseek = no_llseek,
};
-EXPORT_SYMBOL_GPL(mce_chrdev_ops);
static struct miscdevice mce_chrdev_device = {
MISC_MCELOG_MINOR,
^ permalink raw reply related
* Re: Lock in the ironlake_panel_vdd_work()
From: Keith Packard @ 2011-10-31 18:33 UTC (permalink / raw)
To: Daniel Vetter, Konstantin Belousov; +Cc: intel-gfx
In-Reply-To: <20111031133446.GE2920@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 1657 bytes --]
On Mon, 31 Oct 2011 14:34:46 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 31, 2011 at 03:01:33PM +0200, Konstantin Belousov wrote:
> > I have a question about ironlake_panel_vdd_work(). Should it use
> > the device struct_mutex, or need it to be the mode_config.mutex
> > instead ?
>
> Yeah. This was actually flagged in review by Chris and me, but seems to
> have been lost in the merge. Keith?
I thought I fixed that; it must have gotten lost in the fairly steady
set of rebasing/reworking of that patch sequence.
commit 241dedda2785f040da45576418686490431232d2
Author: Keith Packard <keithp@keithp.com>
Date: Mon Oct 31 11:30:10 2011 -0700
drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
Use of the struct_mutex is not correct for locking in mode setting paths.
Signed-off-by: Keith Packard <keithp@keithp.com>
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6611d90..30420c1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -971,9 +971,9 @@ static void ironlake_panel_vdd_work(struct work_struct *__work)
struct intel_dp, panel_vdd_work);
struct drm_device *dev = intel_dp->base.base.dev;
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev->mode_config.mutex);
ironlake_panel_vdd_off_sync(intel_dp);
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->mode_config.mutex);
}
static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.