Date: Tue, 11 Jul 2006 16:51:48 +0800 From: Xin LI <delphij@delphij.net> To: mag@intron.ac Cc: des@des.no, Julian Elischer <julian@elischer.org>, freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ Message-ID: <1152607908.980.8.camel@spirit> In-Reply-To: <courier.44B35DBC.00003F75@intron.ac> References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <courier.44B35DBC.00003F75@intron.ac>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-g2jNqYSpUv7auB1C2Vor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2006-07-11=E4=BA=8C=E7=9A=84 16:13 +0800=EF=BC=8Cmag@intron.ac=E5= =86=99=E9=81=93=EF=BC=9A [...] > I agree with you. Firstly, we may keep up with OpenDarwin, just as > what's on >=20 > http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFu= ndamentals/Features/chapter_2_section_6.html=20 >=20 > 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. >=20 > 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} =3D=3D "icc" > CFLAGS+=3D -nolib_inline > .else > -CFLAGS+=3D -ffreestanding > +CFLAGS+=3D -fno-builtin > .endif > =20 > .if ${CC} =3D=3D "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 =3D buf; > + const uint8_t *p =3D (const uint8_t *) buf; > =20 > while (size--) > crc =3D 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__); > =20 > 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, --=20 Xin LI <delphij delphij net> http://www.delphij.net/ --=-g2jNqYSpUv7auB1C2Vor Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBEs2akhcUczkLqiksRAi9uAKDRyY+GVELhYdtzNLgn5btHeZdQpACfd2/O EfrXE4AUfdGPzX0Xpx6NMHs= =r/1F -----END PGP SIGNATURE----- --=-g2jNqYSpUv7auB1C2Vor--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1152607908.980.8.camel>