 And that was put down saying that there are only very specific files that you should be allowed to create in the C-group file system. This was, for me, this felt like an inslexibility argument. I understand for a particular distro of some sort, this is a challenge where some user space utilities would not know these files in the standard file systems are coming from BPF and they would sort of start relying on them. But I wonder if it should be allowed in a configurable way to extend these file interfaces with BPF. So maybe I want to create something in procfs and I want to add a file there and I could implement the logic or the content of the file with BPF, similarly in C-groupfs. So does it, I know that, I saw some background in the mailing list threads that there has been, like this has been shot down many times that people don't like it. But could it be under some advanced config or like for some people who have, who know what they're doing, sort of, area? You know what you're doing, config options? Yeah, probably. Like RCU expert BPF expert, right? Yeah, exactly. But what was, like maybe how I can talk through, like what was the problem with the overlay fs, trying to combine BPFfs and C-groupfs? So what the KP talked about was the previous, the very first draft version I come up to solve my problem to talk about this morning. The initial thought I had, the solution I gave was actually to using BPF to extend the C-groupfile system interface, basically you can pin a BPF object in the C-groupfile system. When you pin that, you create an artificial file in the C-groupfile system and then you can read it and write it and it was the same. But this will be becoming very intrusive to the C-groupfile system because it's actually adding files to the C-group interfaces. And that idea was not liked by the C-group maintainers. So after that, I kind of switched to the idea to replicate a C-groupfile hierarchy in the BPF file system. So by replicating these hierarchies, you can create files in the BPF file system and then read the files there. Some thoughts I have from the very first version of the RFC patch was that there are pros and cons for that solution by extending the file system. The pro is that whenever the user creates a C-group, they don't need to have added the BPF programs to create those files because it's really, the C-group file system can create these files for you automatically. So it will be a lot simpler for us, don't have the troubles that I have for the whole complicated infrastructure introduced this morning. The cons is that that will be intrusive to our file system. So that's some kind of background or discussion here. So I think there's one more very big advantage there, right? We want to have, we currently have C-groupv1 that is creating some files in the C-groupfile system. They're not taken, they're in C-groupv2. There are programs that expect those files to be present. So there is code change required, there would be code change required, of course. It's inconvenient, right? It's inflexible, which is something we should try to solve with BPF, which is what we tried in the beginning, but this would make the migration easier because the file would effectively be in the same place implemented by BPF. The contents of the file would be implemented by BPF. The other aspect is in proc, right? I want to add my own custom statistics that would be in proc. Of course, the client library to get these statistics could be sort of, you should just move towards BPF maps and the work how I was doing where you allow certain unprivileged code to read like BPF maps, but in the true Linux sense, we should probably have files in proc that could create like statistics generated by BPF programs. This doesn't fly, people don't like other things adding random files in proc, so... I remember initially I was talking to, Yong Hong told me that when they introduced task ether, they were also thinking about extending the proc file system by using BPF. So in that way, you can parameterize the task ether program and then pin those task ether program in the proc file system under each task directory. So that would be very convenient to use, but they told me that there are some concerns there, so they didn't continue in that path. I'm trying to do very much a similar thing, but eventually we choose to do the currently using this, do it in the BPF file system. So I definitely think that being able to extend the pseudo file system interface with the BPF have some uses. Anything, any pseudo file system like proc, cgroup, whatever, like I... Can we use a relay of this? Yes, that was, I think the question was not answered yet. Sorry, sorry, my bad, my bad. There are also proposals, I tried, the solution is that we have, we use the overlay file system, have a two layers of file system, underneath is the cgroup file system and the top layer is a modifiable file system, maybe BPF file system, so you can pin the, you can have, you create a unified view and which is a combination of the cgroup file system and the BPF file system. You can pin that. The issue here is that because the underlying layers is a cgroup file system and it changes from time to time, but there is a requirement in the overlay file system is that they require the underlying file system be immutable. So if you change the underlying file system, you get undefined behaviors. I tried that, it does, it's very confusing. It causes some issues from the view of the user space. For example, if you create a cgroup in the underneath, directly from the underneath file system and then you delete it, the file is cached there and you get an inconsistent view from the unified file system view. So that doesn't work using overlay file system. So what we could do is telepathically relay this question to the file system summit there, right? Like, can we make overlay FS understand base modifiable file system? Sorry, maybe we can ask them, right? This is something they would probably use because they never considered and it's possible, right? I don't know, I can ask a number about it, but my intuition is that technically it'd be difficult to avoid this assumption, to make it work without breaking our assumption. I haven't thought about it this way. I can ask and then try. I would defer to the experts there. Is that answer to that question? Just a question for understanding, like when you have the lower and upper file system, right? Could also be the lower one BPF and BPF is not modifiable except for within the kernel, so it's more controlled. And the upper one is like the C group, which? No, the eventual file system should be the same type as the upper level, upper layer, because you are pinning from the top level and in the top layer should be the same type as it. It definitely has to be the BPF file system. It cannot be the C group file system. So on a principle standpoint, right? I mean, this is a Trojan horse sort of scenario. We're trying to create files. The files will appear on something on a principle standpoint. Is it, would it be fine to add this functionality in whatever way we can if it is under config expert? But who's the ultimate person who has to like? There's no ultimate like here. It's a combination, right? It's a, well, Linux philosophy, I don't know. Like the proc files is like everything in proc should be like maintained by proc. Like C group maintains the C group. Like overlay, I think making overlay files work in this scenario where you don't have all the rights coming through the upper file system, but lower like in this case like C group can be modified on its own. And the overlay files doesn't do the caching. And like every time for every access it like goes through. I think it should be doable. And this is more of like flexible. Then we can combine like we PFS with the group of us or we PFS with proc of us. And we any other like trace of us, debug of us, see so fast, like any other files. This is the longest overlay fs doesn't maintain this caching layer and does not assume that all of the rights going through the top. I agree with you. And on a principle standpoint, that is the functionality overlay fs is supposed to provide, it is provide extension to like a post design differently. So my understanding. Okay. But maybe it will be not won't be even called overlay fs, but it's, it's pseudo file system that combines two and potentially not being, being a master of either. Okay. Should be doable. So overlay f, you have to mount overall fs. Like it cannot just appear. No, no, no, you don't prevent you have proc of us put overall fs with FFS and it all will work in the same spot. In the same slash bar. I know, I know we use overlay fs in container optimized of us where the base images sort of like read, read only. And then there are, there are overlays that go on top of that. But that is the criteria like how was mentioning that the base file system that, that is being overlaid upon is, is, is not changing. And whereas C group currently changes stuff. I just want to have a practice that like if I want to extend be able to extend proc fs, general, not inside my C group, but like overall, right? Like, how do I do this? Like, do I talk over like fast and do time and. Yeah. And then, and then files appear there, right? Because you mounted it by overlay fs, the files would appear when you're doing like, when you're interacting with the file system. This is my understanding. You can correct me if I'm wrong, right? But my understanding is that the files appear as if it was normal proc fs. This is why I was going to the principle argument, right? In principle, that's the end result. Files appear in proc fs by using overlay fs. So you might have the same principle argument here. But proc fs doesn't appear by its own. Like somebody mounts like system d mounts proc fs. Fs tab or whatever there is. If we would do, well, if we can remount, right? It's like. Yeah, but I think. I think we should just ask the first. We should try hard in this direction. Yeah. I mean, otherwise, like, if you extend one file system specifically, it's just a hack on top of other hacks. I think there was in principle agreement on that the overlay fs approaches is reasonable. It was just the limitation of the overlay fs itself. So, like, say, for example, going back to this group fs, how I think you try to do is not only to pin to one link, one iterator into cgroup fs, but also to make cgroup fs when new cgroups are created, you would transfer the old one and put in a new location. So that's becoming like very, very like BPF specific and so on. So that's what like teaching didn't like me. Like, if it was just like, let's just pin an iterator in cgroup fs and do someone special. Well, we can try to convince like humans, other cgroup folks, at least that would be okay, I think, but like automatically now, like, oh, let's take it from here and pins another place, preserve naming convention or not, like it's just becoming like really, really custom and specific. Yeah, it's gonna be messy, yeah, it's gonna be messy. So also inheritance is also important requirement for us. For example, if you have a cgroup and then you pin to parent cgroup, if you create a Chelsea group, the Chelsea should automatically be getting those pinned objects there. And I can see that pinning on the SQL file system would be difficult to have this inheritance in force. But if we add in the sleepable hooks to cgroup creation, potentially there we can create direct, create files in the cgroup of fs. So that's the thing we can sell. Yeah, yeah, sleep file. When there's things like policy, this automatic stuff is not done by the kernel, by the cgroup code. When it's like just a hook there that can create an iterator and it will do something, then it's, I think, will be fine. Right, right. Just keep this in the back of the mind because it'll make stuff a lot simpler if the files do appear somehow in cgroup fs, right? Like either via an overlay or something. I think it's just that the overlay file system is not intended to be used this way. So it has some special... Evolution. We should, I think we should check with the people there in the fs. Glad. Yeah. Yeah. Yeah. Okay, I think this was good. That's all I had. So we asked for a small topic. Perfect. Thank you. Thanks. Thanks, folks.