Linux-Development-Sys Digest #662, Volume #8 Sun, 22 Apr 01 07:13:12 EDT
Contents:
Re: How to get a number of processors (Chris)
Re: A Linux emulator for Linux, does this exist? (SammyTheSnake)
Re: New directions for kernel development ("Igor Shmukler")
Re: How to get all running process names ([EMAIL PROTECTED])
Re: How to get a number of processors ([EMAIL PROTECTED])
Re: How to get a number of processors (Chris)
Re: IO system throughput (Greg Copeland)
Re: Can Linux kernel ported on supercomputer (using 16 processor) (Greg Copeland)
Re: Thoughts on printing best practices?? recommendations?? (Greg Copeland)
Re: A Linux emulator for Linux, does this exist? (Jonadab the Unsightly One)
Re: How do I initiate Gnome? ("ray")
Re: unregistering sysctl (Doc)
Re: IO system throughput ([EMAIL PROTECTED])
Re: Problem compiling PHP 4 to work properly. ("Mark D")
----------------------------------------------------------------------------
From: Chris <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Sun, 22 Apr 2001 00:40:06 +0000
Hong Hsu wrote:
>
> Hi all,
>
> Here is my quick question. My application needs to know how many
> processors running in the host machine, is there API which allows me to
> get a number of processors?
sysconf(2); /usr/include/bits/confname.h
i.e.
printf("%d\n", sysconf(_SC_NPROCESSORS_CONF));
--
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
Sometimes I lie awake at night and ask ``Why me?'' Then a voice
answers ``Nothing personal, your name just happened to come up.''
(Charlie Brown, from `Peanuts', Charles Schultz)
------------------------------
From: [EMAIL PROTECTED] (SammyTheSnake)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Sat, 21 Apr 2001 23:58:29 +0100
In article <[EMAIL PROTECTED]>, Grant Edwards wrote:
>In article <[EMAIL PROTECTED]>, Jonadab the Unsightly One wrote:
>
>>> What about hot-swappable programs?
>>
>>That leads me to a feature I've been thinking about that I'd
>>like to have...
>>
>>At some kind of signal from the user, the kernel writes
>>the entire contents of RAM, plus the CPU registers and
>>any other relevant data, to a big file on disk, saves
>>a pointer to this so that it'll see it at boot time,
>>and then just powers down.
>>
>>Next boot time, it sees that flag file, loads the big
>>file off the disk to RAM, restores everything, and
>>picks up right where it left off, in the middle of
>>whatever it was doing.
>
>How's this different than the existing "suspend to disk" feature?
That's a feature of the (read some, laptops mostly) hardware. What I think
TOP means is something like the swsusp kernel patches which I'll find as
soon as I can get me hands on the blighters...aha!
http://falcon.sch.bme.hu/~seasons/linux/swsusp.html
I hope you like it, I do :)
Cheers & God bless
SammyTheSnake
--
Sam.Penny @ Ntlworld.com | Looking for a computer related
Linux, Hardware & Juggling specialist :-) | job, if you can help, e-mail me :)
Wheels: bike, 'ickle bike, and unicycle. | /o \/
Boxen: K6-266@300, dual Celery500 & Nx486 | \__/\
------------------------------
From: "Igor Shmukler" <[EMAIL PROTECTED]>
Subject: Re: New directions for kernel development
Date: Sun, 22 Apr 2001 00:56:33 GMT
> > As far as support of open source, I am happy to know that we can
> > count on guys like you.
>
> > If some people have not pulled resources back in the day. RMS would
> > have finished Hurd by now. But instead it's stuck in Debian's
> > bureaucracy.
>
> I have to make "contrary remarks" to this; almost certainly the _BEST_
> single thing that _EVER_ happened with Hurd was the involvement of
> Debian.
>
> Until they started the Debian/Hurd project, Hurd was languishing
> because you had to be a _serious_ Hurd hacker to even install it, and
> then were stuck with whatever software had been hacked into place to
> work with Hurd.
>
> When they became a Debian project, that added the potential to have
> many software packages made available without there necessarily being
> huge amounts of Hurd-specific hacking required; many Debian packages
> reportedly can be compiled on Hurd without any special effort.
First, I want to say, I am sorry I have written previous posting.
I was very tired etc and think it was uncalled for.
As far as Debian/Hurd marriage. I have to say one thing. OS in OS and not
some half baked product with lots of bells and whistles.
If they will produce solid kernel, porting shells etc will not take any
time. I think that despite numerous organizations behind project 80% of OS
code is being written by somewhat three people.
I have at some point tried to participate in the project, and can say that
it is not that easy. You need to have signed key, you need to contact
coordinators. I asked a question, if particular sub project is available and
could not get an answer etc.
I think Debian's Linux is best distribution. They are really with compiling
stuff, but I have not seen results from Debian Hurd. I think kernel has not
changed much since 1998. I may be wrong here too, so don't take it too
seriously.
> (concatenate 'string "aa454" "@freenet.carleton.ca")
> http://vip.hyperusa.com/~cbbrowne/resume.html
> "Another of Fortran's breakthroughs was the GOTO statement, which was
> a uniquely simple and understandable means of structuring and
> modularizing programs." -- Article on Backus' "Draper Prize"
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to get all running process names
Crossposted-To: comp.os.linux.development.apps
Date: Sun, 22 Apr 2001 01:08:40 GMT
In comp.os.linux.development.system Hong Hsu <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am newer for Linux and wondering there is API which allows me to get
> process related information, such as process names, process ID and
> process' memory usage. How ps or top get these information? Is source
> code of ps or top available somewhere? If I need to dig into kernel
> symbol table via /dev/kmem, where the data structure of kernel symbol
> table is defined?
You might want to look at the /proc filesystem. If you look there
you are likely to find all sorts of directories which look like
numbers. And if you look at the files in the directories, you
will find the information you want.
I expect that's where ps and top get them from.
--
Best regards,
Stephen Jenuth
([EMAIL PROTECTED])
Quidquid latine dictum sit, altum viditur.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to get a number of processors
Crossposted-To: comp.os.linux.development.apps
Date: Sun, 22 Apr 2001 01:10:18 GMT
In comp.os.linux.development.system Chris <[EMAIL PROTECTED]> wrote:
> Hong Hsu wrote:
>>
>> Hi all,
>>
>> Here is my quick question. My application needs to know how many
>> processors running in the host machine, is there API which allows me to
>> get a number of processors?
> sysconf(2); /usr/include/bits/confname.h
> i.e.
> printf("%d\n", sysconf(_SC_NPROCESSORS_CONF));
A better bet would be to have your program look at /proc/cpuinfo
--
Best regards,
Stephen Jenuth
([EMAIL PROTECTED])
Quidquid latine dictum sit, altum viditur.
------------------------------
From: Chris <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Sun, 22 Apr 2001 01:25:58 +0000
[EMAIL PROTECTED] wrote:
>
> In comp.os.linux.development.system Chris <[EMAIL PROTECTED]> wrote:
> > Hong Hsu wrote:
> >>
> >> Hi all,
> >>
> >> Here is my quick question. My application needs to know how many
> >> processors running in the host machine, is there API which allows me to
> >> get a number of processors?
>
> > sysconf(2); /usr/include/bits/confname.h
>
> > i.e.
>
> > printf("%d\n", sysconf(_SC_NPROCESSORS_CONF));
>
> A better bet would be to have your program look at /proc/cpuinfo
No it wouldn't.
--
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
Dogs believe they are human. Cats believe they are God.
------------------------------
Subject: Re: IO system throughput
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 21 Apr 2001 23:02:57 -0500
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> Paul Repacholi <[EMAIL PROTECTED]> wrote:
>
> >The problem Linux, and unix in general has is that async IO is at zero
> >level in the user code. Chicken and egg to a large degree...
>
> fork() is cheap. _If_ you want async IO let a separate process to do
*Cough*, not compared to letting the kernel do it. By using a fork in this
situation, you have created a _significant_ amount of additional work which
would greatly limit the return on asynchronous I/O which is generally observed
on a heavily I/O bound system. By using fork, you are trying to implement,
poorly and slowly in user code, what the kernel could do elegantly if
implemented properly.
> normal IO to/from shared segment. And "if" above is a pretty serious one -
Now you've added more code to synchronize the access to the data whereby,
the kernel would already be serializing it for you. Again, more overhead.
I'm not saying that there wouldn't be any synchronization or serialization
to perform by the programmer, rather, I believe the task is somewhat eased.
> 99% programmers _can't_ write safe asynchronous code. And I mean algorithm
> level - like "you should not let two threads of execution add elements
> into the same double-linked list unless you protect the critical area".
> If that requires considerable amount of thinking, poking around with
> debugger, etc. - sorry, but it means that one should stay the fsck out
> of any asynchronous code. And for absolute majority of programmers that's
> exactly the case. Worse than buffer overflows, worse than inability to
> live without garbage collector - most of multithreaded programs are
> choke-full of races that should have shown up on the first code review done
> by anybody even remotely competent. And yes, I'm talking about code that
> had been reviewed and intended for real use. So thank you very much, I'd
> rather see async stuff of any kind used only when it's absolutely necessary.
> It's bad enough on the kernel side where that stuff _is_ necessary (and
> people still manage to fuck up in the mind-boggling ways - destructors
> called before removing references from shared data structures, etc.).
> In the applications code... <shudder> Been there. seen that, nearly vomited
> my guts out while reviewing the crap.
You've lumped several things together. Language, implementation, and
architecture. That makes for a mouth full. Actually, since the kernel
would be serializing much (not all) of the operations when asynchronous
I/O is performed (versus a user trying to creating via a fork/thread
model), design is greatly simplified. In short, it *generally* allows the
programmer to concentrate on small sections of code that handle simple
operations. Often the call back is nothing more than a dispatch routine
which calls the actual function that is appropriate to handle the
returned tag. Needless to say, I do understand what you are saying.
>
> Sigh... Sorry about the rant - just spent an hour dealing with a "Threads!
> Are! Wonderful!" duhveloper. Most of that time went on showing him why
> this, this and that is _not_ going to work. And yes, the list included
> manipulation of the shared data structures without any exclusion, use
> of global variables by async code in a way that was completely bogus
> _and_ not needed, memory management stuff done in signal handlers and broken
> beyond belief. deadlocks "dealt with" by sending SIGKILL if potential
> victims made no progress for too long, etc., etc. Finally gave up and
> sent him to hell... If Dave Null feels like continuing attempts to educate
> this idiot - more power to him.
Sorry for the level of frustration that is obvious you currently feel. I've
been there. Please keep in mind the significant reward for using asynchronous
I/O is where very high I/O loads are expected. Generally speaking, this does
not allow most applications to qualify. So, as a rule of thumb, most
programmers should not be using it. Oddly enough, this is probably one of
many reasons why Linux does not currently support it.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 21 Apr 2001 23:13:24 -0500
[EMAIL PROTECTED] (Ulrich Weigand) writes:
> Greg Copeland <[EMAIL PROTECTED]> writes:
>
[snip]
> >as far as I can remember, Linux running on the 390 looks like a uniprocessor
>
> The S/390 is most certainly a SMP machine, both natively and also the virtual
> machines under LPAR, VM, or VIF. The latest hardware models support up to
> 16 physical processors, and under VM you can assign up to 64 virtual processors
> to any single guest. Linux for S/390 of course supports SMP, up to the usual
> (Linux) limit of 32 processors on 32-bit archs (64 processors on 64-bit archs).
Thanks. I was very sure that 390 supported multiple CPUs, I was just under
the impression that Linux could only run as a uniprocessor on said system. Cool!
Thanks for the correction!
>
> >Long story short, last I read, it was thought that Linux would scale well
> >to 12 or so processors with a steady fall off out to about 16 processors.
>
> The question is, what are you doing? User mode processes should scale
> bascially linearly. In kernel mode, it depends on what areas of the kernel
> you are exercising. There are still some things where lock contention gets
> a problem, but for say the networking layer, the 2.4 kernel should scale
> pretty well ...
That's a given. This is, in fact, thought to be one of the reasons why Linux
clusters scale so well because they are mostly user mode FP type code. For
the record, I was only speaking to the 2.4 kernel. It is well understood that
the 2.2 kernel was limited to 2 CPU's and that 4+ was killing it.
>
> However, this can really be decided only by running proper benchmarks; and
> I unfortunately haven't seen any beyond 8-way. A 16-way Linux running
> natively on a S/390 would really make an interesting scalability benchmark
> possible ;-)
Ya! I'd love to see IBM publish some information on this. Be very interesting
to see why kind of scaling they can get out of a box like that using a VM with
Linux running 1, 2, 4, 8, 16, and 32 CPUs. May not have much meaning beyond
that platform but it would sure be nice to see if you even get a return beyond
16 processors!!!
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: Thoughts on printing best practices?? recommendations??
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 21 Apr 2001 23:15:47 -0500
Excellent idea! CUPs even allows for printer
discovery on a network. Very slick. I've used it
only a little, but I have been impressed. Take that
with a grain of salt, but keep in mind, I'm generally
not impressed.
Greg
"Cameron Kerr" <[EMAIL PROTECTED]> writes:
> Look to CUPS. It seems to be promising and suited to
> todays printers (where drivers are often required for
> inkjet printers etc).
>
> --
> Cameron Kerr -- cameron.kerr @ paradise.net.nz
> Praise Slackware, our baud and saviour!
> --
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED] (Jonadab the Unsightly One)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Sun, 22 Apr 2001 04:28:46 GMT
[EMAIL PROTECTED] (Grant Edwards) wrote:
> How's this different than the existing "suspend to disk" feature?
Hey, you mean it's been *done*? Wow, cool. "Suspend to disk" is
a good name for it... I'll have to check that out. Nifty.
- jonadab
------------------------------
From: "ray" <[EMAIL PROTECTED]>
Subject: Re: How do I initiate Gnome?
Date: Sun, 22 Apr 2001 17:26:59 +0800
I have tried both .Xclients and .xinitrc. Neither options work.
When I have the .xinitrc file, the startx command fails. It could not even
execute the fvwm environment.
"Kasper Dupont" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Greg Knopf wrote:
> >
> > If you edit your .xinitrc file, you can specify a window manager, such
as
> > fvwm or afterstep or whatever. I think what you want to do is start
> > "enlightenment" instead of fvwm, and you will get a gnome environment.
> >
> > ray <[EMAIL PROTECTED]> wrote in message
> > news:9bh0m0$kp2$[EMAIL PROTECTED]...
> > > How do I initiate a gnome from fvwm?
> > > Thanks
> > >
> > >
>
> I'm not 100% sure about this, but I think
> it would be better to put that in .Xclients
> rather than .xinitrc.
>
> --
> Kasper Dupont
------------------------------
From: Doc <[EMAIL PROTECTED]>
Subject: Re: unregistering sysctl
Date: Sat, 21 Apr 2001 16:12:34 +0200
Il giorno Thu, 19 Apr 2001 13:40:37 +0200, il gatto di Doc
<[EMAIL PROTECTED]> camminando sulla tastiera ha scritto:
>if i write to "my_entry" (echo "data"> ...../my_entry) i have no
>problem unregistering the interface but if i do the same thing with
>"my_subdirentry" when i unregister the interface that entry is no longer
>removed. if i do *not* write to that entry, all the subtree is removed
>correctly. no error messages are given.
i found the problem. as i've said in last post, i'm trying to find a way
to change the procname displayed in directories at runtime. simply
changing the entry in the table after registering the tree doesn't work
(after seeing the registering code it seems quite obvious) and at
unregistering time it causes the process to fail because the registered
name and that in the table do not corresdond.
the problem about how to change names at runtime persists.
ciao
--
maruko.cjb.net - Seti@Home applets
Designed for Windows
Powered by Linux
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IO system throughput
Date: Sun, 22 Apr 2001 12:27:32 +0200
Greg Copeland <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Alexander Viro) writes:
>> In article <[EMAIL PROTECTED]>,
>> Paul Repacholi <[EMAIL PROTECTED]> wrote:
>>
>> >The problem Linux, and unix in general has is that async IO is at zero
>> >level in the user code. Chicken and egg to a large degree...
>>
>> fork() is cheap. _If_ you want async IO let a separate process to do
> *Cough*, not compared to letting the kernel do it. By using a fork in this
> situation, you have created a _significant_ amount of additional work which
> would greatly limit the return on asynchronous I/O which is generally observed
> on a heavily I/O bound system. By using fork, you are trying to implement,
> poorly and slowly in user code, what the kernel could do elegantly if
> implemented properly.
What do you think of the following system call that exists under FreeBSD
and allows to do the thing you like, if i don't err:
int
kqueue(void)
int
kevent(int kq, const struct kevent *changelist, int nchanges,
struct kevent *eventlist, int nevents,
const struct timespec *timeout)
DESCRIPTION
kqueue() provides a generic method of notifying the user when an event
happens or a condition holds, based on the results of small pieces of
kernel code termed filters. A kevent is identified by the (ident, fil-
ter) pair; there may only be one unique kevent per kqueue.
This is used to do asynchronous read or write:
aio_read - asynchronous read from a file (REALTIME)
aio_write - asynchronous write to a file (REALTIME)
I don't know if the same exists under Linux, but if not it is not a big
addition to do. If this is sufficient to solve your problem, this means
that it can be solved in the Unix context, without having to consider
monstruosities like Windows.
--
Michel Talon
------------------------------
From: "Mark D" <[EMAIL PROTECTED]>
Subject: Re: Problem compiling PHP 4 to work properly.
Date: Sun, 22 Apr 2001 18:48:51 +0800
Thanks Phil
Tried that. The module is in with all the other modules in /usr/lib/apache.
The error seems to be an unresolved symbol in the module itself. If I
compile without IMAP, I don't get the problem, but of course I don't get
IMAP support either.
Cheers
Mark
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sun, 15 Apr 2001 21:29:17 +0800 Mark D <[EMAIL PROTECTED]>
wrote:
>
> | I have a very annoying problem when I try to compile and run PHP 4.
> |
> | I compile with the following options.
> |
> | rm config.cache
> |
./configure --with-apxs --with-imap --with-pgsql --without-mysql --without-k
> | erberos
> | make clean
> | make
> | make install
> |
> | When I try to fire up Apache, I get the following error
> |
> | Starting httpd: Syntax error on line 872 of /etc/httpd/conf/httpd.conf:
> | Cannot load /etc/httpd/modules/libphp4.so into server:
> | /etc/httpd/modules/libphp4.so: undefined symbol: gss_mech_krb5
> |
> | I have loaded all the krb5 rpms, rebuilt the php from scratch, etc, but
I
> | cannot get rid of this error.
> |
> | Any ideas?
>
> Where did the library get installed? Make sure that directory is
> listed in the /etc/ld.so.conf file. Then run "ldconfig" to update
> the /etc/ld.so.cache file. Maybe Apache can be configured with the
> location on its own. See "man dlopen" for a description of the
> library call that Apache is probably using so you can get an idea
> of what information it has to have (or figure out) to load a shared
> library to be a module.
>
> Another option is to not use DSO and compile everything in all at
> once.
>
> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
> | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
> -----------------------------------------------------------------
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
