--> ap/xxxxx

* __

Artistic OS: (2007.07.06:1)


1) The manual/data sheets - the new book

2) The kernel - an intervention into the existent

3) The platform - from scrying http://scrying.org to alice

Notes here:

1) cpu/scrying

2) promiscuOS

3) wonderland - interpreter across all 3

The project is readily broken down as to the three layered sub-project elements classified as to CPU, promiscuous operating system and wonderland language coding environment. Each sub-project builds and informs the next project, ascending a (Babel) tower of abstractions which is itself a strong part of our thematic. The first step is proposed as a summary of contemporary research which maps these domains, including our own previous work. This stage can well be defined as the (public) specification of our artistic computing platform, and can equally be viewed as both a practical and a literary endeavour. We propose the conception of industry-inspired data sheets and specifications as fictions. Such literature, a blend of the practical and theoretical, will be published in book form making use of previous POD (print on demand) experience. This first stage will build heavily on our paper Instruction Sets, delivered at the Interface and Society conference in Oslo last year.

With a specification in place, the three identified elements of the artistic computing platform will be examined and actively constructed, tested and distributed (online). Each element, though building and dependent on others, can be viewed as being occupied with a specific set of concerns as follows:

The CPU is concerned with the black-boxing of technology and a notion of a hidden interior, technology as an interiority. We are interested in the idea of open hardware, and equally in a mapping of such interiority into the world as a philosophical question concerned with rationalism. The project here is concerned with a certain impossibility of exposure. Within a climate of intense (intellectual) property rights management which relies on locking the so-called user out of access to hardware the political concerns here are also important. These will be well mapped out through the documented construction in soft hardware of a functioning Central Processing Unit. The history of computing hardware will be examined in elaborating our artistic platform. Equally there is a relationship to alternative artistic hardware such as Marcel Duchamp's Large Glass and other such bachelor machines. We have technical experience in the coding of FPGAs (Field Programmable Gate Arrays) which will be used to create this speculative, highly reconfigurable hardware.

The promiscuous operating system presents the next level in our model of abstraction proceeding from open hardware to open software. Further interrogating the political concerns of a denial of access to materiality, a politics which can easily be extrapolated from the realm of computation, such a locking-out is equally mimed by software. Users and software are heavily segregated in a universal operating system design which is haunted by the specter of the viral and thus denies the potential of active, shared and networked playful environments. Particular economies are very much present within this model of closed systems and a concern for the politics of control is essential here. This sub-project is concerned with the elaboration, in software, of an active networked operating system which exposes and interrogates control. This OS is concerned with non-functional artistic generation at socially-implied levels of code and production, favouring promiscuous, leaky code and data over security and division by function or task. The highly technical nature of some of the research here means that collaboration on a practical level is essential. This subproject will be launched as a fully-fledged open source software project to highlight the issues at stake here.

The final subproject, the wonderland environment, is the most playful and perhaps loosely specified part of the artistic computing platform. The wonderland environment runs on the OS component and is primarily textual, allowing for language-based manipulation and play with networked instances of highly mobile code and data. The now active, artistic computing system embeds further social systems. The development of a relational language of description and process is implied as well as the question of a meeting between software and fiction; software above all as a means of representation rather than a tool or medium. Again, we are concerned with defining a new artistic practice which is concerned with both science and literature. The working title of a wonderland environment hints at the rich concerns here.

