Linux-Development-Apps Digest #300, Volume #7    Mon, 26 Mar 01 18:13:17 EST

Contents:
  Programming with the datalink layer ("David Wilson")
  Re: look for a linux software which like the Visual Source Safe(VSS) (Guy Rouillier)
  a confusion of write.s? ("Leo Naboro")
  Re: about newlib (redhat)! (jwk)
  problems with select() ("Ruben Real")
  Re: Problem with ASM ("Ruben Real")
  gprof and linux pthread ("^!^ Ka Fai")
  Re: sizeof returns wrong structure size (Rene Herman)
  LessTif Release 0.92.26 is out! (The LessTif Project)
  getmsg() doesn't work any longer ("Roman Kellner")
  Shared library linking problem (Tomasz Karczewski)
  Re: problems with select() (Eric P. McCoy)
  signal queuing (Marco Guidi)
  Re: Too many open files error (Micah Cowan)
  increasing open file limit? (Dustin Puryear)
  Documentation / tutorial for ncurses ? (Helmut Blass)
  rendering context not direct (Rob Sang)
  Re: Documentation / tutorial for ncurses ? (Dave Blake)
  Re: signal queuing ("Lawrence K. Chen, P.Eng.")

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

From: "David Wilson" <[EMAIL PROTECTED]>
Subject: Programming with the datalink layer
Date: Sun, 25 Mar 2001 23:17:41 -0500

Can anyone point me in the correct direction to write to the datalink layer
on RedHat?

I found some documentation on the RedHat site about PF_PACKET and filling in
the sockaddr_ll address. But I do not know what I should put in some of the
fields for the sockaddr_ll structure.
Also the document that I found says that if you create a PF_PACKET with
SOCK_DGRAM then "Packets sent through a SOCK_DGRAM packet socket get a
suitable physical layer header based on the information in the sockaddr_ll
destination address before they are queued."
But I don't know the ARP address for the IP that I want to send it to. Help?


Thanks,
David Wilson



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

From: [EMAIL PROTECTED] (Guy Rouillier)
Subject: Re: look for a linux software which like the Visual Source Safe(VSS)
Date: Mon, 26 Mar 2001 04:23:22 GMT

CVS can store binaries, I believe.

"Leo Naboro" <[EMAIL PROTECTED]> wrote:

>goodevening every,i wanna look for a linux software which like the Visual
>Source Safe(VSS)under windows98(NT).it both manage the source codes and
>libs,i know that the CVS is very useful source contol.But our boss
>need the libs contol also...So does anyone tell me how to do it? Thanks!
>
>
>
>
>
>
>
>

=============================
Guy Rouillier

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

From: "Leo Naboro" <[EMAIL PROTECTED]>
Subject: a confusion of write.s?
Date: Mon, 26 Mar 2001 13:20:44 +0800

Hi,I am a beginner of linux assemble.i see a sample for
http://www.linuxassembly.org/linasm-src.html#write
and have a confuse in it.
/* write.s */
.data
hello:
 .string "hello world\n"
.text
.globl _start
_start:
 movl $SYS_write,%eax // SYS_write = 4
 movl $STDOUT,%ebx // fd = fileno(stdio)
 movl $hello,%ecx // buf = str
=======================================
 movl $12,%edx // count = 0x6
=======================================
 int $0x80

 movl $SYS_exit,%eax
 xorl %ebx,%ebx
 int $0x80
 ret

why "$12=0x6"? i dont know why count=0x6 insted of count=0xc?
Thanks!










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

From: [EMAIL PROTECTED] (jwk)
Subject: Re: about newlib (redhat)!
Date: 26 Mar 2001 05:34:54 GMT
Reply-To: [EMAIL PROTECTED]

On Mon, 26 Mar 2001 09:21:15 +0800, Leo Naboro
<[EMAIL PROTECTED]> wrote:
> I downloaded the newlib from the redhat,but when "make ",i got the error
> !why?
> 
What version, what redhat, what error - provide more details.

Jurriaan
-- 
BOFH excuse #94:

Internet outage
GNU/Linux 2.4.2-ac24 SMP/ReiserFS 2x1743 bogomips load av: 0.06 0.02 0.00

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

From: "Ruben Real" <[EMAIL PROTECTED]>
Subject: problems with select()
Date: 26 Mar 2001 11:07:32 +0200

hi all,


