Date: Mon, 23 Jun 1997 02:36:37 -0800 (AKDT) From: Steve Howe <un_x@anchorage.net> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-hackers <hackers@FreeBSD.ORG> Subject: Re: direct access Message-ID: <Pine.BSF.3.95q.970623002024.21409A-100000@aak.anchorage.net> In-Reply-To: <19970623100142.PK61527@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
"man io" - I/O privilege file
The special file /dev/io is a controlled security hole that allows a pro-
cess to gain I/O privileges (which are normally reserved for kernel-
internal code). Any process that holds a file descriptor on /dev/io open
will get its IOPL bits in the flag register set, thus allowing it to per-
form direct I/O operations. This can be useful in order to write user-
land programs that handle some hardware directly.
The entire access control is handled by the file access permissions of
/dev/io, so care should be taken in granting rights for this device.
Note that even read/only access will grant the full I/O privileges.
> > what's /dev/io all about?
> RTFM... Did you ever try ``man io'', to the least? Apparently not.
yes - but i didn't learn too much. can't say
i learned enough to do anything with it.
thanks though.
i searched through the maillist archives,
handbook, and faq, and didn't see
much on c-programming i/o basics.
i'm sure it doesn't take an einstein,
but of course, i'm basing that on my
limited knowledge. i've only been
programming since 1981, not 1945,
and i only know about 10 languages,
not 100, and i've only been hacking
FBSD for 2 years ... not 20.
> > for example, i need char i/o to the vga screen.
> No, you don't need it. You _think_ you need it. This makes your
> application totally unportable, and people will really hate you for
> this crap then. (You will even hate yourself two years later, believe
how do you know i don't need it? i have special needs with embedded
hardware FreeBSD doesn't support, and that i don't expect FreeBSD to
support, and i'm sure i'm not alone. and i don't have time to re-write
everything from the ground up right now. how do you know my timelines,
my priorities, or if i will even give it out for other people to use,
or if i will ever use it on non-pc based computers?
> portable back to a CP/M machine connected via Kermit emulating an ADM3a
> or VT52 terminal. If your terminal supports colors, you can also get
this is the 90's - i don't care about adm3a/vt52's.
i care about BSD's/Linux/POSIX and hardware i/o testing.
and i don't want to be 90 before i port some 'drivers'
to use for myself. and i don't want my trees of
development to split too far between my embedded
systems code and UN*X code. it will become too much
to maintain for now. for example, i read the slang lib
may be faster than ncurses... but i can't
find any docs on slang i/o. maybe there's
even faster alternatives?
> colors. You read the character back from a backup buffer curses
> maintains inside the program's address space.
i can't find any info on this backup buffer in ncurses.
i tried "apropos buf", "apropos back", ... i tried the
manpages on ncurses stuff, couldn't find anything.
i can find what a current pair color is.
and curses.h doesn't compile well with c++.
besides, from what i read, curses is out of date.
> > > > unsigned char * p = (unsigned char *)0x000b8000;
> > > You cannot directly access the physical address 0x000b8000.
> > is that an absolute? no peek-ing or poke-ing ... at all?
> inside the kernel address space), thus you always need a mapping. The
> kernel provides for mappings in the ``ISA IO memory hole'', but for
> anything else, you're responsible yourself.
so - i just match the virtual addresses to physical, by reading
this map, then i turn off some flag, and i can read ram ...
> > as far as ram goes, i like to watch whats going on
> > in physical ram to learn about systems.
> Impossible. On a typical 16 MB system, there are 4096 different
> physical pages of memory, which can be arbitrarily mapped into the
> virtual address spaces. So, your address 0x0000 of your program might
> be unmapped, address 0x1000 is mapped to physical address 0x133000,
> address 0x2000 is mapped to 0x57000, and so on. What would it give
> you to display physical memory? Nothing, i'd say.
what would it give us to explore anything? maybe unique
things exist that we all don't know about.
> > as far as drives go, file recovery - searching for deleted HD data,
> > which i desperately need,
> Impossible. That's not DOS, our filesystems aren't so simple as a
> lame FAT file system. Your data blocks that once belonged to a file
> might be scattered throughout the entireq partition, and once you've
> lost the block pointers, you stand no chance to reassemble them into
> one file (at least, not realistically).
no it's not, my files are small, i had few small messages on a
drive with keywords, and the drive hasn't been written to
since i disconnected it minutes after the deletion.
one of many uses for a block editor.
> > as far as ports go, the code i'd like to port, detects and
> > debugs certain devices.
> Leave this to kernel code. Write LKMs with device drivers.
i would like to use FreeBSD for embedded systems, and the kernel
doesn't support devices i need to use. maybe lkm's -are- what i need?
> soon make it obvious to you that all your questions were no-brainers
> from the beginning. Sorry for sounding harsh.
sorry for being a so stupid.
i do appreciate your knowledge.
> cheers, J"org
-------------------------------------------------
FingerPrint BA09868C 1B995204 58410FD3 A5E7B2DA
http://www.geocities.com/siliconvalley/way/7747
-------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970623002024.21409A-100000>