Linux-Development-Sys Digest #828, Volume #7 Sun, 7 May 00 01:13:06 EDT
Contents:
Re: Need to find my IP address ("Peter T. Breuer")
Re: Need to find my IP address (Kaz Kylheku)
Re: Need to find my IP address (Kaz Kylheku)
Re: Need to find my IP address ("Peter T. Breuer")
Re: Need to find my IP address (Chris)
Re: Need to find my IP address ("Peter T. Breuer")
Re: Need to find my IP address (brian moore)
bash not core dumping, trying to solve it (Patrick Draper)
bash not core dumping, trying to solve it (Patrick Draper)
Re: Need to find my IP address (Kaz Kylheku)
Uh... floppy disk not being seen? (Paul D. Smith)
Re: Uh... floppy disk not being seen? (Paul D. Smith)
Re: Need to find my IP address (brian moore)
Re: Need help on a Code Launcher project (Eric Taylor)
Re: Have new parallel port - but it's PCI!! (Chris Rankin)
Re: Linux and PCI......? (Chris Rankin)
----------------------------------------------------------------------------
From: "Peter T. Breuer" <[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: 6 May 2000 21:22:41 GMT
In comp.os.linux.misc Chris <[EMAIL PROTECTED]> wrote:
: 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.
You knoiw, that's not a bad idea! Do you mind if I forward it to the
kernel list?
Peter
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Reply-To: [EMAIL PROTECTED]
Date: Sat, 06 May 2000 22:12:59 GMT
On Sat, 06 May 2000 21:06:50 GMT, Chris <[EMAIL PROTECTED]> wrote:
>On Sat, 6 May 2000 17:51:38 +0200, [EMAIL PROTECTED] (Tobias Anderberg)
>wrote in comp.os.linux.development.apps:
>
>> int fd;
>> struct ifreq i;
>> fd = socket(AF_INET, SOCK_DGRAM, 0);
>> strncpy(i.ifr_name, "eth0", 5);
>> ioctl(fd, SIOCGIFADDR, (int) &i);
>> close(fd);
>> return (char *)inet_ntoa(((struct sockaddr_in *)
>> &i.ifr_addr)->sin_addr);
>
>Herein lies one of my biggest complaints about the Linux development
>environment: there should be no reason why an application programmer must
>rely on undocumented "catch-all" calls to accomplish simple tasks. The
>"man ioctl_list" page is a complete waste of time-- it's hopelessly out of
Get real; these ioctl's are easy to find in the kernel source code.
>date and only contains the argument type for each command without any
>explaination of where, why or how each should be used. Application
>programmers shouldn't have to resort to sifting through the kernel source
>code to figure out how to perform simple and common tasks.
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.
Secondly, I disagree that tasks accomplished through operating system specific
ioctl's are ``simple and common''. There is no need for something other than a
system management utility to be making the SIOCGIFADDR ioctl. People writing
system management utilities should have intimate knowledge of the operating
system.
This stuff needs to be hard to find and hard to use, otherwise people will go
rampant writing programs that depend on shaky semi-private interfaces in the
OS.
>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.
The ioctl call is not just for setting and retrieving parameters; ioctl's can
be used to perform synchronous tasks, such as blocking until something happens
in a driver.
The idea of replacing ioctl by /proc is absurd.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Reply-To: [EMAIL PROTECTED]
Date: Sat, 06 May 2000 22:13:15 GMT
On 6 May 2000 21:22:41 GMT, Peter T. Breuer <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.misc Chris <[EMAIL PROTECTED]> wrote:
>: 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.
>
>You knoiw, that's not a bad idea! Do you mind if I forward it to the
>kernel list?
Why, so you can look stupid too?
--
#exclude <windows.h>
------------------------------
From: "Peter T. Breuer" <[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: 6 May 2000 22:29:01 GMT
In comp.os.linux.misc Kaz Kylheku <[EMAIL PROTECTED]> wrote:
: On 6 May 2000 21:22:41 GMT, Peter T. Breuer <[EMAIL PROTECTED]> wrote:
:>In comp.os.linux.misc Chris <[EMAIL PROTECTED]> wrote:
:>: 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.
:>
:>You know, that's not a bad idea! Do you mind if I forward it to the
:>kernel list?
: Why, so you can look stupid too?
Hey, I don't mind! And it's not such a silly idea. I've just spent half
an hour looking for a delete_module function to match the
request_module one in the kernel. There _was_ a syscall to do it, but
nothing callable from driver code. I could have found that out in 1
minute with a man page for module.c.
Peter
------------------------------
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: Sat, 06 May 2000 22:30:30 GMT
[emailed and posted]
On 6 May 2000 21:22:41 GMT, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote
in comp.os.linux.development.apps:
>In comp.os.linux.misc Chris <[EMAIL PROTECTED]> wrote:
>: 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.
>
>You knoiw, that's not a bad idea! Do you mind if I forward it to the
>kernel list?
Please do.
We need to find a way to reduce the inconsistency in /proc as well,
perhaps by creating a policy paper on directory structure and naming
conventions. Ideally a /proc/dev directory would contain directories for
each major number and each would be subdivided into minors. Master device
options (for controlling multi-port boards, for example) would exist as
named files in /proc/dev/{major}/, and per-device settings would be files
in /proc/dev/{major}/{minor}/.
We are half-way there with the current /proc entries for controlling
/dev/lp0, in that the /proc/parport directory is the base directory for
major device 6, and contains a separate directory for each minor. I can
set the IRQ of /dev/lp0 by writing a string-encoded digit to
/proc/parport/0/irq. By comparison, the /proc entries for tty devices is
a complete mess. I cannot simply read the status of /dev/ttyS0, but must
instead read /proc/tty/driver/serial and *guess* which line corresponds to
the desired port.
I would propose moving the /dev/lp0 settings to /proc/dev/6/0/* and the
/dev/ttyS0 settings to /proc/dev/4/64/*. Each should contain a "hardware"
file that outputs all of the information for that port, and a collection
of read/write files corresponding to the individual parameters.
In order to simplify programmatic access to /proc, we would probably want
to introduce readprocfs() and writeprocfs() methods to one of the kernel
libraries. That would allow a program to bypass the normal
open-errorcheck-read/write-close cycle and read or write a /proc entry in
a single step, as in:
int success = 0;
if (success = writeproc("/proc/dev/6/0/irq", "7")) ....
Comments?
------------------------------
From: "Peter T. Breuer" <[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: 6 May 2000 22:31:54 GMT
In comp.os.linux.misc Kaz Kylheku <[EMAIL PROTECTED]> wrote:
: On Sat, 06 May 2000 21:06:50 GMT, Chris <[EMAIL PROTECTED]> wrote:
:>On Sat, 6 May 2000 17:51:38 +0200, [EMAIL PROTECTED] (Tobias Anderberg)
:>wrote in comp.os.linux.development.apps:
:>"man ioctl_list" page is a complete waste of time-- it's hopelessly out of
: Get real; these ioctl's are easy to find in the kernel source code.
Maybe. If you know what they're called. A man -k would help a little.
:>man(2) or man(3) page. Ideally, we should kill off the ioctl() function
:>and place all accessible driver variables in /proc.
: The ioctl call is not just for setting and retrieving parameters; ioctl's can
Ioctls aren't the full story. I think every symbol exported from the
kernel could have a man page entry in a special "k" section of the
manual. At least it would encourage use of the static keyword ...
Peter
------------------------------
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 01:25:34 GMT
On Sat, 06 May 2000 21:06:50 GMT,
Chris <[EMAIL PROTECTED]> wrote:
> On Sat, 6 May 2000 17:51:38 +0200, [EMAIL PROTECTED] (Tobias Anderberg)
> wrote in comp.os.linux.development.apps:
>
> > int fd;
> > struct ifreq i;
> > fd = socket(AF_INET, SOCK_DGRAM, 0);
> > strncpy(i.ifr_name, "eth0", 5);
> > ioctl(fd, SIOCGIFADDR, (int) &i);
> > close(fd);
> > return (char *)inet_ntoa(((struct sockaddr_in *)
> > &i.ifr_addr)->sin_addr);
>
> Herein lies one of my biggest complaints about the Linux development
> environment: there should be no reason why an application programmer must
> rely on undocumented "catch-all" calls to accomplish simple tasks. The
> "man ioctl_list" page is a complete waste of time-- it's hopelessly out of
> date and only contains the argument type for each command without any
> explaination of where, why or how each should be used. Application
> programmers shouldn't have to resort to sifting through the kernel source
> code to figure out how to perform simple and common tasks.
Perhaps you should just buy a book? Something like Unix Network
Programming should have the above.
It will certainly have the much-more-recommended method of finding your
IP number, which is to find your hostname and then look it up. Both
methods will be lacking in some circumstances (think of machines with
more than one IP number for a trivial case).
> 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?
--
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: Patrick Draper <[EMAIL PROTECTED]>
Subject: bash not core dumping, trying to solve it
Date: Sun, 07 May 2000 02:14:11 GMT
This is what I am trying to allow normal users to get core dumps, which
are essential to programming in my opinion.
I looked at the bash source, and that calls setrlimit. That man page
indicated that the core size limit for users is dictated by the kernel,
so I went digging around in there.
I found the sys_setrlimit () function in the ./linux/kernel/sys.c file.
But now I am stuck.
Any ideas?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Patrick Draper <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: bash not core dumping, trying to solve it
Date: Sun, 07 May 2000 02:13:43 GMT
This is what I am trying to allow normal users to get core dumps, which
are essential to programming in my opinion.
I looked at the bash source, and that calls setrlimit. That man page
indicated that the core size limit for users is dictated by the kernel,
so I went digging around in there.
I found the sys_setrlimit () function in the ./linux/kernel/sys.c file.
But now I am stuck.
Any ideas?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Reply-To: [EMAIL PROTECTED]
Date: Sun, 07 May 2000 02:20:58 GMT
On 7 May 2000 01:25:34 GMT, brian moore <[EMAIL PROTECTED]> wrote:
>Perhaps you should just buy a book? Something like Unix Network
>Programming should have the above.
>
>It will certainly have the much-more-recommended method of finding your
>IP number, which is to find your hostname and then look it up. Both
>methods will be lacking in some circumstances (think of machines with
>more than one IP number for a trivial case).
The recommended method is to not try to find your IP number. Programs that try
to discover the IP address of the local machine are kludgy, and will break
under circumstances that the author did not take into account: multiple
interfaces, IP aliasing, dynamic IP, etc.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Uh... floppy disk not being seen?
Date: 06 May 2000 23:14:55 -0400
Reply-To: [EMAIL PROTECTED]
Here's a pisser. This is so stupid. I've had this system for over a
year now, and it so happens this is the first time I've ever tried to
use the floppy from Linux (works fine from Windows).
I've used both "mdir a:" (and b:) and tried "mount -t msdos /dev/fd0
/mnt" (and /dev/fd1) and _nothing happens_. It sits for a while doing
absolutely nothing, then mdir says:
# mdir a:
init: set default params
Cannot initialize 'A:'
(but the config file looks fine), and mount says:
# mount -t msdos /dev/fd0 /mnt
mount: block device /dev/fd0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/fd0,
or too many mounted file systems
But the thing is, it doesn't even try my floppy! There is no noise from
the floppy drive, the disk light doesn't go on, etc. This is a loud
drive, I'd know if it did anything. How can it know anything about the
fs type or superblock if it didn't even move the drive head or spin the
diskette? And I only have 6 filesystems mounted so that doesn't seem
like the problem.
I see these messages in /var/log/messages:
May 6 22:58:09 homebase kernel: FAT bread failed
May 6 22:59:21 homebase kernel: end_request: I/O error, dev 02:01 (floppy), sector 0
May 6 22:59:45 homebase kernel: end_request: I/O error, dev 02:1c (floppy), sector 0
May 6 22:59:45 homebase kernel: FAT bread failed
May 6 23:03:10 homebase kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
May 6 23:07:56 homebase kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
May 6 23:09:08 homebase last message repeated 2 times
May 6 23:09:32 homebase last message repeated 2 times
May 6 23:09:32 homebase kernel: FAT bread failed
I checked and the "floppy" block device is compiled into my kernel (not
as a module) according to the config.
Anyone have any idea what the problem is here?
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Uh... floppy disk not being seen?
Date: 06 May 2000 23:24:19 -0400
Reply-To: [EMAIL PROTECTED]
In case it makes a difference, I forgot to mention I'm running Linux
2.2.14 with a Debian 2.2 (frozen) distribution. My floppy is a standard
1.44M drive, which shows up as A: in DOS/Windows.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
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 04:01:51 GMT
On Sun, 07 May 2000 02:20:58 GMT,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> On 7 May 2000 01:25:34 GMT, brian moore <[EMAIL PROTECTED]> wrote:
> >Perhaps you should just buy a book? Something like Unix Network
> >Programming should have the above.
> >
> >It will certainly have the much-more-recommended method of finding your
> >IP number, which is to find your hostname and then look it up. Both
> >methods will be lacking in some circumstances (think of machines with
> >more than one IP number for a trivial case).
>
> The recommended method is to not try to find your IP number. Programs that try
> to discover the IP address of the local machine are kludgy, and will break
> under circumstances that the author did not take into account: multiple
> interfaces, IP aliasing, dynamic IP, etc.
Yep, though for some applications, you need to know it (such as ftp and
the god-awful PORT command it uses -- gads, that protocol needs
replacing bad... all in all it's just plain evil). When designing new
protocols, it's a very bad thing for the reason we both stated: there
is no good way to determine what the 'real' interface is at the
application layer, and kludges to fake it are stupid.
In such cases, it's best to just bind to IN_ADDR_ANY, and then go look at
the structure after the connect and see what the kernel filled in for
you on the connection. On most systems, this will return the 'closest'
interface to a given destination. At worst, it'll return whatever the
system believes is this 'primary' interface.
--
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: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: Need help on a Code Launcher project
Date: Sat, 06 May 2000 21:14:39 -0700
John Reiser wrote:
>
> How much do you really need to be in kernel mode? Why not just attach
> to the process as a debugger ("gdb a.exe pid", or perhaps use
> /proc/<pid>/exe and /proc/<pid>/mem, and maybe /proc/<pid>/maps, etc.),
> use ptrace() and/or /proc/<pid>/mem to force the process to execute a few
> mmap() calls, and then invoke the mapped code. Then you instruct the process
> to do to itself, anything you wish.
>
> --
> John Reiser, [EMAIL PROTECTED]
Great suggestion!!! Ptrace looks like a really cool item.
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...
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?
3. You seem to imply that /proc/<pid>/mem is writable? 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?
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.
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.
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. Or is this not
a concern as i've read that the system caches recently
opened file paths, so /proc/<pid>/mem might not need
too much work. I would be accessing these 30-50 times
a sec each.
Most of the above questions I will be answering myself
by trying out some code in the next week or so. But
I thought the questions themselves to be interesting
and worth posting.
thanks again for the suggestion
--eric
------------------------------
From: Chris Rankin <au.zipworld.com@{no.spam}rankinc>
Subject: Re: Have new parallel port - but it's PCI!!
Date: Sun, 07 May 2000 14:57:35 +1000
J Bland wrote:
> I have two parallel ports on my server, one being a PCI card. Adding the
> following hardware parameter to lilo does the trick if the parport support
> is compiled into the kernel (there's a similar thing that works in
> modules.conf, have a look, it may be listed in there already):
>
> parport=0x3bc,7 parport=0x9800,auto
>
> These numbers were found by pretty much trying any of the standard parport
> ones and the I/O info found from /proc/pci for the parallel port card.
I have *finally* managed to get this port enabled, although it's taken
several documents from the manufacturer and a lot of email from the
parallel port developers. It seems that my PCI card uses a "multi-IO"
chip which needs a *lot* of special configuring before it will work.
However, now it can do ECP, EPP1.7, EPP1.9, PS2 and SPP - and all I
wanted was somewhere to put my ZIP drive!
Thanks for all the responses,
Chris.
------------------------------
From: Chris Rankin <au.zipworld.com@{no.spam}rankinc>
Subject: Re: Linux and PCI......?
Date: Sun, 07 May 2000 15:04:14 +1000
[EMAIL PROTECTED] wrote:
> I am new to Linux and I want to write a device driver for a PCI device.
> I have written drivers for the same PCI device on Win 9x, Win NT and
> VxWorks and now trying to port the drivers onto the Linux system.
>
> Any help, any pointers, material or examples will be very helpful.
"Use the Source, Luke!"
In particular:
/usr/src/linux/include/linux/pci.h
This header file exports all the Linux functions to access the PCI
configuration data. It sounds like you are already familiar with PCI in
general. Do you also have the pciutils package installed? This allows
you to examine the PCI configuration space using
$ lspci
pciutils can be found through http://freshmeat.net. The latest version
(I think) is 2.1.7.
Chris.
------------------------------
** 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
******************************
