Linux-Development-Sys Digest #830, Volume #7 Sun, 7 May 00 20:13:13 EDT
Contents:
Re: bash not core dumping, trying to solve it (Allin Cottrell)
Re: Need to find my IP address ("Christos Karayiannis")
RE:need to find my IP address ("Christos Karayiannis")
Re: Need help on a Code Launcher project (John Reiser)
Re: SHLVL discrepancies (Stephen Harris)
/proc/<pid>/mem access only to debuggers (Eric Taylor)
Re: Access user space address from kernel space (David Wragg)
Re: Need help on a Code Launcher project (David Wragg)
Re: RS-485 (Mario Klebsch)
Re: Need to find my IP address (Chris)
Re: Need to find my IP address (Chris)
Re: Need to find my IP address (Chris)
Re: Need to find my IP address (brian moore)
Re: Need to find my IP address (brian moore)
----------------------------------------------------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: bash not core dumping, trying to solve it
Date: Sun, 07 May 2000 12:29:55 -0400
Patrick Draper wrote:
>
> This is what I am trying to allow normal users to get core dumps, which
> are essential to programming in my opinion.
man 5 initscript
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
From: "Christos Karayiannis" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Sun, 7 May 2000 20:56:58 +0300
> > > I used getsockname() as:
> > > if (getsockname(sock, (struct sockaddr *) &host, &addrlen) < 0 ) {
> > > perror("getsockname");
> > > exit(1);
> > > }
> > >
> > > printf("My port is %d\n", ntohs(host.sin_port));
> > > printf("My address is %s\n", inet_ntoa(host.sin_addr.s_addr));
> > >
> > >
> > > where host was of type struct sockaddr_in and
> > > addrlen of type int.
> > >
> > > Christos Karayiannis
> > >
Doug Schulz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have a sockets program an need to find the IP address of the machine
> the program is being run from so I can bind the socket to the correct
> address/port. I have tried using gethostname coupled with gethostbyname
> and I can only get 127.0.0.1 (localhost address). I want to find the
> actual IP address of the machine. Is there a way of doing this. Any
> help would be great.
>
> FYI this is a UDP app.
>
> Thanks,
>
> Doug
>
------------------------------
From: "Christos Karayiannis" <[EMAIL PROTECTED]>
Subject: RE:need to find my IP address
Date: Sun, 7 May 2000 20:58:20 +0300
> > > I used getsockname() as:
> > > if (getsockname(sock, (struct sockaddr *) &host, &addrlen) < 0 ) {
> > > perror("getsockname");
> > > exit(1);
> > > }
> > >
> > > printf("My port is %d\n", ntohs(host.sin_port));
> > > printf("My address is %s\n", inet_ntoa(host.sin_addr.s_addr));
> > >
> > >
> > > where host was of type struct sockaddr_in and
> > > addrlen of type int.
> > >
> > > Christos Karayiannis
> > >
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: Need help on a Code Launcher project
Date: Sun, 07 May 2000 11:42:12 -0700
Also look at strace (/usr/bin/strace; "man strace").
--
John Reiser, [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Stephen Harris)
Subject: Re: SHLVL discrepancies
Date: Sun, 7 May 2000 14:28:28 GMT
Anton North ([EMAIL PROTECTED]) wrote:
: When I am running one shell, my SHLVL environment variable is set to 1, and
: increments by 1 for every other shell that I run, which makes sense.
: However, if I look at the environ file in /proc/<pid_of_shell>, I see that
: for the first instance of my shell, no SHLVL exists.
It hasn't been exported to the environment at that stage
: If I create a second shell, and check it's environ file in /proc, I find now
: that SHLVL exists, and is set to 1. If I run a third shell, it gets set to
: 2, etc.
SHLVL is maintained by the shell itself. In your case it is probably bash.
Other shells (eg a real Bourne shell, or ash or ksh) may not track SHLVL as
you expect. For example, ksh93 doesn't maintain it.
: My question is why this confusing system? I want to run a script that will
: kill wayward processes started by users, but _not_ terminate their original,
: logged in shell. I thought to use the SHLVL's listed in the environ files in
: /proc to do this, and want to make sure that this value is reliable.
This is non-standard and non-portable way of detecting wayward processes, and
not guaranteed to work in any way shape or form - even on your own box :-)
--
Stephen Harris
[EMAIL PROTECTED] http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: /proc/<pid>/mem access only to debuggers
Date: Sun, 07 May 2000 12:44:47 -0700
I checked out why the /proc/<pid>/mem file
cannot be casually read. It requires that you are
a debugger (defined as a process that has attached
via ptrace). If not, you get the error return of
no such process.
To see what would happen, I relaxed the requirement
and built a kernel. I didn't have any untoward results.
This code has been entirely re-written recently, yet
the requirement of being a ptrace debugger has remained.
Below is the macro that enforces the check.
Latest Kernel: Base.c
#define MAY_PTRACE(p) \
(p==current||(p->p_pptr==current&&
(p->flags&PF_PTRACED)&&p->state==TASK_STOPPED))
The ptrace requirement limits the number of processes
that can access /proc/pid/mem at the same time to 1-only.
I could live with a requirement of something like
the accessing task be su or root or the same uid,
or gid or some such but I need to permit
reading (at least) w/o being a ptrace debugger
(because the process is allready being ptraced by gdb).
Requiring the task to be stopped probably is a safety issue,
and I can live with that one.
Does anyone know of some other reason why this access should
be so restrictive?
Any possibility that this could be changed in a future update?
--eric
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Access user space address from kernel space
Date: 07 May 2000 13:22:39 +0000
liran <[EMAIL PROTECTED]> writes:
> I wonder is it possible to make user space buffer visible
> to kernel space without considering which context am I
> now.I know that "copy_to_user" and friends will work only
> if I am in the same context which I got the address
> from.
> if it can be done where can I find example code for that.
2.2 does it in fs/proc/mem.c:mem_read(). However, it is hairy and much
slower than accessing memory for the current task.
In 2.3, fs/proc/mem.c is gone, and there is a function
access_process_vm() (in kernel/ptrace.c) which does exactly what you
want. It is still relatively slow though, so you should avoid it if
possible.
Davd Wragg
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Need help on a Code Launcher project
Date: 07 May 2000 19:31:35 +0000
Eric Taylor <[EMAIL PROTECTED]> writes:
> I've begun reading the ptrace code and
> looking at /proc I came up with the following items
> i need to figure out. Perhaps you've got a ready answer?
>
> 1. /proc/<pid>/mem shows as zero size, and I cannot use the od
> program to dump it (like I can with /proc/kcore). Is there some
> trick to reading this file? I notice the other /proc/<pid>
> files also have 0 length, but i can read those. Curious...
Probably due to the zero page not being mapped. You need to seek to
the relevant address before you do a read or a write.
> 2. The man pages i have (r.h 6.1 with a 2.2 kernel) say I cannot
> mmap (yet) the mem file, but hint that it's gonna be real
> soon that i can. I wonder whether this works yet or not?
Not really. There is code for it in 2.2.x, but there's a comment
saying it is unreliable. That code was ripped out in 2.3.x as part of
a procfs overhaul, and I don't think it has been replaced.
> 3. You seem to imply that /proc/<pid>/mem is writable?
You can write to /proc/xxx/mem to mess with the contents of the
address space of a process in whatever way you like. However, I don't
think you can allocate memory from the kernel without getting the
traced process to do the allocation itself by calling sbrk or mmap.
> is that
> what you mean when you say force it to do mmap calls. I see
> that ptrace can write some memory, but how would i get it
> to do a mmap?
You can force the traced process to do any function call by messing
with its stack and registers appropriately (using ptrace and/or
/proc/xxx/mem). gdb does this, and it takes quite a lot of code, but
doing simple fixed function calls should be a lot simpler. For a mmap,
you could call the libc mmap function, but finding out it's address
could be a lot of work. It's probably easier to set up the registers
for a mmap system call "by hand", push an "int $0x80" instruction on
the stack, and point PC to it (these details are of course x86
specific).
> 4. ptrace seems to imply that you don't get data or registers
> unless the process is stopped. It will let me single step
> and run till a system call or a breakpoint that i insert.
Yes, and yes.
> What would be perfect (for me), would be a ptrace call that
> let me continue the target for a time (for instance, let
> it run one clock tick and then come back to my ptrace
> program). But short of that,
>
>
> I've thinking to use ptrace like this for the profiler i
> would like to build:
>
> attach (this also stops the proc)
> loop
> get registers and stack area with ptrace get calls
> continue the process
> wait a few clock ticks
> send a SIGSTOP to the target to stop it again
> (i am still attached, so i hope i can do gets again)
> endloop
>
> Problem is: I don't know when the SIGSTOP has
> actually hit, so i could be looking at a changing
> program.
Your controlling process should call wait4 with the WUNTRACED flag to
wait until the traced process has actually stopped.
> Also, with ptrace, a user cannot be also using gdb.
> (unless he is willing to get in and out with gdb
> and likewise with my program) For that reason, I
> also might want to consider not using ptrace.
>
> A possibility, w/o ptrace is if i can
> use /proc/<pid>/stat to get the stack pointer
> and then /proc/<pid>/mem to read the entire
> stack in one gulp. Then i could loop as follows:
>
> loop
> send sigstop to process
> read stat, get stack pointer, figure out stack loc
> read mem to get the stack
> send sigcont to process
> wait a bit
> endloop
>
> Question is: do i need to keep opening these /proc files
> or can i do a seek or something so i can avoid the
> overhead of the file open each time.
The results you get from reading /proc/xxx/mem are up to date (within
the limits of the machine for SMP).
David Wragg
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: RS-485
Date: Sun, 7 May 2000 22:00:05 +0200
[EMAIL PROTECTED] (Tobias Anderberg) writes:
>I'm about to add support for rs-485 for a project I'm working on.
>I don't want to make this a user-space driver, instead I would
>like to add this directly to the existing serial driver, and make
>it easy accesible with an ioctl(), like "ioctl(fd, RS485, &n);"
>and then all communication with the serial device would be done
>using rs-485 semantics.
I am not sure, what you are calling rs-485 semantics? Are you talking
about bi-directional line drivers and controlling their direction?
When I had to solve that problem ( I chose to implement my driver in
user space), I also had to add some code to the kernel to synchronize
the control of the serial control lines to the serial data stream. I
am sure, my sollution is not optimal, since it uses polling, but if
you are going to experiment with this problem, I would share my
knowledge.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Chris)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Sun, 07 May 2000 20:27:15 GMT
On 7 May 2000 01:25:34 GMT, [EMAIL PROTECTED] (brian moore) wrote in
comp.os.linux.development.apps:
>> People who write device drivers or kernel modules should provide a proper
>> man(2) or man(3) page. Ideally, we should kill off the ioctl() function
>> and place all accessible driver variables in /proc.
>
>If you remove ioctl(), how will you plan on maintaining compatibility
>with other Unix systems?
Who says that using ioctl() preserves compatability? It's a catch-all
function that was written so that programmers could access features of
specific device drivers in a non-standardized way. An ioctl() to a device
in Linux won't be portable to another system unless the underlying device
drivers use identical symbols, argument counts and types, etc. As Linux
stops playing catch-up with the commercial versions and forges ahead into
new territory, the likelihood that applications will remain portable
diminishes.
Are we planning to rewrite our drivers if the commercial vendors choose to
use different symbols? Or are you assuming that commercial Unix system
developers will voluntarily copy the Linux drivers?
There are so many other non-"Unix" diversions on the table that commercial
compatibility is obviously not a holy grail for some people.
------------------------------
From: [EMAIL PROTECTED] (Chris)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Sun, 07 May 2000 20:27:15 GMT
On Sun, 7 May 2000 09:34:11 +0200, [EMAIL PROTECTED] (Tobias Anderberg)
wrote in comp.os.linux.development.apps:
>>programmers shouldn't have to resort to sifting through the kernel source
>>code to figure out how to perform simple and common tasks.
>
>Usually people don't wade through the kernel source for "simple
>and common" tasks. Rather to see how a certain driver, part of
>kernel and so on work, to gain deeper knowledge of the
>operating system, they need to fix something, or out of plain
>interest.
I would think that finding the address(es) of a specific interface should
be a simple task. The need is certainly common, judging by the amount of
bandwidth wasted by news posts every other week asking how to do it.
>If I wanted to know how to fetch my IP, I certainly wouldn't look
>in the kernel source for that (at least not at first). That's just
>something I picked up during my general kernel "research" and I
>found it to be a easy way of solving this particular problem.
Other people in this thread are taking the opposite stand-- they think
that wading through the source code *is* the appropriate way to learn how
to do such things. This kind of elitist "documentation is for dummies"
attitude won't do anything to convince programmers to dump Win9X and start
writing software for Linux.
------------------------------
From: [EMAIL PROTECTED] (Chris)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Sun, 07 May 2000 20:29:22 GMT
On Sat, 06 May 2000 22:12:59 GMT, [EMAIL PROTECTED] (Kaz Kylheku)
wrote in comp.os.linux.development.apps:
>Get real; these ioctl's are easy to find in the kernel source code.
>I disagree on both counts. Having the operating system source code
>is a blessing. I'd rather read ten lines of code than a thousand lines
>of documentation.
I'm heartened to know that you've uninstalled all the man pages from your
system. After all, if you need to know the arguments to a standard C
library call you can always go look in the libc6 sources....
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: 7 May 2000 23:39:45 GMT
On Sun, 07 May 2000 20:27:15 GMT,
Chris <[EMAIL PROTECTED]> wrote:
> On 7 May 2000 01:25:34 GMT, [EMAIL PROTECTED] (brian moore) wrote in
> comp.os.linux.development.apps:
>
> >> People who write device drivers or kernel modules should provide a proper
> >> man(2) or man(3) page. Ideally, we should kill off the ioctl() function
> >> and place all accessible driver variables in /proc.
> >
> >If you remove ioctl(), how will you plan on maintaining compatibility
> >with other Unix systems?
>
> Who says that using ioctl() preserves compatability? It's a catch-all
> function that was written so that programmers could access features of
> specific device drivers in a non-standardized way. An ioctl() to a device
> in Linux won't be portable to another system unless the underlying device
> drivers use identical symbols, argument counts and types, etc. As Linux
> stops playing catch-up with the commercial versions and forges ahead into
> new territory, the likelihood that applications will remain portable
> diminishes.
Huh? The ioctl cited works the same way on Linux, Solaris,
(Free|Net|Open)BSD, BSDI, HP-UX, AIX, etc... It isn't official Posix,
but it is quite portable.
Certainly ioctl() has a shady history, but that doesn't mean it's not
effective and surprisingly portable, especially for things like
networking which were added relatively recently.
> Are we planning to rewrite our drivers if the commercial vendors choose to
> use different symbols? Or are you assuming that commercial Unix system
> developers will voluntarily copy the Linux drivers?
Why would they change symbols? You really think Sun wants to break all
the Solaris applications? You think HP wants to do the same for HP-UX?
What would their justification be to break everything?
They don't need to copy Linux on this -- Linux already copied them. I
doubt Linus (despite his insistence on doing things the 'right' way
instead of hacks like ioctl()) would choose to break things in a way
that broke lots of user space programs.
> There are so many other non-"Unix" diversions on the table that commercial
> compatibility is obviously not a holy grail for some people.
Um, right. So Linux should support the Winsock calls? What other
non-Unix "diversions" are you talking about?
Sorry, until POSIX specifies a replacement for all the ioctl()'s, it's
here to stay. (They have specified some, like tcgetattr(), but there
are dozens of commonly used ioctls that would need an alternative
interface defined.)
--
Brian Moore | Of course vi is God's editor.
Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
Usenet Vandal | for it to load on the seventh day.
Netscum, Bane of Elves.
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: 7 May 2000 23:41:53 GMT
On Sun, 07 May 2000 20:27:15 GMT,
Chris <[EMAIL PROTECTED]> wrote:
> On Sun, 7 May 2000 09:34:11 +0200, [EMAIL PROTECTED] (Tobias Anderberg)
> wrote in comp.os.linux.development.apps:
>
> >>programmers shouldn't have to resort to sifting through the kernel source
> >>code to figure out how to perform simple and common tasks.
> >
> >Usually people don't wade through the kernel source for "simple
> >and common" tasks. Rather to see how a certain driver, part of
> >kernel and so on work, to gain deeper knowledge of the
> >operating system, they need to fix something, or out of plain
> >interest.
>
> I would think that finding the address(es) of a specific interface should
> be a simple task. The need is certainly common, judging by the amount of
> bandwidth wasted by news posts every other week asking how to do it.
It usually is. (Hint -- the vast majority of people that want such
information are on a dynamic IP, assigned through either DHCP or PPP
negotiation, both of which have trivial hooks for scripts that will be
passed the assigned IP number.)
--
Brian Moore | Of course vi is God's editor.
Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting
Usenet Vandal | for it to load on the seventh day.
Netscum, Bane of Elves.
------------------------------
** 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
******************************
