On 08/21/12 09:32 AM, Dan McGregor wrote:
Hi.
I've been working on porting compiler-rt/clang's support for address
sanitization (asan) to FreeBSD. So far I have it building and it
appears to work properly, however the build system expects to be able
to build 32 bit binaries on amd64.
amd64 doe
Hi.
I've been working on porting compiler-rt/clang's support for address
sanitization (asan) to FreeBSD. So far I have it building and it
appears to work properly, however the build system expects to be able
to build 32 bit binaries on amd64.
amd64 doesn't include i386's machine/foo headers. Th
On Thu, Aug 16, 2012 at 9:06 AM, Konstantin Belousov
wrote:
> Since you did not provided exact diff of your change, I cannot comment
> on what goes wrong. Anyway, just merge the r239301 locally and use
> sysctl kern.pid_max.
Thanks, the kern.pid_max tunable works well on 8.2.
The diff to /usr/s
On Mon, 20 Aug 2012 13:05:51 MDT Warner Losh wrote:
>
> On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote:
>
> >> #if defined(__i386__) || defined(__amd64__)
> >> *dst =3D *src;
> >> #else
> >> bcopy(src, dst, ETHER_ADDR_LEN);
> > #else
> > short *tmp1=3D((*short)src),*tmp2=3D((*short)dst
On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote:
>>> or use ++.
>>>
>>> i think it is always aligned to 2 bytes and this should produce usable code
>>> on any CPU? should be 6 instructions on MIPS and PPC IMHO.
>>
>> We should tag it as __aligned(2) then, no? If so, then the compiler shoul
or use ++.
i think it is always aligned to 2 bytes and this should produce usable code on
any CPU? should be 6 instructions on MIPS and PPC IMHO.
We should tag it as __aligned(2) then, no? If so, then the compiler should
generate the code you posted.
should is the most important word in Your
On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote:
>> #if defined(__i386__) || defined(__amd64__)
>> *dst = *src;
>> #else
>> bcopy(src, dst, ETHER_ADDR_LEN);
> #else
> short *tmp1=((*short)src),*tmp2=((*short)dst);
> *tmp2=*tmp1; *(tmp2+1)=*(tmp1+1); *(tmp2+2)=*(tmp1+2);
>
> or use ++.
>
#if defined(__i386__) || defined(__amd64__)
*dst = *src;
#else
bcopy(src, dst, ETHER_ADDR_LEN);
#else
short *tmp1=((*short)src),*tmp2=((*short)dst);
*tmp2=*tmp1; *(tmp2+1)=*(tmp1+1); *(tmp2+2)=*(tmp1+2);
or use ++.
i think it is always aligned to 2 bytes and this should produce usable
co
On Aug 20, 2012, at 8:46 AM, Mitya wrote:
> Hi.
> I found some overhead code in /src/sys/net/if_ethersubr.c and
> /src/sys/netgraph/ng_ether.c
>
> It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN);
> When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6.
> This code call
Hi.
I found some overhead code in /src/sys/net/if_ethersubr.c and
/src/sys/netgraph/ng_ether.c
It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN);
When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6.
This code call every time, when we send Ethernet packet.
On example, o
On 08/20/2012 02:19, Bjoern A. Zeeb wrote:
> On Mon, 20 Aug 2012, Doug Barton wrote:
>
>> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
>>
>>> We will continue to reject this until there are more firm plans,
>>> proper documentation on the security support side, which I cannot
>>> remember Simon got
On 08/20/2012 02:16, Mark Blackman wrote:
>
> On 20 Aug 2012, at 10:12, Doug Barton wrote:
>
>> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
>>
>>> We will continue to reject this until there are more firm plans,
>>> proper documentation on the security support side, which I cannot
>>> remember Si
On 20 Aug 2012, at 10:12, Doug Barton wrote:
> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
>
>> We will continue to reject this until there are more firm plans,
>> proper documentation on the security support side, which I cannot
>> remember Simon got an answer for.
>
> I gave a clear answer. I
On Mon, 20 Aug 2012, Doug Barton wrote:
On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
We will continue to reject this until there are more firm plans,
proper documentation on the security support side, which I cannot
remember Simon got an answer for.
I gave a clear answer. If there are any piec
On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
> We will continue to reject this until there are more firm plans,
> proper documentation on the security support side, which I cannot
> remember Simon got an answer for.
I gave a clear answer. If there are any pieces missing it's up to Simon
to follow u
On Mon, 20 Aug 2012, Doug Barton wrote:
On 08/06/2012 13:23, Vitaly Magerya wrote:
Doug Barton wrote:
On 07/07/2012 16:33, Garrett Wollman wrote:
The utilities (specifically host(1) and dig(1)) are the only
user-visible interfaces I care about.
[...]
ldns (a dependency of unbound) comes wi
On 08/06/2012 13:23, Vitaly Magerya wrote:
> Doug Barton wrote:
>> On 07/07/2012 16:33, Garrett Wollman wrote:
>>> The utilities (specifically host(1) and dig(1)) are the only
>>> user-visible interfaces I care about.
> [...]
>> ldns (a dependency of unbound) comes with drill, which is a dig-alike
17 matches
Mail list logo
