Linux-Development-Sys Digest #60, Volume #7 Tue, 17 Aug 99 02:13:53 EDT
Contents:
Re: mmap() still causing problems (Grant Edwards)
Re: Linux assembly, etc (Alexander Viro)
Re: why not C++? ("Frank V. Castellucci")
Re: why not C++? (Randall Parker)
Re: OT: OO OSs (Re: Troll (was: why not C++?)) (M van Oosterhout)
Re: why not C++? (Randall Parker)
Re: mmap() still causing problems (Kaz Kylheku)
Re: [Q] Parallel port access program permission (Kaz Kylheku)
[Q] Parallel port access program permission (YANAGIHARA)
Re: [Q] Parallel port access program permission (Kaz Kylheku)
Segmentation fault causes extreme badness? (Tim Roberts)
Help with Glibc 2.0 Installation! (Kenny Zhu Qili)
Why so inefficient source RPM's ?? (Peter Mutsaers)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: mmap() still causing problems
Date: Tue, 17 Aug 1999 02:02:21 GMT
In article <[EMAIL PROTECTED]>, Grant Edwards wrote:
>So, I switched to the method used by the sound driver to let
>the user mmap its DMA buffer. At module initialization I grab
>a page and mark it reserved, allow the user to mmap it, then
>unreserve it and free it when the module is unloaded.
Hmm, that seems to be working now. I must have had a different bug
that was causing instability, but I don't know what it was (everything
seems fine now). That worries me.
--
Grant Edwards grante Yow! World War Three can
at be averted by adherence
visi.com to a strictly enforced
dress code!
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Linux assembly, etc
Date: 16 Aug 1999 20:20:55 -0400
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> wrote:
>[Newsgroups trimmed]
>[EMAIL PROTECTED] (Alexander Viro) writes:
>
>> UNIX assumes two protection levels.
>> Which is all that x86 gives, BTW - 4 rings are there only if you are working
>> with segments.
>
>? Reading the 386 Programmer's Reference Manual I can't see this.
Check the stuff regarding permissions on page level.
>ISTM that there are always rings 0-3... it is true that most of this is
>tied up with selectors, but one-selector-per-shared-lib could
>work. (That said, that isn't done in Linux, is it?)
It wouldn't. First of all, you would have to switch descriptors all the time.
*Very* slow on x86. Then you would have to play interesting tricks with
aliasing. Also not fun.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 20:50:43 -0400
Christopher B. Browne wrote in message ...
>On Mon, 16 Aug 1999 07:47:33 -0400, Frank V. Castellucci <[EMAIL PROTECTED]>
>posted:
>>But this can be managed by the Factory pattern. In addition, in a OS
>>context, the factory would
>>be the desired route for instrumentation and management.
>
>Ah, yes. The famed "patterns."
Patterns are not unique, or new. They have existed since life began. Famed?
I think not. Recognizable? You have answered that already.
>>But the right analysis and design will allow predict invarient state.
>
>In other words, if you move to C++, additional analysis and design work
>is necessary to hope that it will work.
Bzzzz! Wrong. I am of the strong point of view that ALL software development
should have a plan that includes the invarient state of (put your favorite
term here) all of the objects that participate during processing. Whether it
be assembler or Logo, if you as the architect do not know what state your
systems or sub-systems are in during use cases you will certainly have a
buggier product.
>GCC has represented a stable C compiler for many years now, and may
>be considered mature.
>
>G++ has not represented a stable C++ compiler for a terribly long time.
>There is no question of it being "mature" yet.
>
>The OS can only be as stable as the compiler is mature.
Yes, and I have seen the comments in the kernel code defering to bugs in the
compiler. We all have written "work-arounds" to overcome a weakness we may
find in our choice of compilers.
>With the C++ language standard only having stabilized in the last year, it
>hardly makes sense to criticize Linux for eschewing the use of a language
>whose definition has been in flux throughout the bulk of its lifetime.
No one is making any derogatory statements in this thread.
>To my mind, the appropriate thing to do is to
> Leave Well Enough Alone.
>
>Linux functions well enough as implemented in C.
>
>Breaking that by moving to C++, and thereby having a significant period of
>time during which Linux would *definitely* not be stable, would be a
>Very Dumb Idea.
Without any basis of how it would be a Very Dumb Idea, I won't agree with
you on these statements. I will take a moment to comment that THERE IS
CHANGE in this world. One measure of the flexibility of a system is how well
it can continue to work in the face of change. How well can it adapt to the
requirements needed to keep it usefull. I have run into these walls with
systems in many languages (including C++).
>If you want to have an OS written in C++, then it makes sense to start
>designing a C++-based OS kernel.
I think that was the original authors starting point.
Frank V. Castellucci
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 19:43:39 -0700
Kaz,
I liked all your points. The hte points about the vtable remind me of
another one:
Suppose you have 3 methods in your pure virtual base class: aa(), bb(),
cc(). Then you start inheriting off it in all sorts of ways that have
various levels of inheritance hierarchy. For the purpose of notation
suppose that each inherited version of aa is numbered: aa1, aa2, aa3, and
so on. Ditto for bb (bb1, bb2, etc) and cc.
Well, you could see a class that implemented
aa1, bb1, cc1,
Then another class that inherited from that class and just overrode bb
again to make it:
aa1, bb2, cc1.
But then another class that inherited from the previous and added a new
cc:
aa1, bb2, cc2
Now here is where we see how C++ comes up short. We want to make a new
class that has
aa1, bb1, cc2.
Well, guess what? There is no way to make this new class after making
those 4 other previous classes without repeating the body of either bb1
or bb2 or cc1 or cc2.
The problem is that when each implementation of aa or bb or cc is defined
it is defined for a particular class. You then run into situations where
you have to repeat an implementation of a particular method in order to
get it in various combinations with the other implementations of other
methods in the inheritance hierarchy.
I've run into this problem more than once in C++ work. So we had to do
things like make functions and instantiate classes with constructors that
got passed lists of pointers to functions. Then you had a class that had
aa, bb, cc and each of them then called a function via a pointer that was
an object variable.
One really would like to be able to define a bunch of versions of aa, of
bb, and of cc. Then be able to instantiate objects that implemented
various combinations of those methods and have a vtable get built at time
of instantiation. That is what I most wanted.
Short of that I'd like to be able to define various classes where instead
of going:
MyDerivedClass::MyMethodAA(arg types)
{
the body of the method
}
One could preferably go:
MyPureBaseClass::MyMethodAA(arg types);
Then go
MyPureBaseClass::MyMethodAA(arg types) MyMethodAA1
{
the body of the method with AA1 style implementation
}
MyPureBaseClass::MyMethodAA(arg types) MyMethodAA2
{
a different body of the method with AA2 style implementation
}
Then be able to inherit MyFirstDefinedClass off of MyPureBaseClass to
define MyFirstDerivedClass. And then go:
MyFirstDerivedClass::MyMethodAA == MyMethodAA2
to indicate which variant of MyMethodAA should have its address stuffed
in the vtable for MyFirstDerivedClass.
But C++ can't do anything like this. Its incredibly static straitjacket
for vtable is a shame.
I think that class level variable scope control is a great idea. C needs
better ways to control the name space. C also needs all sorts of neat
little language extensions that came along in C++ that had nothing to do
with OO. Also, C++ templates (though a compiler writer's nightmare) are a
lot more flexible and powerful than #define macros. But I just find C++'s
way of constructing vtables to be far too limited.
(this message has gone on too long so I won't tell you other things I
find bad about C++)
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Here is trivial example of C++ inflexibility. In C++, your concrete object has
> to implement all pure virtual methods inherited from an interface base class.
> Otherwise, invocations of that method cause a run time error (call to pure
> virtual function). In many places in the Linux, virtual methods that are not
> implemented are represented by a null pointer. The code that wants to call
> the method tests for null and bypasses. Don't want to implement poll() in your
> driver? No problem, just set it null. You can't do this in C++ code without
> compiler-specific tricks that are undefined at the language level. The
> compiler-generated virtual tables are sacred and untouchable things that are
> invisible to the programmer. The usual escape hatch is to implement the
> function, but have it return some ``I am not really implemented'' status. That
> is much more expensive since an actual dispatch has to take place.
------------------------------
Date: Tue, 17 Aug 1999 12:58:03 +1000
From: M van Oosterhout <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: OT: OO OSs (Re: Troll (was: why not C++?))
Joshua D. Boyd wrote:
> but I've never seen stuff like corba do the things that I do with ActiveX).
>Hopefully
Have you looked at GNOME?
It is a whole desktop environment based completely on CORBA. The
most impressive thing I've seen to date is embedding a complete
full-colour vector graphics image of a lion into a speadsheet.
I intend to look at this more in the future, but concepts
behind it are amazing.
Martijn van Oosterhout
Australia
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 19:56:20 -0700
I think the real problem with C++ and heap memory is that too many
programmers who use C++ do not understand how much all the stuff they are
writing is fragmenting the heap.
Watching various (in many cases dangerous) programmers using C++ it has
been my experience that new seems to be more natural to them (ie they are
less likely to hesitate before using it) than is malloc. So they just use
it mad.
Also, I've seen a lot of people writing a bunch of classes where they end
up constructing a smaller object, then passing it to the constructor of a
larger one to be copied into it, and then repeating that about 5 times as
they built up bigger and bigger objects.
They don't see that they are copying data like mad. All that is hidden in
constructors. They also seem to think that doing a new on a class has no
more overhead than declaring a variable on the stack.
I think it takes far greater discipline to write good C++ than good C
even though in theory the syntax of C++ ought to encourage the users to
think more about the design and partitioning of a problem. In practice
they don't know how to partition things into objects, they thrash and
fragment the heap, and they consume way more memory and do much more
copying around of data.
And they do all this seemingly oblivious to what they are doing.
The worst I ever saw of this was when I was able to trace a piece of data
coming in on a serial device and then getting copied a dozen times into a
dozen successively instantitated objects as it got passed back up a call
tree and then got passed between two processes before finally being
formatted for display. Oh, and at each level the new object was bigger
than the object before it. The data did get scaled along the way but
maybe 2 or 3 copies were necessary. Then everyone wondered why the code
was so slow.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> There are also huge disadvantages.
> C++ programs need a library for some of their more advanced language
> constructs, such as new- and delete-operators, and exception handling.
> Note that kernel memory cannot be swapped out; in a user program,
> relying on a big shared library from which not everything is used is
> no problem, but in the kernel, it is.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: mmap() still causing problems
Date: Tue, 17 Aug 1999 03:21:57 GMT
On Tue, 17 Aug 1999 02:02:21 GMT, Grant Edwards <[EMAIL PROTECTED]> wrote:
>Hmm, that seems to be working now. I must have had a different bug
>that was causing instability, but I don't know what it was (everything
>seems fine now). That worries me.
Put up your code on an FTP or web site somewhere, allowing other people
to look at it.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: [Q] Parallel port access program permission
Date: Tue, 17 Aug 1999 04:03:46 GMT
On Tue, 17 Aug 1999 12:32:15 +0900, YANAGIHARA <[EMAIL PROTECTED]> wrote:
>Hello, everybody.
>Please tell me about Parallel port access.
>
>I made parallel port access program. When ueser is root, I
>can successfully read and write binary to parallel port.
>But when ueser is not root, ``Segmentation Fault'' occur at
>inb/outb function. Tell me how to change this program's
>permission ? Or, do I have to do another action ?
You change the ownership to the root user and enable the setuid bit which will
cause it to execute with root permissions.
Because you are cross-posting, I won't tell you how that's done. Read
the chmod man page.
------------------------------
From: YANAGIHARA <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: [Q] Parallel port access program permission
Date: Tue, 17 Aug 1999 12:32:15 +0900
Hello, everybody.
Please tell me about Parallel port access.
I made parallel port access program. When ueser is root, I
can successfully read and write binary to parallel port.
But when ueser is not root, ``Segmentation Fault'' occur at
inb/outb function. Tell me how to change this program's
permission ? Or, do I have to do another action ?
-- My program's abstract is following...
1) include header file ``asm.h''
2) get 3 ports permission from base address of available
parallel port by permio().
3) read by inb(), or write by outb().
(root is local Linux machine's root, and other users are
NIS account which are administered by Solaris NIS server.)
--
Thank you for reading.
Yanagihara
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: [Q] Parallel port access program permission
Date: Tue, 17 Aug 1999 04:05:01 GMT
On Tue, 17 Aug 1999 12:32:15 +0900, YANAGIHARA <[EMAIL PROTECTED]> wrote:
>Hello, everybody.
>Please tell me about Parallel port access.
>
>I made parallel port access program. When ueser is root, I
>can successfully read and write binary to parallel port.
>But when ueser is not root, ``Segmentation Fault'' occur at
>inb/outb function. Tell me how to change this program's
>permission ? Or, do I have to do another action ?
>
>-- My program's abstract is following...
>1) include header file ``asm.h''
>2) get 3 ports permission from base address of available
>parallel port by permio().
>3) read by inb(), or write by outb().
>(root is local Linux machine's root, and other users are
>NIS account which are administered by Solaris NIS server.)
>
>--
>Thank you for reading.
>Yanagihara
------------------------------
From: [EMAIL PROTECTED] (Tim Roberts)
Subject: Segmentation fault causes extreme badness?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 17 Aug 1999 03:32:23 GMT
I'm porting to Linux a hardware debugger we first created for a DOS Extender
-based system with DPMI. Overall, the conversion has gone quite well; I can
manipulate PCI space, tweak I/O ports, map and manipulate physical memory and
so forth.
However, I have had one nagging issue which has caused me great annoyance.
Whenever I get a segmentation fault, I expect it to take a core dump and
terminate. That's not what happens. Instead, the process appears to hang; it
is unresponsive to keystrokes. If I pop to another virtual terminal, killing
the process has no effect. "ps" shows it in status "D", which is an
uninterruptable I/O sleep state. The file "core" is created, but is zero
length.
If I run the exact same series of operations with the program in gdb, gdb
correctly traps the segmentation fault. It's only when the program is run
standalone that I have trouble. This has happened in several different cases
of segmentation faults.
The reason this is particularly annoying is that because the process is
apparently trying to manipulate the "core" file, the system is unable to
cleanly unmount the root file system at shutdown time, thus causing me to
suffer through an fsck on the next reboot.
Are segmentation faults handled differently in suid root processes? My next
adventure will be to add a SIGSEGV handler myself, although I'm not quite sure
what my recovery strategy could be...
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Kenny Zhu Qili <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Help with Glibc 2.0 Installation!
Date: 17 Aug 1999 04:59:00 GMT
Hi there. I was installing glibc 2.06 when I had the following error:
spinlock.h: In function `acquire':
In file included from manager.c:32:
spinlock.h:20: warning: implicit declaration of function `__sched_yield'
manager.c: In function `pthread_start_thread':
manager.c:162: warning: implicit declaration of function
`__sched_setscheduler'
manager.c: In function `pthread_handle_create':
manager.c:229: warning: implicit declaration of function
`__sched_getscheduler'
manager.c:230: warning: implicit declaration of function
`__sched_getparam'
manager.c:241: warning: implicit declaration of function `__clone'
manager.c:242: `CLONE_VM' undeclared (first use in this function)
manager.c:242: (Each undeclared identifier is reported only once
manager.c:242: for each function it appears in.)
manager.c:242: `CLONE_FS' undeclared (first use in this function)
manager.c:242: `CLONE_FILES' undeclared (first use in this function)
manager.c:242: `CLONE_SIGHAND' undeclared (first use in this function)
make[2]: *** [/tmp/glibc-2.0.6/compile/linuxthreads/manager.o] Error 1
make[2]: Leaving directory `/tmp/glibc-2.0.6/linuxthreads'
make[1]: *** [linuxthreads/others] Error 2
make[1]: Leaving directory `/tmp/glibc-2.0.6'
make: *** [all] Error 2
Looks like my pthread lib has some problem. But I have already installed
linuxpthread 0.3.71 and I have used it without problem. Plus I have
included linuxthreads add-on with the compilation. Could someone tell me
what went wrong? Thanks.
Kenny
------------------------------
From: Peter Mutsaers <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Why so inefficient source RPM's ??
Date: 16 Aug 1999 23:32:20 +0200
Coming from FreeBSD, I'm used to the ports system. It is a bit like a
source RPM: you have an original tarball, patches, build instructions
and a file list. This is handled automatically, then packaged and
installed.
But, when someone does a minor adjustment to the port, you don't have
to download again the whole (sometimes very large) original source,
only the update patch or build instructions, usually very small and
thus it is very easy and efficient to stay current (even more so
because of the excellent cvs/cvsup system).
With source RPM's, it seems you have to re-download the whole thing
(sometimes huge RPM's such as gcc) for every minor tweak.
Am I missing something? Is there a place where Redhat (or contrib)
source RPM's are located in unpacked form so that I can update without
downloading the whole original source over and over again?
TIA,
--
Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know
[EMAIL PROTECTED] | the Netherlands | what I'm doing.
------------------------------
** 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
******************************
