Linux-Development-Sys Digest #357, Volume #8     Mon, 18 Dec 00 04:13:11 EST

Contents:
  Problems with C++ in Kernel Module (Rui Antunes)
  Re: slow asymmetric half-duplex communication (ADSL)
  Re: Compiling C++ programs with GCC --> no GPL license implications (John Hasler)
  Kernel panic on installation ("Ed Collins")
  Re: Problems with C++ in Kernel Module ([EMAIL PROTECTED])
  what is ld-linux.so.2? ("�̿���")
  Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
  transfer files through RS232 ("Delcan")
  New Linux Distro ("xxxx")
  Re: how to use raw device (Josef Moellers)
  Re: Kernel panic on installation (Josef Moellers)
  Re: transfer files through RS232 (Josef Moellers)
  Signal handling (Thomas Petazzoni)
  Re: what is ld-linux.so.2? (Thomas Petazzoni)
  Re: Problems with C++ in Kernel Module ("O.Petzold")
  Re: what is ld-linux.so.2? (Michael Kerrisk)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Rui Antunes)
Crossposted-To: comp.os.linux.help
Subject: Problems with C++ in Kernel Module
Date: Mon, 18 Dec 2000 01:10:09 GMT

        I'm developping a Linux Kernel Module (LKM) for 2.2.16. Some of
the files are in C++ (and the rest are in C).

        My Makefile looks something like this:


        KFLAGS = -D__KERNEL__ -DMODULE -I/usr/src/linux/include
        # Module
        tmpmod.o: mainmod.o cipher.o
                $(LD) -r $^ -o $@
        # Main stuff (init_module, ...) in C
        mainmod.o: mainmod.c
                $(CC) $(KFLAGS) -c -o $@ $+
        # Cipher stuff in C++
        cipher.o: cipher.cc
                $(CC) $(KFLAGS) -c -o $@ $+


        When I run "make" everything goes wll (apparently) - it compiles
and links without warnings or errors - but when I insmod it the
following errors are displayed:
        unresolved symbol __builtin_delete
        unresolved symbol __rtti_user
        unresolved symbol __pure_virtual

        I know these errors are due to the C++ code - I know that Linux
Kernel doesn't support C++ very well... But, is there any way to
overcome this errors?

        Also, I can not include<linux/malloc.h> in  bcipher.cc because
<linux/malloc.h> includes <linux/list.h> which declares a variable
with the name new --the C++ compiler returns an error probably because
it confuses it with the new() function; also it returns an error when
including <linux/signal.h> just because it has a switch() that in one
of the case: there is no instruction...
        It all happens even though I do:
        #ifdef __cplusplus
        extern "C" {
        #endif
     #include <linux/malloc.h>
        #ifdef __cplusplus
     }
        #endif
Why?!?

        Is it a good idea to use C++ in the kernel (I don't use exceptions
nor anything too powerful)      ? Alright, probably it isn't. But is it
possible (if the C++ code is relatively simple)?

                Thanks in advance,
                                                                                Rui 
Antunes

------------------------------

From: [EMAIL PROTECTED] ()
Crossposted-To: linux.dev.kernel
Subject: Re: slow asymmetric half-duplex communication (ADSL)
Date: Mon, 18 Dec 2000 01:44:55 -0000

In article <XSdZ5.107$[EMAIL PROTECTED]>,
Michael Buro  <"mic"@(NO SPAM!)verizon.net> wrote:

>I recently got an ADSL connection (640kbaud down, 90kbaud up,
>PPPoE). Installation went well, but a simultaneous upload &
>download revealed that the download speed suffers big time
>when uploading takes place at the same time (total speed <
>120kbaud).

That's normal.

>I later learned that ADSL is indeed using a
>half-duplex protocol! I could't believe it.

You shouldn't believe it because it isn't true.  The downloads slow 
down because the TCP ack's aren't getting through quickly enough.  

--
http://www.spinics.net/linux


