[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Some very thought-provoking ideas about OS architecture.
    > 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

    1. You need an indexing object - in a fileystem it is a directory or
    directory tree
    2. You need to position objects/files for locality
    3. You need fragmentation resistant algorithms

    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
    > commit/rollback.

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.024 / U:13.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site