[RFC] splitting cgroup.c

[RFC] splitting cgroup.c

[Li Zefan]

While working on cgroup xattr, it appeared to me it's better to
create a cgroup_xattr.c instead of stuffing things into cgroup.c.

Then I took a look at how big it is.

    $ ls -l -S kernel/*.c
    -rw-rw-r--  1 lizf lizf 142717 Jan 18 10:15 cgroup.c
    -rw-rw-r--  1 lizf lizf 106498 Jan 18 10:15 workqueue.c
    -rw-rw-r--  1 lizf lizf 105206 Jan 18 10:15 lockdep.c
    -rw-rw-r--  1 lizf lizf  91321 Jan 18 10:16 module.c
    
    $ wc -l kernel/*.c | sort -n -r
      90397 total
       5289 cgroup.c
       4206 lockdep.c
       3840 workqueue.c
       3507 module.c

So I think for the sake of readability and maintainability, we'd
better split cgroup.c into smaller pieces:

- event_control.c
- css_id.c
- debug.c
- proc.c
- super.c
...
- cgroup.c

We may add xattr.c and release_agency.c as I'm working on them.

Any objection?

Re: [RFC] splitting cgroup.c

[Tejun Heo]

Hello,

On Thu, Jan 19, 2012 at 10:13:59AM +0800, Li Zefan wrote:
> While working on cgroup xattr, it appeared to me it's better to
> create a cgroup_xattr.c instead of stuffing things into cgroup.c.
> 
> Then I took a look at how big it is.
> 
>     $ ls -l -S kernel/*.c
>     -rw-rw-r--  1 lizf lizf 142717 Jan 18 10:15 cgroup.c
>     -rw-rw-r--  1 lizf lizf 106498 Jan 18 10:15 workqueue.c
>     -rw-rw-r--  1 lizf lizf 105206 Jan 18 10:15 lockdep.c
>     -rw-rw-r--  1 lizf lizf  91321 Jan 18 10:16 module.c
>     
>     $ wc -l kernel/*.c | sort -n -r
>       90397 total
>        5289 cgroup.c
>        4206 lockdep.c
>        3840 workqueue.c
>        3507 module.c

Yeah, cgroup.c one giant file.

> 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.

Thanks.

-- 
tejun

Re: [RFC] splitting cgroup.c

[Li Zefan]

>> 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.

Re: [RFC] splitting cgroup.c

[Tejun Heo]

Hello, Li.

On Wed, Jan 18, 2012 at 11:26 PM, Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:
>> 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.

Eh? Feasible or desirable?  How can it be not feasible?  Why?

Thanks.

-- 
tejun