Re: Procfs support for non-Allegro lisps?
Frode Vatvedt Fjeld <[email protected]> Fri, 27 Aug 2004 14:24:00 +0200
| Newsgroups | gmane.lisp.movitz.devel |
|---|---|
| Message-ID | <[email protected]> |
James Crippen <[email protected]> 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