iīm trying to write a small prog that basically only forwards data between 
sockets.
i.e. a connection comes in at one socket, a 2nd connection is made to some other 
host. now i want to read data from the 1st socket and write it to the 2nd, and 
vice versa.


my question is: how do i manage it efficiently (no polling) to forward data 
between these two sockets?


thank you for any suggestions.


bye ruben
-- 
_____________________________________________________________
NewsGroups Suchen, lesen, schreiben mit http://netnews.web.de

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

From: "Ruben Real" <[EMAIL PROTECTED]>
Subject: Re: Problem with ASM
Date: 26 Mar 2001 11:14:56 +0200

Bernhard Weichart <[EMAIL PROTECTED]> wrote:
>Hi all
>
>I have a little problem. Iwill learn assembler on linux, but at my code
>are an error at the cmp function.
>Please look at: http://www.hobbies.privateweb.at/bweichart/default.htm 
>for the source-code.
>
>mfg Bernhard


hi all,


i would suggest to XOR the eax register to make sure there is no data in it.
(my knowledge is from msdos, so i donīt know if it applies here.


bye
     ruben


comp:   movl    $ch,%eax                # Compare $ch with $ts
        xor     %eax, %eax              # clear eax
        cmp     $ts,%eax
        jne     kio




-- 
_____________________________________________________________
NewsGroups Suchen, lesen, schreiben mit http://netnews.web.de

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

From: "^!^ Ka Fai" <[EMAIL PROTECTED]>
Subject: gprof and linux pthread
Date: Mon, 26 Mar 2001 17:15:02 +0800

When I try to start a thread in linux, gprof reports this error:

gprof: gmon.out file is missing call-graph data

Does gprof support multi-thread program?

^!^ Ka Fai





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

From: Rene Herman <[EMAIL PROTECTED]>
Subject: Re: sizeof returns wrong structure size
Date: Wed, 21 Mar 2001 17:02:20 +0100

Rolf Magnus wrote:

> C is made to be portable, and it doesn't make sense to force some
> memory alignment

It does, if you could specifically tell the compiler to do so.

> instead of letting the compiler decide based on the
> platform is is made for.

Which it is perfectly free to do when I do *not* explicitly specify 
that I don't want it to do this. 

Not aiming to start a language war, but please, not being able to do 
this is a serious shortcomming of any low-level language. Don't turn C 
into a religion just because it is a good language.


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

From: The LessTif Project <[EMAIL PROTECTED]>
Crossposted-To: comp.windows.x.motif,comp.os.linux.x,comp.unix.cde
Subject: LessTif Release 0.92.26 is out!
Date: 26 Mar 2001 13:23:39 +0200

The LessTif Core Team is pleased to announce
      Release 0.92.26
of the LessTif library!

This is a another "PICO release", the first LessTif release in 2001!
As usual we fixed some bugs in the libraries and tried to further
improve the configuration and build process. So e.g. we removed some
problems with emacs and NEdit.
We start to embed mandatory dependencies into our libraries to avoid
compatibility problems (i.e. libraries used on compile-time
and run-time don't match) as far as current GNU libtool supports this.
Additional i18n support has been added to the Text* widgets.


Check out the NOTES and ChangeLog files for detailled
info on what we have done!

Our companion libraries Xlt and Xbae also got some fixes and
enhancements - check out their specific documentation.


About LessTif:
LessTif is a LGPL'd implemention of the OSF/Motif standard GUI toolkit
for X11. LessTif aims to be source compatible with the OSF/Motif versions 1.2
and 2.1. We're almost done with the 1.2 part, but we still lack
some substantial parts of the 2.1 functionality. (Actually
most 2.x applications do already build, but may not work properly yet.)

So at this point, almost any Motif 1.2 apps compile and run
out of the box with LessTif! The LessTif Core team is interested
in hearing about Motif applications which don't work with LessTif.
Bug reports are welcome; patches are even more welcome!

More information, source code, and binaries for several platforms
are available at:

        http://www.lesstif.org
        http://www.sourceforge.net/projects/lesstif


The LessTif Core Team
-- 
Alexander Mai
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

From: "Roman Kellner" <[EMAIL PROTECTED]>
Subject: getmsg() doesn't work any longer
Date: Mon, 26 Mar 2001 15:48:26 +0200

hi,

since upgrading to SuSE 7.1 and Kernel 2.4 getmsg() always returns errno38
in an application that worked perfectly well before (when passing a file
descriptor) ... any ideas?


    if (getmsg(servfd, NULL, &dat, &flag) < 0)
    {
      fprintf(fp,"Error with getmsg errno=%d\n",errno);
      return(-1);
    }

Regards
Roman
[EMAIL PROTECTED]

============================================================================
A program is complete when it's last user is dead

Yahoo!ID: raistlin_de_majere
ICQ : 100653389
mobile (+43)-664-3730182




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

From: Tomasz Karczewski <[EMAIL PROTECTED]>
Subject: Shared library linking problem
Date: Mon, 26 Mar 2001 16:47:36 +0200

Hello,

I have warning mesage:
/usr/bin/ld: warning: cannot find entry symbol rrors; defaulting to 08048560

when comile program with my shared library (mylib):
gcc -g -errors -Wall -Iinclude -o bin/test src/linux/test.c -Llib -lmylib

Any solutions?


Best regards
KaTo


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

Subject: Re: problems with select()
From: [EMAIL PROTECTED] (Eric P. McCoy)
Date: 26 Mar 2001 10:09:05 -0500

"Ruben Real" <[EMAIL PROTECTED]> writes:

> my question is: how do i manage it efficiently (no polling) to forward data 
> between these two sockets?

Use blocking reads and writes.

If you can't do that, use nonblocking I/O, select(), and perhaps
buffers.  e.g.:

  char *buf, *bufp;
  fd_set rfds, wfds;
  int read_socket, write_socket, maxfd;

  FD_ZERO(&rfds);
  FD_ZERO(&wfds);

  FD_SET(read_socket, &rfds);

  /* if there's no data to write out, don't even check the write socket */
  if(bufp != buf)
    FD_SET(write_socket, &wfds);

  /* ugly code to deal with signals that interrupt select() */
  while(1)
    if(select(maxfd, &rfds, &wfds, NULL, NULL) < 0) {
      if(errno == EINTR)
        continue;

      perror("select");
    }

    break;
  }

  /* if select() says the write_socket is ready... */
  if(FD_ISSET(write_socket, &wfds)) {
    write(write_socket, buf, bufp - buf);
    /* also need to do some other trickiness in case not all bytes are
     * written, but you can figure that out */
  }

  /* and if the read_socket is ready... */
  if(FD_ISSET(read_socket, &rfds) {
    read(read_socket, bufp, MAX_BUFFER_SIZE - bufp);
    /* and update the buffer pointer and check for errors etc */
  }

Lather, rinse, repeat.  The big bottleneck at this point is the
buffer.  I also just realized that we shouldn't check for reads at all
if the buffer is full.  Well, this is the idea; you can figure it out
from here.

-- 
Eric McCoy <[EMAIL PROTECTED]>
  "Knowing that a lot of people across the world with Geocities sites
absolutely despise me is about the only thing that can add a positive
spin to this situation."  - Something Awful, 1/11/2001

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

From: Marco Guidi <[EMAIL PROTECTED]>
Subject: signal queuing
Date: Mon, 26 Mar 2001 19:14:33 +0200

Hi,

does anyone know how to avoid signal queuing ? That is, I wrote the
following example to simulate
a very slow signal handler


[mg@pegasus prova]$ cat main.c
#include <stdio.h>
#include <signal.h>
#include <unistd.h>

void signalHandler(int i) {

    struct sigaction act;
    struct sigaction oldact;

    act.sa_flags=0;
    act.sa_handler=SIG_IGN;
    sigaction(SIGUSR1,&act,&oldact);

    printf("handler of signal number %d sleeping\n",i);
    sleep(10);
    sigaction(SIGUSR1,&oldact,NULL);
}

int main(){

    struct sigaction act;
    struct sigaction oldact;

    act.sa_flags=0;
    act.sa_handler=signalHandler;

    sigaction(SIGUSR1,&act,&oldact);

    printf("looping forever\n");

    while(1) {}
    return 0;
}
[mg@pegasus prova]$

[mg@pegasus prova]$ cc -Wall main.c -o main
[mg@pegasus prova]$

[mg@pegasus prova]$ main &
[2] 13425
[mg@pegasus prova]$ looping forever

[mg@pegasus prova]$ trap -l | grep USR
 8) SIGFPE       9) SIGKILL     10) SIGUSR1     11) SIGSEGV
