[RFC] Stage-3 Linux event model

[mitodrummer]

• Have you signed the contributor license agreement? yes
• Have you followed the contributor guidelines? yes
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process? yes
• If submitting code/script changes, have you verified all tests pass locally using make test? n/a
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes? n/a
• Is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed. yes
• Have you added an entry to the CHANGELOG.next.md? not yet

[kgeller]

@mitodrummer Upon beta implementation of this proposal, the ECS team hit a couple of snags.

1. Are the file_description.socket* fields being utilized yet? As far as I could tell from the examples in the RFC document, they are not. In that case, I'd say we hold off on those for now. It's much easier to add later, than try to remove/alter.

2. ECS re-use nesting is a complex thing when it comes to chaining re-uses. Example: if we nest as cat at dog and as fish at cat, then we will end up with dog.cat.* and cat.fish.* and dog.cat.fish.*. So when trying to implement file, fifo and pipe at file description, we will bring along everything nested at the file fieldset (hash, elf, etc) underneath file description as well. And same goes for when we nest file_description and tty at process. I didn't see any usages for the file fieldset in the examples in the RFC, but is this something worth considering: adding fields to the file_description field set itself?

3. In one of the examples in the RFC, you note To keep backwards compat and avoid data duplication. We keep user/group info for top level process at the top level. What is the difference then between user & process.user and group & process.user.group?

While I hope this makes sense, but in the event that it doesn't, let me know and we can zoom to discuss.

[m-sample]

LGTM