More docs

dist.ini

@@ -0,0 +1,27 @@
+name    = Sys-Linux-Cgroup
+author  = Ryan Voots <simcop2387@simcop2387.info>
+license = Perl_5
+copyright_holder = Ryan Voots
+copyright_year   = 2019
+
+[@Starter]
+revision = 2
+-remove = GatherDir
+-remove = Pod2Readme
+
+[Git::GatherDir]
+
+[Git::Tag]
+[GitHub::Meta]
+[Git::Push]
+[Readme::Brief]
+
+[RewriteVersion]
+
+[BumpVersionAfterRelease]
+[AutoPrereqs]
+
+[Test::Perl::Critic]
+critic_config = perlcritic.rc
+
+[CheckChangesHasContent]

lib/Sys/Linux/Cgroup.pm

@@ -0,0 +1,99 @@
+package Sys::Linux::Cgroup;
+
+# ABSTRACT: Provides API for Linux cgroup v1 and v2 apis
+
+use Moo;
+
+our $VERSION = '0.001';
+
+1;
+__END__
+
+=head1 DESCRIPTION
+
+This module is an easy to use API to work with the Linux kernel cgroup API.  The main purposes of this API are to restrict
+the resource usage of a group of processes, be it I/O, CPU usage, Memory, or even Network bandwidth.  This module will support
+both the newer version 2 api and the original version 1 api of the kernel to maximize support.  This parent module will have
+a high level api that will select the best API implementation for use automatically, typically version 2.
+
+The documentation here will be reflective of the Perl API implemented by this module, exact behavior of the kernel side of things
+is subject to change without this module being invovled.  You should consult the Linux Kernel documentation L<... kernel.org link>
+for the authoritative behavior of the underlying API.
+
+=head1 SYNOPSIS
+
+Quick example of limiting memory usage
+
+    my $group = Sys::Linux::Cgroup->new(name => "naughty_children", memory => {...});
+
+    $group->add_process($pid); # Process must be a child or owned by $UID
+
+=head1 V1 or V2
+
+There's two versions of the cgroup api in the wild, V1 and V2.  V1 has each type of controller in it's own heirarchy, which means that you can have two different trees of cgroups for different types of resource management.  This largely turned out to be a bad idea because it made management more difficult since there's a lot more to keep track of.  It also didn't really pan out that anyone seemed to actually want the flexibility that this allowed.  V2 changed this by having a single heirarchy that starts at a root node where every process is in by default.  Then you can make children in each cgroup and enable the controllers that you want there.  
+
+=head1 CONTROLLERS
+
+The cgroup API works by classifying the types of limits you want to use, calling them Controllers. 
+
+=head2 Memory
+
+With this you can restrict a lot of the memory options for processes.  For details see L<Sys::Linux::Cgroup::Memory> # TODO make pod for this
+
+=head2 CPU
+
+=head2 I/O
+
+=head2 Network
+
+This controller groups all the network traffic being used by the processes, both with latency and bandwidth.  Very useful for testing or preventing a run-away process from eating up all the bandwidth during an upload, copy or some other operation
+
+=head2 Devices
+
+This lets you restrict the 
+
+=head2 Freezer
+
+This one isn't quite the same as the others, it doesn't restrict any actual resource units but does let you stop all of the processes in the group.
+It can be polled to find out if all of the processes are stopped, and carrys on to all child cgroups and child processes automatically.  This lets you
+stop all processes to send them a signal, e.g. SIGKILL, without worrying that they're spawning new children while you try to signal them.  In version 2, this is a property of the group as a whole and not a separate controller.
+
+See L<Sys::Linux::Cgroup::V1::Freezer> or L<Sys::Linux::Cgroup::V2>
+
+N.B. To be truly race-free for sending signals or doing other things with the processes you will also need to use the upcoming C<pidfd> support in newer linux kernels (5.3 and above).  No library currently exists for using this from perl.  Coming Soon.
+
+=head2 RDMA
+
+This one is going to be the last I implement, simply because it's utility for perl code is likely to be very very low.  It deals with how many RDMA handles can be allocated.  Might be useful to have for perl code that manages other processes but that's about it.
+
+=head2 perf_event
+
+This is also going to be a low priority as it deals with performance counters in the kernel and cpu.  This is less likely to be useful for perl code, but might be useful for monitoring the health of another program.
+
+=head1 WARRANTY
+
+This is alpha quality releases right now, there is no warranty.  You use this at your own risk.
+
+=head1 TODO
+
+=over 1
+
+=item Make TODO list
+
+=item Add cgroup v1 apis
+
+=item Add cgroup v2 apis
+
+=item Add high level api that uses either version api to accomplish the needed groupings
+
+=back
+
+=head1 SEE ALSO
+
+L<App::EvalServerAdvanced::REPL>, L<App::EvalServerAdvanced::Protocol>
+
+=head1 AUTHOR
+
+Ryan Voots <simcop@cpan.org>
+
+=cut

lib/Sys/Linux/Cgroup/V1.pm

@@ -0,0 +1,5 @@
+package Sys::Linux::Cgroup::V1;
+
+use Moo;
+
+1;

lib/Sys/Linux/Cgroup/V2.pm

@@ -0,0 +1,5 @@
+package Sys::Linux::Cgroup::V2;
+
+use Moo;
+
+1;

perlcritic.rc

@@ -0,0 +1,3 @@
+# .perlcriticrc
+theme = freenode
+severity = 1