Is the vlserver DB format documented anywhere?

On Mon, Jul 25, 2011 at 1:28 PM, Simon Wilkinson <s...@inf.ed.ac.uk> wrote:
>
> I saw a mention of IPv6 support sometime in 2011 in my old email..
>
> It's a work in progress.
> There are actually multiple components to achieving IPv6 support in AFS-3.
> Different amounts of progress have been made on each of these components...
> 1/ Refactor the OpenAFS RX API so that IPv6 addresses can be used as
> endpoints. There are two sub tasks here. Firstly we need additional
> functions that can support opening connections to  v6 endpoints, and
> internal changes to support accepting connections over IPv6. Secondly, we
> want to rework the API so that the internals of RX structures such as
> connections and calls aren't exposed to library users. This work is also a
> prerequisite for rx/tcp support, and as such is on my list.
> 2/ Create a generic XDR representation for an endpoint. The work in
> afs3-stds to produce an extensible union actually grew from this - once this
> work is complete (it pretty much is) we can move forwards to create an
> address type
> 3/ Create new versions of all AFS-3 RPCs which take IPv4 addresses, and have
> these new versions use the extensible address type. The plan is to do this
> work as part of RPC refresh. Chaz Chandler has already made great progress
> on the new definitions - they're in a comparable form in gerrit 4573. These
> new RPCs will require standardisation.
> 4/ Extend the vlserver database so that it can store IPv6 addresses. This is
> potentially the trickiest part of the puzzle, as we would like to do this
> and maintain a clear mechanism for backing out server upgrades. Ubik
> database formats are private to OpenAFS, so this doesn't require
> standardisation work. Some scoping work has been done here, but no
> implementation of  which I am aware.
> 5/ Rework all of OpenAFS's internal data structures and APIs to store
> addresses in a new extensible format, rather than just using int32s.
> There's enough work here that could be easily accomplished in parallel if
> anyone is interested in contributing to it.
> Cheers,
> Simon.
>



-- 
Tom Maher <tma...@watson.org>
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to