Linux-Development-Sys Digest #67, Volume #7 Wed, 18 Aug 99 15:13:54 EDT
Contents:
vbeutils and VESA framebuffer ("overflow")
Re: why does root need supplementary groups? (Doug DeJulio)
Re: IDE Hard Disk Interrupts (Carsten Prinz)
Re: threads ("Ted Pavlic")
Re: KDE for Redhat 6.0 - problems installing ([EMAIL PROTECTED])
IDE Hard Disk Interrupts ("Nothinman")
Re: Why so inefficient source RPM's ?? (Johan Kullstam)
Re: naive newbie wants to call add_timer() ([EMAIL PROTECTED])
Re: threads ("Bill Burris")
Calling a BIOS interrupt (Gregory Hayrapetian)
Re: Setting LD_LIBRARY_PATH from makefile (Paul Kimoto)
Re: kmalloc() (Kaz Kylheku)
Re: threads (Kaz Kylheku)
GUI apps core dumping on printf's (Dimi Shahbaz)
Adding a non-standard Parallel Port ("Norm Dresner")
Kernel selection guide (Peter Hanely)
RedHat 5.1 / 5.2 / 6.0 (babu krishnamurthy)
----------------------------------------------------------------------------
From: "overflow" <[EMAIL PROTECTED]>
Subject: vbeutils and VESA framebuffer
Date: Wed, 18 Aug 1999 12:54:54 +0200
The VESA framebuffer can't change the video mode in a running kernel
(i.e, it can only be done at boot time). So fbset, the utility used for
setting up the framebuffer in other configurations, doesn't work on the VESA
framebuffer.
VBEUTILS is a package with a few utilities thought to supply the fbset
support. They are very simple, but they work. If you are interested on it,
you can find it at:
http://www.eurielec.etsit.upm.es/~overflow/
Jaime Medrano
[EMAIL PROTECTED]
http://www.eurielec.etsit.upm.es/~overflow/
------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Subject: Re: why does root need supplementary groups?
Date: 18 Aug 1999 09:32:47 -0400
In article <waru3.612$[EMAIL PROTECTED]>,
Phil Howard <[EMAIL PROTECTED]> wrote:
>Why does root need supplementary groups? Redhat and other
>distributions, and even other Unix systems, put root in the
>supplementary list for various groups in /etc/group. What's
>the point in doing that? Doesn't root have almighty power?
There are various contexts in which root does not have almighty power.
Consider a program that starts running as root, and then uses a system
call to change its UID away from root (or give up some of it's divine
power some other way). It then does *not* have ultimate power, and
the groups matter.
Also, on NFS servers, root usually gets mapped to "nobody" on remote
filesystems. Again, groups matter.
Also, consider network file clustering systems like "AFS" (and
probably the AFS-descended "CODA", though I'm not certain). Again,
groups matter.
Also, consider software that uses groups in an advisory manner. "Hey,
I notice you're not in group such-and-such, are you sure you want to
do that?" In that case, ultimate power is irrelevant, as it's purely
advisory. So, groups matter.
I hope this helped,
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
From: Carsten Prinz <[EMAIL PROTECTED]>
Subject: Re: IDE Hard Disk Interrupts
Date: Wed, 18 Aug 1999 17:15:46 +0200
Nothinman wrote:
<snip>
> This is the message that gets printed to the syslog:
> <snip>
> Aug 14 22:44:34 localhost kernel: hdc: lost interrupt
> Aug 14 22:45:16 localhost last message repeated 2 times
> Aug 14 22:46:52 localhost last message repeated 2 times
> Aug 14 22:49:17 localhost last message repeated 3 times
<snip>
try to disable dma access for ide in the kernel configuration.
i had similar problems with a cdrom at ide1, and that fixed it for me
-- carsten
=================================================================
Carsten Prinz [EMAIL PROTECTED]
public pgp key: http://www.uni-mainz.de/~cprinz/key_pgp.asc
pgp fingerprint: E2 CA ED 1A 82 34 6C 01 0E A6 33 BB F2 C6 F4 D0
=================================================================
------------------------------
From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Wed, 18 Aug 1999 10:27:16 -0400
I agree that that particular program should be broken up into separate
processes -- perhaps even separate programs.
But I don't think there's about any tool for all occassions. Forking should
never be eliminated by threading, but certain applications could make a good
use of threading that currently fork... And, as you have shown, people can
most definitely take threading too far.
Christopher Browne <[EMAIL PROTECTED]> wrote in message news:jonu3.10936
...
>
> One package I'm involved with, GnuCash, is having stability problems
> that result from there being a whole pile of code in the same process
> space.
> - There's GUI.
> - There's "database engine."
> - There's a Lisp interpreter.
> - They interact.
> Sometimes, they apparently interfere.
>
> One of the better ideas would be to get things *out* into separate
> processes. Perhaps even not on the same box.
>
> Based on the experiences that I've seen thus far with threads, they
> add complexity, tighten interfaces that often should be loosened, and
> appear valuable as a tuning tool rather than as a
> "tool-for-all-occasions."
> --
> We are MICROS~1. You will be assimilated. Resistance is futile.
> (Attributed to B.G., Gill Bates)
> [EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking,redhat.servers.general
Subject: Re: KDE for Redhat 6.0 - problems installing
Date: Wed, 18 Aug 1999 14:48:52 GMT
I have all those files on the CD for 6.0
problem is, I chose to upgrade this great desktop that my wife is very
familiar with now when I upgraded the system.
Now, kde doesn't work.
I can't install the old version cuz it won't install on 6.0 (old meaning
1.1.1). I can't install the new version (being 1.1.1pre2) cuz it says
that kde is already installed.
So, what to do now?
I tried a forced install with rpm, didn't work.
I did delete the old /opt/kde dir. too, didn't work. (what's with
installing the 1.1.1pre2 in /usr/ where it says it wants to go?!). :-)
Thanks.
CMR
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Nothinman" <[EMAIL PROTECTED]>
Subject: IDE Hard Disk Interrupts
Date: Wed, 18 Aug 1999 13:00:33 GMT
I know this might not be the right group to post this to, but I have not
recieved an answer yet.
I have a problem with an ide drive I was hoping someone could point me
in the right direction on. First off this is a scsi/ide system with an
AHA-1542( I know I should get a 2940 atleast,but I'm cheap =) and the
"buggy" CMD640 ide interface. All the drives on ide0 are fine, one 4G
Quantum drive and a CD-RW, but the drive on ide1 loses it's interrupt
alot.
I discovered it while copying a file from hda1 to hdc1 and it was going
very slowly, then it started printing "hdc: lost interrupt" regularly,
although it appeared to still be copying the file. I copied a file from
sdb5 to hdc1 and it lost it's interrupt then too, just took quite a bit
longer.
Anyone have any idea what causes this and how I can work around it? It's
only affect seems to be speed so far, the file did not get corrupted or
anything.
This is the message that gets printed to the syslog:
<snip>
Aug 14 22:44:34 localhost kernel: hdc: lost interrupt
Aug 14 22:45:16 localhost last message repeated 2 times
Aug 14 22:46:52 localhost last message repeated 2 times
Aug 14 22:49:17 localhost last message repeated 3 times
<snip>
If you reply to this, could you please cc: [EMAIL PROTECTED] as I don't get
to check this newsgroup very often.
Thanks for any help at all
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
Date: 18 Aug 1999 09:53:14 -0400
[EMAIL PROTECTED] (Suchandra Thapa) writes:
> Peter Mutsaers <[EMAIL PROTECTED]> wrote:
> >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?
>
> If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> should get the tar.gz'ed source in the /usr/src/redhat/SOURCE directory
> and the spec in /usr/src/redhat/SPEC directory.
this presupposes that you already have the old source rpm. if you do
not, you have to 1) download the new source 2) download the old
src-rpm. note that step 2) contains the old sources which are 1)
superceded by the new source and hence superflous and 2) often large.
> Just download the patch
> and place it in the SOURCE directory and add the proper lines to the spec
> files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> spec file and a corresponding %patch[n] -your_options_to_patch before the
> %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> rpm should appear in /usr/src/redhat/RPM hierarchy and the source rpm in
> /usr/src/redhat/SRPMS.
sometimes hacking the spec file is a lot of trouble. i spent a few
hours hacking the egcs-1.1.2 rpm-spec file to make it do gcc-2.95.
really, it'd be very nice to have no-source rpms with just the spec
file and patches.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: naive newbie wants to call add_timer()
Date: Wed, 18 Aug 1999 15:16:35 GMT
Ok, thanks. I guess I'll go try and learn about modules.
Also, is there no service available to a "hosted program" that offers
periodic timer/callback (as opposed to sleep()) ?
Thanks,
John
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kaz Kylheku) wrote:
> On Tue, 17 Aug 1999 20:08:58 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> >I'm trying to get some rudimentary understanding of calling a system
> >function.
> >
> >// itimetest.c
> >#include <linux/timer.h>
> >int main()
>
> What are you trying to do? The main function is for starting hosted
programs.
> Kernel code doesn't use main(). A loadable module is expected to
implement
> the init_module and cleanup_module functions.
>
> >{
> > timer_list tl; // (todo: initialize tl properly!)
> > add_timer( &tl);
> >
> >}
> >
> >[jclonts@deathstar cpp]$ g++ itimetest.c
> >/tmp/ccNO5zm3.o: In function `main':
> >/tmp/ccNO5zm3.o(.text+0xb): undefined reference to
> >`add_timer(timer_list *)'
>
> Use gcc, not g++! The code is C (with non-conforming C++ comments) not
C++.
> If you use g++, then even files with a .c suffix get treated as C++.
>
> The fact that the linker is complaining about ``add_timer(timer_list
*)''
> is a big cluestick that the code was compiled as c++. There is type
> information in the object file! You wouldn't be able to tell from a C
compiled
> object file that add_timer has a ``timer_list *'' parameter.
> In other words, the compiler generated a mangled name with type info
> encoded.
>
> Secondly, the add_timer function is not in any library. It is in the
> kernel. The references to kernel symbols are resolved when you insert
> the module into the kernel. A module must be built as an object with
> unresolved symbols (.o file). For example:
>
> gcc -D__KERNEL__ mydriver.c -c
>
> Then if all goes well,
>
> insmod ./mydriver.o
>
> Even if you succeed in doing this, you won't be able to resolve the
> add_timer reference if you compile the thing as C++, unless you
> wrap the kernel headers in extern "C" { /*... */ }.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Bill Burris" <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Wed, 18 Aug 1999 09:42:08 -0600
M van Oosterhout <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Processes on Linux are *very* cheap. A process context switch on Linux
> takes less time than a thread context switch on NT.
>
I don't know how this works on Linux, but on Windows, switching threads
requires the CPU registers to be saved and reloaded. A process switch
requires the memory management unit to be reconfigured as well. As far as
my understanding of the hardware goes, Linux must be similar. Even if
process context switches are cheap, they can't be as cheap as thread context
switches, unless Threads are poorly implemented.
This points out another weakness in Windows. Of the 4G address space for
each process the upper 2G is shared by all applications. An easy way to use
shared libraries, and inter-process communications, but a way for bugs in
one process to affect another.
Looks like time for me to brush up on my Linux knowledge, it must be over 10
years since I read Bach. When I was using Linux 3-4 years ago I spent all
my time trying to get some decent graphics out of XForms, and didn't have
time to think about system level stuff.
Bill
--
http://www.icrossroads.com/~spider
------------------------------
From: Gregory Hayrapetian <[EMAIL PROTECTED]>
Subject: Calling a BIOS interrupt
Date: Wed, 18 Aug 1999 18:23:41 +0200
Can I call a BIOS interrupt, like int 0x10 or something, in Linux?
I heard that Linux saves informations of the BIOS at boottime.
Is this true or not?
-- Greg
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Setting LD_LIBRARY_PATH from makefile
Date: 18 Aug 1999 13:58:36 -0500
Reply-To: [EMAIL PROTECTED]
[Followups reset. This is not a (c.o.l.d.)system issue.]
In article <[EMAIL PROTECTED]>, W. Tucker wrote:
> When I execute these commands from the
> command line, everything works fine. But when I include them inside
> a makefile, the LD_LIBRARY_PATH does not get set properly. The exact
> command I am using inside the makefile is:
>
> LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ; export LD_LIBRARY_PATH
At what stage do you want LD_LIBRARY_PATH to have an effect?
Each makefile rule is executed in a separate shell, and environment
variables are not propagated back from child to parent processes.
If your makefile causes some command like the above to be run,
that rule has no effect on subsequent rules.
Maybe you should change the command where LD_LIBRARY_PATH should
have an effect to
env LD_LIBRARY_PATH=$LD_LIBRARY_PATH my_command and its_arguments
where $LD_LIBRARY_PATH is set appropriately.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kmalloc()
Date: Wed, 18 Aug 1999 18:10:56 GMT
On Wed, 18 Aug 1999 08:05:11 +0100, Quiney, Philip (EXCHANGE:HAL02:HM10)
<[EMAIL PROTECTED]> wrote:
>GFP_ATOMIC: the allocation is allowed to use every bit of free memory so
>the system can have less than 'min_free_pages' of memory and the call
>will succeed rather than sleeping until memory is available.
More importantly, the the allocation can be done in an interrupt context, in
which sleeping is prohibited. So, e.g., a network driver's interrupt service
routine can use this to get memory for a received packet. If there is no memory
available immediately in the reserve, the call will fail rather than block.
It's important to have a sound strategy for dealing with failures from
a GFP_ATOMIC allocation because such failures can happen transiently,
and do not necessarily indicate a catastrophic failure.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: threads
Date: Wed, 18 Aug 1999 18:13:47 GMT
On Wed, 18 Aug 1999 09:42:08 -0600, Bill Burris <[EMAIL PROTECTED]> wrote:
>This points out another weakness in Windows. Of the 4G address space for
>each process the upper 2G is shared by all applications. An easy way to use
>shared libraries, and inter-process communications, but a way for bugs in
>one process to affect another.
Some upper memory is also shared in Linux. but it's a protected kernel space.
It's only accessible to a process that has trapped into the kernel via an
exception, interrupt or system call.
------------------------------
From: Dimi Shahbaz <[EMAIL PROTECTED]>
Crossposted-To: comp.windows.x.kde,linux.dev.c-programming,comp.os.linux.x
Subject: GUI apps core dumping on printf's
Date: Wed, 18 Aug 1999 11:29:12 -0700
Hello,
When developing GUI apps (using KDE &qt) I like to put printf's and
cout's in the code for debugging purposes. This use to work fine, and I
saw the printf's in the app's parent terminal. Now, however, the GUI
program core dumps if it printf's more than 1 newline to the parent
terminal. Ie, if I printf("debug message\n something else\n"); I see
the "debug message" printed ok, but the second line doesn't show up,
and the program seg faults. The program also seg faults when I don't run
it from a terminal but instead run it (by clicking on it) from a file
manager in X.
I have determined that 2 newlines is the problem because if I run the
same program like such: `./program &> out` the program runs fine (ie,
no seg fault).
I don't have a clue what this could be, it is very strange. The machine
in question is a pentium, with kde 1.1.1, and qt1.44. I don't think
I have changed anything from when it worked to now. Any ideas? Has
anyone run into this problem before?
Thank in advance
Dimi
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Adding a non-standard Parallel Port
Date: 18 Aug 1999 16:54:42 GMT
I need to add to a Linux box a parallel port that has been hacked-up to be
at a non-standard address. Where in the kernel source code do I go to add
this address to the list of possible parallel ports?
Thanks
Norm
------------------------------
Date: Wed, 18 Aug 1999 09:45:04 -0700
From: Peter Hanely <[EMAIL PROTECTED]>
Subject: Kernel selection guide
Has anyone compiled a kernel selection guide? Specifically
a listing of which kernel versions have which features/bugs.
I ask because having "upgraded" from 2.0.29(rock solid) to
2.0.34(apparent memory leak, managed by disabling swap).
I'd return to 2.0.29, but would like to use devices not supported
until 2.0.34.
--
Peter Hanely =/\=
[EMAIL PROTECTED] (email has been "jammed")
http://www.jps.net/mhanely
computer software etc. in Sac. Ca
Take a look at my shareware offerings.
------------------------------
From: [EMAIL PROTECTED] (babu krishnamurthy)
Subject: RedHat 5.1 / 5.2 / 6.0
Date: Tue, 17 Aug 1999 18:58:22 -0800
Hi,
I am new to Linux. Please help me
with the following queries:
1. what is the kernel version in
RedHat 5.1 / 5.2 / 6.0 ?
2. what is the extent of SMP support
in these kernel versions ?
3. how much does it affect the Network
Device Driver Development ?
4. where can I find the details of these
internals ?
5. could you suggest the best possible
books / resources for Network Device
Driver development
Thank you in advance.
- Babu -
-**** Posted from RemarQ, http://www.remarq.com/?b ****-
Real Discussions for Real People
------------------------------
** 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
******************************
