Date: Tue, 24 Jun 1997 16:57:37 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: un_x@anchorage.net (Steve Howe) Cc: hackers@FreeBSD.ORG Subject: Re: BSD io Message-ID: <199706240727.QAA23323@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95q.970623215859.7612A-100000@aak.anchorage.net> from Steve Howe at "Jun 23, 97 10:21:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706240727.QAA23323>