proposal /proc/console (was /proc/vidinfo)

proposal /proc/console (was /proc/vidinfo)

Post by Bauke Jan Dou » Sun, 07 May 1995 04:00:00



Hi,

Here's my latest proposal for /proc/console, previously known as
/proc/vidinfo. I renamed it on advice from Daniel Quinlan, who's
cleaning up the /proc filesystem; he also suggested a few changes in
its format, which now looks like this:

type            ega+ color
mode            80x30
crt_index_reg   0x03d4
crt_value_reg   0x03d5
ram             0xb8000-0xc0000

To extract some information from it, e.g.:

  MODE=`sed -n -e 's/^mode      *//p' </proc/console`
  TERM=con$MODE
  cols=${MODE%x[0-9]*}          # if you need them ...
  lines=${MODE#[0-9]*x}         # ... individually

BJ

        Yea, tho I walk through the valley of the shadow of death,
        I shall fear no evil,
        for I am the meanest son of a * in Western Europe

        Have Linux - will travel

-------- cut here --------
*** /usr/src/linux/fs/proc/array.c.old  Sat Apr  8 18:56:30 1995
--- /usr/src/linux/fs/proc/array.c      Thu May  4 20:35:20 1995
***************
*** 27,30 ****
--- 27,33 ----
   * Bruno Haible      :  remove 4K limit for the maps file

+  *
+  * Bauke Jan Douma   :  /proc/console

   */

***************
*** 325,328 ****
--- 328,386 ----
  }

+ static int get_console_info(char * buffer)
+ {
+       unsigned long   video_mem_base;         /* Base of video memory */
+       unsigned long   video_mem_term;         /* End of video memory */
+       /* these two also used in vesa_blank.c */
+       unsigned short  video_port_reg;         /* Video register select port */
+       unsigned short  video_port_val;         /* Video register value port */
+       char *desc;
+
+       /* snatched from console.c -- bjd */    
+       if (ORIG_VIDEO_MODE == 7)       /* Is this a monochrome display? */
+       {
+               video_mem_base = 0xb0000;
+               video_port_reg = 0x3b4;
+               video_port_val = 0x3b5;
+               if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10)
+               {
+                       video_mem_term = 0xb8000;
+                       desc = "ega+ mono";
+               }
+               else
+               {
+                       video_mem_term = 0xb2000;
+                       desc = "mda";
+               }
+       }
+       else                            /* If not, it is color. */
+       {
+               video_mem_base = 0xb8000;
+               video_port_reg = 0x3d4;
+               video_port_val = 0x3d5;
+               if ((ORIG_VIDEO_EGA_BX & 0xff) != 0x10)
+               {
+                       video_mem_term = 0xc0000;
+                       desc = "ega+ color";
+               }
+               else
+               {
+                       video_mem_term = 0xba000;
+                       desc = "cga";
+               }
+       }
+
+       return sprintf(buffer,  "type\t\t%s\n"
+                               "mode\t\t%dx%d\n"
+                               "crt_index_reg\t0x%04x\n"
+                               "crt_value_reg\t0x%04x\n"
+                               "ram\t\t0x%04lx-0x%04lx\n",
+                               desc,
+                               ORIG_VIDEO_COLS, ORIG_VIDEO_LINES,
+                               video_port_reg,
+                               video_port_val,
+                               video_mem_base, video_mem_term );
+ }
+
  static struct task_struct ** get_task(pid_t pid)
  {
***************
*** 753,756 ****
--- 811,815 ----
  extern int get_dma_list(char *);
  extern int get_cpuinfo(char *);
+ extern int get_console_info(char *);
  extern int get_pci_list(char*);

***************
*** 774,777 ****
--- 833,839 ----
                case PROC_CPUINFO:
                        return get_cpuinfo(page);
+                      
+               case PROC_CONSOLE:
+                       return get_console_info(page);

                case PROC_VERSION:
*** /usr/src/linux/fs/proc/root.c.old   Thu Jan 12 15:53:04 1995
--- /usr/src/linux/fs/proc/root.c       Thu May  4 20:35:23 1995
***************
*** 64,67 ****
--- 64,68 ----
  #endif
        { PROC_CPUINFO,         7, "cpuinfo" },
+       { PROC_CONSOLE,         7, "console" },
        { PROC_SELF,            4, "self" },  /* will change inode # */
        { PROC_NET,             3, "net" },
*** /usr/src/linux/include/linux/proc_fs.h.old  Thu Feb 23 16:54:55 1995
--- /usr/src/linux/include/linux/proc_fs.h      Thu May  4 20:35:37 1995
***************
*** 16,19 ****
--- 16,20 ----
        PROC_VERSION,
        PROC_CPUINFO,
+       PROC_CONSOLE,
        PROC_PCI,
        PROC_SELF,      /* will change inode # */
-------- cut here --------

 
 
 

1. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been bitching about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,
everything.)

--Ricky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. eepro100 ?

3. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

4. NEED more loopback devices!!!

5. proposal for /proc/vidinfo

6. OpenServer 5 locks at 'G' at first boot after install

7. /proc/vidinfo proposal revisited

8. Knowledge Inquiry: Can someone tell me about SATAN and where I can get my own copy to play with?

9. Proposal for /proc/vidinfo

10. PROPOSAL: dot-proc interface [was: /proc stuff]

11. /proc/stat description for proc.txt

12. /proc/mounts or /proc/mtab

13. what does /proc or proc stand for?