> I was thinking about this a little more, and I think if we really want to > get it right we need a more comprehensive change that better mirrors what's > going on inside the OS, where dup'd fds are really just different pointers > to the same underlying file object (including the file pointer). So most of > the stuff in FdMap should be in a separate file object so that multiple fds > can point to it, and the fdMap itself should just have the host fd and a > pointer to the file object. Then dupFunc() would call dup() to get a new > host fd, then create a new fdMap entry that has the new host fd but just > copies the pointer from the original fdMap entry. Obviously the > serialize/unserialize gets more complicated now, and if you really want to > do it right you'll need some kind of ref counting on the file objects so > that a dup()/close() sequence does the right thing... I didn't say it would > be a small change, but IMO this is what it will take to really do it right. > And I see that the Process field is really fd_map, but that's actually a > historical anomaly that goes against our style... it should be fdMap.
This is a good idea and if we have a serializer object that supports sub-objects and a way to mark an object as already having been serialized, this (and other things like it, e.g. events, packets, etc.) wouldn't be a big deal at all. In general that sort of support would be quite welcome I should think. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
