[SqNOS] driver framework (was: SqueakNOS boots under VirtualBox on Mac OS X 10.5)

[Jecel Assumpcao Jr]

Gerardo Richarte wrote on Fri, 29 May 2009 01:00:24 -0300:
> Merik Voswinkel wrote:
> > A question from our Morphle team about the name SqueakNOS. Jecel and I
> > are publishing papers about SiliconSqueak and the operating system we
> > run on top of it. It has (among many other innovations)  a new virtual
> > parallel device driver system.
> This is very interesting, where can I read more from this? or see it?
> screenshots, movies, anything!

The paper about the driver framework has not been written yet (much less
the actual code), but there are several sources of information that are
available. There was a thread about this on squeak-dev back in May 1998:

> http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-May/015997.html

Unfortunately, my message that started that thread is missing from the
archives. So I will add a copy of it to the end of this one.

A wish list for Squeak was discussed earlier this year and two items
were a rewrite of the event interface between the VM and the image and
the inclusion of the Announcements framework (created in VisualWorks and
ported to Dolphin Smalltalk and Squeak) as part of the official image. I
suggested that these two items could be merged and several people felt
this is a good idea, but not work has been done on this.

http://wiki.squeak.org/squeak/5734

An interesting aspect of SqueakNOS is that interrupts get translated
into semaphore signals. This allows some forked code to block in
different points on this semaphore, which gets us something more like
coroutines than traditional interrupts handlers (which always start in
the same point and so have no saved state). This is very similar to what
was developed for the Apertos operating system that I have mentioned
here before.

http://www.sonycsl.co.jp/project/Apertos/techpaper.html

I am talking about papers 8, 9, 10  and 12 (I haven't actually read 10
since it is in Japanese). For your convenience, I have translated paper
12 from Postscript to PDF:

http://www.merlintec.com/download/SCSL-TM-94-005.pdf

> > Would you mind if we would call that SqueakNOS 2.0, or is that name
> > reserved for the work that you and Luciano did?
> well, truly, I think it's not a good idea, unless it's really based on
> SqueakNOS, and unless you are going to contribute everything back to
> SqueakNOS right away. We'd really have to see it to decide, but until we
> do, please, don't call it SqueakNOS or anything similar.
> 
> On the other hand, if you implemented a new platform where SqueakNOS can
> run, it's just SqueakNOS, not 2.0, we commit it to the source
> repository, and that's it.

The code we are developing will be just plain SqueakNOS. I am very much
against forking except in extreme cases. In my discussion with Merik, I
mentioned that the current state of SqueakNOS has some limitations
equivalent to early Linux or even MS DOS 1.0. In those systems the
hardware configuration was hardwired into the software and you had to
recompile it (or wait for Microsoft to do it for you) before you could
access new hardware. Eventually Linux got its kernel modules and MS DOS
2.0 got its .sys files, so I said we need to get to at least that level
with SqueakNOS where some framework allows the PS/2 mouse to be replaced
with a USB one, for example.

So I used the term "SqueakNOS 2.0" to refer to a version at least as
modular as DOS 2.0 (not the most ambitious target for an OS developer,
right?).

> And then, yes, we are planning a SqueakNOS 2.0 already (and a 3.0 and a
> 404 too :)

Exactly - let us get our roadmaps in synch if possible.

Just to be clear: the discussion was about code to be added at the
Smalltalk level to SqueakNOS and not about any details of the lower
level platform. And I am also very interested in having SqueakNOS track
any changes in terms of event handling that might be developed for
"normal" Squeak.

-- Jecel

Here is the initial email in the i/o framework for Squeak thread:
=============
>From - Tue May 19 22:05:54 1998
Received: from jerry.cs.uiuc.edu (qmailr at jerry.cs.uiuc.edu [128.174.246.71])
        by hermes.lsi.usp.br (8.8.8/8.8.8) with SMTP id CAA25363
        for <jecel at lsi.usp.br>; Tue, 19 May 1998 02:19:02 -0300 (BSC)
Received: (qmail 27590 invoked by uid 95); 19 May 1998 05:18:39 -0000
Resent-Date: 19 May 1998 05:18:39 -0000
Resent-Cc: recipient list not shown: ;
Date: Tue, 19 May 1998 00:17:14 -0500 (CDT)
From: jecel at lsi.usp.br
Message-Id: <199805190517.AAA27596 at c.cs.uiuc.edu>
Subject: KeyUp events
Resent-Message-ID: <"Hw2QrC.A.goG.hYRY1"@jerry>
To: squeak at cs.uiuc.edu
Resent-From: squeak at cs.uiuc.edu
Reply-To: squeak at cs.uiuc.edu
X-Mailing-List: <squeak at cs.uiuc.edu> archive/latest/2072
X-Loop: squeak at cs.uiuc.edu
Precedence: list
Resent-Sender: squeak-request at cs.uiuc.edu
Status: RO
X-Mozilla-Status: 0001
Content-Length: 2357

I really haven't looked too deeply at this, but it seems
to me that it is not possible to detect keyUp events in
Squeak. That makes it impossible to write certain kinds
of games, a simple piano application or, in my case, a
chorded keyboard emulator.

To tell the truth, I haven't been very pleased with what
I have seen so far of the input architecture. I thought
you might find a design I came up with interesting (if
not, sorry for wasting bandwidth...).

My idea is to have a set of components connected in
a graph-like structure. The graph's edges can be either
"push" (where the origin sends a message like #mouseDown:
to the destination) or "pull" (where the destination sends
a message like #curentCursorX to the origin).

A pushInput/pullOutput component is a buffer, like the
well known keyboard type-ahead buffer. A pullInput/pushOutput
object could be called a "pump", and can be quite handy
in certain situations. A filter is normally a push/push
component, but could also be a pull/pull one. They are  
linked in a 2D graph, so an object can pull from several
sources or send to many destinations if the need arises.

Now this graph is dynamic, and can change in response
to hardware changes (pluging in that new USB joystick)
user preferences (invoking Alan Kay's character         
recognizer) or application needs (after a drag is      
initiated you want to keep track of the cursor).      

The application should be able to "dip into" this event
graph at the points which match its semantic needs 
the best. If it needs to insert text in a morph then   
it should poll the TextMux object for input. At this     
point it could be seeing cooked input from a multi-       
language keyboard system, the result of a fancy voice
recognition system or even the interpretation of some
touch tones over the phone line. On the other hand,   
the toy piano app I mentioned above would be driven          
by virtual keyboard scancodes. In the same way, a      
program that needs gestures could get them from
a filter on the mouse or from a VR glove, while a
paint program might prefer to see mouse events
directly (not really, but you get the idea).

Extending Squeak with remote "hands", MIDI,
future facial expression recognition from video
and so on will become ever more difficult unless
something like I suggested is implemented.

-- Jecel
=============