.\"<-xtx-*> tbl changes.ms | troff -ms | lp -d stdout.FP palatino.ps 9.nr PS 9.vs 11.nr VS 11.nr dP 1.nr dV 1p.nr dT 4m.nr XT 4.TLSystem and Interface Changes to Inferno.AUC H Forsyth.brVita Nuova.brforsyth@vitanuova.com.br9 June 2003.SHOverview.LPThis paper describes some of the changes made to Infernointerfaces as they stood in the published Third Edition manuals,to form the current Fourth Edition of the system,and the broad effects on internal and external interfaces.Changes include: extensions to the Limbo language;new instructions in Dis and the virtual machine; extra contentin Dis object files; structure of the source tree; configuration of.CW emu ;replacement of the window system with changes to the client interface;commands renamed, replaced, and removed;revised support for network booting;9P2000 becomes the basis for Styx;a graphics model offering alpha-blended compositing and general pixel structure;and improvements to Tk..NH 1Limbo.LPExceptions and fixed point have been added to the Limbo language.They are described in more detail in separate notes by John Firth,shortly to be available on the Vita Nuova web site.CW www.vitanuova.com .Channels can now be buffered.A form of polymorphism is now available in Limbo..NH 2Exceptions.LPDiscussion of exceptions will be restricted here to implications for existing source code.The most obvious changes are that.CW Sys->rescue ,.CW Sys->rescued ,.CW Sys->unrescueand.CW Sys->raisehave vanished.Instead the exception handling is expressed using constructions in the Limbo language.Named exceptions can be declared and used (these are described in the note by Firth), andthey are declared as part of the type of functions that raise them.There is also a general `failure' exception that effectively subsumes the old.CW Sys->rescuescheme, including run-time errors such as `out of memory' that can happen in almost any function.Unlike named exceptions a `failure' exception can be raised or caught by any function,and its value is a string.The.CW raisestatement raises an exception.This is most obvious in commands that wish to produce an `exit status'.Instead of.P1sys->raise("fail:usage");.P2one must now write.P1raise "fail:usage";.P2(That is one of the more common source changes required to Third Edition Limbo commands,since that was the most common use of exceptions before.)A block can have an.CW exceptionhandler:.P1{ a := array[128] of byte; dosomething(a);} exception e {"out of memory:*" => sys->print("i need more space: %s\en", e);"fail:*" => sys->print("exit status: %s\en", e);"*" => sys->print("unexpected error: %s\en", e); raise; # propagate it}.P2If an exception is raised during the execution of the block (including functions it calls),execution of the block is abandoned, and control transfers to the appropriate exception handler(which is outside the block).Because the compiler and run-time system know the scope of the exception,values such as.CW aabove are correctly reclaimed on exit from the faulty block.Unhandled failures are propagated to callers; unhandled named exceptions (currently) become failures..LPA process group can cause unhandled exceptions in any process in the group either topropagate to all members of the group, or to be propagated to the process group leaderafter destroying the other processes in the group.This makes it easier to program recovery from exceptions within a group of concurrent processes.For instance, if a process is expected to send to another on a channel, but fails unexpectedly instead(eg, because memory was exhausted),instead of leaving the intended recipient blocked on a receive operation, it can be sentan exception to notify it of the failure of the other process, allowing it to take appropriate recovery action.(This could sometimes be programmed using the.CW waitfile of.I prog (3),but not always.).LPException handling is intended for recovering from disaster.We still think it is better Limbo styleto use tuples, channels and processes to make ordinary error handling explicit.The few attempts to use failure exceptions to achieve `pretty' but peculiar control flow have had exactly the usualeffect of making the code hard to follow and error-prone..NH 2Channels.LPBuffered channels have been added:.P1c := chan [N] of int;.P2where.I Nis an integer value,creates a channel that will allow up to.I Ninteger values to be sent to it without an intervening receive without blocking the sender.If.I Nis zero, the channel is unbuffered, equivalent to plain.CW "chan of int" ,and synchronises sender and receiver as before..LPThe restriction that a given channel value could not be sent to or received from in two.CW altstatements simultaneously has been removed..NH 2Polymorphism.LPJohn Firth has implemented a form of parametric polymorphism in Limbo.It too will be described in a separate note.Currently we are still fussing over aspects of the constraint syntaxand some other implications of the most general form, and since some aspects aretherefore subject to change, including syntax, we have not yet published the details.We think it is possible to use the following subset without having to change the code later:.IP 1.Function declarations can be parametrised by one or more type variables:For example:.RS.P1reverse[T](l: list of T): list of T{ rl: list of T; for(; l != nil; l = tl l) rl = hd l :: rl; return rl;}.P2Such a function can then be invoked on any compatible set of values.The function invocation does not specify the type (the compiler does type unification on the parameters).Thus the above can be used as:.P1l1: list of string;l2: list of ref Item;l3: list of list of string;l1 = reverse(l1);l2 = reverse(l2);l3 = reverse(l3);.P2.RE.IP 2.ADTs can also be parametrised:.P1Tree: adt[T] { v: T; l, r: cyclic ref Tree[T];};.P2allowing declaration of.CW "Tree[ref Item]"and.CW "Tree[string]"for instance..IP 3.Values of the parametrised type can only be declared, assigned, passed as parameters, returned,or sent down channels.The only types that can be used as actual parameter types are reference types (ie,.CW ref " ADT,".CW array ,.CW chan ,.CW listand.CW module ),and.CW string(which is a value type but is implemented using a reference).At some point we shall allow a function such as.CW reverseabove to be invoked with any compatible type (not just reference types) butthat requires changes to Dis and the virtual machine not yet made..LPThe formal type parameters can be further constrained by listing a setof operations that they must have (which currently implies the actual parametersmust be ADT types with compatible operations).We are not completely happy with the current constraint syntax, and some otheraspects of the scheme, and so thatbe described here later once we have settled it..NH 1Dis and virtual machine.LPTo make the Limbo changes and extensions some new operators were added tothe virtual machine.(We also added a.CW caseloperator to allow.CW casestatements to work on.CW bigvalues.)Modules that have exception handlers also have a (new) exception table,added to the Dis object format.Furthermore, we moved the import table used by the.CW loadoperator out of the Dis data space into the object format(which also makes it available for inspection by.CW wm/rtamongst others)..LPThere is now an internal interface to set conditions underwhich modules must be signed to be loaded, and to check a signature on a module.Appropriate stubs are defined when module signing is not configured; if.I sign (3)is configured, however, it replaces them by ones that enforce its signing policy..NH 1Window manager.LPThe window manager.I wm (1)has been reimplemented by Roger Peppe.It now multiplexes pointer and keyboard input to applications,and manages windows on the display..I Tk (2)no longer manages windows from inside the kernel.In some ways the structure is closer to that of.I mux (1)and more specifically the design described in Rob Pike's paper ``A Concurrent Window System''.It is possible to import and export window system environments between hosts..LPThis is one of the bigger causes of source file changes, although many of themcan be done by global substitutions (eg, using.I acme (1)).Appendix A gives details..CW Wmlibis no longer the application's interface to the window system.Instead that is done through a new.CW Tkclientmodule; see.I tkclient (2).(It uses a different.CW Wmlibas an auxiliary module,and also uses a new.CW Titlebarmodule to allow the look of the window decoration to be changed more easily).An application acquires a window by a call to.CW Tkclient->toplevel ;starts pointer or keyboard input if desired by calling.CW Tkclient->startinput ;and puts the window on screen (after sending it Tk configuration commands)using.CW Tkclient->onscreen .Nothing appears on screen until that is called (which amongst other things avoids the resizing on start up that afflictedthe original scheme)..CW Onscreengives it a connection to the window manager for pointer, keyboard and control input,with a separate channel for each.When it receives data from any of the channels(typically using.CW alt )it must pass it to Tk using calls to appropriate.CW Tkclientfunctions..LPThe toolbar used by the old.I wmis now provided by a separate program.CW wm/toolbar(see.I toolbar (1)),and it is.CW toolbarthat interprets the.CW /lib/wmsetupfile..CW Wminvokes.CW wm/toolbarby default so most users will see no difference, but it does make it easier to develop alternative interfaces.More visible is that.CW wm/logonis now a.I clientof the window manager, and must be invoked as follows:.P1wm/wm wm/logon.P2.LPApplications need not even use.I tk (2).There is an interface for.CW draw -onlyclients,.I wmclient (2)..NH 1Inferno source tree.LPThe structure of the Inferno source tree has changed in the following ways..NH 2Library source.LPThe.CW imageand.CW memimagedirectories have gone, replaced by.CW libdrawand.CW libmemdraw .The directories in the Inferno root that contain the source for librariesnowalways have names starting `\f5lib\f1':.CW libcrypt ,.CW libinterp ,.CW libkeyring ,.CW libmath ,etc..NH 2Emu source.LPThe.CW emudirectory now contains a subdirectory structure similar to the.CW oskernels, and uses a similar configuration file (parts list) to say what goes ina given instance of.CW emu .This allows platform-dependent selection of drivers, libraries and even.CW #/(ie,.I root (3))contents to be done easily..LPThe top directory,.CW /emu ,contains:.CW mkfilethat simply moves to the platform configured by.CW /mkconfig ,allowing builds in the Inferno root as before;a subdirectory.CW portcontaining portable code (including some code shared by several platforms, such as.CW devfs-posix.c );and a subdirectory for each hosting platform, distinguished by an upper-case initial letter.Current platforms include.CW FreeBSD ,.CW Irix ,.CW Linux ,.CW Nt(for all Windows platforms after 95),.CW Plan9 ,.CW Solaris ,and several others..NH 2Emu configuration.LPEach platform-specific directory contains a configuration file with thesame structure and indeed similar contents to the ones used for the native kernel.The default configuration file is called.CW emu .Another can be chosen, again in a similar way to the native kernel, by using.P1mk 'CONF=\fIcfile\fP'.P2where.I cfileis the name of the configuration file.The name of the resulting executable file contains the configuration file name but depends on the platform:it is \fIcfile\fP\f5.exe\fP on Windows, \f5o.\fP\fIcfile\fP on Unix systems, and \f58.\fP\fIcfile\fP on 386 Plan 9 systems.The configuration file format and contents is documented for all types of kernels by.I conf (10.6)..NH 2Tk source.LPThe Tk implementation in.CW libtkhas been made more modular.It allows a significantly different `style' to be implemented,and although that is by no means trivial to do, there is at least an interface to do it.We hope to change various aspects of the standard style further, but that has not yet been done..NH 1Commands and modules.LPThere are new commands and library modules, others have become obsolete and been removed,and a few existing ones have been given new names (typically when ones with similar function have beencollected together).The biggest change has been to.I wm (1),which retains the same name but slightly different invocation and completely differentimplementation,as discussed above.Here I shall simply note the bigger changes, rather than discuss new functionality..NH 2Renamed commands.LPAs part of a mild reorganisation of the.CW /appland.CW /distrees, we have moved commands out of.CW /dis/libso that it now contains only library modules except for a few commands leftthere temporarily for compatibility.Commands themselves have sometimes been shuffled to subdirectories,often copying seemingly better structure from Plan 9,so that authentication commands are.CW auth/ ...,naming service commands are.CW ndb/ ...,andIP-specific commands are.CW ip/ "... .".LPOne noticeable change is that.CW lib/csis now.CW ndb/cs .More dramatically, the command.CW lib/srv(ie,.I srv (8))has been replaced by.I sh (1)scripts, all described by.I svc (8),that contain appropriate calls to.I listen (1)after setting up any locally-desired environment..LPOther commands have also moved:.IP •.CW lib/plumberis now simply.CW plumber.IP •.CW lib/bootpand.CW lib/tfptdhave become.CW ip/bootpdand.CW ip/tftpd ,documented in.I bootpd (8).IP •.CW lib/virgildhas become.CW ip/virgild(see.I virgild (8)).IP •.CW lib/chatsrv ,.CW lib/rdbgsrvand.CW cpuslavehave moved to.CW auxi(ie,.CW /dis/auxiand.CW /appl/cmd/auxi).IP •.CW csqueryhas become.CW ndb/csquery.NH 2New or newly-documented commands.IP •an authentication server (signer) can use.I keyfs (4)Lines 1–500 of 2053. Load more
.\"<-xtx-*> tbl changes.ms | troff -ms | lp -d stdout .FP palatino .ps 9 .nr PS 9 .vs 11 .nr VS 11 .nr dP 1 .nr dV 1p .nr dT 4m .nr XT 4 .TL System and Interface Changes to Inferno .AU C H Forsyth .br Vita Nuova .br forsyth@vitanuova.com .br 9 June 2003 .SH Overview .LP This paper describes some of the changes made to Inferno interfaces as they stood in the published Third Edition manuals, to form the current Fourth Edition of the system, and the broad effects on internal and external interfaces. Changes include: extensions to the Limbo language; new instructions in Dis and the virtual machine; extra content in Dis object files; structure of the source tree; configuration of .CW emu ; replacement of the window system with changes to the client interface; commands renamed, replaced, and removed; revised support for network booting; 9P2000 becomes the basis for Styx; a graphics model offering alpha-blended compositing and general pixel structure; and improvements to Tk. .NH 1 Limbo .LP Exceptions and fixed point have been added to the Limbo language. They are described in more detail in separate notes by John Firth, shortly to be available on the Vita Nuova web site .CW www.vitanuova.com . Channels can now be buffered. A form of polymorphism is now available in Limbo. .NH 2 Exceptions .LP Discussion of exceptions will be restricted here to implications for existing source code. The most obvious changes are that .CW Sys->rescue , .CW Sys->rescued , .CW Sys->unrescue and .CW Sys->raise have vanished. Instead the exception handling is expressed using constructions in the Limbo language. Named exceptions can be declared and used (these are described in the note by Firth), and they are declared as part of the type of functions that raise them. There is also a general `failure' exception that effectively subsumes the old .CW Sys->rescue scheme, including run-time errors such as `out of memory' that can happen in almost any function. Unlike named exceptions a `failure' exception can be raised or caught by any function, and its value is a string. The .CW raise statement raises an exception. This is most obvious in commands that wish to produce an `exit status'. Instead of .P1 sys->raise("fail:usage"); .P2 one must now write .P1 raise "fail:usage"; .P2 (That is one of the more common source changes required to Third Edition Limbo commands, since that was the most common use of exceptions before.) A block can have an .CW exception handler: .P1 { a := array[128] of byte; dosomething(a); } exception e { "out of memory:*" => sys->print("i need more space: %s\en", e); "fail:*" => sys->print("exit status: %s\en", e); "*" => sys->print("unexpected error: %s\en", e); raise; # propagate it } .P2 If an exception is raised during the execution of the block (including functions it calls), execution of the block is abandoned, and control transfers to the appropriate exception handler (which is outside the block). Because the compiler and run-time system know the scope of the exception, values such as .CW a above are correctly reclaimed on exit from the faulty block. Unhandled failures are propagated to callers; unhandled named exceptions (currently) become failures. .LP A process group can cause unhandled exceptions in any process in the group either to propagate to all members of the group, or to be propagated to the process group leader after destroying the other processes in the group. This makes it easier to program recovery from exceptions within a group of concurrent processes. For instance, if a process is expected to send to another on a channel, but fails unexpectedly instead (eg, because memory was exhausted), instead of leaving the intended recipient blocked on a receive operation, it can be sent an exception to notify it of the failure of the other process, allowing it to take appropriate recovery action. (This could sometimes be programmed using the .CW wait file of .I prog (3), but not always.) .LP Exception handling is intended for recovering from disaster. We still think it is better Limbo style to use tuples, channels and processes to make ordinary error handling explicit. The few attempts to use failure exceptions to achieve `pretty' but peculiar control flow have had exactly the usual effect of making the code hard to follow and error-prone. .NH 2 Channels .LP Buffered channels have been added: .P1 c := chan [N] of int; .P2 where .I N is an integer value, creates a channel that will allow up to .I N integer values to be sent to it without an intervening receive without blocking the sender. If .I N is zero, the channel is unbuffered, equivalent to plain .CW "chan of int" , and synchronises sender and receiver as before. .LP The restriction that a given channel value could not be sent to or received from in two .CW alt statements simultaneously has been removed. .NH 2 Polymorphism .LP John Firth has implemented a form of parametric polymorphism in Limbo. It too will be described in a separate note. Currently we are still fussing over aspects of the constraint syntax and some other implications of the most general form, and since some aspects are therefore subject to change, including syntax, we have not yet published the details. We think it is possible to use the following subset without having to change the code later: .IP 1. Function declarations can be parametrised by one or more type variables: For example: .RS .P1 reverse[T](l: list of T): list of T { rl: list of T; for(; l != nil; l = tl l) rl = hd l :: rl; return rl; } .P2 Such a function can then be invoked on any compatible set of values. The function invocation does not specify the type (the compiler does type unification on the parameters). Thus the above can be used as: .P1 l1: list of string; l2: list of ref Item; l3: list of list of string; l1 = reverse(l1); l2 = reverse(l2); l3 = reverse(l3); .P2 .RE .IP 2. ADTs can also be parametrised: .P1 Tree: adt[T] { v: T; l, r: cyclic ref Tree[T]; }; .P2 allowing declaration of .CW "Tree[ref Item]" and .CW "Tree[string]" for instance. .IP 3. Values of the parametrised type can only be declared, assigned, passed as parameters, returned, or sent down channels. The only types that can be used as actual parameter types are reference types (ie, .CW ref " ADT," .CW array , .CW chan , .CW list and .CW module ), and .CW string (which is a value type but is implemented using a reference). At some point we shall allow a function such as .CW reverse above to be invoked with any compatible type (not just reference types) but that requires changes to Dis and the virtual machine not yet made. .LP The formal type parameters can be further constrained by listing a set of operations that they must have (which currently implies the actual parameters must be ADT types with compatible operations). We are not completely happy with the current constraint syntax, and some other aspects of the scheme, and so that be described here later once we have settled it. .NH 1 Dis and virtual machine .LP To make the Limbo changes and extensions some new operators were added to the virtual machine. (We also added a .CW casel operator to allow .CW case statements to work on .CW big values.) Modules that have exception handlers also have a (new) exception table, added to the Dis object format. Furthermore, we moved the import table used by the .CW load operator out of the Dis data space into the object format (which also makes it available for inspection by .CW wm/rt amongst others). .LP There is now an internal interface to set conditions under which modules must be signed to be loaded, and to check a signature on a module. Appropriate stubs are defined when module signing is not configured; if .I sign (3) is configured, however, it replaces them by ones that enforce its signing policy. .NH 1 Window manager .LP The window manager .I wm (1) has been reimplemented by Roger Peppe. It now multiplexes pointer and keyboard input to applications, and manages windows on the display. .I Tk (2) no longer manages windows from inside the kernel. In some ways the structure is closer to that of .I mux (1) and more specifically the design described in Rob Pike's paper ``A Concurrent Window System''. It is possible to import and export window system environments between hosts. .LP This is one of the bigger causes of source file changes, although many of them can be done by global substitutions (eg, using .I acme (1)). Appendix A gives details. .CW Wmlib is no longer the application's interface to the window system. Instead that is done through a new .CW Tkclient module; see .I tkclient (2). (It uses a different .CW Wmlib as an auxiliary module, and also uses a new .CW Titlebar module to allow the look of the window decoration to be changed more easily). An application acquires a window by a call to .CW Tkclient->toplevel ; starts pointer or keyboard input if desired by calling .CW Tkclient->startinput ; and puts the window on screen (after sending it Tk configuration commands) using .CW Tkclient->onscreen . Nothing appears on screen until that is called (which amongst other things avoids the resizing on start up that afflicted the original scheme). .CW Onscreen gives it a connection to the window manager for pointer, keyboard and control input, with a separate channel for each. When it receives data from any of the channels (typically using .CW alt ) it must pass it to Tk using calls to appropriate .CW Tkclient functions. .LP The toolbar used by the old .I wm is now provided by a separate program .CW wm/toolbar (see .I toolbar (1)), and it is .CW toolbar that interprets the .CW /lib/wmsetup file. .CW Wm invokes .CW wm/toolbar by default so most users will see no difference, but it does make it easier to develop alternative interfaces. More visible is that .CW wm/logon is now a .I client of the window manager, and must be invoked as follows: .P1 wm/wm wm/logon .P2 .LP Applications need not even use .I tk (2). There is an interface for .CW draw -only clients, .I wmclient (2). .NH 1 Inferno source tree .LP The structure of the Inferno source tree has changed in the following ways. .NH 2 Library source .LP The .CW image and .CW memimage directories have gone, replaced by .CW libdraw and .CW libmemdraw . The directories in the Inferno root that contain the source for libraries now always have names starting `\f5lib\f1': .CW libcrypt , .CW libinterp , .CW libkeyring , .CW libmath , etc. .NH 2 Emu source .LP The .CW emu directory now contains a subdirectory structure similar to the .CW os kernels, and uses a similar configuration file (parts list) to say what goes in a given instance of .CW emu . This allows platform-dependent selection of drivers, libraries and even .CW #/ (ie, .I root (3)) contents to be done easily. .LP The top directory, .CW /emu , contains: .CW mkfile that simply moves to the platform configured by .CW /mkconfig , allowing builds in the Inferno root as before; a subdirectory .CW port containing portable code (including some code shared by several platforms, such as .CW devfs-posix.c ); and a subdirectory for each hosting platform, distinguished by an upper-case initial letter. Current platforms include .CW FreeBSD , .CW Irix , .CW Linux , .CW Nt (for all Windows platforms after 95), .CW Plan9 , .CW Solaris , and several others. .NH 2 Emu configuration .LP Each platform-specific directory contains a configuration file with the same structure and indeed similar contents to the ones used for the native kernel. The default configuration file is called .CW emu . Another can be chosen, again in a similar way to the native kernel, by using .P1 mk 'CONF=\fIcfile\fP' .P2 where .I cfile is the name of the configuration file. The name of the resulting executable file contains the configuration file name but depends on the platform: it is \fIcfile\fP\f5.exe\fP on Windows, \f5o.\fP\fIcfile\fP on Unix systems, and \f58.\fP\fIcfile\fP on 386 Plan 9 systems. The configuration file format and contents is documented for all types of kernels by .I conf (10.6). .NH 2 Tk source .LP The Tk implementation in .CW libtk has been made more modular. It allows a significantly different `style' to be implemented, and although that is by no means trivial to do, there is at least an interface to do it. We hope to change various aspects of the standard style further, but that has not yet been done. .NH 1 Commands and modules .LP There are new commands and library modules, others have become obsolete and been removed, and a few existing ones have been given new names (typically when ones with similar function have been collected together). The biggest change has been to .I wm (1), which retains the same name but slightly different invocation and completely different implementation, as discussed above. Here I shall simply note the bigger changes, rather than discuss new functionality. .NH 2 Renamed commands .LP As part of a mild reorganisation of the .CW /appl and .CW /dis trees, we have moved commands out of .CW /dis/lib so that it now contains only library modules except for a few commands left there temporarily for compatibility. Commands themselves have sometimes been shuffled to subdirectories, often copying seemingly better structure from Plan 9, so that authentication commands are .CW auth/ ..., naming service commands are .CW ndb/ ..., and IP-specific commands are .CW ip/ "... ." .LP One noticeable change is that .CW lib/cs is now .CW ndb/cs . More dramatically, the command .CW lib/srv (ie, .I srv (8)) has been replaced by .I sh (1) scripts, all described by .I svc (8), that contain appropriate calls to .I listen (1) after setting up any locally-desired environment. .LP Other commands have also moved: .IP • .CW lib/plumber is now simply .CW plumber .IP • .CW lib/bootp and .CW lib/tfptd have become .CW ip/bootpd and .CW ip/tftpd , documented in .I bootpd (8) .IP • .CW lib/virgild has become .CW ip/virgild (see .I virgild (8)) .IP • .CW lib/chatsrv , .CW lib/rdbgsrv and .CW cpuslave have moved to .CW auxi (ie, .CW /dis/auxi and .CW /appl/cmd/auxi) .IP • .CW csquery has become .CW ndb/csquery .NH 2 New or newly-documented commands .IP • an authentication server (signer) can use .I keyfs (4)