Vino [148] adopta un enfoque similar al de Spin, dado que permite insertar código (grafts o injertos en Vino) en el kernel como mecanismo básico de adaptación del sistema. Consiguientemente presenta los problemas (mencionados en el apartado anterior) derivados de esta estrategia. Vino se plantea extensiones que alteren la política, el rendimiento y la funcionalidad del sistema aunque no es factible reemplazar aquellas abstracciones que resulten inadecuadas y ya estén presentes en el sistema.
Vino suministra un interfaz común que se emplea para cualquier recurso presente en el sistema. Dicho interfaz es independiente de la representación adoptada por cada recurso. Los recursos en Vino son entidades que poseen un conjunto de operaciones y un conjunto de propiedades (algo no muy diferente de la estructura de los recursos en sistemas basados en objetos). En cuanto al nivel de abstracción de dichos recursos, debemos decir que éstos incluyen abstracciones tales como ficheros.
Estos recursos están tipados y, aunque pueden reemplazarse (o su implementación extenderse) en tiempo de ejecución, la jerarquía de tipos de dichos recursos en Vino ha de indicarse por completo en tiempo de compilación del sistema. Sorprendentemente, esta limitación es explícitamente introducida por los autores del sistema [148] de tal modo que se beneficie el rendimiento y la robustez como consecuencia de la información adicional (tipos) suministrada. Como compensación, se permite introducir nuevos subtipos en tiempo de ejecución (un subtipo ha de mantener al menos la semántica del tipo de que deriva).
Pensando ahora en la implementación de los recursos, y no en el
interfaz que éstos presentan, la implementación por defecto que
suministra el sistema para los distintos recursos puede alterarse
mediante la introducción de grafts en el núcleo del mismo. Como
vemos, Vino resulta entonces muy similar a Spin. Al contrario que
Spin, Vino emplea C y C++ como lenguaje para escribir grafts.
El compilador que se emplea para compilarlos introduce comprobaciones
adicionales en todos los accesos a memoria y en todas las llamadas a
función. En nuestra opinión, resulta en este caso más efectivo el
empleo de un lenguaje con tipado estricto de datos como Modula 3, de
tal modo que gran parte de estas comprobaciones puedan obviarse
Aunque es cierto que sin dichas comprobaciones, un usuario malicioso
puede emplear un compilador modificado
para sortear el
sistema de tipado estricto.
Una de las contribuciones de los autores de Vino es la clasificación de los distintos modelos de extensiones que pueden realizarse [147]. Dichos autores distinguen entre extensiones de priorización, de streaming y de caja negra. El primer modelo se basa en asignar prioridades a distintos elementos de entre los que se supone hay que escoger alguno(s). Un caso típico es la elección de una página a reemplazar. Así, anidando distintas políticas es factible partir de un conjunto original de elementos e ir aplicando dichas políticas de forma sucesiva hasta obtener el conjunto final de elementos que interesa. El segundo modelo, streaming, se basa en el procesamiento mediante pipe-lines de tal modo que sucesivos componentes van filtrando los datos de que se parte hasta obtener un conjunto de datos ya procesado. El tercer modelo (caja negra) es el más general y consiste en un elemento software que tiene algunas entradas, un proceso que no conocemos (y sobre el que no cabe hacer suposiciones) y presenta una única salida. La política de ``read-ahead'' en un disco es un ejemplo de este último modelo.