|
From: John M. <tt...@te...> - 2005-07-25 14:37:11
Attachments:
valgrind-inotify.patch
|
Yo, I've attached a patch that wraps the inotify system calls on x86 linux. Please consider this for the next version of valgrind. Thanks, John McCutchan |
|
From: Tom H. <to...@co...> - 2005-07-25 14:45:19
|
In message <1122302613.2226.5.camel@localhost>
John McCutchan <tt...@te...> wrote:
> I've attached a patch that wraps the inotify system calls on x86 linux.
> Please consider this for the next version of valgrind.
I can't see any sign of these calls in the 2.6.12 kernel source. Are
they part of the standard kernel?
If not where do we find the source for them? Are the system call
numbers well defined or might the official kernel reuse them for
something else? I notice that you haven't defined any constants
for the call numbers and have just put in manifest constants?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christian P. <tr...@ge...> - 2005-07-25 15:07:39
|
On Monday 25 July 2005 16:45, Tom Hughes wrote: > In message <1122302613.2226.5.camel@localhost> > > John McCutchan <tt...@te...> wrote: > > I've attached a patch that wraps the inotify system calls on x86 linux. > > Please consider this for the next version of valgrind. > > I can't see any sign of these calls in the 2.6.12 kernel source. Are > they part of the standard kernel? > > If not where do we find the source for them? Are the system call > numbers well defined or might the official kernel reuse them for > something else? I notice that you haven't defined any constants > for the call numbers and have just put in manifest constants? > > Tom Hmm.... looks like a patch, but a very promising one: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.24/inotify= =2D0.24-rml-2.6.13-rc2-4.patch Articles about: http://kerneltrap.org/node/3847 http://www-128.ibm.com/developerworks/linux/library/l-inotify.html?ca=3Ddgr= =2Dlnxw52Inotify http://lwn.net/Articles/104343/ Although, I thought about playing around with it a bit, too(!). The gentoo-sources Linux kernel includes this patch already. Googling aroun= d=20 has shown me that debian *seems* to have it too. Regards, Christian Parpart. =2D-=20 16:54:56 up 124 days, 6:02, 2 users, load average: 3.61, 3.43, 3.83 |
|
From: John M. <tt...@te...> - 2005-07-25 15:08:50
|
On Mon, 2005-07-25 at 15:45 +0100, Tom Hughes wrote: > In message <1122302613.2226.5.camel@localhost> > John McCutchan <tt...@te...> wrote: > > > I've attached a patch that wraps the inotify system calls on x86 linux. > > Please consider this for the next version of valgrind. > > I can't see any sign of these calls in the 2.6.12 kernel source. Are > they part of the standard kernel? > Inotify will be part of 2.6.13 > If not where do we find the source for them? Are the system call > numbers well defined or might the official kernel reuse them for > something else? I notice that you haven't defined any constants > for the call numbers and have just put in manifest constants? The system call numbers are defined in 2.6.13. They are not going to be reused for anything. John |
|
From: Dirk M. <dm...@gm...> - 2005-07-25 15:13:07
|
On Monday 25 July 2005 16:45, Tom Hughes wrote: > I can't see any sign of these calls in the 2.6.12 kernel source. Are > they part of the standard kernel? Its brand-new and will appear in 2.6.13 (its in vanilla tree starting with 2.6.13rc3 I think). > If not where do we find the source for them? Are the system call > numbers well defined or might the official kernel reuse them for > something else? They're the official ones. Dirk |
|
From: Tom H. <to...@co...> - 2005-07-25 15:10:12
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <1122302613.2226.5.camel@localhost>
> John McCutchan <tt...@te...> wrote:
>
>> I've attached a patch that wraps the inotify system calls on x86 linux.
>> Please consider this for the next version of valgrind.
>
> I can't see any sign of these calls in the 2.6.12 kernel source. Are
> they part of the standard kernel?
I've found it in the 2.6.13-rc3 source now. I notice that it's only
hooked in to the x86 system call table though.
I've updated our lists of system call numbers, and I'm just fixing up
a couple of things in your patch before committing it but I notice
that you've marked inotify_init as a blocking call but it doesn't look
like it should block. Can you clarify when it will block?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John M. <tt...@te...> - 2005-07-25 15:13:02
|
On Mon, 2005-07-25 at 16:10 +0100, Tom Hughes wrote: > In message <yek...@de...> > Tom Hughes <to...@co...> wrote: > > > In message <1122302613.2226.5.camel@localhost> > > John McCutchan <tt...@te...> wrote: > > > >> I've attached a patch that wraps the inotify system calls on x86 linux. > >> Please consider this for the next version of valgrind. > > > > I can't see any sign of these calls in the 2.6.12 kernel source. Are > > they part of the standard kernel? > > I've found it in the 2.6.13-rc3 source now. I notice that it's only > hooked in to the x86 system call table though. > It will be hooked into amd64 soon to. Nothing about the code is platform specific, but we are letting the platforms hook it up as they need. > I've updated our lists of system call numbers, and I'm just fixing up > a couple of things in your patch before committing it but I notice > that you've marked inotify_init as a blocking call but it doesn't look > like it should block. Can you clarify when it will block? :), I really didn't know what I was doing, but sys_open, and sys_futex (both which can create fd's like inotify_init) say they might block. So, I was trying to be conservative and added that. John McCutchan |
|
From: Tom H. <to...@co...> - 2005-07-25 15:23:06
|
In message <1122304763.4591.6.camel@localhost>
John McCutchan <tt...@te...> wrote:
> On Mon, 2005-07-25 at 16:10 +0100, Tom Hughes wrote:
>
>> I've updated our lists of system call numbers, and I'm just fixing up
>> a couple of things in your patch before committing it but I notice
>> that you've marked inotify_init as a blocking call but it doesn't look
>> like it should block. Can you clarify when it will block?
>
> :), I really didn't know what I was doing, but sys_open, and sys_futex
> (both which can create fd's like inotify_init) say they might block. So,
> I was trying to be conservative and added that.
Both open and futex can block - open if you are opening a pipe or
device or a network mounted file or something like that and futex
because that is it's job in life ;-)
I've committed inotify support based on your patch now anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John M. <tt...@te...> - 2005-07-25 15:28:17
|
On Mon, 2005-07-25 at 16:22 +0100, Tom Hughes wrote: > In message <1122304763.4591.6.camel@localhost> > John McCutchan <tt...@te...> wrote: > > > On Mon, 2005-07-25 at 16:10 +0100, Tom Hughes wrote: > > > >> I've updated our lists of system call numbers, and I'm just fixing up > >> a couple of things in your patch before committing it but I notice > >> that you've marked inotify_init as a blocking call but it doesn't look > >> like it should block. Can you clarify when it will block? > > > > :), I really didn't know what I was doing, but sys_open, and sys_futex > > (both which can create fd's like inotify_init) say they might block. So, > > I was trying to be conservative and added that. > > Both open and futex can block - open if you are opening a pipe or > device or a network mounted file or something like that and futex > because that is it's job in life ;-) > > I've committed inotify support based on your patch now anyway. > > Tom > |
|
From: John M. <tt...@te...> - 2005-07-25 15:28:46
|
On Mon, 2005-07-25 at 16:22 +0100, Tom Hughes wrote: > In message <1122304763.4591.6.camel@localhost> > John McCutchan <tt...@te...> wrote: > > > On Mon, 2005-07-25 at 16:10 +0100, Tom Hughes wrote: > > > >> I've updated our lists of system call numbers, and I'm just fixing up > >> a couple of things in your patch before committing it but I notice > >> that you've marked inotify_init as a blocking call but it doesn't look > >> like it should block. Can you clarify when it will block? > > > > :), I really didn't know what I was doing, but sys_open, and sys_futex > > (both which can create fd's like inotify_init) say they might block. So, > > I was trying to be conservative and added that. > > Both open and futex can block - open if you are opening a pipe or > device or a network mounted file or something like that and futex > because that is it's job in life ;-) > > I've committed inotify support based on your patch now anyway. Wicked. Thanks! John McCutchan |