DragonFly kernel List (threaded) for 2007-05
DragonFly BSD
DragonFly kernel List (threaded) for 2007-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Leaf changes


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 29 May 2007 10:13:25 -0700 (PDT)

:Last time I looked it was quite portable code, just the endian conversion=
: was missing to make it truely interoperable.
:
:cheers
:  simon

    Yah, it should be fairly portable, since I actually use the network
    mode between a DragonFly box and a linux box for my offsite backups.

    It will detect incompatible endian because it puts a magic number in
    the header, but it does not yet do any conversion.

    If someone wants to tackle that, here is what I suggest:

    * Always send data in native endian format (NOT network endian format).

    * Receiver detects that the sent endian != its native endian by
      detecting that magic is HCMAGIC_REV instead of HCMAGIC.

    * Receiver translates the message before passing the message on to
      the RPC function.

    * RPC function is not touched.

    And for data translation I recommend:

    * The header and item structure can be endian detected and adjusted
      very easily.  The messages use structured data that is well defined.

    * Most item data payloads are identified with LCF_TYPEMASK and can be
      endian-adjusted without the RPC code needing to know about it.

    * Any other opaque item data (not sure if there is any) that isn't
      just a raw data buffer must be endian-adjusted by the protocol.

      I'm not sure how many bits and pieces would have to be fixed, but
      it would not be much.

    cpdup uses a bastardized version of the syslink messaging encoding,
    which is why it seems ready-made for this sort of work... because
    syslink is designed to be easily endian adjusted.

						-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]