New extension: Inotify

[Arnaud Le Blanc]

Hi,

I have written an extension for the Linux' Inotify API:
http://en.wikipedia.org/wiki/Inotify

The extension exposes the inotify functions inotify_init(),
inotify_add_watch() and inotify_rm_watch().

As the C inotify_init() function returns a file descriptor, PHP's
inotify_init() returns a stream resource, so you can use the standard
stream functions on it, like stream_select(), stream_set_blocking(),
and also fclose(), used to close an inotify instance and all its
watches.

It also exports two additional functions:

inotify_queue_len(resource $inotify_instance), which returns a number
upper than zero if their are waiting events

inotify_read(resource $inotify_instance), which replaces the C way
of reading inotify events. It returns arrays of events, in which keys
represents the members of the inotify_event structure.

The code can be found here, released under the PHP license:
http://php-inotify.s3.amazonaws.com/php-inotify-0.1.tar.bz2

Regards,

Arnaud

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Alexey Zakhlestin]

The only serious problem I see: PHP License is not compatible with
GPL, and lnotify is a part of Linux kernel, which is GPL-licensed.
Which means, that this extension can't be part of pecl.

There were previous talks about making separate extension-repository
for GPL-based extensions, but those never resulted in action, as far
as I remember.


On Fri, Jul 4, 2008 at 9:59 AM, Arnaud.lb <arnaud.lb@...> wrote:

> Hi,
>
> I have written an extension for the Linux' Inotify API:
> http://en.wikipedia.org/wiki/Inotify
>
> The extension exposes the inotify functions inotify_init(),
> inotify_add_watch() and inotify_rm_watch().
>
> As the C inotify_init() function returns a file descriptor, PHP's
> inotify_init() returns a stream resource, so you can use the standard
> stream functions on it, like stream_select(), stream_set_blocking(),
> and also fclose(), used to close an inotify instance and all its
> watches.
>
> It also exports two additional functions:
>
> inotify_queue_len(resource $inotify_instance), which returns a number
> upper than zero if their are waiting events
>
> inotify_read(resource $inotify_instance), which replaces the C way
> of reading inotify events. It returns arrays of events, in which keys
> represents the members of the inotify_event structure.
>
> The code can be found here, released under the PHP license:
> http://php-inotify.s3.amazonaws.com/php-inotify-0.1.tar.bz2
>
> Regards,
>
> Arnaud
>
> --
> PECL development discussion Mailing List (http://pecl.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Lars Strojny-2]

Hi Alex,

Am Freitag, den 04.07.2008, 12:00 +0400 schrieb Alexey Zakhlestin:
> The only serious problem I see: PHP License is not compatible with
> GPL, and lnotify is a part of Linux kernel, which is GPL-licensed.
> Which means, that this extension can't be part of pecl.

It would be possible to wrap gamin
(http://www.gnome.org/~veillard/gamin/). It is LGPL so not optimal but
as far as I know LGPL is alright.

cu, Lars

[Arnaud Le Blanc]

> lnotify is a part of Linux kernel, which is GPL-licensed.

The inotify functions are a set of syscalls, just like open() and
close(). Using open() in your code does not force you to release it
under the GPL ;) That's the same situation with inotify.

The only  problem I see is that I included an inotify-nosys.h header
in the archive to allow the extension to compile even if the system's
libc is not recent enougth to have the required symbols and includes.
But this file is not used at all on recent systems, so I removed it.

A new version without any byte of GPL code is available here:
http://php-inotify.s3.amazonaws.com/inotify-0.1.1.tar.bz2

Regards

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Antony Dovgal-3]

On 04.07.2008 22:19, Arnaud LB wrote:
>> lnotify is a part of Linux kernel, which is GPL-licensed.
>
> The inotify functions are a set of syscalls, just like open() and
> close(). Using open() in your code does not force you to release it
> under the GPL ;) That's the same situation with inotify.

open() and close() exist in other (non-GPL) systems, i.e. your code
doesn't depend on any certain kernel/library, hence its license doesn't
affect your code.

In case of Inotify, you code was clearly done especially for Inotify and
fully depends on Inotify, which to my understanding means that this is a
"derivative work" and it should be GPLed, too, unfortunately.

We've had an opposite case: ext/readline can link to both GPL-ed readline and
BSD-licensed libedit, which allows us to license it under PHP license.

--
Wbr,
Antony Dovgal

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Arnaud Le Blanc]

On Tue, Jul 8, 2008 at 3:31 PM, Antony Dovgal <tony@...> wrote:

