Mail Archives: cygwin-apps/2001/09/02/18:47:34
Ralf Habacker wrote:
>>Ralf Habacker wrote:
>>
>>>Hi,
>>>has anybody thinked about the cygipc package, which is needed by
>>>
>>kde ? Should
>>
>>>this be integrated and if so in which category ?
>>>
>>>
>>This has been mentioned with respect to postgresql and kde.
>>Unfortunately, the answer is: "nothing we can do". That particular
>>dependency will remain "off book" (kinda like Social Security in the US
>>-- it's "real", but it doesn't "count")
>>
>>The problem is basically that the best is the enemy of the good (or in
>>this case, the merely adequate).
>>
>>The Right Thing To Do is to add full IPC support to cygwin itself.
>>There are a few folks thinking about this issue, and what it will
>>require. Among them: a streamlined daemon starter (cygrunsrv...), a
>>daemon to manage permissions and the shared objects themselves (Egor's
>>"cygwin daemon"?), and *a complete rewrite of IPC code without reference
>>to cygipc*. (This has to do with licensing issues; the original authors
>>of cygipc retain copyright, and seem to have disappeared -- therefore,
>>we can't contact them to encourage them to assign copyright to Cygnus.
>>
>
> The email adress if from france. I know a french developer, to which I have
> send the infos about these guys. Perhaps he can find out something.
Well, if Chris is right (and I assume he is) about the fact that the
cygipc code came from linux, then "these guys" can't really assign
copyright over to Red Hat *either*.
IOW, this code is covered by copyright owned by not only the two French
developers, but also an unknown number of unknown linux contributors.
All of those people must be tracked down, contacted, convinced to sign
over copyright to Red Hat,...
(Tangent; this tangled mess of overlapping and diverse copyrights is
touted by Linus Torvalds as one of the strengths of the linux kernel --
NOBODY owns a significant portion of it, not even him. So NOBODY can
EVER "sign over" ownership to a possibly malevolent corporate interest.
No matter what.)
Back to cygipc: so, this ain't gonna happen. If we want to have IPC
stuff directly in the cygwin kernel, "we" are going to have to write it
ourselves. (Unfortunately, I am most likely disallowed from helping, as
are a number of other people. "Contaminated" by exposure to the cygipc
code. How can anyone be sure that any code I contribute is not
influenced -- or even copied! -- from my knowledge of the cygipc internals?)
>
> I understand this complex problem only a little and I have some additional
> questions/remarks from my
> subjective view:
>
> pro packaging:
> 1. Which advantage has integrating cygipc into cygwin ?
> For kde2 as example I have no problem to use an additional package, because it
> depends
> on about 15 external libs. One more or less isn't very important.
> Are there performance issues, stability, maintainance or other reasons ?
> What about the needed time to integrate this ? When would this be ready for use
> ?
Well, currently we're in a "no new packages" freeze. Once that is
lifted, I can have a cygipc package ready for SOME OTHER MAINTAINER to
contribute in about a week. (I am not willing to personally contribute
cygipc, because I just can't handle another package...I'm swamped.)
> pro integrating
> 2. Is cygipc not distributed under the GPL ? Isn't that not enough to modify
> and use this code for cygwin, perhaps maintained as separate static lib,
> but linked into cygwin like the cygwin xfree team thinked about for the Xextlib
> ?
No, you misunderstand two issues: licensing and cygipc client/server
dualism.
1) licensing: anything that is a part of the cygwin kernel ITSELF must
have copyright ownership assigned to Red Hat. This is because a
copyright OWNER is allowed to distribute the software under multiple
licenses; Red Hat distributes the cygwin kernel under BOTH GPL and a
proprietary license.
Now, as a NON copyright owner, you or I have the right to *redistribute*
*GPL* code -- but ONLY under the GPL.
Thus, if the cygipc *Server* code (more on this later) is actually
INCORPORATED into the cygwin kernel -- either (a) it must by copyright
assigned to Red Hat, or (b) Red Hat loses its right to distribute cygwin
under the proprietary license.
Now, RH is not going to do that. (and please, let's not start that old
flamewar about GPL purity and proprietary licenses). We thus have a choice:
a) do nothing -- status quo
b) provide cygipc as an official *package* with cygwin -- but not
incorporated into the dll itself
c) fork cygwin -- incorporate cygipc directly into "our" version of
the cygwin kernel
d) rewrite the IPC server function calls in a "cleanroom" way, and
incorporate THAT into the cygwin kernel. Rewrite the ipc-daemon as a
cygwin deamon (in a "cleanroom" way) to handle the actual
open/close/security manipulation IPC stuff. Distribute that daemon as a
core cygwin package. <IMO, Egor's cygwin deamon is a better starting
place for this than ipc-daemon) Rewrite the libcygipc.a client library
(in a "cleanroom" way) and distribute as a core cygwin package.
e) **CAN'T DO THIS; SEE ABOVE** get copyright assignment from
original authors of cygipc code, incorporate cygipc directly in to
cygwin dll.
Client/Server duality:
to provide IPC functionality, you need a *server process*. linux has
the kernel (which is an actual, running process). The cygwin "kernel"
is NOT really a kernel. It's just a shared lib that takes advantage of
certain windows quirks to *pretend* that it is a running process.
Unfortunately, that's not enough for IPC. we need a *real* process --
thus, the server daemon.
You also need some "system calls". In linux, these are handled by the
kernel. In cygipc, these are split between ipc-daemon (which implements
some stuff itself, or calls on the Win32 low-level IPC stuff), and the
client library libcygipc.a.
In choice (d) above, the cygwin kernel would provide implemenations for
many of the server-side syscalls AND implementations for the client-side
syscalls. (thus, no more need for -lcygipc when building client
programs). The cygwin daemon would be started at boot time, but most of
the "guts" would actually just be calls to functions implemented in
cygwin1.dll.
> pro integrating
> 3. Chris wrote:
>
>>IIRC, the original "authors" got the code from the linux kernel
>>so they couldn't actually assign anything.
>>
> What's than the problem to take this code and integrate it ? Who can made a
> decision ?
As I explained above, many unavailable (unknown?) copyright holders is
NOT the same thing as zero copyright holders. It is NOT the same thing
as "public domain." We *can't* just take the code without permission --
and then release it under a proprietary license (as well as GPL) as if
the code were our own. ("we" and "our" == Red Hat; but I am not am
employee of RH).
>
> As I stated before, I see this from my very subjective way and this is because
> of the hard work on
> porting kde, mostly with ld and libtool (which are not ready for use with kde2)
aside; yeah, I've been desperately trying to contact Paul but he's not
returning my email. There's a BIG bug in binutils that I can't fix, in
ADDITION to the memory leak that's causing you <ralf> so much trouble.
Sigh.
> I like the cygipc as it is.
> Install and run. Thats all.
I wish. I get at least one email a week from somebody who has trouble
with "install and run".
> If someone is able to say integrating is very little
> work (I can't that), than this would be the best way :-)
sure, recompiling cygipc to live in the /usr tree (not /usr/local),
stripping out the --install-as-service stuff (and relying on cygrunsrv
instead) -- that would take very little time.
BUT
I will not contribute and support yet another official package. I can
barely keep up with the ones I'm supporting now. (Anybody want to take
over zlib and libpng?) So, IF (and it's a big if) we decide to
incorporate cygipc as a official-but-separate package(*), I will help
someone else get started, and then *that* person may contribute it.
(*) e.g. a cygipc package, distributed on the cygwin mirror system,
installable by setup.exe -- but not part of cygwin1.dll itself.
--Chuck
- Raw text -