Linux-Development-Apps Digest #587, Volume #6 Sun, 7 May 00 00:13:07 EDT
Contents:
How can an app place a frame in an interface's rx queue? (Michael Evangelista)
Re: How can an app place a frame in an interface's rx queue? (Kaz Kylheku)
Re: Need to find my IP address (Chris)
Re: Need to find my IP address ("Peter T. Breuer")
Re: Is JavaServer Pages alive in Linux? ([EMAIL PROTECTED])
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")
C++ GUI library question ([EMAIL PROTECTED])
Re: Need to find my IP address (brian moore)
Re: Need to find my IP address (Kaz Kylheku)
Re: C++ GUI library question (Lac Hao Viet)
Re: Wrinting A Function Like DelTree ("Bert Douglas")
Re: Need to find my IP address (brian moore)
----------------------------------------------------------------------------
From: Michael Evangelista <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.development.system
Subject: How can an app place a frame in an interface's rx queue?
Date: Sat, 06 May 2000 15:22:50 -0500
Hello,
For the purpose of building a simple bridge, I am looking for a way for
an application to place a frame in the incoming queue for a particular
interface, making it appear as if it came off that interface's wire.
Writing a frame to the interface using SOCK_PACKET does not accomplish
this. Is there any nice way for an app to get a datagram to an
interface's in-queue (i.e., get a frame to dev_loopback_xmit)?
I've examinged the briding code in Linux. Presumably, it too must pass a
frame destined for the local machine up to to the correct interface
regardless of the physical interface over which it arrived (e.g., a
machine on segment B ARPs your interface that is connected to segment
A). However, the code in br.c only calls dev_queue_xmit() -- the same
call invoked by packet_sendmsg_spkt() which doesn't seem to solve my
problem.
Does anyone have any suggestions?
Thanks,
mhe
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.networking,comp.os.linux.development.system
Subject: Re: How can an app place a frame in an interface's rx queue?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 06 May 2000 20:52:10 GMT
On Sat, 06 May 2000 15:22:50 -0500, Michael Evangelista <[EMAIL PROTECTED]>
wrote:
>Hello,
>
>For the purpose of building a simple bridge, I am looking for a way for
>an application to place a frame in the incoming queue for a particular
>interface, making it appear as if it came off that interface's wire.
>Writing a frame to the interface using SOCK_PACKET does not accomplish
>this. Is there any nice way for an app to get a datagram to an
>interface's in-queue (i.e., get a frame to dev_loopback_xmit)?
>
>I've examinged the briding code in Linux. Presumably, it too must pass a
>frame destined for the local machine up to to the correct interface
>regardless of the physical interface over which it arrived (e.g., a
I don't see why. A bridge copies frames from one interface to another.
Why would it have to fake input?
>machine on segment B ARPs your interface that is connected to segment
>A).
In this case the bridge simply has to answer the ARP request and shove
it down the appropriate interface. Logic similar to Proxy ARP can
take care of this.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Chris)
Crossposted-To: comp.os.linux.development.system,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Sat, 06 May 2000 21:06:50 GMT
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.
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.
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system,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]
Crossposted-To: alt.os.linux,comp.os.linux.misc,comp.lang.java.programmer
Subject: Re: Is JavaServer Pages alive in Linux?
Date: Sat, 06 May 2000 21:34:18 GMT
I have had good success with JRun version 2.3.3 build >= 155 on
Linux, along with Apache 1.3.9. I have also heard of good
results with people using Resin (which includes its own 100%-pure-
Java webserver, reputed to be quite fast). I use the Sun build
of the Linux JVM verison 1.2.2 with green threads and sunwjit.
Visit http://www.allaire.com/, http://www.caucho.com/, and
http://java.sun.com/ to download these. All of the above are free
for development...
-=- D. J.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Also in particular, which free JSP implementations should i use
>
> 1) GNU ServerPages by bitmechanic, or
> 2) GNU JavaServer Pages by klomp
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.system,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.system,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.system,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.system,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.system,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]
Subject: C++ GUI library question
Date: Sat, 06 May 2000 17:04:45 -0700
I've made many console apps so I know some c++, but I'm a beginner in
making GUI apps. I've researched and found GTK, qt, tcl/tk on the
internet. Which of these is the best for a beginner? Or is there one
better than these?
Thank you for your help.
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.development.system,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: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.system,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: Lac Hao Viet <[EMAIL PROTECTED]>
Subject: Re: C++ GUI library question
Date: Sun, 07 May 2000 02:36:18 GMT
All of them are being used for desktop development; they're definitely
for programmers on all levels.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I've made many console apps so I know some c++, but I'm a beginner in
> making GUI apps. I've researched and found GTK, qt, tcl/tk on the
> internet. Which of these is the best for a beginner? Or is there one
> better than these?
>
> Thank you for your help.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Bert Douglas" <[EMAIL PROTECTED]>
Subject: Re: Wrinting A Function Like DelTree
Date: Sat, 6 May 2000 22:37:01 -0500
It would probably be worthwhile to study the source to the
GNU "rm".
It is probably on your computer somewhere.
Or you can get it from www.gnu.org.
I think it is in the package called "file utilities".
------------------------------
From: [EMAIL PROTECTED] (brian moore)
Crossposted-To: comp.os.linux.development.system,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.
------------------------------
** 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.apps) 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-Apps Digest
******************************