> On 04.07.2008 22:19, Arnaud LB wrote:
>>>
>>> lnotify is a part of Linux kernel, which is GPL-licensed.
>>
>> The inotify functions are a set of syscalls, just like open() and
>> close(). Using open() in your code does not force you to release it
>> under the GPL ;) That's the same situation with inotify.
>
> open() and close() exist in other (non-GPL) systems, i.e. your code doesn't
> depend on any certain kernel/library, hence its license doesn't affect your
> code.
>
> In case of Inotify, you code was clearly done especially for Inotify and
> fully depends on Inotify, which to my understanding means that this is a
> "derivative work" and it should be GPLed, too, unfortunately.
>
> We've had an opposite case: ext/readline can link to both GPL-ed readline
> and BSD-licensed libedit, which allows us to license it under PHP license.
>
> --
> Wbr, Antony Dovgal
>

I fully understand the purpose of these restrictions on the license of
the extensions you host on PECL. But I think that my extension can be
released under the PHP license without violating any license.

It does not link to any user-land GPL'd library. Inotify is not a
library like readline. Actually inotify is a set of 3 syscalls named
inotify_init, inotify_add_watch and inotify_rm_watch. The only
user-land code of inotify is in the glibc, and it may looks something
like that:

int inotify_init () {
        return syscall (SYS_inotify_init);
}

Where SYS_inotify_init is the number for the inotif_init syscall. This
is so generic that the glibc writes these functions at compile time
from a list of syscall names and numbers.

So, yes, my code links and depends on the glibc (which is LGPL)
because it uses these 3 convenience functions instead of using
directly the syscall() function. I think it does not cause any problem
to the PHP license, but if it does I may use syscall() directly or
write these functions myself to not depend on any specific libc.
However there are chances that other non-(L)GPL libcs export (or will
export) the inotify functions, which would make my extension to not
depend on any specific libc.

And for the syscall part, Linux license [1] says:

 "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".

My extension is in this case, it uses only normal system calls, and is
not a derived work of Linux or Inotify.

[1] http://www.kernel.org/pub/linux/kernel/COPYING

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Rasmus Lerdorf]

Tony, I think this case is fine.  Calls to glibc and the kernel are
fine.  Linux has an explicit exception for the kernel calls and glibc is
LGPL'ed, so we are in the clear here.

-Rasmus

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Antony Dovgal-3]

On 09.07.2008 07:44, Rasmus Lerdorf wrote:
> Tony, I think this case is fine.  Calls to glibc and the kernel are
> fine.  Linux has an explicit exception for the kernel calls and glibc is
> LGPL'ed, so we are in the clear here.

Okay, I didn't know that, thanks.

--
Wbr,
Antony Dovgal

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Derick Rethans]

On Wed, 9 Jul 2008, Arnaud LB wrote:

> On Tue, Jul 8, 2008 at 3:31 PM, Antony Dovgal <tony@...> wrote:
> > On 04.07.2008 22:19, Arnaud LB wrote:
> >>>
> >>> lnotify is a part of Linux kernel, which is GPL-licensed.
> >>
> >> The inotify functions are a set of syscalls, just like open() and
> >> close(). Using open() in your code does not force you to release it
> >> under the GPL ;) That's the same situation with inotify.
> >
> > open() and close() exist in other (non-GPL) systems, i.e. your code doesn't
> > depend on any certain kernel/library, hence its license doesn't affect your
> > code.
> >
> > In case of Inotify, you code was clearly done especially for Inotify and
> > fully depends on Inotify, which to my understanding means that this is a
> > "derivative work" and it should be GPLed, too, unfortunately.
> >
> > We've had an opposite case: ext/readline can link to both GPL-ed readline
> > and BSD-licensed libedit, which allows us to license it under PHP license.

<snip>

> So, yes, my code links and depends on the glibc (which is LGPL)
> because it uses these 3 convenience functions instead of using
> directly the syscall() function. I think it does not cause any problem
> to the PHP license, but if it does I may use syscall() directly or
> write these functions myself to not depend on any specific libc.
> However there are chances that other non-(L)GPL libcs export (or will
> export) the inotify functions, which would make my extension to not
> depend on any specific libc.

Perhaps you might want to check whether ulibc has it, if that's the case
even this should be in the clear.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Arnaud Le Blanc]

On Wed, Jul 9, 2008 at 9:32 AM, Derick Rethans <derick@...> wrote:

>> So, yes, my code links and depends on the glibc (which is LGPL)
>> because it uses these 3 convenience functions instead of using
>> directly the syscall() function. I think it does not cause any problem
>> to the PHP license, but if it does I may use syscall() directly or
>> write these functions myself to not depend on any specific libc.
>> However there are chances that other non-(L)GPL libcs export (or will
>> export) the inotify functions, which would make my extension to not
>> depend on any specific libc.
>
> Perhaps you might want to check whether ulibc has it, if that's the case
> even this should be in the clear.
>
> regards,
> Derick
>
> --
> Derick Rethans
> http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
>

Yes uclibc [1], dietlibc [2] and klibc [3] have it.

[1] http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/common/inotify.c?rev=16821&view=markup
[2] http://www.google.com/codesearch?hl=fr&q=show:RJKoCQ4ycug:aHidVsNf4-k:0udVqc7Q9LA&sa=N&ct=rd&cs_p=http://kernel.osuosl.org/pub/linux/libs/dietlibc/dietlibc-0.30.tar.gz&cs_f=dietlibc-0.30/syscalls.s/inotify_init.S&start=1
[3] http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob_plain;f=usr/klibc/SYSCALLS.def;hb=HEAD

Regards,

Arnaud

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Arnaud Le Blanc]

Hi,

Since all seems to be Ok with this extension I made a PECL account request a
week ago, but I did not received any news. Could someone review my request
please ?

Regards,

Arnaud

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Pierre Joye]

Hi Arnaud,

On Wed, Jul 16, 2008 at 6:18 PM, Arnaud Le Blanc <arnaud.lb@...> wrote:
> Hi,
>
> Since all seems to be Ok with this extension I made a PECL account request a
> week ago, but I did not received any news. Could someone review my request
> please ?

Have you requested a CVS account as well?


Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Arnaud Le Blanc]

On Wednesday 16 July 2008 22:34:18 Pierre Joye wrote:
> Hi Arnaud,
>
> On Wed, Jul 16, 2008 at 6:18 PM, Arnaud Le Blanc <arnaud.lb@...>
wrote:
> > Hi,
> >
> > Since all seems to be Ok with this extension I made a PECL account request
a
> > week ago, but I did not received any news. Could someone review my request
> > please ?
>
> Have you requested a CVS account as well?
>

Hi Pierre,

I already have a SVN repository at berlios.de, so I do not checked the "Need a
CVS account" checkbox. But I can move to PECL's CVS if it is required in
order to publish my extension in PECL.

Regards

Arnaud

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Olivier Hill-2]

On Wed, Jul 16, 2008 at 9:08 PM, Arnaud Le Blanc <arnaud.lb@...> wrote:
>
> I already have a SVN repository at berlios.de, so I do not checked the "Need a
> CVS account" checkbox. But I can move to PECL's CVS if it is required in
> order to publish my extension in PECL.

Well.. it is highly recommended, as you can get peer reviews and real
open source development.

It's a good thing when people can fix bugs for you :)

Of course, you stay the lead person and nobody is going to change your
code for no reason.

Regards,
Olivier

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Arnaud Le Blanc]

On Thursday 17 July 2008 03:14:57 Olivier Hill wrote:
> On Wed, Jul 16, 2008 at 9:08 PM, Arnaud Le Blanc <arnaud.lb@...>
wrote:
> >
> > I already have a SVN repository at berlios.de, so I do not checked
the "Need a

> > CVS account" checkbox. But I can move to PECL's CVS if it is required in
> > order to publish my extension in PECL.
>
> Well.. it is highly recommended, as you can get peer reviews and real
> open source development.
>
> It's a good thing when people can fix bugs for you :)
>
> Of course, you stay the lead person and nobody is going to change your
> code for no reason.
>

Ok, so I will need a CVS account too :)

Regards,

Arnaud

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Antony Dovgal-3]

On 17.07.2008 05:27, Arnaud Le Blanc wrote:
> Ok, so I will need a CVS account too :)

Then request it here, please: http://php.net/cvs-php.php

--
Wbr,
Antony Dovgal

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Arnaud Le Blanc]

On Thursday 17 July 2008 09:35:18 Antony Dovgal wrote:
> On 17.07.2008 05:27, Arnaud Le Blanc wrote:
> > Ok, so I will need a CVS account too :)
>
> Then request it here, please: http://php.net/cvs-php.php
>

Thanks, my account has been created :)

--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Nicos-4]

Thats a good news. Welcome aboard.

--

Regards.

--
Nicolas Chaillan | GROUPAKT.fr | UIN : 16549830
nicos@... | info@... | http://www.groupakt.fr
http://www.fmsakt.fr | http://www.prospecttel.com
Directeur général.

""Arnaud Le Blanc"" <arnaud.lb@...> a écrit dans le message de groupe
de discussion : 200807171937.22601.arnaud.lb@......
> On Thursday 17 July 2008 09:35:18 Antony Dovgal wrote:
>> On 17.07.2008 05:27, Arnaud Le Blanc wrote:
>> > Ok, so I will need a CVS account too :)
>>
>> Then request it here, please: http://php.net/cvs-php.php
>>
>
> Thanks, my account has been created :)


--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php