Linux-Development-Sys Digest #911, Volume #7 Sat, 27 May 00 13:13:15 EDT
Contents:
Re: How do I patch the kernel? (Paul Kimoto)
touch panel ("sllai")
Re: Call stack in C (Peter Pointner)
Re: ICMP (Peter Pointner)
Re: Call stack in C (jwk)
Re: Multicast programming question ("Ian S. Nelson")
Re: touch panel (fhc)
Re: Need ideas for university funded project for linux (Craig Kelley)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: How do I patch the kernel?
Date: 27 May 2000 01:50:55 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Jay Randall wrote:
> I need to patch the kernel.
> Do I need to only make the changes to the code, remake the kernel, and
> reboot? Or is there some installation process I need to go through in
> addition?
You may need to do something about modules, and you have to somehow
tell your booting method about the new kernel (image). This sort of
thing is discussed in the kernel-source README and the Kernel HOWTO
(http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html).
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: "sllai" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: touch panel
Date: Sat, 27 May 2000 14:20:45 +0800
I would like to know in order to control the touch panel, what are the
things I need to know.
Does the Linux OS have the touch panel driver. I knew that in the KDE for
GUI development contain the mouse operation to indicate the mouse movement
and mouse click. Howevr, what should I use if I use the touch panel to
activate the progarm and not the mouse click action.
Can somebody provide some info regarding this.
thanks
sllai
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: Call stack in C
Date: 27 May 2000 08:21:19 +0200
H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>>
>> How can I get a call stack strace from a
>> running program. I want something like pstack
>> on Solaris for Linux
>>
> gdb -p <process_id>
> where
On my Suse 6.3 with gdb 4.18 this gives
gdb: unrecognized option `-p'
But
gdb <executable> <process_id>
works.
Peter
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: ICMP
Date: 27 May 2000 08:33:33 +0200
Sake <[EMAIL PROTECTED]> wrote:
> Hi,
> I built a kernel with full TCP/IP suport, and made a single floppy
> ram-disk-only
> system. System booted, interfaces are configured, everything looks fine. But
> when
> I tried use 'ping' to reach out to other machines I got the message "unknoen
> protocol icmp"
> while other machines on the network can successfuly ping this one.
> What did I miss ?
Maybe the entry
icmp 1 ICMP # internet control message protocol
in /etc/protocols
Peter
------------------------------
From: [EMAIL PROTECTED] (jwk)
Subject: Re: Call stack in C
Date: 27 May 2000 07:10:36 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 26 May 2000 17:39:20 -0700, John Reiser
<[EMAIL PROTECTED]> wrote:
>> Is there a function call that can be made from within a running
>> program that will write a stack-trace to some stream (stdout, stderr, etc.)?
>
>glibc-2.1.2 has functions
> int backtrace(void **p_pc, int n)
> char **backtrace_symbols(void *const *arr, int n)
> void backtrace_symbols_fd(void *const *arr, int n, int fd)
>which work best when the code is compiled with the usual frame pointers.
>See <execinfo.h>. These routines are relatively young; YMMV.
>
Check the gcc-extension __builtin_return_address (on dejanews for
example).
Good luck,
Jurriaan
--
That which walks the corridors of power is a virus that mutates;
immune to all resistance, and every turn of history...
New Model Army - Killing
GNU/Linux 2.2.15 SMP 5 users load av: 0.00 0.04 0.01
------------------------------
From: "Ian S. Nelson" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Multicast programming question
Date: Sat, 27 May 2000 09:49:06 -0600
==============0AC4EB66917FF6F0DD10423C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
As tradition dictates, I found the solution moments after posting the
question...
In case anyone wanted to know. It was the bind that was screwed up, I
should have used "INANY_ADDR" for the "server address" I guess when you
do the setsockopt for multicast it picks the device and if you've
already bound it to a device then that parts get's screwed up.
Ian
"Ian S. Nelson" wrote:
> I hope this is obvious to someone... I'm a multicast newbie. I'm
> betting on my history of posting stupid questions and as soon as a
> embarass myself the answer presents itself to me..
>
> So I've written a driver that gets multicast UDP packets from some
> source and pushes them on the linux network queue. It works
> flawlessly with unicast packets, very cool. My multicast packets
> don't seem to go through though. The machine has an ethernet adaptor
> and my "adaptor" which is called tv0. (the packets are coming from a
> satellite)
>
> Ethernet IP addr is 172.20.50.110
> Tv0 IP addr is 9.99.99.99 (cause 9 is easy to remember)
>
> I'm thinking that it has something to do with the subnet mask or my
> "sink" I've been setting the subnet to be 255.255.255.0
> My test packets have a multicast addr of 239.255.0.1 I don't
> remember seeing a lof of 255 or 0 in IP addrs but this makes it
> through the is_it_our_multicast_packet test and goes on to the local
> delivery section of the kernel. The src and dst ports are 7777 on the
> packets. The packets are good and they get through the kernel.
>
> my test sink is this: it's ugly because it's been hacked to death...
> If I pull out the mreq/setsockopt stuff and send unicast packets they
> route through the kernel perfectly. When I sent multicast they get
> dropped somewhere in the ip_local_deliver portion of the network stack
> which is what makes me think it's my socket program or something to
> do with my subnet. When I build the multicast list in (the
> setsockopt builds a list in the kernel) the interface resolves to tv0
> so I don't think I need to do the IP_MULTICAST_IF option, anyone know?
>
> /*
> Stupid Socket code
> */
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <string.h>
>
> #include <netdb.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
>
> #define NUL '\0' /* ASCII NUL character */
>
> int main(int argc, char*argv[] )
> {
> int sock, newsock; /* socket descriptor */
> struct hostent *hp; /* ptr to host info struct */
> struct servent *sp; /* ptr to service info struct */
> struct sockaddr_in server; /* socket address and port */
> struct sockaddr_in theiraddr; /* socket address and port */
> int stat; /* status return value */
> int rc;
> int sin_size;
> struct ip_mreq mreq;
>
> char buf[517]; /* most buffers aren't 517bytes, this
> allows for easier kernel debugging... */
>
> /*------------------------------------------------------*/
> /* Create the socket */
> /*------------------------------------------------------*/
>
> sock = socket( PF_INET, SOCK_DGRAM, 0 );
> if (sock < 0)
> {
> perror( "could not create socket" );
> exit( 1 );
> }
>
> /* set up our side */
> server.sin_family = PF_INET;
> server.sin_port = htons(7777);
> server.sin_addr.s_addr = inet_addr( "9.99.99.99" );
>
> /* set up their side */
> theiraddr.sin_family = PF_INET;
> theiraddr.sin_port = htons(7777);
> theiraddr.sin_addr.s_addr = htonl( INADDR_ANY );
>
> rc = bind( sock, (struct sockaddr_in *) &server, sizeof(struct
> sockaddr));
> if ( rc < 0 ) {
> perror("Bind failed\n");
> exit( 1 );
> }
>
> /* set up socket to do multicast */
> mreq.imr_multiaddr.s_addr = inet_addr("239.255.0.1");
> mreq.imr_interface.s_addr = inet_addr("9.99.99.99");
>
> if(setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq,
> sizeof(struct ip_mreq)) < 0) {
> perror("setsockopt failed");
> exit( 3 );
> }
>
> sin_size = sizeof(struct sockaddr_in);
> while(1) {
> rc = recvfrom( sock, buf, 517, 0, (struct
> sockaddr*)&theiraddr, &sin_size );
> printf("%d, got one\n", rc);
> if(rc == -1)
> perror("revcfrom error:");
> }
>
> close( sock );
> exit( 0 );
> }
>
>
> Any obvious flaws you can see? The other side of this is that there
> must be something screwed up with my driver that blocks multicast out
> but it's much deeper than the normal filtering in the kernel. My
> printks have been causing me some crashing problems as I get closer to
> the socket code (any ideas? I've got pints for payment) so I've
> decided that the easier approach at this point is to make sure my test
> program works...
>
> thanks,
> Ian
>
> --
> Ian S. Nelson
> [EMAIL PROTECTED]
>
>
--
Ian S. Nelson
[EMAIL PROTECTED]
==============0AC4EB66917FF6F0DD10423C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
As tradition dictates, I found the solution moments after posting
the question...
<p>In case anyone wanted to know. It was the bind that was
screwed up, I should have used "INANY_ADDR" for the "server address"
I guess when you do the setsockopt for multicast it picks the device and
if you've already bound it to a device then that parts get's screwed up.
<p>Ian
<p>"Ian S. Nelson" wrote:
<blockquote TYPE=CITE>I hope this is obvious to someone... I'm a
multicast newbie. I'm betting on my history of posting stupid questions
and as soon as a embarass myself the answer presents itself to me..
<p>So I've written a driver that gets multicast UDP packets from some source
and pushes them on the linux network queue. It works flawlessly with
unicast packets, very cool. My multicast packets don't seem to go
through though. The machine has an ethernet adaptor and my "adaptor"
which is called tv0. (the packets are coming from a satellite)
<p>Ethernet IP addr is 172.20.50.110
<br>Tv0 IP addr is 9.99.99.99 (cause 9 is easy to remember)
<p>I'm thinking that it has something to do with the subnet mask or my
"sink" I've been setting the subnet to be 255.255.255.0
<br>My test packets have a multicast addr of 239.255.0.1 I
don't remember seeing a lof of 255 or 0 in IP addrs but this makes it through
the is_it_our_multicast_packet test and goes on to the local delivery section
of the kernel. The src and dst ports are 7777 on the packets.
The packets are good and they get through the kernel.
<p>my test sink is this: it's ugly because it's been hacked to death...
If I pull out the mreq/setsockopt stuff and send unicast packets they route
through the kernel perfectly. When I sent multicast they get dropped
somewhere in the ip_local_deliver portion of the network stack which is
what makes me think it's my socket program or something to do with
my subnet. When I build the multicast list in (the setsockopt
builds a list in the kernel) the interface resolves to tv0 so I don't think
I need to do the IP_MULTICAST_IF option, anyone know?
<p>/*
<br> Stupid Socket code
<br>*/
<p>#include <stdio.h>
<br>#include <stdlib.h>
<br>#include <ctype.h>
<br>#include <string.h>
<p>#include <netdb.h>
<br>#include <sys/socket.h>
<br>#include <netinet/in.h>
<p>#define NUL
'\0' /* ASCII NUL character */
<p>int main(int argc, char*argv[] )
<br>{
<br> int sock,
newsock;
/* socket descriptor */
<br> struct hostent
*hp;
/* ptr to host info struct */
<br> struct servent
*sp;
/* ptr to service info struct */
<br> struct sockaddr_in server;
/* socket address and port */
<br> struct sockaddr_in theiraddr;
/* socket address and port */
<br> int
stat;
/* status return value */
<br> int rc;
<br> int sin_size;
<br> struct ip_mreq mreq;
<p> char buf[517];
/* most buffers aren't 517bytes, this allows for easier kernel debugging...
*/
<p>
/*------------------------------------------------------*/
<br> /* Create the
socket
*/
<br>
/*------------------------------------------------------*/
<p> sock = socket( PF_INET, SOCK_DGRAM,
0 );
<br> if (sock < 0)
<br> {
<br>
perror( "could not create socket" );
<br>
exit( 1 );
<br> }
<p>/* set up our side */
<br> server.sin_family = PF_INET;
<br> server.sin_port = htons(7777);
<br> server.sin_addr.s_addr =
inet_addr( "9.99.99.99" );
<p>/* set up their side */
<br> theiraddr.sin_family = PF_INET;
<br> theiraddr.sin_port = htons(7777);
<br> theiraddr.sin_addr.s_addr
= htonl( INADDR_ANY );
<p> rc = bind( sock, (struct
sockaddr_in *) &server, sizeof(struct sockaddr));
<br> if ( rc < 0 ) {
<br>
perror("Bind failed\n");
<br>
exit( 1 );
<br> }
<p>/* set up socket to do multicast */
<br> mreq.imr_multiaddr.s_addr
= inet_addr("239.255.0.1");
<br> mreq.imr_interface.s_addr
= inet_addr("9.99.99.99");
<p> if(setsockopt(sock, IPPROTO_IP,
IP_ADD_MEMBERSHIP, &mreq, sizeof(struct ip_mreq)) < 0) {
<br> perror("setsockopt
failed");
<br> exit( 3 );
<br> }
<p> sin_size = sizeof(struct
sockaddr_in);
<br> while(1) {
<br> rc = recvfrom(
sock, buf, 517, 0, (struct sockaddr*)&theiraddr, &sin_size );
<br> printf("%d,
got one\n", rc);
<br> if(rc == -1)
<br>
perror("revcfrom error:");
<br> }
<p> close( sock );
<br> exit( 0 );
<br>}
<br>
<p>Any obvious flaws you can see? The other side of this is that
there must be something screwed up with my driver that blocks multicast
out but it's much deeper than the normal filtering in the kernel.
My printks have been causing me some crashing problems as I get closer
to the socket code (any ideas? I've got pints for payment) so I've
decided that the easier approach at this point is to make sure my test
program works...
<p>thanks,
<br>Ian
<pre>--
Ian S. Nelson
[EMAIL PROTECTED]</pre>
</blockquote>
<pre>--
Ian S. Nelson
[EMAIL PROTECTED]</pre>
</html>
==============0AC4EB66917FF6F0DD10423C==
------------------------------
From: fhc <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: touch panel
Date: Sat, 27 May 2000 10:07:02 -0600
sllai wrote:
>
> I would like to know in order to control the touch panel, what are the
> things I need to know.
> Does the Linux OS have the touch panel driver. I knew that in the KDE for
> GUI development contain the mouse operation to indicate the mouse movement
> and mouse click. Howevr, what should I use if I use the touch panel to
> activate the progarm and not the mouse click action.
> Can somebody provide some info regarding this.
>
> thanks
> sllai
X Window System provides support for a few devices including some touch
screens I believe. Look at the documentation for XF86Config file. Just
for fun I set up the computer to be controlled by a joystick. You can
set it up to auto switch or require a manual switch (by calling some
utilitie or function). You can use this technique to add as many input
devices as you want. Anyway, hope it supports your screen.
Frank Carney
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: Craig Kelley <[EMAIL PROTECTED]>
Date: 24 May 2000 12:32:39 -0600
[EMAIL PROTECTED] (JEDIDIAH) writes:
> >But there is no reason to expect it to be any better. Is there a tool
> >that tells you when the last program that uses a shared library
> >has been removed?
>
> Sure there is. It could query the actual state of the system
> rather than just keeping track of what packages had been
> manipulated.
A database is the only way to really solve this problem with any
speed. Sure, you could find(1) all executables and ldd them to see
which libraries they use, but what a waste of time. It won't even
work all the time (What about an application which is on an unmounted
disk? What about an application which uses dlopen(3)?)
For all the faults in dpkg and rpm; they are light-years ahead of
autoconf, even for source (which I usually use -- I hate precompiled
stuff).
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
** 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
******************************
