Bryn M. Reeves writes:
On 07/17/2012 12:42 PM, Sam Varshavchik wrote: > … which can be used to reset the > application, so that it knows that it's been updated. Because that is a common need across many packages. Apparently being notified of a prelink is not such a common need. Even if such a thing did exist it could not protect you from any other modifications to the binary if it was specific to prelinking so you would still need to handle this case to avoid bugs in your program.
I'm having some kind of a difficulty parsing the above. How exactly would some kind of a notification that your executable has been prelinked would not be effective for modifications that result from prelinking.
Maybe you would find more acceptance for a request asking for something like this rather than demanding the removal of something that has been used for many years and that has good evidence for the benefits it claims to provide?
I don't recall myself demanding anything. I described a problem that prelink is causing, namely invalidation of the contents of the /proc/self/exe symlink. I also floated some alternatives, like skipping binaries that are currently running.
I see little sense in demanding something that can already be easily done anyway, like removing prelink altogether, or by blacklisting a selected executable, which is trivial to implement. I just thought – and as I said, that this is not solving the problem, but sweeping it under the rug, and that there should be a better way to avoid having prelink break /proc/self/exe.
> If you tell me how an app can be notified that prelink is about to rewrite > it, then this would be a comparable situation. But it's not. Inotify? If you care about it in your app (and since nobody else appears to have asked for it I'd argue that's a good sign that there is not yet any justification for a general facility like this) perhaps you should look at inotify and register a watch for your executable's inode so that you can take appropriate actions? This would also deal with modifications other than prelinking.
I'm dying to know what other "modifications" are there, other than prelinking – inquiring mind wants to know. And the coin can be flipped both ways too: AFAIK nothing else other than prelink randomly scribbles over random executables. Somehow, things have been fine all along, before prelink came along, and perhaps, some consideration could've been provided for applications to use and integrate with.
You could even make such a thing into a library that other developers could use to solve the same problem. If there's widespread need for the facility I'm sure you'd soon have plenty of users and a good justification to get it included in distributions. That's generally how things move forward in open source.
Thank you for telling me what I've already done. But, it would've been great to avoid dealing with prelink's broken design in the first place.
Attachment:
pgp1p5OT1ODDy.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
