This is the mail archive of the cygwin-developers 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]
Other format: [Raw text]

Re: Avoid collisions between parallel installations of Cygwin


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


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