This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16:30:24.0 +1100
+++
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
and change the caller now that everybody can handle it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
mm/mmap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Index: linux-cell/mm/mmap.c
===
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel/s
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
On Wed, 2007-04-04 at 14:01 +1000, Benjamin Herrenschmidt wrote:
> This is a "first step" as there are still cleanups to be done in various
> areas touched by that code but I think it's probably good to go as is and
> at least enables me to implement what I need for PowerPC.
.../...
And sorry f
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/sparc64/mm/huget
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
User space queries like "what is the cpuset to which this task belongs",
where the answer needs to be something of the form "/dev/cpuset/C1"?
The patches address that requirement atm by having a dentry pointer in
struct cpuset itself.
Hav
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
=
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
resend
On 4/3/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel c
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via th
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel/s
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/sparc64/mm/huget
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
=
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
> > [EMAIL PROTECTED] music]# stat .
> > Device: fd00h/64768dInode: 10354963Links: 39
> > Now rebooted to 2.6.21-rc5:
> > Device: ee00h/60928dInode: 1035
On Sat, Mar 31, 2007 at 04:27:46PM +0530, Milind Arun Choudhary wrote:
> Clean up ROUND_?UP, Use ALIGN where ever appropriate.
>
> Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
Milind,
Looks good to me.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Kyle,
can you remind me how the
Alan Cox writes:
> That would be completely unmanagable on many systems with multiport
> controllers and interfaces where the naming tells you things like which
> cable port off which socket off which multiplexor is the one you are
> talking about.
I never suggested *all* serial ports should be /
Don't know if this got reported yet. It's slightly stale
(against 2.6.21-rc4-git6), but I don't recall seeing
anything in the changelogs recently that would make this
irrelevant.
Dave
--
http://www.codemonkey.org.uk
--- Begin Message ---
Please do not reply directly to this email. All ad
Jan Engelhardt a écrit :
On Apr 2 2007 12:41, Eric Dumazet wrote:
The following patch does the right thing for pipes, I let you doing
the same for sockets...
Is struct sock->sk_receive_queue->qlen actually the thing I am
looking for? (Previously, I had struct sock->sk_rcvbuf, which was
obvious
On Sun, Apr 01, 2007 at 01:06:46PM +0530, Milind Arun Choudhary wrote:
> ROUND_UP macro cleanup, use ALIGN where ever appropriate
>
> Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
Also looks good to me. Just one white space nit we can fixup by hand.
Signed-off-by: Grant Grundler <[EMA
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
> Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the above mail didnt make it into lkml (maybe it
exceeded the m
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the same
page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code. That is certainly not
wi
On Wed, 2007-04-04 at 14:20 +1000, Paul Mackerras wrote:
> I never suggested *all* serial ports should be /dev/ttySn, I said that
> the built-in ports on the motherboard should be /dev/ttySn.
Why? What's so special about the name 'ttyS'?
> The built-in ports can generally be enumerated early on
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >Move the page walker code to lib/
> >
> >This lets it get shared outside of proc/ and linked in only when
> >needed.
>
> I think it would be better in mm/.
I originally was looking at putting it in mm/memory.c a
H. Peter Anvin wrote:
> Mutable data should be separated from code. I think any current CPU
> will do fine as long as they are in separate 128-byte chunks, but they
> need at least that much separation.
P4 manual says that if one processor modifies data within 2k of another
processor executing cod
H. Peter Anvin a écrit :
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the
same page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code.
This is an old bug. It has been happening forever, but I'd love to
know how I can help get this tracked down and fixed.
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Pro
On Tue, 2007-04-03 at 17:35 +0100, Paul LeoNerd Evans wrote:
> On Tue, Apr 03, 2007 at 04:20:52PM +, Pavel Machek wrote:
> > HPA is right... this should be fixed in userland. Reset should reset a
> > console, and if you want utf-8, do \ec\ewhatever to get it.
>
> As I've already said elsewhere
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifies data within 2k of anothe
Nick Piggin a écrit :
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private to each thread. A sequence could invalidate
the cache(s).
ie instead of a mm->mmap_cache, having a mm->sequence, and each thread
having a current->mmap_c
On Tue, 2007-04-03 at 17:37 +0200, Martin Mares wrote:
> Hello!
>
> > Does whatever defines what these escapes mean, have any comment to make
> > about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset"
> > mode, the default that would be dropped to on a full reset, and if
> > anyo
On Wed, 4 Apr 2007 00:33:36 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> This is an old bug. It has been happening forever, but I'd love to
> know how I can help get this tracked down and fixed.
Yes, I've been hitting something like that in the past 3-4 weeks. We
started to diagnose it but I
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifie
Alan Cox wrote:
Nothing terribly exciting here just odd glitches from the merge
ACK, will apply if I can sort out the confusion between -mm and local
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Wed, 04 Apr 2007 01:19:59 -0400
> I don't see why that 'should' be the case. Certainly it _isn't_ the case
> on most supported platforms -- we have separate device numbers, and
> names, for most types of ports. There's only one or two drivers which
>
Matt Mackall wrote:
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
I originally was looking at putting it in mm
David Woodhouse writes:
> Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
> > The built-in ports can generally be enumerated early on boot in a
> > stable order, and they should be assigned the low ttySn numbers,
> > regardles
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > Why? What's so special about the name 'ttyS'?
>
> It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered dev
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
+++ linux/drivers/ata/libata-scsi.
Eric Dumazet wrote:
Nick Piggin a écrit :
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared
by all threads but private to each thread. A sequence could
invalidate the cache(s).
ie instead of a mm->mmap_cache, having a mm->sequence, and each
thread h
Robert Hancock wrote:
This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
Windows driver .inf files. There are some confirming reports of problems
with these drives under Linux (for example
http://lkml.org/lkml/2007/3/4/178)
so let's disable NCQ on these drives.
Signed-
On Tue, Apr 03 2007, Pekka J Enberg wrote:
> > mcdx:: close()
>
> However, we never hit do_mcdx_request(). Jens, do we need to do
> set_capacity() somewhere? I don't see other cdrom drivers doing it but
> they could be broken too...
Yeah, that would be appropriate.
--
Jens Axboe
-
To unsubsc
On Tue, 3 Apr 2007, Matt Mackall wrote:
> Make /proc/pid/clear_refs option under CONFIG_EMBEDDED
>
> This interface is primarily useful for doing memory profiling and not
> much use on deployed embedded boxes. Make it optional. Together with
> /proc/pid/smaps, this save a few K.
>
> Signed-off-b
On Wed, 04 Apr 2007 16:09:40 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew, do you have any objections to putting Eric's fairly
> important patch at least into -mm?
you know what to do ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH] Just include linux/kallsyms.h all the time as the header will
handle prototypes/defines when CONFIG_KALLSYMS is disabled ... fixes
build error when disabled due to print_ip_sym not being macroed away
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/traps.c |5 ++---
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
include/asm-blackfin/socket.h | 55
include/asm-blackfin/sockios.h | 13 +
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 include/asm-blackfin/socket.h
create mode 100644
USB gadget rndis: skb_push function may return a pointer which is not
aligned as required by struct rndis_packet_msg_type.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/usb/gadget/rndis.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
mm/nommu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 2d0a82f..0016557 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -261,6 +261,14 @@ void vunmap(void *addr)
}
/*
+ * Implement a
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index ce51882..9870c60 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/k
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
include/asm-blackfin/pgtable.h | 44 +++
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/include/asm-blackfin/pgtable.h b/include/asm-blackfin/pgtable.h
index 9328537..5a8f9e4 100644
--- a/includ
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/lib/memchr.S | 31 +---
arch/blackfin/lib/memcmp.S | 46 ++
arch/blackfin/lib/memcpy.S | 24 +++---
arch/blackfin/lib/memmove.S | 12 ++
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
include/asm-blackfin/uaccess.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/asm-blackfin/uaccess.h b/include/asm-blackfin/uaccess.h
index ed931bb..bfcb679 100644
--- a/include/asm-blackfin/uaccess.h
+++ b/inclu
On 4/4/07, Rene Herman <[EMAIL PROTECTED]> wrote:
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Can you get anything out with sysrq-t? The original oops would be
enough to conclude it's a double-free if it weren't
David Woodhouse writes:
> > It 'should' be the case because that is what is easiest for users and
> > makes most sense from a user's point of view.
>
> I really don't buy that argument. People cope perfectly well
> with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
Those are
On Wed, 4 Apr 2007, Antoine Martin wrote:
> and this one:
> http://www.suse.de/~kraxel/uml/patches/2.6.18-rc4/uml-x11-fb
> which applied cleanly, but is not letting me set the option - Kconfig is
> beyond me:
>
> arch/um/Kconfig:144:warning: 'select' used by config symbol 'X11_FB' refer to
> undef
On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote:
[...]
> Well, it works for me on 32-bit as well, right up to 100% full.
> No problems at all...
Maybe it depends on the kernel. I patched 2.6.20 with the patches
above and got the described behaviour.
Regards,
Tino
-
To unsubscribe fro
On Tue, Apr 03, 2007 at 03:55:32PM +0200, Bernhard Kaindl wrote:
> PS: I attached a program which uses msr.ko (CONFIG_X86_MSR) from
> Processor type and features
> -> [M/*] /dev/cpu/*/msr - Model-specific register support
> to dump the contents of the fixed-range MTTRs to stdout.
>
>
(sorry to change the subjet, I was initially going to send the
threaded vma cache patches on list, but then decided they didn't
have enough changelog!)
Andrew Morton wrote:
On Wed, 04 Apr 2007 16:09:40 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew, do you have any objections to putting
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c | 33 -
drivers/ata/libata-eh.c | 22 +++---
drivers/a
On Tue, 2007-04-03 at 20:22 -0700, Randy Dunlap wrote:
> > +/**
> > + * val_outside - is a value and length past a limit?
> > + * @val: the start value
> > + * @len: the length from the start
> > + * @limit: the first invalid value
> > + *
> > + * Like val + len > limit, except with overflow checki
Nick Piggin wrote:
> Sad. Although Ulrich did seem interested at one point I think? Ulrich,
> do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Desc
Ulrich Drepper wrote:
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
Private futexes.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this
On Tue, Apr 03, 2007 at 07:04:58PM -0700, Paul Jackson wrote:
> Andrew wrote:
> > I'd have thought that in general an application should be querying its
> > present affinity mask - something like sched_getaffinity()? That fixes the
> > CPU hotplug issues too, of course.
>
> The sched_getaffinity
Ulrich Drepper a écrit :
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
You were CC on this one, you can find an archive here :
http://lkml.
On Wed, 2007-04-04 at 14:28 +0800, Wu, Bryan wrote:
> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> ---
> include/asm-blackfin/socket.h | 55
>
> include/asm-blackfin/sockios.h | 13 +
> 2 files changed, 68 insertions(+), 0 deletions(-)
> cre
Eric Dumazet wrote:
> You were CC on this one, you can find an archive here :
You cc:ed my gmail account. I don't pick out mails sent to me there.
If you want me to look at something you have to send it to my
@redhat.com address.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain Vi
David Woodhouse writes:
> A GUI PPP dialer should be
> listing the available serial ports in the system whatever their names
> are.
How do you propose they do that? Neither kppp nor gnome-ppp seem to
be able to do that currently. Gnome-ppp offers just /dev/modem and
/dev/ttyS[0123]. Kppp offer
401 - 484 of 484 matches
Mail list logo
