[movitz-devel] Re: Procfs support for non-Allegro lisps?

[Frode Vatvedt Fjeld]

James Crippen <jcrippen at gmail.com> writes:

> Is there any procfs support in the works out there for non-Allegro
> lisps? I note that the procfs-image.lisp file uses a few functions
> from a PROCFS package that I presume is Allegro-specific. What would
> it take to get this working in other Lisps? It seems like it should
> be some not-overly-complicated file accessing after some pid lookup,
> right?

It's actually not Allegro-specific, it is if anything FreeBSD (or just
*BSD, I don't know) specific. I think someone on #lisp made a minimal
effort of porting it to linux, but I think it wasn't 100% trivial, I
don't remember what came of it. Shouldn't be too difficult,
though. The code is in the infunix package that I uploaded at
http://www.cs.uit.no/~frodef/sw/ if you want to have a look. Note
however that to be actually useful, the procfs stuff requires some
sort of hacked bochs (or perhaps qemu can also be hacked) to be
useful. I've modified bochs to print out the locations of the emulated
address-space and the variables that hold the emulated CPU registers
etc. (and this info is read in when creating a bochs-image instance,
which is a specialized procfs-image) so as to get interactive probing
of the emulated system (and this is a _very_ nice debugging tool).

> Also, I'm working on implementing timers and RTC support. I intend
> to use this to implement some support for things like Unix's
> sleep(3) and alarm(2). That should fix the problems with things like
> the busy-wait loops in harddisk.lisp.

I suppose one very simple approach to the "wait for interrupt
response" problem would be to do e.g.

  (do-send-harddisk-request device ...)
  (setf (exception-handler (irq-exception-vector device))
    (lambda ()
       (do-acknowledge-response device ..)))

i.e. simply to install the continuation (as a lambda) as the interrupt
handler. The same can be done for the timers. This scheme of course
can't deal with multiple outstanding requests etc. but might be
appropriate for very simple (MoKA) architectures. Just a thought.

-- 
Frode Vatvedt Fjeld