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.


Adam