[Vol-dev] [patch] Pylint improvements for new_object

Hi guys, Here's another pylint patch, much of it the same as the last one, but this one applies to the new_object branch (it's probably a bit better than the last one). new_object requires utils.py[1] and linked_lists.py[2] to work, and the patch requires their presence. Please be aware, I don't have a complete library of images to test this stuff against, so whilst none of the changes should break anything, if they do, please let me know and I'll be happy to fix them up (particularly if you've got an image I can test them against!). 5:) I think the load_as function from utils.py (which makes use of the new address_space voting scheme that scudette wrote) will make a huge difference to the duplication going on in all the plugins, so my next step is going to be converting vmodules.py into individual plugin files, and then converting each one to use the new address_space system. Once I get good at that, I can start taking on externally written plugins, if it'll help? I think maintaining backwards compatibility will clutter an already complicated layout, so I'd sooner offer my time to convert other people's plugins, than try and maintain two mechanisms side-by-side and hope people don't get confused about which one they should be using. With the namespace cleanup happening anyway, this seems like an ideal time to drop any deprecated code, unless people think otherwise? After that, I'm going to have a go at converting them from Object to NewObject calls. Does anyone know whether NewObject is a drop in replacement for Object, or if there are specific changes required (such as, does NewObject require Profiles, or will it still work with normal types arrays)? Also, I wondered what people's thoughts were (as a long term goal) on integrating the Object2/NewObject code with the object code, so that all the familiars like read_string and so on, would be done through the one single object model? So, once all the modules are in their own individual files, and the imports are all explicit, it should become much easier to move things around, and get volatility into it's own namespace. Once that's been done, I'll probably do a sweep over the code changing all the direct imports (from blah.mumble import foo) to slightly more explicit ones (import blah.mumble) or similar. The reason I'd do this is because the imports were all over the place (as evidenced by the fact that not one internal plugin imported forensics.commands!), and the namespaces were getting messed up (so most of the plugins were importing gmtime from other volatility modules, rather than from time itself). The main question becomes, would it be tedious/ugly to have such long names (like "volatility.forensics.win32.tasks.process_handle(blah)") or are they not called often enough to make coding cumbersome? What do people think? That should cover the first three items on the todo list[3], and four and five I've got existing code[4] that should get everything sorted with the installation system, and allow volatility.exe binaries to be created (there'll need to be some code modifications to allow plugins to be dropped into directories external to the executable, but that's all doable)... Then it's just merging the linux stuff in (where does that come from?) and lots and lots and lots of documentation!!! Anyone want to help out with that? It'd really help to have some words about how scudette's NewObject system works from anyone who understands it... 5:) Mike 5:) [1] http://www.pyflag.net/pyflag/src/plugins/MemoryForensics/Volatility-1.3_Lin… [2] http://www.pyflag.net/pyflag/src/plugins/MemoryForensics/Volatility-1.3_Lin… [3] http://code.google.com/p/volatility/wiki/ToDo14 [4] http://phormat.svn.sourceforge.net/viewvc/phormat/trunk/phormat/setup.py?re…