Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Oct 2015 18:26:12 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Alexander Motin <mav@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-vendor@FreeBSD.org
Subject:   Re: svn commit: r289310 - vendor-sys/illumos/dist/common/zfs vendor-sys/illumos/dist/uts/common vendor-sys/illumos/dist/uts/common/crypto vendor-sys/illumos/dist/uts/common/crypto/io vendor-sys/illumos...
Message-ID:  <56212524.2020301@FreeBSD.org>
In-Reply-To: <561FCAE1.1040504@FreeBSD.org>
References:  <201510141112.t9EBCmFZ022230@repo.freebsd.org> <561FC5A0.3040909@FreeBSD.org> <561FC90F.4090706@FreeBSD.org> <561FC996.3020207@FreeBSD.org> <561FCAE1.1040504@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 15/10/2015 17:48, Alexander Motin wrote:
> On 15.10.2015 18:43, Andriy Gapon wrote:
>> On 15/10/2015 17:41, Alexander Motin wrote:
>>> On 15.10.2015 18:26, Andriy Gapon wrote:
>>>> On 14/10/2015 13:12, Alexander Motin wrote:
>>>>> Author: mav
>>>>> Date: Wed Oct 14 11:12:47 2015
>>>>> New Revision: 289310
>>>>> URL: https://svnweb.freebsd.org/changeset/base/289310
>>>>>
>>>>> Log:
>>>>>   4185 add new cryptographic checksums to ZFS: SHA-512, Skein, Edon-R
>>>>>   
>>>>>   Reviewed by: George Wilson <george.wilson@delphix.com>
>>>>>   Reviewed by: Prakash Surya <prakash.surya@delphix.com>
>>>>>   Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com>
>>>>>   Reviewed by: Richard Lowe <richlowe@richlowe.net>
>>>>>   Approved by: Garrett D'Amore <garrett@damore.org>
>>>>>   Author: Matthew Ahrens <mahrens@delphix.com>
>>>>>   
>>>>>   illumos/illumos-gate@45818ee124adeaaf947698996b4f4c722afc6d1f
>>>>>
>>>>> Added:
>>>>>   vendor/illumos/dist/common/crypto/
>>>>>   vendor/illumos/dist/common/crypto/edonr/
>>>>>   vendor/illumos/dist/common/crypto/edonr/edonr.c   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/edonr/edonr_byteorder.h   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/
>>>>>   vendor/illumos/dist/common/crypto/skein/THIRDPARTYLICENSE   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/THIRDPARTYLICENSE.descrip   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/skein.c   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/skein_block.c   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/skein_impl.h   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/skein_iv.c   (contents, props changed)
>>>>>   vendor/illumos/dist/common/crypto/skein/skein_port.h   (contents, props changed)
>>>>
>>>> It seems that these are pieces of code that can be used by both the
>>>> userland and the kernel.  I think that previously we used to import such
>>>> code into illumos-sys and then integrate it into sys/cddl (e.g.
>>>> common/zfs/).  Perhaps it is worthwhile following that convention in
>>>> this case as well?
>>>
>>> I haven't decided what to do with this specific case. As I understand,
>>> now we are using FreeBSD's native crypto code instead of illumos' one. I
>>> was thinking about importing this commit only in infrastructural parts,
>>> until respective algorithms are implemented in our native crypto. I
>>> think it should not be a problem for Skein, since according to comments
>>> it is in public domain. About Edon-R I am not sure, since it seems to be
>>> CDDL.
>>
>> This is confusing...  It seems that like you replied to my question in
>> another email, not the quoted one :-)
> 
> What other email?

So, I was confused, I got an impression that you had replied to this one
http://article.gmane.org/gmane.os.freebsd.devel.cvs/534648
Actually, it would be nice if you do :)

> You've told me that I put code into the wrong place,
> and I replied that it may be irrelevant, since I am not sure we should
> import this code to FreeBSD as-is to its place in illumos.

Even if the code turns out to be irrelevant for us, it still would be
nice to put it into the correct / conventional place in the vendor area.
There is no reason to create the confusion for no good cause.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56212524.2020301>