subject:"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 Thread Xin LI

在 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++

2006-07-11 Thread Matthias Andree

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: 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++

2006-07-11 Thread Joerg Sonnenberger

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++

2006-07-11 Thread Matthias Andree

(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]

Re: kern/99979: Get Ready for Kernel Module in C++

2006-07-11 Thread Garance A Drosehn


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: 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++

2006-07-11 Thread Warner Losh

 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-07-11 Thread Attilio Rao


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]

Re: kern/99979: Get Ready for Kernel Module in C++

2006-07-11 Thread Rick C. Petty

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++

2006-07-11 Thread Mike Meyer

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++

2006-07-11 Thread pfgshield-freebsd

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++

2006-07-11 Thread Garance A Drosihn


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++

2006-07-11 Thread Jason Slagle


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++

2006-07-11 Thread Intron


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++