> Only that it's essentially untested, and really deprecated. Roland, do > you think it's worth keeping around? Is there another way to guarantee > correct exec behavior? (Like, say, reading the entire file in a single > RPC; is that enough?)
I didn't realize that the io_map_cntl stuff was deprecated in your eyes. (That doesn't mean we didn't have a conversation with that conclusion, I may have just forgotten.) It's certainly never been used. But we've also never actually had the execve vs write atomicity guarantee. (Note that AFAICT there is no specification anywhere that requires atomicity of execve vs write. POSIX.1-1996 talks only about read vs write, and extends this to stdio and other things via the "underlying function" clauses--but there are no such clauses applying to exec. AFAIK other systems do not always provide this guarantee, e.g. none I'm aware of do for NFS; I don't know whether other current systems in fact make the guarantee for disk files.) I'm not saying it's not a worthwhile thing to have, but just to put in perspective how much hassle and other inefficiencies it might really be worth. I am dubious about the idea of an io_read for the entire file in exec. That approach presumes the filesystem will be doing something as lazy for io_read as it does for mapping. Maybe diskfs does, but it still seems dicey in principle. And I wonder how the overhead of the io_read to vm_copy to ool reply of pages mapped to self compares to the overhead of io_map to the other guy's vm_map. Even if the io is delayed, I am still uncomfortable with having to consume arbitrary chunks of address space in exec during the procedure. An executable file with debug symbols can be very huge, and exec would have to do the single io_read to get it all before looking in the first page to discover what tiny fraction needs to go into the process image. This might be a relatively quick window, but there's no reason there shouldn't be 2000 of them going on simultaneously and just the rare possibility of running out of address space in exec for an instant introduces either unreliability or a bunch of hair in the code to cope with waiting and retrying or capping the maximum number and so forth. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
