* Re: OT: compilation
From: Pekka Paalanen @ 2010-10-07 20:34 UTC (permalink / raw)
To: Grzesiek Sójka; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <4CAE2A1B.1000105-t9zbU3WrWHI@public.gmane.org>
On Thu, 07 Oct 2010 22:14:19 +0200
Grzesiek Sójka <pld-t9zbU3WrWHI@public.gmane.org> wrote:
> I have two problems with the kernel compilation.
>
> 1. I have a small rootfs. It is too small to put all the modules
> there without gzipping it first. So installing it requires lots
> of sweating. That is why I was wondering if there is a (more/less
> easy) way to make the "make modules_install" command gzip the
> modules "on the fly".
Wait, does modprobe support compressed kernel modules? I've
never heard of that. If you really do not want to touch
the partitioning, how about symlinking some directories
elsewhere? Be careful on what is needed to boot, though.
> 2. I modified the sources and after compilation the string
> "g76f6e1f-dirty" was appended to the kernel version. It is a bit
> annoying because of the lack of the space at the rootfs. Is there
> a way to avoid this kind of a version extension??
Yes, it is CONFIG_LOCALVERSION_AUTO as far as I recall, disable that.
--
Pekka Paalanen
http://www.iki.fi/pq/
^ permalink raw reply
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Jonathan Nieder @ 2010-10-07 20:28 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: David Barr, Git Mailing List, Ramkumar Ramachandra
In-Reply-To: <AANLkTikjzQ09XBxYZXXQf6XCme3FiLKtusZ0MLTa--mM@mail.gmail.com>
Sverre Rabbelier wrote:
> This means nothing to me
Sorry for the lack of clarity. Probably I should have just said:
| For a command (like filter-branch --subdirectory-filter) that wants
| to commit a lot of trees that already exist in the object db, writing
| undeltified objects as loose files only to repack them later can
| involve a significant amount[*] of overhead.
|
| Fortunately we have fast-import (which is one of the only git commands
| that will write to a pack directly) but there is not an advertised way
| to tell fast-import to commit a given tree without unpacking it.
|
| This patch changes that, by allowing
|
| M 040000 <tree id> ""
|
| as a filemodify line in a commit to reset to a particular tree without
| any need to parse it. For example,
|
| M 040000 4b825dc642cb6eb9a060e54bf8d69288fbee4904 ""
|
| is a synonym for the deleteall command.
[*] how significant? Numbers are always nice. :)
> Ok, so maybe I do understand, is it basically 'git read-tree
> 4b825dc642cb6eb9a060e54bf8d69288fbee4904' for fast-import?
Yep.
Thanks.
^ permalink raw reply
* + mm-stack-based-kmap_atomic-fix.patch added to -mm tree
From: akpm @ 2010-10-07 20:00 UTC (permalink / raw)
To: mm-commits; +Cc: akpm, a.p.zijlstra
The patch titled
mm-stack-based-kmap_atomic-fix
has been added to the -mm tree. Its filename is
mm-stack-based-kmap_atomic-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: mm-stack-based-kmap_atomic-fix
From: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff -puN drivers/gpu/drm/i915/intel_overlay.c~mm-stack-based-kmap_atomic-fix drivers/gpu/drm/i915/intel_overlay.c
--- a/drivers/gpu/drm/i915/intel_overlay.c~mm-stack-based-kmap_atomic-fix
+++ a/drivers/gpu/drm/i915/intel_overlay.c
@@ -1475,21 +1475,18 @@ intel_overlay_map_regs_atomic(struct int
regs = overlay->reg_bo->phys_obj->handle->vaddr;
else
regs = io_mapping_map_atomic_wc(dev_priv->mm.gtt_mapping,
- overlay->reg_bo->gtt_offset,
- slot);
+ overlay->reg_bo->gtt_offset);
return regs;
}
static void intel_overlay_unmap_regs_atomic(struct intel_overlay *overlay,
- int slot,
struct overlay_registers *regs)
{
if (!OVERLAY_NEEDS_PHYSICAL(overlay->dev))
- io_mapping_unmap_atomic(regs, slot);
+ io_mapping_unmap_atomic(regs);
}
-
struct intel_overlay_error_state *
intel_overlay_capture_error_state(struct drm_device *dev)
{
@@ -1517,7 +1514,7 @@ intel_overlay_capture_error_state(struct
goto err;
memcpy_fromio(&error->regs, regs, sizeof(struct overlay_registers));
- intel_overlay_unmap_regs_atomic(overlay, KM_IRQ0, regs);
+ intel_overlay_unmap_regs_atomic(overlay, regs);
return error;
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
maintainers-haavard-has-moved.patch
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
arch-mips-include-asm-fcntlh-needs-typesh.patch
arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch
arch-x86-kernel-entry_32s-i386-too.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
drivers-media-video-cx23885-cx23885-corec-fix-cx23885_dev_checkrevision.patch
fs-notify-fanotify-fanotify_userc-fix-warnings.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-low-threshold-to-pwm-backlight.patch
serial8250-ratelimit-too-much-work-error-fix.patch
serial8250-ratelimit-too-much-work-error-fix-fix.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
drivers-message-fusion-mptsasc-fix-warning.patch
vfs-allow-mnt_want_write-to-sleep-fix.patch
mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-fix.patch
rmap-make-anon_vma_free-static-fix.patch
vmstat-include-compactionh-when-config_compaction-fix.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
hpet-factor-timer-allocate-from-open-fix.patch
m68k-__pa-cast-arg-to-long.patch
kernelh-add-minmax3-macros-fix.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
printk-declare-printk_ratelimit_state-in-ratelimith-fix.patch
vsprintfc-use-default-pointer-field-size-for-null-strings-fix.patch
scripts-get_maintainerpl-add-git-blame-rolestats-authored-lines-information.patch
idr-fix-idr_pre_get-locking-description-fix.patch
checkpatch-returning-errno-typically-should-be-negative.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
vcs-add-poll-fasync-support-fix-fix.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatch-fixes.patch
drivers-char-hvc_consolec-remove-unneeded-__set_current_statetask_running.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
fuse-use-release_pages.patch
pps-add-async-pps-event-handler-fix.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-fix.patch
kernel-resourcec-handle-reinsertion-of-an-already-inserted-resource.patch
ramoops-use-the-platform-data-structure-instead-of-module-params-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
getblk-handle-2tb-devices.patch
^ permalink raw reply
* Re: format-patch on permission change gives empty patch
From: Junio C Hamano @ 2010-10-07 20:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, David Miller
In-Reply-To: <alpine.LFD.2.00.1010071503210.3107@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Wed, 6 Oct 2010, Junio C Hamano wrote:
>
>> I have a mixed feeling about where to go next.
>>
>> (1) Treat "rebase" as a way to reproduce a reasonable history; the
>> current behaviour to drop empty commits is consistent with this view,
>> as a history with an empty commit is _not_ entirely reasonable.
>
> But a file mode change isn't exactly an empty commit, no?
The second message from DaveM:
Message-ID: <20101006.174008.70175671.davem@davemloft.net>
Ok it turns out that the commit in question was a NOP since the file
permissions didn't change.
^ permalink raw reply
* Re: [PATCH] net: clear heap allocation for ETHTOOL_GRXCLSRLALL
From: Ben Hutchings @ 2010-10-07 20:28 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, David S. Miller, Jeff Garzik, Jeff Kirsher,
Peter P Waskiewicz Jr, netdev
In-Reply-To: <20101007200348.GA6038@outflux.net>
On Thu, 2010-10-07 at 13:03 -0700, Kees Cook wrote:
> Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel
> heap without clearing it. For the one driver (niu) that implements it,
> it will leave the unused portion of heap unchanged and copy the full
> contents back to userspace.
>
> Cc: stable@kernel.org
> Signed-off-by: Kees Cook <kees.cook@canonical.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Should have spotted this myself. :-(
Ben.
> ---
> net/core/ethtool.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 7a85367..4016ac6 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -348,7 +348,7 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
> if (info.cmd == ETHTOOL_GRXCLSRLALL) {
> if (info.rule_cnt > 0) {
> if (info.rule_cnt <= KMALLOC_MAX_SIZE / sizeof(u32))
> - rule_buf = kmalloc(info.rule_cnt * sizeof(u32),
> + rule_buf = kzalloc(info.rule_cnt * sizeof(u32),
> GFP_USER);
> if (!rule_buf)
> return -ENOMEM;
> --
> 1.7.1
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [dm-crypt] What happen if hard drive has a read error?
From: octane indice @ 2010-10-07 20:20 UTC (permalink / raw)
To: dm-crypt
Hello
It's just a theorical question. I encrypted some data with dm-crypt on an
hard drive.
But what happens if the hard drive has an error? Not a kind of a big error
which cause the hard drive hangs, but just a small error that make the
system doesn't read the bytes all right?
Obviously, dm-crypt won't decrypt the data. But what happens next?
-dm-crypt will panic() the kernel
-Only a block won't be decrypted, so it means that at best, only a file is
corrupted, and at worst all of the filesystem is trashed, depending the
location of the error?
-Or everything beyond the point of the read error will be trash?
-Or it depends of the crypto layer choosen as CBC, or else?
That's just a theorical question, thank you
Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-07 20:26 UTC (permalink / raw)
To: david.hagood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fe4c3e4086132d746b79670f236302f1.squirrel@localhost>
On Thu, 7 Oct 2010 15:12:26 -0500
<david.hagood@gmail.com> wrote:
> > On Tue, 21 Sep 2010 17:37:15 -0400
> > The MPIC interrupt numberspace in the device tree (which is not
> > virtual; it is a private numberspace to MPIC) is based on the offset of
> > the registers for that interrupt source. External interrupts start at
> > zero (which is valid), internal at 16, and special things like MSIs at
> > higher numbers (I don't think it's quite 256).
>
> OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
> sending this information to the folks doing the Linux Device Drivers
> books? They are just a bit x86 centric right now...).
>
> As I understand, what I have to do is somehow get a device_node *, then
> make a call to irq_of_parse_and_map() to convert that into a system IRQ.
>
> What I am doing right now is:
> device_node *mpic = of_find_node_by_type(0,"open-pic");
> irq = irq_of_parse_and_map(mpic,256);
This is asking for the 256th specifier in the interrupts property in
the mpic node -- not what you want.
Ideally you would have a node for your device with an interrupt
specifier that you could look up with irq_of_parse_and_map(). But if
not, you can use irq_create_mapping() to directly convert an MPIC IRQ
number to a virtual IRQ.
What interrupt are you trying to select with 256? That doesn't look
like a valid MPIC interrupt number.
> 2) How do I know for certain that 256 is the right value for the first MSI
> signaled via MSIR0?
It isn't. The vector/priority register (MSIVPR0) is at offset
0x51c00. Each interrupt source is 32 bytes. The first interrupt
source is at 0x50000.
So the interrupt number is (0x51c00 - 0x50000) / 32 = 224.
BTW, the MSIs are already described in an msi node in the device tree.
Are you trying to do something different with them than PCI MSIs? If
not, is the existing MSI driver not working? If you are trying to do
something different, you should bind to that node yourself and use
irq_of_parse_and_map() on it.
-Scott
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-07 20:52 UTC (permalink / raw)
To: Mike Frysinger
Cc: Daniel Walker, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Greg Kroah-Hartman, Ben Dooks, Alan Cox,
Kukjin Kim, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <AANLkTinxorq2XhJdGDNQuUghxzr1q6OW=S1VjupOu5nH@mail.gmail.com>
On Thu, 7 Oct 2010 15:25:34 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Thu, Oct 7, 2010 at 14:36, Daniel Walker wrote:
> > Many of JTAG debuggers for ARM support DCC protocol over JTAG
> > connection, which is very useful to debug hardwares which has no
> > serial port. This patch adds DCC serial emulation and the console
> > support. System timer based polling method is used for the
> > emulation of serial input interrupt handling.
>
> why use serial_core at all ? seems like you could just use the tty
> layer directly. i did that with drivers/char/bfin_jtag_comm.c.
I would agree 100% with this for the driver in question. The tty_port
helpers now make it trivial to do so and it'll be small and clean as a
result.
Alan
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-07 20:50 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286476616-3373-1-git-send-email-dwalker@codeaurora.org>
> + Say Y here if you want to install DCC driver as a normal serial port
> + /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
> + (major 4, minor 128) and can co-exist with other UARTs, such as
> + 8250/16C550 compatibles.
> +
NAK to both
ttyJ0 is 204,186 for "JTAG1 DCC protocol based serial"
so there is an existing name and minor allocation, which as you won't be
using two of them should be quite usable.
If you want to be able to switch at runtime to pretend it is ttyS0 please
deal with that in your user space. The same rules apply to you as have
been applied to everyone else who has tried to implement this same crap
in their uart driver too (we'd have it in about 30 by now otherwise)
>
> +static inline void dcc_rx_chars(struct uart_port *port)
> +{
> + unsigned char ch;
> + struct tty_struct *tty = port->state->port.tty;
Not safe in the general case - you might get a hangup here then call
through a NULL pointer. Please use the proper tty_port helpers.
> +static inline void dcc_overrun_chars(struct uart_port *port)
> +{
> + port->icount.overrun++;
> +}
Why make this a function?
> +static void
> +dcc_set_termios(struct uart_port *port, struct ktermios *termios,
> + struct ktermios *old)
> +{
> + unsigned int baud, quot;
> +
> + /*
> + * We don't support parity, stop bits, or anything other
> + * than 8 bits, so clear these termios flags.
> + */
> + termios->c_cflag &= ~(CSIZE | CSTOPB | PARENB | PARODD | CREAD);
> + termios->c_cflag |= CS8;
> +
> + /*
> + * We don't appear to support any error conditions either.
> + */
> + termios->c_iflag &= ~(INPCK | IGNPAR | IGNBRK | BRKINT);
There is a helper function for keeping the hardware bits fixed. If your
hardware is fixed then please use it.
Alan
^ permalink raw reply
* [Qemu-devel] [PATCH 1/2] fix fd leak on one qcow2_create2() error path
From: Eduardo Habkost @ 2010-10-07 20:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Kevin Wolf
In-Reply-To: <1286483105-9768-1-git-send-email-ehabkost@redhat.com>
When getting an invalid cluster size, the open fd must be closed before
qcow2_create() returns an error.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
block/qcow2.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index ee3481b..c5fb28e 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -918,7 +918,8 @@ static int qcow_create2(const char *filename, int64_t total_size,
"%d and %dk\n",
1 << MIN_CLUSTER_BITS,
1 << (MAX_CLUSTER_BITS - 10));
- return -EINVAL;
+ ret = -EINVAL;
+ goto exit_close;
}
s->cluster_size = 1 << s->cluster_bits;
@@ -1052,6 +1053,8 @@ static int qcow_create2(const char *filename, int64_t total_size,
exit:
qemu_free(s->refcount_table);
qemu_free(s->refcount_block);
+
+exit_close:
close(fd);
/* Preallocate metadata */
--
1.6.5.5
^ permalink raw reply related
* [Qemu-devel] [PATCH 0/2] qcow2_create() error handling fixes
From: Eduardo Habkost @ 2010-10-07 20:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Kevin Wolf
From: Eduardo Habkost <ehabkost@raisama.net>
Hi,
Here are two small fixes on qcow2_create() error handling.
Eduardo Habkost (2):
fix fd leak on a qcow2_create2() error path
check for close() errors on qcow2_create()
block/qcow2.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
^ permalink raw reply
* [Qemu-devel] [PATCH 2/2] check for close() errors on qcow2_create()
From: Eduardo Habkost @ 2010-10-07 20:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Kevin Wolf
In-Reply-To: <1286483105-9768-1-git-send-email-ehabkost@redhat.com>
Errors when closing the file we just created should not be ignored. I/O errors
may happen and "qemu-img create" should fail in those cases.
If we are already exiting due to an error, we will still return the original
error number, though.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
block/qcow2.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index c5fb28e..d3a056b 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -882,7 +882,7 @@ static int qcow_create2(const char *filename, int64_t total_size,
uint64_t old_ref_clusters;
QCowCreateState s1, *s = &s1;
QCowExtension ext_bf = {0, 0};
- int ret;
+ int ret, cret;
memset(s, 0, sizeof(*s));
@@ -1055,7 +1055,9 @@ exit:
qemu_free(s->refcount_block);
exit_close:
- close(fd);
+ cret = close(fd);
+ if (ret == 0 && cret < 0)
+ ret = -errno;
/* Preallocate metadata */
if (ret == 0 && prealloc) {
--
1.6.5.5
^ permalink raw reply related
* [ANNOUNCE] metagit 0.1.2
From: Christian Dietrich @ 2010-10-07 20:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]
Hi,
I wanted to announce my project metagit[1], which I started a few weeks
ago. It is a python program, which allows you to manage many scm
repositories at once, e.g. pull all repositories, that are matched by a
given regex. Before you can use it you have to define a set of
repositories. This can either be accomplished by defining them one by
one, or you can use a repo lister.
One good example of a repo lister is the SSHDir lister. It performs a
find on a remote server within a given directory and adds all the
repositories there to your repo set. There is also a lister to get all
your github repos (or gitorious).
But metagit isn't narrowed to git as scm. At this point it also gives
you the possibility to use mercurial as scm backend and you can clone
your damned fucked SVN repo with git-svn (with the externals, if you wish).
The configuration is just a python script, where you can use the power
of python to define your repositories, and no package is used that isn't
shipped with python (at minimum python 2.5 (it workes perfectly with
debian stable)).
You can also define policies which of your defined repos (or listers)
show up on a machine (this is done by a regex against the fqdn).
If you have any wish what metagit should also be able to do, write me a
mail, write a issue at github or fork it :-)
greetz didi
[1] http://github.com/stettberger/metagit
--
(λ x . x x) (λ x . x x) -- See how beatiful the lambda is
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] xfs: remove xfs_buf wrappers
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184126.919946101@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-cleanup-buf-wrappers)
> Stop having two different names for many buffer functions and use the
> more descriptive xfs_buf_* names directly.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good, I prefer this.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 6/7] xfs: remove xfs_cred.h
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184126.663057623@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-remove-cred.h)
> We're not actually passing around credentials inside XFS for a while now,
> so remove all xfs_cred.h with it's cred_t typedef and all instances of it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
Looks good. I think I found one or two spots left where
"cred" was used in comments (maybe above xfs_ialloc()?).
But that's OK.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 5/7] xfs: remove xfs_globals.h
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184126.419695420@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-kill-globals.h)
> This header only provides one extern that isn't actually declared anywhere,
> and shadowed by a macro.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 1/1] um: ubd: Fix data corruption
From: Chris Frey @ 2010-10-07 20:23 UTC (permalink / raw)
To: Jens Axboe
Cc: Tejun Heo, Richard Weinberger, Andrew Morton,
linux-kernel@vger.kernel.org, jdike@addtoit.com,
user-mode-linux-devel@lists.sourceforge.net,
user-mode-linux-user@lists.sourceforge.net, janjaap@bos.nl,
geert@linux-m68k.org, martin.petersen@oracle.com,
adobriyan@gmail.com, syzop@vulnscan.org
In-Reply-To: <4CAD7D98.7080808@fusionio.com>
On Thu, Oct 07, 2010 at 09:58:16AM +0200, Jens Axboe wrote:
> So how about this? Note that I haven't even compiled this. The request
> handling logic really should be fixed in there, it's horribly
> inefficient.
Thanks. I fixed the compile error with:
> + .rq_offset 0, \
to
> + .rq_offset = 0, \
But after testing, I still got the same errors:
EXT3-fs error (device ubda): ext3_lookup: deleted inode referenced: 964816
EXT3-fs error (device ubda): ext3_lookup: deleted inode referenced: 964862
EXT3-fs error (device ubda): ext3_lookup: deleted inode referenced: 964786
EXT3-fs error (device ubda): ext3_lookup: deleted inode referenced: 964815
...
- Chris
^ permalink raw reply
* Re: [PATCH 4/7] xfs: remove xfs_version.h
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184126.161666009@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-kill-version.h)
> It used to have a place when it contained an automatically generated CVS
> version, but these days it's entirely superflous.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 3/7] xfs: remove xfs_refcache.h
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184125.895296316@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-kill-xfs_refcache.h)
> This header has been completely unused for a couple of years.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [msysGit] Re: [PULL] Pull request from msysGit
From: Erik Faye-Lund @ 2010-10-07 20:22 UTC (permalink / raw)
To: Pat Thoyts
Cc: Peter Harris, Ramsay Jones, Pat Thoyts, Junio C Hamano, git,
msysgit, sschuberth
In-Reply-To: <AANLkTinSjFDdwqTEU6XzOVHupph0G2ZKM+u3r7t_W3DD@mail.gmail.com>
On Thu, Oct 7, 2010 at 10:18 PM, Pat Thoyts <patthoyts@gmail.com> wrote:
>
> I also wonder why changes to a compat/mingw.h file should affect the
> msvc build. As it has it's own compat/vcbuild and headers in there,
> surely it should be independent of mingw-gcc compatability headers?
>
compat/msvc.h includes compat/mingw.h. We really should move more
stuff to compat/win32.h, and have cygwin include it's own header or
something instead.
^ permalink raw reply
* Re: [PATCH 2/7] xfs: fix the xfs_trans_committed
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184125.617230666@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-fix-cb_func_prototype)
> Use the correct prototype for xfs_trans_committed instead of casting it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 1/7] xfs: remove unused t_callback field in struct xfs_trans
From: Alex Elder @ 2010-10-07 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184125.327557835@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-remove-t_callback)
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* RE: [PATCH] iovmm: IVA2 MMU range is from 0x11000000 to 0xFFFFFFFF
From: Guzman Lugo, Fernando @ 2010-10-07 20:23 UTC (permalink / raw)
To: Hiroshi DOYU
Cc: felipe.contreras@nokia.com, ameya.palande@nokia.com,
david.cohen@nokia.com, linux-kernel@vger.kernel.org,
andy.shevchenko@gmail.com, linux-omap@vger.kernel.org
In-Reply-To: <20101007.221401.226802875.Hiroshi.DOYU@nokia.com>
Hi Hiroshi,
> -----Original Message-----
> From: Hiroshi DOYU [mailto:Hiroshi.DOYU@nokia.com]
> Sent: Thursday, October 07, 2010 2:14 PM
> To: Guzman Lugo, Fernando
> Cc: felipe.contreras@nokia.com; ameya.palande@nokia.com;
> david.cohen@nokia.com; linux-kernel@vger.kernel.org;
> andy.shevchenko@gmail.com; linux-omap@vger.kernel.org
> Subject: Re: [PATCH] iovmm: IVA2 MMU range is from 0x11000000
> to 0xFFFFFFFF
>
> From: ext Fernando Guzman Lugo <x0095840@ti.com>
> Subject: [PATCH] iovmm: IVA2 MMU range is from 0x11000000 to
> 0xFFFFFFFF
> Date: Thu, 7 Oct 2010 20:43:41 +0200
>
> > IV2 MMU capable addresses start from 0x11000000
>
> Wouldn't it be better to add an general API to configure the
> valid 'da' range in advance?
Yes I was thinking in passing start and end range in iommu_get
(because don't need to change rage, it is needed only one time)
And create new elements in iommu struct for start and end address
or maybe defining the range statically when the structures are
Fillup for omapxxx. But I tought I was break other users of iommu
Like omap4 and isp and it would be easier to accept an small patch.
But I am agree with you it would be better to make it configurable.
As tidspbridge iommu migratio seems to be target to 37 I can
Make a new patch and resend.
Please let me know if you have some suggestions.
Regards,
Fernando.
>
> I don't think that it's a good idea to introduce the iommu
> instance("iva2:iommu") specific code here.
>
^ permalink raw reply
* [AUTOTEST MIRROR][PATCH] Introduce .gitignore file
From: Luiz Capitulino @ 2010-10-07 20:22 UTC (permalink / raw)
To: ehabkost; +Cc: kvm
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
Eduardo, can you actually commit to a git mirror? It's hard to work in your
repo w/o this file.
.gitignore | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..f23bd95
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,7 @@
+*.pyc
+client/control
+client/results/
+client/tests/kvm/images
+client/tests/kvm/env
+client/tmp
+client/tests/kvm/*.cfg
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* Re: libgee_0.6.0: gee/Makefile.am:95: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
From: Dr. Michael Lauer @ 2010-10-07 20:28 UTC (permalink / raw)
To: Steve Sakoman; +Cc: openembedded-devel@lists.openembedded.org
In-Reply-To: <AANLkTi=nS_3emPJsndTjjAM=cPwwc=pW0Ktk7DJwEj++@mail.gmail.com>
That probably needs to be converted into a DEPENDS.
Cheers,
:M:
Am 07.10.2010 um 21:35 schrieb Steve Sakoman <sakoman@gmail.com>:
> On Wed, Oct 6, 2010 at 4:33 PM, Paul Menzel
> <paulepanter@users.sourceforge.net> wrote:
>> Dear OE folks,
>>
>>
>> `configure` fails for me for `libgee_0.6.0.bb` [1].
>>
>> | gee/Makefile.am:95: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
>>
>> `libgee_0.5.2.bb` builds correctly because it does not yet use gobject-introspection.
>>
>> This question was brought up before but was left unanswered [2].
>>
>> There was no file `introspection.m4`, where `HAVE_INTROSPECTION` is
>> defined in, in
>>
>> …/work/armv7a-oe-linux-gnueabi/libgee-1_0.6.0-r1/libgee-0.6.0/m4
>>
>> as recommended in [3]. Should the m4 file be copied there as it is done
>> for the other m4 files?
>>
>> […]
>> | autoreconf: configure.ac: tracing
>> | autoreconf: running: libtoolize --copy --force
>> | libtoolize: putting auxiliary files in `.'.
>> | libtoolize: copying file `./ltmain.sh'
>> | libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
>> | libtoolize: copying file `m4/libtool.m4'
>> | libtoolize: copying file `m4/ltoptions.m4'
>> | libtoolize: copying file `m4/ltsugar.m4'
>> | libtoolize: copying file `m4/ltversion.m4'
>> | libtoolize: copying file `m4/lt~obsolete.m4'
>> […]
>>
>> I manually put the m4 file [4] into `libgee-0.6.0/m4/` and added
>> `m4/introspection.m4` to `EXTRA_DIST` in `Makefile.am` to `` but
>>
>> bitbake -c configure libgee
>>
>> still failed.
>>
>> Do you have any ideas?
>
> I found that if I built gobject-introspection-native manually, then
> libgee would complete without error.
>
> The DEPENDS_virtclass-native = "gobject-introspection-native" in the
> libgee recipe isn't triggering the build automatically.
>
> Steve
^ permalink raw reply
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.