CMSC 838Y Paper Reviews

Skip down to paper 0: Alastair Reid, Matthew Flatt, Leigh Stoller, Jay Lepreau, and Eric Eide. Knit: Component composition for systems software. In Proceedings of theFourth USENIX Symposium on Operating Systems Design and Implementation, pages 347-360, October 2000.[ .pdf ]


Reviews for paper 0

Review from Yuan Yuan<yuanyuan@cs> at Mon Feb 24 13:49:38 EST 2003:

Authors present part of their work in the Alchemy Project. They developed a 
first component definition and linking toolset to improve the usability and 
performance of C code. The main idea of Knit is to provide a language tool to 
describe linking specification so that it could be separated from core 
programming language. Because of the drawback of conventional linking (no clear 
interface and hard to do extension) and object-based linking (hard to trace 
error, bad performance, limited type-check tools), this paper proposed Unit 
linking. In Units, corresponding to components, the description for imports, 
exports and source code using them is explicit. Also you can let system check 
compatibility between components and find ˇ°global errorˇ± by giving 
architectural constraints. Also authors argue that Knit makes code easier to 
understand and trace without hurting performance much.

The idea in Knit is good. Clear linking language will sure help programmer 
understand source code than interleaving dynamic linking of system. But Knit 
pushed the work of system to programmers by acclaiming the linking process is 
more amendable for programmers. Also the syntax of Knit looks verbose. I think 
the graphic tools and automatic generating linking specification will help. 
Also the optimization method is merging all the code together will generating a 
big source for system, will it lose the flexibility of component systems?

Review from Prashant Lamba<plamba@wam.umd.edu> at Mon Feb 24 15:05:30 EST 2003:

This paper defines the concept of KNIT which is component defination and 
linking alnguage for C.In the begning of the paper authors explain the need of 
the componet based systems and critises the existing systems for their poor 
component support and gives the valid and convincing reason for this basic 
building blocks of the KNIT are units.KNIT is designed to have static linking 
so it supports components on both the source and compiled form.In the next 
section of the paper author explains the different linking methods link 
conventional linking,Object based linking(COM) and Unit Linking .And explains 
the reasons for the use of the Unit Linking .
The linking in KNIT has two kinds of units a atomic and compound units.Author 
explains the Model for the KNIT .The Realistic model of the KNIT is well 
described in the paper.The concept of the bundles.The paper also explains the 
architectural constrains and gives the solution for that .In KNIT when the 
components are linked together KNIT analysis the constraints and report an 
error if constraints are not satisfied.This paper also gives the brief 
discription of CLARK.At the end of the paper it gives the implementation and 
performance issues of the KNIT.
In short author is able to explain the need of component based systems 
verywell.
And presents the KNIT as an plateform for the developeent of the component 
system.

Review from Bryan Payne <bdpayne@cs> at Mon Feb 24 19:47:08 EST 2003:

Knit solves a problem that I've never had problems with before.  Or, to say 
that a little more clearly, Knit addresses problems with ld that will only be 
encountered in rather complex or unique coding situatitions.  It just so 
happens that I have never run into one of these situations.  Therefore, I had 
to read a little ways into the paper before I felt like I fully understood the 
problem that they were solving.

Some software system have unique linking needs that go beyond the normal call 
of duty for ld.  One such system is OSKit.  OSKit allows people to put together 
an OS as a union of separate OS modules.  However, the actual order of module 
linking is dependent upon the modules chooen to create the OS.  And this is 
where Knit comes in handy.

Knit provides additional syntax (somewhat excess syntax in my opinion...and the 
authors seem to agree) to allow for more intelligent linking of components.  I 
found that this paper was very readable and did a nice job of presenting the 
ideas.  In addition, I felt that the ideas provided a good solution to this 
problem.  One interesting note is the method of optimization discussed at the 
end of the paper.  The basic idea was to roll all of the source code into a 
single file...and then compile.  The authors claimed that this provided a 
substantial increase in performance.  While I find their speed improvement 
claims to be considerably larger than I would have expected, it would be 
interesting to further explore this idea in an effort to better understand the 
benefits and drawbacks invovled.

Review from Nikhil Swamy <nswamy@cs> at Mon Feb 24 23:15:50 EST 2003:

The authors have addressed the problem of weak modularization of C-code by the 
creation of a language to explicitly provide linkage structure to a C-program 
in a declarative manner. The Knit infrastructure provides components without 
making any extensions to C - though limited in expressivity, Knit appears to be 
clean and extensible implementation of module systems, familiar constructs in 
many other languages, for C.

The paper is well structured - sufficient abstract motivation for the problem 
sets the stage for the introduction of the solution. The design of Knit is 
presented using a toy-model, which, refreshingly, is not overly contrived - it 
presents the fairly common scenario of interposition of methods. Perhaps it is 
the conceptual simplicity of Knit itself that lends itself to easy description.

