Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jun 1997 22:21:54 -0800 (AKDT)
From:      Steve Howe <un_x@anchorage.net>
To:        freebsd-hackers <hackers@freebsd.org>
Subject:   BSD io
Message-ID:  <Pine.BSF.3.95q.970623215859.7612A-100000@aak.anchorage.net>

next in thread | raw e-mail | index | archive | help

> 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.

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.

i run across bits and pieces, but i am not sure
i have covered all my options.  an when i run
across new ones, they are heavily clouded
with personal opinions.

from lkm's, to dev/io, to kernel io, 
to various scripting languages.

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.

then, on my own i found out i could do:

#include <ncurses.h> and then use cbreak();
OR
#include <stdlib.h> and then use system("stty cbreak");

so i don't know what to think.

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?

> 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

i never said it was wonderful, it's just useful to me.
first, i'd like to know exactly how to write a device
driver.  ie, disconnect any existing driver, plug in
a new one, do port i/o, use the driver, disconnect
it, and restore the original.

i read info relating to other unices, but it's not valid with
BSD, many functions are appear to be different.

> would call "craptalks".  If you can raise some real examples then
> we can get specific.

i don't know anything about demo crowds.
does anyone have any info on the slang lib?
or how it compares to ncurses?

> 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.

> 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.

call it what you want.

> 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).

> 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.

you guys think you know it all, and got it all figured out,
yet i hardly see any documentation of all your knowledge,
where's your "write a BSD driver tutorial"?

> > 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.

since when does strings work on deleted files?
others say fsbs (whatever) will do the trick.

> 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.

> 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)

i'm available for $$$ too.
and i am a rocket scientist. (BSAE).

> just ignore you, and you'll understand we want to help 8)

i do - i hope you understand i do to.
-------------------------------------------------
 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.970623215859.7612A-100000>