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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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