From owner-linux-activists@joker.cs.hut.fi Fri Nov 20 05:32:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["806" "Fri" "20" "November" "1992" "05:27:24" "+0200"
"Shannon Hendrix" "shendrix@PCS.CNU.EDU " nil "19" "kernel protections..."
"^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA24029
(5.65c8/HUTCS-S 1.4); Fri, 20 Nov 1992 05:32:19 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61528-3>;
Fri, 20 Nov 1992 05:31:40 +0200
Received: from PCS.CNU.EDU ([137.155.2.10])
by niksula.hut.fi with SMTP id <61542-2>; Fri, 20 Nov 1992 05:30:11 +0200
Received: from livonia.PCS.CNU.EDU (livonia.pcs.cnc.edu) by PCS.CNU.EDU (4.1/SMI-4.1)
id AA28713; Thu, 19 Nov 92 22:27:52 EST
Message-Id: <9211200327.AA28713@PCS.CNU.EDU>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
From: shendrix@PCS.CNU.EDU (Shannon Hendrix)
To: linux-activists@joker.cs.hut.fi
Subject: kernel protections...
Date: Fri, 20 Nov 1992 05:27:24 +0200
X-Mn-Key: NORMAL
X-Mn-Key: kernel
I would like to write some programs that change the font on my
VGA card when running under Linux. However, I didn't know if Linux allows
one to mess with the first megabyte of RAM (rather this be a "normal" program
and not an OS modification).
Also, is there any way to switch from one mode to another? I usually
boot in 132x25 but would sometimes like to go back to 80x25. I know how to
write programs that do this with the graphics card but I don't know what all
would be affected by that.
=====================================================
Shannon Hendrix |shendrix@pcs.cnu.edu
Christopher Newport University |---------------------
Newport News, VA |** space for rent **
=====================================================
From owner-linux-activists@joker.cs.hut.fi Sat Nov 21 08:39:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1966" "Fri" "20" "November" "1992" "17:15:44" "+0200"
"gt8134b@prism.gatech.edu" "gt8134b@prism.gatech.edu" nil "47"
"SVGA modes per VC (was kernel protections...)" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA02053
(5.65c8/HUTCS-S 1.4); Sat, 21 Nov 1992 08:39:39 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61958-1>;
Sat, 21 Nov 1992 08:39:25 +0200
Received: from hydra.gatech.edu ([128.61.6.11])
by niksula.hut.fi with SMTP id <61592-1>; Fri, 20 Nov 1992 17:16:11 +0200
Received: from prism (sundial.gatech.edu) by hydra.gatech.edu (5.65c/3.1)
id AA14456; Fri, 20 Nov 1992 10:16:19 -0500
Received: by prism.gatech.edu (4.1/1.0)
id AA19491; Fri, 20 Nov 92 10:16:13 EST
Message-Id: <9211201516.AA19491@prism>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211200327.AA28713@PCS.CNU.EDU>;
from "Shannon Hendrix" at Nov 20, 92 5:27 am
From: gt8134b@prism.gatech.edu
To: linux-activists@joker.cs.hut.fi
Subject: SVGA modes per VC (was kernel protections...)
Date: Fri, 20 Nov 1992 17:15:44 +0200
X-Mn-Key: NORMAL
X-Mn-Key: kernel
> I would like to write some programs that change the font on my
> VGA card when running under Linux. However, I didn't know if Linux allows
> one to mess with the first megabyte of RAM (rather this be a "normal" program
> and not an OS modification).
>
> Also, is there any way to switch from one mode to another? I usually
> boot in 132x25 but would sometimes like to go back to 80x25. I know how to
> write programs that do this with the graphics card but I don't know what all
> would be affected by that.
I am planning to hack the kernel to allow different modes for different
virtual consoles. Having just gotten Linux two weeks ago, I still haven't
really absorbed everything in the kernel source.
The functionality would be provided through an extension of the "setterm"
command sequence (parsed in, er, linux/kernel/chr_drv/console.c, I think).
A friend of mine is a bit squeamish about such fundamental control through
escape sequences, but the vt100 escapes can ruin your session just fine
without any help, so I don't see the added danger. A "stty sane; setterm sane"
should fix things anyway.
To reduce the risk of serious problems, I'd like the console routines to have
some idea of what sort of card you have (so it can reject invalid modes.)
The code in linux/boot/setup.S detects the video card and decides which
SVGA mode it can use, which is exactly what I want.
Now the question: how do I reserve space somewhere for the setup.S
routines to store parameters in (just 2 tiny bytes!), parameters which
the console.c routines can access?
Oh, I just looked at setup.S, and it seems to use the BIOS to change video
modes. Since you know how to program video cards (I'm an ex-Amiga user,so
this new hardware is different and frightening :-), maybe we could work
together?
>
> Shannon Hendrix |shendrix@pcs.cnu.edu
Robert Sanders
gt8134b@prism.gatech.edu
pshuprs@prism.gatech.edu
From owner-linux-activists@joker.cs.hut.fi Sat Nov 21 11:39:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1955" "Sat" "21" "November" "1992" "11:37:37" "+0200"
"Kenneth Falck" "kennu@mdata.fi" nil "43"
"Re: SVGA modes per VC (was kernel protections...)" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA02522
(5.65c8/HUTCS-S 1.4); Sat, 21 Nov 1992 11:39:06 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61683-4>;
Sat, 21 Nov 1992 11:38:45 +0200
Received: from mdata.fi ([192.98.43.1])
by niksula.hut.fi with SMTP id <61677-2>; Sat, 21 Nov 1992 11:38:28 +0200
Received: by mdata.fi (5.65c/1.51PH)
id AA16931; Sat, 21 Nov 1992 11:38:07 +0200
Message-Id: <199211210938.AA16931@mdata.fi>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211201516.AA19491@prism>;
from "gt8134b@prism.gatech.edu" at Nov 20, 92 5:15 pm
X-Mailer: ELM [version 2.3 PL11]
From: Kenneth Falck < kennu@mdata.fi>
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC (was kernel protections...)
Date: Sat, 21 Nov 1992 11:37:37 +0200
X-Mn-Key: NORMAL
X-Mn-Key: kernel
> I am planning to hack the kernel to allow different modes for different
> virtual consoles. Having just gotten Linux two weeks ago, I still haven't
> really absorbed everything in the kernel source.
>
> The functionality would be provided through an extension of the "setterm"
> command sequence (parsed in, er, linux/kernel/chr_drv/console.c, I think).
> A friend of mine is a bit squeamish about such fundamental control through
> escape sequences, but the vt100 escapes can ruin your session just fine
> without any help, so I don't see the added danger. A "stty sane; setterm sane"
> should fix things anyway.
Not to discourage you or anything :-), but is it really the best option
to set up all kinds of new things to work via VT100-like escape codes?
I mean, it might not be that much fun if you run a public access Linux
system, and one day all the practical jokers hear about these codes
that you can play with just with a echo -n ^[[...] > /dev/console...
I was kind of thinking about a special kernel configuration menu,
that could be accessed by pressing a key like maybe SysRq. Like with
dumb terminals. Would this make any sense? Is it possible from
keyboard.c to capture SysRq, display a menu, and then change all
kinds of options from there? I'm not very familiar with the way the
kernel works in general, so if I go adding stuff just like that,
it'll probably halt the whole system until the user exits the menu...
Or maybe the menu should be implemented by an external process, and
you could change things with ioctls or something. Or escape codes,
which brings us back to setterm... :-)
Hmm now that I think more of it, maybe the ^[[..] codes are already
`protected' so that they only work when the process echoing the characters
is owned by root. Or at least, maybe they should be protected...
> Robert Sanders
> gt8134b@prism.gatech.edu
> pshuprs@prism.gatech.edu
--
kennu@mits.mdata.fi
From owner-linux-activists@joker.cs.hut.fi Sun Nov 22 23:54:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1089" "Mon" "23" "November" "1992" "14:52:22" "+0200"
"fjh@cs.mu.oz.au" "fjh@cs.mu.oz.au" nil "32"
"Re: SVGA modes per VC (was kernel protections...)" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA07088
(5.65c8/HUTCS-S 1.4); Sun, 22 Nov 1992 23:54:07 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62605-3>;
Sun, 22 Nov 1992 23:53:42 +0200
Received: from mulga.cs.mu.OZ.AU ([128.250.35.21])
by niksula.hut.fi with SMTP id <62608-1>; Sun, 22 Nov 1992 23:53:05 +0200
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50);
id AA04927
Mon, 23 Nov 1992 08:52:53 +1100 (from fjh)
Received: by munta.cs.mu.OZ.AU (920110.SGI/slave-1.1)
id AA00463; Mon, 23 Nov 92 08:52:51 +1100
Message-Id: <9211222152.463@munta.cs.mu.OZ.AU>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
X-Mailer: ELM [version 2.3 PL11]
From: fjh@cs.mu.oz.au
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC (was kernel protections...)
Date: Mon, 23 Nov 1992 14:52:22 +0200
X-Mn-Key: NORMAL
X-Mn-Key: kernel
Kenneth Falck, you wrote:
>
> Not to discourage you or anything :-), but is it really the best option
> to set up all kinds of new things to work via VT100-like escape codes?
Yes, I think that is probably best.
> I mean, it might not be that much fun if you run a public access Linux
> system, and one day all the practical jokers hear about these codes
> that you can play with just with a echo -n ^[[...] > /dev/console...
That's easily solved. Just set the permissions on the tty devices in /dev
appropriately.
$ echo -n ^[[...] > /dev/console
$ /dev/console: Permission denied
If you want the practical jokers to be able to use write, talk, etc.,
make sure that all the selected programs programs filter their
output through cat -v (write some small wrapper programs if necessary),
and then make them setgid tty.
--
Fergus Henderson fjh@munta.cs.mu.OZ.AU
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!
From owner-linux-activists@joker.cs.hut.fi Mon Nov 23 12:18:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["787" "Mon" "23" "November" "1992" "12:17:31" "+0200"
"Mika Liljeberg" "liljeber@cs.Helsinki.FI " nil "23"
"Re: SVGA modes per VC (was kernel protections...)" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA10158
(5.65c8/HUTCS-S 1.4); Mon, 23 Nov 1992 12:18:29 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61791-1>;
Mon, 23 Nov 1992 12:18:08 +0200
Received: from hydra.Helsinki.FI ([128.214.4.29])
by niksula.hut.fi with SMTP id <61755-1>; Mon, 23 Nov 1992 12:17:50 +0200
Received: from kypros (kypros.Helsinki.FI) by hydra.Helsinki.FI (4.1/SMI-4.1/36)
id AA11414; Mon, 23 Nov 92 12:18:01 +0200
Message-Id: <9211231018.AA11414@hydra.Helsinki.FI>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211222152.463@munta.cs.mu.OZ.AU>;
from "fjh@cs.mu.oz.au" at Nov 23, 92 2:52 pm
X-Mailer: ELM [version 2.3 PL11]
From: liljeber@cs.Helsinki.FI (Mika Liljeberg)
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC (was kernel protections...)
Date: Mon, 23 Nov 1992 12:17:31 +0200
X-Mn-Key: NORMAL
Wow! Are you going to write a driver for all those SVGA cards?
Say, how are you going to do it? Flip the processor into vm86
mode and use the video bios, or program the cards directly?
> > Not to discourage you or anything :-), but is it really the best option
> > to set up all kinds of new things to work via VT100-like escape codes?
>
> Yes, I think that is probably best.
Btw, why not just use ioctls? There's even supposed to be a
preferred interface for doing this. One that Xfree86 can use.
Heh, t'would be cool to run X in two different virtual consoles.
Seriously, you're considering a major project here. I wish you the
best of luck.
Mika
--
Mika Liljeberg Email: liljeber@hydra.Helsinki.FI
Helsinki University Mika.Liljeberg@Helsinki.FI
Dept. of Computer Science
From owner-linux-activists@joker.cs.hut.fi Mon Nov 23 16:34:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1244" "Mon" "23" "November" "1992" "16:27:15" "+0200"
"gt8134b@prism.gatech.edu" "gt8134b@prism.gatech.edu" nil "31"
"Re: SVGA modes per VC (was kernel protections...)" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA12145
(5.65c8/HUTCS-S 1.4); Mon, 23 Nov 1992 16:34:36 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61755-1>;
Mon, 23 Nov 1992 16:34:10 +0200
Received: from hydra.gatech.edu ([128.61.6.11])
by niksula.hut.fi with SMTP id <62036-2>; Mon, 23 Nov 1992 16:32:34 +0200
Received: from prism (sundial.gatech.edu) by hydra.gatech.edu (5.65c/3.1)
id AA21317; Mon, 23 Nov 1992 09:27:44 -0500
Received: by prism.gatech.edu (4.1/1.0)
id AA27672; Mon, 23 Nov 92 09:27:43 EST
Message-Id: <9211231427.AA27672@prism>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211231018.AA11414@hydra.Helsinki.FI>;
from "Mika Liljeberg" at Nov 23, 92 12:17 pm
From: gt8134b@prism.gatech.edu
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC (was kernel protections...)
Date: Mon, 23 Nov 1992 16:27:15 +0200
X-Mn-Key: NORMAL
> Wow! Are you going to write a driver for all those SVGA cards?
> Say, how are you going to do it? Flip the processor into vm86
> mode and use the video bios, or program the cards directly?
Hey, I didn't check the kernel sources well enough before planning,
but you don't need to rub salt in the wounds. :-). Here was my
reasoning:
1) everyone says "Linux doesn't use the BIOS"
2) Linux lets me choose my video mode
3) Some code in boot/setup.S recognizes different card types
therefore, all the SVGA drivers are in there and there's no worry. All I
have to do is twiddle some stuff here, add a few lines there. Little did
I know that Linux uses the BIOS's dying breath to do the video magic.
> Seriously, you're considering a major project here. I wish you the
> best of luck.
I am rapidly unconsidering it. Not that I'm afraid of the project, just
that I think a change this major should be done by a licensed professional
(Linus). I'd hate to add something that wouldn't even last across kernel
revisions long enough to get stable.
> Mika Liljeberg Email: liljeber@hydra.Helsinki.FI
> Helsinki University Mika.Liljeberg@Helsinki.FI
> Dept. of Computer Science
Robert Sanders
gt8134b@prism.gatech.edu
From owner-linux-activists@joker.cs.hut.fi Wed Nov 25 00:24:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1826" "Wed" "25" "November" "1992" "00:19:14" "+0200"
"Zeyd M. Ben-Halim" "zmbenhal@netcom.com " nil "50"
"Re: SVGA modes per VC" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA22288
(5.65c8/HUTCS-S 1.4); Wed, 25 Nov 1992 00:23:48 +0159
Received: from joker.cs.hut.fi by niksula.hut.fi id <61746-2>;
Wed, 25 Nov 1992 00:23:35 +0200
Received: from netcom2.netcom.com ([192.100.81.108])
by niksula.hut.fi with SMTP id <61777-3>; Wed, 25 Nov 1992 00:23:18 +0200
Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom)
id AA25500; Tue, 24 Nov 92 14:19:42 -0800
Message-Id: <9211242219.AA25500@netcom2.netcom.com>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
From: zmbenhal@netcom.com (Zeyd M. Ben-Halim)
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC
Date: Wed, 25 Nov 1992 00:19:14 +0200
X-Mn-Key: NORMAL
>> Wow! Are you going to write a driver for all those SVGA cards?
>> Say, how are you going to do it? Flip the processor into vm86
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This would be the most useful approach, IMHO. This will allow
us to disregard the differences between the VGA cards (exaclty
what the BIOS is for). twidlling the registers should be used for
everything except mode setting.
>> mode and use the video bios, or program the cards directly?
>Hey, I didn't check the kernel sources well enough before planning,
>but you don't need to rub salt in the wounds. :-). Here was my
>reasoning:
> 1) everyone says "Linux doesn't use the BIOS"
> 2) Linux lets me choose my video mode
> 3) Some code in boot/setup.S recognizes different card types
>
>therefore, all the SVGA drivers are in there and there's no worry. All I
>have to do is twiddle some stuff here, add a few lines there. Little did
>I know that Linux uses the BIOS's dying breath to do the video magic.
>
>> Seriously, you're considering a major project here. I wish you the
>> best of luck.
>
>I am rapidly unconsidering it. Not that I'm afraid of the project, just
^^^^^^^^^^^^^
Please reconsider! DJGPP flips back to real-mode to do int10 (video) and
int33 (mouse). So it is doable. I think Linus (or TPTB) frown on such an
idea even though it would save people many hours in twidlling with Xconfig
files and the like.
>that I think a change this major should be done by a licensed professional
>(Linus). I'd hate to add something that wouldn't even last across kernel
>revisions long enough to get stable.
>
>> Mika Liljeberg Email: liljeber@hydra.Helsinki.FI
>> Helsinki University Mika.Liljeberg@Helsinki.FI
>> Dept. of Computer Science
>
>Robert Sanders
>gt8134b@prism.gatech.edu
>
Zeyd
zmbenhal@netcom.com
From owner-linux-activists@joker.cs.hut.fi Wed Nov 25 04:23:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["5824" "Wed" "25" "November" "1992" "04:19:04" "+0200"
"Craig Metz" "cmetz@thor.tjhsst.edu" nil "116"
"Re: SVGA modes per VC " "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA23108
(5.65c8/HUTCS-S 1.4); Wed, 25 Nov 1992 04:23:53 +0159
Received: from joker.cs.hut.fi by niksula.hut.fi id <61599-2>;
Wed, 25 Nov 1992 04:23:44 +0200
Received: from thor.tjhsst.edu ([192.65.174.100])
by niksula.hut.fi with SMTP id <61596-4>; Wed, 25 Nov 1992 04:23:29 +0200
Received: by thor.tjhsst.edu (5.67/TJ1.06)
id AA03636; Wed, 25 Nov 92 02:19:44 GMT
Message-Id: <9211250219.AA03636@thor.tjhsst.edu>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: Your message of "Wed, 25 Nov 1992 00:19:14 +0200 ."
<9211242219.AA25500@netcom2.netcom.com>
From: Craig Metz < cmetz@thor.tjhsst.edu>
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC
Date: Wed, 25 Nov 1992 04:19:04 +0200
Cc: linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
In message <9211242219.AA25500@netcom2.netcom.com> you write:
>>> Wow! Are you going to write a driver for all those SVGA cards?
>>> Say, how are you going to do it? Flip the processor into vm86
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>This would be the most useful approach, IMHO. This will allow
>us to disregard the differences between the VGA cards (exaclty
>what the BIOS is for). twidlling the registers should be used for
>everything except mode setting.
>
>>> mode and use the video bios, or program the cards directly?
>>Hey, I didn't check the kernel sources well enough before planning,
>>but you don't need to rub salt in the wounds. :-). Here was my
>>reasoning:
>> 1) everyone says "Linux doesn't use the BIOS"
>> 2) Linux lets me choose my video mode
>> 3) Some code in boot/setup.S recognizes different card types
>>
>>therefore, all the SVGA drivers are in there and there's no worry. All I
>>have to do is twiddle some stuff here, add a few lines there. Little did
>>I know that Linux uses the BIOS's dying breath to do the video magic.
>>
>>> Seriously, you're considering a major project here. I wish you the
>>> best of luck.
>>
>>I am rapidly unconsidering it. Not that I'm afraid of the project, just
> ^^^^^^^^^^^^^
>Please reconsider! DJGPP flips back to real-mode to do int10 (video) and
>int33 (mouse). So it is doable. I think Linus (or TPTB) frown on such an
>idea even though it would save people many hours in twidlling with Xconfig
>files and the like.
>
>>that I think a change this major should be done by a licensed professional
>>(Linus). I'd hate to add something that wouldn't even last across kernel
>>revisions long enough to get stable.
>>
>>> Mika Liljeberg Email: liljeber@hydra.Helsinki.FI
>>> Helsinki University Mika.Liljeberg@Helsinki.FI
>>> Dept. of Computer Science
>>
>>Robert Sanders
>>gt8134b@prism.gatech.edu
>>
>
>Zeyd
>zmbenhal@netcom.com
I'll keep the evangelism short, but this is a good example of one of
the biggest problems we face - the "DOS Mentality". One part of which is the
insatiable urge to use the BIOS to solve all of our problems. I will present
four simple reasons why, IMO, we should avoid the BIOS at all cost, and
certainly this idea should not be taken any further.
1. Speed
I do have neither the resources nor the time to tell you exactly how
much time the CPU would spend in the process of setting up for a Virtual 8086-
mode session, switching to that session, executing the BIOS code, and then
returning to normal Protected Mode and restoring the session state, but needless
to say, this involves a significant amount of overhead and requires that the
CPU be in a state where it is not doing anything else for an excessive amount
of time. At the bare minimum, IRQs will be unserviced during this period, but
there could be other complications depending on actual implementation.
2. Documentation
I know of no less than one university local to me that actually uses
the Linux kernel in a course on operating systems, and I am sure that there
are others. Also, the Linux kernel contains information on the inner workings
of the PC hardware and code that actually uses this hardware in a level of
detail which I dare venture to say has not been available to the public domain
ever before. Every added device driver in the kernel or in XFree86 is a very
good source of real, production code using the hardware directly. By using a
BIOS, you will not be providing any sort of documentation on the way the
hardware works.
3. Portability and identity
If we simply go about implementing things as vm86 calls to a BIOS, then
first of all, how can this be translated to other free PC operating systems
like 386BSD or Mach? Many people in the Linux user community have such a strong
liking for Linux that they will go to unjustified steps to demean and degrade
these systems and others like them, but ultimately there are so many benefits
to writing code that is at least translatable between these kernels that we
should try to do so if we can. Certainly, if we were to put code in our kernel
to do vm86 calls to the BIOS to do things, it would be a cop-out, and would not
help any of those development efforts any. And if we spend more and more of our
time simply switching to vm86 mode and running the BIOS code, then Linux would
become more of a 386/DOS Extender of sorts than a real operating system.
4. "Universal" Support
I can see where those who would like universal support are coming from,
and if that is your end, then BIOS use is a nice sounding means. But given the
complexity involved, I ask you, do we need to support everything? I would much
rather see the products of those manufacturers which gladly provide technical
documentation and assistance to hobbyists so they can add direct-programming
support for the product be supported than those manufacturers which naively and,
in a few instances, arrogantly horde the low-level information on their products
using such excuses as "Proprietary information" to try to justify their
paranoia. As it stands now, Linux does not support every product there is, and
I feel very strongly that we should not kid ourselves by trying to make it do
so.
To all those who are not convinced by my admittedly not very convincing
arguments, I leave you one last thought: Are *YOU* going to write the code to
do this? I am somewhat angered by the number of people who will feverishly
clamor for something to be done, but when it comes time to do it, none of them
are willing to try. If somebody can turn this idea into code and make diffs
for the masses, then we will see if it is a reasonable solution in practice.
All the debating in the world, however, won't get anything done. Those who
stand firmly by this idea, please go and code it.
-Craig
From owner-linux-activists@joker.cs.hut.fi Wed Nov 25 09:10:45 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2049" "Wed" "25" "November" "1992" "01:24:10" "+0200"
"Ed Carp" "erc@khijol.uucp " nil "34" "Re: SVGA modes per VC" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA24244
(5.65c8/HUTCS-S 1.4); Wed, 25 Nov 1992 09:10:41 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61598-4>;
Wed, 25 Nov 1992 09:10:28 +0200
Received: from uplherc.upl.com ([131.219.5.10])
by niksula.hut.fi with SMTP id <61631-2>; Wed, 25 Nov 1992 09:09:10 +0200
Received: from saturn.upl.com by uplherc.upl.com (4.1/SMI-4.1)
id AA27945; Wed, 25 Nov 92 00:08:52 MST
Received: from khijol.UUCP by saturn.upl.com (4.1/SMI-4.1)
id AA01584; Wed, 25 Nov 92 00:08:51 MST
Received: by khijol.uucp (Smail3.1.28.1 #2)
id m0muGAw-0000G4C; Tue, 24 Nov 92 23:24 MST
Message-Id: < m0muGAw-0000G4C@khijol.uucp>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: <9211250219.AA03636@thor.tjhsst.edu>
from "Craig Metz" at Nov 25, 92 04:19:04 am
Reply-To: erc@saturn.upl.com
X-Organization: Computer Security Technologies - Salt Lake City, UT
X-Mailer: ELM [version 2.4 PL3]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2048
From: erc@khijol.uucp (Ed Carp)
To: linux-activists@joker.cs.hut.fi
Subject: Re: SVGA modes per VC
Date: Wed, 25 Nov 1992 01:24:10 +0200
Cc: linux-activists@joker.cs.hut.fi (Linux Activists Mailing List)
X-Mn-Key: NORMAL
> I know of no less than one university local to me that actually uses
> the Linux kernel in a course on operating systems, and I am sure that there
> are others. Also, the Linux kernel contains information on the inner workings
> of the PC hardware and code that actually uses this hardware in a level of
> detail which I dare venture to say has not been available to the public domain
> ever before. Every added device driver in the kernel or in XFree86 is a very
> good source of real, production code using the hardware directly. By using a
> BIOS, you will not be providing any sort of documentation on the way the
> hardware works.
Uh, is there any way to get one's hands on the course materials, especially
the internals notes? Now *that* would be a *very* handy document to have!
I'm considering switching to 386BSD, partially because BSD is so well documented,
both internally (I refer you to the "Berkeley Software Architecture Manual",
the "Installing and Operating" guide, "Building Kernels with Config", and the
"Network Implementation Notes"), aswell as the excellent book, "The Design and
Implementation of the 4.3BSD UNIX Operating System". I'd sure like to see
this kind of quality documentation for Linux. I'd write it myself, but it
would sure save me a lot of slaving over the code if I could have a starting
point.
386BSD also has a central point for distribution of patches, which is a serious
flaw for Linux, IMHO. The patch mechanisms are in place and reportedly work
very well - perhaps it's time for some of the Linux die-hards to look and see
what the 386BSD community has done. Seems to me that a pooling of talent and
efforts is in order.
--
Ed Carp, N7EKG erc@apple.com, khijol!erc@saturn.upl.com 801/538-0177
"There is nothing to seek and nothing to find. You're already enlightened,
and all the words in the world won't give you what you already have. The wise
seeker, therefore, is concerned with one thing only: to become aware of what
he already is, of the True Self within." -- Zen maxim
From owner-linux-activists@joker.cs.hut.fi Wed Nov 25 17:52:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2321" "Wed" "25" "November" "1992" "18:54:30" "+0200"
"Eric Youngdale" "eric@tantalus.nrl.navy.mil " nil "42"
"SVGA modes per VC" "^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA28675
(5.65c8/HUTCS-S 1.4); Wed, 25 Nov 1992 17:52:22 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61629-1>;
Wed, 25 Nov 1992 17:51:55 +0200
Received: from V6550C.NRL.NAVY.MIL ([128.60.11.7])
by niksula.hut.fi with SMTP id <61531-2>; Wed, 25 Nov 1992 17:51:43 +0200
Received: from tantalus.nrl.navy.mil by V6550C.NRL.NAVY.MIL (MX V2.3) with
SMTP; Wed, 25 Nov 1992 10:52:43 EST
Received: by tantalus.nrl.navy.mil (4.1/SMI-4.1) id AA22281; Wed, 25 Nov 92
11:54:58 EST
Message-Id: <9211251654.AA22281@tantalus.nrl.navy.mil>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: Ed Carp's message of Wed, 25 Nov 1992 01:24:10 +0200
< m0muGAw-0000G4C@khijol.uucp>
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
To: linux-activists@joker.cs.hut.fi
Subject: SVGA modes per VC
Date: Wed, 25 Nov 1992 18:54:30 +0200
Cc: linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
>Uh, is there any way to get one's hands on the course materials, especially
>the internals notes? Now *that* would be a *very* handy document to have!
>I'm considering switching to 386BSD, partially because BSD is so well documented,
>both internally (I refer you to the "Berkeley Software Architecture Manual",
>the "Installing and Operating" guide, "Building Kernels with Config", and the
>"Network Implementation Notes"), aswell as the excellent book, "The Design and
>Implementation of the 4.3BSD UNIX Operating System". I'd sure like to see
>this kind of quality documentation for Linux. I'd write it myself, but it
>would sure save me a lot of slaving over the code if I could have a starting
>point.
Unfortunately, the linux kernel is changing enough that a book would be
out of date before it hit the shelves. I do think that the pace is going to
let up quite a bit, because over the past 6 months, we have been seeing various
minixisms dissappear one by one. Personally, I learn about whatever I need in
order to get the job at hand done. I am now pretty good with block devices and
filesystems, but I know next to nothing about how the memory manager works, for
example.
The best reference is probably the NORMAL channel. The people who are
the most familiar with various parts of the kernel can answer your questions.
>386BSD also has a central point for distribution of patches, which is a serious
>flaw for Linux, IMHO. The patch mechanisms are in place and reportedly work
>very well - perhaps it's time for some of the Linux die-hards to look and see
>what the 386BSD community has done. Seems to me that a pooling of talent and
>efforts is in order.
I would tend to agree with some of the points here. Some things are on
tsx-11, others are on sunsite, and some things can only be found on
nic.funet.fi. If we could centralize this somehow, and have the other sites
act as mirrors, it would be a great improvement.
As for the rest of BSD386, I am not as familiar with how things are
laid out for them. I poke my nose over there every once in a while to see what
they are up to, but I really do not have the time and disk space to have both
systems on my machine. Could you describe for us in more detail the things
that they have that you think that linux should also have?
-Eric
From owner-linux-activists@joker.cs.hut.fi Wed Nov 25 20:41:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1977" "Wed" "25" "November" "1992" "20:39:56" "+0200"
"Theodore Ts'o" "tytso@ATHENA.MIT.EDU " nil "41"
"Linux documentation and central distribution (Was: SVGA modes per VC)"
"^From:" nil nil "11"])
Received: from joker.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA29379
(5.65c8/HUTCS-S 1.4); Wed, 25 Nov 1992 20:41:14 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <62116-2>;
Wed, 25 Nov 1992 20:40:57 +0200
Received: from tsx-11.MIT.EDU ([18.172.1.2])
by niksula.hut.fi with SMTP id <62074-2>; Wed, 25 Nov 1992 20:40:40 +0200
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA02564; Wed, 25 Nov 92 13:40:24 EST
Message-Id: <9211251840.AA02564@tsx-11.MIT.EDU>
Sender: owner-linux-activists@joker.cs.hut.fi
X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
In-Reply-To: Ed Carp's message of Wed, 25 Nov 1992 01:24:10 +0200,
< m0muGAw-0000G4C@khijol.uucp>
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: linux-activists@joker.cs.hut.fi
Subject: Linux documentation and central distribution (Was: SVGA modes per VC)
Date: Wed, 25 Nov 1992 20:39:56 +0200
Cc: linux-activists@joker.cs.hut.fi
X-Mn-Key: NORMAL
From: khijol!erc (Ed Carp)
Date: Wed, 25 Nov 1992 01:24:10 +0200
Uh, is there any way to get one's hands on the course materials, especially
the internals notes? Now *that* would be a *very* handy document to have!
I'm considering switching to 386BSD, partially because BSD is so well
documented.....
uh.... have you actually tried to trace through BSD code, or try to
debug it, or add significant new features to it? I assure that the
Linux kernel is much easier to understand than the BSD one. Indeed, the
reason why there are so many books is because you *need* them.
After all, just because a VCR has a 2 inch think manual, does not mean
that it is easier to program than a VCR that has only a 2 page manual,
but has on-screen prompts. Length and size of documentation is not the
only measure of a products usability! (In fact, you might claim an
inverse relationship....)
386BSD also has a central point for distribution of patches, which is
a serious flaw for Linux, IMHO. The patch mechanisms are in place
and reportedly work very well - perhaps it's time for some of the
Linux die-hards to look and see what the 386BSD community has done.
Seems to me that a pooling of talent and efforts is in order.
Again, just because 386 BSD has a central point for patch distribution
doesn't mean that it is necessarily superior. After all, recall that
386 BSD seems to be settling on a 6-9 month time period between
releases, where as Linus releases new kernels every 1-3 weeks. With
that sort of release schedule, you don't *need* a central point for
patch distribution, at least for the kernel. As for the utilities, the
central point for patch distribution should be the places where we
originally got the program. So, for example, in many places the FSF
should be the places to report bugs and send in patches.
Creating new central bureaucracies is very rarely the real solution to
problems, real or imagined.
- Ted