------------------------------

From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Wed, 13 Dec 2000 14:06:46 GMT

jbs writes:
> If you are uncomfortable relying on their representations in email, then
> just wait for the next release. Or grab a developer snapshot which might
> well have incorporated the licensing correction already (or wait for one
> that does).

Or write directly to the copyright owner and ask that they grant you the
permissions you need.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

------------------------------

From: "Ed Collins" <[EMAIL PROTECTED]>
Subject: Kernel panic on installation
Date: Mon, 18 Dec 2000 04:01:14 GMT

Hello, there:

I just installed Linux on the d: drive on a 486DX.  I get the following
message and cannot proced further.

    Kernel panic:  VFS: Unable to mount root fs on 16:45


Does anyone know what the problem is?  I would certainly appreciate anyone's
help.

ed.



------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Problems with C++ in Kernel Module
Date: Mon, 18 Dec 2000 04:50:58 GMT

[EMAIL PROTECTED] (Rui Antunes) writes:
> I'm developping a Linux Kernel Module (LKM) for 2.2.16. Some of the
> files are in C++ (and the rest are in C).

"Some of the files are in C++" is the first indication of problems...

> When I run "make" everything goes wll (apparently) - it compiles and
> links without warnings or errors - but when I insmod it the
> following errors are displayed:
>       unresolved symbol __builtin_delete
>       unresolved symbol __rtti_user
>       unresolved symbol __pure_virtual
> 
> I know these errors are due to the C++ code - I know that Linux
> Kernel doesn't support C++ very well... But, is there any way to
> overcome this errors?

Realistically?  Not particularly.  The C++ runtime environment is not
implemented as part of the Linux kernel, so that you will have to
implement anything you need yourself.

> Is it a good idea to use C++ in the kernel (I don't use exceptions
> nor anything too powerful) ? Alright, probably it isn't. But is it
> possible (if the C++ code is relatively simple)?

Linux is a kernel designed to be programmed in C; fighting against
that is likely to be more trouble than it's worth.

On the one hand, it might be attractive to organize data structures
using C++ classes; on the other, the _major_ enhancements that C++
offers, notably:
 - Automatic memory allocation
 - Exception handling
represent things that need considerable runtime support that are NOT
going to be included in the kernel.
-- 
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
"It has been said  that man is a rational animal.  All  my life I have
been searching for evidence which could support this."
-- Bertrand Russell

------------------------------

From: "�̿���" <[EMAIL PROTECTED]>
Subject: what is ld-linux.so.2?
Date: Mon, 18 Dec 2000 15:10:27 +0900

I have one question...

linux's "/lib" directory have ld-linux.so.2.

what is this?
what program use this?





------------------------------

Date: Mon, 18 Dec 2000 00:40:02 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86

Mea culpa, mea culpa, mea maxima culpa.

Linus is entirely correct about cache effects.  Additional code below 
shows it clearly.  I had hoped that Intel's "optimized string hardware"
would save the memory reads which just get overwritten.  Not so.

(Note to transistor peddlers:  Full cacheline writes are not rare in
code.  Add a cacheline write buffer which if completely filled cancels
the fill-in read.  This will save you some precious memory reads, 
especially with longer cachelines.  Or maybe you've got too much 
memory bandwidth and too little latency? :)

I will forego the customary nitpicky "shred it apart" defense where 
I object to Linus' wording or precise semantics.  Instead, I have made 
some comments others might find interesting:

Linus Torvalds wrote in small part
> 
> No.  What happens is that under Linux, most of those 12000 cycles are
> clearing memory that is not in the cache.  In particular, see above on
> the FreeBSD memset() numbers.  Of the Linux 12000 cycles, 90%+ is for
> the memset. The actual page fault handling etc takes on the order of
> 1000 cycles - a few hundred of this is the actual hardware cost on x86
> to take a page fault.

