This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Need name and functionality suggestions for a new utility


On Wed, Oct 24, 2001 at 11:43:53AM +0400, egor duda wrote:
>Hi!
>
>Wednesday, 24 October, 2001 Christopher Faylor cgf@redhat.com wrote:
>
>CF> On Wed, Oct 24, 2001 at 01:18:22AM -0400, Charles Wilson wrote:
>>>Christopher Faylor wrote:
>>>>Does anyone have an idea for a name?  Or even an idea for more
>>>>functionality for this utility?  Now that I think of it, this utility
>>>>should also change the shared memory id 
>>>
>>>Can you DO that without adding hooks to cygwin1.dll?
>
>CF> No.  You need to add some hooks.  The cygheap changes that I made a while
>CF> ago make this very easy, though.
>
>does your tweak works in such scenario?
>
> "cygwin-app-1" starts "non-cygwin-app-2" and it starts "cygwin-app-3"
>
>will cygwin-app-3 be properly "jailed"?

Nope.  It doesn't work with non-cygwin apps since that breaks the cygheap
chain.  chroot operates similarly.

>i was supposing to write a patch to add (ahem) yet another CYGWIN env
>variable option so one can write, e.g.
>'set CYGWIN=profile:old_install'

As you can probably surmise, the first suggestion for this was to use an
environment variable.   That would sort of work around the above scenario
but it makes it very easy for a user to circumvent, too.  I don't think
it's useful.

>CF> I had the hooks written and cygwin compiled.  Then, sending this email
>CF> started a whole flood of new ideas about what needed to be changed.
>
>CF> I think it might just be possible to allow two different cygwins to
>CF> coexist without this as long as they share the mount table.  I don't
>CF> know if that's a good thing or not.
>
>CF> It means that instead of getting "shared memory mismatch" we'll be hearing
>CF> about how the new version of cygwin doesn't fix their problems -- because
>CF> they still have a cygwin1.dll in their windows/system directory.
>
>this can be easily revealed by cygcheck.

Yeah, especially now that cygcheck will actually be able to run in this
scenario.  Previously, it would just crash with the "shared memory
mismatch" error.  Not too useful.

Incidentally, in 1.3.4, I have changed this error to a multi-line message
which gives explicit instructions.  It will be interesting to see how my
instructions are misinterpreted.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]