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

Michael Cohen wrote: Hiya Michael, You're quite right, the patch I attached was entirely and completely non-existant (it was a bzip2 of an empty file). Sorry about that everybody! 5:( You should find the full thing attached now. There were, I think it's just the one call to list_do in forensics.linux.tasks. It's not (at least, not the volatility svn tree), it's included in this giant patch though (as, unfortunately, is linked_list). The only other thing that the code seemed to be missing before it would work correctly was a definition of _LDR_DATA_TABLE_ENTRY, which this patch also adds. I spotted pstree, it's the plugin I was going to use as the basis for modifying the others to using load_as! 5:) Unfortunately, I've no idea which plugins duplicate functionality, and which simply do things a different way (all of the blahscan2 functions appear *much* quicker than the blahscan functions, but produce pretty much the same output), so I was going to convert them all and then ask people to help me cut away the ones we don't need... That sounds good to me, although it might be a courtesy to add some kind of a field in the forensics.commands.command object which specifies which version of volatility is needed for the plugin, just so that uses end up with a "this plugin won't work with this version" message, rather than a python stacktrace. 5;) That'd need some planning to figure out though (since there may be times a version bumps without breaking compatibility). Ok, I was more just asking about code conversion, since the function siganture for the Object constructor seemed similar to the call for NewObject, I was wondering if changing the code was going to be as easy as just changing all Objects to NewObjects. It sounds like I'm going to have to know a lot more about how it works than I do at the moment to start converting them (which also means the pylint patch may break some things in a couple of places as I was doing the import clean-ups). The new object code implements the Sounds pretty ideal though. 5;) There's still a few places where this is in use and is just reading a 'char', rather than a specifically designated type (linux.scan/win32.scan2). I think that's what I was asking, will it be possible to fold in default types (like 'char', 'int', etc) into the NewObject model, so that we can effectively drop forensics.object, and then later rename forensics.object2 to its rightful place. 5:) Ah, yeah, I was wondering where the autogenerator code is (or are you just saying it could be autogenerated from .h files? Presumably that should be somewhere in the repository? How does it decide which classes to yoink from the .h, or does it grab all of them and you weed them out manually? Yep, that's a nice little trick. 5:) I'm completely in agreement with you there. Does anyone have any problems with converting the code to a style like that? Well, it will become difficult, but other large projects do manage plugins (although granted, developers often have more time to work on them that our userbase does). This comes back to the compatibility flag in the plugin. As long as it can safely be discarded if it doesn't work properly, that should be fine. Bringing modules into the tree is great, but only if there's someone there to maintain them, otherwise you're just burdening the developers with access to the tree with more code to maintain. That's why planning a really good interface for everything, and then trying hard not to change it, is a worthwhile challenge... Well, I'm having a go at it, but I think it's mostly the mix of the two systems that's hindering adoption. Not knowing whether you can or can't use read_obj, etc and then whether you can use forensics.addrspace. The documentation will certainly help, particularly if it shows how to properly use the latest system for everything, though... 5;) Mike 5:)