[promiscuOS + CPU work] as: (2006.12.08:2 research#117 promiscuOS_notes#6 OS#1)

an active highly practical investigation of how the CPU and Operating System, those twin (Babel) towers of abstraction, map other domains (at the same time mapping each other - the x rings of processor privelege mapped under Linux kernel to two spaces: user and kernel space) - the domain of life coding.


---> here the fpga research, the switching of circuits UNDER

instruction and paper circuits pile


user ____ kernel

Kernel/OS definitions and related ideas

The kernel or operating system abstracts that which is uniform (the hardware-tagged space of memory cells) as that which is segmented according to process (PID - unique ID) and user. Shared memory space. Clone and fork of processes in a tree structure which mimes the filesystem hierarchy.

From Daniel. P Bovet et al. Understanding the Linux Kernel. 2005. O'Reilly:

The operating system must fulfill two main objectives:


In a multiuser system, each user has a private space on the machine; typically, he owns some quota of the disk space to store files, receives private mail messages, and so on. The operating system must ensure that the private portion of a user space is visible only to its owner. In particular, it must ensure that no user can exploit a system application for the purpose of violating the private space of another user.



All operating systems use one fundamental abstraction: the process. A process can be defined either as "an instance of a program in execution" or as the "execution context" of a running program. In traditional operating systems, a process executes a single sequence of instructions in an address space; the address space is the set of memory addresses that the process is allowed to reference. Modern operating systems allow processes with multiple execution flows that is, multiple sequences of instructions executed in the same address space.


Unix-like operating systems adopt a process/kernel model . Each process has the illusion that it's the only process on the machine, and it has exclusive access to the operating system services. Whenever a process makes a system call (i.e., a request to the kernel, see Chapter 10), the hardware changes the privilege mode from User Mode to Kernel Mode, and the process starts the execution of a kernel procedure with a strictly limited purpose. In this way, the operating system acts within the execution context of the process in order to satisfy its request. Whenever the request is fully satisfied, the kernel procedure forces the hardware to return to User Mode and the process continues its execution from the instruction following the system call.

[Online ref: http://linux-security.cn/ebooks/ulk3-html/0596005652/understandlk-CHP-1-SECT-4.html]

for promiscuOS... some notes:

leaks across process memory (implemented beneath the process - within generic segmentation faultcode), filesystem, sockets+pipes (referred to as IPC): memory is context. segregation of memory is seperation of user and process.

address space of a process: all linear addresses that the process is allowed to use (see p.352 Understanding)

pipes p.776+ also the pipe code we found: lp-01 which copies file descriptors (pipe is only accessible to parent process). FIFO allows for arbitrary piping and is associated with a kernel buffer.

IPC shared memory. executable in shared memory?

http://user-mode-linux.sourceforge.net/projects.html - note DSM - distributed shared memory:

This can be done with UML because UML's physical memory is really virtual memory on the host, so it can be mapped and unmapped. So, the idea is to spread a single UML instance over multiple hosts by running a virtual processor on each host and partitioning UML physical memory between them. A page that's present on one node will be unmapped from the others. If one of the other nodes accesses it, it will fault, and a new low-level fault handler will figure out what node currently has it, and request that it be sent over. The other node will unmap it, and copy it over to the requesting node, which will map it in to the appropriate location and continue running.

In UML codebase we're also looking at:

linux-2.6.19/arch/um/sys-i386/signal.c:364: force_sig(SIGSEGV, current);


int handle_page_fault(unsigned long address, unsigned long ip,... in:

linux-2.6.19/arch/um/kernel/trap.c:203: force_sig_info(SIGSEGV, &si, current);


how exactly does UML work with memory management?

"A page fault exception is raised when the addressed page is not present in memory, the corresponding page table entry is null or a violation of the paging protection mechanism has occurred." [ULK]. Linux handles a page fault exception with the page fault handler "do_page_fault()". This handler can be found in "arch/i386/mm/fault.c". You may also need to read related contents of Chapter 4 in LKP "The next most important piece of the port is the virtual memory emulation. An important job of the kernel is to maintain a separate memory context for each process, making it impossible for one process to access memory belonging to another. Native kernels accomplish this by allocating physical pages and doing hardware magic to map them into the appropriate location in a process virtual memory. UML emulates this first by creating a file that is the same size as the physical memory that UML has been told it has, and then by mapping this file as a whole into an area of its virtual memory that will be treated as its "physical" memory. When a process needs memory to be allocated, pages will be allocated from this area and the corresponding pages in the file will be mmapped() into the process virtual memory.

access to file?

UML must also emulate hardware faults and device interrupts. The most important fault that needs to be emulated is a page fault, which happens whenever a process does an invalid memory access. In UML this generates a SIGSEGV; the handler does the necessary checking to see if the access is valid and a new page needs to be mapped into the process (if it's invalid, the process is sent the SIGSEGV). Device interrupts are generally emulated with SIGIO on the file descriptor used to communicate with the virtual device. The timer is implemented by requesting a SIGVTALRM timer from the host kernel. SIGSEGV, SIGIO, and SIGVTALRM are the equivalent of hardware traps. Just as processes on a physical Linux machine aren't affected by hardware traps unless the kernel converts them into Linux signals, these signals don't affect any UML processes unless the UML kernel converts them into Linux signals. UML installs its own handlers for these signals, which run in UML kernel mode." ... Jeff Dike

from: http://lass.cs.umass.edu/~shenoy/courses/spring04/577/lab5.html

raw access to filesystem (/dev/hda1 for example)

path of execution. passed down through shell.