From owner-freebsd-hackers Mon Jun 23 23:53:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA28015 for hackers-outgoing; Mon, 23 Jun 1997 23:53:21 -0700 (PDT) Received: from aak.anchorage.net (ai-136.anchorage.net [207.14.72.136]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA28010 for ; Mon, 23 Jun 1997 23:53:17 -0700 (PDT) Received: from localhost (abc@localhost) by aak.anchorage.net (8.8.5/8.8.5) with SMTP id WAA07903 for ; Mon, 23 Jun 1997 22:41:45 -0800 (AKDT) X-Authentication-Warning: aak.anchorage.net: abc owned process doing -bs Date: Mon, 23 Jun 1997 22:41:44 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net cc: freebsd-hackers Subject: BSD io In-Reply-To: <33AEB401.446B9B3D@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I think you've asked the wrong questions then.. > you don't want to probe ports while the system is running i do, i'd like to set an "inert" flag or something so the kernel isn't bothered by these things. i'd like to be able to take control of the hardware without rebooting the system while some code does hardware diags. > boot from a floppy and have your diagnostic there that's not an option. > BSD will not run on a 186 no? you're kidding. > but a 386sx20 will run ports at 115000 without flow control. i'd say that's pushing it, if there's some truth, i'd bet you'd get errors on a long steady stream. > if you are wanting to use less than 386 machines you need to go > elsewhere. you don't say. > > i see a few generalizations about device drivers, > > but no solid instructions / rules for FreeBSD. > in /usr/share/examples/drivers > are two shell scripts that WRITE A DRIVER FOR YOU my directory is empty, what dist fills the drivers directory? > juat answer the questions then take the output > and fill in the bits you want to add. > > because i am dealing with unique hardware, a2d cards, parallel i/o > > cards, 8530's, that the kernel will know nothing about, and i need > > simple and effective ways of dealing with them. some people say > > UN*X is no good for embedded systems because drivers are such a > > hassle. maybe they are? i don't know. > no they are easy.. you want a driver. > Use the example driver programs > then your application rograms become SO SIMPLE. thanks - i look forward to finding them. > > > learn about what's going on, attach a debugger to the kernel and > > > look at both the source _and_ the data. > with 2 machines hooked together with a serial cable > and the right s/w loaded, > you can single step the 2md machine in the kernel > and examine each line of C as it's run, and look at all variables, > structures etc. > THAT is educational, as it takes into account all the mappings for you. why isn't there a tutorial on the kmem/gdb methods to help people out that want to learn more? things should take matters of days, not weeks. tutorials delayed, is learning denied. ------------------------------------------------- FingerPrint BA09868C 1B995204 58410FD3 A5E7B2DA http://www.geocities.com/siliconvalley/way/7747 -------------------------------------------------