This is true.  I measure 11000 for a cold cache memset, and 1000 for
OS pagelist maintenance is very reasonable, especially considering
the hardware cost of `int/iret` [I once measured 241 IIRC]   
Linus, can I get a bare-naked `iret` in the IDT for Xmas? :)
and a null syscall too?  I get tired of using getpid.

> On FreeBSD, those 5000 cycles are just mapping in an already zeroed
> page. It looks to me like FreeBSD basically keeps most of the free
> page list zeroed at all times, which is why you can have even 1000 pages
> take a constant (fairly low) time for the mapping cost.

This is probably true, and then 5000 cycles for OS pagelist work
becomes highly questionable.  What are they doing???

>    Pre-zeroing makes the kernel profile look good, which is probably
>    what BSD's do it. What it doesn't show is that it generates all the
>    wrong behaviour for the cache: it means that the cache has long since
>    cooled down by the time the page is actually _used_. Look at the sum
>    of all numbers (which is basically doing the same thing), and FreeBSD
>    clearly loses to Linux.
 <snip> 
> You can obviously find cases where the pre-initialization actually does
> help: if you don't touch the pages after allocating them,
> pre-initialization is a clear win. It's easy to create these kinds of
> benchmarks, I just don't think they are very realistic.

This is a subtile and philosophical point.  It will all depend on what 
is done on that page.  If only a few numbers are written, then coldzero 
wins.  If the whole page is written relatively inefficiently (32bit
writes),
then hotzero wins.  But if the whole page is written efficiently, then
it
may make no difference.  Should be worth some more tests.  Just what
happens to most new pages?  Program work area? Load from disk?
 
> Anyway, I would suggest you improve your benchmark to more clearly state

Whoa!  I have to stop you there.  My code was a simple asm hack 
I would never call a "benchmark".  It is nothing but a simple test,
producing simple data that needs [much] interpretation.

> what it actually tests. I also would suggest that at least your
> benchmark actually shows that the FreeBSD approach sucks quite badly,
> and Linux comes out the clear winner here. You may want to create a
> benchmark that shows the reverse ;)

Your wish is my command, sire :)  "Show me the code!" -- 'Tis below!

It just runs the same code twice: first chewing through 4 MB, then
going back and revisiting the same 4 MB.  Caches should be drowned
by then and stone cold (read right-to-left):

                               usr  libc 2nd  1stWr                             
First pass Linux numbers are:  847   915  33  12000
second pass 2.4.0t8 numbers:   847 11000  33     33
FreeBSD 4.1 first pass        1030 11000  33   5000
FBSD 4.1 2nd pass (estimated) 1030 11000  33     33? 

The glibc bzero can be commented out, and then the user 
`rep stosl` takes 11000.  Clearly cache effects at work.

-- Robert

# bzerock 0.2 - Check block zero timing
# Copyright 2000 RJ Redelmeier  Licenced under GNU GPL 2.0
# compile:  gcc -s -o bzerock  bzerock.s
# outputs 4 numbers, all in CPU clocks:
#   user_bzero libc_bzero  second_write  first_write
# times taken in right-to-left order [cache effects]
# 
.globl main
main:
        call    work
        call    exit
work:
        call    work1
work1:
        movl    $1000, count
        movl    $buf, %edi
        addl    $4096, %edi
        andl    $-4096, %edi
again:
        xorl    %ebx, %ebx
        rdtsc
        xchgl   %ebx, %eax
        movl    %eax, (%edi)
        rdtsc
        subl    %ebx, %eax
        pushl   %eax

        xorl    %ebx, %ebx
        rdtsc
        xchgl   %ebx, %eax
        movl    %eax, 4(%edi)
        rdtsc
        subl    %ebx, %eax
        pushl   %eax

        xorl    %ebx, %ebx
        rdtsc
        pushl   %eax
        pushl   $4096
        pushl   %edi
        call    bzero
        addl    $8, %esp
        rdtsc
        popl    %ebx
        subl    %ebx, %eax
        pushl   %eax

        movl    $1024, %ecx
        xorl    %ebx, %ebx
        rdtsc
        xchgl   %ebx, %eax
        rep
        stosl
        rdtsc
        subl    %ebx, %eax
        pushl   %eax

        pushl   $fmt
        call    printf
        addl    $20, %esp
        decl    count
        jnz     again
        ret     
