Linux-Development-Sys Digest #52, Volume #8 Sat, 29 Jul 00 10:13:07 EDT
Contents:
Re: test (bill davidsen)
Re: test (Johan Kullstam)
Re: library to implement NFS (Erik de Castro Lopo)
USER Space not right! ("Rob Morris")
Re: Tracing fork system calls. (David Wragg)
USER SPACE not right. divice driver. ("Rob Morris")
What about multiple SYN's? (Andr�s Gri��)
Re: library to implement NFS (phil hunt)
Re: exec*() and argv[0] (John Reiser)
interrupt ("Peter Huang")
Re: What about multiple SYN's? ("Eric A. Hall")
Re: library to implement NFS (Nic)
Re: interrupt (Pete Zaitcev)
siginfo->si_pid and siginfo->si_gid always zero? (Noam Koren)
Re: Kernel 2.4 question (Donald Becker)
Re: RedHat 6.1 kernel module oddities (Donald Becker)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: test
Date: 28 Jul 2000 19:33:56 GMT
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
|
| please ignore. i don't have alt.test and my nntp server has been
| giving grief.
How about putting Distribution: local in the next one?
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: test
Date: 28 Jul 2000 15:47:25 -0400
[EMAIL PROTECTED] (bill davidsen) writes:
> In article <[EMAIL PROTECTED]>,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> |
> | please ignore. i don't have alt.test and my nntp server has been
> | giving grief.
>
> How about putting Distribution: local in the next one?
because my posts were getting to the local server. distribution local
was working fine. they just weren't going anywhere after that. i
should have just added some two-cents of drivel to some random thread
but i figured clueful users would have apply a large negative score or
kill to any messages with subject "test" and never be bothered by it
at all.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
sysengr
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: library to implement NFS
Date: Fri, 28 Jul 2000 20:55:22 +0000
phil hunt wrote:
>
> I'm looking for software that will enable me to implement a
> filing system that communicates using the NFS protocol.
>
> Does anyone know of any well-documented C or C++ libraries that
> will allow me to do that, available on an open-source licence?
Why do you need a library? Couldn't you just mount the NFS drive
and use the standard fopen/fread/fwrite/fclose calls?
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
"He's a born-again Christian. The trouble is, he suffered brain
damage during rebirth."
------------------------------
From: "Rob Morris" <[EMAIL PROTECTED]>
Subject: USER Space not right!
Date: Fri, 28 Jul 2000 14:21:35 -0700
The sample program, testdriver, by Gavin Smyth, compiles and installs with
some modifications (like register_symtab() is gone and memcpy_tofs() changed
to copy_to_user() ).
When I ran application, open() works fine, bur read() ends up with an error.
It seems : filp in the argument list of testdriver_read(idone, filp, buf,
count) has no info that was initialized when testdriver_open ran. I can get
around that by using the declared struct testdriverDev instead of filp.
But the biggest problem is that the address in "buf", a pointer suppesed
given by the user application. It seems bogus, and ends up with
segmentation error in copy_to_user().
Can anyone help me? Thank you.
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux
Subject: Re: Tracing fork system calls.
Date: 28 Jul 2000 21:19:22 +0000
Tim Muir <[EMAIL PROTECTED]> writes:
> I was hoping not to have to alter the kernel source, but if I must, I
> must. My problem begins when tracing a fork call.
In 2.3/2.4, there is a CLONE_PTRACE flag to clone, which allows the
child to inherit the traced status of the parent. Also, with
PTRACE_SYSCALL you can adjust the registers, including the syscall
number. So it should be possible to do what you want by turning a
fork() into a clone() with the CLONE_PTRACE flag.
David Wragg
------------------------------
From: "Rob Morris" <[EMAIL PROTECTED]>
Subject: USER SPACE not right. divice driver.
Date: Fri, 28 Jul 2000 15:33:10 -0700
This is additional info to the previous post, USER space not right.
On testdriver device driver.
fd = open("/dev/testdriver", O_RDWR);
read(fd, buf, 9);
so, testdriver_read(idone, filp, buf,count) should see 9 in count. But it
is
a huge negative number. The error message is
Unable to handle kernel NULL pointer dereference at virtual address
00000000.
then
register dump
then
Stack dump
I can see 9 is on the stack but testdriver_read is not getting it.
Can anyone help? Thank you.
------------------------------
From: [EMAIL PROTECTED] (Andr�s Gri��)
Crossposted-To: comp.protocols.tcp-ip
Subject: What about multiple SYN's?
Date: Tue, 25 Jul 2000 15:55:26 GMT
While looking at trace of TPC/IP session between a Red Hat Linux 6.2 and a IBM
S/390 with Connectivity Systems's TCP/IP for VSE 1.4, I found this odd packet
exchange:
(I omit the first part of secuence number as they remain the same across the
trace - the display is in tcpdump format).
ibm.721 -> linux.515: S 58:58
linux.515 -> ibm.721: S 2187:2187 ACK 59
ibm.721 -> linux.515: S 60:60
linux.515 -> ibm.721: S 5956:5956 ACK 61
The TCP/IP for VSE tried to open two session using the same origin and
destination ports. That's another error of that bug ridden TCP/IP stack
(sending duplicate ACK is another one).
Next Connectivity Systems' TCP/IP send a reset:
ibm.721 -> linux.515: R 61:61
And Linux tries to resync the two starting sessions:
linux.515 -> ibm.721: S 2187:2187 ACK 59
linux.515 -> ibm.721: S 5956:5956 ACK 61
And Connectivity Systems' TCP/IP send another reset ...
I check the RFC 793, but I was unable to reach a conclusion.
I think Linux is thinking these are two separate connections, even if they use
the same origen-dest ports.
IMHO, Linux is not handling well this case, but I wonder what's the appropiate
answer to this situation.
Yours
Andr�s Gri��
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: library to implement NFS
Date: Sat, 29 Jul 2000 00:15:32 +0100
On Fri, 28 Jul 2000 20:55:22 +0000, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>>
>> I'm looking for software that will enable me to implement a
>> filing system that communicates using the NFS protocol.
>>
>> Does anyone know of any well-documented C or C++ libraries that
>> will allow me to do that, available on an open-source licence?
>
>Why do you need a library? Couldn't you just mount the NFS drive
>and use the standard fopen/fread/fwrite/fclose calls?
Because what I want to do is the opposite.
I want to write a program that emulates an NFS server. So other
programs will call my program, using the NFS protocol, and ask it
for files, etc. Then my program will respond by sending the files.
--
***** Phil Hunt *****
The RIAA have banned Napster -- so boycott the music industry!
Don't buy any CDs during August (especially on Tuesday 1st August).
Spread the word: put this message in your sig, tell all your friends.
See website <http://boycott-riaa.com/>.
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: exec*() and argv[0]
Date: Fri, 28 Jul 2000 17:45:22 -0700
> When you run a
> script starting with #!, argv[0] is set to only the program name, not
> the full path. For example, if you have #!/www/python/bin/python,
> argv[0] is set to just "python", which we found caused Python to fall
> back to looking along the path for its libraries, and finding the
> wrong version (we have Python installed in a non-standard place).
Try this:
===== file /tmp/foo
#!/bin/echo
=====
===== shell transcript
$ chmod +x /tmp/foo
$ /tmp/foo 1 2 3
/tmp/foo 1 2 3
$
=====
So the pathname of the original exec()ed script becomes argv[1],
and the script interpreter can read that file and do whatever
it wants, including discovering the path that follows #!.
It seems to me that Linux tries to follow the original UNIX _convention_,
namely that argv[0] is the last component of the pathname that is
specified as the first argument to exec().
In general, a process that tries to infer any information from the
pathname that was exec()ed is doomed to failure. There simply is
no guarantee about whether that pathname still has any relevance at all.
Any number of unlink, chdir, unmount, chroot, etc. (by this process
or any other) could have taken place between the exec() and the
attempted inference. Do not attempt to infer an "installation
directory", the location of any "preferences file", etc., from
the pathname to exec(). [Also remember /proc/self/exe, for what
it is worth.]
If you _really_ want to know what the pathname was, Linux helps
you by putting it at the fixed end of the stack. On common x86
systems where the stack ends at 0xc0000000, then 0xbffffffc has
32 bits of 0, and 0xbffffffb has the '\0' which terminates the
pathname. So search backwards for another '\0', and the pathname
lies between.
--
John Reiser, [EMAIL PROTECTED]
------------------------------
From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: interrupt
Date: Fri, 28 Jul 2000 17:43:19 -0700
Hi
Right now, I have a EBSA285 card that attach to the PCI of my system. I have
it generate a interrupt by setting a doorbell mask and register. In my
driver, I have this line
if(request_irq(pci_irq,pci_test_interrupt,SA_SHIRQ,"testpci",&pci_id_array[s
Cnt]))
pci_irq is from pdev->irq and pdev is from pci_find_device
pci_test_interrupt function contains only one printk line.
"testpci" name is same as the driver registered name.
&pci_id_array[sCnt] contain the structure element that has the vendor id and
device id of EBSA_285.
Right now, the Linux system hangs up once I enable the doorbell mask and
register, which sends a interrupt to the Linux host. Can anyone tell me what
I'm doing wrong. Do I have to explicitly turn off the interrupt from the
Linux driver? What am I missing here?
Peter
------------------------------
From: "Eric A. Hall" <[EMAIL PROTECTED]>
Crossposted-To: comp.protocols.tcp-ip
Subject: Re: What about multiple SYN's?
Date: 28 Jul 2000 21:17:39 EDT
> While looking at trace of TPC/IP session between a Red Hat Linux 6.2
> and a IBM S/390 with Connectivity Systems's TCP/IP for VSE 1.4, I
> found this odd packet exchange:
> ibm.721 -> linux.515: S 58:58
> linux.515 -> ibm.721: S 2187:2187 ACK 59
After the first SYN was SYN/ACK'd, the first circuit should be in an
established state on the IBM box (sort of, it never sent an ACK for the
SYN/ACK so it never completed the three-way handshake, but it did get
past SYN-SENT, and probably would get further if not for the next
segment). The Linux box is in the SYN-RECEIVED state.
> ibm.721 -> linux.515: S 60:60
> linux.515 -> ibm.721: S 5956:5956 ACK 61
The Linux box should RST this (making an assumption about window sizes
here, we need the full data to be precise).
Instead, the second connection also enters the SYN-RECEIVED state.
> Next Connectivity Systems' TCP/IP send a reset:
>
> ibm.721 -> linux.515: R 61:61
The IBM box properly RSTs the second SYN.
The Linux box is receiving a RST on the second circuit. According to RFC
793, page 32, it should destroy the second connection after receiving
the RST:
If the receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
One of the two systems would probably have eventually reissued the SYN
or SYN/ACK segments for the other connection and operations would have
returned to normal. Maybe.
> And Linux tries to resync the two starting sessions:
>
> linux.515 -> ibm.721: S 2187:2187 ACK 59
> linux.515 -> ibm.721: S 5956:5956 ACK 61
As stated above, the Linux box should have destroyed the second
connection once it received a RST while still in SYN-RECEIVED.
> I check the RFC 793, but I was unable to reach a conclusion.
There are three problems here. The first one you know about, which is
that the IBM box is retransmitting the connection request for some
reason. That's bad form and must be fixed.
The second issue is that the Linux box should be issuing RST on the
second connection request since the SYN was out of place for the
original connection (it's in SYN-RECEIVED so should be getting an ACK
not a SYN).
The third issue is that the Linux box is not aborting the second
connection after getting the RST from the IBM box. If it dropped that
connection, then the first connection would probably get off the ground
again sooner or later. Maybe, who knows what will happen next.
3.4. Establishing a connection
The "three-way handshake" is the procedure used to establish a
connection. This procedure normally is initiated by one TCP and
responded to by another TCP. The procedure also works if two TCP
simultaneously initiate the procedure. When simultaneous attempt
occurs, each TCP receives a "SYN" segment which carries no
acknowledgment after it has sent a "SYN". Of course, the arrival of
an old duplicate "SYN" segment can potentially make it appear, to the
recipient, that a simultaneous connection initiation is in progress.
Proper use of "reset" segments can disambiguate these cases.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
------------------------------
From: Nic <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: library to implement NFS
Date: Sat, 29 Jul 2000 13:20:00 +1200
phil hunt wrote:
>
> I want to write a program that emulates an NFS server. So other
> programs will call my program, using the NFS protocol, and ask it
> for files, etc. Then my program will respond by sending the files.
I believe CFS (crypto file system) is implemented as an NFS server, so
it may be worth taking a look at.
http://the.wiretapped.net/security/cryptography/filesystems/cfs-1.3.3.tar.gz
Regards,
Nic.
--
My non-official mailbox: < sky at wibble dot net >
Internet Software & Security Consulting - http://www.bellamy.co.nz/
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: interrupt
Date: Sat, 29 Jul 2000 05:13:16 GMT
> Right now, the Linux system hangs up once I enable the doorbell mask and
> register, which sends a interrupt to the Linux host. Can anyone tell me what
> I'm doing wrong. Do I have to explicitly turn off the interrupt from the
> Linux driver? What am I missing here?
You must program your device to stop issuing the interrupt signal.
--Pete
------------------------------
From: Noam Koren <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: siginfo->si_pid and siginfo->si_gid always zero?
Date: Sat, 29 Jul 2000 15:56:17 +0300
Hi,
I wrote a signal handler that uses the SA_SIGINFO flag and was installed
using the sa_sigaction parameter. I did this in order to make use of the
siginfo_t which should be passed to the handler (see: man sigaction).
However, when the handler is invoked (after a kill(pid,SIGUSR1) in a
child process), only the si_signo is filled correctly in the siginfo_t
struct (si_uid and si_pid are 0).
Any ideas?
The handler begins like this:
void handler(int signo, siginfo_t * siginfo,ucontext * uc){
int a;
pid_t b;
uid_t c;
a=siginfo->si_signo;
b=siginfo->si_pid; // this always returns 0
c=siginfo->si_uid; // this always returns 0 (yes, even when I am not
root...)
...
...
}
Thanks in advance,
Noam
------------------------------
From: [EMAIL PROTECTED] (Donald Becker)
Subject: Re: Kernel 2.4 question
Date: Sat, 29 Jul 2000 13:17:47 GMT
In article <[EMAIL PROTECTED]>,
Andreas Jaeger <[EMAIL PROTECTED]> wrote:
>>>>>> Paul Kimoto writes:
>>> In article <[EMAIL PROTECTED]>,
>>> Todd Scheetz <[EMAIL PROTECTED]> wrote:
>>> | is kernel 2.4 capable of
>>> | accessing (reading and writing) files larger than 2 GB?
>>> Yes.
>Paul> I've read that rebuilt libraries and executables are needed, too. Do you
>Paul> know whether that's the case?
>
>You need to rebuild glibc (glibc 2.1.3 is needed) with the
>2.4. headers installed but you don't need to rebuild dynamically
>linked programs.
That's not correct, unless SuSE has done some additional work specific to
its own distribution.
Scyld has added LFS support to the 2.2.* kernel and done extensive testing,
so we have experience that relates to 2.4.* issues. It certainly not as
easy as using 2.4.0-preSomething and just recompiling glibc.
You might expect that LFS is trivial to do -- just a few minor kernel
patches for the x86-specific code, and everything else is known to work on
the 64 bit Alpha architecture. But we found that it involved significant
in-kernel work, glibc modifications, and fixing basic utilities such as
'grep' to work with x86 LFS support.
We started our LFS work 11 months ago, and thus we based it on 2.2.
It was easy to get a patch (ref Matti Arnio) that added nominal LFS support
to the 2.2 kernel. This allowed creation of a sparse 5GB file on ext2,
which is the usual extent that "demo-ware" is tested. (No disrespect to
Matti -- prototype developers are not responsible when others present their
code as a finished solution.)
We immediately saw that additional changes (essentially a rewrite of the
patch) was needed to make it usable. Most of the time, however, was spent
on library and utility issues. It takes a lot of time to construct test
cases, identify problems and track down the solutions. That includes
coverage testing for common but non-traditional uses such as loopback
mounting large files. (The loopback driver bug is a good example of why you
must test with dense files and sparse files with "holes" at different
boundaries.)
The Scyld LFS patches are, of course, released under the GPL.
The pre-built kernel, libc, and tested Posix utilities are available with
commercial support, and are also integrated with the new Scyld Beowulf-2
distribution.
--
Donald Becker [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations
Annapolis MD 21403
------------------------------
From: [EMAIL PROTECTED] (Donald Becker)
Subject: Re: RedHat 6.1 kernel module oddities
Date: Sat, 29 Jul 2000 13:38:27 GMT
In article <[EMAIL PROTECTED]>,
Richard Bonomo <[EMAIL PROTECTED]> wrote:
>Villy Kruse wrote:
>>
>> On Fri, 07 Jul 2000 17:39:31 -0500, Richard Bonomo <[EMAIL PROTECTED]> wrote:
>> >While calls to "inb" and "outb" worked just fine
>> >in a privileged user program, and while gcc -c <name>
>> >produces no errors, attempts to load the module
>> >(with insmod) immediately generates messages to the
>> >effect that outb and inb are not recognized symbols (!!).
>>
>> ioremap is an inline function, and that works only if you
>> compile with -O2. Same for inb and outb.
>>
>> These inline functions are defined in <asm/io.h>.
>
>Yes, I know they are defined in <asm/io.h>, but the
>subtlety about -O being REQUIRED had escaped me.
I used to get a dozen or so emails a day with people that didn't follow the
compile instructions until I put the following lines in my drivers:
#ifndef __KERNEL__
#define __KERNEL__
#endif
#if !defined(__OPTIMIZE__)
#warning You must compile this file with the correct options!
#warning See the last lines of the source file.
#error You must compile this driver with "-O".
#endif
>P.S. Do you know if there is a "sleep" or "usleep"
>function (or equivalent) available to the kernel, or
>is it necessary to employ a do-nothing loop to put
>in a delay?
Use 'usleep()', but only if you are delaying for a under 50 usec. *total*.
(Not in a loop.) If you need to wait longer, set a timer and return from
the interrupt or reschedule().
Never, ever write a loop that does "while (jiffies < endtime) ;" unless you
understand everything about the kernel.
(I have seen this style of delay loop called at interrupt time. It might
work some of the time, but consider nested interrupts or shared interrupts.)
--
Donald Becker [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations
Annapolis MD 21403
------------------------------
** 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
******************************
