This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 22 Oct 2009 11:04:45 +0200
- Subject: Re: Avoid collisions between parallel installations of Cygwin
- References: <4ADF8538.8060902@cwilson.fastmail.fm>
- Reply-to: cygwin-developers at cygwin dot com
On Oct 21 18:03, Charles Wilson wrote:
> [Consolidated reply]:
> Corinna wrote:
> > struct props {
> > char magic[PROPS_MAGIG_LEN];
> > size_t cb;
> > ulong disable_key;
> > [...]
> > };
> >
> > If the cb value is 4, we only support the disable_key value. The tool
> > script of the same age only supports the disable_key value either. So
> > no worry.
> >
> > If the cb value is 8, we also support the foo_bar value. The old tool
> > script version ...
> >
> > If the cb value is 12, ...
>
> The limitation of this approach -- which might be acceptable, but it IS
> a limitation -- is that you are not allowed to change the semantics of
> any existing values, or ever replace old members with new names of the
> same size ("member #2 is a 32 bit value representing "disable_key" if cb
Right. I don't think we should do that anyway. And it's still
questionable that we need to add members very often.
> Of course, that comes at a cost. You way, old tools will always be able
> to manipulate the members they know about, for any new DLL -- doing so
> may not have any effect if a particular struct member no longer has any
> realistic use in the new DLL, but that's ok. With explicit versioning
> there are no guarantees about the stability of members between versions.
Yep.
> It's just a choice. You da boss, pick one (but please don't use windows
> as the gold standard of all things excellent in API design.)
I don't. I just think it's a neat and simple way to accomplish
extensibility in this specific case.
> Which is an argument for not putting very much in there; which was the
> plan anyway, I think. The less you put there, the fewer "opportunities"
> for changes...
ACK.
> > Nothing really keeps you from providing a newlib patch adding this
> > functionality ;)
>
> What worries me about that is trying to get it validated on all 392
> different newlib platforms all at once (and I'm not going to do anything
> before 1.7.x is released). Is there a way to add general functionality
> to newlib, so that it only has immediate effect on one platform but can
> later -- one at a time? -- be enabled on additional ones after
> verification (and need) by the users of those platforms?
Sure. Use a define to enable XDR in sys/config.h, e.g.
#ifdef __CYGWIN__
[...]
#define _ENABLE_XDR_ 1
#endif
> Corinna also wrote:
> > On Oct 21 13:13, Charles Wilson wrote:
> >> Well, that's true too. You complain though about the time involved in
> >> the whole FindResource/LockResource deal. But, is that really a problem?
> >> Unless these items are explicitly immutable (and, in the case of the
> >> disable-unique-object-names, it pretty well SHOULD be immutable!), you'd
> >> still need to manage a lock when accessing the global struct that holds
> >> their values, right?
> >
> > Why? The external tool changes the binary data on disk. It does not
> > change the representation within a DLL in memory.
>
> Well, the FindResource/LockResource has no meaningful time impact on the
> standalone tool; it's instantaneous as far as the user who invoked it is
> concerned. So, if we're worried about the runtime effects, then we're
> talking about the in-kernel accesses to the struct or variables which
> hold the values.
We're talking about two different things. I'm saying we don't need a
lock since the props data doesn't change at runtime. And I was planning
to make it const anyway. As far as FindResource/... is concerned,
yes, I'm only talking about the Cygwin DLL, not the external tool.
> Since you're inside cygwin, and these are just variables, then they can
> conceivably be modified -- especially if their values are obtained
> (populated) from the persistent storage in the .rsrc section: the
> variables themselves must be mutable in order to load their values at
> early startup. If something CAN be changed at runtime, you can bet that
> it WILL be changed when you did not originally plan for it -- unless you
I don't see the point. Any Cygwin process can scramble any data in the
non-R/O sections of the DLL at runtime, in memory.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat