> Accepting your analysis, it still seems to me there's a difference,
> though. In an EROS-like world, you would only pay the complexity cost of doing
> fscobject-like things in the postmortem analyzer that's trying to
> stitch together the remaining pieces. You wouldn't have to pay that same
That depends on if you want to consistency check your object store after a crash. Unless you journal the object store - which btw is hard. If you have two thousand inter-related objects you need to dump the set of them consistently and in a snapshotted state.
Funnily enough "object system" and file system journalling are identical.
> is run its own debugging and benchmarking tools. Still, the fact that
> the test kernel can be that small is IMO an argument that the design
> is sound.
V7 Unix is smaller than that. System III is about 60K on a 68010 CPU.
> > block writes tell me how it will outperform a conventional OS if only
> > a small number of changes in a small number of objects occur.
> No seeks to read inodes, because the map from EROS's virtual-space
> blocks to disk blocks is almost trivial (essentially the disks get
> treated like a honkin' big series of swap volumes). So the disk
> access pattern would be quite different, I think.
Not really. The mapping of objects to disks is complex the moment you allow an object to expand or want to reclaim space. Again it is the same problems
There are arguments about how you provide this - ranging from conventional cylinder groups through log structured file systems to stuff like reiserfs where the fs is viewed much more in a database fashion.
It doesn't matter if your email is an object or a file or a database record, they are the same thing. Your handle just changes name.
> That, under most circumstances, you don't have to manage persistence
> yourself (or to put it more concretely, no explicit disk I/O in most
> applications). That's clearly a huge win, even if you end up having to do
> more conventional-looking things in applications that require
Why is having persistence managed by a library that is playing guessing games of your intent a good idea ? It has to know about object relationships, potentially it has to blindly snapshot the entire system. It has to do a lot of work to know in detail what has changed.
Again this is identical to conventional file system problems. if you've ever tried to send someone a file not knowing what other files it happens to include or need, you've met the object relationship problems.
So all you have to do is export every object that this object refers to. Like the windowing environment, whoops oh dear. I've worked with persistant object stores of sorts. AberMUD5 is a multiuser game that is basically a persistant object store. The "how do I split something off from the rest" problem isn't fun. You can do most of it by making a logical copy of the object store marking the objects you want as needed and garbage collecting the rest. However even if you then are smart about some of the object linkages you still find large numbers of objects that wont go away and whose connectivity and relation to the stuff you want is very complex even to visualise.
> What I'm thinking is this: remember RT-Linux? Suppose the kernel were
> a process running over an EROS-like layer...
Suppose Eros was just a set of persistent object libraries that ran on top of numerous other platforms too, could be downloaded off the net and worked pretty well within the limits of the "programmer lazy, do more work than needed" paradigm.
And that is demonstrably the right way up. If you put a "lazy programmer" system at the bottom of an environment you prevent the smart programmer doing smart things. If your bottom layer is fundamentally ignorant of programmer provided clues you cripple the smart.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/