The two options "CAN bit-timing calculation" and

[socketcan-devel.git] / README

diff --git a/README b/README
index 98772a10b53a804770a8b9abc9fc9e0d1d129be6..e2ab994bcb8500eaa9c267cd012c02c6240e538f 100644 (file)
--- a/README
+++ b/README
@@ -97,11 +97,11 @@ driver which provides a character device interface to send and
 receive raw CAN frames, directly to/from the controller hardware.
 Queueing of frames and higher-level transport protocols like ISO-TP
 have to be implemented in user space applications.  Also, most
-character-device implementation support only one single process to
+character-device implementations support only one single process to
 open the device at a time, similar to a serial interface.  Exchanging
-the CAN controller requires employment of another device dricer and
-often the need for apadption of large parts of the application the new
-driver's API.
+the CAN controller requires employment of another device driver and
+often the need for adaption of large parts of the application to the
+new driver's API.
 
 Socket CAN was designed to overcome all of these limitations.  A new
 protocol family has been implemented which provides a socket interface
@@ -152,7 +152,7 @@ solution for a couple of reasons:
   and IDE subsystems for the devices mentioned above.
 
   The easiest way to implement a CAN device driver is as a character
-  without such a (complete) abstraction layer, as is done by some
+  without such a (complete) abstraction layer, as is done by most
   existing drivers.  The right way, however, would be to add such a
   layer with all the functionality like registering for certain CAN
   IDs, supporting several open file descriptors and (de)multplexing