[rescue] Parallel ports [was Re: Slightly OT: ?Bad Cap Saga]
jorge234q at yahoo.com
Fri Aug 22 14:16:16 CDT 2008
--- On Fri, 8/22/08, der Mouse <mouse at Rodents-Montreal.ORG> wrote:
> >> Because that's output-only, not "the output one byte, input one
> >> byte, repeat" paradigm I'm actually using.
> > But you're controlling *relays*... (??)
> Oh, two different projects. The relay controller, yes, is
> I've done two others, each of which uses the send/read/send/read
> paradigm. One is the ROM reader I alluded to briefly upthread; the
> other is a cable pinout sensor (plug a cable in and the host driving it
> can sense which pins are connected to which other pins).
But, neither is going to suddenly become impractical if you have
10,000 traps vs. *1* trap. And, certainly the rest of the
system isn't going to cringe if you burn a few gazillion
CPU cycles trying to read 64Kbytes out of a PROM...
If you're trying to do something that needs its own processor,
then *give it* it's own processor! If you're trying to do
something that's just exploits the "convenience" of having a
processor to do the work (e.g., turn on your desk lamp each
morning based on whether or not your calendar(1) says you
have a meeting that day), then chances are it won't matter
how inefficient the code is.
I wrote a routine to crack a security device (essentially
a FSM with 8 bits of state and 8 inputs). It just hammered
away at the device building a state transition table from
each set of (current state, inputs) data. Each iteration
required a write to the device and a read from it. It
ran in user-land (because the OS was "closed"). The time
it took to run was less than the time it took to write the
> >>> and more *portable* and future-safe on the "host" (PC) side.
> >> As for the latter, there is no such thing.
> > Note that I didn't use the superlative in my description. Just MORE
> > future-safe.
> My misreading, then; I read "(more portable) and
> (future-safe)", rather than "more (portable and future-safe)".
> > Thinking this out can be a real win. E.g., like UN*X opting to treat
> > everything as files.
> ...except things that aren't. Network interfaces.
> Shared memory segments. ioctl(). sysctl().
Sure! There are exceptions to everything. Otherwise, there
would onoy be a need for *one* OS, one text editor, one PCB
layout tool, one geek port, etc. You try to come up with a
solotion that gives you 80% of the solution for 20% of the
work. The other 20% you either *ignore* or "spend disproportionately
more resources on"
> Also, a paradigm like that can be as constraining as any other. I once
> was hired to build glue code between an experimental encrypted
> distributed storage paradigm and the Unix filesystem paradigm.
> It took me six months.
More information about the rescue