[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [MirageOS-devel] console interface
I tried to find the reasoning behind the log functions in the module type CONSOLE (using the git history). Some facts: - Nowadays (since 15th October 2014, or Mirage-2.0.0) a CONSOLE is a FLOW (and thus has read/write/writev/close) - there is a log_s : t -> string -> unit io - and a log : t -> string -> unit From the documentation of log (which mirage-console-xen follows AFAIU, -unix and -solo5 implementations write the entire string): "writes as many characters of string that can be written in one write operation to the console." Both log and log_s append line breaks to the given string - that is convenient for hello world like applications and printf debugging. But there are several problems with log and log_s: They cannot fail (in contrast to write/writev which can return `Eof). Furthermore, if you emit ANSII escape codes to colour your output and use log, since it only attempts to write as many characters as can be written, the output console can be in a strange state. I don't know what the intended semantics of the following program should be: module Main (C: V1_LWT.CONSOLE) = struct let start c = C.log_s c "hello" >>= fun () -> C.close c >>= fun () -> C.log_s c "world" end (From the documentation of FLOW.close: flushes all pending writes and signals the remote endpoint that there will be no future writes.) I propose the following: - remove CONSOLE.log - rename CONSOLE.log_s to CONSOLE.log - document that CONSOLE.log_s may fail silently if the console device has been closed Searching through mirage-skeleton using grep(1) results in few unikernels where log is used -- all of which are inside the Lwt monad, and thus log_s can be used instead. Please let me know if I missed something. Expect a PR soon, hannes _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |