Linux-Development-Sys Digest #153, Volume #7 Sat, 4 Sep 99 11:14:03 EDT
Contents:
Re: LINUX AND COREL (Peter Samuelson)
Re: threads (Peter Samuelson)
Re: How can i see the output of printk ? (Peter Samuelson)
Re: what about SGI's xfs? (Warren Young)
Re: select() and FD_SETSIZE (Warren Young)
Re: linux driver examples from rubini (Warren Young)
Re: TAO: the ultimate OS (Nix)
Re: LispOS? (Nix)
Can I install Linux on an IBM PS/2 model 95 XP 486? ("Alan Smeltzer")
Re: Help Compiling GCC 2.95.1 (Please!! ) (NF Stevens)
Re: need help on ptrace (David Powell)
Re: problems with put_user (nightstalker)
Re: [Linux] Calling C from Fortran: Function always returns zero? (John Forkosh)
Re: Linux on RS/6000 (Magnus Larsson)
Re: Question: Child Process I/O (Sami Tikka)
[Linux] Calling C from Fortran: Function always returns zero? (John H. Chauvin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.misc
Subject: Re: LINUX AND COREL
Date: 4 Sep 1999 02:01:22 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Robert Komar <[EMAIL PROTECTED]>]
> Not only their own code. If Wine works well, then more Windows users
> might be persuaded to leave behind their OS without abandoning their
> applications. Corel apps by themselves may not persuade many people
> people to move to Linux, but being able to use Windows apps within
> Linux will probably attract more of them.
You're probably right; their upcoming distribution is engineered for
ease of use. But I get the feeling they decided to invest in wine
mostly for their own code. WordPerfect Office 2000 is huge. It is
closely tied to Win32, arguably even more closely tied than Microsoft
Office which has a Mac port. They might well have decided that getting
winelib to the point of being able to run WP Office 2000 (perhaps with
some source tweaks to their own code to help) would be easier than
porting all their own code.
I do appreciate the goodwill gesture of working with the Wine project
rather than forking off a private copy of winelib, which the BSD-ish
license would have allowed. I say goodwill because although it's
common sense, you can't always assume corporate types will see the
sense in it.
> And if their code happens to run flawlessly in that environment while
> the others cough once in a while,...?
Actually I would expect the reverse: operating system quality
notwithstanding, winelib still has a long ways to go to match the
stability of the reference implementation....
Or did you mean "the others" to be other winelib apps? In that case I
agree with you.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: threads
Date: 4 Sep 1999 01:48:51 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[M van Oosterhout]
> > The other main problem with threads is that if any of then get an
> > error, then the whole process dies. With Apache, if a loadable
> > module segfaults. that single process dies and it's parent spawns
> > a new one. Thus, Apache tends to never crash.
[David Schwartz <[EMAIL PROTECTED]>]
> Any program that has a bug will crash, threaded or not. Hardening
> threaded programs is done the same way you harden non-threaded ones.
> This is a red herring.
No it's not. Apache *contains the damage* if a single module happens
to be buggy and segfaults. This is good because Apache has a modular
design which allows you to run third-party modules easily, some of
which may be more stable than others. Better to abort a certain type
of connection, or whatever circumstance triggers the module bug, than
to have to take down and restart the whole web server. At worst case
you have a little slowdown (extra fork()s necessary) and connections
which meet certain conditions (server-side imagemaps, say) won't be
served properly, while other connections will.
To get this level of protection with threads, you would have to catch
SIGSEGV and SIGBUS and either shut down the thread or figure out a way
to longjmp back to a known good state. Possible, yes, but harder.
> > The reason why samba doesn't use threads is because it needs
> > different security contexts for each connection (uid, groups,
> > etc).
> If you receive an unknown message in a threaded program, you can log
> it and stop processing that connection.
Which doesn't answer the reason I quoted above, the reason which would
IMHO make it quite inappropriate to use threads in Samba. And no,
before someone suggests it, the answer is NOT to run as root and do all
the security checking yourself.... (:
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: How can i see the output of printk ?
Date: 4 Sep 1999 01:53:04 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Kim Jeong-Won <[EMAIL PROTECTED]>]
> How can I see the output of printk() in kernel code ?
Use prefixes -- see include/linux/kernel.h for KERN_EMERG et al.
Adjust /proc/sys/kernel/printk -- see Documentation/proc.txt.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: what about SGI's xfs?
Date: Tue, 31 Aug 1999 22:33:48 -0600
Peter Samuelson wrote:
>
> important. Distributions are getting along fine without ACL's now; I
> foresee that if and when ACL's become available, that they will be used
> primarily by individual administrators and users rather than set up as
> defaults by a distribution.
It seems to me that ACLs are a fine-grained access control mechanism for
ad-hoc security: Joe User wants to give access to one of his files to
Jane User, but doesn't want to ask the sysadmin to set up a group for
that one purpose, and doesn't want to inadvertently give Jim User access
to the file by setting it g+r. So, he adds Jane to the file's ACL for
read-only access.
If you have a more permanent need to fill, you can probably get by with
suitable usage of group permissions.
One thing to keep in mind about ACLs is that they're mandated for class
B Orange Book security. So, they're probably in a lot of OSes just so
you can sell the OS into particular government bids, not because they're
all that helpful.
Something else occurs to me: if it's agreed that ACLs aren't all that
great, and we're just putting them in to satisfy a few squeaky wheels,
is it worth trying to reinvent the, um, wheel? I'm not saying to go
with mediocrity, but rather that I doubt we could create enough inertia
in the Linux community to force any serious apps to conform to Our New
Way. Let's save the Hype Machine for situations where it can do some
real good.
To put it another way, Linux often succeeds because it's a unifying
force, not a divisive one: it's easy to port to, it fits Unixheads'
mental models of how a system should work, etc.
> Definitely, especially since (as I noted before) a prototype in this
> case is somewhat non-trivial. I suppose the prototype could probably
> get away with just the ext2 and vfs implementations plus a couple tools
> that do the ioctls or whatever; patching cp and tar could wait. Would
> that be enough for people to use to intelligently evaluate whether they
> like the approach?
Actually, cp shouldn't need to be patched: it'll try to access a file it
doesn't have access to, and the kernel will slap its hands. tar is
another matter, but you're right, it could wait.
My point isn't to pick nits in your examples, but to point out that, for
a large class of programs, you don't need to change the program for ACLs
to affect it. It's only programs that directly manipulate and display
permissions that would need to be changed. Even chmod could remain
unchanged: it simply messes with a different _subset_ of a file's
security attributes than get/setacl.
> What have the commercial Unices done? I am only passingly familiar
> with ACL's on Solaris and AIX. Did they each roll their own, or is
> there a standard/de facto standard they followed?
I know SCO UnixWare has a system call called acl(2) that implements all
the functionality.
There are other calls, like aclipc(2) to do similar things on IPC
channels and aclsort(3) to sort the entries in an acl structure to make
acl(2) happy. In addition, there are user-land programs called getacl
and setacl, which I suppose use acl(2) internally. (They're not
installed on the local UnixWare box, so I can't ldd them.)
I suspect that Solaris shares this same mechanism, because ACLs appeared
in SysVR4.2 according to the Unix FAQ, so that's probably the same
mechanism as the one I described above. (UnixWare is pure SysVR4.2 --
it's the lineal descendant of the AT&T code.)
I don't know if AIX's mechanism works the same way, but it's interesting
to note that IBM and SCO are working to merge AIX and UnixWare in an
effort called Monterey. If they currently have different APIs,
obviously only one API will win: maybe someone should find out whose.
If someone is interested in making Linux work like UW in this respect,
you can get a semi-free copy of the OS from SCO by going to
http://www.sco.com/offers/ If you don't know anyone with the media,
it'll cost you $70 (includes more manuals and CDs for the price than Red
Hat does for your $80, but fewer bumper stickers ;->) The license
itself is free.
You might also be interested in the UnixWare versus Linux comparison
papers I have at the URL in the signature. They're fairly well-balanced
and detailed descriptions of what the philosophical and technical
differences are between the OSes. Believe it or not, Linux doesn't come
out on top in all areas.
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: select() and FD_SETSIZE
Date: Tue, 31 Aug 1999 22:57:10 -0600
Christian Schlange wrote:
>
> I've one question concerning the select()-function on linux-systems :
>
> Is the number of file-descriptors you can use with the select-function
> limited. And if so, can one adjust the maximum value via the
> FD_SETSIZE-define ??
A casual browse of the system's header files indicates that you need to
use __FD_SETSIZE instead. But yes, you can increase the size of this
block to fairly huge values (at least 3000, perhaps as high as 4000).
For larger values (eek!), you need poll().
(The reason you can't use FD_SETSIZE is that FD_SETSIZE is blindly set
to __FD_SETSIZE even if FD_SETSIZE is already set by the time
sys/select.h is included. (In glibc 2.1.1 at least.) This is probably
a bug -- complain to the glibc people.)
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: linux driver examples from rubini
Date: Tue, 31 Aug 1999 22:46:56 -0600
[EMAIL PROTECTED] wrote:
>
> Has someone been able to make rubini's examples
> work on 2.2.+
>
> Is there an archive where I can get a copy of such?
Tried the website? http://www.oreilly.com/catalog/linuxdrive/
See both the Examples and the Errata sub-pages.
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 03 Sep 1999 07:39:34 +0100
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Theodore Y. Ts'o <[EMAIL PROTECTED]>]
> Ted T'so
I'm sure this indicates something.
Maybe just `Ted's name is hard for the plebs to spell unless we have a
pronunciation guide' ;)
Oh well, compared to one poor sot (not reading this) who referred to
`that Ted Stow person' in email to me, this is a minor error ;)
(OK, I admit it, I spell Ted's name wrong ~50% of the time too).
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Oxford
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: LispOS?
Date: 03 Sep 1999 00:44:47 +0100
[EMAIL PROTECTED] (Peter Samuelson) writes:
> So ... can Emacs run as a proper `init'? As I see
Not yet, no :(
> it, init must do two things (not counting silly things like starting
> getty): (a) wait for adopted children, and (b) respond to ctrl-alt-del.
It has somewhat special sematics wrt signals as well.
Shouldn't be too hard to add it though. I'll work up some patches for
xemacs, I think, just as a gimmick ;)
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Oxford
breed of `conference American'.
------------------------------
From: "Alan Smeltzer" <[EMAIL PROTECTED]>
Subject: Can I install Linux on an IBM PS/2 model 95 XP 486?
Date: Fri, 3 Sep 1999 14:18:42 -0400
I have an IBM PS/2 model 95 XP 486. This thing uses an IBM SCSI controller
that isn't on the list of drivers included with my copy of Red Hat Linux
5.2. Does anyone know if there is a driver for this controller out there
anywhere?
Second: I am only trying to load Linux on this for testing purposes. If the
PS/2 and microchannel devices are just not supported (or are a real pain),
then I can probably scrape together a clone. If I happen to get the driver,
should I continue or is this a waste of time?
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.setup,comp.os.linux.development.apps
Subject: Re: Help Compiling GCC 2.95.1 (Please!! )
Date: Sat, 04 Sep 1999 11:02:53 GMT
[EMAIL PROTECTED] (John McDonald, Jr.)
wrote:
[snip]
>Now, I changedir to /u7/installs/gcc-2.95.1/, and the binaries are in
>/bin, and the libs are in /lib, and everything seems alright, except
>there are NO INCLUDE files in /include. The g++ include files are in
>/include/g++, but there are no other headers in this distribution.
>This seems a bit puzzling to me, and my stuff tends to fail when I'm
>unable to include the necessary files... Hmm..
gcc will use whatever c library you have installed. It will
use the headers from that library installation. If you
want to install a c library then glibc is one possible choice.
Norman
------------------------------
From: David Powell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.help
Subject: Re: need help on ptrace
Date: Sat, 04 Sep 1999 08:03:44 -0400
Reply-To: [EMAIL PROTECTED]
That was in Virginie's original program. I'm a happy perror user,
thanks.
Mario Klebsch wrote:
>
> David Powell <[EMAIL PROTECTED]> writes:
>
> >You need to convert the cmd line arg from a string to an int (or pid_t):
>
> > sscanf(argv[1], "%d", &pid);
> > printf ("pid of the process to trace: %d\n", pid);
> > if ( ptrace(PTRACE_ATTACH, pid, 0, 0) == -1) {
> > switch (errno) {
> > case EIO: ...
> > case EPERM: ...
> > case ESRCH: ...
>
> Perhaps you should take a look at perror() and strerror(). It seems,
> these function can save you a lot of work. :-)
>
> 73, Mario
> --
> Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: nightstalker <[EMAIL PROTECTED]>
Subject: Re: problems with put_user
Date: Sat, 04 Sep 1999 13:26:16 GMT
Mark McDougall wrote:
> Have you #included <asm/uaccess.h> rather than <asm/segment.h> ???
>
>
yes, i did.
i just copied the example for writing character devices from the linux
kernel module programming guide.
ns.
------------------------------
From: [EMAIL PROTECTED] (John Forkosh)
Subject: Re: [Linux] Calling C from Fortran: Function always returns zero?
Date: 4 Sep 1999 09:35:04 -0400
John H. Chauvin ([EMAIL PROTECTED]) wrote:
: I have written a very simple fortran program which calls a
: function which is written in C.
: The program passes the number four to the C function where
: it is multiple by two and the resultant value is returned to
: the fortran program. Unfortunately, the return value as
: printed from the fortran routine is always zero.
: Fortran Program (number.f)
: -------------------
: program Main
: integer result,number
: number = 4
: write(6,'(''number(F)='',I1)') number
: result = testit(number)
: write(6,'(''result(F)='',I1)') result
: stop
: end
: C Function (testit.c)
: -------------------
: #include "stdio.h"
: int testit_(number)
: int *number;
: {
: int result;
: result = *number * 2;
: printf("number(C)=%d\nresult(C)=%d\n",*number,result);
: return result;
: }
: Run Result
: -------------------
: number(F)=4
: number(C)=4
: result(C)=8
: result(F)=0
Not sure. You seem to correctly realize that Fortran
passes addresses, and you accommodate that properly
in C function. But you're using a Fortran function here
rather than a Fortran subroutine. So, first, I'll bet
it works okay if you write void testit_(int *number, int *result),
and call testit(number,result) from Fortran.
If that works, then I might try writing
int *testit_(int *number), and passing back the address of
result.
Don't forget to declare static int result in C, for both
tests; otherwise its scope will disappear upon return.
Please followup when done...I'm curious to know what
(if anything) works.
John ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Magnus Larsson)
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: Sat, 04 Sep 1999 13:44:22 GMT
On Fri, 3 Sep 1999 08:27:52 -0500, Dave Weis <[EMAIL PROTECTED]>
wrote:
>
>>
>> >I wanna start an organized Linux development on the RS/6000. Anyone
>> >interested?
>>
>> I know nothing about the development side of things, but I may soon have some
>> older MCA RS/6000s (both PowerPC and Power2?) that I can donate to someone
>> serious about coding.
>
>I had started doing a little bit with it on a 7011-250 but my company got
>rid of the machine. If you have one like that or another PowerPC machine
>(not POWER2) let me know and we'll talk.
>
Like I said, I have two 355:s
//Magnus
------------------------------
From: [EMAIL PROTECTED] (Sami Tikka)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Question: Child Process I/O
Date: Wed, 1 Sep 1999 00:54:57 +0300
Reply-To: [EMAIL PROTECTED]
On Tue, 31 Aug 1999 08:49:10 -0500, Herng-Jeng Jou <[EMAIL PROTECTED]> wrote:
>So, I need to know when the child is idle (waiting for
>further input) and to get all the output before further input. The problem is I
>do not know how to collect all output not pass the buffer .... if I use fgets()
>in a loop, it eventually stays there waiting for more output from child while
>the child is waiting for input ... I had to quit it by Ctrl-C. I think I need to
>learn more about the terminal device I/O programming and also take a look
>of the code you sent.
That's a tough one. So you cannot give any input to the progra until you
have all the output? Cool. So how do you know when you have all the output?
Unix (or Linux) cannot tell you that. You have to be able to determine it
from the output itself.
First of all, forget about using the stdio library calls like gets to
communicate with the child process. The internal buffering is bound to
create some ill effects that are difficult to trace. Use plain systemcalls
like read() and write().
One problem is this: you call
read(fd, buffer, 1024);
What if your program only sends, say 50 bytes and then pauses to wait for
input? I don't remember how is it with pipes... does a blocking read on a
pipe return immediately with whatever is available or does it block waiting
for the rest of the 974 bytes to arrive?
Anyway, if you do not want to become blocked in read waiting for output from
your child, set the file descriptor in non-blocking mode (fcntl(fd, F_SETFL,
O_NONBLOCK)). This way you'll get just the data that is available *right
now*. The return value from read() will tell you how many bytes you got.
Do the same for the file descriptor you use to feed data to the input of
your child.
Then use select() to wait for the file descriptors to become readable or
writable.
But *you* are the one who must decide by analysing the output of the child
when to stop reading and when to begin writing. You see, if your read()
returns, say 50 bytes, you cannot know if the program is just pausing for a
millisecond, which caused your read to return with just 50 bytes or is the
50 bytes all you're going to get.
Things are much easier when you don't have to have a conversation with the
child process. Then you can just use select() and whenever the child's
output is readable, read, and whenever input is writable, write.
--
Sami Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
------------------------------
From: [EMAIL PROTECTED] (John H. Chauvin)
Subject: [Linux] Calling C from Fortran: Function always returns zero?
Date: 4 Sep 1999 12:54:41 GMT
I have written a very simple fortran program which calls a
function which is written in C. This is a very straight
forward test case for mixed Fortran and C programming
under Linux using g77 and gcc.
The program passes the number four to the C function where
it is multiple by two and the resultant value is returned to
the fortran program. Unfortunately, the return value as
printed from the fortran routine is always zero. Why is
the return value being lost?
Any hints as to why this is happening?
Thanks,
John Chauvin
Fortran Program (number.f)
===================
program Main
integer result,number
number = 4
write(6,'(''number(F)='',I1)') number
result = testit(number)
write(6,'(''result(F)='',I1)') result
stop
end
C Function (testit.c)
===================
#include "stdio.h"
int testit_(number)
int *number;
{
int result;
result = *number * 2;
printf("number(C)=%d\nresult(C)=%d\n",*number,result);
return result;
}
Compile and run Procedure
===================
gcc -c testit.c
g77 number.f testit.o -o number
../number
Run Result
===================
number(F)=4
number(C)=4
result(C)=8
result(F)=0
--
John H. Chauvin [EMAIL PROTECTED]
Netcom - Online Communication Services San Jose, CA
------------------------------
** 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
******************************
