On 02/16, Srivatsa Vaddagiri wrote:
Note with the change proposed in refrigerator, we can avoid
CPU_DEAD_KILL_THREADS and do all cleanup in CPU_DEAD itself.
In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just use
Remove the long-obsolete raw device support.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
based on this excerpt from
Documentation/feature-removal-schedule.txt:
What: RAW driver (CONFIG_RAW_DRIVER)
When: December 2005
Why:declared obsolete since kernel 2.6.3
G'day people,
I was looking at bitops.h and noticed there were a couple of inline roll
functions to operate on 32bit variables. (left and right)
I think that is a little bit dumb as they are constant width (only
32bits) due to it being an inline function, and was wondering if anyone
thought it
Am 16.02.2007 09:33 schrieb Adrian Bunk:
...
LD drivers/isdn/gigaset/built-in.o
drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb':
(.text+0xe50): multiple definition of `gigaset_m10x_send_skb'
drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here
On Fri, 16 Feb 2007 14:37:28 +0100
Rolf Eike Beer [EMAIL PROTECTED] wrote:
I can't bring up my machine with root LVM anymore using x86_64. The same
machine from same kernel tree boots fine as x86. The error message is quoted
in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b
On Fri, 16 Feb 2007 11:05:32 -0600
[EMAIL PROTECTED] (Olof Johansson) wrote:
+ nfsi-req_lock = SPIN_LOCK_UNLOCKED;
This can confound lockdep. Please use spin_lock_init().
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Constant folding does not work for the swabXX() byte swapping functions,
and the C versions optimize poorly.
Attempting to initialize a global variable to swab16(0x1234) or put
something like case swab32(42): in a switch statement will not compile.
It can work, swab.h just isn't doing it
John Rose [EMAIL PROTECTED] wrote on 15.02.2007 14:57:37:
Looks good. Questions: how can the user space tools verify the success
of an add or remove?
If the probe operation succeeds, the respective device will show up
beneath
/sys/bus/ibmebus/devices.
Also, will /sys/bus/ibmebus exist
Loose cache mode was added primarily to asssist exclusive, read-only
mounts (like venti) -- however, there is also a case for using loose
write cacheing in support of read/write exclusive mounts. This feature
is linked to the loose cache option and is disabled by default.
This code adds the
On Thu, 15 Feb 2007, Ingo Molnar wrote:
+ spin_lock(ah-lock);
+
+ new_async_thread = pick_ready_cachemiss_thread(ah);
+ if (!new_async_thread)
+ goto out_unlock;
+
+ async_ready = t-async_ready;
+ WARN_ON(!async_ready);
+ t-async_ready = NULL;
+
+
Con Kolivas wrote:
mm-filesize_dependant_lru_cache_add.patch
I like it.
Is any of this stuff ever going to be merged?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 16 Feb 2007 18:46:59 -0600
Eric Van Hensbergen [EMAIL PROTECTED] wrote:
Loose cache mode was added primarily to asssist exclusive, read-only
mounts (like venti) -- however, there is also a case for using loose
write cacheing in support of read/write exclusive mounts. This feature
is
On Thursday 15 February 2007 9:12 pm, David Brownell wrote:
On Thursday 15 February 2007 8:38 pm, Len Brown wrote:
So I've taken Andi's advice and checked in the patches below.
OK; that simplifies things for me, good! I can discard that patch
(broken by Andi's pcspkr change anyway), stop
On Sat, Feb 17 2007, Paul P Komkoff Jr wrote:
Hi!
Is there any plans to make splice(socket, ..., pipe, ...) work?
It's a work in-progress, latest effort is to import and attempt to fix
the stuff that Intel initially posted some months ago. See the
splice-net branch of the block git repo.
--
On Saturday 17 February 2007 11:53, Chuck Ebbert wrote:
Con Kolivas wrote:
mm-filesize_dependant_lru_cache_add.patch
I like it.
Thanks :-)
Is any of this stuff ever going to be merged?
See the last paragraph here:
http://lkml.org/lkml/2007/2/9/112
I'm thru with bashing my head against
I get the following OOPS on boot, presumably connected with USB driver
loading. I've attached the entire log. Please CC on replies as I'm not
subscribed.
[ 149.525742] Unable to handle kernel NULL pointer dereference at
0008 RIP:
[ 149.531302] [8887eec3]
On Fri, 16 Feb 2007 11:05:32 -0600
[EMAIL PROTECTED] (Olof Johansson) wrote:
Seems like req_lock is never initialized. CONFIG_DEBUG_SPINLOCK reported:
BUG: spinlock bad magic on CPU#0, mount/1073
lock: c0007fdca108, .magic: , .owner: /24576, .owner_cpu: 0
Call Trace:
Why does inet_bind (instead of socket_bind) check that ports below 1024 require
CAP_NET_BIND_SERVICE?
Couldn't this check be moved to the dummy socket_bind so that the behaviour can
be changed by a security module?
---
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index cf358c8..d75a2c5
On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
Greetings,
Per $subject, git.yesterday hangs hard on boot here. A git bisect
fingered the commit below, which I verified via git bisect reset; git
revert -n
On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
Greetings,
Per $subject, git.yesterday hangs hard on boot here. A git bisect
fingered the commit below,
Yes, an obscure .config, but it used to build before today:
kernel/built-in.o: In function `tick_broadcast_on_off':
(.text+0x1b6f0): undefined reference to `smp_call_function_single'
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20
# Fri Feb 16 19:08:20 2007
#
On Fri, 2007-02-16 at 05:10 -0700, Eric W. Biederman wrote:
Getting the drivers changed actually looks to be pretty straight
forward it will just be a very large mechanical change. We change the
type where of variables where appropriate and every once in a while
introduce an irq_nr(irq) to
On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
So I propose we remove all assumptions from the code that we actually
have an array of irqs. That will allow for irq_desc to be dynamically
allocated instead of statically allocated
Rather than having the job of rewriting this code during 2.6, I'd much
prefer to get something sorted, even if it is ARM only before 2.6.
I believe that there are some common problems with the existing API
which have been hinted at over the last few days, such as large
NR_IRQS. As
On Fri, 16 Feb 2007 23:06:54 +0100
Olaf Hering [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Un-Breaks pthreads, since Oct 2003.
Oh come on, that's not a changelog. I refuse to believe that nobody has
used pthreads on ia64 for the past three years.
Index:
On 2/16/07, Olaf Hering [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Un-Breaks pthreads, since Oct 2003.
why aren't you using /etc/security/limits.conf?
I think the stack limit can be set as big as 8TB on ia64 with default
16KB page size.
- Ken
-
To unsubscribe from this list: send the
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now have a standard kernel-wide, c99-friendly way of
expressing true and false, I'd suggest that this decision can be revisited.
Because a true is significantly more meaningful (and hence readable)
thing than a bare 1.
On Thu, 2007-02-15 at 19:53 -0700, Patro, Sumant wrote:
Hello James,
I re-submitted the patch yesterday with the space issue fixed
(adhering to coding guideline).
I will check for alternative to calculate the time driver have
been sending host busy to OS. Will check with
James Bottomley wrote:
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now have a standard kernel-wide, c99-friendly way of
expressing true and false, I'd suggest that this decision can be revisited.
Because a true is significantly more meaningful (and hence readable)
On Fri, 2007-02-16 at 19:04 +0100, Richard Knutsson wrote:
James Bottomley wrote:
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now have a standard kernel-wide, c99-friendly way of
expressing true and false, I'd suggest that this decision can be revisited.
On Fri, 16 Feb 2007 10:42:12 -0600 James Bottomley [EMAIL PROTECTED] wrote:
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now have a standard kernel-wide, c99-friendly way of
expressing true and false, I'd suggest that this decision can be revisited.
Because a
On Fri, 2007-02-16 at 10:34 -0800, Andrew Morton wrote:
On Fri, 16 Feb 2007 10:42:12 -0600 James Bottomley [EMAIL PROTECTED] wrote:
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now have a standard kernel-wide, c99-friendly way of
expressing true and false, I'd
On Fri, 16 Feb 2007 12:42:27 -0600 James Bottomley [EMAIL PROTECTED] wrote:
On Fri, 2007-02-16 at 10:34 -0800, Andrew Morton wrote:
On Fri, 16 Feb 2007 10:42:12 -0600 James Bottomley [EMAIL PROTECTED]
wrote:
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now
James Bottomley wrote:
On Fri, 2007-02-16 at 19:04 +0100, Richard Knutsson wrote:
James Bottomley wrote:
On Mon, 2007-02-12 at 12:27 -0800, Andrew Morton wrote:
Given that we now have a standard kernel-wide, c99-friendly way of
expressing true and false, I'd suggest that
On Fri, 2007-02-16 at 10:50 -0800, Andrew Morton wrote:
Me no understand.
If you take the specific example of
void
ahd_set_syncrate(struct ahd_softc *ahd, struct ahd_devinfo *devinfo,
u_int period, u_int offset, u_int ppr_options,
u_int type, int paused)
Tobias Diedrich wrote:
Jeff Garzik wrote:
Tobias Diedrich wrote:
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
It probably needs to
Hi,
I agree with most points. Here the new design proposal:
On Wednesday 14 February 2007 23:25, John Rose wrote:
Hi-
A few high level comments, then some really insignificant ones.
First, is there a reason why we shouldn't have a sysfs entry/kobject for
each logical port? How is it
Hi-
Sounds good. A couple of questions/comments:
I think it is not necessary to have a special entry/kobject for each logical
port. I suggest we use SET_NETDEV_DEV to create links to all ethernet devices
that represent each a logical port. This should be in sync with all other
ethernet
Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm
asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44
to compile on systems with these cpus.
This patch was created with the assumption that another method of
dma_sync_single_range_for_cpu/device does not
Richard Knutsson [EMAIL PROTECTED] writes:
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
Ack.
--- a/drivers/net/wan/pc300too.c
+++ b/drivers/net/wan/pc300too.c
@@ -542,7 +542,7 @@ static int __init pc300_init_module(void)
On Fri, Feb 16, 2007 at 05:27:28PM -0500, Lennart Sorensen wrote:
On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote:
It seems whenever it gets stuck, it is always the same descripter it is
stuck on. Here is my current log:
eth1: interrupt csr0=0x4f3 new csr=0x33,
On Fri, Feb 16, 2007 at 05:48:24PM -0500, Lennart Sorensen wrote:
Well so far it really looks like enabling OOSTORE on the Geode
SC1200/GX1 really does make a difference. A bit of searching seems to
indicate the person that originally submitted the patch that enabled
load/store reordering on
This happens under heavy I/O + network traffic, it happened again, this
time under 2.6.20-- is this normal/or would it be considered a bug?
Because it does retry/re-discover the device.
== /p34/var/log/messages ==
Feb 16 09:26:21 p34 kernel: [1007261.262023] usb 6-2: USB disconnect,
address 2
On Fri, 16 Feb 2007, Justin Piszcz wrote:
This happens under heavy I/O + network traffic, it happened again, this
time under 2.6.20-- is this normal/or would it be considered a bug?
It would be considered a bug in your device, not a bug in the kernel.
Alan Stern
-
To unsubscribe from this
Hello James,
It is difficult to know when the device will go into a state
where it is not able to process cmds within timeout period consistently.
Many factors may be contributing for the device to get into this state.
Reducing can_queue may help but the difficult part is when
On Thu, Feb 15, 2007 at 03:48:04PM -0800, Linus Torvalds wrote:
On Thu, 15 Feb 2007, Jeff Garzik wrote:
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index db185f3..d51f0f1 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -22,6 +22,7 @@ config IA64
config
Tejun Heo wrote:
Hello,
Robert Hancock wrote:
[--correct summary snipped--]
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we
need to FUA-blacklist any drives this should likely be added to the
existing horkage mechanism we now
Tobias Diedrich wrote:
Possibly a known issue:
After resume pata_amd drops from UDMA/33 to PIO on my system.
Reloading the module puts both attached optical drives (master and
slave) back to UDMA/33.
AFAICS simplex DMA is claimed by other device, disabling DMA seems
to be causing it to drop to
Robert Hancock wrote:
Tobias Diedrich wrote:
Possibly a known issue:
After resume pata_amd drops from UDMA/33 to PIO on my system.
Reloading the module puts both attached optical drives (master and
slave) back to UDMA/33.
AFAICS simplex DMA is claimed by other device, disabling DMA seems
to
On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
You might want to have a look at the powerpc API with it's remaping
capabilities. It's very nice for handling multiple domain spaces. It
might be of some use for you.
I don't consider the powerpc virtual IRQs a solution for the
On 2/16/07, Con Kolivas [EMAIL PROTECTED] wrote:
I'm thru with bashing my head against the wall.
I do hope this post isn't in any way redundant, but from what I can
see, this has never been suggested... (someone please do enlighten me
if I'm wrong.)
Has anyone tried booting a kernel with the
On 2/17/07, Greg KH [EMAIL PROTECTED] wrote:
On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
Greetings,
Per $subject, git.yesterday hangs hard on boot
Sylvain Munaut [EMAIL PROTECTED] wrote on 15.02.2007 15:11:42:
Mmmh, I posted a patch that added a common uevent interface for all
of_device based bus. And that kinda clash with this one.
Oops, I was not aware of this. I had a look at your patch and yes, it's a
nice
and generic interface. I
On Sat, Feb 17, 2007 at 02:59:39AM +0300, Oleg Nesterov wrote:
In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just use
kthread_stop/kthread_should_stop.
Great, thanks!
This also means that probably it won't be
On Fri, Feb 16, 2007 at 10:46:05PM +0300, Oleg Nesterov wrote:
Instead, we can just clear PF_FROZEN before kthread_should_stop().
That should work too. Thanks!
I don't claim this is better, but this way we don't need to add a
subtle change to process.c.
--
Regards,
vatsa
-
To unsubscribe
Periodic load balancing in recent kernels happen in the softirq.
In certain -rt configurations, these softirqs are handled in softirqd
context. And hence the check for idle processor was always returning
busy (as nr_running 1).
This patch captures the idle information at the tick and passes this
On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote:
Just to be perfectly clear, it is an outrageous claim that *every*
*possible* kernel module must be a derivative work of the
kernel. Copyright
*cannot* protect every possible way to accomplish a particular
function (and
On 2/16/07, David Schwartz [EMAIL PROTECTED] wrote:
(See, among other cases, Lexmark. v. Static
Controls.) A copyright is not a patent, you can only own
something if there
are multiple equally good ways to do it and you claim *one* of them.
Only in a world where write a Linux module
That's exactly what they're doing. Knowing only the *function* of his
program, they are claiming it must obey their licensing terms.
They have no
idea exactly how he chose to implement that function, but claim
they must
own it anyway.
They are not claiming ownership of his code.
Changes since v1:
- Move the idle load balancer selection from schedule()
to the first busy scheduler_tick() after restarting the tick.
This will avoid the unnecessay ownership changes when
softirq's(which are run in softirqd context in certain -rt
configurations) like timer,
This patch replaces ibmebus_uevent() by Sylvain's generic function.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
ibmebus.c | 37 +++--
1 file changed, 3 insertions(+), 34 deletions(-)
diff -urp a/arch/powerpc/kernel/ibmebus.c
Linking with kernel exported symbols in a kernel module is by many
people considered creating a work derived from the kernel.
That's simply unreasonable. It is the most clear settled law that only a
creative process can create a work for copyright purposes. Linking is an
automated process, not
On 2/17/07, Markus Rechberger [EMAIL PROTECTED] wrote:
On 2/17/07, Greg KH [EMAIL PROTECTED] wrote:
On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
On Fri, Feb 16, 2007 at 10:55:10AM +0100, Mike Galbraith wrote:
On Saturday 17 February 2007 13:15, michael chang wrote:
On 2/16/07, Con Kolivas [EMAIL PROTECTED] wrote:
I'm thru with bashing my head against the wall.
I do hope this post isn't in any way redundant, but from what I can
see, this has never been suggested... (someone please do enlighten me
From: Olaf Hering
Newsgroups: gmane.linux.kernel
Subject: [PATCH] override build timestamp
Date: Fri, 16 Feb 2007 22:52:13 +0100
Hallo, Olaf.
Pass a timestamp to kbuild via an enviroment variable.
TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
This can be used when the
If one of clear_bit, change_bit or set_bit is defined as a do { } while (0)
function usage of these functions in parenthesis like
(foo_bit(23, var))
while be expaned to something like
(do { ... } while (0)}).
resulting in a build error. This patch removes the useless parenthesis.
Hi Eric,
I committed your code to linuxtv.org to review and modify it there.
http://linuxtv.org/hg/~mrechberger/chipcardreader
one thing I noticed is the error handling in ozscr_probe.
I'll continue the rest during the next few days, I'd like to see it as
soon as possible in the upstream
On 2/15/07, Gene Heskett [EMAIL PROTECTED] wrote:
[ignorant silliness]
There is no one to my knowledge here, who would not cheer loudly once a
verdict was rendered because that courts decision would give the FOSS
community a quotable case law as to exactly what is, and is not legal for
you to do
On Friday 16 February 2007, Michael K. Edwards wrote:
On 2/15/07, Gene Heskett [EMAIL PROTECTED] wrote:
[ignorant silliness]
There is no one to my knowledge here, who would not cheer loudly once
a verdict was rendered because that courts decision would give the
FOSS community a quotable case
On Fri, Feb 16, 2007 at 02:47:45PM -0800, Daniel Walker wrote:
Gets pretty ugly .. The clocksource interface already has a positive
rating to describe the best clocks in the system, which is used to
return the best clock .. Where the maintainers of the system give each
clock a rating.
On Fri, 2007-02-16 at 22:56 +0100, Oleg Verych wrote:
Hallo.
lguest parts look good though!
Rusty.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On Sat, Feb 17, 2007 at 04:04:52AM +0100, Markus Rechberger wrote:
On 2/17/07, Markus Rechberger [EMAIL PROTECTED] wrote:
On 2/17/07, Greg KH [EMAIL PROTECTED] wrote:
On Sat, Feb 17, 2007 at 02:38:08AM +0100, Mike Galbraith wrote:
On Fri, 2007-02-16 at 14:36 -0800, Greg KH wrote:
On
On Feb 16, 2007, at 5:10 PM, Robert Hancock wrote:
Kumar Gala wrote:
I'm seeing an issue with a stock 2.6.20 kernel running on an
embedded PPC. I've got a usb flash drive plugged in and the
filesystem on the drive is vfat. Running with 64M and no swap.
If I execute a series of large
Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki kou.ishizaki
at toshiba.co.jp) and a bunch of rather obvious cleanups/improvements (me).
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This adds IB multicast tracking, to allow userspace
Andi Kleen wrote:
It's for populating the pagetable in a vmalloc area. There's magic in
If the lazy setup doesn't work for you you can always call vmalloc_sync()
early.
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic. I
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic. I guess I could just move it all to
arch/i386/mm.
This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and
On 16/2/07 17:10, Keir Fraser [EMAIL PROTECTED] wrote:
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic. I guess I could just move it all to
arch/i386/mm.
This whole
Nick Piggin wrote:
Pekka Enberg wrote:
On 2/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Remove the ctor for the pgd cache. There's no point in having the
cache machinery do this via an indirect call when all pgd are freed in
the one place anyway.
The reason we have slab
On Fri, 2007-02-16 at 17:10 +, Keir Fraser wrote:
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic. I guess I could just move it all to
arch/i386/mm.
This
Keir Fraser wrote:
On 16/2/07 17:10, Keir Fraser [EMAIL PROTECTED] wrote:
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic. I guess I could just move it all to
Andi Kleen wrote:
Subject? description?
On Thu, Feb 15, 2007 at 06:24:53PM -0800, Jeremy Fitzhardinge wrote:
-static void vmi_set_pte_present(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pte)
+static void vmi_set_pte_present(struct mm_struct *mm, u32 addr, pte_t
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
that we are going to have some nasty bugs to fix up as a result, but we
can't fix them until we find them! Then we can convert
On 16/2/07 17:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
that we are going to have some nasty bugs to fix up as a
On 16/2/07 17:27, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
In fact that file is only built for i386 and x86_64, so there really is no
problem with using vmalloc_sync_all() directly and without ifdef.
I had moved it to mm/vmalloc.c in response to previous review comments
(namely,
On 16/2/07 19:06, Keir Fraser [EMAIL PROTECTED] wrote:
I had moved it to mm/vmalloc.c in response to previous review comments
(namely, its not Xen specific, so it shouldn't live in the Xen part of
the tree).
Then the call will have to be CONFIG_X86. I hadn't realised powerpc were
also
Keir Fraser wrote:
We can extend the Xen timer interface quite easily and get rid of this one
too. In fact it doesn't *much* matter if the CONFIG_HZ differs from the Xen
ticker rate -- we modified the Linux timer ISR to handle timer interrupts at
arbitrary times already. The only drawback is
Keir Fraser wrote:
Hmmm... Actually looks like a bunch of architectures do lazy sync of the
vmalloc area, although neither ia64 nor powerpc does so. However, all
current users of the alloc_vm_area() function would be okay since none of
the other lazy-syncing architectures are supported by Xen.
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
Remove the ctor for the pgd cache. There's no point in having the
cache machinery do this via an indirect call when all pgd are freed in
the one place anyway.
Great. We finally get rid of this evil .
On second throughts:
Are you sure
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
this issue closely but it seems
Christoph Lameter wrote:
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
On Fri, 16 Feb 2007, Zachary Amsden wrote:
For the most part, it doesn't disturb VMware or KVM. Xen does need some
additional functionality in paravirt-ops because they took a different design
choice - direct page tables instead of shadow page tables. This is where all
the requirements for
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
For the most part, it doesn't disturb VMware or KVM. Xen does need some
additional functionality in paravirt-ops because they took a different design
choice - direct page tables instead of shadow page tables. This is
Keir Fraser wrote:
On 16/2/07 17:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
that we are going to have some nasty
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can correct me if lhype's puppy's have precluded the addition
of new hooks). Xen
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can correct me if lhype's puppy's have precluded the
On 02/16/2007 01:51 PM, Zachary Amsden wrote:
Keir Fraser wrote:
On 16/2/07 17:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT
On 16/2/07 19:26, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Keir Fraser wrote:
Hmmm... Actually looks like a bunch of architectures do lazy sync of the
vmalloc area, although neither ia64 nor powerpc does so. However, all
current users of the alloc_vm_area() function would be okay since
Christoph Lameter wrote:
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
Remove the ctor for the pgd cache. There's no point in having the
cache machinery do this via an indirect call when all pgd are freed in
the one place anyway.
Great. We finally get rid of this evil .
Keir Fraser wrote:
It has no other users right now and get_vm_area_sync() would be a
better-named and more generically useful function than alloc_vm_area().
I'm thinking reserve might be a better term; get generally has the
suggestion of a refcount.
get_vm_area_sync(), partnered with existing
301 - 400 of 843 matches
Mail list logo
