Linux-Development-Sys Digest #2, Volume #7 Wed, 28 Jul 99 07:13:51 EDT
Contents:
Re: __socket (David T. Blake)
Why I can't compile my driver to SMP-Ready? ("robert_c")
Need help with PAM/g++ (lx)
Re: Intercepting network calls (Carlos Vidal)
problems with two network cards. Fundamental limitation? (Chetan Ahuja)
meaning of sched_rr_get_interval() (Kuniyasu Suzaki)
Re: reading damaged CDs ([EMAIL PROTECTED])
Re: MICROSOFT LINUX DISTRIBUTION (Klamer Schutte)
Re: problems with two network cards. Fundamental limitation? (Tony Gale)
Re: Formating from C code (Bernd Strieder)
Re: when will Linux support > 2GB file size??? (Graffiti)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: __socket
Date: 28 Jul 1999 01:34:34 GMT
Reply-To: [EMAIL PROTECTED]
Jen-Chieh Tang <[EMAIL PROTECTED]> wrote:
> Hello All :
>
> I have recently aquired some test code which includes the
> __socket function call. I can compile it into a .so file,
> but it fails giving the following error :
>
> LD_PRELOAD=./socket.so ping www.yahoo.com
> application called `socket'
> ping: error in loading shared libraries: ./socket.so: undefined symbol:
>__socket
>
> Does anyone know how to resolve this ? Thanks.
Don't use the __socket function call.
It is an internal function to glibc, and should not be
used outside of glibc. Try wading through the info tree
for libc::sockets for functions external to glibc. You
may try man socket, for example.
If you do decide to use internal functions to glibc you
can expect your binaries to break on glibc upgrades.
As an addendum, you can try compiling and running it on a
glibc2.0 system to see if that works first before rewriting
the socket code.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: "robert_c" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Why I can't compile my driver to SMP-Ready?
Date: 28 Jul 1999 02:19:42 GMT
Hello:
Could someone tell me why I can't compile my UP-Ready Driver into SMP-Ready
Driver. The following is my operations steps. Could you give me some advice?
Thanks.
1. in the /usr/src/linux
issue command: "make config"( just answer "Y" in support "CONFIG_SMP"
option, others keep no change)
2. in the same directory
issue command: "make dep"
3. go to my driver directory <-- Question 1: Is it needed to put our driver
code into /usr/src/linux/drivers/misc? I think it is not necessary, isn't
it?
cd /robert/
4. compile our driver code
gcc -D__SMP__ -D__KERNEL__ -DMODULE -DMODVERSIONS -O -w -c MyDriver.c
<---- Question 2: Does it need another option? (and in my MyDriver.h, I have
included <linux/modversions.h>)
5. Compile OK!
6. insmod in current directory, not in /lib/modules/2.2.5-15smp/misc <----
Question 3: Does it be necessary to move to the certain directory?
insmod -f MyDriver.o
7. It told me some error like following:
Warning: kernel-module version mismatch
MyDriver.o was compiled for kernel version 2.2.5-15<------ The same
error like before
while this kernel is version 2.2.5-15smp
MyDriver.o: unresolved symbol schedule_timeout_R17d59d01
MyDriver.o: unresolved symbol release_region_R43bde9b1
MyDriver.o: unresolved symbol boot_cpu_data_R660bd466
MyDriver.o: unresolved symbol kmalloc_R93d4cfe6
MyDriver.o: unresolved symbol unregister_chrdev_Rc192d491
MyDriver.o: unresolved symbol __verify_write_R203afbeb
MyDriver.o: unresolved symbol register_chrdev_R0f33bd81
MyDriver.o: unresolved symbol add_timer_Rbea990b2
MyDriver.o: unresolved symbol jiffies_R0da02d67
MyDriver.o: unresolved symbol request_region_R6d32b2d7
MyDriver.o: unresolved symbol check_region_R522f4d72
MyDriver.o: unresolved symbol kfree_R037a0cba
MyDriver.o: unresolved symbol memcpy_fromfs
MyDriver.o: unresolved symbol printk_R1b7d4074
.....
And I check my kernel supported function like schedule_timeout, issue
command like following:
[root@robert MyDriver]# ksyms -a|grep schedule_timeout
c011215c schedule_timeout_Rsmp_17d59d01
^^^
I got the reason why I can't insmod my SMP-driver into SMP-Kernel, because
my driver still is UP-Driver. But how to change it to SMP-Ready Driver?
8. Sorry to bother you again. Could you give me a example driver (just say
"Hello"), and a easy Makefile, and some operation steps. Because I always
get failed for this problem.
Appreciate for any your advices.
Best Regards,
Robert
------------------------------
From: lx <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Need help with PAM/g++
Date: 27 Jul 1999 15:15:18 GMT
This seems like such a simple problem, but it's just not working
out that way. ;)
I have successfully completed an application in C which utilizes
the pam (0.66) libraries to authenticate a user via the system's
passwd list. It works great; compiles, executes, gives valid data.
I have compiled it with gcc, egcs 2.91.66 (and running Redhat 6.0).
I am trying to suture it into the mother application, which is in
C++, and upon running the same compile request with g++ rather
than gcc, I get "undefined references" on the pam libs.
These are my command lines:
gcc auth.c -o auth -ldl -lpam -lpam_misc
g++ auth.c -o auth -ldl -lpam -lpam_misc
The first works. The second yields undefined references on PAM
functions described in both libpam.so and libpam_misc.so. What on
earth is going on here??
If any of you UNIX gurus can assist on this, I will be more than
a little in your debt.
Thanks in advance,
.lx
--
[ [EMAIL PROTECTED] -- http://www.audiophonic.com/lx/ ]
[ "in a mirror, all the time turns counter-clockwise." ]
[ "and every time i look, i find my face has changed." ]
------------------------------
From: Carlos Vidal <[EMAIL PROTECTED]>
Subject: Re: Intercepting network calls
Date: Wed, 28 Jul 1999 08:46:02 +0200
Anand Paka wrote:
>
> Hi,
>
> I'm new to Linux and am looking around for a mechanism to intercept all
> the sockets calls made. My intention is to monitor the socket traffic,
> their types, usage etc. for all application using the network resources.
> (This should be transparent to the application).
Check 'ntop' at http://www-serra.unipi.it/~ntop. It's quite close to
what you want and it's www interface is great.
--
Carlos Vidal
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Chetan Ahuja)
Subject: problems with two network cards. Fundamental limitation?
Date: 28 Jul 1999 07:53:37 GMT
Hi,
I posted this a few weeks ago on the networking group but got
absolutely no replies. This might be a better place for such a question.
So here goes...
I have made a router out of a pentium 60 using the LRP (Linux Router
Project based on 2.0.36 modified a little) distro. It has two network
cards ( One Tulip based and the other via-rhine based) One talks to my
internal network and the other one talks to the external world. Now,
the external connection ( through xDSL) goes dead sometimes due to
problems beyond my control. The problem is, when that happens, I can't
even telnet into the box through it's internal interface. I can still
ping the box though. But no telnet. If a kernel hacker is reading
this, could you tell me where exactly is the problem. Is it a hardware
driver level problem, TCP/IP stack problem, or even a tcp-wrapper
problem ( all servers on the router box are invoked through inetd). My
guess is that the external connection is blocking on a read/write and
that somehow blocks the internal connection too.. ( or is it supposed
to be obvious and I am just exposing the limits of my knowledge here)
Is there a fix for it...(or has it been taken care in later kernels in
2.2 series ) or is it a fundamental limitation of the kernel
architecture ??? If you can point me to a source file in the kernel tree,
or other sources of information, that will be good too...
Chetan
--
------------------------------
From: [EMAIL PROTECTED] (Kuniyasu Suzaki)
Crossposted-To: comp.os.linux.questions
Subject: meaning of sched_rr_get_interval()
Date: 28 Jul 1999 08:03:54 GMT
Dear,
Please tell me the meaning of sched_rr_get_interval().
I was thinking it returns the period of round robin scheduling at
"SCHED_RR". However the return value of sched_rr_get_interval() and
the real period of round robin scheduling were different. I add the
check program at the bottom of this mail.
The period of round robin scheduling was looked to be decided by the
"counter" value of task struct which showed the priority. The return
value of sched_rr_get_interval() was fixed 150us in "kernel/sched.c".
What does the time 150us mean? Why doesn't sched_rr_get_interval()
return the real period of round robin?
Please tell me the the meaning. Thank you.
P.S.
On Solaris sched_rr_get_interval() returned the real period of round
robin.
P.P.S.
The check program did not work well on kernel 2.2.*. It looked like
that context switch did not work well on "RR_SCHED".
Sincerely yours,
Kuniyasu Suzaki
Electrotechnical Lab
======= check program "rr_time.c" =======
/*
Linux
gcc -o rr_time rr_time.c
Solaris
gcc -DSOLARIS -o rr_time rr_time.c -lposix4
*/
#include <unistd.h>
#include <sched.h>
#include <stdio.h>
#include <errno.h>
#include <sys/time.h>
#include <time.h>
#include <signal.h>
#include <sys/types.h>
#include <sched.h>
#define TIMES 10
main()
{
int max;
pid_t child;
int i;
int policy;
float ftmp;
struct sched_param param;
struct timespec rr_period;
struct timeval on[TIMES];
struct timeval off[TIMES];
struct timezone tz;
if((max = sched_get_priority_max(SCHED_RR)) == -1) {
perror("sched_get_priority_max");
exit(1);
}
param.sched_priority = max;
if(sched_setscheduler(getpid(),SCHED_RR,¶m) == -1){
perror("sched_setscheduler");
exit(1);
}
if((policy = sched_getscheduler(getpid())) != -1) {
switch(policy) {
case 0:
printf("SCHED_OTHER\n");
break;
case 1:
printf("SCHED_FIFO\n");
break;
case 2:
printf("SCHED_RR\n");
break;
#ifdef SOLARIS
case 3:
printf("SCHED_SYS\n");
break;
case 4:
printf("SCHED_IA\n");
break;
case 5:
printf("_SCHED_NEXT\n");
break;
#endif
default:
printf("Unknown Scheduling (No.%d)\n",policy);
break;
}
}
if(sched_getparam(getpid(),¶m) != 0) {
perror("sched_getparam");
exit(1);
}
printf("priority = %d\n",param.sched_priority);
if(sched_rr_get_interval(0,&rr_period) == -1) {
perror("sched_rr_get_interval");
exit(1);
}
printf("Default RR interval = %e\n",((double)rr_period.tv_sec) +
(((double)rr_period.tv_nsec)*0.000000001));
child = fork();
if(child == 0) {
/*** child process ***/
/*** it inherits SCHED_RR scheduling. ***/
while(1) {
for(i = 0; i < 100; i++) {
ftmp = (float)(1) / 1000.0;
}
}
exit(1); /*** never reach ***/
}
for(i = 0; i < TIMES; i++) {
gettimeofday(&(on[i]),&tz);
if(sched_yield() == -1) {
perror("sched_yield()");
exit(1);
}
gettimeofday(&(off[i]),&tz);
}
printf("%d %d\n",getpid(),child);
kill(child,SIGINT);
for(i = 0; i < TIMES; i++) {
printf("%f sec (%f%%)\n",
((double)(off[i].tv_sec - on[i].tv_sec)) + (((double)(off[i].tv_usec -
on[i].tv_usec))*0.000001),
((((double)(off[i].tv_sec - on[i].tv_sec)) + (((double)(off[i].tv_usec -
on[i].tv_usec))*0.000001)) * 100.0)
/ (((double)rr_period.tv_sec) + (((double)rr_period.tv_nsec)*0.000000001))
);
}
exit(1);
}
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: reading damaged CDs
Date: 28 Jul 1999 08:43:16 GMT
[EMAIL PROTECTED] wrote:
: It seems that in /usr/include/cdrom.h there's a way to make the cdrom
: driver ignore bad blocks or at least not throw an EIO back when read(2)ing
: a damaged block. How is this done?
For audio CDs, you could use CDPARANOIA.
Maybe you could also look at the source for
CDPARANOIA to find out how it skips blocks
(perhaps audio CD specific, though).
Rich.
--
[EMAIL PROTECTED] | Free email for life at: http://www.postmaster.co.uk/
BiblioTech Ltd, Unit 2 Piper Centre, 50 Carnwath Road, London, SW6 3EG.
+44 171 384 6917 | Click here to play XRacer: http://xracer.annexia.org/
--- Original message content Copyright � 1999 Richard Jones ---
------------------------------
From: Klamer Schutte <[EMAIL PROTECTED]>
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: Mon, 26 Jul 1999 23:02:11 +0200
Samuel Brown wrote:
> I had a someone tell me that Microsoft will sell their own linux
> distribution. Is this true?
> It will have word and excel 2000 also.
If that would provide perfect file compatibility with Office'97 then I
definitely would be interested in that distribution (most likely
only in these two programs -- or is there also a powerpoint? ;-)
Klamer
------------------------------
From: [EMAIL PROTECTED] (Tony Gale)
Subject: Re: problems with two network cards. Fundamental limitation?
Date: 28 Jul 1999 09:11:08 GMT
In article <7nmcu2$l3d$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Chetan Ahuja) writes:
> I have made a router out of a pentium 60 using the LRP (Linux Router
> Project based on 2.0.36 modified a little) distro. It has two network
> cards ( One Tulip based and the other via-rhine based) One talks to my
> internal network and the other one talks to the external world. Now,
> the external connection ( through xDSL) goes dead sometimes due to
> problems beyond my control. The problem is, when that happens, I can't
> even telnet into the box through it's internal interface. I can still
> ping the box though. But no telnet. If a kernel hacker is reading
> this, could you tell me where exactly is the problem. Is it a hardware
> driver level problem, TCP/IP stack problem, or even a tcp-wrapper
> problem ( all servers on the router box are invoked through inetd). My
> guess is that the external connection is blocking on a read/write and
> that somehow blocks the internal connection too.. ( or is it supposed
> to be obvious and I am just exposing the limits of my knowledge here)
> Is there a fix for it...(or has it been taken care in later kernels in
> 2.2 series ) or is it a fundamental limitation of the kernel
> architecture ??? If you can point me to a source file in the kernel tree,
> or other sources of information, that will be good too...
>
Is, by any chance, your DNS server on the side that goes down?
-tony
--
E-Mail: Tony Gale <[EMAIL PROTECTED]>
The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Formating from C code
Date: Wed, 28 Jul 1999 11:52:09 +0200
Hi
Neal Richter wrote:
>
> Hello,
> Could someone please direct me to some sample code and/or documentation
> of formating drives from C/C++ code... Partitioning would be good too.
>
> I'm hoping that the basic command-line utilities are avaliable in a
> library somewhere..
>
> Thanks!
>
> Neal
How about system("mkfs.ext2 ......")? This makes your code much easier
since you need not include the real code which might be outdated some
day. And your app gets more portable. Many linux distributions include
some configuration utility which gives a front end to fdisk/cfdisk and
mkfs, respectively . This is used to be done by remotely controlling
fdisk/cfdisk from the utility by simulating user input, I think this was
at least the case with SuSE.
I would strongly recommend to not include the real code within your app.
Look in the man-Pages about "system", "fork", pipes and the like, and
you will get the idea of the UNIX philosophy to build up your solution
out of the toolbox of small solutions.
Regards,
Bernd Strieder
------------------------------
From: Graffiti <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 27 Jul 1999 12:15:52 -0700
In article <[EMAIL PROTECTED]>,
Philip Brown <[EMAIL PROTECTED]> wrote:
[snip]
>>fd = open("/opt/bloated_commercial_database/data/big_fat_table.dat");
>>foo = mmap(start, 100000000000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
>
>Yes, I know that. However, that's not the ONLY way databases work.
>They can be reformulated to work with "raw" devices, which don't support
>memory mapping. Yes, I know there aren't too many databases for linux that
That's aside the point, since this discussion is about supporting files that
require 64-bits to represent the size, not raw device access. :-)
>support this. But it's not impossible with the existing VM, like you seem to
>be making it out.
Not impossible, no, but hard as hell to do cleanly (and in such a way that Linus
will accept it, assuming it's even possible: if you want to maintain/use custom
non-mainstream patches, that's a different thing. The main point that others
made is about tossing this feature in the *main* kernel source tree.)
>>And again, I tell you, THE FILESYSTEM DOES NOT SUPPORT MEMORY MAPPING.
>
>And again, I tell you, "SO WHAT" :-)
You said you'd rather fiddle w/ the filesystem to use 64 bit files. Ext2 already
supports 64-bit files.
>>So would I. IF IT WORKS. It won't.
>
>If I wasn't already busy writing solaris drivers, I'd love to shove code in
>your face to prove you wrong :-)
Sure, gimme a small snippet.
>Bottom line:
>
>If you have an application, and all it wants to do is do
>
> while(1){
> lseek64()
> read/write()
> }
>
>on a really large data file, it should be doable on a 32-bit VM system, with
>some custom filesystem rewrites, and possibly an override of the lseek64()
>libc routine.
If that's all it wants to do, yes, you can with the current VM on 32-bit systems.
The question becomes, then, how much of the regular UNIX/BSD/Standard-of-the-week
API do you support? If you want to write custom code to act as replacements for
it on a source level and link only against the new libraries, that's an option.
That also means you can't use any existing libraries/binaries/etc. Your existing
tools no longer work (cp, mv, tar, cpio). You have to re-write or re-compile
*everything* that might at some point have to deal with 64-bit files.
>It won't be pretty. It won't be efficient. But it is doable, and safer
>than messing around with the VM system.
>[On the other hand, it may end up being a lot more work. But since I'm not
> the one who needs it, I don't care :-) ]
Yes, it will be a hell of a lot of work. And you'll have a large set of regular
library calls that can't work on the "64-bit file" anymore, so you'll have to
explicitly list the supported routines.
Remember, this isn't about "Is it possible?", but "Is it practical?". And I'd say
NO to the latter.
-- DN
------------------------------
** 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
******************************
