Linux-Development-Sys Digest #56, Volume #7 Mon, 16 Aug 99 11:15:50 EDT
Contents:
Re: why not C++? (Stephan Houben)
Re: Kernel Debugging (Emsi)
ONLY ADULTS 85710 ([EMAIL PROTECTED])
Re: vi and non-printable character ("T.E.Dickey")
Re: Toshiba DVD-RAM and Linux (Christoph Martin)
Re: DRIVER for Toshiba DVD-RAM (only tested on kernel 2.0.36) (Christoph Martin)
kernel compiler, undefined reference to `__cmpdi2' (root)
9600bps quicker than expected ("Sebastien")
Re: why not C++? (Erik de Castro Lopo)
Accessing user space memory in kernel mode. ([EMAIL PROTECTED])
Deadly optimization bug (all versions!) (Veksler Michael)
Re: why not C++? ("Frank V. Castellucci")
SCSI Tekram DC-390F on linux 2.0.36 (or 2.2.11) (Dorin-Ioan MARINCA)
Re: Looking for a good IP packet analyzer (Andrea Montefusco)
What is loff_t? ([EMAIL PROTECTED])
What does ~current->blocked mean? ([EMAIL PROTECTED])
Re: why not C++? (Edwin Young)
serialprogramming (juergen leeb)
----------------------------------------------------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 16 Aug 1999 10:32:49 +0200
Cocheese <[EMAIL PROTECTED]> writes:
> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
> admit i am no Linux Guru so this may be off the wall.
>
>
> *Why Is linux done primarily in the C programming language rather than
> C++?*
>
>
> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2, but if C++ is so much faster,
> easier, and stable- WHY NOT?
C++ might be easier, but it's not faster, nor stabler, than C.
OK, this depends also on the implementation, but the only serious
free C++-compiler is GCC, and for GCC, this statement is true.
You might want to take into account that Linus still sticks with
an older compiler (2.7, IIRC), because some of the optimisations
in the newer GCC versions break some of the Linux source code.
If even fixing such "minor" problems are that difficult, imagine
what it would mean to convert the whole of Linux to C++.
> There are many differences Between the two programming languages and
> there are huge advantages to C++.
There are also huge disadvantages.
C++ programs need a library for some of their more advanced language
constructs, such as new- and delete-operators, and exception handling.
Note that kernel memory cannot be swapped out; in a user program,
relying on a big shared library from which not everything is used is
no problem, but in the kernel, it is.
> The downside is "linux has always been a C based Program so it will always
> be."
A C++ Linux would probably mean a complete rewrite.
So who's stopping you from writing "Cocheex" ;-)
> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***
Did you take a marketing course recently?
Greetings,
Stephan
------------------------------
From: Emsi <[EMAIL PROTECTED]>
Subject: Re: Kernel Debugging
Date: Mon, 16 Aug 1999 10:02:07 +0200
Reply-To: Emsi <[EMAIL PROTECTED]>
On 16 Aug 1999, root wrote:
> Is there any way to debug kernel just like using gdb at normal user program?
>
Yes. Read the kernel documentation. You can use /proc/kcore and have a
phun ;)
--
[EMAIL PROTECTED]
http://it.pl/emsi
nawet nie mysl o tym ze moglbys przechytrzyc los wbijajac sobie
w serce kilkucentymetrowy kolec z zimnego metalu
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: ONLY ADULTS 85710
Date: Sun, 15 Aug 1999 23:30:20 -0600
Reply-To: [EMAIL PROTECTED]
Free XXX:
http://207.240.225.250
yzw&fZfA
------------------------------
From: "T.E.Dickey" <[EMAIL PROTECTED]>
Subject: Re: vi and non-printable character
Date: Mon, 16 Aug 1999 09:27:03 GMT
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> Actually what I said is wrong. Without the x prefix, it is the decimal
> character code you are entering, rather than octal.
iirc, vim implements what vile does.
from the help-file:
As numbers -- the ^V prefix (or, more correctly, the key bound to
the "quote-next-character" function), if followed by up to
three digits, will insert a character whose value is that
number (no greater than 255) into the buffer. The number may
be entered in decimal (^VNNN), octal with a leading '0' (^V0NNN),
or hex with a leading 'x' (^VxNN).
--
Thomas E. Dickey
[EMAIL PROTECTED]
http://www.clark.net/pub/dickey
------------------------------
From: Christoph Martin <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Toshiba DVD-RAM and Linux
Date: 16 Aug 1999 12:00:18 +0200
Christoph Martin <[EMAIL PROTECTED]> writes:
>
> "Hartmut W. Malzahn" <[EMAIL PROTECTED]> writes:
>
> >
> > Can you give me a hint how I might reproduce the read problem with the
> > drive? I've written a quick (and very dirty :) fix for the write problem
> > and the drive appears to work fine now...
>
> If I remember right, it was reading large chunks from a DVD-ROM (not
> RAM), like parts of a film, via cp or dd. I try to reproduce it this
> weekend and give you the details then.
Mount a DVD-ROM via the /dev/scd0, then try to dd a 400M file to
/dev/null. Same happens with the DVD-RAM, which was written under
Windows/95. dd runs for a while happily, then it hangs, a scsi bus
reset occurs and after that all the scsi devices hang. -> reboot :(
>
> > I've attached the write patch (patches
> > /usr/src/linux/drivers/scsi/scsi.c on kernels 2.2.5 or 2.2.6, probably
> > on later ones too) to this message, maybe it helps someone.
>
> Thanks. I try the patch this weekend and let you know, if it work for
> me.
Applied the patch to kernel 2.2.6 and did some tests. mke2fs on the
DVD-RAM still makes problems, like reported above while reading.
Christoph
--
============================================================================
Christoph Martin, Uni-Mainz, Germany
Internet-Mail: [EMAIL PROTECTED]
------------------------------
From: Christoph Martin <[EMAIL PROTECTED]>
Subject: Re: DRIVER for Toshiba DVD-RAM (only tested on kernel 2.0.36)
Date: 16 Aug 1999 12:06:30 +0200
Christian Mund <[EMAIL PROTECTED]> writes:
>
> Congratulations, it works !
>
It did not work, applying it to kernel 2.2.6. Same problems with read
and write. Works for some time, then hangs, scsi bus reset, all
devices hang -> reboot
Christoph
--
============================================================================
Christoph Martin, Uni-Mainz, Germany
Internet-Mail: [EMAIL PROTECTED]
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: kernel compiler, undefined reference to `__cmpdi2'
Date: 16 Aug 1999 09:50:57 GMT
thanks for all you previos kindness help
I can use RDTSC to read clock now
but there comes another problem
I add some code as following and want to measure the running time
__u64 before;
before = rdtsc();/* function to read time stamp */
......code segment to time....
before = rdtsc() - before;
printk("it took %Lf ns exec \n", before / (350 *1e-3)); /* pentiumII 350 Mhz*/
recompile kernel and got error
ipv4.o(.text+0x5180): undefined reference to `__cmpdi2'
ipv4.o(.text+0x51c5): undefined reference to `__fixunsdfdi'
what's wrong ? no float in kernel?!
what does I should do to coquer this?
and I use PentiumII 350 + redhat 6.0 + twp PCI ethernet card as a router
it seems a bit slow, any thing should I do?
------------------------------
From: "Sebastien" <[EMAIL PROTECTED]>
Subject: 9600bps quicker than expected
Date: Mon, 16 Aug 1999 11:16:01 +0100
I have found a strange behaviour on linux serial communication : the bit
duration is quicker than what you would expect.
I wanted to check the speed of the communication between two PC so I have
connected the serial port (/dev/ttyS1) of the computer sending the data to
an oscilloscope. I have then measured the lenght of the bites that are
displayed on my oscilloscope. I observed a series of low and high states.
Sending just one caracter to the port I was able to recognize it's periodic
shape for example 1010111101 .
The duration of one pulse (bit) should be equal to 1/(Baud_base). For
example I have set the setserial /dev/ttyS1 Baud_base 9600. The duration of
one bit should then be 0.104 millisec. I then ran my small program. And the
lenght of one bit on my oscilloscope is only 0.008 microseconds (one byte is
the equal to 0.08 microseconds)
.
I have changed the communication speed to differents other values. Here are
the values :
setserial /dev/ttyS1 Baud_base 36000 generates a byte duration of 0.260
msec on the oscilloscope
setserial /dev/ttyS1 Baud_base 56000 generates a byte duration of 0.4
msec on the oscilloscope
setserial /dev/ttyS1 Baud_base 115200 generates a byte duration of 1.04
msec on the oscilloscope
This behaviour is the opposite as what you would expect !!!!!
Is there something important that I am missing ?
I am using the linux Mandrake 6.0 based on the kernel 2.2.9.
Altough the speed is quicker than what I would expect, my communication
programs (between two linux computer) worked fine.
Thanks in advance. Sebastien.
Here is very simple program that I wrote with some other people :
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <math.h>
#include <time.h>
#include <termios.h>
/*
* simple program to generate a string of characters on a serial
* line port (/dev/ttyS0 i.e. com1 for Linux)
*/
#define BAUDRATE B9600
#define MODEMDEVICE "/dev/ttyS1"
#define POSIX_SOURCE 1
#define FALSE 0
#define TRUE 1
main(unsigned int argc, char **argv)
{
char test_string[]="seb",buffer[80],texte[50];
int com, nwrite, compteur;
int fd,c,res;
struct termios oldtio,newtio;
char buf[255];
long ncount=0L;
int t;
struct timespec sleep_1ms = {0, 91};
if (argc <2)
{
}
com = open(MODEMDEVICE, O_RDWR);
if (com == -1)
printf("error opening the port");
exit(1);
}
printf("port open %i \n",com);
/*
* loop forever writing this string to the serial port ...
*/
for (;ncount<50000000;ncount++)
{
sprintf(texte,"z%d",ncount);
nwrite = write(com,texte,strlen(texte));
}
close("/dev/ttyS1");
printf("port ferm� %i \n",com );
}
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 19:34:52 +1000
Cocheese wrote:
>
> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
> admit i am no Linux Guru so this may be off the wall.
Well first off I should inform you there was a HTTNSTE (huge thread that
never seemed to end (tm)) a couple of weeks ago on this exact topic. Why
not search deja.com?
> *Why Is linux done primarily in the C programming language rather than
> C++?*
For programming OS kernels, C is a more lightweight language and probably
a better fit. For applications any language may be used, including C, C++
or any one of the dozen or so others that are available.
> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2,
To rewrite the kernel in C++? You must be joking. Even getting it to compile
reliably and correctly would take a lot of effort for exactly zero gain.
> but if C++ is so much faster,
> easier, and stable- WHY NOT?
How is faster, easier or more stable. C++ is a more complex laguage
syntactically and hence takes longer for the compiler to parse. C++
code object are bigger if things like exception handling and other C++
extras are used.
As for easier, how can you possibly say that a language with a much
larger syntax is easier. My experience of other people's C++ code
(I code mostly in C, only using C++ when I really need C++ features)
seems to suggest that with C++ it may be easier for an inexperienced
programmer to get something working (but inefficient) in C++ than it is
in C, but for an experienced programmers who know both languages there
isn't much difference.
The rare exception to this is where C++ is a much better fit to the
problem domain. For an example of this I would cite the Octave project
(large numerical analysis framework/application) where there is a
huge advantage to using C++ objects for things like matrices rather
than structs.
Finally, C++ compilers are not more stable. People have been working
on the gcc compiler for many years, but the C++ compiler g++ has only
just started being stable.
> I have been a RH 6.0 user since the first week it was first released
> and since then i have loved it. I am struggling with it a bit but as i
> continue to learn this from an "other leading brand OS" and a full time
> programmer for a large company.
>
> There are many differences Between the two programming languages and
> there are huge advantages to C++.
>
> The downside is "linux has always been a C based Program so it will always
> be."
The kernel should be in C. C++ does not hold any huge advantages for
kernal development. For applications, feel free to use whatever you feel
mosty comfortable with.
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
"I once worked for a company where as part of the BS5750 "Quality"
process I attended a meeting where I was informed that it was Company
Policy not to use free software. When I asked him for his written
authorisation for me to remove X Windows from our Sun workstations,
he backtracked." -- Phil Hunt
------------------------------
From: [EMAIL PROTECTED]
Subject: Accessing user space memory in kernel mode.
Date: Mon, 16 Aug 1999 11:07:43 GMT
Which functions should i use to access user space memory in kernel
mode?
How do i access the file system in from device driver?
- David Belius
------------------------------
From: Veksler Michael <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc.help
Subject: Deadly optimization bug (all versions!)
Date: 16 Aug 1999 11:24:11 GMT
The bug shows itself on gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2, gcc-2.95.
On AIX-4.1, Linux-x86 (RH4.2 and RH6.0).
Just try to compile the following code once with -O and once without.
This may be the reason behind some of the problems with Linux-2.2.xx
(I post this here, instead of gnu.gcc.bugs, since my previous
posts did not reach the group).
The code:
========== bug.c ========
#include <stdio.h>
/* If one=1, then the output should be: bit&1 */
unsigned test(unsigned one , unsigned bit)
{
unsigned val= bit & 1;
unsigned zero= one >> 1;
val++;
return zero + ( val>> 1 );
}
int main()
{
printf("ret=%d\n", test(1,0)); /* should print 0 */
printf("ret=%d\n", test(1,1)); /* should print 1 */
printf("ret=%d\n", test(1,65535)); /* should print 1 */
return 0;
}
------------------------------
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 07:47:33 -0400
Kaz Kylheku wrote in message ...
>On Mon, 16 Aug 1999 06:47:45 GMT, Satch <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Cocheese) wrote in
>><[EMAIL PROTECTED]>:
>>
>>>*Why Is linux done primarily in the C programming language rather than
>>>
>>>C++?*
>>
>>First, the object model with its constructors and destructors mandates a
>>heavy-duty memory management routine...and usually that memory management
>>routine is part of the operating system. Chicken and egg problem...
>
>But there are disadvantages to C++ constructors. For one thing, they do not
>return a value. The only sanctioned mechanism for indicating construction
>failure is to throw an exception. Exception handling requires run-time
support
>and causes an increase in object file size. It has only recently begun to
be
>properly supported by G++, thanks to EGCS. The implementation adds serious
>bloat to object files.
>
But this can be managed by the Factory pattern. In addition, in a OS
context, the factory would
be the desired route for instrumentation and management.
>>Next, it's very difficult to predict how a C++ package is going to react
>>in all circumstances, because there is more state inherent in a C++
>>program than in a regular C program. Dynamic detection of object type,
>>and run-time binding of objects to subroutines means that you have more
>>run-time overhead...and operating systems already take too many cycles
>>for the services they provide.
But the right analysis and design will allow predict invarient state.
I also noticed in this thread posits like "because g++ is not up to the
task" etc, etc. But I am sure that the developers of the Linux kernel
uncovered more then 1 bug in gcc!
Frank V. Castellucci
------------------------------
From: Dorin-Ioan MARINCA <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: SCSI Tekram DC-390F on linux 2.0.36 (or 2.2.11)
Date: Mon, 16 Aug 1999 15:18:45 +0200
Hi!
What I must check on "make -xconfig" windows to create an linux kernel
(2.0.36 or 2.2.10/11) which supports an SCSI controller Tekram DC-390F?
and
can anyone give me some hints (links to docs/HOWTOs/keywords) on how to
make an soft RAID 0/5 on some disks connected to above card? ...
Thanks in advance.
D.I.M.
------------------------------
From: Andrea Montefusco <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Looking for a good IP packet analyzer
Date: Mon, 16 Aug 1999 14:35:58 +0200
Remco Treffkorn wrote:
>
> Tom Emerson wrote:
> >
> > I'm looking for a good, easy-to-use packet analyzer that runs under Linux.
> > Yes, I know "tcpdump" exists, but that doesn't (easily) show me what I'm
>
Another sniffer with source code and a decent GUI is Ethereal
http://ethereal.zing.org/
It needs GTK and libpcap to compile.
*am*
===============================
Andrea Montefusco
Teseo srl
via S.Giovanni Valdarno 8
00138 ROMA
===============================
Those who can, do. Those who can't, teach. Those who can
do neither, critize.
And those who cant teach, teach teachers.
------------------------------
From: [EMAIL PROTECTED]
Subject: What is loff_t?
Date: Mon, 16 Aug 1999 14:02:44 GMT
What is the type loff_t used for?
What is it used for in the arg to a charter device's read function?
The prototype for such a function is:
ssize_t foo_read(struct file *, char *, size_t, loff_t *);
What is the ssize_t type used for?
- David Belius
------------------------------
From: [EMAIL PROTECTED]
Subject: What does ~current->blocked mean?
Date: Mon, 16 Aug 1999 13:58:47 GMT
In an example of a charter device driver i saw this line of code:
if(current->signal & ~current->blocked) {
What does the ~ mean?
What does this line of code do?
What are current->signal and current->blocked used for?
- David Belius
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
From: Edwin Young <[EMAIL PROTECTED]>
Date: 16 Aug 1999 14:10:17 +0100
Stephan Houben <[EMAIL PROTECTED]> writes:
> You might want to take into account that Linus still sticks with
> an older compiler (2.7, IIRC), because some of the optimisations
> in the newer GCC versions break some of the Linux source code.
I believe that kernel 2.0.x must be compiled with gcc 2.7.2.3 because
it has various bits of broken assembler which just happen to work with
that compiler, but not more recent versions. More recent kernels are
much more robust w.r.t gcc version.
Regards,
--
Edwin Young
------------------------------
Date: Mon, 16 Aug 1999 16:09:13 +0200
From: juergen leeb <[EMAIL PROTECTED]>
Subject: serialprogramming
i have to find out if the parity bit of an serialport is wrong.
Because this is the beginning of a protokol.
does anybody know how to do this?
thank you!!
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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
******************************
