Hi...
I have a problem with nfs. It always worked, so I don't know what is
failing now.
I have a server running 2.6.11-rc3-mm2. I try to export a dir via nfs:
/etc/exports:
/raid belly.cps.unizar.es(ro,insecure,no_root_squash,no_subtree_check)
nada:/proc/fs/nfs# exportfs -v
/raid
Hi...
I have a problem with nfs. It always worked, so I don't know what is
failing now.
I have a server running 2.6.11-rc3-mm2. I try to export a dir via nfs:
/etc/exports:
/raid belly.cps.unizar.es(ro,insecure,no_root_squash,no_subtree_check)
nada:/proc/fs/nfs# exportfs -v
/raid
On Thu, 2005-02-24 at 07:41 +0100, Guillaume Thouvenin wrote:
> On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > > Please assume that > > originally written for> will always be listening.
> > >
> > > > > What happened to the idea of sending an on/off message down the
> > > > >
On Thu, 2005-02-24 at 07:41 +0100, Guillaume Thouvenin wrote:
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
Please assume that whatever secret application the connector stuff was
originally written for will always be listening.
What happened to the idea of sending an
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > Please assume that > originally written for> will always be listening.
> >
> > > > What happened to the idea of sending an on/off message down the netlink
> > > > socket?
> > ...
> > Arrange for the userspace daemon to send a message
On Wed, 23 Feb 2005 02:58:06 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 23 Feb 2005 01:07:47 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > >
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Feb 2005 01:07:47 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > This patch replaces the relay_fork module and it implements a fork
> > > connector
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > This patch replaces the relay_fork module and it implements a fork
> > connector in the kernel/fork.c:do_fork() routine. The connector sends
> >
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> This patch replaces the relay_fork module and it implements a fork
> connector in the kernel/fork.c:do_fork() routine. The connector sends
> information about parent PID and child PID over a netlink interface. It
> allows to several
nnector.h |2 ++
kernel/fork.c | 41 +
3 files changed, 51 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
/fork.c | 41 +
3 files changed, 51 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig 2005-02-11
11
Guillaume Thouvenin [EMAIL PROTECTED] wrote:
Hello,
This patch replaces the relay_fork module and it implements a fork
connector in the kernel/fork.c:do_fork() routine. The connector sends
information about parent PID and child PID over a netlink interface. It
allows to several user
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Guillaume Thouvenin [EMAIL PROTECTED] wrote:
Hello,
This patch replaces the relay_fork module and it implements a fork
connector in the kernel/fork.c:do_fork() routine. The connector sends
information about
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Guillaume Thouvenin [EMAIL PROTECTED] wrote:
Hello,
This patch replaces the relay_fork module and it implements a fork
connector in the
On Wed, 23 Feb 2005 02:58:06 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Guillaume Thouvenin [EMAIL PROTECTED] wrote:
Hello,
This patch replaces the
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
Please assume that whatever secret application the connector stuff was
originally written for will always be listening.
What happened to the idea of sending an on/off message down the netlink
socket?
...
Arrange for the
Guillaume wrote:
>
> I understand your point of view but I'm using netlink interface
> because it's already in the kernel so my choice is to use something that
> is already in the kernel instead of adding dozens of new instructions
> and also to do things in user space.
All else equal, yes it is
On Monday 21 February 2005 15:43, Guillaume Thouvenin wrote:
>
> I also choose this implementation because Erich Focht wrote in the
> email http://lkml.org/lkml/2004/12/17/99 that keeps the historic about
> the creation of processes "sounds very useful for a lot of interesting
> stuff". So I
On Mon, 2005-02-21 at 03:58 -0800, Paul Jackson wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent PID and child PID over a netlink interface. It allows to several
> > user space
Thank-you for your quick answer.
Guillaume wrote:
>
> If a process belongs to several group of processes, an new integer in
> the task_struct is not enough, you need a list or something like this.
> If you're using a list you need to add function to manage this list in
> the kernel but we don't
On Mon, 2005-02-21 at 01:47 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The problem is the following: I have a user space daemon that manages
> > group of processes. The main idea is, if a parent belongs to a group
> > then its child belongs to the same group. To achieve this I need to know
Guillaume wrote:
> The problem is the following: I have a user space daemon that manages
> group of processes. The main idea is, if a parent belongs to a group
> then its child belongs to the same group. To achieve this I need to know
> when a fork occurs and which processes are involved. I don't
On Mon, 2005-02-21 at 09:05 +0100, Guillaume Thouvenin wrote:
> On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> > >
> > > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
> >
> > I suspect CONFIG_FORK_CONNECTOR is enough.
>
> The problem here is that if connector
ns, a message is send. I
> > > don't know how to avoid that. I added an option (FORK_CONNECTOR) to
> > > enable the fork connector (or disable) when compiling the kernel. To
> > > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> > > h
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> >
> > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR)
>
> I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and
fork_connector as builtin there will be undefined
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
+#if defined(CONFIG_CONNECTOR) defined(CONFIG_FORK_CONNECTOR)
I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and
fork_connector as builtin there will be undefined
(FORK_CONNECTOR) to
enable the fork connector (or disable) when compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.11-rc3-mm2 kernel with two user space
applications connected.
It is used by ELSA to manage
On Mon, 2005-02-21 at 09:05 +0100, Guillaume Thouvenin wrote:
On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
+#if defined(CONFIG_CONNECTOR) defined(CONFIG_FORK_CONNECTOR)
I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a
Guillaume wrote:
The problem is the following: I have a user space daemon that manages
group of processes. The main idea is, if a parent belongs to a group
then its child belongs to the same group. To achieve this I need to know
when a fork occurs and which processes are involved. I don't see
On Mon, 2005-02-21 at 01:47 -0800, Paul Jackson wrote:
Guillaume wrote:
The problem is the following: I have a user space daemon that manages
group of processes. The main idea is, if a parent belongs to a group
then its child belongs to the same group. To achieve this I need to know
when
Thank-you for your quick answer.
Guillaume wrote:
If a process belongs to several group of processes, an new integer in
the task_struct is not enough, you need a list or something like this.
If you're using a list you need to add function to manage this list in
the kernel but we don't want
On Mon, 2005-02-21 at 03:58 -0800, Paul Jackson wrote:
It's a new patch that implements a fork connector in the
kernel/fork.c:do_fork() routine. The connector sends information about
parent PID and child PID over a netlink interface. It allows to several
user space applications to be
On Monday 21 February 2005 15:43, Guillaume Thouvenin wrote:
I also choose this implementation because Erich Focht wrote in the
email http://lkml.org/lkml/2004/12/17/99 that keeps the historic about
the creation of processes sounds very useful for a lot of interesting
stuff. So I thought
Guillaume wrote:
I understand your point of view but I'm using netlink interface
because it's already in the kernel so my choice is to use something that
is already in the kernel instead of adding dozens of new instructions
and also to do things in user space.
All else equal, yes it is good
ECTOR) to
> > enable the fork connector (or disable) when compiling the kernel. To
> > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> > has been tested on a 2.6.11-rc3-mm2 kernel with two user space
> > applications connected.
> >
> When running a Posix conformance test (from posixtestsuite), the kernel
> locks up with:
>
> BUG: soft lockup detected on CPU#0
>
> Pid: 1873, comm: 10-1.test
> EIP: 0060:[] CPU: 0
> EIP is at sys_timer_settime+0xfa+0x1f0
> EFLAGS: 00000282 Not tainted (2.6.11-r
2.6.11-rc3-mm2/arch/ppc/kernel/misc.S
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
--- linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S 2005-02-20 12:39:29.0
+0100
+++
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
2005
perfctr-2.7.10 update, 3/4:
- Update x86_64 syscall table for perfctr-2.7.10 API changes.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
include/asm-x86_64/unistd.h |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/include/asm-
fctr.h | 19 ++-
kernel/sys_ni.c |3
4 files changed, 159 insertions(+), 98 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/version.h
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h
--- linux-2.6.11-rc3-mm2/drivers/perfctr/version.h 2005
de/asm-x86_64/ia32_unistd.h |7 +++
4 files changed, 8 insertions(+), 12 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S
--- linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S 2005-02-20
/perfctr.h | 19 ++-
kernel/sys_ni.c |3
4 files changed, 159 insertions(+), 98 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/version.h
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h
--- linux-2.6.11-rc3-mm2/drivers/perfctr/version.h
-x86_64/ia32_unistd.h |7 +++
4 files changed, 8 insertions(+), 12 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S
--- linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S 2005-02-20
12:39
perfctr-2.7.10 update, 3/4:
- Update x86_64 syscall table for perfctr-2.7.10 API changes.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
include/asm-x86_64/unistd.h |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff -rupN linux-2.6.11-rc3-mm2/include/asm-x86_64/unistd.h
-rc3-mm2/arch/ppc/kernel/misc.S
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
--- linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S 2005-02-20 12:39:29.0
+0100
+++
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
2005-02-20 13
When running a Posix conformance test (from posixtestsuite), the kernel
locks up with:
BUG: soft lockup detected on CPU#0
Pid: 1873, comm: 10-1.test
EIP: 0060:[c0126fda] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX
compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.11-rc3-mm2 kernel with two user space
applications connected.
It is used by ELSA to manage group of processes in user space. In
conjunction with a per-process
I found the following in my logs:
<-- snip -->
Feb 19 15:46:05 r063144 kernel: smb_get_length: Invalid NBT packet, code=86
Feb 19 15:46:35 r063144 kernel: smb_add_request: request [d5242d40, mid=50934]
timed out!
Feb 19 15:46:35 r063144 kernel: BUG: atomic counter underflow at:
Feb 19
When running a Posix conformance test (from posixtestsuite), the kernel
locks up with:
BUG: soft lockup detected on CPU#0
Pid: 1873, comm: 10-1.test
EIP: 0060:[] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX: 0001 ECX
When running a Posix conformance test (from posixtestsuite), the kernel
locks up with:
BUG: soft lockup detected on CPU#0
Pid: 1873, comm: 10-1.test
EIP: 0060:[c0126fda] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX: 0001 ECX
I found the following in my logs:
-- snip --
Feb 19 15:46:05 r063144 kernel: smb_get_length: Invalid NBT packet, code=86
Feb 19 15:46:35 r063144 kernel: smb_add_request: request [d5242d40, mid=50934]
timed out!
Feb 19 15:46:35 r063144 kernel: BUG: atomic counter underflow at:
Feb 19 15:46:35
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote:
> Fix the damn locking, already.
Fast as I can.
Robert Love
-
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, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote:
> inotify, bitches
/me does "pick a random function, find a race" again.
> +/*
> + * inode_add_watch - add a watch to the given inode
> + *
> + * Callers must hold dev->lock, because we call inode_find_dev().
> + */
> +static int
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
> Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
arch/sparc64/Kconfig | 13
dri
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love [EMAIL PROTECTED]
arch/sparc64/Kconfig | 13
drivers/char/Kconfig
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote:
inotify, bitches
/me does pick a random function, find a race again.
+/*
+ * inode_add_watch - add a watch to the given inode
+ *
+ * Callers must hold dev-lock, because we call inode_find_dev().
+ */
+static int
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote:
Fix the damn locking, already.
Fast as I can.
Robert Love
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
ption (FORK_CONNECTOR) to
> enable the fork connector (or disable) when compiling the kernel. To
> work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> has been tested on a 2.6.11-rc3-mm2 kernel with two user space
> applications connected.
>
> It is us
drawback is that even if nobody listens, a message is send. I
don't know how to avoid that. I added an option (FORK_CONNECTOR) to
enable the fork connector (or disable) when compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.11-rc3-mm2
drawback is that even if nobody listens, a message is send. I
don't know how to avoid that. I added an option (FORK_CONNECTOR) to
enable the fork connector (or disable) when compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.11-rc3-mm2
) to
enable the fork connector (or disable) when compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.11-rc3-mm2 kernel with two user space
applications connected.
It is used by ELSA to manage group of processes in user space
On Mon, Feb 14, 2005 at 09:26:49AM +0100, Guillaume Thouvenin wrote:
>
> I'm using kobject because it allows to notify user space application by
> sending an event and as I need to send a kernel event (fork event) to a
> user space application I thought about kobject. Do you think that it's
>
2.6.11-rc3-mm2
# Fri Feb 11 08:56:56 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
#
# General
On Mon, 2005-02-14 at 13:01 +0100, Guillaume Thouvenin wrote:
> This patch removes unreachable code in cn_netlink_send() function.
The code can be reach via
nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
So the patch is wrong
Sorry for that
Guillaume
-
To unsubscribe
This patch removes unreachable code in cn_netlink_send() function.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
--- drivers/connector/connector.c.orig 2005-02-14 12:52:32.0 +0100
+++ drivers/connector/connector.c 2005-02-14 12:52:44.0 +0100
@@ -119,11 +119,6 @@
On Fri, 2005-02-11 at 11:11 -0800, Greg KH wrote:
> > + char *kobj_path = NULL;
> > + char *action_string = NULL;
> > + char **envp = NULL;
> > + char ppid_string[FORK_BUFFER_SIZE];
> > + char cpid_string[FORK_BUFFER_SIZE];
> > +
> > + if (!uevent_sock)
> > + return;
> > +
On Fri, 2005-02-11 at 11:11 -0800, Greg KH wrote:
+ char *kobj_path = NULL;
+ char *action_string = NULL;
+ char **envp = NULL;
+ char ppid_string[FORK_BUFFER_SIZE];
+ char cpid_string[FORK_BUFFER_SIZE];
+
+ if (!uevent_sock)
+ return;
+
+
This patch removes unreachable code in cn_netlink_send() function.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
--- drivers/connector/connector.c.orig 2005-02-14 12:52:32.0 +0100
+++ drivers/connector/connector.c 2005-02-14 12:52:44.0 +0100
@@ -119,11 +119,6 @@
On Mon, 2005-02-14 at 13:01 +0100, Guillaume Thouvenin wrote:
This patch removes unreachable code in cn_netlink_send() function.
The code can be reach via
nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - sizeof(*nlh));
So the patch is wrong
Sorry for that
Guillaume
-
To unsubscribe from
]
Memory at e780 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at effe [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc3
On Mon, Feb 14, 2005 at 09:26:49AM +0100, Guillaume Thouvenin wrote:
I'm using kobject because it allows to notify user space application by
sending an event and as I need to send a kernel event (fork event) to a
user space application I thought about kobject. Do you think that it's
not the
Ingo Molnar wrote:
> the pro applications will always want to have a 100% guarantee (it
> really sucks to generate a nasty audio click during a live performance)
... and the "generic kernels" distributions use will follow just
as swiftly, as soon as the feature appears stable enough. It even
Ingo Molnar wrote:
the pro applications will always want to have a 100% guarantee (it
really sucks to generate a nasty audio click during a live performance)
... and the generic kernels distributions use will follow just
as swiftly, as soon as the feature appears stable enough. It even
makes
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>>
>> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
>> It seems that nothing else is going to come along and this is completely
>> encapsulated.
>
>
Hi,
Yuval Tanny wrote:
> Andrew Morton wrote:
>>cachefs-filesystem.patch
>> CacheFS filesystem
> ...
as you mention cachefs - know what's the status of supporting nfs?
Or is the project as dead as the mailing-list?
Is there any whole-in-one patch relative to vanilla-sources,
at best including
Hi,
Yuval Tanny wrote:
Andrew Morton wrote:
cachefs-filesystem.patch
CacheFS filesystem
...
as you mention cachefs - know what's the status of supporting nfs?
Or is the project as dead as the mailing-list?
Is there any whole-in-one patch relative to vanilla-sources,
at best including
Christoph Hellwig [EMAIL PROTECTED] writes:
On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
- Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
It seems that nothing else is going to come along and this is completely
encapsulated.
Even if we
On Fri, Feb 11, 2005 at 06:49:05PM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > > Yes. There's also the whole soft limit thing.
> > >
> > > i'm curious, how does this 'per-app' rlimit thing work? If a user has
> > > jackd installed and runs it from X
On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote:
> On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> > >RT-LSM introduces architectural problems in the form of bogus API. And
> >
> > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> > introduce *any* API
On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> >RT-LSM introduces architectural problems in the form of bogus API. And
>
> that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> introduce *any* API whatsoever - it simply allows software to call
> various existing
On Fri, Feb 11, 2005 at 04:08:40PM +0100, Guillaume Thouvenin wrote:
> +void kobject_fork(struct kobject *kobj, pid_t parent, pid_t child)
> +{
> +#ifdef CONFIG_KOBJECT_UEVENT
No, provide two different functions. In a header file make it a static
inline function that does nothing if this option
On Fri, Feb 11, 2005 at 10:53:27AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> > >
> > > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> > > destroys the careful balance of
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > > Yes. There's also the whole soft limit thing.
> >
> > i'm curious, how does this 'per-app' rlimit thing work? If a user has
> > jackd installed and runs it from X unprivileged, how does it get the
> > elevated rlimit?
>
> It needs a setuid
>introduced. See devfs. And I think the adoption barrier thing is a red
>herring as well: the current users are by and large compiling their
>own RT-tuned kernels.
not true. most people are using kernels built for specialized distros
or addons, such as CCRMA, Demudi, Ubuntu, or dyne:bolic.
--p
-
In fs/Kconfig,
See "Documentation/filesystems/fscache.txt for more information." and
"See Documentation/filesystems/cachefs.txt for more information."
Should be changed to:
"See Documentation/filesystems/caching/fscache.txt for more
information." and "See
On Fri, 2005-02-11 at 00:54 -0800, Andrew Morton wrote:
> > I tested this patch on a 2.6.11-rc3-mm2 kernel and there is a little
> > overhead when I compile a Linux kernel:
> >
> >#time sh -c 'make O=/home/guill/build/k2610 bzImage &&
> >
This patch adds the output interface control to VR41xx SIU driver.
And obsolete function for VR41xx SIU is removed.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/casio-e55/setup.c
a/arch/mips/vr41xx/casio-e55/setup.c
---
On Fri, 2005-02-11 at 00:54 -0800, Andrew Morton wrote:
> > I tested this patch on a 2.6.11-rc3-mm2 kernel and there is a little
> > overhead when I compile a Linux kernel:
> >
> >#time sh -c 'make O=/home/guill/build/k2610 bzImage &&
> >
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> >
> > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> > destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> > can be useful if you _need_ a
On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
>
> think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> can be useful if you _need_ a scheduling guarantee due to physical
> constraints, and it
On Fri, Feb 11, 2005 at 10:04:19AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > So the comparison boils down to putting a magic gid in a sysfs
> > file/module parameter or setting an rlimit with standard tools (PAM,
> > etc). I'm really boggled that anyone could
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> So the comparison boils down to putting a magic gid in a sysfs
> file/module parameter or setting an rlimit with standard tools (PAM,
> etc). I'm really boggled that anyone could prefer the former,
> especially since we had almost this exact debate
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> Read more closely: there are two independent limits in the patch,
> RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice
> without SCHED_FIFO.
ok, indeed.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > i disagree that desktop performance tomorrow will necessarily have to
> > utilize SCHED_FIFO. Today's desktop audio applications perform quite
> > good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
> > interactivity/latency fixes
On Fri, Feb 11, 2005 at 09:48:43AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Here's Chris' patch for reference:
> >
> > http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80
>
> how does this patch solve the separation of 'negative nice
wkward. Why not just feed that kobject you have there into
> > kobject_uevent()?
>
> Like Andrew suggested, I wrote a new patch (tested on 2.6.11-rc3-mm2)
> that notifies to user space application the creation of a new process
> when kernel forks by using the kobje
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> Here's Chris' patch for reference:
>
> http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80
how does this patch solve the separation of 'negative nice values' and
'RT priority rlimits'? In one piece of code it handles the rlimit
On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
>
> > I think it's important to recognize that we're trying to address an
> > issue that has a much wider potential audience than pro audio users,
> > and not very far off - what is high end audio performance today will
> > be expected
On Fri, Feb 11, 2005 at 08:54:17AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Eh? Chris Wright's original rlimits patch was very straightforward
> > [...]
>
> the problem is that it didnt solve the problem (unprivileged user can
> lock up the system) in any
On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
> an "RT priorities rlimit" is still not adequate as a desktop solution,
> because it still allows the box to be locked up. Also, if it turns out
> to be a mistake then it's already codified into the ABI, while RT-LSM is
> much less
ack has its own watchdog thread which
should solve most of the lockup situations. Lets not overdesign the
solution, especially when we dont yet know how the problem really looks
like.
or an even simpler solution for the lockup problem would be a
kernel-based RT watchdog. In fact 2.6.11-rc3-mm2 alrea
1 - 100 of 176 matches
Mail list logo
