在 2006-07-11二的 16:13 [EMAIL PROTECTED]
[...]
>       I agree with you. Firstly, we may keep up with OpenDarwin, just as
> what's on
> 
> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/chapter_2_section_6.html
>  
> 
> At the same time, we may port/rewrite C++ support library for GNU CC or
> Intel C++ Compiler step by step as we really need.
> 
>       But prior to long-term discussion, please commit my 4 patches
> firstly. They are nearly CPP-independent and do no harm to current
> FreeBSD kernel.

No.  These patches are incomplete, see below.

> --- kern.mk.orig      Fri Jun 30 05:15:25 2006
> +++ kern.mk   Mon Jul 10 18:42:43 2006
> @@ -88,7 +88,7 @@
>   .if ${CC} == "icc"
>   CFLAGS+=    -nolib_inline
>   .else
> -CFLAGS+=     -ffreestanding
> +CFLAGS+=     -fno-builtin
>   .endif
>   
>   .if ${CC} == "icc"

It is wrong to remove -ffreestanding here, at least for now.

> --- libkern.h.orig    Fri Oct  7 03:06:07 2005
> +++ libkern.h Mon Jul 10 18:50:23 2006
> @@ -115,7 +115,7 @@
>   static __inline uint32_t
>   crc32_raw(const void *buf, size_t size, uint32_t crc)
>   {
> -     const uint8_t *p = buf;
> +     const uint8_t *p = (const uint8_t *) buf;
>   
>       while (size--)
>               crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8);

This change hides an API problem here.  We really should be more careful
here.

> --- systm.h.orig      Mon Jul 10 05:42:58 2006
> +++ systm.h   Mon Jul 10 18:44:01 2006
> @@ -203,7 +203,7 @@
>   int suword16(void *base, int word);
>   int suword32(void *base, int32_t word);
>   int suword64(void *base, int64_t word);
> -intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t new);
> +intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t __new__);
>   
>   void        realitexpire(void *);

__ is typically reserved for compilers.  How can you assume that __new__
does not stand for a constructor in some compliers?  Also the change
would break the code consistency, and it is incomplete.  I have take
some time to investigate the kernel code and there are multiple
instances of "new" as an identifier across the kernel source, and
changing it here and leave others alone does not make the code better,
IMHO.

So, I think we should move the discussion to -arch@ and no change should
be made until we have worked out a right way.

Cheers,
-- 
Xin LI <delphij delphij net>    http://www.delphij.net/

Attachment: signature.asc
Description: 这是信件的数 字签名部分

Reply via email to