Newsgroups: comp.os.linux
From: techs@pioneer.unm.edu (Erik Fichtner)
Subject: Problem with inb and outb.... Segmentation Fault?!??
Date: Sun, 14 Jun 92 02:52:45 GMT
Organization: Space and Planetary Image Facility
Keywords: inb outb broken doesn't_work.
Well, Here I am working on the dos emulator.... more things
work, but trying to get the inb and outb functions to work
causes a segmentation fault...
Here's what i did...
#include < asm/io.h>
whenever there's a call to either inb or outb, which are assembled
in the .h file, it crashes the program with a segmentation fault.
Why doesn't this code work? it's distributed with the compiler, I'd
expect it to work. /usr/src/linux/include/asm/io.h doesn't work
and it should since the KERNEL uses these functions without any
problems.
What's wrong here??!
Totally confused,
--
Techs
[techs@pioneer.unm.edu][Space and Planatary Image Facility]
"What do ya mean I ain't kind? Just not *your* kind!" - Megadeth
Disclaimer - Any inaccuracies are caused by the phase of the moon.
Newsgroups: comp.os.linux
From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Subject: Re: Problem with inb and outb.... Segmentation Fault?!??
Nntp-Posting-Host: tartarus.uwa.edu.au
Organization: University of Western Australia
Date: Sun, 14 Jun 1992 10:26:04 GMT
techs@pioneer.unm.edu (Erik Fichtner) writes:
: Well, Here I am working on the dos emulator.... more things
: work, but trying to get the inb and outb functions to work
: causes a segmentation fault...
:
: Here's what i did...
:
: #include < asm/io.h>
:
: whenever there's a call to either inb or outb, which are assembled
: in the .h file, it crashes the program with a segmentation fault.
:
: Why doesn't this code work? it's distributed with the compiler, I'd
: expect it to work. /usr/src/linux/include/asm/io.h doesn't work
: and it should since the KERNEL uses these functions without any
: problems.
: What's wrong here??!
User programs CAN'T do arbitrary I/O to ports. You have to go via the
ioperm sys call to explicity allow it. In general you shouldn\'t need to
go to the ports as linux can get very confused if you do. Allowing the
dos emulator to do all the port I/O it wants is almost guarenteed to
crash linux.. ;)
A better way to go would be to emulate the port in question. I.e. if it
is trying to directly access the serial port, translate this to read()
and write() and ioctl()'s on a serial device.
: Totally confused,
: Techs
: [techs@pioneer.unm.edu][Space and Planatary Image Facility]
From: techs@pioneer.unm.edu (Erik Fichtner)
Newsgroups: comp.os.linux
Subject: inb/outb babble.. was Re: Problem with inb and outb..
Date: 14 Jun 92 19:16:22 GMT
Organization: Space and Planetary Image Facility
In article <1992Jun14.102604.11229@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au
(Michael O'Reilly) writes:
>techs@pioneer.unm.edu (Erik Fichtner) writes:
>: Well, Here I am working on the dos emulator.... more things
>: What's wrong here??!
>
>User programs CAN'T do arbitrary I/O to ports. You have to go via the
>ioperm sys call to explicity allow it. In general you shouldn\'t need to
>go to the ports as linux can get very confused if you do. Allowing the
>dos emulator to do all the port I/O it wants is almost guarenteed to
>crash linux.. ;)
>
Heheh.. Yes, a friend and I realize that this will probably defeat the
purpose of Linux, but we're stubborn. I want it to run WWIV. that's
the only program I have any need of from DOS. also need Turbo C to keep
WWIV happy. these programs both requre heavy port io. anyway, this
is the end goal I'm working towards. for ports that really destroy Linux,
IE Keyboard and Video, i'll probably end up HAVING to write some device driver
for it, but for a lot of things, like a simple inb from the video display
asking what mode the display is in should be allowed.
My friends's goal is to hack the kernel to allow switching between graphics
consoles so that he can run X on one console and GeoWorks under the dos
emulator. ;-) It'll be a cool hack if it works. so will the port stuff,
i think.
anyway... i've gotten lots of mail about ioperm(). thanks to those who
sent info...
>A better way to go would be to emulate the port in question. I.e. if it
>is trying to directly access the serial port, translate this to read()
>and write() and ioctl()'s on a serial device.
>
Ugh. This is a good idea for devices you KNOW about. like the keyboard,
video, serial, parallel, and so forth. but what if the DOS emulator
wants to talk to... a Colorado Tape Drive, for instance. That's not
something that Linux even understands.... nor do I, or I'd write a kernel
patch... Since it's not being used, i see no fault in letting something
that understands it deal with it unrestricted.
>: Totally confused,
.....less confused now... much less...
--
Techs
[techs@pioneer.unm.edu][Space and Planatary Image Facility]
"What do ya mean I ain't kind? Just not *your* kind!" - Megadeth
Disclaimer - Any inaccuracies are caused by the phase of the moon.
From: jwaters@deepthought.unm.edu (Joe Waters)
Newsgroups: comp.os.linux
Subject: Re: inb/outb babble.. was Re: Problem with inb and outb..
Date: 15 Jun 92 22:49:04 GMT
Organization: The University of New Mexico, Albuquerque, NM
In-Reply-To: joel@wam.umd.edu's message of 15 Jun 92 12:55:04 GMT
In article <1992Jun15.125504.7083@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman)
writes:
>Heheh.. Yes, a friend and I realize that this will probably defeat the
>purpose of Linux, but we're stubborn. I want it to run WWIV. that's
>the only program I have any need of from DOS. also need Turbo C to keep
>WWIV happy. these programs both requre heavy port io. anyway, this
>is the end goal I'm working towards. for ports that really destroy Linux,
> If it's not too hard, I would suggest two compile-time options, one
> with direct port access by the vm86 process, and the other with
> emulation. Emulation is a MUCH better solution for many reasons. One
> that comes to mind is that more than one vm86 process can run at a
> time. The other, already stated, is that it won't compromise system
> integr{ty.
I (being Techs' friend) was planning something similar. Instead of
making it a compile-time option, it would be a runtime option such as issuing
the command "dosemu -P" which would put the emulator into a sort of protected
mode that traps most i/o port calls and emulates what it can. Of course,
emulation would be a better way to go; the main problem is that there are
0xFFF ports which DOS programs call any time they feel like it. There will
probably be three modes which the thing can operate in: 1) emulation-only of
whatever we can make emulatable, 2) full I/O access (which will essentially
turn Linux into a DOS box until you shut down the emulator with a reboot
command, at which point Linux will return to the land of the living (this
part already works), and 3) the "protected" mode, where the code emulates
everything which will blow up Linux (reading the keyboard directly, serial
ports (hopefully with lockfiles - I'll look at that in the next few days),
etc, while letting some non-dangerous I/O calls (stuff to the game port, for
example) through, and finally LOCKING COMPLETELY OUT some I/O calls (like stuff
that directly accesses DMA, the HD controller, etc)... This should make
just about everybody happy, and the full I/O access option will be "run at
your own risk"...
>My friends's goal is to hack the kernel to allow switching between graphics
>consoles so that he can run X on one console and GeoWorks under the dos
>emulator. ;-) It'll be a cool hack if it works. so will the port stuff,
>i think.
> CMU's Dos emulator has code for completely saving and restoring the
> state of the VGA card. You might want to look at it.
> -Joel
I know -- I've already taken a look at that code... Anything with
saving/reloading the entire VGA card when you switch VCs is a way off though --
we're going to get the simpler stuff working better first (like color for the
text mode which is going to require a major rewrite of the direct screen
access stuff)... Things are moving though.
Joe
--
/---------------------------+-------------------------------------------------\
| Joe Waters ("Falc") | "Most any problem can be solved with duct tape |
|jwaters@deepthought.unm.edu| and Froot Loops . . . or a good heavy club." |
\---------------------------+-------------------------------------------------/
From: techs@pioneer.unm.edu (Erik Fichtner)
Newsgroups: comp.os.linux
Subject: DOS Emulator (was Re: Problem with inb and outb.... Segmentation Fault?!??)
Keywords: inb outb broken doesn't_work.
Date: 19 Jun 92 20:23:36 GMT
Organization: Space and Planetary Image Facility
The Inb()/Outb() problems have been solved... thanks go out to
all those who replied.
The DOS emulator is coming along rather smoothly.
Direct to Screen writes work, although not always with the
correct attribute byte. HotDIR 2.1 works and displays in
color, no less.
A serial port handler is in the works... shouldn't take too
terribly long to finish.. once the serial port handler is
completed and bug free, then *TELIX* will work and we don't
need to diddle about with pcomm or kermit... ;-)
Currently Telix functions as a program but can't talk to
the serial ports... :-( I believe this is because
Linux already has control over them and it doesn't quite
understand why this rogue program is trying to touch them...
at least that's my theory. < grin> at any rate, direct port
access to and from the serial ports doesn't work, even
after they've been ioperm()'ed. s'alright... we
needed to make it use lock files for the ports anyway. < grin>
a keyboard hack in the kernel would be a nice idea.
what's needed is something that will feed a V86 task (but not
something else) *scancodes* instead of ASCII, *BUT* only
when that task is also running as the current vtcon.
sick kludge, but if we can get something like that we can make
Word Perfect run.
The Graphics Swapping kernel hack is still a loooong way away.
--
Techs
[techs@pioneer.unm.edu][Space and Planatary Image Facility]
"What do ya mean I ain't kind? Just not *your* kind!" - Megadeth
Disclaimer - Any inaccuracies are caused by the phase of the moon.
Newsgroups: comp.os.linux
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: DOS Emulator (was Re: Problem with inb and outb.... Segmentation Fault?!??)
Organization: Printer Products Eastman Kodak
X-Newsreader: Tin 1.1 PL3
Date: Sat, 20 Jun 1992 01:51:57 GMT
techs@pioneer.unm.edu (Erik Fichtner) writes:
...
>
>a keyboard hack in the kernel would be a nice idea.
>what's needed is something that will feed a V86 task (but not
>something else) *scancodes* instead of ASCII, *BUT* only
>when that task is also running as the current vtcon.
>sick kludge, but if we can get something like that we can make
>Word Perfect run.
you can get raw scancodes from a linux0.96 or higher kernel by using the
KD_RAW ioctl which i stuffed in for x11. here is a small demo program
to show how its done:
--cut--
#include < stdio.h>
#include < sys/types.h>
#include < sys/kd.h>
#include < termio.h>
/*
* test of the raw keyboard interface. must be run from a vtcon.
*
* in raw mode, the keyboard produces direct scancodes rather than
* translated characters. this demo eats ten chars then switches back
* to translated mode.
*
* todo: need to implement the get/set translation ioctls so can read
* the raw scancodes and map them to "fixed" chars, like is done in the
* kernel.
*/
void
showstate()
{
int i;
if (ioctl(0, KDGKBMODE, &i) < 0)
perror("KDGKBMODE");
else
printf("keyboard in %s state\n",
(i == K_RAW) ? "raw" : "translated");
}
void
dumpbuf(char buf[], int size)
{
int i;
for (i = 0; i < size; ++i)
printf("0x%02x ", buf[i] & 0xff);
printf("\n");
fflush(stdout);
}
test()
{
int i, n, c;
char buf[10];
struct termio old_tty, new_tty;
ioctl(0, TCGETA, &old_tty);
for (i = 0; i < sizeof(buf); ++i)
buf[i] = 0xff;
showstate();
if (ioctl(0, KDSKBMODE, K_RAW) < 0)
perror("KDSKBMODE raw");
showstate();
dumpbuf(buf, sizeof(buf));
printf("type some chars...\n");
new_tty = old_tty;
new_tty.c_iflag = (IGNPAR | IGNBRK) & (~PARMRK) & (~ISTRIP);
new_tty.c_oflag = 0;
new_tty.c_cflag = CREAD | CS8 | B9600;
new_tty.c_lflag = 0;
new_tty.c_cc[VTIME] = 0;
new_tty.c_cc[VMIN] = 1;
ioctl(0, TCSETA, &new_tty);
for (n = 0; n < sizeof(buf); )
{
i = read(0, buf + n, sizeof(buf) - n);
if (i == 0)
continue;
if (i < 0)
{
perror("read");
break;
}
n += i;
}
ioctl(0, TCSETA, &old_tty);
dumpbuf(buf, sizeof(buf));
if (ioctl(0, KDSKBMODE, K_XLATE) < 0)
perror("KDSKBMODE xlate");
showstate();
}
main(int ac, char **av)
{
if (ac == 2 && !strcmp(av[1], "off"))
ioctl(0, KDSKBMODE, K_XLATE);
else
test();
}
--cut--
...
>--
>Techs
>[techs@pioneer.unm.edu][Space and Planatary Image Facility]
>"What do ya mean I ain't kind? Just not *your* kind!" - Megadeth
>Disclaimer - Any inaccuracies are caused by the phase of the moon.
zorst
[obz@raster.Kodak.COM]
--
zorst (orest zborowski)
[obz@raster.Kodak.COM]