>> So I think for the sake of readability and maintainability, we'd >> better split cgroup.c into smaller pieces: > > I agree that splitting is necessary but IMHO splitting usually tends > to go too far. Maybe we can split it into two and think about further > splitting later on? e.g. internal logic vs. userland interfacing. > This isn't feasible. The feasible way is to split by functionality, which I think was the way taken by perf developers. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
