(Illustration by Gaich Muramatsu)
Greg Troxel wrote: > Adam Wolbach <awolbach_at_andrew.cmu.edu> writes: > >>> Do you really mean that this is Linux specific and won't run on BSD? >>> I think it would be useful to post the design and interface >>> specification to ASRs. Does this work change the venus/kernel >>> interface, or just interact with venus, or just use repair ioctls and >>> the filesystem? > >> I haven't tried it yet on BSD -- there might be a few library calls I >> make that are Linux specific, but certainly the work does not change >> the venus/kernel interface. It uses accesses and writes to the file >> system along with existing repair tools (filerepair, e.g.), although >> it comes with a few more cfs calls that make playing with a volume's >> CML possible from the command line. I will test ASR's shortly on a >> BSD installation; the goal is to have the ASR framework be >> platform-independent. > > That sounds good. I presume by 'cfs calls' you mean pioctls that are > handled by venus? More repair/CML richness from the command line > sounds like a good idea independent of ASR. > Creating new pioctls wasn't really necessary, I simply hijacked existing ones used solely by the Coda repair tool for local/global conflicts. The commands look like: cfs listlocal [volume] //list all CML entries in this volume cfs preservelocal [volume] //attempt to semantically preserve the head entry in this volume's CML cfs discardlocal [volume] //discard the head CML entry of a volume cfs discardallocal [volume] //identical to cfs purgeml [volume] They do turn out to be extremely useful when debugging, as well as with ASRs. >> A short design overview: what really happens upon conflict discovery, >> is venus (upon noticing a conflict) forks the ASRLauncher, an ASR >> handler program that performs the search for an ASR rules file, parses >> the file, resolves dependencies and executes the appropriate ASR, if >> it checks out. The ASR then just purely interacts with Venus and the >> file system. >> >> I will post documentation, including design/implementation >> considerations, to the Coda Wiki in the near future, but feel free to >> ask any more questions you may have, I will be checking the codalist. >> > > Thanks - that sounds sensible (to me who hasn't thought about this > much) and doesn't sound like it has any lurking OS dependencies Thanks for the feedback. AdamReceived on 2006-04-19 17:32:21