12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
[mg@pegasus prova]$
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ handler of signal number 10 sleeping
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425
[mg@pegasus prova]$ kill -10 13425handler of signal number 10 sleeping
[mg@pegasus prova]$
[mg@pegasus prova]$ cc --version
egcs-2.91.66
[mg@pegasus prova]$
[mg@pegasus prova]$ more /proc/sys/kernel/version
#1 Mon Oct 16 10:46:55 CEST 2000
[mg@pegasus prova]$ more /proc/sys/kernel/osrelease
2.2.5-15




That is, it seems that while the signal handler is running the other
signals
are queued by setting a bit in a "bitarray" of pending signals.
In this way, even if I kill one million time the SIGUSR1 to the process
number
13425, I just set one million time the same bit.
It also seems that, when the handler returns, the O.S. looks at the
bitarray of pending signals. When it find that the bit corresponding to
SIGUSR1 is set => he let the handler run again.

Is there a way not to queue the pending signal, that is I would like
to ignore the SIGUSR1s sent to the process when the handler is
running. Moreover I don't want to take care of pending signals,
that is I don't want that the handler is run again because of a SIGUSR1
received while the SIGUSR1 is running.

Thank you in advance,
Marco Guidi

email: [EMAIL PROTECTED]





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

Crossposted-To: comp.os.linux,comp.os.linux.development.system,comp.os.linux.networking
Subject: Re: Too many open files error
From: Micah Cowan <[EMAIL PROTECTED]>
Date: 26 Mar 2001 09:53:29 -0800

"David K. Means" <[EMAIL PROTECTED]> writes:

> It is probably worth finding out why there are so many open files.
> I recently cleaned out a hacked system, which had exactly this symptom
> because the hacker was a script-kiddie, and my machine didn't fit his
> script exactly.  So bind was eating up lots of sockets.
> 
> So when you get the machine working again, it might be worthwhile to look
> for evidence of hackery:  on my machine it was the existence of
> /dev/.lib/lib/*
> and a missing /etc/hosts.deny.

s/hack/crack/, please.

-Micah

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

From: [EMAIL PROTECTED] (Dustin Puryear)
Subject: increasing open file limit?
Date: Mon, 26 Mar 2001 12:05:40 -0600
Reply-To: [EMAIL PROTECTED]

Hello, I have found that under Linux 2.2 the maximum number of files that can
be opened is 1024. I want to increase this limit as it is a bit unrealistic 
for our network server (the application should be able to open up a few 
thousand sockets and maintain the connections).

I believe I read somewhere that this was doable, but quite painful. Is that
true? Has anyone solved this problem another way?

I was unsure if this should go to comp.os.linux.development.system or here,
so I just took a guess. :) Also, I could not find a FAQ for this ng at
www.faq.org. If one exist, and covers this topic, please alert me.

Regards, Dustin

-- 
Dustin Puryear <[EMAIL PROTECTED]>
http://members.telocity.com/~dpuryear
Integrate Linux Solutions into Your Windows Network
- http://www.prima-tech.com/integrate-linux


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

From: Helmut Blass <[EMAIL PROTECTED]>
Subject: Documentation / tutorial for ncurses ?
Date: Mon, 26 Mar 2001 21:28:45 +0200

Hi folks,
does anybody know where in the Internet I can get detailed information or even
a tutorial for programming with ncurses ?

thanx for your help, Helmut

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

From: Rob Sang <[EMAIL PROTECTED]>
Crossposted-To: 
comp.graphics.api.opengl,comp.os.linux.x,comp.programming,comp.unix.programmer
Subject: rendering context not direct
Date: Mon, 26 Mar 2001 16:40:15 -0500

On my Redhat Linux system, glXIsDirect tells that rendering context is
not direct, which means rendering contexts pass all rendering commands
to the X server. I'm afraid that's why there occurs the Xlib
syquence-lost error and Xlib unexpected-async-reply error when I port a
multi-threaded software, which uses both X and OpenGL, from SGI unix to
Redhat Linux. Mesa 3D was installed on the Linux platform. Is it
available to get direct rendering context?

Any help is highly appreciated.


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

From: [EMAIL PROTECTED] (Dave Blake)
Subject: Re: Documentation / tutorial for ncurses ?
Date: 26 Mar 2001 21:48:08 GMT
Reply-To: [EMAIL PROTECTED]

Helmut Blass <[EMAIL PROTECTED]> wrote:
> Hi folks, does anybody know where in the Internet I can get
> detailed information or even a tutorial for programming with
> ncurses ?

I generally use the html help files distributed with ncurses.
It is easy to use and to learn.

-- 
Dave Blake
[EMAIL PROTECTED]

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

From: "Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]>
Subject: Re: signal queuing
Date: Mon, 26 Mar 2001 17:08:47 -0500

You could change the signal state to ignore while inside the handler (though
there is that race condition between the handler being called and the handler
changing the disposition for the signal).

Another might be to use signal() instead of sigaction()....then you get the
unreliable signal handling. (which means it either goes to SIG_DFL or
blocks....I believe the distinction is SysV or BSD....I forget which
convention Linux goes for).

Oh....SA_ONESHOT or SA_RESETHAND is the default behaviour for
signal()....hmmm, the default action for the signal is process
termination....I guess you don't want the default.  Try using a signal where
the default action is to ignore the signal.

Marco Guidi wrote:
> 
> Hi,
> 
> does anyone know how to avoid signal queuing ? That is, I wrote the
> following example to simulate
> a very slow signal handler
> 
> [mg@pegasus prova]$ cat main.c
> #include <stdio.h>
> #include <signal.h>
> #include <unistd.h>
> 
> void signalHandler(int i) {
> 
>     struct sigaction act;
>     struct sigaction oldact;
> 
>     act.sa_flags=0;
>     act.sa_handler=SIG_IGN;
>     sigaction(SIGUSR1,&act,&oldact);
> 
>     printf("handler of signal number %d sleeping\n",i);
>     sleep(10);
>     sigaction(SIGUSR1,&oldact,NULL);
> }
> 
> int main(){
> 
>     struct sigaction act;
>     struct sigaction oldact;
> 
>     act.sa_flags=0;
>     act.sa_handler=signalHandler;
> 
>     sigaction(SIGUSR1,&act,&oldact);
> 
>     printf("looping forever\n");
> 
>     while(1) {}
>     return 0;
> }
> [mg@pegasus prova]$
> 
> [mg@pegasus prova]$ cc -Wall main.c -o main
> [mg@pegasus prova]$
> 
> [mg@pegasus prova]$ main &
> [2] 13425
> [mg@pegasus prova]$ looping forever
> 
> [mg@pegasus prova]$ trap -l | grep USR
>  8) SIGFPE       9) SIGKILL     10) SIGUSR1     11) SIGSEGV
> 12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
> [mg@pegasus prova]$
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ handler of signal number 10 sleeping
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425
> [mg@pegasus prova]$ kill -10 13425handler of signal number 10 sleeping
> [mg@pegasus prova]$
> [mg@pegasus prova]$ cc --version
> egcs-2.91.66
> [mg@pegasus prova]$
> [mg@pegasus prova]$ more /proc/sys/kernel/version
> #1 Mon Oct 16 10:46:55 CEST 2000
> [mg@pegasus prova]$ more /proc/sys/kernel/osrelease
> 2.2.5-15
> 
> That is, it seems that while the signal handler is running the other
> signals
> are queued by setting a bit in a "bitarray" of pending signals.
> In this way, even if I kill one million time the SIGUSR1 to the process
> number
> 13425, I just set one million time the same bit.
> It also seems that, when the handler returns, the O.S. looks at the
> bitarray of pending signals. When it find that the bit corresponding to
> SIGUSR1 is set => he let the handler run again.
> 
> Is there a way not to queue the pending signal, that is I would like
> to ignore the SIGUSR1s sent to the process when the handler is
> running. Moreover I don't want to take care of pending signals,
> that is I don't want that the handler is run again because of a SIGUSR1
> received while the SIGUSR1 is running.
> 
> Thank you in advance,
> Marco Guidi
> 
> email: [EMAIL PROTECTED]

-- 
   Who: Lawrence Chen, P.Eng.                     Email: [EMAIL PROTECTED]
  What: Software Developer                        Phone: 614-761-7449
 Where: Open Text, BASIS Division                   Fax: 614-761-7269
        5080 Tuttle Crossing Blvd., M/S 7&8         ICQ: 12129673
        Dublin, OH  43016                URL: http://www.opentext.com/basis
 DISCLAIMER: All opinions expressed are mine and *NOT* my employers

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


** 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.apps 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-Apps Digest
******************************

Reply via email to