Linux-Development-Sys Digest #126, Volume #8 Wed, 6 Sep 00 06:13:12 EDT
Contents:
Re: Alocate a memory location above 4G of memory (Karl Heyes)
Re: Threads on Linux (Mark Hahn)
Re: will GUI program compile using gtk+ run on KDE? (Christopher Browne)
cannot fork on linux mail server (Don Carroll)
Re: Threads on Linux ([EMAIL PROTECTED])
two fib_lookup ? (wolf)
Re: Threads on Linux (Karl Heyes)
Re: cannot fork on linux mail server (Karl Heyes)
Re: netif_rx ? ([EMAIL PROTECTED])
Re: cannot fork on linux mail server ([EMAIL PROTECTED])
Re: using the /proc interface ([EMAIL PROTECTED])
Re: Threads on Linux ([EMAIL PROTECTED])
Linux driver for NI PCI6035E MIO card ("Yuhong Ren")
Re: will GUI program compile using gtk+ run on KDE? (Arturo C)
Re: /dev/log (Kasper Dupont)
Re: two fib_lookup ? (Andi Kleen)
Re: Strange Cash (Kasper Dupont)
----------------------------------------------------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Alocate a memory location above 4G of memory
Date: Wed, 06 Sep 2000 01:47:01 +0000
In article <[EMAIL PROTECTED]>,
David Wu <[EMAIL PROTECTED]> wrote:
> Thanks for the reply. I try to search for "mmap64" in 2.4 source but cannot
> find it. Is it under a different name ? Thanks ... Dave Wu
>
> Karl Heyes wrote:
>
>> In article <[EMAIL PROTECTED]>, David Wu <[EMAIL PROTECTED]>
>> wrote:
>
>>
>> the mmap interface is 32 bit. you would have to use mmap64 to address
>> bigger areas of memory. try and avoid going back to the segmented model.
>>
mmap64 and its friends are posix and are defined in glibc, I think it maps to
the mmap2 syscall in 2.4.
karl.
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: Threads on Linux
Date: 6 Sep 2000 00:41:22 GMT
>> trying to port some software to Linux, but the fact that each
>> "thread" has it's own PID is causing me no end of trouble. Any
it seems like a clear design flaw to rely on this relation,
since it means you're wired into just one of the many
ways to implement threads. never work with N:1, or N:M,
I'm guessing.
> right now, your best bet is to replace Linux with FreeBSD.
gee, when I leave my car running in the garage,
it seems so smoggy inside. solution: move to montana.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer,linux.redhat
Subject: Re: will GUI program compile using gtk+ run on KDE?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 06 Sep 2000 01:38:58 GMT
Centuries ago, Nostradamus foresaw a time when Richard Lim would say:
>can I use gtk+ to program GUI application and run it in KDE other then GNOME
>which I suppose it is suppose to run on.
Absolutely not. If you write a program to use the GTK toolkit, you
CANNOT run it using the Qt toolkit.
However, your question seems to betray a misunderstanding of what GNOME
and KDE _are_.
There are two sensible Points Of View:
a) They represent a set of libraries for doing GUI stuff atop X, and
providing other services such as XML parsers, access to config files,
and such.
b) They represent a set of applications written to use the respective
libraries from a).
There would be some "conflict" if you could not install GTK libraries
and KDE libraries on the same system, or if applications required
exclusive access to the X server, or of the Unix environment.
Reality is, however, that since the library names do not conflict, and
since X servers provide multiplexed access, and Unix-like environments
can multitask perfectly well, there _is_ no conflict. GNOME and KDE
applications can run concurrently for a single user on a single X
server _perfectly_ well, albeit consuming the memory resources required
by both sets of apps/libraries.
Note that neither of those Points Of View make _ANY_ mention of window
managers, which is as it should be.
While those that produce _DISTRIBUTIONS_ (e.g. - Red Hat, Caldera, SuSE,
Corel, ...) express some prejudices in their default configurations
of the respective "desktops," particularly vis-a-vis window manager
configuration, this represents the prejudices of those producing the
distributions, and does not reflect anything fundamental to GNOME or KDE.
If you dislike how Red Hat sets up WM configuration, that's not the
fault of either KDE or GNOME folk.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/xdesktop.html>
Rules of the Evil Overlord #117. "No matter how much I want revenge, I
will never order an underling ``Leave him. He's mine!''"
<http://www.eviloverlord.com/>
------------------------------
From: Don Carroll <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: cannot fork on linux mail server
Date: Wed, 06 Sep 2000 01:54:53 GMT
running a dual 300mhz pIII 512 meg ram , 500 meg swap
Linux 2.2 , Sendmail relay
getting cannot fork message sometimes when trying to run other software
, i.e
ps , ls, joe
this is pretty heavily loaded sendmail system , processes wise (100,000
users)
cpu is not that bad
is there a howto on increasing process limits , etc
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Threads on Linux
Date: Wed, 06 Sep 2000 02:44:33 GMT
Mark Hahn <[EMAIL PROTECTED]> wrote:
>>> trying to port some software to Linux, but the fact that each
>>> "thread" has it's own PID is causing me no end of trouble. Any
> it seems like a clear design flaw to rely on this relation,
> since it means you're wired into just one of the many
> ways to implement threads. never work with N:1, or N:M,
> I'm guessing.
Ok, this has been done to death before. Yes, you're relying on one way
to implement threads, the implementation specified in the POSIX
standard. Should we also avoid writing programs in C, since it means
you're wired into just one of the many ways of implementing programs?
>> right now, your best bet is to replace Linux with FreeBSD.
> gee, when I leave my car running in the garage,
> it seems so smoggy inside. solution: move to montana.
Actually, if you _really_ want to know, FreeBSD has Posix threads, a
better secheduler, and better memory managment. Linux has more
shrink-wrapped software available.
I'm sure there are other differences, but much like the continuous
Gnome Vs KDE debate, neither is clearly better. And unlike the moronic
example of being able to shut off you car, his options are:
1. Add threads to the kernel.
2. Rewrite the application, rather than just porting it.
3. Switch to a system that has pthreads.
The third being the fastest solution.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: wolf <[EMAIL PROTECTED]>
Subject: two fib_lookup ?
Date: Wed, 06 Sep 2000 10:48:38 +0800
when i was investigate the route method of linux , i found two different
definition of fib_lookup(), which is used to look up a route for an ip
packet.
they are in :
/linux/include/linux/ip_fib.h and
/linux/net/ipv4/fib_rules.c
why ?
my linux kernel version if 2.2.15
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Threads on Linux
Date: Wed, 06 Sep 2000 06:26:26 +0000
In article <lcit5.70916$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> Actually, if you _really_ want to know, FreeBSD has Posix threads, a better
> secheduler, and better memory managment. Linux has more shrink-wrapped
> software available.
>
These are good points, but be-aware that linux is being put into places where
Freebsd isn't been considered. Freebsd has always had a good MM, it needed
it for the workloads it was given, heavy server work.
Threads have only made big book of buzz words because of java!!
> I'm sure there are other differences, but much like the continuous Gnome Vs
> KDE debate, neither is clearly better. And unlike the moronic example of
> being able to shut off you car, his options are:
>
> 1. Add threads to the kernel.
> 2. Rewrite the application, rather than just porting it.
> 3. Switch to a system that has pthreads.
>
> The third being the fastest solution.
>
true, I haven't used threads that much myself, but most uses I've seen have
been bad. To help the original poster, there is support for threading at the
kernel level, but each entry in the so-called "ps list" is called a task.
Each task can be a thread or full process, the kernel doesn't care, so it
allocates a separate id for each task.
karl.
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: cannot fork on linux mail server
Date: Wed, 06 Sep 2000 06:31:54 +0000
In article <[EMAIL PROTECTED]>, Don Carroll <[EMAIL PROTECTED]> wrote:
> running a dual 300mhz pIII 512 meg ram , 500 meg swap Linux 2.2 , Sendmail
> relay
>
>
> getting cannot fork message sometimes when trying to run other software
> , i.e
>
> ps , ls, joe
>
> this is pretty heavily loaded sendmail system , processes wise (100,000
> users)
>
> cpu is not that bad
>
> is there a howto on increasing process limits , etc
>
There is a NR_TASKS value you can change, but that means re-compile. I
think 2.4 allows a dynamic run-time setting.
You should consider limiting your system if he process list is becoming full,
I guess it would be a sendmail option based on load.
karl
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: netif_rx ?
Date: Wed, 06 Sep 2000 05:32:29 GMT
In article <8p32ee$mr8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> im lost and i hope that any one can help me ....
> i need detail information about how netif_rx works
> thus how it call the right function on the upper layer
> thanks ayalone
Well actually, the real dispatching to higher level layers happens in
void net_bh(void) (/usr/src/linux/net/core/dev.c). Every network-layer
that wants to receive incoming packets has to register itself by calling
void dev_add_pack(struct packet_type *pt). The struct in the parameter
contains a pointer to a function. Now back to net_bh. This function
tries every registered packet_type, sees wether the incoming packet-type
is the same as the one contained in the packet_type struct. If it is, it
performs the function (remember the pointer in packet_type). So why 2
for-loops ? Simple, the first one sends it to things like sniffers
(tcpdump etc...), the second for sends it to the actual protocol-layers.
Hope this helps.
Dirk
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: cannot fork on linux mail server
Date: Wed, 06 Sep 2000 05:38:28 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> running a dual 300mhz pIII 512 meg ram , 500 meg swap
> Linux 2.2 , Sendmail relay
>
> getting cannot fork message sometimes when trying to run other
software
> , i.e
>
> ps , ls, joe
>
> this is pretty heavily loaded sendmail system , processes wise
(100,000
> users)
>
> cpu is not that bad
>
> is there a howto on increasing process limits , etc
Yeah sure, try fiddeling with ulimit and cranck up the
nr-of-processes-limit.
Dirk
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: using the /proc interface
Date: Wed, 06 Sep 2000 05:43:24 GMT
In article <8otl7p$75i$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm looking for help on how to implement a two way interface for
> configuring/querying a kernel module threw the /proc filesystem. where
can I
> find the relevant documentation. thanks Eran
<[EMAIL PROTECTED]>
Try reading the linux-kernel-module-programming-guide. It's a pretty
good and readable tutorial of howto write your own modules and it does
cover the topic of the /proc interface.
Dirk
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Threads on Linux
Date: Wed, 06 Sep 2000 06:50:17 GMT
Karl Heyes <[EMAIL PROTECTED]> wrote:
> Threads have only made big book of buzz words because of java!!
That's half-true. They're certainly integral to java, but they can
make C programs easier to grasp as well. Which is what they _should_
be used for, making code more readable. :)
I'll admit there's a certain amount of "flavor of the monthness" to
them, but it's not all hype.
> true, I haven't used threads that much myself, but most uses I've
> seen have been bad. To help the original poster, there is support
> for threading at the kernel level, but each entry in the so-called
> "ps list" is called a task.
> Each task can be a thread or full process, the kernel doesn't care, so it
> allocates a separate id for each task.
Most uses are bad. (See above) Unfortunatly, what you're suggesting
doesn't help, because the program he's porting relies on shared pids,
which _are_ required by the standard, and _not_ provided by the
kernel. See the long diatribe here about a week ago. :)
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Date: Wed, 6 Sep 2000 14:31:17 +0800
Reply-To: "Yuhong Ren" <[EMAIL PROTECTED]>
From: "Yuhong Ren" <[EMAIL PROTECTED]>
Subject: Linux driver for NI PCI6035E MIO card
Hi, all,
I have downloaded two Linus drivers for NI PCI6035E card, one is from the
NI's website, another is from Comedi. However, I could not setup them well
after trial and error. I always was informed that the device : /dev/nidaqX
or /dev/comediX could not be opened, but when I list with : ls -l /dev/ni*
or ls -l /dev/com*, the device all are there. I was puzzled with this
problem.
If you could please point out where I was wrong, I will be greatly
appreciated.
Warm regards,
Yuhong
------------------------------
From: [EMAIL PROTECTED] (Arturo C)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer,linux.redhat
Subject: Re: will GUI program compile using gtk+ run on KDE?
Date: 6 Sep 2000 07:02:20 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 5 Sep 2000 19:33:31 +0800, Richard Lim <[EMAIL PROTECTED]> wrote:
>can I use gtk+ to program GUI application and run it in KDE other then GNOME
>which I suppose it is suppose to run on.
If you mean running a GTK app while running the KDE evnironment. Yes, as
long as you have the libs installed its fine.
I don't use Gnome or KDE, but I have the libs for both installed, so I can
use Gnome/Gtk, and Qt/KDE apps, without having to run their Desktop Enviroment.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: /dev/log
Date: Wed, 06 Sep 2000 11:15:53 +0200
Derek Fountain wrote:
>
> I'm so vague on this I'm not even sure where to ask the
> question. Someone point me the right direction if this forum
> isn't appropriate.
>
> On my 2 Linux systems - 1 Redhat, the other SuSE - there's
> file called /dev/log. It's socket file:
>
> > ls -l /dev/log
> srw-rw-rw- 1 root root 0 May 4 11:11
> /dev/log
>
> I'm unfamiliar with the concept of sockets on my file
> system. Can someone explain how they are used, and, in
> particular, how I create one?
>
> I'm setting up a minimal Linux system on an embedded PC, and
> I've started from absolute scratch. It's an interesting
> exercise and I'm learning a huge amount, but mingetty won't
> run without this /dev/log file. I'm at a standstill until
> someone can tell me how to create it.
If you just need to create the special file you can
use this piece of code (Without error checking):
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
int main(int argc,char**argv)
{
struct sockaddr_un addr;
addr.sun_family=AF_UNIX;
sprintf(addr.sun_path,argv[1]);
bind(socket(PF_UNIX,SOCK_STREAM,0),&addr,SUN_LEN(&addr));
}
compile it with "gcc mksock.c -o mksock" and call it with
"mksock /dev/log". I don't know if that is enough to solve
your problem.
--
Kasper Dupont
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: two fib_lookup ?
Date: 06 Sep 2000 11:42:05 +0200
wolf <[EMAIL PROTECTED]> writes:
> when i was investigate the route method of linux , i found two different
> definition of fib_lookup(), which is used to look up a route for an ip
> packet.
>
> they are in :
> /linux/include/linux/ip_fib.h and
> /linux/net/ipv4/fib_rules.c
> why ?
One is used without CONFIG_IP_MULTIPLE_TABLES (=policy routing)
and the other is used with.
-Andi
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Strange Cash
Date: Wed, 06 Sep 2000 11:55:22 +0200
Adam Miezianko wrote:
>
> I had this strange system crash today on my VA Linux FullOn 2x2 running VA
> Linux 6.2. It stopped resoponding to all network connections, so I plugged
> in a monitor and keyboard and that too was dead. After a reboot I found
> that in /var/log/messages it said that:
>
> init: Id "x" respawning too fast: disabled for 5 minutes
>
> five times, at five minute intervals (which looks more or less normal). My
> inittab has:
>
> x:5:respawn:/etc/X11/prefdm -nodaemon
>
> which too looks normal.
>
> So, my question is, why would that bring the kernel down (I assume it did, I
> don't know how to verify that for sure). I have not had any problem with
> the box for months (though I did upgrade from 6.0 to 6.2 last week). I also
> don't know why gdm would be dying so much, since that did happen only this
> one time, and no one was using X at the time. Oh, if this helps, I
> installed Helix Gnome, which I am not sure if it modified any of the gdm
> files.
>
> Adam Miezianko
> [EMAIL PROTECTED]
>From the syslog messages it should be obvious that
the kernel, init and syslog was still runing as
usual.
When monitor and screen seemed dead it is probably
because X has crashed or been killed without the
oppertunity to shut down properly. That would leave
the keyboard in K_RAW mode on a VC with no programs
runing. This condition can only be fixed remote. I
think that both conditions would leave the image on
the screen frozen. So if X crashed after switching
to graphics mode, but before displaying anything,
the screen would be left black.
I cannot explain exactly what the connection between
dead network connections and X crashes are, but it
is likely that there are some connection.
I have a few suggestions for small modifictations to
the system configuration. First of all if you
normally not have any monitor connected I cannot
understand why you need X. Changing default runlevel
from 5 to 3 would probably be a good idea.
If you have any unused serial ports they can easily
be configured to be helpfull in this situation, I
use it all the time when I do some stupid experiments.
In /etc/inittab copy on of the mingetty lines and change
the ID field and the tty to eg S0 and ttyS0. Or even
better replace mingetty with a script which as far as I
remember should look something like:
#!/bin/sh
stty sane < /dev/$0
exec mingetty $0
That would probably make you a lot better prepared if
you happen to get problems again.
--
Kasper Dupont
------------------------------
** 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
******************************
