This is the mail archive of the cygwin 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: cygwin-setup & rebaseall


Satish Balay wrote:

> - open a dialog box with a message:
>  "some packages that require 'rebaseall' are updated. This operation
>  cannot be done at this time due to active cygwin processes. Please
>  reboot, shutdown cygwin services, and run 'rebaseall' from 'ash'."

The thing is, you can't just do a "partial" rebaseall.  If you update
just one DLL, you can't just pick a new base address for that one DLL,
you have to start over and reassign all new base addresses to every
DLL.  This is because the current algorithm for choosing the base
addresses just packs them together back to back, so adding/modifying one
could potentially cause all those below to have to be moved.  You can
get around this by setting up some kind of registry of assigned base
addresses, or treating the problem like a heap, but that get
extraordinarily more complex because you have to maintain state.

This is why the whole rebasing method is not scaleable and why we should
really be aiming to throw away rebase and use --enable-auto-image-base
for every package.

So, the reason I mention all that is that it means that the above dialog
box would be displayed *any time* that setup was run with *any cygwin
program or service active*, no matter how small or irrelevent.  We would
get flooded with complaints about this extra annoying dialog box, and
"why can't setup replace in use files like it used to", and "I don't
care about rebasing, all my apps work fine, how can I disable this?"

> - open a dialog box with a message: "some packages that require
>   'rebaseall' are updated - hence setup is incomplete. Please reboot,
>   shutdown cygwin services and rerun setup - so that it can continue
>   and fix this."

You wouldn't want to bail partway through a rebase and leave things in a
partial state.  What setup would have to do is perform the full rebase
of all DLLs, scheduling any that were in use for replacement with their
rebased copy on the next reboot, as it already does for upgrading DLLs. 
But as I've been trying to say this requires a great deal of coding in
setup because you have to internalize all the rebasing logic, it can't
just punt to the rebaseall script.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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