lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1305203663.15167.111.camel@deneb.localdomain>
Date:	Thu, 12 May 2011 08:34:23 -0400
From:	Mark Salter <msalter@...hat.com>
To:	Milton Miller <miltonm@....com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arch/c6x: new architecture port for linux

On Wed, 2011-05-11 at 20:13 +0000, Milton Miller wrote:
> On Wed, 11 May 2011 around 17:11:19 EST, Mark Salter wrote:
> > This patch series adds support for a new architecture (arch/c6x) to
> > Linux. This architecture supports members of the Texas Instruments
> > family of C64x single and multicore DSPs. The multicore DSPs do not
> > support cache coherancy, so are not suitable for SMP. Also, these are
> > no-mmu processors. This core architecture is VLIW with an instruction
> > set optimized for DSP applications. For details on the processors:
> 
> So all the changelogs talk about C64x but the arch and all the configs
> are called c6x?  Is it that hard to type 2 digits?   Or do you expect
> an additional chip that breaks the C64 but would fit the C6x name?
> 

The full DSP family is C6000. The current port supports C64xx processors
within that family. There are also C67xx processors with floating point
support. Future support for those seem likely as the instruction set is
nearly identical.

> Also, a couple of one liners while preparing my comments on hvc_c6x:
> 
> [09/16] C6X: add kernel files
> 
> in kernel/setup.c you include linux/delay.h multiple times
> 
Okay, I'll get rid of it.

> 
> 
> [11/16] C6X: add lib files
> 
> arch/c6x/lib/memset.c
> 
> (1) file header says linux/arch/c6x/lib/memcmp.c
> (you should probably just delete such headers, they are just maintence errors)

Agreed. I've been removing these as I find them. I need to sweep the
whole code base and get rid of them all.

> 
> (2) it appears to mach lib/string.c implementation except (1) register (2)
> uses post-increment instead of pre-increment.   Does it matter with gcc?
> 
> arch/c6x/lib/memcmp.c
> 	your version returns -1 or 1 while string.c returns the difference
> after promotion to int.   man page for userspace says just integer less
> than or greater, so I guess this is ok.  But is this more efficient,
> or could you use the generic version?

I'm pretty sure the generic versions would be just fine using gcc. There
may have been a reason for them when using the TI toolchain, but it
makes sense to just ditch the c6x versions at this point.

--Mark



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