Linux-Development-Sys Digest #966, Volume #6 Fri, 16 Jul 99 06:13:49 EDT
Contents:
Re: Bug of GCC (Ross Smith)
Re: any suggestion about reading kernel source code ? ("Charles Sullivan")
Re: any suggestion about reading kernel source code ? (Scott Lanning)
X-citer (Lisa)
any suggestion about reading kernel source code ? ("Tony")
Simple The Best !!! ([EMAIL PROTECTED])
Re: Bug of GCC (Ulrich Drepper)
Re: Bug of GCC (Tim Roberts)
Re: Bug of GCC ("Cute Panda")
Re: Bug of GCC (Frank Sweetser)
Re: measuring interrupts time ("B. James Phillippe")
Re: Bug of GCC (Scott Lanning)
Re: Bug of GCC (Scott Lanning)
Re: newbie question ("Moors, ing. E.W.J.")
Re: Why we are still holding on to X Windows (Michel Bardiaux)
Pbl rlogin (Vincent)
Re: NT to Linux port questions (Heinz =?iso-8859-1?Q?H=E4berle?=)
Re: DMA from/to user space? (Maciej Golebiewski)
Re: Pbl rlogin (Dupont Nicolas)
----------------------------------------------------------------------------
From: Ross Smith <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: Fri, 16 Jul 1999 15:36:52 +1300
Scott Lanning wrote:
>
> Ulrich Drepper ([EMAIL PROTECTED]) wrote:
> : This is no bug in gcc, it's a bug in your program.
>
> Please explain why you think it is consistent that
>
> /*
> '
> */
>
> is preprocessed without an error, whereas
>
> #if 0
> '
> #endif
>
> gives an error.
Because that's what the C/C++ standards say. Tokenisation takes place
before preprocessing. Comments are lost at the tokenisation stage, so
anything can go between /* and */. But anything between #if 0 and #endif
has to consist of valid preprocessing tokens.
> The native Irix system here, 'cc foo.c'
> will work in both cases, but 'gcc foo.c' won't.
Behaviour on encountering an unmatched ' or " during preprocessing is
explicitly stated to be undefined (in the C++ standard; I don't have the
C standard but I expect the preprocessor is pretty much the same).
Accepting it without comment, rejecting it with an error, making demons
fly out of your nose, or starting World War III are all valid responses.
--
Ross Smith <[EMAIL PROTECTED]> The Internet Group, Auckland, New Zealand
========================================================================
The good news, according to the FCC, is that television viewing won't be
interrupted by the Y2K problem. The bad news, according to the rest of
us, is that television viewing won't be interrupted by the Y2K problem.
-- Jonathan Erickson in Dr Dobb's Journal
------------------------------
From: "Charles Sullivan" <[EMAIL PROTECTED]>
Subject: Re: any suggestion about reading kernel source code ?
Date: Fri, 16 Jul 1999 00:17:29 -0400
Comments, comments ... we don' need no steenking comments!
Tony wrote in message ...
>hi, there,
>
>I am new in linux development, i'd like to read some kernel source code to
>know more about system. But there are too few comments in source code. Can
>someone tell me how can i get more detail comments about kernel source code
>?
>
>thanks
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: any suggestion about reading kernel source code ?
Date: 16 Jul 1999 04:29:06 GMT
Tony ([EMAIL PROTECTED]) wrote:
: I am new in linux development, i'd like to read some kernel source
: code to know more about system. But there are too few comments in
: source code. Can someone tell me how can i get more detail comments
: about kernel source code ?
On the LDP site, there are several guides/HOWTOs on the kernel.
There are several books. "Linux Kernel Internals" by Beck et al
is pretty good, IMHO.
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer."
--Edsger Dijkstra
------------------------------
From: Lisa <[EMAIL PROTECTED]>
Subject: X-citer
Date: 11 Jul 1999 21:30:11 PDT
X-citer(tm)
Potency Enhancer For Men
X-citer is an aphrodisiac dietary supplement formulated with unique ingredients that
not only relieve erectile difficulties, but also significantly increases a man's
sexual desire. These synergistic qualities make E-citer a powerful sexual stimulant.
X-citer is a safe, effective, and easy to use alternative to expensive prescription
medicine. It is the only product that affects both impotence and libido by improving
penile erection, as well as, enhancing sexual desire. Other treatments only improve
penile erection without any positive effect on sexual desire. X-citer has a clear
advantage by being able to provide both without any serious side effects.
Visit our website now!!
http://www.angelfire.com/fl2/xciter
You owe it to yourself to try X-citer, the natural and safe alternative...
Imagine the fun and excitement you can bring back into your life with X-citer, the all
natural, safe product, for enhanced sexual function and satisfaction. It is an amazing
alternative to the leading prescription brand, at a fraction of the cost.
X-citer is a complete product for enhanced sexual function and satisfaction, such as
desire, orgasmic function, erectile function, and ejaculation.
X-citer's formula has the two ingredients that have everyone talking, Yohimbe Bark and
L-Arginine HCL. Now, after two years of exhaustive testing on hundreds of individuals,
it is available to you. CALL NOW! 1-888-454-4549
X-citer is Guaranteed or your money is returned.
To Order call 1-888-454-4548
30 Day Supply is $19.95 plus $4.50 S.& H.
60 Day Supply is $35.95 plus $4.50 S.& H.
ALL MAJOR CREDIT CARDS ACCEPTED.
Advanced Natural Products
P.O. Box 9498
Cincinnati, Ohio 45209
[EMAIL PROTECTED]
------------------------------
From: "Tony" <[EMAIL PROTECTED]>
Subject: any suggestion about reading kernel source code ?
Date: Fri, 16 Jul 1999 00:05:39 -0700
hi, there,
I am new in linux development, i'd like to read some kernel source code to
know more about system. But there are too few comments in source code. Can
someone tell me how can i get more detail comments about kernel source code
?
thanks
------------------------------
From: [EMAIL PROTECTED]
Subject: Simple The Best !!!
Date: 16 Jul 1999 03:52:49 GMT
Looking for absolutely new ways to earn money?
I got them for you!
That's it: http://jump.to/webmoney
There are no BS ! only approved methodes.
Why don't you visit this site right now?...
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: 15 Jul 1999 20:50:35 -0700
Reply-To: [EMAIL PROTECTED] (Ulrich Drepper)
"Cute Panda" <[EMAIL PROTECTED]> writes:
> Lots of preprocessors, like MS VC++, Sunsoft Workshop, IBM and HP, they
> don't complain about
> "#if 0 ... It's a bug .... #endif", only gnu preprocessor complains about
> this code.
And your point is? It's still no valid code.
--
===============. drepper at gnu.org ,=. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: [EMAIL PROTECTED] (Tim Roberts)
Subject: Re: Bug of GCC
Date: Fri, 16 Jul 1999 06:30:57 GMT
[EMAIL PROTECTED] (Scott Lanning) wrote:
>Ulrich Drepper ([EMAIL PROTECTED]) wrote:
>: This is no bug in gcc, it's a bug in your program.
>
>Please explain why you think it is consistent that
>
>/*
>'
>*/
>
>is preprocessed without an error, whereas
>
>#if 0
>'
>#endif
>
>gives an error. The native Irix system here, 'cc foo.c'
>will work in both cases, but 'gcc foo.c' won't.
Whether you think it is consistent or not, this behavior is specified in
the ANSI/ISO C standard. Text within #if/#endif must be valid, parsable C
code; text within comments can be anything at all. Your Irix "cc" is not
standard-compliant.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: "Cute Panda" <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: 16 Jul 1999 06:33:50 GMT
If it's the way ANSI C is specified, then why the other preprocessor
don't suffer this
problem ? they don't meet the ANSCI standard, right ?
Many books talk about this code and say it's a simple way to make
comments, and lots of
programmers write their code like this, well, I think it's very inconvenient
for some people
to modify their code just because gcc preprocessor complains about this kind
of code.
if gcc preprocessor is able to recognize "#if 0", then it should know
that all the following
code before #endif is not real code and should not be tokenized, why is it
necessary to break the
text into tokens ? don't you think tokenizing the text inside #if 0 ...
#endif is a redundant job ?
Ulrich Drepper ���g��峹 ...
>"Cute Panda" <[EMAIL PROTECTED]> writes:
>
>> Lots of preprocessors, like MS VC++, Sunsoft Workshop, IBM and HP, they
>> don't complain about
>> "#if 0 ... It's a bug .... #endif", only gnu preprocessor complains
about
>> this code.
>
>And your point is? It's still no valid code.
>
>--
>---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
>Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
>Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: 16 Jul 1999 01:28:29 -0400
"Stuart MacDonald" <[EMAIL PROTECTED]> writes:
> Ross Smith <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Because that's what the C/C++ standards say. Tokenisation takes place
> > before preprocessing. Comments are lost at the tokenisation stage, so
> > anything can go between /* and */. But anything between #if 0 and #endif
> > has to consist of valid preprocessing tokens.
>
> Not much of a *pre*processor then is it?
and how would you suggest doing #define substitutions before you've broken
the text into tokens?
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
Woody: How are you today, Mr. Peterson?
Norm: Never been better, Woody. ... Just once I'd like to be better.
-- Cheers, Chambers vs. Malone
------------------------------
From: "B. James Phillippe" <[EMAIL PROTECTED]>
Subject: Re: measuring interrupts time
Date: 16 Jul 1999 06:00:52 GMT
On Tue, 13 Jul 1999, Sebastien wrote:
> Hi,
>
> Does anybody have a program to test the respose time of linux to an
> interruption?
For small delays, you can usually make use of some kind of CPU timing
feature. I know that Pentium and Alpha CPU's have such a feature, though I
don't know how to get at it in an Alpha. For Pentiums, you can do
something like this:
static inline unsigned long rdtsc(void) {
unsigned long time;
asm volatile
(
".byte 0x0f; .byte 0x31" /* Opcodes for RDTSC */
: "=a" (time) /* Output - time=EAX */
: /* No inputs */
: "eax", "edx" /* Clobbers */
);
return time;
}
and then call this before and after your operation and compare the results.
I believe the measurement is in CPU cycles, so a delta of 100 on a Pentium
100 would be 1 microsecond.
-bp
--
# bryan at terran dot org
# http://www.terran.org/~bryan
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 06:00:01 GMT
Ross Smith ([EMAIL PROTECTED]) wrote:
: Behaviour on encountering an unmatched ' or " during preprocessing
: is explicitly stated to be undefined (in the C++ standard; I don't
Then the the GNU C preprocessor behavior is moronic. If it is possible
to ignore it, and that is more convenient for the programmer, then it
should be ignored. From the first page of "The C Preprocessor" by RMS,
ANSI Standard C requires the rejection of many harmless constructs
commonly used by today's C programs. Such incompatibility would be
inconvenient for users, so the GNU C preprocessor is configured to
accept these constructs by default. Strictly speaking, to get ANSI
Standard C, you must use the options `-trigraphs', `-undef' and
`-pedantic', but in practice the consequences of having strict
ANSI Standard C make it undesirable to do this.
With this in mind, why is GNU's cpp such a prick w.r.t. unmatched
strings inside #if 0 ? I've never considered GNU to be such a
stickler about pre-existing standards...
Anyway, I don't think the C standard has any business specifying
preprocessor behavior. But who cares what I think...? <sigh>
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"If lightning is the anger of the gods, the gods are concerned mostly
with trees." --Lao Tse
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 07:08:36 GMT
Cute Panda ([EMAIL PROTECTED]) wrote:
: if gcc preprocessor is able to recognize "#if 0", then it should
: know that all the following code before #endif is not real code and
: should not be tokenized, why is it necessary to break the text into
: tokens ? don't you think tokenizing the text inside #if 0 ... #endif
: is a redundant job ?
Yeah, I agree with you. I think some people are more concerned with
sticking to a familiar, "elegant" system rather than one which is
more practical. (Sometimes I'm one of them.. :( )
Anyway, I have another example of how the GNU preprocessor ignores the
standard. In the syntax of conditionals (section 1.5.2 in GNU manual)
#if expression
controlled text
#endif /* expression */
Then it says, "In fact, you can put anything at all after the
`#endif' and it will be ignored by the GNU C preprocessor, but only
comments are acceptable in ANSI Standard C." So, please don't
give arguments based on the high moral ground of the GNU C
preprocessor because it conforms to "standard" C.
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"I'm going to have fun telling you about this absurdity, because I
find it delightful." --Richard Feynman
------------------------------
From: "Moors, ing. E.W.J." <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Fri, 16 Jul 1999 07:24:36 GMT
Azhar Abu Talib wrote:
>
> I am a little bit new with linux . Be patient with me. I have this book
> By Alessandro Rubini about linux device drivers, and i tried the
> examples in the book but even the simplest one doesn't work . I've test
>
> the example in two versions of kernel ; one is 2.0.34 , the other one
> is 2.2.5. The examples given seems do not work on both.
> The example is like this:
>
> #define MODULE
> #include <linux/module.h>
>
> int init_module(void) { printk(" <1>Heelo World \n"); return; }
> void cleanup_module { printk("<1>Goodbye Cruel World \n");
>
> i compile the file with gcc -c then try to insmod the module but somehow
>
> the print
Did you type "dmesg", after the insmod to see if it was printed?
> statement never came out. Can anybody tell me what i am doing wrong .
> Thanks
>
> Azhar
eric
------------------------------
From: Michel Bardiaux <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Fri, 16 Jul 1999 10:31:24 +0200
Philip Brown wrote:
>
> On Thu, 15 Jul 1999 20:03:33 +0200, [EMAIL PROTECTED] wrote:
> >...
> >Much more than tweaking. IIRC there is absolutely no way for the *client
> >app*
> >to supply a font, fonts have to be installed on a font server.
>
> you just contradicted yourself.
>
> The app can say "Add this font server to the font path"
> The app can ALSO open a port and act as a font server.
Yes, there are ways; but there is no *simple* X or Xt API for that; the
client machine becomes
a font server for the whole network, which breaks robustness and maybe
security. It also breaks the basic X programming paradigm.
In Windoze, one can pass data to the "rendering subsystem" (deliberately
vague term) and say "This is the font to be used for this string". Much
simpler (in principle! practically, Windoze has lotsa problems and
technicalities!)
>
---
Michel Bardiaux
UsrConsult S.P.R.L. Rue Margot, 37 B-1457 Nil St Vincent
Tel : +32 10 65.44.15 Fax : +32 10 65.44.10
------------------------------
From: Vincent <[EMAIL PROTECTED]>
Subject: Pbl rlogin
Date: Fri, 16 Jul 1999 09:10:23 +0200
I can't connect to my linux system with a rlogin command.
Are there a file to modify to accept rlogin ???
Tanks.
--
=========================================
DEVERRE Vincent - MCII : [EMAIL PROTECTED]
=========================================
------------------------------
From: Heinz =?iso-8859-1?Q?H=E4berle?= <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Fri, 16 Jul 1999 10:37:17 +0200
The only thing I have seen is the combination pthread_mutex and
pthread_cond. I have built
an event-system like windows. But only single events (its easy). You have
to code something
for a multiple object. but if you have events and semaphores it's possible!
> timers, and thread handles. Does Linux have something similar. ie. a
> mechanism
> that allows a thread to wait for any one of a number of event to signal?
>
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: DMA from/to user space?
Date: Fri, 16 Jul 1999 10:52:27 +0200
Clark Williams wrote:
> I've got the M-VIA code and the kernel patch by Robert Kaiser and am in the
> process of studying them. I would like to incorporate a set of user memory
> locking and unlocking functions such as in the patch, but I don't really
> want to modify the kernel proper. I'd rather just incorporate the locking
> code into my loadable module and do all the grungy details there.
What about putting this functionality into a separate module? So that
the next time someone need that, instead of patching the kernel or
reimplementing the code, it would be enough to use an existing module?
Since you're gonna do this anyway, it should not generate any additional
work, and would be very useful for many people.
> My intent is to lock down the pages that form the buffer specified by a
> read/write request and DMA to/from them using scatter-gather. One question
> I've got is: do I have to be back in process context to unlock them? Or
> will it be safe to do so from interrupt context?
Honestly, I don't know. I don't use signals very extensively, so I
have no clue whether there are any caveats with calling kernel functions
from a signal handler (unlocking would be done by your module).
What you could do instead, would be to follow M-VIA approach: the
library
creates additional thread used to call user declared callback functions
whenever an error occures. This is convenient, because you are allowed
to more withing a thread than withing an interrupt handler, and in
normal circumstances the additional thread does not consume CPU time
as it most probably is sleeps on a condition variable.
> Also, any hints as to where in the via code you got the memory locking code?
> ;-)
In VI Architecture it's called Registering and Deregistering so look
for the code for VipRegisterMem and VipDeregisterMem and actual
implementation at the level of the device independent kernel agent
you can most likely found in src/vipk_core/
Cheers,
Maciej
------------------------------
From: Dupont Nicolas <[EMAIL PROTECTED]>
Subject: Re: Pbl rlogin
Date: Thu, 15 Jul 1999 11:05:38 +0200
Vincent wrote:
>
> I can't connect to my linux system with a rlogin command.
> Are there a file to modify to accept rlogin ???
> Tanks.
>
> --
>
> =========================================
> DEVERRE Vincent - MCII : [EMAIL PROTECTED]
> =========================================
Regarde dans le fichier /etc/inetd.conf.
decommente la ligne commencant par login.
ensuite, soit tu reboote la machine, soit tu relance le demon inet qui
se trouve dans /etc/rc.d/init.d sur redhat, ou dans /etc/init.d dans
debian
( tape : inet reload )
Nicolas Dupont
------------------------------
** 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
******************************
