Date: Tue, 25 Apr 2000 17:02:05 -0400 (EDT) From: "Brandon D. Valentine" <bandix@looksharp.net> To: Andrzej Bialecki <abial@webgiro.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility Message-ID: <Pine.BSF.4.21.0004251641130.38092-100000@turtle.looksharp.net> In-Reply-To: <20000425201600.A1134@yedi.wbnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Apr 2000, Wilko Bulte wrote: >OK. But you do have to uniquely identify the binary that needs to be >patched. So, my question is when you generate 10x the same binary, will all >these 10 binaries have the same MD5 checksum? In other words: if people did >a local buildworld once on a -release sourcetree will all the executables >have the same MD5 as the ones on the -release cdrom? Any place I have used the pronoun 'you' below is a reference to Andrzej Bialecki, originator of the thread, and not Wilko Bulte, who happened to provide a nice starting point for my response. Ideally, yes. But this assumes that the binaries are built on the same architecture with the same compiler options(especially optimizations). If you feed it the same asm as86 should always generate the same binary. Of course the minute you change compiler versions or add a different -march or -O flag to gcc you run the risk of ending up with slightly different binary code. To do this using checksums would be problematic. The only way something like this is feasible is if the binaries themselves contain information about what version they are. In other words some sort of a header in the binary which contains the RCS version number the binary was compiled from so that whatever method you were using to sync your "binary" trees(no pun intended) so to speak can compare RCS tags just as you would do with source. If you were to implement this you'd probably check the binary versions against the remote repository and then any outdated binaries would have a replacement downloaded into /usr/upgrade or some such directory where one could later chdir and run a Makefile from single user mode to move those new binaries into place. Since there are already servers which generate nightly binary snapshots the problem of keeping a -STABLE binary set available is already solved. If you want to do this you need to come up with a cvsup patchset to support this and a proposal for how to keep RCS tags available in the binary header without breaking compatibility. You also need to believe strongly in the necessity of such a system and you need to convince the project that it is important and will not place a further strain on the project's resources. Ideally a system like this could be used to replace the current upgrade knob in sysinstall. I just don't know that this is as pressing an issue at the moment as some of the other projects going on in the source tree so if it is going to happen someone(namely you) is going to need to volunteer. Brandon D. Valentine -- bandix@looksharp.net Illegitimi non carborundum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004251641130.38092-100000>