RE: Re: [PATCH v2 2/6] crypto: crc64 - add crc64-iso framework

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

 



"Elliott, Robert (Servers)" <elliott@xxxxxxx> writes:

>> -----Original Message-----
>> From: Kamlesh Gurudasani <kamlesh@xxxxxx>
>> Sent: Friday, August 18, 2023 2:26 AM
>> Subject: Re: [EXTERNAL] Re: [PATCH v2 2/6] crypto: crc64 - add crc64-iso
>> framework
>> 
>> Eric Biggers <ebiggers@xxxxxxxxxx> writes:
>> 
>> > Is "crc64-iso" clear enough, or should it be "crc64-iso3309"?  There are
>> > thousands of ISO standards.  Different CRC variants are specified by
>> different
>> > ISO standards.  Is this particular variant indeed commonly referred to
>> as simply
>> > the "ISO" CRC-64?  Even if it's currently the case that all other CRCs
>> in ISO
>> > standards are different widths than 64 bits (which may be unlikely?),
>> I'm not
>> > sure we should count on no CRC-64 variant ever being standardized by
>> ISO.
>> >
>> > - Eric
>> https://en.wikipedia.org/wiki/Cyclic_redundancy_check
>> 
>> Last entry CRC-64-ISO in the table.
>> It is mentioned as crc64-iso and that's the
>> only 64-bit CRC standardized by ISO. 
>
> ECMA-182 (DLT-1 tapes) was contributed to become ISO/IEC 13421 in 1993, so
> that was another "64-bit CRC standardized by ISO." Plus, ISO could publish new
> standards with new CRCs at any time.
>
>> But I do agree that crc64-iso3309 would be more specific, will change it
>> to crc64-iso3309 in next revision. Thanks.
>> 
>> Regards,
>> Kamlesh
>
> ISO-3309:1991 was withdrawn and revised by
> ISO/IEC 3309:1993, which was withdrawn and revised by
> ISO/IEC 13239:2002, which was confirmed in 2007 and is still current.
>
> Apparently only the 1991 version defined a CRC-64; later versions dropped
> that.
>
> Is there really a demand for adding a 23 year old deprecated algorithm to
> the kernel?
I understand your concern but a lot of TI's K3 based J7* and AM6* SOCs
have MCRC and MCRC64(Mostly on AM6* SOCs)
Where MCRC64 only supports above mentioned CRC64 algorithm and few
customers wants to use the hardware based CRC to ensure FFI, so we
actually need it.
If it is available in upstream and can be used easily, a lot of
customers would want to use it.

I'll look into the naming and will provide something specific to that
particular algo.

Kamlesh




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux