Mail Archives: cygwin-developers/2001/10/24/01:17:18

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Wed, 24 Oct 2001 01:18:15 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Need name and functionality suggestions for a new utility
Message-ID: <>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A40 AT itdomain002 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/1.3.21i

On Wed, Oct 24, 2001 at 03:17:40PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
>> So, we eventually came up with the idea of something like a 'chroot'
>> utility where you could say something like:
>> cygisolate MyOwnCywin bash
>> and that bash and all of its children would use MyOwnCygwin as the
>> registry key rather than "Cygwin".
>> This would mean that you could have an isolated set of mounts which
>> would not be touched by something not in the cygisolate "tree".
>> The concept is similar to chroot.  It is so similar that I'm tempted
>> to just add a switch to chroot to handle this but I hate hacking up
>> existing utilities for Cygwin's purposes.
>Well, chroot doesn't address shmid's and the like, and this will need
>> So, I've got everything written to accomodate this usage but I'm stuck
>> on a name.  I don't like cygisolate but I can't think of 
>> anything else.
>> 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 so that there are no conflicts
>> between this cygwin and another running instance.
>Also mmap id's, and any named objects that are file path/name based will
>need alteration (prefix with 'MyOwnCygwin' ?). The cygwin daemon is
>going to need adjustment for this as well.

I don't think I want to go that crazy.  This is just for cygwin objects.
Theoretically, the whole mount table will look different so mmap
objects, at least, will refer to different paths anyway.

I'd want to provide a mechanism for someone to isolate one cygwin
release from another (which is probably something that I vowed I'd never
do, actually).  But, I don't want it to be too intrusive.

shm ids could be handled by changing the seeding of ftok(), though.

>>cygjail maybe?  cygisland?  cygme?
>cygme with your coding trick?  (aplogies to Ian Dury).

Don't know the reference, sorry.

>I like isolate, it's pretty clear, and shouldn't create mental conflict
>with 'jail' or 'chroot'.  Also, howabout 'cygvirtual' or 'cygalternate'
>Or even 'cygXP :}'.
>mycyg might be another one.

Maybe.  I don't like the prefix 'cyg' much but it does help reduce
namespace pollution if we call all of the unique cygwin utilities
cygsomething -- even if we strayed from that naming in the past.


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019