Hi all, Does any one know the mathematical theory of below functions in: https://github.com/ceph/ceph/blob/master/src/common/armor.c 1) ceph_armor 2) ceph_unarmor B.R. Changcheng
(resending to include dev@ceph.io) On 5/13/2020 7:56 AM, Liu, Changcheng wrote:
Hi all, Does any one know the mathematical theory of below functions in: https://github.com/ceph/ceph/blob/master/src/common/armor.c 1) ceph_armor 2) ceph_unarmor
B.R. Changcheng _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
It's just, as it says, base64 encoding; that is, it selects an ASCII character for each 6 bits of the input. https://en.wikipedia.org/wiki/Base64
Hi Dan Mick, Thanks for your confirm. Math is magic. B.R. Changcheng On 20:05 Wed 13 May, Dan Mick wrote:
(resending to include dev@ceph.io)
On 5/13/2020 7:56 AM, Liu, Changcheng wrote:
Hi all, Does any one know the mathematical theory of below functions in: https://github.com/ceph/ceph/blob/master/src/common/armor.c 1) ceph_armor 2) ceph_unarmor
B.R. Changcheng _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
It's just, as it says, base64 encoding; that is, it selects an ASCII character for each 6 bits of the input. https://en.wikipedia.org/wiki/Base64 _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
On Thu, May 14, 2020 at 6:06 AM Dan Mick <dmick@redhat.com> wrote:
(resending to include dev@ceph.io)
On 5/13/2020 7:56 AM, Liu, Changcheng wrote:
Hi all, Does any one know the mathematical theory of below functions in: https://github.com/ceph/ceph/blob/master/src/common/armor.c 1) ceph_armor 2) ceph_unarmor
These are basic base64 conversions. Yehuda
B.R. Changcheng _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
It's just, as it says, base64 encoding; that is, it selects an ASCII character for each 6 bits of the input. https://en.wikipedia.org/wiki/Base64 _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
Hi all, I'm trying to accelerate base64 encode/decode in Ceph. There's one contradictory logic in ceph_armor & ceph_unarmor: 1. ceph_armor: It won't add new breakline '\n' in the encoded result. https://github.com/ceph/ceph/blob/master/src/common/armor.c#L85 Note: line_width is always 0 https://github.com/ceph/ceph/blob/master/src/common/armor.c#L96 2. ceph_unarmor: It will use specific logic to deal with the new breakline in '\n' https://github.com/ceph/ceph/blob/master/src/common/armor.c#L106 Why do we implement it in this way? Which version of base64 RFC is followd by Ceph? B.R. Changcheng
On Sat, May 16, 2020 at 4:33 PM Liu, Changcheng <changcheng.liu@intel.com> wrote:
Hi all, I'm trying to accelerate base64 encode/decode in Ceph.
There's one contradictory logic in ceph_armor & ceph_unarmor: 1. ceph_armor: It won't add new breakline '\n' in the encoded result. https://github.com/ceph/ceph/blob/master/src/common/armor.c#L85 Note: line_width is always 0 https://github.com/ceph/ceph/blob/master/src/common/armor.c#L96 2. ceph_unarmor: It will use specific logic to deal with the new breakline in '\n' https://github.com/ceph/ceph/blob/master/src/common/armor.c#L106
Why do we implement it in this way? Which version of base64 RFC is followd by Ceph?
It is common to have base64 strings that have line breaks in them, so our decoding function needs to be able to handle that whether we use it or not. We do have ceph_armor_line_break() that can be used in theory (although it's not being used right now). There are cases where we need to handle base64 strings that were encoded by external sources, so code needs to be resilient and handle these cases. Yehuda
On 10:27 Sun 17 May, Yehuda Sadeh-Weinraub wrote:
On Sat, May 16, 2020 at 4:33 PM Liu, Changcheng <changcheng.liu@intel.com> wrote:
Hi all, I'm trying to accelerate base64 encode/decode in Ceph.
Why do we implement it in this way? Which version of base64 RFC is followd by Ceph?
It is common to have base64 strings that have line breaks in them, so our decoding function needs to be able to handle that whether we use it or not. We do have ceph_armor_line_break() that can be used in theory (although it's not being used right now). There are cases where we need to handle base64 strings that were encoded by external sources, so code needs to be resilient and handle these cases.
Could you show which acutal usage needs to decode the '\n' in the encoded base64 string? Which base64 RFC is followd by Ceph? What's extra changes are added based the standard used RFC? --Changcheng
Yehuda
On 5/17/2020 6:40 AM, Liu, Changcheng wrote:
On 10:27 Sun 17 May, Yehuda Sadeh-Weinraub wrote:
On Sat, May 16, 2020 at 4:33 PM Liu, Changcheng <changcheng.liu@intel.com> wrote:
Hi all, I'm trying to accelerate base64 encode/decode in Ceph.
Why do we implement it in this way? Which version of base64 RFC is followd by Ceph?
It is common to have base64 strings that have line breaks in them, so our decoding function needs to be able to handle that whether we use it or not. We do have ceph_armor_line_break() that can be used in theory (although it's not being used right now). There are cases where we need to handle base64 strings that were encoded by external sources, so code needs to be resilient and handle these cases.
Could you show which acutal usage needs to decode the '\n' in the encoded base64 string? Which base64 RFC is followd by Ceph? What's extra changes are added based the standard used RFC?
This seems like a very strange thing to focus on. The Ceph utility routine has the capability to add line breaks if requested; so far, the callers inside ceph do not add line breaks, but they could if desired. The code also ignores line breaks on input. This is just a normal coding decision, as the newline itself (or indeed any whitespace) is not part of the coding domain. Why do you find this to be an issue that requires attention?
participants (3)
-
Dan Mick
-
Liu, Changcheng
-
Yehuda Sadeh-Weinraub