Re: multi CPU's
On Thu, Apr 06, 2000 at 07:28:06AM +0300, Eray Ozkural wrote:
> Is it totally different? That was my implicit question. Don't you
> think there should be only a marginal difference between the two
> images, since saying SMP just switches a few preprocessor symbols
> here and there. Then, the bulk of the binary code would be same.
> Though I'm pretty sure those preprocessor symbols are then scattered
> all over the megs of source code. But that seems to be less than 1000.
> [I've checked].
Yes, but the generated binary is then gzipped, causing the small
changes to greatly preturb the output. Also, generally, when program
source code changes, the diffs between the resultant binaries is
large. (Ie, ddiff is only useful for minor packaging changes, rather
than full new releases, although this may vary if a package uses a lot
of static data files.)
> If I remember correctly from my grad. algorithms course, the diff
> tools use hyper-cool dynamic prog. stuff... which will just give you
> the differences :) Anyway, what do you think would be the ddiff
> output? Or shall we just try and see? My estimate is that it will
> be less than 512k, and perhaps much smaller. And I guess that the
> incurred cost will be very small for some other desirable options
> that can't be built as modules.
Please note that my kernel is only on the order of 600k or so. I'm
wondering if there's a way to build modules so that they can be used
with or without SMP support, which is perhaps the biggest change
between kernels.
> Of course, it would be best if ddiff worked transparently from the user's
> point of view. Then, the user would see different packages which are in fact
> patched in place with ddiff.
My eventual vision of ddiff would be integration with apt... I'm not
sure how relavent that is in this case, however.
--
Tom Rothamel --------- http://onegeek.org/~tom/ ------- Using GNU/Linux
Writing from home, just outside Northport, NY.
The Moon is Waxing Crescent (3% of Full).
Reply to: