Messages in this thread | | | Date | Wed, 05 Jul 2000 13:51:29 +0000 | From | Peter Rival <> | Subject | Re: a joint letter on low latency and Linux |
| |
Steve VanDevender wrote:
> Albert D. Cahalan writes: > > Digital UNIX (now Tru64, was OSF/1) uses self-modifying code to > > create a generic kernel that can do, if I remember right: > > > > 1. plain > > 2. real-time > > 3. SMP > > 4. real-time SMP > > 5. lock debugging >
<snip>
> > I don't think any sane person would want to maintain whatever > self-modifying code tricks that Digital UNIX might use to accomplish > this fabled feat.
Have you actually looked at the code that does the self-modification work? It has remained (so far) fairly stable for quite a while. The big difference, which I don't believe most people understand, is that Linux inlines its locking code whereas Tru64 does not. That makes the code modification work much more simple. Just take a look at the assembly code of simple_lock_patch_init() in dbx - it's really quite straightforward.
> And did I mention that the Digital UNIX kernel is a > massive 8 megabytes _after_ you prune out most of the optional features?
Did you ever notice that it also still has all of its symbols and debugging info in the same file? The Linux vmlinux.gz/bzImage is stripped and compressed; a correct comparison would be between a vmlinux (not vmlinux.gz) image built with -g3, that way all the same information is present in both.
I'm not saying anything is better or worse for Linux or Tru64 - there are definite advantages to both ways of doing things. I just want to make sure that if people are going to think about trying to do things the way Tru64 does them they are fully informed. And considering that I'm getting paid to make comparisons between Tru64 and Linux at a code level, one could hopefully say that I'm fairly well informed. ;)
- Pete
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |