Linux-Development-Sys Digest #678, Volume #8 Sun, 29 Apr 01 23:13:11 EDT
Contents:
Re: scripting questions (Ulrich Eckhardt)
Re: Kernel 2.4.4 Problems (ioan)
Re: Kernel 2.4.4 Problems (xstatik)
Re: DHCP client broken in 2.4.4 (xstatik)
How to write to a file in Linux Kernel (ouyang)
Re: Pipe Problem ("Frank")
Re: Kernel 2.4.4 Problems (Robert Lynch)
Re: DHCP client broken in 2.4.4 ("Peter T. Breuer")
Shared library related questions (Timur Aydin)
Re: Linux, streams and the standard library (John Beardmore)
Re: Shared library related questions (Chronos Tachyon)
Re: Shared library related questions ("Timur Aydin")
Re: Shared library related questions (Chronos Tachyon)
----------------------------------------------------------------------------
From: Ulrich Eckhardt <[EMAIL PROTECTED]>
Subject: Re: scripting questions
Date: Sun, 29 Apr 2001 13:10:09 +0200
PPP wrote:
> I am trying to get proficient in scripting. I have a few questions.
>
> $SETSID $PPPD pty "$PPPOE_CMD" \
> $PPP_STD_OPTIONS \
> $DEMAND \
> $PPPD_SYNC &
> echo "$!" > $PPPD_PIDFILE
> fi
> wait
I guess that you somewhere have these variables defined like
PPPD=/sbin/pppd
or
PPPD=/sbin/alternate-pppd
That the real command is not used makes it easier to substitute it for
something else, that is change one line and change the whole script.
>
> Now when a program returns a value the calling script usually uses $? to
> represent the returned value. What does the term $! represent (why was $?
> not used)?
This is interpreted with something (probably sh, bash, perl, python ),
you'll have to look up the interpreter's documentation.
>
> What does the wait command do? Would not the script wait for $PPPD to
> return anyway? If this is the case then why is wait used?
pppd can (iirc) be started in daemon-mode, that is become a
background-process. Examine eg PPP_STD_OPTIONS for how it is invoked here.
uli
------------------------------
From: ioan <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.4 Problems
Date: Mon, 30 Apr 2001 02:23:50 -0500
Hi, Fruitbat, i can confirm that this problem does indeed exist for other people
as well, more precisely..me..heh, i have problems when using rp-pppoe 3.0 with
2.4.4, i have also tried upgrading pppd to the latest version but it did no goo,
i tried reaching you at your e-mail address but it could not be reached so i
tried usenet.well, if you do manage to find a solution please e-mail me at
[EMAIL PROTECTED] (i'll give you my real-email address if you ask for it,
main reason not posting it here is obvious, spam ;)
as to what could be causing this problem, my guess would be some changes in the
new kernel with regard to ppp, ppp_generic, ppp_async to be more exact.
well, i gotta go, thanks for posting this message here, otherwise i would have
also never been able to confirm that im not the only one with this problem..
take care, also dont reply to this message cause im not a avid usenet user and i
will not post another message again, e-mail me and we can discus fixes or
whatever.
later..
Fruitbat wrote:
> I have just compiled the 2.4.4 kernel and have found that my pppoe based
> ADSL connection times out when attempting to connect on my RH7.1 system, the
> system log is as follows:
>
> Apr 29 10:45:31 fruitbat pppd[1301]: Exit.
> Apr 29 10:45:57 fruitbat pppd[1351]: pppd 2.4.1 started by root, uid 0
> Apr 29 10:45:57 fruitbat pppd[1351]: Using interface ppp0
> Apr 29 10:45:57 fruitbat pppd[1351]: Connect: ppp0 <--> /dev/pts/2
> Apr 29 10:46:28 fruitbat pppd[1351]: LCP: timeout sending Config-Requests
> Apr 29 10:46:28 fruitbat pppd[1351]: Connection terminated.
> Apr 29 10:46:32 fruitbat pppoe[1352]: Timeout waiting for PADO packets
> Apr 29 10:46:32 fruitbat pppd[1351]: Exit.
>
> I have backed out to kernel 2.4.3 and everything is fine. Has anyone else
> experienced this problem with 2.4.4?
>
> --
> ^^Fruitbat^^
------------------------------
From: xstatik <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.4 Problems
Date: Mon, 30 Apr 2001 02:28:07 -0400
Hi, Fruitbat, i can confirm that this problem does indeed exist for other people
as well, more precisely..me..heh, i have problems when using rp-pppoe 3.0 with
2.4.4, i have also tried upgrading pppd to the latest version but it did no goo,
i tried reaching you at your e-mail address but it could not be reached so i
tried usenet.well, if you do manage to find a solution please e-mail me at
[EMAIL PROTECTED] (i'll give you my real-email address if you ask for it,
main reason not posting it here is obvious, spam ;)
as to what could be causing this problem, my guess would be some changes in the
new kernel with regard to ppp, ppp_generic, ppp_async to be more exact.
well, i gotta go, thanks for posting this message here, otherwise i would have
also never been able to confirm that im not the only one with this problem..
take care, also dont reply to this message cause im not a avid usenet user and i
will not post another message again, e-mail me and we can discus fixes or
whatever.
later..
sorry if i posted this reply twice but the first had an invalid e-mail address.
> I have just compiled the 2.4.4 kernel and have found that my pppoe based
> ADSL connection times out when attempting to connect on my RH7.1 system, the
> system log is as follows:
>
> Apr 29 10:45:31 fruitbat pppd[1301]: Exit.
> Apr 29 10:45:57 fruitbat pppd[1351]: pppd 2.4.1 started by root, uid 0
> Apr 29 10:45:57 fruitbat pppd[1351]: Using interface ppp0
> Apr 29 10:45:57 fruitbat pppd[1351]: Connect: ppp0 <--> /dev/pts/2
> Apr 29 10:46:28 fruitbat pppd[1351]: LCP: timeout sending Config-Requests
> Apr 29 10:46:28 fruitbat pppd[1351]: Connection terminated.
> Apr 29 10:46:32 fruitbat pppoe[1352]: Timeout waiting for PADO packets
> Apr 29 10:46:32 fruitbat pppd[1351]: Exit.
>
> I have backed out to kernel 2.4.3 and everything is fine. Has anyone else
> experienced this problem with 2.4.4?
>
> --
> ^^Fruitbat^^
------------------------------
From: xstatik <[EMAIL PROTECTED]>
Subject: Re: DHCP client broken in 2.4.4
Date: Mon, 30 Apr 2001 02:35:02 -0400
could possibly be that RealTek drivers are somehow broke or so radically
changed (cannot confirm this). I also have two of the same cards in my
main system and i seem to be having problems with ADSL setup, timeout
waiting for PADO packets, as with you it works fine with 2.4.3,
soo..have no idea what is going on here, but it sure sucks.
e-mail me for further questions and reply to [EMAIL PROTECTED]
Guy Geens wrote:
> I just tried to upgrade my system from kernel 2.4.3 to 2.4.4. After
> reboot, the system could not get a network address from the DHCP
> server. The old 2.4.3 kernel works fine.
>
> Both kernels have been compiled with the same options.
>
> When I assign a static IP address to the network card, I can make
> connections without problems.
>
> The DCHP client tries to get an IP address from the server, but it
> doesn't seem to get any answer. (So it tries again and again...)
>
> When I look in the log files for the DHCP server, I see each request
> and the answer being logged and answered.
>
> My network card is a RTL8139 (driver 8139too.c). The DHCP client is
> the ISC client, version 2.0pl5. (Taken from Debian woody.)
>
> Any hints on how to fix this are appreciated.
>
> Please CC: me on your replies.
>
> --
> G. ``Iggy'' Geens - ICQ: #64109250
> Home: <[EMAIL PROTECTED]> - Work: <[EMAIL PROTECTED]>
> WWW: http://users.pandora.be/guy.geens/
> ``I was thinking about how everyone was dying
> and maybe it's time to live.'' - Eels
------------------------------
From: ouyang <[EMAIL PROTECTED]>
Subject: How to write to a file in Linux Kernel
Date: Sun, 29 Apr 2001 18:52:09 -0400
I am using Linux Kernel 2.2.16.
I want to write to a file when I am in kernel.
What should I do?
Your help will be greatly appreciated.
vincent
------------------------------
From: "Frank" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Pipe Problem
Date: Sun, 29 Apr 2001 16:10:50 -0700
"eric" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Frank wrote:
>
> > Hi all,
> >
> > I'm currently implementing the pipe operator for a custom shell.
> > Though, it seems that my pipe hangs on the second process when I try to
> > pipe more than 2 programs. So, I could only assume that I might have
> > implemented the pipe wrong for all processes in between. So, the only
> > assumption is the the first process and the last process works
> > correctly. So, I'm wondering what am I doing wrong with the processes
> > in between.
> >
> > Frank
> > TIA
> >
> > /* NOTE: nPipes is the number of operators present. So, if nPipes = 2,
> > then 3 programs need to be executed */
> >
> > void ExecutePipe(struct CmdLine *pList, int nPipes)
> > {
> > int i;
> > int fidPipe[2];
> > enum PIPES { READ, WRITE }; /* Constants 0 and 1 for READ and WRITE */
> > struct CmdLine *pCurrent = pList;
> >
> > pipe(fidPipe);
> >
> > for(i = 0; i < nPipes + 1; i++) {
> > if(i == nPipes) {
> > ...
> > if( (pid = fork()) == 0
> > execvp(pCurrent->argv[0], pCurrent->argv);
> > } else {
> > waitpid(...)
> > ...
> > }
> > } else {
> > int pid;
> > if((pid = fork()) == 0) {
> > if(i != 0) {
> > /* if we are in the middle of a pipe, stdin should be closed
> > and be converted to the read of the pipe. */
> > close(fileno(stdin));
> > dup2(fidPipe[READ], fileno(stdin));
> > }
> > /* Now, close the read end of the pipe since we don't need it
> > */
> > lose(fidPipe[READ]);
> > /* Close stdout, which would be redircted the the write end of
> > the pipe */
> > close(fileno(stdout));
> > dup2(fidPipe[WRITE], fileno(stdout));
> > /* Close the write pipe, which we don't need */
> > close(fidPipe[WRITE]);
> > execvp(pCurrent->argv[0], pCurrent->argv);
> > } else {
> > int status;
> > waitpid(pid, &status, 0);
> > }
> > }
> > pCurrent = next in link list;
> > }
> > return;
> > }
>
> I'd say you actually have two problems. The first is the waitpid in the
> else clause of the lower fork. This will cause your program to stop and
> wait until the child process has stopped before it will fire off the next
> child process. The second problem which looks even hairier is that you
are
> trying to assign each of the middle processes the same pipe as their stdin
> and stdout. You need to have a pipe set for each process (actually
> I believe you can use n-1 pipe sets) that you fire up. The stdin in for
> the next process needs to be assigned the stdout of the previous process
> and it's stdout be one of the new pipes, with the last one having it's
> stdout be regular stdout (which you do have).
>
> Hope this helped,
>
> Eric
> MVP for Unix Programming
> BrainBench http://www.brainbench.com
>
Thanks, I figured that it had something to do with using one pipe. And,
thanks, I didn't think about the queuing effect that I had with the pipes.
I guess a way to do it is to make an array of pipes, though, wouldn't that
be an unoptimized method since I might have so many pipes created at once?
Or, would the performance outweigh the memory I would be allocating for
those pipes?
Frank
------------------------------
From: Robert Lynch <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Kernel 2.4.4 Problems
Date: Sun, 29 Apr 2001 16:12:50 -0700
ioan wrote:
>
> Hi, Fruitbat, i can confirm that this problem does indeed exist for other people
> as well, more precisely..me..heh, i have problems when using rp-pppoe 3.0 with
> 2.4.4, i have also tried upgrading pppd to the latest version but it did no goo,
> i tried reaching you at your e-mail address but it could not be reached so i
> tried usenet.well, if you do manage to find a solution please e-mail me at
> [EMAIL PROTECTED] (i'll give you my real-email address if you ask for it,
> main reason not posting it here is obvious, spam ;)
>
> as to what could be causing this problem, my guess would be some changes in the
> new kernel with regard to ppp, ppp_generic, ppp_async to be more exact.
>
> well, i gotta go, thanks for posting this message here, otherwise i would have
> also never been able to confirm that im not the only one with this problem..
>
> take care, also dont reply to this message cause im not a avid usenet user and i
> will not post another message again, e-mail me and we can discus fixes or
> whatever.
> later..
Just for reference, I am using 2.4.4 with pppoe, no problems or
differences found between 2.4.3 and 2.4.4
I have:
# rpm -qv rp-pppoe
rp-pppoe-3.0-1
but ppp is installed from tar.gz, according to instructions at:
http://www.roaringpenguin.com/pppoe/#download
and:
http://www.math.uwaterloo.ca/~mostrows/
FWIW. Bob L.
> Fruitbat wrote:
>
> > I have just compiled the 2.4.4 kernel and have found that my pppoe based
> > ADSL connection times out when attempting to connect on my RH7.1 system, the
> > system log is as follows:
> >
> > Apr 29 10:45:31 fruitbat pppd[1301]: Exit.
> > Apr 29 10:45:57 fruitbat pppd[1351]: pppd 2.4.1 started by root, uid 0
> > Apr 29 10:45:57 fruitbat pppd[1351]: Using interface ppp0
> > Apr 29 10:45:57 fruitbat pppd[1351]: Connect: ppp0 <--> /dev/pts/2
> > Apr 29 10:46:28 fruitbat pppd[1351]: LCP: timeout sending Config-Requests
> > Apr 29 10:46:28 fruitbat pppd[1351]: Connection terminated.
> > Apr 29 10:46:32 fruitbat pppoe[1352]: Timeout waiting for PADO packets
> > Apr 29 10:46:32 fruitbat pppd[1351]: Exit.
> >
> > I have backed out to kernel 2.4.3 and everything is fine. Has anyone else
> > experienced this problem with 2.4.4?
> >
> > --
> > ^^Fruitbat^^
--
Robert Lynch Berkeley CA USA [EMAIL PROTECTED]
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: DHCP client broken in 2.4.4
Date: Mon, 30 Apr 2001 00:55:14 +0200
xstatik <[EMAIL PROTECTED]> wrote:
> could possibly be that RealTek drivers are somehow broke or so radically
> changed (cannot confirm this). I also have two of the same cards in my
Sporadic reports of 8139too problems in 2.4.4 are reaching the kernel
list. Apparently the card loses the first packets. Downgrade the driver
using the 2.4.3 source for it to compile just it, and you should be
OK.
Peter
------------------------------
From: Timur Aydin <[EMAIL PROTECTED]>
Subject: Shared library related questions
Reply-To: [EMAIL PROTECTED]
Date: Sun, 29 Apr 2001 19:42:03 -0400
Hi everybody,
1. Under win32, whenever a DLL is loaded into memory by a separate process,
the system will use the same code segment for each instance, but the data
segment will be separate for each instance. In order to share memory
between the DLL's, some work needs to be done. How are things with shared
libraries under linux? If two processes use the same library (either
through dl_open or through the gcc -shared switch), will they have separate
data segments or not?
2. Under win32, whenever a DLL is loaded and the DLL has a function called
DllMain, it will be called with a parameter that contains
DLL_PROCESS_ATTACH. Whenever the DLL is unloaded, the same DllMain will be
called with a parameter that contains DLL_PROCESS_DETACH. Now I know that
for linux, the _init and _fini functions can be used for the same purpose,
but if possible, I want to find a solution that is source code compatible
for both win32 and linux. Would the solution below work? If yes, what are
the limitations or difference in behavior compared to the above mentioned
methods (DllMain, _init, _fini).
void LibraryInitialize()
{
...
}
void LibraryShutdown()
{
...
}
class A
{
public:
A() {LibraryInitialize();}
~A() {LIbraryShutdown();}
};
A a;
It is expected that object a's constructor will be called when the library
loads for the first time and that the destructor will be called when the
library unloads. And the source can be used on both win32 and linux without
any modification.
Any thoughts?
Timur.
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.alpha,comp.os.linux.setup
Subject: Re: Linux, streams and the standard library
Date: Mon, 30 Apr 2001 01:44:12 +0100
In article <[EMAIL PROTECTED]>, Neil Butterworth
<[EMAIL PROTECTED]> writes
>"John Beardmore" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> >> So - a couple of questions:
>> >>
>> >> 1) is there a way to get ostringstream to work ?
>> >
>> >Yes - use STLport. You can download it from www.stlport.org.
OK, I'll try that when a get 2.95.3 running.
>> >> 2) is the Standard C++ library ready for prime time under Linux ?
>> >> Isn't its
>> >> use utterly routine these days ? Or am I trying to be too modern
>?
>> >
>> >No, I've been using it for quite some time with absolutely no problems.
>Not
>> >under RedHat though - I run SuSE.
>>
>> What compiler version are you using ?
>
>gcc 2.95.2
OK, pretty recent then !
Cheers, J/.
--
John Beardmore
------------------------------
From: Chronos Tachyon <[EMAIL PROTECTED]>
Subject: Re: Shared library related questions
Date: Mon, 30 Apr 2001 02:18:24 GMT
On Sun 29 Apr 2001 06:42, Timur Aydin wrote:
> Hi everybody,
>
> 1. Under win32, whenever a DLL is loaded into memory by a separate
> process, the system will use the same code segment for each instance, but
> the data segment will be separate for each instance. In order to share
> memory between the DLL's, some work needs to be done. How are things with
> shared libraries under linux? If two processes use the same library
> (either through dl_open or through the gcc -shared switch), will they have
> separate data segments or not?
>
In Linux, there's no such thing as "code segment" and "data segment"; the
CS and DS registers are always set to the same value. The entire library
is loaded into the address space of each process that uses it via the
mmap(2) function, and the loading is done using copy-on-write. That means
that a page of memory that never gets written to (like .text) will be
shared across all running programs, but each program will have its own copy
of read-write data. As far as heap and stack go, the library becomes a
part of the running executable. If you want to share memory regions
between libraries (or programs, for that matter), you have to use either
mmap(2) on a globally writable file, or System V shared memory.
> 2. Under win32, whenever a DLL is loaded and the DLL has a function called
> DllMain, it will be called with a parameter that contains
> DLL_PROCESS_ATTACH. Whenever the DLL is unloaded, the same DllMain will be
> called with a parameter that contains DLL_PROCESS_DETACH. Now I know that
> for linux, the _init and _fini functions can be used for the same purpose,
> but if possible, I want to find a solution that is source code compatible
> for both win32 and linux. Would the solution below work? If yes, what are
> the limitations or difference in behavior compared to the above mentioned
> methods (DllMain, _init, _fini).
>
> void LibraryInitialize()
> {
> ...
> }
>
> void LibraryShutdown()
> {
> ...
> }
>
> class A
> {
> public:
> A() {LibraryInitialize();}
> ~A() {LIbraryShutdown();}
> };
>
> A a;
>
> It is expected that object a's constructor will be called when the library
> loads for the first time and that the destructor will be called when the
> library unloads. And the source can be used on both win32 and linux
> without any modification.
>
> Any thoughts?
>
Ick. Putting C++ in a shared library is generally a bad idea (esp. due to
name mangling and exception handling issues), but this *should* work
as expected.
--
Chronos Tachyon
Guardian of Eristic Paraphernalia
Gatekeeper of the Region of Thud
[Reply instructions: My real domain is "echo <address> | cut -d. -f6,7"]
------------------------------
From: "Timur Aydin" <[EMAIL PROTECTED]>
Subject: Re: Shared library related questions
Date: Sun, 29 Apr 2001 22:43:14 -0400
"Chronos Tachyon" <[EMAIL PROTECTED]> wrote in
message news:QX3H6.17294$[EMAIL PROTECTED]...
> On Sun 29 Apr 2001 06:42, Timur Aydin wrote:
>
> Ick. Putting C++ in a shared library is generally a bad idea (esp. due to
> name mangling and exception handling issues), but this *should* work
> as expected.
>
Would LibraryShutdown() be called even if the process that uses the shared
library gets killed?
Timur.
------------------------------
From: Chronos Tachyon <[EMAIL PROTECTED]>
Subject: Re: Shared library related questions
Date: Mon, 30 Apr 2001 02:45:29 GMT
On Sun 29 Apr 2001 09:43, Timur Aydin wrote:
>
> "Chronos Tachyon" <[EMAIL PROTECTED]> wrote in
> message news:QX3H6.17294$[EMAIL PROTECTED]...
>> On Sun 29 Apr 2001 06:42, Timur Aydin wrote:
>>
>> Ick. Putting C++ in a shared library is generally a bad idea (esp. due
>> to name mangling and exception handling issues), but this *should* work
>> as expected.
>>
>
> Would LibraryShutdown() be called even if the process that uses the shared
> library gets killed?
>
> Timur.
>
>
>
No, not if a signal was the cause of death. If the process catches the
signal and exits gracefully, then your shutdown code will be called. Just
keep in mind that nothing stops a SIGKILL.
--
Chronos Tachyon
Guardian of Eristic Paraphernalia
Gatekeeper of the Region of Thud
[Reply instructions: My real domain is "echo <address> | cut -d. -f6,7"]
------------------------------
** 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
******************************
