[Linuxconsole-commit]CVS: ruby/web/htdocs/paper fbdev.html,1.3,1.4 index.html,1.1,1.2

[Brad M. <bra...@us...>]

Update of /cvsroot/linuxconsole/ruby/web/htdocs/paper
In directory usw-pr-cvs1:/tmp/cvs-serv6851

Modified Files:
	fbdev.html index.html 
Log Message:
finished proofing what's here


Index: fbdev.html
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/paper/fbdev.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- fbdev.html	16 Apr 2002 19:45:13 -0000	1.3
+++ fbdev.html	3 May 2002 23:00:34 -0000	1.4
@@ -57,8 +57,8 @@
 </H2>
 
 <P>
-    If you look at the current framebuffer console layer you will see alot 
-of replicated code and and huge of code handling tty/console functionality.
+    If you look at the current framebuffer console layer you will see a lot 
+of replicated code and and huge amount of code handling tty/console functionality.
 
 </P>
 
@@ -77,13 +77,13 @@
 struct vc_data to data in a device independent way in struct fb_info. Then
 various functions in struct fb_ops will be called to store the device
 dependent state in the par field in struct fb_info and to change the
-hardware to that state. This allows a very clean seperation of the fbdev
+hardware to that state. This allows a very clean separation of the fbdev
 layer from the console layer. It also allows one to use fbdev on its own
-which is a bounus for embedded devices. The reason this approach works is
-for each framebuffer device when used as a tty/console device is allocated
+which is a bonus for embedded devices. The reason this approach works is
+because each framebuffer device, when used as a tty/console device, is allocated
 a set of virtual terminals to it. Only one virtual terminal can be active
 per framebuffer device. We already have all the data we need in struct
-vc_data so why store a bunch of colormaps and other fbdev specific data
+vc_data so we shouldn't store a bunch of colormaps and other fbdev specific data
 per virtual terminal.
 </P>
 

Index: index.html
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/paper/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- index.html	12 Apr 2002 19:11:16 -0000	1.1
+++ index.html	3 May 2002 23:00:35 -0000	1.2
@@ -121,25 +121,25 @@
 have very different needs and are very different from the classical PC. 
 The initial Linux kernel code was designed on the standard PC which had a large 
 influence on the code design. As Linux appears on new types of hardware devices
-we begain to see limitations to some of the central designs. As Linux kept 
-evolving and expanding to new platforms hardware was encountered that didn't
-fit the "PC" model. So instead often a extra interface of some kind either 
-userland or in kernel space was developed to compensate. 
+we began to see limitations of some of the central designs. As Linux kept 
+evolving and expanding to new platforms, hardware was encountered that didn't
+fit the "PC" model. So instead often an extra interface of some kind, either 
+userland or in kernel space, was developed to compensate. 
 
 <P>
-One of the major areas of the kernel affected by this is the tty layer. Here we 
+One of the major areas of the kernel affected by this is the tty layer. Here
 we witness things like the classical definition for a virtual terminal
 starting to break down and the handling of complex human input devices 
 addressed by the tty layer. Also for embedded devices size is critical 
 especially when dealing with boot loaders which often make certain assumptions 
-or place certain limitations. Modular is also lacking. Often with modern embedded 
+or place certain limitations. Modularity is also lacking. Often with modern embedded 
 devices we have removable pieces of hardware including things like keyboards
-which where in a classic PC sense critical to have.
+which were in a classic PC sense critical to have.
 
 <P>
 A major way of rethinking was needed to rework the tty layer. That way was to 
-reverse the flow of developement. The current way of thinking is expand the tty
-features with new device interfaces that influence the behavior of the TTY. A
+reverse the flow of development. The current way of thinking is to expand the tty
+features with new device interfaces that influence the behavior of the TTY. An
 example of this is for a framebuffer console we use a /dev/fb interface to resize
 a tty device. The proper method to resize would be to use a standard that already
 exist i.e the POSIX tty ioctl call TIOCSWINSZ.