Date: Mon, 23 Jun 1997 21:27:39 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: un_x@anchorage.net (Steve Howe) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG Subject: Re: direct access Message-ID: <199706231157.VAA18802@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95q.970623002024.21409A-100000@aak.anchorage.net> from Steve Howe at "Jun 23, 97 02:36:37 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Howe stands accused of saying: > > "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. What more do you need to know? Oh, you mean you haven't read the documentation for the '386? ... yet you claim to want to do low-level hardware stuff, so I presume you must know _something_ about reading datasheets. If you look a little further, you will find in <machine/cpufunc.h> the in* and out* macros familiar to most intel C programmers. The IOPL bit is copiously documented in the Intel literature; if you don't have an x86 processor databook, have a prowl around www.x86.org; they have lots of useful stuff. > i searched through the maillist archives, > handbook, and faq, and didn't see > much on c-programming i/o basics. What is there to know? Seriously, registers is registers. It's assumed that if you're going to work on that sort of thing that you'll already have some experience. > 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. No, you're not. (See my .sig before you write me off as a snob; I've been doing embedded systems with FreeBSD for the last ~3 years.) However, as we are trying to point out, you have the wrong attitude, and you need to _stop_ thinking like you are, and embrace a whole new paradigm. You _cannot_ apply your current modes of thought to working with FreeBSD; the result will be a lot of wasted time and a non-functional product. Please believe me when I say that the comments that have been made are not intended to discourage you, or deprecate your general self-worth; what's intended is that you should forget everything you may have learnt about how to write embedded software for DOS (what I used to do too) and learn how to do it with a unixlike system. I for one would be more than happy to talk to you about how to do what you're talking about, but so far all I've heard you talk about is some wonderful "visual everything editor", and a lot of what the demo crowd would call "craptalks". If you can raise some real examples then we can get specific. > 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? We don't. But several centuries worth of collected *nix programming experience is trying very hard to teach you the first basic lesson of open systems programming; _generalise_. Don't be specific where you can be general. Embrace portability because it brings you opportunity for rapid code and knowledge reuse; far more than any language technology ever will. I also know that writing a driver to fit inside an established I/O framework is about 1/10th the work of writing a complete standalone I/O stack and making it work alongside an existing one. > 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? Speed is irrelevant here; ncurses isn't "slow"; you are seeing the fundamental difference between a cursor-addressible serial-stream display and a memory-mapped screen, and failing to decouple your thinking from the ordering of output on the screen. If you have a specialised requirement for talking to the framebuffer, and you can't achieve what you want using a portable solution, then take the advice you've been given and memory-map the console device into your process. If this is all double-talk, come back to us with an example and some rationale for your requirement so we can understand it and for sure someone will be able to help you. > > 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. Firstly; why on earth do you want to read back from the screen anyway? This is a totally losing idea in almost any circumstance; it's the sort of thing that beginner assembly programmers do because they've run out of registers. Then let's just observe that it's possible for other programs to write to the screen at the same time that you are... > 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. Not as such. The BSD curses library is _older_, yes, but also more compact. ncurses is newer, more featureful, but bloated. > > > > > 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 ... No. As a user process, the memory pages that are mapped to your address space only contain what you put into them. You can't read other processes' pages, or the pages used by the operating system. As far as your program is concerned, it has the machine all to itself; the significant point to note here is that it has a _virtual_ machine to itself, and this virtual machine has no registers, no Q00l memory locations, nothing. Joerg talked about the "ISA hole"; let's clarify a little. The kernel is, in most cases, very much like another user program; the memory addresses referenced by the code are virtual addresses, mapped to physical addresses by the same basic mechanism used for user processes. The kernel has extra privileges which allow it to modify these mappings, and to determine and arrange mappings to suit its needs. One of these mappings arranges pages so that kernel virtual addresses in the range 0xa0000-0xfffff refer to physical addresses 0xa0000-0xfffff, in order to make life slightly easier for ISA drivers. It doesn't apply to user processes, which have their own mappings. > > 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. I can't actually make any sense out of this at all. Are you saying that you can't read source code? Or that you don't know how to use (or learn to use) a source-level debugger? or do you have some deep spiritual connection with the random movement of data in your system? There's literally no point whatsover in staring at random pieces of system memory;interpreting what you see is much easier when you have the source code sitting in front of you. > > 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. A block editor _will_not_help_you_ for this, other than to perhaps recover some of the data from the files, and if the files are in text form, 'strings' will do the job just as well. ufs filesystems don't work _anything_ like the FAT filesystems. Don't make the mistake of thinking that they have anything at all in common. > 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? An LKM is just a slab of code that gets loaded into the kernel. You can write device drivers; they're not rocket science. If you feel that it's too hard, you can pay someone else to do it; several of us are quite available if there's money in the deal 8) > sorry for being a so stupid. It's not your being stupid that's vexing, it's the effort swinging the mallet to drive the new information between your ears. Consider whether we are doing this for fun, or whether it wouldn't be easier to just ignore you, and you'll understand we want to help 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706231157.VAA18802>