.data
count:  .long   1000
fmt:    .asciz " %d  %d  %d  %d \n"
.bss
        .lcomm  buf, 4<<20
--

------------------------------

From: "Delcan" <[EMAIL PROTECTED]>
Subject: transfer files through RS232
Date: Mon, 18 Dec 2000 11:46:37 +0800

Hi

How can I continually to receive files(read-wait mode, and there are more
than one file to be received)?

tks




------------------------------

From: "xxxx" <[EMAIL PROTECTED]>
Subject: New Linux Distro
Date: Sun, 17 Dec 2000 09:19:09 +0200

Hello from Greece!

We are starting up a Project for a New Linux Distro, which will make use of
QT embeded version, and we are in need of developers with knowledge of C/C++
, Assembly , Hardware etc. We are also in need of web developers and mailing
list maintainers. This Distro will be probably based on a Version of KDE
which we want to compile under QTembed (KDE noX). This will be a desktop
oriented distro. Your help (and ideas) is very much welcome. Come on and
let's make a Fast , reliable, and easy Linux Distro

Dimitrios Koukoravas

Mail: [EMAIL PROTECTED]
Tel: [ask me for it :-) ]



------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,linux.dev.kernel
Subject: Re: how to use raw device
Date: Mon, 18 Dec 2000 08:45:29 +0100

Norman Dresner wrote:
> =

> Ronald Cole <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Josef Moellers <[EMAIL PROTECTED]> writes:
> > > ca depend, as the French use to say.
> > >
> > > It depends on which kernel version you use. 2.2 kernels don't have =
raw
> > > devices.
> >
>     What advantages does this give you?

Raw devices? Simply: a write to a raw device will write the data to the
device, not to a kernel buffer. Similarly a read from a raw device will
also not use kernel buffers, so if you e.g. wanted to copy a disk, you
could use raw devices and you wouldn't clobber your buffer cache.

As to databases: read Kaz' reply.
-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
        If failure had no penalty success would not be a prize (T.  Pratchett)

------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Kernel panic on installation
Date: Mon, 18 Dec 2000 08:52:30 +0100

Ed Collins wrote:
> =

> Hello, there:
> =

> I just installed Linux on the d: drive on a 486DX.  I get the following=

> message and cannot proced further.
> =

>     Kernel panic:  VFS: Unable to mount root fs on 16:45
> =

> Does anyone know what the problem is?  I would certainly appreciate any=
one's
> help.

Your setup does not load the device driver for the root disk's
controller/host adapter.
This may be due to the fact that you haven't run mkinitrd (or any of
it's relatives, depening on the distribution you're using).

But this is all guesswork. You haven't said what your disk
controller/host adapter is, what distribution you're trying to install
etc.

-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
        If failure had no penalty success would not be a prize (T.  Pratchett)

------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: transfer files through RS232
Date: Mon, 18 Dec 2000 08:55:21 +0100

Delcan wrote:
> =

> Hi
> =

> How can I continually to receive files(read-wait mode, and there are mo=
re
> than one file to be received)?

Please explain in more detail what you want to achieve.

A possible answer maight be to use a terminal emulator like minicom and
file transmission programs like rz and sz.

-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
        If failure had no penalty success would not be a prize (T.  Pratchett)

------------------------------

From: Thomas Petazzoni <[EMAIL PROTECTED]>
Subject: Signal handling
Date: Mon, 18 Dec 2000 09:17:21 +0100
Reply-To: [EMAIL PROTECTED]

Hi,

