This is an archive of the discontinued LLVM Phabricator instance.

Move ProcessInstanceInfo and similar to Utility
ClosedPublic

Authored by zturner on Mar 1 2019, 11:32 AM.

Details

Summary

There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist.

To cement this, I'm moving this class to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being.

After this there are only 2 remaining references to Target from Host, neither of which is terribly difficult to fix on its own and which I'll address in followups.

Diff Detail

Event Timeline

zturner created this revision.Mar 1 2019, 11:32 AM
labath added a comment.Mar 1 2019, 1:11 PM

My main reason for creating D58167 was so that this move (*) could be done without leaving the remnants of the Dump function in the form DumpProcessInstance functions in Process.cpp (among other benefits I think that refactoring will bring). I still think it would be better to do this in that order, but if takes too long to get that patch accepted (I'm not sure what's the holdup, maybe people just don't care enough about that?), then we can do things in the opposite order too (or just drop the second patch, if noone's interested in it).

(*) I was originally planning to move these into Host (and I have actually already moved some of them recently, which is why some of these classes are in Host and others in Target). I did that because Host already contains code for working with processes and there's no problem in Target depending on Host, so it was "good enough". However, the case for Utility also sounds reasonable to me, so I am fine with that option too.

labath added a comment.Mar 1 2019, 1:18 PM

Hmm.. I think I've thought of (or remembered, because I have been thinking about Utility too) a reason why it might be better to keep these in Host. ProcessLaunchInfo cannot be trivially moved to Utility (and indeed, in this patch, you are keeping it in Host), because it contains some references to Host-specific code (PTY stuff). Now, I am not convinced having the PTY class be a member of ProcessLaunchInfo is a good thing, but assuming we don't want to refactor that now, I think it might be better to keep Process(Launch)Info and friends in the same package (i.e., in Host), at least until we have a reason to do otherwise.

Hmm.. I think I've thought of (or remembered, because I have been thinking about Utility too) a reason why it might be better to keep these in Host. ProcessLaunchInfo cannot be trivially moved to Utility (and indeed, in this patch, you are keeping it in Host), because it contains some references to Host-specific code (PTY stuff). Now, I am not convinced having the PTY class be a member of ProcessLaunchInfo is a good thing, but assuming we don't want to refactor that now, I think it might be better to keep Process(Launch)Info and friends in the same package (i.e., in Host), at least until we have a reason to do otherwise.

Well, the biggest difference between ProcessAttachInfo / ProcessLaunchInfo and the ones here is that those actually have some non-trivial functionality associated with them. It might be possible to decouple that functionality from the descriptions themselves, but it didn't seem worth it to me.

I have a mild preference for putting them in Utility on the grounds that logically that's where they seem to make the most sense. A Process could just as easily be running on a target as on the host, and we may want to pass this description around, and so favoring one or the other regarding to put them seemed a bit biased. We do already have a process class in Host called HostProcess, and that's more what I envision a host-specific process looking like. Low level methods that map directly to system calls to manipulate and query a process's state, etc.

As for D58167, I mostly just had a drive-by passing comment, and it looked fine to me after that, but I guess I was waiting for someone else to click Accept since my comment was fairly minor. But I'll go ahead and accept it anyway just to unblock

labath added a comment.Mar 2 2019, 1:00 PM

Hmm.. I think I've thought of (or remembered, because I have been thinking about Utility too) a reason why it might be better to keep these in Host. ProcessLaunchInfo cannot be trivially moved to Utility (and indeed, in this patch, you are keeping it in Host), because it contains some references to Host-specific code (PTY stuff). Now, I am not convinced having the PTY class be a member of ProcessLaunchInfo is a good thing, but assuming we don't want to refactor that now, I think it might be better to keep Process(Launch)Info and friends in the same package (i.e., in Host), at least until we have a reason to do otherwise.

Well, the biggest difference between ProcessAttachInfo / ProcessLaunchInfo and the ones here is that those actually have some non-trivial functionality associated with them. It might be possible to decouple that functionality from the descriptions themselves, but it didn't seem worth it to me.

I agree it's not a top priority, but I think it would be nice to factor that out. The reason for that is that ProcessLaunchInfo is also used to describe remote launches, and in this case, having a Host PTY around doesn't make sense (we might (and we do) want to have a flag that says a pty should be used on the remote side, but an actual host pty object does not make sense there).

I have a mild preference for putting them in Utility on the grounds that logically that's where they seem to make the most sense. A Process could just as easily be running on a target as on the host, and we may want to pass this description around, and so favoring one or the other regarding to put them seemed a bit biased. We do already have a process class in Host called HostProcess, and that's more what I envision a host-specific process looking like. Low level methods that map directly to system calls to manipulate and query a process's state, etc.

Ok, I am fine with putting this in Utility then (unless someone else speaks up about his preference for the location of this). In the future, I am starting to think we could have a new package (name TBD) which would contain things that "describe some property of a process, but without any bias towards a particular implementation of the process (Target, Host, lldb-server, ...)". I will soon need to move MemoryRegionInfo out of Utility and into something else, and it seems to me this class could fit that description too.

As for D58167, I mostly just had a drive-by passing comment, and it looked fine to me after that, but I guess I was waiting for someone else to click Accept since my comment was fairly minor. But I'll go ahead and accept it anyway just to unblock

Ok so it seems it's not clear if I answered all of Greg's comments or not. Let's wait to see if he has anything to say until monday. If that patch takes longer, then you commit this, and I'll rebase that patch on top of this.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 4 2019, 1:50 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2019, 1:50 PM