Synchonize FDUser and InodeUser dataclasses

[ikelos]

linux.lsof and linux.pagecache define an FDUser and InodeUser dataclass, respectively. The documentation in linux.lsof says that a function returns an InodeUser when it doesn't, although some of the fields are shared. If these two structures are related, we need to figure out which bits are shared and how to share them sensibly. If it's just a documentation issue, then it needs fixing. One way or another, a lot of things have been added and I'm not yet confident they've all been added with visibility of each other or considered which parts can be shared...

[ikelos]

@atcuno @Abyss-W4tcher @gcmoreira could you please get together and ensure that everything's running as efficiently as it can be in linux world please?

[Abyss-W4tcher]

I'm pretty confident this one is a documentation typo.

We could make these kind of dataclasses inherit from VersionableInterface, and include them in get_requirements when needed. However this can be quite heavy for plugins like linux.netfilter with many classes/dataclasses.

[ikelos]

I don't want to make it too onerous on the users, but perhaps they should just be defined within the (versioned) class? That way you only have one version check, and the classes tend to stay associated with the plugin they're used for?

[gcmoreira]

Hey @ikelos

linux.lsof and linux.pagecache define an FDUser and InodeUser dataclass, respectively. The documentation in linux.lsof says that a function returns an InodeUser when it doesn't, although some of the fields are shared.

It's clearly a typo in the docstring.

@dataclasses.dataclass
class FDInternal:
...
    def to_user(self) -> FDUser:
        """Augment the FD information to be presented to the user

        Returns:
            An InodeUser dataclass
        """
            fd_user = FDUser(
...
        return fd_user

We can fix it with just s/An InodeUser dataclass/An FDUser dataclass/.

If these two structures are related, we need to figure out which bits are shared and how to share them sensibly. If it's just a documentation issue, then it needs fixing.

hm related? The lsof plugin yields file descriptors and the page cache plugins yield inodes. If file descriptors and inodes are relates.. well yes and no. A file descriptor is associated with an inode, but an inode can exist without a file descriptor since file descriptors are only assigned to open files.

One way or another, a lot of things have been added and I'm not yet confident they've all been added with visibility of each other or considered which parts can be shared...

Sorry, not sure what you mean with this. Could you please elaborate this?

[ikelos]

It's clearly a typo in the docstring.

Ok, since some of the fields were similar, I couldn't be certain.

We can fix it with just s/An InodeUser dataclass/An FDUser dataclass/.

Cool, be good to get a PR with that in. May also be worth looking at the following to go in it too...

hm related? The lsof plugin yields file descriptors and the page cache plugins yield inodes. If file descriptors and inodes are relates.. well yes and no. A file descriptor is associated with an inode, but an inode can exist without a file descriptor since file descriptors are only assigned to open files.

Ok, so if every file descriptor has an inode, then... surely the FileDescriptor dataclass should contain an inode field, that points to the inode dataclass?

One way or another, a lot of things have been added and I'm not yet confident they've all been added with visibility of each other or considered which parts can be shared...

Sorry, not sure what you mean with this. Could you please elaborate this?

I just mean there's been a lot of new commits to several areas and plugins across the linux base (and the windows base, to be fair) being made by several people and I can't tell if they're all aware of what's going on as the PRs are being merged. There's high chance someone won't be following what's happening elsewhere, even if it's relevant (such as the file descriptors not making use of the inode dataclass). And now that we've run into the dataclass versioning issue (which I propose to solve by defining the dataclass as a property of the versioned class) when dataclasses weren't even a thing a few weeks ago. It's all moving very fast at the moment and I want to make sure everyone's keeping an eye out on what's going on and that we all have time to breath and get comfortable with the changes.

I know there's been a push for parity, and we've had an incredible amount of work done, but going that quickly can also lead to mistakes and I'm getting less and less certain I haven't missed things, given the speed with which we've been throwing things into the codebase. So after the parity release is out, I'd appreciate it everyone can look over the existing plugins and make sure they interact with each other properly where they should, that we don't have two competing ways of doing something in the codebase, and that they're all joined up (like file descriptors and inodes should be) in a way that makes sense...

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity.