headers
Roman Zippel | 1 Sep 2005 01:01

RE: FW: [RFC] A more general timeout specification

Hi,

On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:

> >Why is that needed in a _general_ timeout API? What exactly makes it so
> >useful for everyone and not just more complex for everyone?
> 
> Because if a system call gets a timeout specification it needs to
> verify its correctness first. Instead of doing that at the point
> where it goes to sleep, that could be deep in an atomic section,
> we provide a separate function [timeout_validate()] which is the
> one you mention, to do that.
> 
> Usefulness: (see the rationale in the patch), but in a nutshell;
> most POSIX timeout specs have to be absolute in CLOCK_REALTIME
> (eg: pthread_mutex_timed_lock()). Current kernel needs the timeout
> relative, so glibc calls the kernel/however gets the time, computes
> relative times and syscalls. Race conditions, overhead...etc. 
> 
> This mechanism supports both. That's why it is more general.

Your patch basically only mentions fusyn, why does it need multiple clock 
sources? Why is not sufficient to just add a relative/absolute version, 
which convert the time at entry to kernel time?

bye, Roman
Permalink | Reply | 0 comments |
headers
Rodney Gordon II | 1 Sep 2005 01:03
Picon
Favicon

Re: 2.6.13-ck1

On Thu, Sep 01, 2005 at 08:47:36AM +1000, Con Kolivas wrote:
> On Thu, 1 Sep 2005 06:07 am, daniel mclellan wrote:
> > Yes.
> >
> >
> > Linux yavanna 2.6.13-ckx1 #1 Tue Aug 30 04:03:25 EST 2005 x86_64 AMD
> > Athlon(tm) 64 FX-53 Processor AuthenticAMD GNU/Linux
> >
> > On Wednesday 31 August 2005 14:49, Rodney Gordon II wrote:
> > > On Mon, Aug 29, 2005 at 05:03:24PM +1000, Con Kolivas wrote:
> > > > These are patches designed to improve system responsiveness and
> > > > interactivity. It is configurable to any workload but the default ck*
> > > > patch is aimed at the desktop and ck*-server is available with more
> > > > emphasis on serverspace.
> > > >
> > > >
> > > > Apply to 2.6.13
> > > > http://ck.kolivas.org/patches/2.6/2.6.13/2.6.13-ck1/patch-2.6.13-ck1.bz
> > > >2 or development version:
> > > > http://ck.kolivas.org/patches/2.6/2.6.13/2.6.13-ck1/patch-2.6.13-ck1+.b
> > > >z2
> > > >
> > > > or server version:
> > > > http://ck.kolivas.org/patches/2.6/2.6.13/2.6.13-ck1/patch-2.6.13-ck1-se
> > > >rv er.bz2
> > >
> > > I am having odd lockup problems with just the non-+ 'stable' ck lately..
> > > Trying a large copy will often lock my disk I/O up and I have to do a
> > > hard reboot. Nothing shows in logs..
> > >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Friesen | 1 Sep 2005 01:06
Favicon

Re: FW: [RFC] A more general timeout specification

Perez-Gonzalez, Inaky wrote:

>>I can get the first sleep.  Suppose I oversleep by X nanoseconds.  I
>>wake, and get an opaque timeout back.  How do I ask for the new wake
>>time to be "endtime + INTERVAL"?
> 
> 
> endtime.ts += INTERVAL
> [we all know opaque is relative too] 

Heh. Okay, then what are the rules about what I'm allowed to do with 
endtime?  Joe mentioned there was a bit in there somewhere to denote 
absolute time.

> Or better, use itimers :)

I as actually thinking in terms of implementing itimers on top of your 
new API.

Chris
Permalink | Reply | 0 comments |
headers
Perez-Gonzalez, Inaky | 1 Sep 2005 01:17
Picon
Favicon

RE: FW: [RFC] A more general timeout specification

>From: Christopher Friesen [mailto:cfriesen <at> nortel.com]
>Perez-Gonzalez, Inaky wrote:
>
>>>I can get the first sleep.  Suppose I oversleep by X nanoseconds.  I
>>>wake, and get an opaque timeout back.  How do I ask for the new wake
>>>time to be "endtime + INTERVAL"?
>>
>>
>> endtime.ts += INTERVAL
>> [we all know opaque is relative too]
>
>Heh. Okay, then what are the rules about what I'm allowed to do with
>endtime?  Joe mentioned there was a bit in there somewhere to denote
>absolute time.

Well, it doesn't really matter. The bit in endtime.clock_id (highest,
AFAIR) says if it is absolute or not, but because adding a relative
value to a value maintains its condition (absolute or relative), it
is not a concern. Just add it.

Unless I am missing something really basic, of course.

>> Or better, use itimers :)
>
>I as actually thinking in terms of implementing itimers on top of your
>new API.

Heh, got me.

-- Inaky
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego Calleja | 1 Sep 2005 01:22
Picon

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

El Wed, 31 Aug 2005 14:27:47 -0600,
"Jeff V. Merkey" <jmerkey <at> soleranetworks.com> escribió:

>  
> NOTE! This copyright does *not* cover user programs that use kernel
>  services by normal system calls - this is merely considered normal use
>  of the kernel, and does *not* fall under the heading of "derived work".
>  Also note that the GPL below is copyrighted by the Free Software
>  Foundation, but the instance of code that it refers to (the linux
>  kernel) is copyrighted by me and others who actually wrote it.

So, that means that DSFS runs on userspace? (We can't see the source
so it'd be nice to know how DSFS works)

Also, I'm curious about this piece of code on your patch:
ftp://ftp.soleranetworks.com/pub/dsfs/datascout-only-2.6.9-06-28-05.patch

-		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
-		       mod->name, license);
+//		printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
+//		       mod->name, license);