Yesterday, I was wondering where is the code for handling signals like
SIGKILL or SIGSEGV. You don't need to call explicitly signal() or
sigaction() to handle these signals. So where is the code to handle
these signals ?

That might be a stupid question, but i don't have the answer :)

Thx a lot.

thomas
-- 
PETAZZONI Thomas
[EMAIL PROTECTED]     ICQ : 34937744
[EMAIL PROTECTED]         http://kos.enix.org


------------------------------

From: Thomas Petazzoni <[EMAIL PROTECTED]>
Subject: Re: what is ld-linux.so.2?
Date: Mon, 18 Dec 2000 09:22:13 +0100
Reply-To: [EMAIL PROTECTED]

"�̿���" wrote:
> 
> I have one question...
> 
> linux's "/lib" directory have ld-linux.so.2.
> 
> what is this?
> what program use this?

this program is used to dynamically load and link librairies.
do a cat /proc/pid/maps (where pid is a pid of a process present on the
system), and you'll see that every process has the code of ld-linux
mapped into its address space.

thomas
-- 
PETAZZONI Thomas
[EMAIL PROTECTED]     ICQ : 34937744
[EMAIL PROTECTED]         http://kos.enix.org

------------------------------

From: "O.Petzold" <[EMAIL PROTECTED]>
Subject: Re: Problems with C++ in Kernel Module
Date: Mon, 18 Dec 2000 10:00:02 +0100

>
>         When I run "make" everything goes wll (apparently) - it compiles
> and links without warnings or errors - but when I insmod it the
> following errors are displayed:
>         unresolved symbol __builtin_delete
>         unresolved symbol __rtti_user
>         unresolved symbol __pure_virtual

You have to bring your own new and delete (e.g. using kmalloc/kfree) and
you can't use exceptions and rtti, since the startup code isn't ported to
the kernel yet. (gcc -fno-exceptions -fno-rtti). At moment I try to port
some of the code to the kernel (a priori exception handling). __pure_virtual
is small "guard" that calls in user space abort(), since nobody should call
a pure virtual function (e.g. as a result of c-casts..). There is a next problem -
how to terminate a kernel module ??

>         Also, I can not include<linux/malloc.h> in  bcipher.cc because
> <linux/malloc.h> includes <linux/list.h> which declares a variable
> with the name new --the C++ compiler returns an error probably because
> it confuses it with the new() function; also it returns an error when
> including <linux/signal.h> just because it has a switch() that in one
> of the case: there is no instruction...

Yep, some includes are a nightmare. The only solution for signal.h which I
have is to patch it. The other is to
extern "C" {
#define new    hide_new
....
#include <linux/malloc.h>
#undef new
....
}

>         Is it a good idea to use C++ in the kernel (I don't use exceptions
> nor anything too powerful)      ? Alright, probably it isn't. But is it
> possible (if the C++ code is relatively simple)?

C++ has a big advantage concerning cleaning up the resources using the
destructors. There is nothings equal to in C imo. The next is hiding the data
etc. Well, on the other side, there are a lot of problems as you can see.
The best would be to port the basic functionality to the kernel. Living
without exceptions is possible but, it's a nightmare on shared files for
user and kernel space since you have to ifdef/else/.. - that's my problem.
The next would be to shadow the kernel header and than you can port
parts of the libstdc++ (e.g. string - nesessary for some exceptions ..)

Regards
Olaf




------------------------------

From: [EMAIL PROTECTED] (Michael Kerrisk)
Subject: Re: what is ld-linux.so.2?
Date: Mon, 18 Dec 2000 09:07:28 GMT

On Mon, 18 Dec 2000 15:10:27 +0900, "�̿���"
<[EMAIL PROTECTED]> wrote:

>I have one question...
>
>linux's "/lib" directory have ld-linux.so.2.
>
>what is this?
>what program use this?

Crossposting a question like this to bold COLDA and COLDS is quite
unnecessay...

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to