Linux-Development-Sys Digest #96, Volume #8 Wed, 23 Aug 00 13:13:19 EDT
Contents:
Re: Kernel Versions and depmod (Mike)
Re: "Best" x86 Linux C/C++ compiler?? (Warren Young)
help with linux network programming ([EMAIL PROTECTED])
crypt(3) (Fro-Man)
Re: "Best" x86 Linux C/C++ compiler?? (Aaron C Coday)
Re: Circumventing TIME_WAIT...howto? ("Robert Colbert")
Re: "Best" x86 Linux C/C++ compiler?? (Andi Kleen)
Re: all threads in a process share the same pid? (Mario Klebsch)
Re: how to insert my protocol into the linux protocol stack? (Mario Klebsch)
Re: all threads in a process share the same pid? (Mario Klebsch)
Re: all threads in a process share the same pid? (Mario Klebsch)
Re: all threads in a process share the same pid? (Mario Klebsch)
Re: modules char-major-6? (Mario Klebsch)
Re: all threads in a process share the same pid? (Mario Klebsch)
Re: Kernel 2.4.0-test6 Compile and install module problem? (Ivar Koppel)
----------------------------------------------------------------------------
From: Mike <[EMAIL PROTECTED]>
Subject: Re: Kernel Versions and depmod
Date: Wed, 23 Aug 2000 15:29:24 GMT
Mike wrote:
>
> I recently moved from a test kernel to the last 2.2.xx kernel. I had to
do
> this due to the fact that the tdfx.o module currently will not compile on
> the text kernel. The problem I am having is this. When I compile my
> modules and do depmod - it uses the 2.4 test kernel directory instead of
my
> 2.2 module directory, and I also get loads of unresolved symbol errors.
> Any help would be greatly appriceated.
>
> Mike
>
> --
I appreciate the help, by supplying it options seemed to work. Not sure
what is going on, but depmod seems to assume highest kernel. Using the
version indicator solves problems
> Posted via CNET Help.com
> http://www.help.com/
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: Wed, 23 Aug 2000 09:56:49 -0600
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: "Best" x86 Linux C/C++ compiler??
Martin von Loewis wrote:
>
> There is also The Portland Group CC, http://www.pgroup.com; I don't
> have any performance information on that compiler, either.
There's also KAI C++ (www.kai.com), which is supposed to be a very nice
compiler.
> People migrating from DOS often ask for conio, and are always referred
> to curses. This is a FAQ, that's why it shows up in discussions.
There's a new library I saw on Freshmeat the other day: UConio. No
doubt it's a wrapper around curses to provide Conio-like function calls.
--
= Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: [EMAIL PROTECTED]
Subject: help with linux network programming
Date: Wed, 23 Aug 2000 15:52:56 GMT
i want some help with writing simple network
programs like
generating IP packets, able to modify IP headers for
IP address, flags in IP packets etc, detect arrival of
packets and evaluate its headers, flags etc.
basically these are the programming skills that i
need to develop and master.
through this list, i would request if you can provide
me with sample working code, web resources, books etc.
i find the unix network programming book a good resource
for concepts but actually on the linux i have not been
able to compile the programs. hence i really do not have
any working code examples.
thanks
brian
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Fro-Man <[EMAIL PROTECTED]>
Subject: crypt(3)
Date: Wed, 23 Aug 2000 11:55:54 -0400
Hopefully this is a simple question:
/* excerpt from man page */
#define _XOPEN_SOURCE
#include <unistd.h>
char *crypt(const char *key, const char *salt);
/* end of excerpt */
The char* that crypt returns, what is it? Is it malloc()'d memory or
static somewhere? I have tried compiling it with with free()'ing the
returned pointer, but it segfaults. If it isn't malloc()'d, where'd it
come from?
Also, for some reason when I try to compile I do not seem to be getting
the correct include files. Or atleast the declaration for the crypt
function does not seem to exist where the man pages says it does. I can
easily get the error to go away if I just declare it within my program,
but that seems kind of messy. I'd just rather inlcude it correctly.
~/src/example/crypt > gcc -Wall encrypt.c -c
encrypt.c: In function `main':
encrypt.c:13: warning: implicit declaration of function `crypt'
encrypt.c:13: warning: assignment makes pointer from integer without a
cast
~/src/example/crypt > gcc -Wall encrypt.o -lcrypt
~/src/example/crypt >
TIA
# Aaron Day # [EMAIL PROTECTED] # http://www.csis.gvsu.edu/~daya #
Ever get that feeling you are being watched?...
Its a skunk.
------------------------------
From: Aaron C Coday <[EMAIL PROTECTED]>
Subject: Re: "Best" x86 Linux C/C++ compiler??
Date: Wed, 23 Aug 2000 08:54:19 -0700
So I would suggest checking out Cygnus (now Redhat)'s Codefusion.
It a derivative of gcc, but with optimizations and more standardized
C++.
It also comes with a very nice source navigator that give you much the
niceities of Visual C++ (class browser, include browser, cross ref.).
However, it does cost money...
Aaron
"H.W. Stockman" wrote:
> I'd like to purchase a shrink-wrapped x86 Linux package with a
> "good" C/C++ compiler. I define "Good" to mean: the compiler
> produces efficient executables for source code comparable to
> the Spec2000 suite. The main use would be for compiling
> memory-intensive floating point code, with some middling
> graphics. An IDE is nice, but not the most important feature;
> I would like a good, intuitive text editor.
>
> Currently I use Intel C/C++ 4.5 under Microsoft VC++ in
> Windows. I did numerous tests with gcc and egcs back in
> 1997 and early 1998, and generally found they produced
> slower executables than did the Intel compiler (by 20 to 50%).
> I'd like to set up a system for dual-boot, and would like to
> have the Linux system communicate with the 4 windows PCs
> on my TCP/IP network
>
> It would be nice to have conio.h features available in the Linux
> compiler; it would be nicer still to have some equivalents of
> the Windows console functions like SetConsoleScreenBuffer().
>
> I've never used Linux for more than a few hours at a crack.
> However, I installed AT&T SVR4 and X-windows on two 486
> PCs back in early 1992, and set up gc and emacs, etc. in that
> environment. So I have a sense of what I may be up against
> (I suspect the setup it is tremendously easier now-- back then
> it was an arcane process with 42 floppy disks, and adding a driver
> for a DC2020 tape drive or modem could take hours.)
>
> Thanks for opinions-- please fork your responses to my e-mail.
------------------------------
From: "Robert Colbert" <[EMAIL PROTECTED]>
Subject: Re: Circumventing TIME_WAIT...howto?
Date: Wed, 23 Aug 2000 09:02:29 -0700
Well, I've got my workaround for the TIME_WAIT issue. I received a few
private email replies to this thread, and am now going to share the most
important discoveries here. I'm not posting people's private email text,
email addresses, names or anything here; I'm only going to post my own reply
text to them and to this group in the hope that, if anyone else encounters
this problem, they'll have a way to solve it:
I am now using a close() on both sides (analogous to Windows SDK
closesocket()). Here's the pseudocode for both sides:
[-server-]
bind()
listen()
while(1)
{
cli = accept()
read(cli)
close(cli)
}
[-client-]
while(1)
{
s = socket()
connect()
SO_LINGER( s, {on, 2 seconds} )
close()
if( every 200 connections )
sleep(3ms) // give the server and network a little catch-up time
}
The read call in the server makes him "block" until the client calls
close(). This will cause the read to fail out, then the server will call
close(). Thus, the client gets to call close() first performing the active
close.
The client will wait until the server has ACK'ed his FIN to close out the
session because of the SO_LINGER option on the socket. This keeps them both
pretty much in-sync. The sleep every 200 connections or so is necesary to
just let the machines think about the status of the universe from time to
time and let the network deal with all the traffic. Even with a recompiled
kernel, I can't just let all the machines run in tight loops never coming up
for air initiating session after glorious session full-bore. It's just too
stressful and things will, eventually, start to break down and I notice lots
of SYN_RCVD and CLOSE_WAIT sockets without these sleeps.
I'm not using the shutdown() call because that generates additional packets,
and I'm trying as hard as I can to generate a seven packet session
(S/SA/A/FA/A/FA/A). There are other tests that actually involve
sending/receiving data, but our basic session tester is looking to just
pound out a device's load balancing algorithms by establishing sessions to
servers as fast as possible.
I have recompiled the kernel to eliminate the TIME_WAIT state with great
success at this point. I did it as an optional condition, though, to either
allow for full RFC compliance testing or high-performance rapid session
testing. Basically, during init, I look for a file named /etc/no_time_wait
to exist. If it's there, I set a variable that will conditionally control
whether sockets will ever be placed into the TIME_WAIT state or not.
Everything at this point is working like a dream. I've got clients that are
able to generate over 4,000 sessions per second at near full-RFC compliance
(only the TIME_WAIT state is never used) to load-balanced servers. We
actually expect to execute over 12 million full TCP sessions per minute
through the balancer (200,000 per second) aggregated across 96 rack-mounted
PCs. This test is finally possbile and working now that we're able to
sustain these kinds of session rates over long periods of time (days) with
great consistency.
Thanks again for all of your (plural) help and advice. I've never built a
kernel before. Now, I've actually modified one to better-suit the needs of a
particular problem with success. I have to publicly say that having that
kind of ability makes life a lot easier and is one of the major reasons we
switched our testbed from Windows NT to Linux. Having access to a community
of people willing to help with advice when it really counts makes it
possible to get things done at an alarmingly fast rate. The quality of the
software with which we are working is nothing short of becoming one of the
wonders of the world. I am really happy to be an active part of this
community!
I will post my exact kernel source modification once I get into the office
today. It's a few new lines of code inside of tcp_input.c and a few other
files. It will virtually remove the TIME_WAIT from ever occuring on sockets.
As a tip, I was able to find a comment in the tcp_input.c source file where
it attempts to allocate a structure to store the TIME_WAIT'ed socket,
handling a failed alloc, that reads something like, "We have more important
things to worry about than proper socket closure. Just close the socket and
ignore the TIME_WAIT state." Granted, that's not very likely to occur on the
very vast majority of systems running today, but when I forced it happen by
assigning NULL to the tw variable instead of calling the alloc to actually
allocate one, the TIME_WAIT sockets do, in fact, disappear (no surprise
here) and everything keeps right on running just fine and quickly!
You'll want to make sure to actually REMOVE the allocation. Don't let the
allocation happen then assign NULL to tw. This will cause a disastrous
memory leak in the kernel (a bad place for leaks). Just comment out the tw =
(long blurb) line and replace it with tw = NULL.
Again, to everyone who ever responded within this thread, a HUGE thank-you
is owed. I'd like to virtually buy everyone in the thread a beer at this
point! Enjoy your virtual beer, and keep on kerneling! And, hey, since it's
a *-virtual-* beer, you don't need to call a taxi or have a designated
driver to get home. You can actually drive!
Seriously, though, thanks for the help. This wasn't exactly Mission
Impossible, but it ended up being, "Mission With a Fast Solution," thanks to
the advice I received here over the past week or so.
My original post asking for help is repeated at the end of this message for
review.
-Rob Colbert ([EMAIL PROTECTED])
"If you see a motorcycle rider frowning at the end of a ride, they brought
it with them and couldn't get rid of it."
--
-Rob Colbert ([EMAIL PROTECTED])
"If you see a rider frowning at the end of a ride, they brought it with them
and couldn't get rid of it."
"Robert Colbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> First, I know why TIME_WAIT is there for TCP sockets. I don't need it,
> and I know this completely. Our network does not communicate over
> satellites, broken fiber one mile deep in the ocean and crappy phone
> lines with even worse modems attached. The network is a dedicated system
> that needs to generate massive amounts of connections per second through
> a completely isolated series of boxes, etc., etc., etc.
>
> Is there any way to completely eliminate the TIME_WAIT state short of
> recompiling the kernel? Will SO_REUSEADDR do all that I need? What do I
> need? I need sockets to become available immediately after a session has
> ended. I can guarentee that there are no packets left in the ether. I
> don't want this "protective" coating on my pill. I'll swallow it whole
> and take the pain that occurs if I'm wrong.
>
> In essence, is there any "proper" way to get around this TIME_WAIT state
> in a socket without a kernel hack? This is not for an application that
> is for public distribution. We're working on a very specific, in-house
> test tool and I need to be able to get sockets available again fast.
> Waiting for them to die out of the TIME_WAIT state severely limits our
> ability to do what we're trying to do.
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: "Best" x86 Linux C/C++ compiler??
Date: 23 Aug 2000 18:00:38 +0200
Martin von Loewis <[EMAIL PROTECTED]> writes:
> "H.W. Stockman" <[EMAIL PROTECTED]> writes:
>
> > I'd truly like to see comparable performance.
>
> I believe at the moment, there is no other choice but gcc on
> Linux. With some effort, you may be able to find a copy of lcc, but I
> have no idea which would perform better.
>
> There is also The Portland Group CC, http://www.pgroup.com; I don't
> have any performance information on that compiler, either.
There is also TenDRA C/C++. It produces worse code than gcc at least
on x86 and it is generally very hard to get things to compile on it.
TenDRA is free.
Commercial candidates are also KAI C++ and Fujitsu C/C++.
-Andi
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Tue, 22 Aug 2000 18:50:35 +0200
[EMAIL PROTECTED] writes:
>| This is wholey a matter of opinion. I mine, it makes much more sense
>| for threads to share the current working directory. In particluar, if
>| you call chdir() based on user input in one thread, the logical
>| assumption is that the user wanted to change his working directory,
>| not that he wanted to change it "just for this thread"
>The change, however, would be an asyncronous change of context as it
>affects other threads.
Since it is the nature of threads to share their context, asny changes
to it are the rule, not the exception.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: how to insert my protocol into the linux protocol stack?
Date: Tue, 22 Aug 2000 19:05:24 +0200
[EMAIL PROTECTED] (Grant Edwards) writes:
>You just call dev_add_pack() with a pointer to a struct
>containing the Etherenet protocol number and a pointer to a
>callback routine to be called when packets of that type are
>received.
And how is the other side done, connecting my own protocol to
socket(2)?
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Tue, 22 Aug 2000 19:03:20 +0200
[EMAIL PROTECTED] writes:
>I think he means if you have some path like:
> /a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z.txt
>you can get at z.txt via
> chdir("/a/b/c/d/e/f");
> chdir("g/h/i/j/k/l/m");
> chdir("n/o/p/q/r/s/t");
> fopen("u/v/w/x/y/z.txt", "r");
>Now, if each of those letters are actually words twenty characters
>long...
IMHO, if you would implement anything like open() in this way, it
would be a bug, not a feature. :-(
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Tue, 22 Aug 2000 19:01:46 +0200
[EMAIL PROTECTED] writes:
>What about a multithreaded file manager, where each window may
>represent a different directory? When the user double-clicks on a
>program, the program should have the directory of the window as its
>current directory (even if the "program" is really just a symlink to a
>program in a different directory). If the kernel doesn't allow
>different current directories for each thread, before fork/exec you
>have to lock the current directory using a mutex (to keep the same
>user from opening another program in a different directory and thus
>screwing both up), change directories, fork/exec, return to the
>original directory (unless you always use absolute paths), and unlock
>the directory.
Sometimes things are really simple! What about:
fork(); chdir(); exec*();
You have to fork() anyway, so just change the CWD after fork()ing!
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Tue, 22 Aug 2000 18:54:04 +0200
[EMAIL PROTECTED] (Kaz Kylheku) writes:
>>This is completely wrong. There shouldn't be _any_ case in which
>>chdir() will accept a pathname longer than open() or close().
>That's tno the issue. You can make several calls to chdir in order to shorten
>the relative path needed to access an object that is inaccessible via an
>absolute path.
IMHO a program should only call chdir, if it is explicitly ordered by
the user to do so. Although it might be usefill to circumvent some
limit, IMHO this does not jutify a process to change its current
working directory.
IMHO there surely is something else broken, when your path names are
too long.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: modules char-major-6?
Date: Tue, 22 Aug 2000 19:07:30 +0200
[EMAIL PROTECTED] writes:
> Does any know why I kept getting the error message "modprobe: can't
>locate module char-major-6" in my /var/log/message every 5 mintues or
>so.
Just look at the linux dokumantation (remember linux is the kernel)!
It is in <path to kernel source>/Documentation/devices.txt:
6 char Parallel printer devices
0 = /dev/lp0 Parallel printer on parport0
1 = /dev/lp1 Parallel printer on parport1
...
Current Linux kernels no longer have a fixed mapping
between parallel ports and I/O addresses. Instead,
they are redirected through the parport multiplex layer.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Tue, 22 Aug 2000 18:57:33 +0200
[EMAIL PROTECTED] (Kaz Kylheku) writes:
>If you have only one choice, then making the CWD a thread attribute
>is safer, because it minimizes unwanted interactions between
>unrelated subsystems;
If they are unrelated, why do you use a thread?
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: Ivar Koppel <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.0-test6 Compile and install module problem?
Date: Wed, 23 Aug 2000 19:08:49 +0300
Paul Kimoto wrote:
> In article <[EMAIL PROTECTED]>, John Gluck wrote:
> > Paul Kimoto wrote:
> >> There have been newer modutils releases to
> >> take care of that.
>
> > That's wonderful information... It would be useful if you also said what
> > versions of modutils and where to find them.
>
> See Documentation/Changes.
>
> (Note, however, <[EMAIL PROTECTED]>'s message that his umsdos problems were
> not helped.)
>
> --
> Paul Kimoto
> Disclaimer: Other than explicit citations of URLs, hyperlinks appearing
> in this article have been inserted without the permission of the author.
I also have updated modutils, but the compilation bombs out while making
bzImage during
iptables compilation.
Regards,
Ivar
------------------------------
** 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
******************************
