Thanks! The primary idea is to remove unnecessary separation between SE and FS modes which should reduce complexity and make the implementation (hopefully) easier to understand. It should also make it possible to be somewhere else along the FS/SE line, like having a BIOS emulation mode where BIOS calls are emulated. That would make it possible to run an OS like DOS without having to actually implement all the BIOS interrupts, or a power management firmware where the power management operations were hand wavy calls to gem5 mechanisms, etc.
It would also make SE mode more flexible, where there would be an "OS" object which would have the list of emulated system calls and loaders for processes that would run under it. That object would be able to control OS level resource allocation (in a hand wavy, high level way, of course) and OS level policies in a way that reflects either the real behavior of that OS, or that matches the requirements of whoever is using it. Gabe On Tue, Oct 29, 2019 at 6:39 AM Ciro Santilli <ciro.santi...@arm.com> wrote: > 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 <gem5-dev-boun...@gem5.org> on behalf of Gabe Black < > gabebl...@google.com> > Sent: Tuesday, October 29, 2019 2:01 AM > To: gem5 Developer List <gem5-dev@gem5.org> > 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://gem5-review.googlesource.com/c/public/gem5/+/22243/1 > > 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 > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
