Linux-Development-Sys Digest #698, Volume #8 Mon, 7 May 01 14:13:15 EDT
Contents:
Re: Assigning capabilities to users (Eric Buddington)
Re: How to get a number of processors (Stefaan A Eeckels)
Re: Sun Solaris IPC (Chuck Dillon)
Re: Sun Solaris IPC ([EMAIL PROTECTED])
dependancy question (TN)
Re: Help - Edit route table in software? ("MR")
Re: How to get a number of processors (John Beardmore)
Re: How to get a number of processors (John Beardmore)
Re: losing bottom halves
Re: How to get a number of processors (Roberto Nibali)
Re: serial port autodetection (Javier Loureiro Varela)
Re: programming the serial port (Javier Loureiro Varela)
Re: How to get a number of processors (Nix)
Re: How to get a number of processors (Greg Copeland)
Re: serial port autodetection (Grant Edwards)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Eric Buddington)
Subject: Re: Assigning capabilities to users
Date: Mon, 07 May 2001 14:18:44 GMT
In article <wvUF6.1082$[EMAIL PROTECTED]>, Cameron Kerr wrote:
>
>In order to minimise risk, I would like to give each user
>the capability CAP_NET_RAW so they can create the socket
>they need for their program to work, instead of assigning
>root rights, which is not something I want to do.
>
>Can this be done? I would like to able to put an entry
>into the passwd file, so that the capability would be
>inherited from the shell.
>
>eg.
>cameron:x:1000:100:Cameron Kerr,,,:/home/cameron:givecap CAP_NET_RAW
>/bin/bash
>
>Is this even the right way to approach capabilities?
No, but only because /bin/login won't recognize such a field.
If you install libcap, you will have a utility called 'setpcaps'
which can be used to give capabilities to running processes.
However, the 'setpcaps' program has to have the capability cap_setpcap,
which is entirely disabled in the current kernel - you'll have to tweak
linux/include/sys/capability.h and set CAP_FULL_SET to 'to_cap_t(~0)' and
recompile Mr. Kernel.
The rest you can probably figure out.
-Eric
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: How to get a number of processors
Crossposted-To: comp.os.linux.development.apps
Date: Mon, 7 May 2001 15:19:55 +0200
In article <[EMAIL PROTECTED]>,
Greg Copeland <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Eric P. McCoy) writes:
>
>> Greg Copeland <[EMAIL PROTECTED]> writes:
>>
>> > Oddly enough, my man page for sysconf doesn't show the _SC_NPROCESSORS_CONF
>> > option. Hmm....wonder how long it's been around.
>>
>> It starts with an underscore, which probably means it's nonstandard.
>> I'd be a little stronger and say that if it's not in the man page,
>> you also shouldn't use it.
>>
>> This strikes me as a battle of bad ideas: I hate writing a text parser
>> to deal with /proc; I don't like using nonstandard pieces of code; and
>> no program should ever need to know how many processors are in a given
>> box. There are cases where you'd want to use one or all of these bad
>> ideas, but I, for one, would need a pressing reason.
>>
>
> I strongly disagree with the assertion that no one would ever need to know
> how many processors there are in a system. I have worked on some large UNIX
> boxes and needed to know how may there were. I took the short path made it
> a user determined value, but making it dynamic would of been nicer. BTW, it
> was for parallelizing some computations and the number parallel index
> optimizations that could be run at a single time while still allowing for
> free CPU's to handle from other batch jobs. In short, if I exceeded more
> than 75% of the CPU's (rounded down), the batch jobs suffered too heavily. As
> you can see, making it dynamic would of been nice since it had to run on
> several different size boxes (4 and 8 CPU machines). Keep in mind, some of
> these batch jobs would run for 8-18 hours. If I took the other CPU's,
> it would force them to run over their maximum run-time window, which was
> 18-hours. If I didn't take enough, I wouldn't finish in the required
> window. I would of rather had someone be able to say 50% or 75% of the CPUs
> should go here, than a hard number, as I did do, which required unique config
> files on each system. At any rate, I don't think it's wise to assert such a
> rule should exist.
Maybe the OS should provide a service to ensure that certain
processes get a minimum of CPU time. The approach you describe
is a hack, and goes completely against the basic Unix concept
of hiding the hardware differences and specifics from the
applications.
--
Stefaan
--
How's it supposed to get the respect of management if you've got just
one guy working on the project? It's much more impressive to have a
battery of programmers slaving away. -- Jeffrey Hobbs (comp.lang.tcl)
------------------------------
From: Chuck Dillon <[EMAIL PROTECTED]>
Crossposted-To:
comp.unix.questions,comp.unix.programmer,comp.os.linux.misc,comp.unix.solaris
Subject: Re: Sun Solaris IPC
Date: Mon, 07 May 2001 09:32:59 -0500
vardhan wrote:
>
> Hi,
>
> I need to find information about the various UNIX
> implementations/standards(?) for IPCs (message Queues, pipes, shared
> memory), such as POSIX, ATT, SVR4, BSD etc. I need this for comparing
> and listing the adv/disadv of each for a particular project, to find the
> best IPC mechanism suitable for the project.
>
> The project is based on a Solaris platform (version unknown) running a
> SunOS (probably 5.6). I assume that the particular SunOS itself will be
> using a specific Unix IPC standard. Please correct me if I am wrong. My
> question is, in this case (Sun on Solaris) what are the options I have
> for IPC, and where do I get the information to made a comparative study
> most suitable for me? Specifically, where do I begin to get the
> information I need? I am quite comfortable with basic UNIX IPC and sytem
> calls.
>
> Any suggestions in the form of book titles/we links are welcome!
Try going to docs.sun.com and searching for IPC. The 'System
Interface Guide' of the developer collection is probably a good
place to start.
-- ced
--
Chuck Dillon
Senior Software Engineer
Genetics Computer Group, a subsidiary of Pharmacopeia, Inc.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
comp.unix.questions,comp.unix.programmer,comp.os.linux.misc,comp.unix.solaris
Subject: Re: Sun Solaris IPC
Date: Mon, 07 May 2001 15:02:53 GMT
There are multiple methods of doing IPC, depending on what your requirements
are. Basic "UNIX" facilities include the use of pipes (half duplex) and
named
pipes (full duplex, aka FIFOs). There is also UNIX domain sockets for
full duplex communication between processes.
Traditional System V IPC consists of;
- Shared memory
- Message Queues
- Semaphores
POSIX came along and added;
- Shared Memory
- Message Queues
- Semaphores
[see a pattern? :^)]
Basically, you have 2 different and distinct sets of APIs for doing shared
memory,
messaging and/or semaphores. The POSIX and SysV interfaces are very
different,
and while they provide similar functionality, there are some important usage
differences. They are also implented very differently; Sys V IPC is
implemented
in the kernel, POSIX IPC is implemented using mmap'd files.
Solaris also provides an extremely poorly documented facility called Doors.
To learn how and when to use these facilities, please read;
UNIX Network Programming, Interprocess Communications, Volume 2,
Second Edition. by W. Richard Stevens. ISBN 0-13-081081-9.
To learn a bit about how they are implemented in Solaris, please read;
Solaris Internals. by Jim Mauro and Richard McDougall.
ISBN 0-13-022496-0
/jim
vardhan wrote:
> Hi,
>
> I need to find information about the various UNIX
> implementations/standards(?) for IPCs (message Queues, pipes, shared
> memory), such as POSIX, ATT, SVR4, BSD etc. I need this for comparing
> and listing the adv/disadv of each for a particular project, to find the
> best IPC mechanism suitable for the project.
>
> The project is based on a Solaris platform (version unknown) running a
> SunOS (probably 5.6). I assume that the particular SunOS itself will be
> using a specific Unix IPC standard. Please correct me if I am wrong. My
> question is, in this case (Sun on Solaris) what are the options I have
> for IPC, and where do I get the information to made a comparative study
> most suitable for me? Specifically, where do I begin to get the
> information I need? I am quite comfortable with basic UNIX IPC and sytem
> calls.
>
> Any suggestions in the form of book titles/we links are welcome!
>
> thanks,
> Vardhan
>
> PS: Please pardon if the question has been incorrectly framed, since I
> am not yet quite comfortable with
> different flavors of Unix.
>
> --
>
> Vardhan Walavalkar
> email: [EMAIL PROTECTED]
------------------------------
From: TN <[EMAIL PROTECTED]>
Subject: dependancy question
Date: Mon, 7 May 2001 11:42:59 -0400
When I get a dependancy problem, what is the best way of finding/tracing
what package/library the missing file is in.
TIA
------------------------------
From: "MR" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Help - Edit route table in software?
Date: Wed, 2 May 2001 19:12:10 +0200
"Sebastien Jean" <[EMAIL PROTECTED]> wrote in message
news:9c56b2$7ac$[EMAIL PROTECTED]...
> Changing the routing table from the command line is easy. Does anyone
know
> how to change the routing table from within a program written in C/C++?
> What about changing Ethernet device parameters.
>
Try the libiptc library shipped with iptables 1.2.1.
Bye,
MR
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Mon, 7 May 2001 16:45:10 +0100
In message <[EMAIL PROTECTED]>, Stefaan A Eeckels
<[EMAIL PROTECTED]> writes
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Dave Blake) writes:
>> Eric P. McCoy <[EMAIL PROTECTED]> wrote:
>>
>>> This strikes me as a battle of bad ideas: I hate writing a
>>> text parser to deal with /proc; I don't like using nonstandard
>>> pieces of code; and no program should ever need to know how
>>> many processors are in a given box. There are cases where
>>> you'd want to use one or all of these bad ideas, but I, for
>>> one, would need a pressing reason.
>>
>> Suppose I am writing a data crunching piece of software that
>> parallelizes easily, and wish to run a thread on each processor.
>>
>> I first parse /proc/stat, and then crunch away with a thread
>> on each CPU.
>>
>> For a web searching program, you may wish to know the number of
>> NICs and CPUs, and take the lower of the two as the number of
>> threads to run. And so on.
>
>In a Unix system, the application should not need to know
>anything about the hardware details.
<dOGMA aLERT !>
Well then, in that case, why don't YOU start the project to make gcc
exploit all possible opportunities for parallelism ?
> The recent obsession
>with threads violates that basic tenet.
You sound if you find threads morally objectionable as opposed to 'just
another way to get the job done'.
> If one wants to
>squeeze the last ounce of performance from a box,
But it's not the 'last ounce' ! On some boxes it's most of the ounces !
> don't
>use an OS.
Oh balls.
'Use an OS and a compiler that knows about parallelism'
might be a better assertion, but pausing briefly to live in the real
world, C is not terribly 'parallel aware', and gcc is what most us here
want to work with.
I don't see any moral problem with C and Linux supporting threads. Even
on single CPU machines this can speed up some IO operations with
simultaneous reads on more than one device for example. I really don't
see the point in coming over all 'closed minded' about it.
Now if you're going to make the number of threads equal the number of
processors for some crunching task, WTF is wrong with the OS making that
info available ?? It's only one integer and nobody's forcing YOU to use
it if you object on religious grounds.
Cheers, J/.
--
John Beardmore
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Mon, 7 May 2001 16:47:19 +0100
In message <[EMAIL PROTECTED]>, Stefaan A Eeckels
<[EMAIL PROTECTED]> writes
>Maybe the OS should provide a service to ensure that certain
>processes get a minimum of CPU time. The approach you describe
>is a hack, and goes completely against the basic Unix concept
>of hiding the hardware differences and specifics from the
>applications.
Guaranteeing resources to processes may be a good tool, but it isn't an
alternative to knowing how many threads to create for a big crunching
job. For that, you still need to know the number of available
processors.
Cheers, J/.
--
John Beardmore
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: losing bottom halves
Date: Mon, 07 May 2001 15:54:30 -0000
In article <9d5od2$bqg$[EMAIL PROTECTED]>,
Barry Smyth <[EMAIL PROTECTED]> wrote:
>I have transfered all my Bottom Half code directly into the isr, since the
>bottom half cannot be guaranteed to execute before the next interrupt
>arrives.
You say that as though it were some kind of flaw.
--
http://www.spinics.net/linux
------------------------------
From: Roberto Nibali <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Mon, 07 May 2001 18:03:34 +0200
> I *think* this is new in glibc2.2. If you don't have this sysconf, you can do
> the C equivalent of:
>
> grep processor < /proc/cpuinfo | wc -l
>
> :)
<completely OT>
On behalf of Randal L. Schwartz:
UUOC: grep -c processor /proc/cpuinfo
Just another Useless Use of Usenet,
Roberto Nibali, ratz
</completely OT>
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
------------------------------
From: [EMAIL PROTECTED] (Javier Loureiro Varela)
Subject: Re: serial port autodetection
Date: Mon, 07 May 2001 16:41:37 GMT
On Fri, 4 May 2001 18:22:31 +0100, John Beardmore
<[EMAIL PROTECTED]> wrote:
>Are they just getting lucky with the UART settings, or are they doing
>something smarted along the lines of looking 'around' they UART to the
>incoming wave form and working out the baud rate from the length of the
>start bit or something ?
maybe, they use some kind of low level protocol for this
autodetection (like LAPM for error checking)...
but I'm talking about a plain serial port sending raw ascii
data... I dont know where to begin. Anyone has detected any parameter
from the "remote" serial port?
thaks!
--
signed,
Javier Loureiro Varela
Class One
System Research Leader
------------------------------
From: [EMAIL PROTECTED] (Javier Loureiro Varela)
Subject: Re: programming the serial port
Date: Mon, 07 May 2001 16:41:38 GMT
On Mon, 07 May 2001 01:39:35 GMT, [EMAIL PROTECTED] (Carlos
Justiniano) wrote:
>Javier,
>
>If you haven't already come across the "Serial Programming Guide for
>POSIX Operating Systems", I highly recommend it!
>
>http://www.easysw.com/~mike/serial/serial.html
I did it, and It's pretty cool, indeed!
also, I found this book in Amazon: "C programmers Guide to Serial
Communication", by Joe Campbell. Have you ever read about this book?
--
signed,
Javier Loureiro Varela
Class One
System Research Leader
------------------------------
From: Nix <$}xinix{$@esperi.demon.co.uk>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: 07 May 2001 17:18:56 +0100
On Mon, 7 May 2001, John Beardmore yowled:
> Guaranteeing resources to processes may be a good tool, but it isn't
> an alternative to knowing how many threads to create for a big
> crunching job. For that, you still need to know the number of
> available processors.
<pedant>
No, you need to know the number of simultaneously executing tasks, which
is quite a different thing (or it could be, on high-end systems).
The number of physical lumps of doped silicon inside the machine is an
irrelevant hardware detail.
</pedant>
--
`I like to think the situation could be likened to doing heart surgery
in a hurry with a plastic spoon after having a couple of pints.'
--- James Reeves
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 07 May 2001 12:37:38 -0500
[EMAIL PROTECTED] (Stefaan A Eeckels) writes:
> In article <[EMAIL PROTECTED]>,
> Greg Copeland <[EMAIL PROTECTED]> writes:
> >
> > I strongly disagree with the assertion that no one would ever need to know
> > how many processors there are in a system. I have worked on some large UNIX
>
> Maybe the OS should provide a service to ensure that certain
> processes get a minimum of CPU time. The approach you describe
> is a hack, and goes completely against the basic Unix concept
> of hiding the hardware differences and specifics from the
> applications.
I *completely* disagree with you. You are unable to get past the simple fact that
parallel computing has requirements above and beyond simple server programming
where you are using a pool of processes/threads or even a 1:1 process/thread per
client. Actually, let's talk about those for a second. If you are no longer
using a 1:1 model of process/thread per client, then it's safe to assume you've
come to an scalability impasse where you decided that a pool of resources will
scale better. Why do you supposed that you hit the wall and was forced to change
models? In the above cases, you are assuming that you are the only processes with
significant priority on it, as obviously, a heavily loaded system will, by far,
not be servicing clients and other applications fairly. Once you realize that
you may need to service a mix of these types of applications, you are once again
forced to adopt another model. This is hardly a hack. This is the real world.
Now then, *my* implemention is somewhat of a hack, but simply because the
information was not readily available. Keep in mind, this is one such reason
why some OS's provide facilities for process afinity which would simply allow
a process to run, for example, on the first 4 processors and leave the other
four free reguardless of how many children or threads the parent makes.
I spelled out, using a real world situation why such a mechanism needs to exist.
You simply said it's a hack and violates some made up "tenet". Please tell me
how you would solve it. Keep in mind this was on a project that was three years
and 2-million overdue and long delays of yet *another* complex system would
more than likely result in the rolling of your head and/or arse. Even without
such constraints, I'd like to see your magical solution. Saying the concept
is a hack, which is clearly required, without any supportive evidence seems
a pretty cheap way out to me.
Greg
--
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] (Grant Edwards)
Subject: Re: serial port autodetection
Date: Mon, 07 May 2001 18:08:39 GMT
In article <[EMAIL PROTECTED]>, Javier Loureiro Varela wrote:
>>Are they just getting lucky with the UART settings, or are they
>>doing something smarted along the lines of looking 'around'
>>they UART to the incoming wave form and working out the baud
>>rate from the length of the start bit or something ?
>
> maybe, they use some kind of low level protocol for this
>autodetection (like LAPM for error checking)...
Nope, they don't. They just assume that the first thing they
see is going to be an 'A'. You measure the length of the start
bit to determine baud rate, and then look for the stop/parity
bits.
> but I'm talking about a plain serial port sending raw ascii
>data... I dont know where to begin. Anyone has detected any parameter
>from the "remote" serial port?
It can't be done using a normal Posix serial driver. At least
not on any of the ones I've worked on or looked at.
--
Grant Edwards grante Yow! Yow! Is my fallout
at shelter termite proof?
visi.com
------------------------------
** 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
******************************
