On 06/08/20 21:32, Tejun Heo wrote: > On Thu, Aug 06, 2020 at 09:20:38PM +0200, Paolo Bonzini wrote: >> On 06/08/20 20:49, Tejun Heo wrote: >>>> perf and bpf have file descriptors, system calls and data structures of >>>> their own, here there is simply none: it's just an array of chars. Can >>>> you explain _why_ it doesn't fit in the cgroupfs? >>> What's the hierarchical or delegation behavior? >> >> If a cgroup does not have an app identifier the driver should use the >> one from the closes parent that has one. >> >>> Why do the vast majority of >>> people who don't have the hardware or feature need to see it? We can argue >>> but I can pretty much guarantee that the conclusion is gonna be the same and >>> it's gonna be a waste of time and energy for both of us. >> >> I don't want to argue, I want to understand. My standard is that a >> maintainer that rejects code explains a plan for integrating with his >> subsystem and/or points to existing code that does something similar, >> rather than handwaving it away as something "that I can't remember off >> the top of my head". > > I could be misreading you but my general sense is that you tend to be > antagonistic in sometimes underhanded way, like above - you lifted that part > from a sentence which was listing two examples prior to that phrase. Yes, I did, but I already explained that they are irrelevant. If I ask you to buy me something, asking an extra question and saying "you might want to ask XYZ instead" would make me happier than "you might want to buy that on Amazon or ask someone else I can't remember off the top of my head". Perhaps I needed icecream that Amazon doesn't even sell. :) I do apologize for being too blunt, but here are the reasons you brought up: - "I'm not sure it makes sense to introduce custom IDs for these given that there already are unique per-host cgroup IDs which aren't recycled" (VM IDs are recycled, that's the idea, so I don't think this applies?) - "There are basic problems with e.g. delegation as these things are at odds with everything else sharing the interface" (this I cannot parse at all: what is delegation, who is the everything else that's sharing the interface? why would the problem not be there if you put the interface somewhere in the SCSI layer?) - "people who don't need app_identifier don't see them and preferably can disable them" (ok this I get, but then the same applies to a lot of stuff in sysfs). - "the proposed is akin to adding per-thread application ID to procfs [...] which wouldn't fly well either given the specialized and (at least for now) niche nature of the feature" (so it is basically that it is too specialized; cache allocation technology comes to mind then, it is also very specialized but we _did_ add resctrl hooks into procfs). My feeling (it's a feeling---it doesn't have to be that way!) was that you didn't try too hard to understand the problem and to help the submitter reframe it. As you said very properly, apologies if I'm misunderstanding you, but I would like to be clear about what I perceived. Thanks, Paolo