I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
Permalink | Reply | 13 comments |
headers
Perez-Gonzalez, Inaky | 1 Sep 2005 01:24
Picon
Favicon

RE: FW: [RFC] A more general timeout specification

>From: Roman Zippel [mailto:zippel <at> linux-m68k.org]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Usefulness: (see the rationale in the patch), but in a nutshell;
>> most POSIX timeout specs have to be absolute in CLOCK_REALTIME
>> (eg: pthread_mutex_timed_lock()). Current kernel needs the timeout
>> relative, so glibc calls the kernel/however gets the time, computes
>> relative times and syscalls. Race conditions, overhead...etc.
>>
>> This mechanism supports both. That's why it is more general.
>
>Your patch basically only mentions fusyn, why does it need multiple
clock
>sources?

I cannot produce (top of my head) any other POSIX API calls that
allow you to specify another clock source, but they are there,
somewhere. If I am to introduce a new API, I better make it 
flexible enough so that other subsystems can use it for more stuff
other than...

>Why is not sufficient to just add a relative/absolute version,
>which convert the time at entry to kernel time?

...adding more versions that add complexity and duplicate
code in many different places (user-to-kernel copy, syscall entry 
points, timespec validation). And the minute you add a clock_id
you can steal some bits for specifying absolute/relative (or vice
versa), so it is almost a win-win situarion.
(Continue reading)

Permalink | Reply | 9 comments |
headers
H. Peter Anvin | 1 Sep 2005 01:27
Favicon

Re: [Patch] Support UTF-8 scripts

Followup to:  <42FDE286.40707 <at> v.loewis.de>
By author:    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin <at> v.loewis.de>
In newsgroup: linux.dev.kernel
>
> This patch adds support for UTF-8 signatures (aka BOM, byte order
> mark) to binfmt_script. Files that start with EF BF FF # ! are now
> recognized as scripts (in addition to files starting with # !).
> 
> With such support, creating scripts that reliably carry non-ASCII
> characters is simplified. Editors and the script interpreter can
> easily agree on what the encoding of the script is, and the
> interpreter can then render strings appropriately. Currently,
> Python supports source files that start with the UTF-8 signature;
> the approach would naturally extend to Perl to enhance/replace
> the "use utf8" pragma. Likewise, Tcl could use the UTF-8 signature
> to reliably identify UTF-8 source code (instead of assuming
> [encoding system] for source code).
> 

BOM should not be used in UTF-8.  In fact, it shouldn't be used at
all.

	-hpa
Permalink | Reply | 0 comments |
headers
Andi Kleen | 1 Sep 2005 01:29
Picon

Re: MAX_ARG_PAGES has no effect?

Ingo Molnar <mingo <at> elte.hu> writes:
> 
> MAX_ARG_PAGES should work just fine. I think the 'getconf ARG_MAX' 
> output is hardcoded. (because the kernel does not provide the 
> information dynamically)

Perhaps it would be a good idea to make it a sysctl. Is there 
any reason it should be hardcoded?  I cannot think of any.

Ok if someone lowers the sysctl then execve has to handle
the case of the args/environment possibly not fitting anymore,
but that should be easy.

-Andi
Permalink | Reply | 3 comments |
headers
Roman Zippel | 1 Sep 2005 01:50

RE: FW: [RFC] A more general timeout specification

Hi,

On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:

> I cannot produce (top of my head) any other POSIX API calls that
> allow you to specify another clock source, but they are there,
> somewhere. If I am to introduce a new API, I better make it 
> flexible enough so that other subsystems can use it for more stuff
> other than...

So we have to deal at kernel level with every broken timeout specification 
that comes along?

> >Why is not sufficient to just add a relative/absolute version,
> >which convert the time at entry to kernel time?
> 
> ...adding more versions that add complexity and duplicate
> code in many different places (user-to-kernel copy, syscall entry 
> points, timespec validation). And the minute you add a clock_id
> you can steal some bits for specifying absolute/relative (or vice
> versa), so it is almost a win-win situarion.

What "more versions" are you talking about? When you convert a user time 
to kernel time you can automatically validate it and later you can use 
standard kernel APIs, so you don't have to add even more API bloat.

bye, Roman
Permalink | Reply | 8 comments |
headers
Eric Van Hensbergen | 1 Sep 2005 01:58
Picon
Gravatar

[PATCH] v9fs: Support to force umount

[PATCH] v9fs: Support to force umount

Support for force umount

Signed-off-by: Latchesar Ionkov <lucho <at> ionkov.net>
Signed-off-by: Eric Van Hensbergen <ericvh <at> gmail.com>

---
commit 3f92b2539fe581ee9011d687fbd43cebb641465e
tree cd34696129c3b636b85578f659f260100196dee1
parent 83f1fe3d2adc3746d719e430d0a794de1f151c40
author Eric Van Hensbergen <ericvh <at> gmail.com> Wed, 31 Aug 2005 15:53:14
-0500
committer Eric Van Hensbergen <ericvh <at> gmail.com> Wed, 31 Aug 2005
15:53:14 -0500

 fs/9p/mux.c       |   20 ++++++++++++++++++++
 fs/9p/mux.h       |    1 +
 fs/9p/v9fs.c      |    9 +++++++++
 fs/9p/v9fs.h      |    4 +---
 fs/9p/vfs_super.c |    9 +++++++++
 5 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/fs/9p/mux.c b/fs/9p/mux.c
--- a/fs/9p/mux.c
+++ b/fs/9p/mux.c
 <at>  <at>  -331,6 +331,26  <at>  <at>  v9fs_mux_rpc(struct v9fs_session_info *v
 }

 /**
(Continue reading)

Permalink | Reply | 0 comments |

Gmane