Re: kern/99979: Get Ready for Kernel Module in C++
Václav Haisman [EMAIL PROTECTED] writes: Deciding that some features are bad beforehand, before you evaluate them is IMO bad idea. Let interested people write a bunch of C++ modules with the complete language before deciding on what shouldn't be used. It's not that simple. The complete language requires a ton of support code which must be written and tested. Are you volunteering to do that? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
[EMAIL PROTECTED] writes:
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.
We don't do the kind of changes you propose without discussion.
--- 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
Are you sure this is correct? I'm pretty certain it isn't. The
kernel's C environment is not a hosted implementation.
--- 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__);
This is a namespace violation. A simpler solution is to leave out
argument names entirely.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Dag-Erling [iso-8859-1] Sm grav wrote:
[EMAIL PROTECTED] writes:
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.
We don't do the kind of changes you propose without discussion.
--- kern.mk.origFri 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
Are you sure this is correct? I'm pretty certain it isn't. The
kernel's C environment is not a hosted implementation.
GCC manual page gcc(1) says:
-ffreestanding
Compile for a freestanding environment; this implies the `-fno-
builtin' option, and implies that main has no special require-
ments.
GCC manual says:
(http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C-Dialect-Options.html)
-ffreestanding
Assert that compilation takes place in a freestanding environment.
This implies -fno-builtin. A freestanding environment is one in
which the standard library may not exist, and program startup may
not necessarily be at main. The most obvious example is an OS
kernel. This is equivalent to -fno-hosted.
But -ffreestanding doesn't work with C++. According to above
explanation, -fno-builtin is a subset of -ffreestanding and it's
enough for kernel.
In /usr/src/contrib/gcc/c-opts.c, -ffreestanding is recognized as:
case OPT_ffreestanding:
value = !value;
/* Fall through */
case OPT_fhosted:
flag_hosted = value;
flag_no_builtin = !value;
/* warn_main will be 2 if set by -Wall, 1 if set by -Wmain */
if (!value warn_main == 2)
warn_main = 0;
break;
In /usr/src/contrib/gcc/c-decl.c, -ffreestanding takes effects as:
if (MAIN_NAME_P (DECL_NAME (fndecl)) flag_hosted)
{
if (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (fndecl)))
!= integer_type_node)
{
/* If warn_main is 1 (-Wmain) or 2 (-Wall), we have already warned.
If warn_main is -1 (-Wno-main) we don't want to be warned. */
if (!warn_main)
pedwarn (%Jreturn type of '%D' is not `int', fndecl, fndecl);
}
else
{
#ifdef DEFAULT_MAIN_RETURN
/* Make it so that `main' always returns success by default. */
DEFAULT_MAIN_RETURN;
#else
if (flag_isoc99)
c_expand_return (integer_zero_node);
#endif
}
}
From above code we can conclude that -ffreestanding can affect only
something about main() more than -fno-builtin.
I have compiled the whole FreeBSD kernel with -fno-builtin and met
no problems. Now I am running the kernel with -fno-builtin to write
to you with Linux ABI Mozilla-GTK1 1.7.12 and NVIDIA X11 driver 1.0-8762.
--- systm.h.origMon Jul 10 05:42:58 2006
+++ systm.h Mon Jul 10 18:44:01 2006
@@ -203,7 +203,7 @@
intsuword16(void *base, int word);
intsuword32(void *base, int32_t word);
intsuword64(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__);
This is a namespace violation. A simpler solution is to leave out
argument names entirely.
If the code style permits, I agree with you.
GCC support library usually uses namespace to add various prefixes
to its built-in functions/variables in order to avoid conflicts against
user code. In ELF binary file, built-in functions/variables' names are
much longer than __new__. See files in
/usr/src/contrib/libstdc++/libsupc++/.
From Beijing, China
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
[EMAIL PROTECTED] writes: But -ffreestanding doesn't work with C++. While the C++ standard does define hosted and freestanding implementations, its definition is different from (and less useful than) that in the C standard. For instance, the C++ standard requires the existence of abort(), atexit() and exit() even in a freestanding implementation. Basically, one cannot indiscriminately use the same compiler flags for C and C++, because they are very different languages - far more different than they seem on the surface. Modern C++ is very poorly suited for low-level code. According to above explanation, -fno-builtin is a subset of -ffreestanding and it's enough for kernel. No, it isn't. I think you would do wisely to acquire a little more knowledge of and experience with C, C++ and kernel programming before you pursue this topic any further. Most importantly, we already have an working object model in the FreeBSD kernel, with classes, inheritance, and all that jazz, implemented partly in C and partly in a custom IDL which is translated into C by src/sys/tools/makeobjops.awk. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
在 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.origFri 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__);
voidrealitexpire(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 nethttp://www.delphij.net/
signature.asc
Description: 这是信件的数 字签名部分
Re: kern/99979: Get Ready for Kernel Module in C++
Václav Haisman [EMAIL PROTECTED] writes: Binary compatibility is always a problem, no mater the language used. Besides, doesn't the FreeBSD kernel build system always compile all modules? It can be configured in make.conf if you want only a subset of modules. Deciding that some features are bad beforehand, before you evaluate them is IMO bad idea. Let interested people write a bunch of C++ modules with the complete language before deciding on what shouldn't be used. No, that won't work -- plus you need a bunch of run-time support (libstdc++ isn't exactly something that belongs into the kernel you know). -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stop further socket() or connect() calls.
mal content [EMAIL PROTECTED] wrote: I was looking for a way to write a small wrapper program that disables network access and then exec()'s a given program. Sorry for the late reply, but ... The easiest way to do what you described is to run the program in a jail which has a jail IP that doesn't exist and isn't routed. Then the program cannot perform any network access. For example: jail / foo 127.0.0.2 /your/program All attempts to access the network should result in an error no route to host (errno EHOSTUNREACH). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++: an octopus made by nailing extra legs onto a dog -- Steve Taylor, 1998 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Dag-Erling [iso-8859-1] Sm grav wrote:
[EMAIL PROTECTED] writes:
But -ffreestanding doesn't work with C++.
While the C++ standard does define hosted and freestanding
implementations, its definition is different from (and less useful
than) that in the C standard. For instance, the C++ standard requires
the existence of abort(), atexit() and exit() even in a freestanding
implementation.
Basically, one cannot indiscriminately use the same compiler flags for
C and C++, because they are very different languages - far more
different than they seem on the surface. Modern C++ is very poorly
suited for low-level code.
Just as you said, C++ is more complicated than C. However, without
C++ exception and other advanced features, it hasn't brought much
complexity to C++ runtime library. Early C++ compiler even translates
C++ code into C code before real compilation.
We can judge whether a C++ feature can or cannot be imported into FreeBSD
kernel by assemble code generated by GNU CC.
For example, I think C++ exception handling is really poorly suited for
low-level code.
According to above explanation, -fno-builtin is a subset of
-ffreestanding and it's enough for kernel.
No, it isn't. I think you would do wisely to acquire a little more
knowledge of and experience with C, C++ and kernel programming before
you pursue this topic any further.
Most importantly, we already have an working object model in the
FreeBSD kernel, with classes, inheritance, and all that jazz,
implemented partly in C and partly in a custom IDL which is translated
into C by src/sys/tools/makeobjops.awk.
Is the object model described in FreeBSD Architecture Handbook?
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/kernel-objects.html)
But the object model is still obscure to understand no matter how many
people all over the world master C++. What's more, can the object model
function really as OpenDarwin's IOKit class model?
(http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html)
Now, OpenDarwin has owned a C++-based kernel object model. But why
cannot FreeBSD?
DES
--
Dag-Erling Sm grav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on
FreeBSD's actuality: so weak USB support (kernel crash easier than many
other OSs that we laughed at and that we are laughing at), so weak PCI
device support.
But how difficult to write a device driver for FreeBSD? We have only
incomplete FreeBSD documents, and we must search FreeBSD source code
that probably has little relationship to the hardware device. If still
confused, we must search Google and submit a question in mailing lists
just like an ignorant pupil.
A really terrible style of FreeBSD device driver is REPEATING so many
codes similar to other device drivers.
Please look at files in /sys/dev/usb/. Why do so many USB device
drivers repeat:
err = usbd_device2interface_handle( ... );
...
for( ... ) {
...
ed = usbd_interface2endpoint_descriptor( ... );
...
}
Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI
device drivers repeat:
pci_read_config( ... )
...
sc-vr_res = bus_alloc_resource_any( ... );
...
sc-vr_irq = bus_alloc_resource_any( ... );
...
Is this kind of awful writing just of FreeBSD's style?
In contrast, with C++, we can avoid many code repeating among device
drivers.
Many USB/PCI driver need only override a member function like
OnUSBMatch() and OnPCIProbe() to identify a deivce by
Vendor/Product ID.
After matching, in many device drivers, a default member function
of base class like OnUSBAttach() or OnPCIAttach() can do attaching
operations in the most common way. Most of driver writes needn't override
default OnXXXAttach(), and they can indicate its own IRQ, I/O address,
USB bulk in/out pipe by some member variables like m_nIRQ, m_nIOAddr,
m_nUSBBulkIn and m_nUSBBulkOut, inherited from base class.
Userland program may call read() and write() while device driver may
simply submit/obtain a packet or a stream section to/from special member
functions without concerning buffering or not, O_NONBLOCK or not,
O_ASYNC or not.
If we would have constructed an object model in C++, a programmer who
master Microsoft MFC, Darwin I/O Kit could easily write a device drive
with the device's hardware data sheet. At that time, FreeBSD can win
support from hardware manufacturers more easily.
You can LOOK DOWN UPON me again and again. But is it really your patent,
a FreeBSD security team member's patent: you know what FreeBSD kernel
and C++ is, but I am too BRAINLESS to understand FreeBSD kernel and C++?
Re: kern/99979: Get Ready for Kernel Module in C++
[EMAIL PROTECTED] writes: Dag-Erling [iso-8859-1] Sm grav wrote: [EMAIL PROTECTED] writes: But -ffreestanding doesn't work with C++. While the C++ standard does define hosted and freestanding implementations, its definition is different from (and less useful than) that in the C standard. For instance, the C++ standard requires the existence of abort(), atexit() and exit() even in a freestanding implementation. Basically, one cannot indiscriminately use the same compiler flags for C and C++, because they are very different languages - far more different than they seem on the surface. Modern C++ is very poorly suited for low-level code. Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. Several C++ compilers still do that, but that is irrelevant. What is relevant is the size and complexity of the runtime support library. For example, I think C++ exception handling is really poorly suited for low-level code. Exception handling is required by the standard, even for freestanding implementations. Is the object model described in FreeBSD Architecture Handbook? (http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/kernel-objects.html) Yes. But the object model is still obscure to understand no matter how many people all over the world master C++. The fact that you don't understand it doesn't mean it's bad. What's more, can the object model function really as OpenDarwin's IOKit class model? Does it need to? Now, OpenDarwin has owned a C++-based kernel object model. But why cannot FreeBSD? Look, if you want MacOS X, you know where to find it. Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. Please provide references to the PRs you filed about these issues. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
On Tue, Jul 11, 2006 at 10:45:52PM +0800, [EMAIL PROTECTED] wrote: Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. RTTI, allocation, exceptions and static allocators all add complexity for the runtime library. If you really want to use C++ for a kernel, you must likely want to use all of them as well. For example, I think C++ exception handling is really poorly suited for low-level code. Bullshit. With a proper implementation exceptions add no overhead as long an exception is not thrown in terms of speed. It does matter somewhat in terms of code (or better: data) size, but the very same information is useful to generate much better tracebacks as well. RTTI is highly useful for debugging and semi-optional consistent checks, which should not be neglected either. I don't care about the abuse of explicitly comparing object types etc., but the ability to decide what exactly a certain object is. But the object model is still obscure to understand no matter how many people all over the world master C++. What's more, can the object model function really as OpenDarwin's IOKit class model? (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) The kobj implementation has the same feature set as a lightweight C++, e.g. inheritance and virtual functions. That's basically what IOKit is using as well. It is not obscure, just a Domain Specific Language. Now, OpenDarwin has owned a C++-based kernel object model. But why cannot FreeBSD? Because the kernel is C and not many points to incrementally add C++ have been made, which makes it a worthwhile goal. And if you want to complain about redundancy in drivers, carefully look for differences which often far outweight the common functionality. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
On Tuesday 11 July 2006 10:57, Dag-Erling Smørgrav wrote: For example, I think C++ exception handling is really poorly suited for low-level code. Exception handling is required by the standard, even for freestanding implementations. Standards aside, in Darwin, the C++ Apple uses does not have any exception handling or RTTI (and maybe not even templates). They use their own set of meta classes to implement an RTTI-like system that allows for future changes in the ABI. You would also benefit from doing some of your own research. But the object model is still obscure to understand no matter how many people all over the world master C++. The fact that you don't understand it doesn't mean it's bad. No, but it is obtuse. And very underused. How many device drivers do you know of that use kobj inheritance? What's more, can the object model function really as OpenDarwin's IOKit class model? Does it need to? He's trying to port IOKit to FreeBSD for his exercise (if you had read his first e-mail you'd know that). Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. Please provide references to the PRs you filed about these issues. USB crashes are not that uncommon, and compared to other OS's (such as Windows and OS X both of which I've written a PCI driver for) we require device driver writers to go through a lot more hoops to do certain things like allocate resources. At the very least there is much that can be improved in our driver model. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
(please don't Cc me on list replies; chopping down the Cc list) On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote: Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. But what's the point of C++ if it is mutilated below minimum standard compliance levels so that you can no longer call it C++? This discussion has been through for other systems such as Linux long ago, and it wasn't lack of manpower, but lack of technical feasibility, or in other words, what was still useful for a kernel wasn't that much different from C any more. C99 already adressed several concerns of C89, and ISTR that FreeBSD kernels are C99 code these days. We can judge whether a C++ feature can or cannot be imported into FreeBSD kernel by assemble code generated by GNU CC. Great, make the whole kernel depend on compiler internals. Can you imagine a single vendor who'd have interest in hauling so many dependencies into their software and handle all the support? I can't. Write a C stub and put the rest into userspace where C++ works. For example, I think C++ exception handling is really poorly suited for low-level code. Which chops off one of C++'s legs to stand on. Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT) with Linux and plugged TWO devices into it and see Linux fail to talk to the device you plugged in later? No? If so, you have zero clue how bad USB support can get. And that's not the only problem Linux USB has had or still has. Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI device drivers repeat: pci_read_config( ... ) ... sc-vr_res = bus_alloc_resource_any( ... ); ... sc-vr_irq = bus_alloc_resource_any( ... ); ... Is this kind of awful writing just of FreeBSD's style? In contrast, with C++, we can avoid many code repeating among device drivers. How would C++ avoid such? Generic programming, RTTI support and such stuff requires an awful lot of compile-time code generation and runtime library support. If we would have constructed an object model in C++, a programmer who master Microsoft MFC, Darwin I/O Kit could easily write a device drive with the device's hardware data sheet. And errata, and talking to the device happens in C-like programming anyways... -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] Václav Haisman [EMAIL PROTECTED] writes: : Deciding that some features are bad beforehand, before you evaluate them : is IMO bad idea. Let interested people write a bunch of C++ modules with : the complete language before deciding on what shouldn't be used. There's actually a fair amount of experience with people doing C++ in FreeBSD kernels. People have been doing things with it for about 8 years now. There are significant performance issues with even C code compiled as C++. It is possible to write fast C++ for kernel work, but it is also very easy to write really bad C++ for kernel work. Easier than bad C code. There's reasons that people here are somewhat skeptical about using C++ in the kernel. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : --- systm.h.orig Mon Jul 10 05:42:58 2006 : +++ systm.hMon 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__); : : This is a namespace violation. A simpler solution is to leave out : argument names entirely. : : If the code style permits, I agree with you. : : GCC support library usually uses namespace to add various prefixes : to its built-in functions/variables in order to avoid conflicts against : user code. In ELF binary file, built-in functions/variables' names are : much longer than __new__. See files in : /usr/src/contrib/libstdc++/libsupc++/. __new__ is bogus. _new if you must. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : You can LOOK DOWN UPON me again and again. But is it really your patent, : a FreeBSD security team member's patent: you know what FreeBSD kernel : and C++ is, but I am too BRAINLESS to understand FreeBSD kernel and C++? I don't think anybody thinks you are brainless to understand kernel and C++. Many people here have actually done C++ experiements with the FreeBSD kernel, and to date those experiments have all failed badly. If you'd like to do such an experiment yourself, please by all means feel free. When you have more experimental evidence to support the claims you are making, we'd love to see it. However, given then extreme pain than many of the kernel developers have had with C++ in the kernel, the burdon of proof will be on those advocating C++ as being better proving with real code their assertions. As to your other points, the resource allocation repetition has been improved with bus_alloc_resources. the trouble is that many drivers haven't been converted to use the new api. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : and OS X both of which I've written a PCI driver for) we require device : driver writers to go through a lot more hoops to do certain things like : allocate resources. At the very least there is much that can be improved in : our driver model. bus_alloc_resources goes a long ways in this respect. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
John Baldwin wrote: On Tuesday 11 July 2006 10:57, Dag-Erling Sm grav wrote: For example, I think C++ exception handling is really poorly suited for low-level code. Exception handling is required by the standard, even for freestanding implementations. Standards aside, in Darwin, the C++ Apple uses does not have any exception handling or RTTI (and maybe not even templates). They use their own set of meta classes to implement an RTTI-like system that allows for future changes in the ABI. You would also benefit from doing some of your own research. Yeah. Besides inspection to OpenDarwin, my motivation comes from my inspection to assemble code generated by GNU CC. Many object-oriented directives have been implemented in .o file by compiler. But the object model is still obscure to understand no matter how many people all over the world master C++. The fact that you don't understand it doesn't mean it's bad. No, but it is obtuse. And very underused. How many device drivers do you know of that use kobj inheritance? Of course many (with bus_if.h and device_if.h generated). But if I am writing a member function, I am not enough grammartically prompted that it belongs to a class. What I see is a C function pointer list (static device_method_t). And when I access a context-specific variable in a member function, I must write variable name sc-XXX after obtain the context pointer. What's more, can the object model function really as OpenDarwin's IOKit class model? Does it need to? He's trying to port IOKit to FreeBSD for his exercise (if you had read his first e-mail you'd know that). You're somewhat right. Now, I would only submit some MINOR patches to FreeBSD, only to sweep out some conflicts against C++ language. These patches are also irrelevant to C++ runtime library. There patches do ABSOLUTELY NO HARM to current FreeBSD kernel. Before I do enough experiments, naturally I would never talk about this thing. I don't know why Dag-Erling C. Smo/rgrav is so unfriendly to me ??? !!! Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. Please provide references to the PRs you filed about these issues. USB crashes are not that uncommon, and compared to other OS's (such as Windows and OS X both of which I've written a PCI driver for) we require device driver writers to go through a lot more hoops to do certain things like allocate resources. At the very least there is much that can be improved in our driver model. If manufactures would write FreeBSD driver itself, they must do their best, just as NVIDIA. We should provide a good kernel environment for them. But now some FreeBSD drivers by volunteers, even expert at FreeBSD, are somewhat rough. -- John Baldwin From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
John Baldwin [EMAIL PROTECTED] writes: On Tuesday 11 July 2006 10:57, Dag-Erling Smørgrav wrote: [EMAIL PROTECTED] writes: What's more, can the object model function really as OpenDarwin's IOKit class model? Does it need to? He's trying to port IOKit to FreeBSD for his exercise (if you had read his first e-mail you'd know that). I saw no such thing in his first email, nor in any of his subsequent messages; all I see is variations on FreeBSD sucks, but luckily for you I'm here to tell you how to fix it which is not going to fly. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Joerg Sonnenberger wrote: On Tue, Jul 11, 2006 at 10:45:52PM +0800, [EMAIL PROTECTED] wrote: Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. RTTI, allocation, exceptions and static allocators all add complexity for the runtime library. If you really want to use C++ for a kernel, you must likely want to use all of them as well. For example, I think C++ exception handling is really poorly suited for low-level code. Bullshit. With a proper implementation exceptions add no overhead as long an exception is not thrown in terms of speed. It does matter somewhat in terms of code (or better: data) size, but the very same information is useful to generate much better tracebacks as well. RTTI is highly useful for debugging and semi-optional consistent checks, which should not be neglected either. I don't care about the abuse of explicitly comparing object types etc., but the ability to decide what exactly a certain object is. Aside from the complexity of C++ exception support, in FreeBSD kernel, every exception must be carefully processed, simple exception throw and catch may lay memory leak and resource non-freeing inside kernel if the programmer fails to pay enough attention. Even if C++ code is carefully written for FreeBSD kernel, outer exception catch is so difficult to help deep inner exception. But the object model is still obscure to understand no matter how many people all over the world master C++. What's more, can the object model function really as OpenDarwin's IOKit class model? (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) The kobj implementation has the same feature set as a lightweight C++, e.g. inheritance and virtual functions. That's basically what IOKit is using as well. It is not obscure, just a Domain Specific Language. A domain specific language, C function pointer list, software context and other independent kernel functions are obscure enough for FreeBSD newbies. Now, OpenDarwin has owned a C++-based kernel object model. But why cannot FreeBSD? Because the kernel is C and not many points to incrementally add C++ have been made, which makes it a worthwhile goal. And if you want to complain about redundancy in drivers, carefully look for differences which often far outweight the common functionality. If there's only small differences, there operations can be packed into a function tunable by some arguments. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Dag-Erling [iso-8859-1] Sm grav wrote: John Baldwin [EMAIL PROTECTED] writes: On Tuesday 11 July 2006 10:57, Dag-Erling Sm grav wrote: [EMAIL PROTECTED] writes: What's more, can the object model function really as OpenDarwin's IOKit class model? Does it need to? He's trying to port IOKit to FreeBSD for his exercise (if you had read his first e-mail you'd know that). I saw no such thing in his first email, nor in any of his subsequent messages; all I see is variations on FreeBSD sucks, but luckily for you I'm here to tell you how to fix it which is not going to fly. DES -- Dag-Erling Sm grav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Can you mistake my meaning even if you haven't seen my previous messages? Have you any evidence besides your assumption to prove that I did as you said? From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Why do you all consider importing C++ code to FreeBSD kernel to be so complicated at the beginning? Matthias Andree wrote: (please don't Cc me on list replies; chopping down the Cc list) On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote: Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. But what's the point of C++ if it is mutilated below minimum standard compliance levels so that you can no longer call it C++? This discussion has been through for other systems such as Linux long ago, and it wasn't lack of manpower, but lack of technical feasibility, or in other words, what was still useful for a kernel wasn't that much different from C any more. C99 already adressed several concerns of C89, and ISTR that FreeBSD kernels are C99 code these days. We can judge whether a C++ feature can or cannot be imported into FreeBSD kernel by assemble code generated by GNU CC. Great, make the whole kernel depend on compiler internals. Can you imagine a single vendor who'd have interest in hauling so many dependencies into their software and handle all the support? I can't. Please complain about the portability of runtime library after reading codes in /usr/src/contrib/libstdc++/libsupc++/. Are they really so difficult to port? Write a C stub and put the rest into userspace where C++ works. For example, I think C++ exception handling is really poorly suited for low-level code. Which chops off one of C++'s legs to stand on. Aside from the complexity of implementing C++ exception, in kernel, every exception must be carefully processed. A simple exception throw may lay memory leak and unfreed resource allocation. And outer exception catch is difficult to help inner exception. Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT) with Linux and plugged TWO devices into it and see Linux fail to talk to the device you plugged in later? No? If so, you have zero clue how bad USB support can get. And that's not the only problem Linux USB has had or still has. Actually, what I would talk about is Microsoft Windows 2000/XP. We should ignore Microsoft's superiority just because we love FreeBSD. Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI device drivers repeat: pci_read_config( ... ) ... sc-vr_res = bus_alloc_resource_any( ... ); ... sc-vr_irq = bus_alloc_resource_any( ... ); ... Is this kind of awful writing just of FreeBSD's style? In contrast, with C++, we can avoid many code repeating among device drivers. How would C++ avoid such? Generic programming, RTTI support and such stuff requires an awful lot of compile-time code generation and runtime library support. Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkits? Good packages for various APIs are much easier to learn/debug than those original APIs. If we would have constructed an object model in C++, a programmer who master Microsoft MFC, Darwin I/O Kit could easily write a device drive with the device's hardware data sheet. And errata, and talking to the device happens in C-like programming anyways... -- Matthias Andree From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : and OS X both of which I've written a PCI driver for) we require device : driver writers to go through a lot more hoops to do certain things like : allocate resources. At the very least there is much that can be improved in : our driver model. bus_alloc_resources goes a long ways in this respect. Yes, but in OS X I didn't even have to do that. All I had to do was ask it to map a BAR if I wanted to use it. It already allocated all the resources regardless. Windows was the same way (though a bit weirder, you get a message that lists all your resources and you have to map them if you want to use them). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : John Baldwin [EMAIL PROTECTED] writes: : : and OS X both of which I've written a PCI driver for) we require device : : driver writers to go through a lot more hoops to do certain things like : : allocate resources. At the very least there is much that can be improved : in : : our driver model. : : bus_alloc_resources goes a long ways in this respect. : : Yes, but in OS X I didn't even have to do that. All I had to do was ask it to : map a BAR if I wanted to use it. It already allocated all the resources : regardless. Windows was the same way (though a bit weirder, you get a : message that lists all your resources and you have to map them if you want to : use them). What's the difference in asking for a resource to be mapped, and calling a routine that allocates and maps the resource? Also, in FreeBSD, the resources are already allocated by the bus code. It just changes ownership to the child when the request comes in... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Intel Vanderpool (VT) on FreeBSD or FreeBSD Xen
Dear All, Does anybody succeed to boot FreeBSD on an Intel Vanderpool capable machine? My colleague tried it and the result is a BTX halt as can be seen on the screenshots on page linked. He successfully run unmodified Linux, Windows 2003 under Xen virtual machines, but FreeBSD failed in the boot phase. http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd.png http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd2.png By the way what is the state of Xen port of FreeBSD? I already asked these questions on FreeBSD-stable but no answers... Thanks, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
At 12:43 AM +0800 7/12/06, [EMAIL PROTECTED] wrote: Before I do enough experiments, naturally I would never talk about this thing. I don't know why Dag-Erling C. Smo/rgrav is so unfriendly to me ??? !!! He is commenting on your patches. Do not take those as personal attacks on you. You seem to be assuming that no one here has worked with C++, but that is not true. Some previous C++ experiments did not go well, so it might seem that we are quick to put down you want to do. It's not really that we're hostile to you, it is just that we want to go slow enough with any major change, to make sure we know what is going on. (me, I don't know enough about C++ to comment on your changes. I'm just saying that objections to your updates do not mean anyone is mad at you personally) -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel Vanderpool (VT) on FreeBSD or FreeBSD Xen
I asked the person who wrote vtxassist (only SVM supports paged real mode) - he thinks that it broke when support for big real mode was added. He did not seem particularly inclined to fix it. It may be that Xen's VT-x support is considered less interesting to his organization now that VMware is free (as in beer). -Kip On 7/11/06, Mohacsi Janos [EMAIL PROTECTED] wrote: Dear All, Does anybody succeed to boot FreeBSD on an Intel Vanderpool capable machine? My colleague tried it and the result is a BTX halt as can be seen on the screenshots on page linked. He successfully run unmodified Linux, Windows 2003 under Xen virtual machines, but FreeBSD failed in the boot phase. http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd.png http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd2.png By the way what is the state of Xen port of FreeBSD? I already asked these questions on FreeBSD-stable but no answers... Thanks, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
On Tuesday 11 July 2006 15:21, [EMAIL PROTECTED] wrote: John Baldwin wrote: On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : and OS X both of which I've written a PCI driver for) we require device : driver writers to go through a lot more hoops to do certain things like : allocate resources. At the very least there is much that can be improved in : our driver model. bus_alloc_resources goes a long ways in this respect. Yes, but in OS X I didn't even have to do that. All I had to do was ask it to map a BAR if I wanted to use it. It already allocated all the resources regardless. Windows was the same way (though a bit weirder, you get a message that lists all your resources and you have to map them if you want to use them). -- John Baldwin Do you mean that the kernel pre-allocate resources for all devices whether a device has been attached by a device driver? Does BIOS do the same thing before OS boots? Maybe (kernel can allocate it once probe has succeeded perhaps, or just always do it) and Yes (if PNP OS is set to No, that is what PNP OS means, is if the OS is smart enough to alloc the resources on its own). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
On Tuesday 11 July 2006 14:48, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : John Baldwin [EMAIL PROTECTED] writes: : : and OS X both of which I've written a PCI driver for) we require device : : driver writers to go through a lot more hoops to do certain things like : : allocate resources. At the very least there is much that can be improved : in : : our driver model. : : bus_alloc_resources goes a long ways in this respect. : : Yes, but in OS X I didn't even have to do that. All I had to do was ask it to : map a BAR if I wanted to use it. It already allocated all the resources : regardless. Windows was the same way (though a bit weirder, you get a : message that lists all your resources and you have to map them if you want to : use them). What's the difference in asking for a resource to be mapped, and calling a routine that allocates and maps the resource? It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's no separate bus_alloc_resource/bus_setup_intr for interrupts though for example, just bus_setup_intr() equivalent. This is pretty simple though: /* OS X */ IOMemoryMap *myBarMap; void *myBar; u_int32_t reg; /* BAR 0 */ myBarMap = provider-mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); myBar = myBarMap-getVirtualAddress(); reg = OSReadLittleInt32(myBar, FOO_REG); reg |= BAR_FLAG; OSWriteLittleIntew(myBar, FOO_REG, reg); myBar-release(); In FreeBSD-7 this is something like: struct resource *res; int rid; u_int32_t reg; rid = PCIR_BAR(0); res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, rid, RF_ACTIVE); /* XXX: Not sure about endian.. stream_read maybe? */ reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, SYS_RES_MEMORY, rid, res); Which is very similar though there is some clutter (bus_release_resource() should take fewer args, like just dev and res, and it would be nice to say something like map_bar(dev, PCIR_BAR(0)) and get back a resource *). Older FreeBSD looks like this: struct resource *res; bus_space_tag_t tag; bus_space_handle_t hnd; int rid; u_int32_t reg; rid = 0x10; res = bus_alloc_resource(dev, SYS_RES_MEMORY, rid, 0ul, ~0ul, 1, RF_ACTIVE); tag = rman_get_bustag(res); hnd = rman_get_bushandle(res); reg = bus_space_read_4(tag, hnd, FOO_REG); reg |= BAR_FLAG; bus_space_write_4(tag, hnd, FOO_REG, reg); bus_release_resource(dev, SYS_RES_MEMORY, rid, res); Usually drivers come up with macros to hide the bus handles and tags which is an indication that they were quite unsightly (thankfully that's been fixed in 7). :) I don't recall the Windows syntax off the top of my head. Note though that what verboseness there is in the OS X case comes from the really long and descriptive function names. Shorter function names would make it far more compact. Both Windows and OS X also allow you to only submap part of a bar if you want, and to specify the caching mode (UC, WC, WB, WT, etc.) when you map the bar. Oh, and just because I'm on my soapbox, on OS X you can mmap device memory (or any sort of malloc'd memory) _really_ easily in userland using an arbitrary mapping type, because their mmap-type operation (clientForMemoryType on an IOUserClient) just asks the device driver to provide an IOMemoryMap (which describes the backing physical addresses along with the cache mode etc.) and then takes care of mapping that into UVA, but I digress on that point. Anyways, if you took FreeBSD-7 and cut down some of the gunk similar to OS X you'd have something like: struct resource *res; u_int32_t reg; res = pci_alloc_bar(dev, PCIR_BAR(0)); /* XXX: endian question again */ reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, res); Which is at least somewhat better I think. Also, in FreeBSD, the resources are already allocated by the bus code. It just changes ownership to the child when the request comes in... Yes, this has been a recent improvement. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's no separate bus_alloc_resource/bus_setup_intr for interrupts though for example, just bus_setup_intr() equivalent. This is pretty simple though: /* OS X */ IOMemoryMap *myBarMap; void *myBar; u_int32_t reg; /* BAR 0 */ myBarMap = provider-mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); myBar = myBarMap-getVirtualAddress(); reg = OSReadLittleInt32(myBar, FOO_REG); reg |= BAR_FLAG; OSWriteLittleIntew(myBar, FOO_REG, reg); myBar-release(); In FreeBSD-7 this is something like: struct resource *res; int rid; u_int32_t reg; uint32_t is the standards compliant spelling :-) rid = PCIR_BAR(0); res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, rid, RF_ACTIVE); The above should be shortenable to: res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE); because we don't need to have rid be a pointer. /* XXX: Not sure about endian.. stream_read maybe? */ no. bus_read is correct, because the pci bus is little endian by definition. bus_stream_read will read/write from native endian to bus endian. reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, SYS_RES_MEMORY, rid, res); We should be able to shorten that to: bus_release_resource(dev, res); these days. Which is very similar though there is some clutter (bus_release_resource() should take fewer args, like just dev and res, and it would be nice to say something like map_bar(dev, PCIR_BAR(0)) and get back a resource *). Agreed. If you have mutliple resources, you can stack them up as well. Usually drivers come up with macros to hide the bus handles and tags which is an indication that they were quite unsightly (thankfully that's been fixed in 7). :) I usually do: #define RD4(sc, r) bus_read_4(sc-res, (r)) #define WR4(sc, r, v) bus_write_4(sc-res, (r), (v)) which makes usage even shorter. It also helps me hid cross-version differences... Anyways, if you took FreeBSD-7 and cut down some of the gunk similar to OS X you'd have something like: struct resource *res; u_int32_t reg; res = pci_alloc_bar(dev, PCIR_BAR(0)); /* XXX: endian question again */ reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, res); Which is at least somewhat better I think. In the case where you don't care what kind of mapping you get, that would work great. It wouldn't be too hard to implement a pci_alloc_bar that does the default allocation and mapping. Changing some of the other APIs would be more difficult... Also, in FreeBSD, the resources are already allocated by the bus code. It just changes ownership to the child when the request comes in... Yes, this has been a recent improvement. Yes. We also do it in a lazy way so that if the resource is allocated or not is transparent to the driver and the system. If it could be decoded, we reserve it. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : Why do you all consider importing C++ code to FreeBSD kernel to be so : complicated at the beginning? Many people reading this list have conducted experiments in the past at various employers. Everyone who has conducted the experiments reports that the 'trivial' parts of C++ are trivial to do in the kernel. new/delete support is easy. Subclassing is easy, so long as it is single inheritance. Some limited template support is possible. Exceptions can be made to be not too bad, but at the expense of much of the exception functionality. If you look at the number of weasil words I used here to describe the functionality, you'll see that the 'easy' parts of C++ aren't a very large subset of the entire language, and many would argue aren't a useful enough subset to be worth the efforts to clean up the code and make it production quality. However, C++ has so many standard libraries and interfaces that importing them into the kernel is a daunting task. STL is right out, for example, as are the insertion and extraction operators. Also, g++ has traditionally produced worse code for C++ than for C, even when the source is identical. This stems mainly from subtle differences in the semantics of the two languages. This was true in 2.3 times, in 2.4 times, and is still true with 3.4.4 that we have in current, although a few simple tests indicates that things have gotten much better. Basically, people here have tried it in the past and given up. They are very leery of any changes in this direction, and need some sort of proof to be convinced otherwise. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Tuesday 11 July 2006 15:21, [EMAIL PROTECTED] wrote: : John Baldwin wrote: : : On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : John Baldwin [EMAIL PROTECTED] writes: : : and OS X both of which I've written a PCI driver for) we require device : : driver writers to go through a lot more hoops to do certain things like : : allocate resources. At the very least there is much that can be : improved : in : : our driver model. : : bus_alloc_resources goes a long ways in this respect. : : Yes, but in OS X I didn't even have to do that. All I had to do was ask : it to : map a BAR if I wanted to use it. It already allocated all the resources : regardless. Windows was the same way (though a bit weirder, you get a : message that lists all your resources and you have to map them if you want : to : use them). : : -- : John Baldwin : : Do you mean that the kernel pre-allocate resources for all devices whether : a device has been attached by a device driver? : Does BIOS do the same thing before OS boots? : : Maybe (kernel can allocate it once probe has succeeded perhaps, or just always : do it) and Yes (if PNP OS is set to No, that is what PNP OS means, is if the : OS is smart enough to alloc the resources on its own). For FreeBSD, the kernel pre-allocates all resources that the BIOS allocated in the pci bus. We then give them out to the driver as the driver requests them. If the driver requests a resource that hasn't been pre-allocated, FreeBSD will attempt to allocate then and there that resource, and if successful return it. Generally, PnPOS == no means 'allocate everything you possibly can for these devices' while PnPOS == yes means 'allocate just enough to boot and leave the rest to the OS'. FreeBSD copes with both settings, as well as really old BIOSes that always allocated and new ones where you can't set PnPOS to no. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
2006/7/11, [EMAIL PROTECTED] [EMAIL PROTECTED]: Why do you all consider importing C++ code to FreeBSD kernel to be so complicated at the beginning? Matthias Andree wrote: (please don't Cc me on list replies; chopping down the Cc list) On Tue, 11 Jul 2006, [EMAIL PROTECTED] wrote: Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. But what's the point of C++ if it is mutilated below minimum standard compliance levels so that you can no longer call it C++? This discussion has been through for other systems such as Linux long ago, and it wasn't lack of manpower, but lack of technical feasibility, or in other words, what was still useful for a kernel wasn't that much different from C any more. C99 already adressed several concerns of C89, and ISTR that FreeBSD kernels are C99 code these days. We can judge whether a C++ feature can or cannot be imported into FreeBSD kernel by assemble code generated by GNU CC. Great, make the whole kernel depend on compiler internals. Can you imagine a single vendor who'd have interest in hauling so many dependencies into their software and handle all the support? I can't. Please complain about the portability of runtime library after reading codes in /usr/src/contrib/libstdc++/libsupc++/. Are they really so difficult to port? Write a C stub and put the rest into userspace where C++ works. For example, I think C++ exception handling is really poorly suited for low-level code. Which chops off one of C++'s legs to stand on. Aside from the complexity of implementing C++ exception, in kernel, every exception must be carefully processed. A simple exception throw may lay memory leak and unfreed resource allocation. And outer exception catch is difficult to help inner exception. Even if I have no proof-of-concepts (so maybe somebody can show that this is not fair), if we have setjmp/longjmp in the kernel we can have a correct exception handling mechanism without not great problems. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Status Report Second Quarter 2006
April-June 2006 Status Report Introduction With the release of FreeBSD 5.5 and FreeBSD 6.1, the second quarter of 2006 has been productive. Google is sponsoring 14 students to work on FreeBSD as part of their Summer of Code Program (most of which already submitted a report for elaboration on their projects). Sun's open-source software is starting to make its way into FreeBSD as a port of DTrace is nearing completion and a port to the UltraSparc T1 processor (which gives a great push to the ongoing SMP efforts). Having a powerful debugging tool combined with a CPU that can run up to 32 concurrent threads helps to identify scalability issues. BSDCan 2006 was yet again a smashing success and much was covered in the 2-day developer summit. As a product of the conference, a new focus on FreeBSD for the embedded sector has started. Various ARM boards are targeted, a MIPS32 port is gearing up and people are looking for other interesting platforms to port FreeBSD to. Preparation for the EuroBSDCon (in Milan, Italy) on November has already issued a call for papers. In addition, a lot of spring cleaning is taking place in the network stack. After conclusion of the KAME project, IPv6 code integration has been refocused and a fully locked port of SCTP is in the final stage of integration. Of course, all this goes without noting all the progress made with the other network projects. Please read below for more detailed news on the projects that happened in FreeBSD during the last three months. If you are interested in helping, consider the Open Tasks lists provided with some reports. In addition we would like to point you at the list of projects and ideas for volunteers and hope to receive a status report from you next time. Thanks to all reporters for your excellent work and timing!. Enjoy reading. _ Google summer of code * BSNMP Bridge module * gvirstor * Improving Ports Collection * Interrupt handling * IPv6 Vulnerabilities * Jail Resource Limits * K Kernel Meta-Language * Linuxolator kernel update to match functionality of 2.6.x * Nss-LDAP importing and nsswitch subsystem improvement Projects * DTrace * Embedded FreeBSD * TrustedBSD Audit Network infrastructure * FAST_IPSEC Upgrade * FreeBSD NFS Status Report * IPv6 cleanup * Multi-IP v4/v6 jails * SCTP Integration * Wireless Networking Kernel * Giant-Less UFS with Quotas * Giant-Less USB framework * GJournal * Gvinum improvements * Sound subsystem improvements * SSE2 Kernel support * XFS for FreeBSD Documentation * FreeBSD list of projects and ideas for volunteers * Hungarian translation of the webpages Userland programs * Low-overhead performance monitoring tools Architectures * PowerPC Port Ports * FreshPorts * Ports Collection * Update of the Linux userland infrastructure in the Ports Collection Vendor / 3rd Party Software * BSDInstaller * pfSense * xscale board buy Miscellaneous * BSDCan * EuroBSDCon 2006 - November 10th - 12th, Milan, Italy * FreeBSD Security Officer and Security Team * Release Engineering _ BSDCan URL: http://www.bsdcan.org/ Contact: Dan Langille [EMAIL PROTECTED] BSDCan 2006 continues to impress. Again this year, we had a good collection of talks from a wide range of speakers. In all, we had over 200 people from 14 different countries. Our sponsorship pool continues to grow. This year we had sponsorship from: * USENIX * The FreeBSD Foundation * PARSE * iXsystems * O'Reilly * Stevens Institute of Technology * nCircle The t-shirts were very popular, with all of them going in very short time. Of course, it helped that this year they were free, courtesy of PARSE. The 2007 planning has already begun and we look forward to another popular and successful event. My thanks to the 2006 program committee, the speakers, the volunteers, the sponsors, and, of course, the attendees. See you at BSDCan 2007. _ BSDInstaller URL: http://wikitest.freebsd.org/moin.cgi/BSDInstaller Contact: Andrew Turner [EMAIL PROTECTED] Since the last status report ports have been created for all parts of the BSDInstaller except the backend. A snapshot of the BSDInstaller was released during this quarter. This has shown a number of bugs with the installation process. Most have now been fixed. _ BSNMP Bridge module URL:
Re: kern/99979: Get Ready for Kernel Module in C++
On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote: Matthias Andree wrote: Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Because they like buggy code? (Not that the basic API is much better) Why is gtkmm created for GTK+? Because they enjoy extremely long compile times? And they like wrappers around wrappers around wrappers? Would you write a X11 application with original X11 API, without QT or other X11 toolkits? Comparing KDE/Qt to GNOME/GTK+ is comparing C++ to C. I personally prefer the GTK API (GDK is quite similar to the X11 API) over Qt. My preference is mostly due to the overhead and complexity of C++. C++ and Java are great for Applications, not as much so for kernels. I don't mean to drag this into a KDE vs. GNOME flame war. Also this is not a fair comparison because these toolkits augment what X11 provides, much like how userland augments a kernel. Write the front-end in whatever language/toolkit you prefer; you're still calling Xlib to pass packets to/from the X server. Good packages for various APIs are much easier to learn/debug than those original APIs. What makes you say that C++ would provide a good API? I think perhaps the problem may be that the current kernel APIs in C are insufficient... but introducing the complexity of C++ both from a language perspective and from a standard library perspective seems silly to me. When on the device driver level, I would rather know precisely when my code is being called and manage my own memory, etc. and other nitty-gritty details. I agree that a good API is crucial! But I also believe that C provides this better than others. You can always write code in C++ which calls C functions, but the converse is quite tricky. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote: Good packages for various APIs are much easier to learn/debug than those original APIs. What makes you say that C++ would provide a good API? Good point. About the only thing C++ has going for it as an OO language is popularity. If the goal is just to provide better API in the kernel, then there are certainly better languages to add. D comes to mind. I'd much rather write D than C++ - but that's got more to do with C++ than D, as it's true for most substitutes for D. But D is OO - done much better than C++ - and has a front end available for GCC. It may not be a good choice, as I haven't looked at it seriously. But I certainly wouldn't start trying to improve the FreeBDS kernel by adding support for a new language without doing so. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
M. Warner Losh wrote: In message: [EMAIL PROTECTED] V lav Haisman [EMAIL PROTECTED] writes: : Deciding that some features are bad beforehand, before you evaluate them : is IMO bad idea. Let interested people write a bunch of C++ modules with : the complete language before deciding on what shouldn't be used. There's actually a fair amount of experience with people doing C++ in FreeBSD kernels. People have been doing things with it for about 8 years now. There are significant performance issues with even C code compiled as C++. It is possible to write fast C++ for kernel work, but it is also very easy to write really bad C++ for kernel work. Easier than bad C code. Currently, GNU CC has made great advance in binary code execution efficiency. And Intel C++ Compiler is also an excellent one. We can evaluate them by assemble code generated by them. I would repeat several sentences in my last reply. Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm framework created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkit? I believe the answer is that all programmers are human begins, not machines. Human programmer would reduce brainwork, even if an API package/wrapper slightly reduces running efficiency. There's reasons that people here are somewhat skeptical about using C++ in the kernel. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
John Baldwin wrote: On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : and OS X both of which I've written a PCI driver for) we require device : driver writers to go through a lot more hoops to do certain things like : allocate resources. At the very least there is much that can be improved in : our driver model. bus_alloc_resources goes a long ways in this respect. Yes, but in OS X I didn't even have to do that. All I had to do was ask it to map a BAR if I wanted to use it. It already allocated all the resources regardless. Windows was the same way (though a bit weirder, you get a message that lists all your resources and you have to map them if you want to use them). -- John Baldwin Do you mean that the kernel pre-allocate resources for all devices whether a device has been attached by a device driver? Does BIOS do the same thing before OS boots? From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
FWIW and just IMHO; I think it would be really nice to have the IOKit, or a lookalike that uses kobj(), available on FreeBSD. Another interesting experiment that I've mentioned before is OpenBFS: http://www.bug-br.org.br/openbfs/index.phtml?section=development OpenBFS, as all file systems under BeOS, is being developed as a kernel add-on. Unlike all other file systems (and kernel add-ons in general), it is being developed in C++. Contrary to popular belief, it is possible to use C++ in the kernel provided you play by the book and follow some rules: - No exceptions - (Almost) no virtuals (well, the Query code in OpenBFS uses them) - It's basically only the C++ syntax, and type checking - Since one tend to encapsulate everything in classes, it has a slightly higher memory overhead This is acceptable as we get some benefits out of it: - Nicer code - Easier to maintain cheers, Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
At 7:03 PM -0400 7/11/06, Mike Meyer wrote: In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote: Good packages for various APIs are much easier to learn/debug than those original APIs. What makes you say that C++ would provide a good API? Good point. About the only thing C++ has going for it as an OO language is popularity. If the goal is just to provide better API in the kernel, then there are certainly better languages to add. D comes to mind. I'd much rather write D than C++ - but that's got more to do with C++ than D, as it's true for most substitutes for D. But D is OO - done much better than C++ - and has a front end available for GCC. This would be an interesting idea. I haven't used D for anything myself, but some friends of mine have and think that it is quite good. They say the available libraries are still a little thin in what they implement, but maybe it'd be better to start with some kind of thin environment, and see how that works out. I guess that wouldn't help out much with supporting IOKit, though, if IOKit is already written using C++. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote: I would repeat several sentences in my last reply. Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm framework created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkit? I believe the answer is that all programmers are human begins, not machines. Human programmer would reduce brainwork, even if an API package/wrapper slightly reduces running efficiency. And this is why office 2003 takes longer to load on a 2.4ghz machine then office 97 did on a 233. I don't think that is a comparison you can safely make and retain any creditability. If you want to keep the changes you made in a local tree or a p4 tree or whatever, and show us we're all wrong when you're done, thats fine. But expecting committers to drop your code into the tree for such a purpose is silly. Jason -- Jason Slagle /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Jason Slagle wrote: On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote: I would repeat several sentences in my last reply. Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm framework created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkit? I believe the answer is that all programmers are human begins, not machines. Human programmer would reduce brainwork, even if an API package/wrapper slightly reduces running efficiency. And this is why office 2003 takes longer to load on a 2.4ghz machine then office 97 did on a 233. I don't think that is a comparison you can safely make and retain any creditability. If you want to keep the changes you made in a local tree or a p4 tree or whatever, and show us we're all wrong when you're done, thats fine. But expecting committers to drop your code into the tree for such a purpose is silly. Jason -- Jason Slagle /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Why don't you say that Office 2003 is more powerful than Office 97? We are discussing C++ and other object-oriented encapsulation for kernel module here. If you want to complain that your Office 2003 is slower than Office 97, please leave your grouse for Microsoft technical support staff. You even haven't known what we are discussing and what I would commit. Actually my patches has little relationship to C++. Read previous mails first before your great speech here! From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
Jason Slagle wrote: On Wed, 12 Jul 2006, [EMAIL PROTECTED] wrote: I would repeat several sentences in my last reply. Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm framework created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkit? I believe the answer is that all programmers are human begins, not machines. Human programmer would reduce brainwork, even if an API package/wrapper slightly reduces running efficiency. And this is why office 2003 takes longer to load on a 2.4ghz machine then office 97 did on a 233. I don't think that is a comparison you can safely make and retain any creditability. If you want to keep the changes you made in a local tree or a p4 tree or whatever, and show us we're all wrong when you're done, thats fine. But expecting committers to drop your code into the tree for such a purpose is silly. Jason -- Jason Slagle /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Why don't you say that Office 2003 is more powerful than Office 97? We are discussing C++ and other object-oriented encapsulation for kernel module here. If you want to complain that your Office 2003 is slower than Office 97, please leave your grouse for Microsoft technical support staff. You even haven't known what we are discussing and what I would commit. Actually my patches has little relationship to C++. Read previous mails first before your great speech here! From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
