> ... and exec does it's own attempt at synchronization, so that it sees a > consistent file content. Yeah, locking it was bogus. I am wondering if for > the other calls locking is also unnecessary (although not harmful) as we are > only passing through and the locking of the "real" node at the end of the > chain will make sure nothing bad happens.
It's not worth the trouble to unlock in the other cases since the locking happens in the netfs layer. The locking is necessary for things that change the netfs data structures, of course. Including the ch* and stat RPCs to the underlying node in the locked portion serializes those calls, which might matter for some races that surely noone actually cares about for fakeroot. > I don't understand this in the context of fakeroot. We are only forwarding > a message, and never try again. Wrong. The stubs themselves built into libc like file_exec do the retrying. > argv[0] is fine. I run bashbug. It found bashbug in /usr/bin/bashbug. > But the io_identity is different for the FILE passed to file_exec, and > NAME_FILE looked up in the exec server. Duh. The file_exec to the underlying node calls exec_exec with a port to the underlying node, but the INIT_PORT_CRDIR used to start the lookup is the fakeroot one. We should probably override netfs_S_io_identity to lie and return the underlying node's info. Hmm, but then how would it notice talking to itself in netfs_attempt_lookup? > > But even with that broken, the /dev/fd/3 ought > > to work (unless the script itself closes the descriptor before using it or > > something). > > Well, all scripts fail the same way, nothing is closing it. I have not come > further with this one. Not sure what I will try next. Is there an easier > way to find out how PIDs in different Hurds map to each other than listing > all with ps -A and matching up the statistics? Not really. Often you can just guess by the order of the processes after boot. If you want to prove your manhood, you can always debug the exec server of the live system. Just make sure not to try to run any new programs while you are attached. But you can still suspend gdb and fg it, and detach in gdb when you want to be able to run again. (Of course if you diddle the state rather than just examining and stepping through, you might screw it.) _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