The authors make a brief presentation of a constraint satisfaction system that 
is built into Knit - one can imagine a number of ways in which this might be 
implemented (a type checker being the most obvious), and it would have been 
interesting to learn more about this feature. Overall, this paper is a good 
read and presents its core concepts clearly.

Review from Jeff Odom <jodom@cs.umd.edu> at Tue Feb 25 03:10:32 EST 2003:

Knit is a linking language specification for C that lies between classic ld and 
total object-oriented programming (e.g. COM).  Instead of relying on object 
files to separate interfaces, import/export collections ("units") are 
explicitly specified in Knit.  For final linking, a partial ordering may be 
specified in the Knit language.

There were two features of Knit that were interesting.  First, the ability to 
encapsulate one interface with another, without changing the code of anything 
that imports that interface, and on a per-client basis as well.  This has the 
advantage of being able to selectively replace invocations of interfaces while 
retaining the original code (to either be built upon or only called in certain 
places).  Secondly, the concept of adding constraints to the linking process 
seems a good idea, both in terms of sanity checking as well as for future 
upgrade consistency.

The only area I felt was questionable was the cross-component optimization.  To 
perform this, they merge several C files into a single file, rename 
variables/functions, and then perform inter-procedural optimizations.  In 
general, performing a mass compilation on a single file and running a 
inter-procedural analysis does not perform well - it is questionable as to why 
the authors felt the need to mention this feature.

Review from Brian Krznarich <bjkrz@cs> at Tue Feb 25 08:47:51 EST 2003:

It would be nice if this form selected the paper by default- I just had to 
rewrite this after submitting and it telling me that no form was selected.  For 
some reason ie6 does not like caching as much as previous versions (for 
security?)

Knit is a language designed to specify Components and Component linking in a 
more precise way than linking with ld can accomplish (at least without a lot of 
work by the programmer with renaming and other preprocessing tricks).   It's 
key features are: 1) managing intialization order of mutually referencing 
components.  2) Constraint checking- in particular the mention "can this bit of 
code be run without a process context?". 3) Inlining functions across component 
boundaries. 

Their list faults with standard ld linking. One is difficulty interposing one 
component between two others that usually word together, because of ld global 
naming and general inability to specify which of multiple options one would 
like to link to.   Another is difficulty in component replacement, when perhaps 
documentation has not made it clear exactly what an individual component 
specifies or requires.  While this is likely often true it does not seem an 
inherant fault of current linking methods, though Knit does try to force the 
programmer to be more structured in specifying how linking for components 
should be performed. 

He also mentions the alternative of object based linking. Among some 
performance and programming overheads of object "Symptoms of misusing objects 
as components include late discovery of errors, difficulty of tracing the 
source of link errors"- I couldn't figure out why this was more true for 
objects than components.

Later on it seems that his optimizations are all 'source available' ones.  Knit 
can provide some useful information to a compiler, but in general source is not 
available for components, negating almost all of their suggested optimizations.

The language seems to follow standard linking contructs; A module has an 
interface specifying imports and exports and propogations from one to the 
other. Renaming of functions inside the module is supported.  Dependencies are 
addressed with the 'needs' keyword. 

On restraint checking the authors state "... conventional type systems detect 
local errors, but the problems that occur in component software are often 
global errors, where each individual component may be correct, but the entire 
system is wrong".  That seems like a pretty strong assertion, I could have used 
an example. 

They look at performance with OSKid and teh CLick dynamic router- performance 
is generally alright, no surpise since actual linking methods don't really 
change, only the methods for specifying how linking should be done.  

Review from Polyvios Pratikakis <polyvios@cs> at Tue Feb 25 08:51:45 EST 2003:

Knit is a system that helps managing program components written in C. In this 
paper, after a small introduction on current linking techniques of C 
components, the notion of Unit linking for C is presented. Knit uses a "little 
language" to specify the interface of components, which can then be combined in 
many ways, the system checking for safety each combination. Two examples of 
Knit application are presented, and application to a "custom operating system 
builder" toolkit, and a modular router. These are clearly systems that already 
use the notion of components, even implicitly.
Overall, I think the application of such "wrappings" to C code are good, but do 
not make up for the language's missing support for correct modular/component 
programming. Also, the applications of Knit presented were already modular 
systems, where all modules were clearly defined in advance. Even so, there was 
a substantial amount of effort to convert the existing programs and write the 
interface definitions. The implementation of the system is not described in 
detail, but it would be really interesting to see how knit handles "very 
type-unsafe" programs written in C. Because of the application of Knit, there 
was an increase in performance, due to the optimizations made possible by the 
"type-system" of Knit. However, it's main purpose is not to substitute an 
optimizing compiler/linker, but to add better component-programming support to 
the C language.

Review from Piyush Bhagat<piyushb@glue.umd.edu> at Tue Feb 25 10:42:42 EST 2003:

