Linux Killer?

Linux Killer?

So Tycho said this was just about the most fascinating thing he'd read lately, and I have to agree.

Jack Thompson would both love and hate Reiser; he's a case study for both sides of the argument that violent videogames create violent people. I'd definitely be interested in seeing where the kid, Rory Reiser ends up in 10 years.

I'm at work and it is boring me stupid.



Do you think he's a good case study for both sides of the argument because he might have killed his wife? Surely, in fact, he either did or he didn't - so for one of the groups he's a very bad example.

Or were you thinking, and this is why the case is fascinating, it just shows how strange, alien people can appear normal and capable?

I read a lot about Reiser back when this all hit, and I'm not convinced of his guilt. The more I hear from him, the more likely I think it is that he'd burn and bleach car seats, that'd he'd drive erratically to lose a tail, and that he'd come across as unhinged to a Wired reporter. A Wired reporter who doesn't understand the difference between source and a patch, thinks Reiser4 is a 'program' and thinks it consists of one 80,500 line file.
+ 1. His infancy.
+ Once upon a time, the znode was born deep inside of zget() by call to
+ zalloc(). At the return from zget() znode had:
+ . reference counter (x_count) of 1
+ . assigned block number, marked as used in bitmap
+ . pointer to parent znode. Root znode parent pointer points
+ to its father: "fake" znode. This, in turn, has NULL parent pointer.
+ . hash table linkage
+ . no data loaded from disk
+ . no node plugin
+ . no sibling linkage
+ 2. His childhood
+ Each node is either brought into memory as a result of tree traversal, or
+ created afresh, creation of the root being a special case of the latter. In
+ either case it's inserted into sibling list. This will typically require
+ some ancillary tree traversing, but ultimately both sibling pointers will
+ exist and JNODE_LEFT_CONNECTED and JNODE_RIGHT_CONNECTED will be true in
+ zjnode.state.
+ 3. His youth.
+ If znode is bound to already existing node in a tree, its content is read
+ from the disk by call to zload(). At that moment, JNODE_LOADED bit is set
+ in zjnode.state and zdata() function starts to return non null for this
+ znode. zload() further calls zparse() that determines which node layout
+ this node is rendered in, and sets ->nplug on success.
+ If znode is for new node just created, memory for it is allocated and
+ zinit_new() function is called to initialise data, according to selected
+ node layout.
+ 4. His maturity.
+ After this point, znode lingers in memory for some time. Threads can
+ acquire references to znode either by blocknr through call to zget(), or by
+ following a pointer to unallocated znode from internal item. Each time
+ reference to znode is obtained, x_count is increased. Thread can read/write
+ lock znode. Znode data can be loaded through calls to zload(), d_count will
+ be increased appropriately. If all references to znode are released
+ (x_count drops to 0), znode is not recycled immediately. Rather, it is
+ still cached in the hash table in the hope that it will be accessed
+ shortly.
+ There are two ways in which znode existence can be terminated:
+ . sudden death: node bound to this znode is removed from the tree
+ . overpopulation: znode is purged out of memory due to memory pressure
+ 5. His death.
+ Death is complex process.
+ When we irrevocably commit ourselves to decision to remove node from the
+ tree, JNODE_HEARD_BANSHEE bit is set in zjnode.state of corresponding
+ znode. This is done either in ->kill_hook() of internal item or in
+ kill_root() function when tree root is removed.
+ At this moment znode still has:
+ . locks held on it, necessary write ones
+ . references to it
+ . disk block assigned to it
+ . data loaded from the disk
+ . pending requests for lock
+ But once JNODE_HEARD_BANSHEE bit set, last call to unlock_znode() does node
+ deletion. Node deletion includes two phases. First all ways to get
+ references to that znode (sibling and parent links and hash lookup using
+ block number stored in parent node) should be deleted -- it is done through
+ sibling_list_remove(), also we assume that nobody uses down link from
+ parent node due to its nonexistence or proper parent node locking and
+ nobody uses parent pointers from children due to absence of them. Second we
+ invalidate all pending lock requests which still are on znode's lock
+ request queue, this is done by invalidate_lock(). Another JNODE_IS_DYING
+ znode status bit is used to invalidate pending lock requests. Once it set
+ all requesters are forced to return -EINVAL from
+ longterm_lock_znode(). Future locking attempts are not possible because all
+ ways to get references to that znode are removed already. Last, node is
+ uncaptured from transaction.
+ When last reference to the dying znode is just about to be released,
+ block number for this lock is released and znode is removed from the
+ hash table.
+ Now znode can be recycled.
+ [it's possible to free bitmap block and remove znode from the hash
+ table when last lock is released. This will result in having
+ referenced but completely orphaned znode]
+ 6. Limbo
+ As have been mentioned above znodes with reference counter 0 are
+ still cached in a hash table. Once memory pressure increases they are
+ purged out of there [this requires something like LRU list for
+ efficient implementation. LRU list would also greatly simplify
+ implementation of coord cache that would in this case morph to just
+ scanning some initial segment of LRU list]. Data loaded into
+ unreferenced znode are flushed back to the durable storage if
+ necessary and memory is freed. Znodes themselves can be recycled at
+ this point too.
Now guess which line the journalist chose to pull out of context? Which one did he say "concludes" the comment?
Well, if he did kill her then he's an argument for it, but if he didn't then he's an argument against it.