]> git.ipfire.org Git - thirdparty/libcgroup.git/commitdiff
README: fix typos across the file
authorKamalesh Babulal <kamalesh.babulal@oracle.com>
Mon, 1 Nov 2021 20:28:59 +0000 (14:28 -0600)
committerTom Hromatka <tom.hromatka@oracle.com>
Mon, 1 Nov 2021 20:29:02 +0000 (14:29 -0600)
Fix a couple of typos across the file.

Signed-off-by: Kamalesh Babulal <kamalesh.babulal@oracle.com>
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
(cherry picked from commit c171be33bce722d92566c78c3b5fefa8ac2a3d92)

README

diff --git a/README b/README
index 54e0f7bb20b16f6b45c2a8f37af22a06d003b7c5..882c9ad22a1df969d228045390abf3af62eb2dbc 100644 (file)
--- a/README
+++ b/README
@@ -3,7 +3,7 @@ Design
 
 After cgroup system has taken shape, its time to have some basic tools
 in user space which can enable a user to use the resource management
-functionality effictively.
+functionality effectively.
 
 One of the needed functionality is rule based placement of a task.  In general,
 there can be either uid or gid or exec based rules. Admin/root will
@@ -142,7 +142,7 @@ rules in /etc/cgrules.conf do following.
   your rules).
 - Run cgrulesengd.
        - ./cgrulesengd
-- Launch some task or login as a user to the sytem. Daemon should automatically
+- Launch some task or login as a user to the system. Daemon should automatically
   place the task in right cgroup.
 
 FAQ
@@ -170,14 +170,14 @@ A. Unix file system provides access control only based on uid/gid. So
  admin will not be able to control that.
 
  [Note: user2 will control what tasks can be added in /container/database/user2
-  and will contol what further subdirs can be created under user2 dir. Root
+  and will control what further subdirs can be created under user2 dir. Root
   should not restrict the control to root only for practical purposes. Its
-  something like that till /container/databse, admin controls the resources
+  something like that till /container/database, admin controls the resources
   and below that how resources are further subdivided among various projects
   should be controlled by respective user].
 
 In the light of above, it seems to make more sense that admin should enforce
 rules only based on uid and gid. Probably later we can have a per user exec
-based rules config file (~/.cgrules.conf), which can be parsed by cgrulesd
+based rules config file (~/.cgrules.conf), which can be parsed by cgrulesengd
 and then jobs launched by user will be placed in right cgroup based on
 combination of rules in /etc/cgrules.conf and ~/cgrules.conf.