The paper describes Knit, which is a new module language and toolset for 
managing systems components. It is made on the lines of module languages like 
modula-3 and mesa. The paper underlines the need for components in software 
systems. It says that the components should be general and flexible enough to 
be used in many contexts but at the same time they should be simple enough so 
that different programmers are able to understand their interfaces and 
implement them. The existing linkers and compilers do not work very well with 
such components as they are designed for libraries. The paper presents several 
qualities of knit like It provides automatic scheduling, initialization and 
finalization of components etc. I feel one of the most important aspects of 
Knit is its ability to work on components in both source form and compiled 
form. Knit supports separate compilation and linking which I think now is a 
basic requirement from any programming language. The paper finally bends 
towards the usage and implementation of Knit in the Oskit operating system. 
OSKit is an operating system built up of various components, which in turn are 
built up of Knit. The paper also discusses implementation and performance 
issues and claims that inspite of bad performance of component softwares Knits 
performance is pretty good. 
I feel in future many more languages for defining and linking system components 
will come up with the aim of making components and linking specifications 
easier to define.    

Review from James Rose <rosejr@cs> at Tue Feb 25 11:56:52 EST 2003:


	Knit takes ordinary theoretical tools and uses them to design
a linker that can address many concerns in component-based software.
It essentially acts as a layer of indirection during the linking
phase: symbols are no longer global identifiers, but simply plugs to
be wired to other plugs.  It also shifts the emphasis away from single
object files or single classes as the unit of organization to larger,
arbitrarily-defined components.  To demonstrate the benefits of this
shift, Knit adds a "flattening" optimization, where all source files
constituting a single component are compiled together at once, giving
the compiler a better chance to optimize.  Another orthogonal feature, 
constraint types, is also added on.  

	I think that Knit could make building large systems in C / C++
much easier, without complicating the code written by programmers.
What I like most about it is that it ignores the trend of wrapping
things in more and more complex abstractions; it is simply a tool with
a lot of options.  Of course, it doesn't have the flexibility of a
full run-time linking system, but it trades that for speed and
simplicity, while making static configuration much simpler.

	I don't think there is anything particularly exciting about
the property / constraint system.  It is like any other type system,
except that it is applied during the linking phase, and over larger
units of code than we typically see.  The primary reason to put it in
the linker rather than in the language is because they are working
with a weakly-typed language and untyped object files, so it is easier
to add it to the linker.  One (fairly obvious) way to improve the
system I think would be to add these constraints to a type-safe
language which uses type-safe object code.

	The primary weakness of Knit, which they acknowledge in the
paper, is that it requires complicated linking specifications.
Hopefully some of this complexity is compensated by simpler Makefiles.



Review from Nathaniel Waisbrot <waisbrot@cs> at Tue Feb 25 12:00:34 EST 2003:

	Most of the paper seems well-explained, and the component model is clearly 
useful in programming systems.  The architectural constraints in Knit (knowing 
where a component can and cannot be used, as in their example, where some 
components need a process context, and therefore can't run at the lowest 
levels), were not explained as well as I would have liked.  For example, if one 
component describes hundreds of constraints, do all components that import or 
export it also need to define those constraints?

Review from Mujtaba Ali <mujtaba@bitsmart.com> at Tue Feb 25 12:12:05 EST 2003:

The paper did a good job early on of explaining the difference between a 
library and a component, as well as establishing a good case for Knit over 
current compiling and linking tools.  The authors also make a very compelling 
argument as to why they didn't choose a more dynamic-oriented approach (systems 
stuff doesn't change much).  Simplicity is the key here and for system-level 
programming, the Knit authors realized (by experience) that something like 
COM/CORBA is overkill.  Personally, I wish all linking would follow such an 
explicit model.  I have always disliked what the authors refer to as the "grab 
bag" approach for the very reason they mention - it's very confusing to a new 
programmer coming in on even a mid-sized project.  The authors' examples are 
very clear and concise, and the syntax of Knit played a major role here.  The 
Jiazzi paper is at a clear disadvantage, primarily because of the awful syntax 
Jiazzi has.  I found the choice of Clack a poor one, though.  Unlike an OS, I 
would think a router would need frequent security updates.  Also, the 
cross-component optimization was simply appalling.  I can't believe they even 
included such a "hack" in a published article.

Knit's constraint-checking system was an interesting twist on 
programming-by-contract.  Although the Knit authors have tried to tune to 
constraint-checking model for systems programming, I think a more general 
programming-by-contract model would still be better.  I can't think of many 
uses outside of the context example provided where the specialized model would 
fit.

For some reason, Knit felt somewhat like the C equivalent of Java interfaces.  
In fact, this seems to be a trend (partially demonstrated by even Cyclone).  
Currently, there are a lot of efforts to find the holy grail: how to "port" the 
flexibility found in many aspects of high-level languages to C, but still keep 
performance intact.  Initialization and finalization, although useful for 
automatic scheduling, also felt a lot like constructors and destructors in OO 
languages.


Generated: Thu Mar 6 15:39:24 EST 2003 by mwh


mwh@cs.umd.edu