Skip site navigation (1)Skip section navigation (2)
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>