Oh, I see one point of confusion I had. I had thought the built in module initialization functions (pybind_init_core, pybind_init_stats, etc) were installing things under the m5 module, but they're really installing things under the _m5 module. I think I missed that since the _ isn't obvious in the variable that holds the module, m_m5.
It seems fine to me to add a purely python m5 submodule (like m5.systemc and/or m5.tlm) and have that if nothing else just import and pass through the _m5 versions of the same. I think the problem then becomes, how do I add a systemc or tlm submodule to m5 without adding the code under src/python/m5? Putting the code there would be mostly ok since systemc and tlm are part of the main gem5 code base, but is there a way to bring that sort of thing in with EXTRAS? Maybe that's overkill for something that may not be that important, ie major bits of functionality that deserve highly integrated python interfaces but are still not part of the primary code base. Anyway, I think I know how to make what I was initially after work without having to do anything overly weird and without any additional machinery. Thanks! Gabe On Wed, Feb 20, 2019 at 8:38 AM Andreas Sandberg <andreas.sandb...@arm.com> wrote: > Hi Gabe, > > I think this might make sense. As you have probably seen already, the > main intention of the _m5 namespace is to hide the potentially clunky > C++-like interfaces from the normal m5 namespace. A common design > pattern for native Python packages used to be to have a native namespace > that provides a low-level API and then wrap it using Python code to > provide a more high-level API. "m5/event.py" is a pretty good example of > this design pattern. > > I'm not entirely sure how well it would work to combine native code and > Python code in the same namespace. Importing the m5 module and adding to > it could work, but it depends on the initialization order and seems a > bit scary. What we used to do in the past for this was to add a > pseudo-package in native Python code that just re-exports the native > functionality. Would this solve the problem? > > Cheers, > Andreas > > On 15/02/2019 02:10, Gabe Black wrote: > > Hey folks. For the systemc stuff I currently use our pybind11 > > infrastructure to define and populate a _m5.systemc submodule, but I'd > like > > to make that m5.systemc so it seems less hacky to use explicitly, and > > perhaps even an m5.tlm. > > > > Is this something that makes sense to do? There aren't hooks for it atm, > > but I'm thinking I can get it to work by importing the m5 module in my > > EmbeddedPyBind hook and then adding things to it that way. That also > seems > > hacky, but should it work? Would it be worth adding hooks to add > submodules > > to the non-internal m5 module? > > > > Gabe > > _______________________________________________ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
