From owner-freebsd-hackers Tue Jun 24 00:34:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA00376 for hackers-outgoing; Tue, 24 Jun 1997 00:34:46 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA00371 for ; Tue, 24 Jun 1997 00:34:40 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA23323; Tue, 24 Jun 1997 16:57:38 +0930 (CST) From: Michael Smith Message-Id: <199706240727.QAA23323@genesis.atrad.adelaide.edu.au> Subject: Re: BSD io In-Reply-To: from Steve Howe at "Jun 23, 97 10:21:54 pm" To: un_x@anchorage.net (Steve Howe) Date: Tue, 24 Jun 1997 16:57:37 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Howe stands accused of saying: > > all i've done over the past 4 years is driver/OS level io > interfaces. and i have a ton of code i'd like to share > with BSD. i guess i wish i had a list of all possible > levels of i/o interfaces, with the pros, cons and limits > of each one, so i could intellingently choose at what > level i wanted to port code at. Only experience will give you a list like that; it'll always be coloured by personal opinion and circumstance, as will your perception of other peoples' lists. > i remember i asked once how to read in a character mode > from the keyboard, and while i was, as always, humbled > by people reaching out to help, i ended up with 3 responses > with pages of source code each, and no real clear cut answer. Well, at least part of the problem is in the questions that you ask. "read in a character mode from the keyboard" doesn't actually _mean_ anything, so it's impossible to give you a useful answer. How about you explain the situation you're trying to handle, rather than coming up with half a solution on your own and having us try to guess at it? > and for those of you that conquer some aspect of BSD, > like driver coding or kernel source debugging, for example, > why don't you try to document your efforts and share them > with the BSD community? We do. We sit here, as the ultimate interactive multimedia information source. Writing stuff down is hard, and the information gets stale faster than you care to imagine. > i don't know anything about demo crowds. > does anyone have any info on the slang lib? > or how it compares to ncurses? >From /usr/ports/devel/libslang/pkg/DESCR : S-Lang is a C programmer's library that includes routines for the rapid development of sophisticated, user friendly, multi-platform applications. The S-Lang library includes the following: Low level tty input routines for reading single characters at a time. Keymap routines for defining keys and manipulating multiple keymaps. High level screen management routines for manipulating both monochrome and color terminals. These routines are very efficient. Low level terminal-independent routines for manipulating the display of a terminal. Routines for reading single line input with line editing and recall capabilities. Searching functions: both ordinary searches and regular expression searches. An embedded stack-based language interpreter with a C-like syntax. A malloc debugging package > > Firstly; why on earth do you want to read back from the screen anyway? > > because i find it more efficient to scan a screen for data entries > / error checking than to write code that deals, in a global sense, > with each field entered by a cursor. Uh. As this message is rated PG, I'll reserve my judgement on that one. > > 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? > > for one thing, i need RAM tests run on regular intervals > to check system integrity. maybe you don't consider these > things important to your data aquisition systems, but i do, > and it is mandated in my contracts (hardware integrity checks). Oh, we consider RAM tests vital. You should look back through the BSD archives for all the discussions on RAM problems that have gone past. Unfortunately, RAM tests aren't worth spit in most cases. > > 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. > > since when does strings work on deleted files? > others say fsbs (whatever) will do the trick. fsdb. 'strings' looks for ascii strings in file objects. If you point it at a disk device, it will scan the disk (because it looks like a file), and print everything that looks like ascii off it. > > 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. > > they each store data in blocks, and consecutively if possible. Half a mark for "blocks" (you fail to make the distinction that UFS uses both blocks and frags), and no marks for "consecutively". -- ]] 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 [[