Hi Boris. This is something that's happening, but since it's a big change it's taking a while. Because at least this initial part is such a big change, I've broken it into pieces which include all the general code (the CL you linked to), and then CLs after that for each of the ISAs. In the end once everything is reviewed, those pieces will be recombined into a single change so that we don't have a broken tree in the middle, and to make our continuous integration system happy.
The changes so far are primarily focused on FS mode just because that was somewhere to start and was a little more baked into things than SE mode is, but I fully intend to move SE mode to this system in the future too. As far as the votes on the change, there have been some, but when I upload a new version that isn't trivially the same gerrit (the review system) clears the votes since it's no longer exactly what people were approving earlier. Also since this is in pieces, I'm going to wait until all the pieces are good to go before I consider the whole thing approved, then merge it into a single change, add the necessary votes in aggregate, and get it checked in. I consider the main piece approved since Giacomo has given it a +2 (twice!), but most of the ISA specific parts still need approval. There may not be anyone who feels comfortable reviewing the change for a couple of the ISAs (SPARC and MIPS) so I may end up just self approving those after people have had an abundance of time to chime in if they have an opinion. Gabe On Wed, Feb 19, 2020 at 7:48 PM Boris Shingarov <[email protected]> wrote: > Gabe, > > I am confused -- did this get committed, or is it where it was in > October? The link to the review, > https://gem5-review.googlesource.com/c/public/gem5/+/22243/1 > seems to say "no votes" and the head of neither master nor develop branch > has the change, but after the migration to GoogleSource I no longer > understand how the new system works. > > On the actual subject matter: I've been thinking about something like this > too. Right now SE mode is inseparable from GEM5's ELF loader, and for my > use-case this is too restrictive: in my case, the address-space image is > programmatically created from scratch; to achieve this, I have a "thin > shell" which is an ELF image full of zeroes, then I programmatically fill > it at tick 0 just before starting the simulation. This hack has served me > sort of ok, but is getting progressively more annoying, so I have been > thinking about a more flexible system along the lines of what you are > proposing, just never having the actual time to do it. Is this topic, > something that is still relevant, or did I just pull a slowpoke? > > Boris > > > -----"gem5-dev" <[email protected]> wrote: ----- > To: "gem5 Developer List" <[email protected]> > From: "Ciro Santilli" > Sent by: "gem5-dev" > Date: 10/29/2019 09:39AM > Subject: Re: [gem5-dev] kernel object RFC > > Gabe, this looks interesting. > > To understand better, is there a "new specific end functionality" that you > are aiming to achieve, or is it just to keep existing functionality but in > a saner way? > > Both are great of course. > ________________________________ > From: gem5-dev <[email protected]> on behalf of Gabe Black < > [email protected]> > Sent: Tuesday, October 29, 2019 2:01 AM > To: gem5 Developer List <[email protected]> > Subject: [gem5-dev] kernel object RFC > > Hi folks. I've been working towards various ways of merging FS and SE modes > more completely, and one of the places the diverge today is how System > objects are set up. In FS mode, the System object is responsible for > loading the kernel, firmware blobs, etc., and is specialized for that for > each ISA. It also has all the parameters related to the kernel (object file > location, various addresses, etc.) directly. > > I recently put together a little exploratory change over here: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__gem5-2Dreview.googlesource.com_c_public_gem5_-2B_22243_1&d=DwIGaQ&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=rS7AybN8eMboGsiQeXQMJB0T-v86F0SgE6fLgYc5E3U&s=KWFSaVlL2-W3yvAzYLCvP0Na-L26IlzpSy6XUBK73m8&e= > > Which attempts to start pulling the kernel out of the System object to make > it its own replaceable, overridable entity. I don't even know if the code > in that CL will compile, but before sinking a lot of time into it I thought > it would be a good idea to see what people thought. > > To develop it further, I want to make the OpSysKernel SimObject I've > created inherit from a more generic Workload object which can include an > OpSysKernel, but can also include firmware bits, etc. The System would then > have a single, opaque Workload, and that could be an Alpha Tru64 kernel, an > ARM bare metal program, a fake Linux which loads a SPARC binary in SE mode, > etc. The System object would then become a much more generic container for > truly system level things like holding memory, collecting relating > SimObjects, etc. > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > > https://urldefense.proofpoint.com/v2/url?u=http-3A__m5sim.org_mailman_listinfo_gem5-2Ddev&d=DwIGaQ&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=rS7AybN8eMboGsiQeXQMJB0T-v86F0SgE6fLgYc5E3U&s=mWC6o45ZN3c79x3c5sHssQ-lbZxERq8aZLs0oSanAao&e= > _______________________________________________ > gem5-dev mailing list > [email protected] > > https://urldefense.proofpoint.com/v2/url?u=http-3A__m5sim.org_mailman_listinfo_gem5-2Ddev&d=DwIGaQ&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=rS7AybN8eMboGsiQeXQMJB0T-v86F0SgE6fLgYc5E3U&s=mWC6o45ZN3c79x3c5sHssQ-lbZxERq8aZLs0oSanAao&e= > > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
