Linux-Development-Sys Digest #722, Volume #6 Tue, 18 May 99 12:14:12 EDT
Contents:
Re: Registry in Linux ??? (Christopher Browne)
Help for MMX ([EMAIL PROTECTED])
Changes in signals (kernel > 2.2.1) ? (Jason Neudorf)
Re: WipeOut IDE crashes - help? (William J. Hayes)
Re: 2.2.8 - Evil behavior (bryan)
2.3.x -- development goals anybody? (Mike Dowling)
compiling berkely via project, solution (Maciej Golebiewski)
Re: find device major/minor numbers via C program?? (Andreas Schwab)
Filesize larger than 2 GB on Intel machines an Linux 2.0.36 ("Axel H�lzer")
Re: Changes in signals (kernel > 2.2.1) ? (Andreas Schwab)
Re: 2.3.x -- development goals anybody? (Brett Neely)
Re: A Real Puzzler, (try your hand) ([EMAIL PROTECTED])
Re: Hostile Takeover of Linux (Phil Howard)
RipTide Modem/Audio (Andrew Bland)
transname patch? (Marko Meyer)
Re: Accurate profiling with Pentium TSC (David Konerding)
Re: Changes in signals (kernel > 2.2.1) ? (Paul D. Smith)
Re: find device major/minor numbers via C program?? (Dave Weis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.misc
Subject: Re: Registry in Linux ???
Reply-To: [EMAIL PROTECTED]
Date: Tue, 18 May 1999 03:40:22 GMT
On Sat, 15 May 1999 16:22:33 +0200, Thomas Scholz <[EMAIL PROTECTED]> wrote:
>These packet managers are exactely what I ment with being just put on top of
>the os. As you said these managers (or comparable sw) don't recognize the
>stuff you put on the system, let's say manually, nor the stuff other apps
>might put on the system. So the data these managers are maintaining is
>"corrupt", not complete. The concept is wrong.
>
>Solution would be a database (integrated into the os, no user manipulation)
>that recognizes everything(!!!) that goes in and out of the system. This
>would provide system integrity.
Unfortunately, such a scheme establishes a new facility whose
robustness cannot exceed (assuming the use of the Bayes principle) the
multiple of:
a) How reliable the process of managing the creation of DB entries is,
b) How reliable the DB manager is,
c) How reliable the filesystem on which the DB is stored is.
Thus, if there's a problem with one of these things, the total
reliability suffers. And if there are significant problems with more
than one of these, reliability suffers *dramatically.*
Furthermore, this merely addresses "low level" reliability, which is
where the Windows Registry *first* falls down. It doesn't address
problems of "usefulness," which layers on further issues:
d) How reliably we may ensure that configuration changes are correctly
identified as such,
e) How useful the "metadata" is that seeks to provide the user with
*useful* information about the configuration change,
f) Whether or not there is a reliable transaction management system so
that if a configuration change is not successfully completed, both the
actual system changes *and the logging thereof* may be rolled back.
Note that f) crosses a line in that it fits as much with the "low level"
reliability side of the equation as it does with "usability."
>Ok, question is, if something like this is desirable.
The big problem is that "in the beginning," when the code base isn't
mature, the little problems in each area multiply to make it worse than
useless.
It's not much good unless you can leap from "no pervasive registry" to
an "extremely reliable pervasive registry." And it's not viable to
expect that to happen. Software doesn't start out perfect; it has to be
debugged.
All that being said, it would be *plausible* for something *moderately*
pervasive to grow into place, supposing we were able to combine:
a) A set of libraries supporting configuration management at the
application level, with an inclusion of some metadata so that a
"higher level" application is able to identify what application the
config data is for.
The extra metadata means that [for instance] a generic
"configuration manager" can scan files and identify what application
the config is for, and perhaps even meaningfully manipulate the
data.
b) Generic "config management" software that can read config files,
making reference to the libraries, and providing a multiplexed way
of reading, if not *all* configuration information, at least a
"whole whopping lot of it."
This does *not* represent a comprehensive mechanism that enforces that
*all* changes to files get "managed" as to their impact on system
configuration; I would argue that *that* represents an intractable
problem.
By encouraging apps to use some well-coded libraries that provide robust
mechanisms for managing the data, we may not get universal coverage of
all config, but this gives a way of moving towards getting better
control of *most* of it, which is a Good Thing.
Upshot of this is that people should *consider* using libPropList, or
libCFG, or opStore to manage configuration.
--
"Lumping configuration data, security data, kernel tuning parameters,
etc. into one monstrous fragile binary data structure is really dumb."
- David F. Skoll
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED]
Subject: Help for MMX
Date: Tue, 18 May 1999 05:20:06 GMT
Hi,
Anyone could tell where I can find MMX instructions set that GCC
recognizes? Or is there any other compilers on linux that can process
MMX instructions?
Thanks very very much!!!
Edward Yu
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Jason Neudorf)
Subject: Changes in signals (kernel > 2.2.1) ?
Date: 18 May 1999 01:42:12 -0400
Somewhere between 2.2.1 and 2.2.6 signals change (2.2.5 maybe? I
read the patch diff summaries). Since the "2.2" series is release, I
assume changes are bad, but perhaps I've been taking advantage of
a quirk that shouldn't be used.
I've been doing some work with a Tk widget using the meteor driver.
The meteor driver can be told to send a signal at every new frame.
I used this signal to update an X window.
The problem occurs after a tcl "exec". Under 2.2.1, signals are not
disrupted. Under 2.2.6, signals are no longer sent after the tcl "exec".
I define the sigaction struct using:
static const struct sigaction sigact = (struct sigaction) {
gotframe, ((sigset_t) {{}}), SA_RESTART, NULL };
where "gotframe" is the function I'm calling, and tell the kernel about it
using:
sigaction(SIGUSR2, &sigact, NULL);
Perhaps there's a problem with the way I define the sigaction struct?
Or perhaps there's a kernel bug?
Please advise me if you find anything.
------------------------------
From: [EMAIL PROTECTED] (William J. Hayes)
Subject: Re: WipeOut IDE crashes - help?
Date: Tue, 18 May 1999 03:55:30 GMT
Signal 11 is often caused by RAM that is not up to speed. Try
underclocking your CPU or fiddling with your BIOS settings.
user ([EMAIL PROTECTED]) wrote:
: I have just downloaded and installed WipeOut (glibc ver) on my newly
: installed RedHat 6.0. I used the default method of insallation for
: WipeOut. There is lots of free memory and harddrive space. JDK 1.1.7 is
: installed and working.
: When I try to run wipeout, I get this:
: rbw abort handler: signal 11 caught
: Please send a full bug report (WipeOut version, OS version, library
: versions) to [EMAIL PROTECTED] Thanks!
: Killed
: I have e-mailed softwarebuero, but not heard back yet (granted, I only
: e-mailed them last night). I am in a hurry for this because my class
: assignments are due almost immediately. Can anyone advise? Please reply
: to newsgroup.
: Thanks for any help!
: Luke
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: 2.2.8 - Evil behavior
Date: Tue, 18 May 1999 07:28:09 GMT
bill davidsen <[EMAIL PROTECTED]> wrote:
: In article <7hhull$a91$[EMAIL PROTECTED]>,
: Kevin Turnquist <[EMAIL PROTECTED]> wrote:
: | I think the former is smart strategy. What really fried me is that
: | 2.2.8 ran flawlessly on my "test" machine, which is under constant load.
: | It only blew up on my production servers...most unkind.
: This suggests that if you are upgrading you do it one at a time, or at
: least a few at a time until you have some faith in the software. Also, I
: always build a new kernel and modules and unstall them without touching
: the old version, then add a stanza to the lilo.conf and run LILO. This
: lets me boot the new kernel *by hand* and be secure that the old kernel
: will boot the next time if the machine rolls over.
# make zdisk
is your friend. use it for test kernels. if it boots, great. if
not, you didn't touch lilo so it should still work ;-)
also, good to make zdisk (from your current working system) before
making a new boot disk.
and NEVER wipe out the current boot disk with the new/test kernel.
use a new floppy. really. ;-) [can you tell that I've been there
before?]
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (Mike Dowling)
Subject: 2.3.x -- development goals anybody?
Date: 18 May 1999 09:05:49 GMT
I'm just a little cruious, that's all.
Now that the 2.3.x kernels are being developed, can anybody please describe
briefly what the development goals are? Obviously new drivers for new
hardware will be part of it, but what other major developments can we expect?
Cheers,
Mike Dowling
--
My email address [EMAIL PROTECTED] above is a valid email address.
It is, in fact, a sendmail alias; the digit 'N' is incremented regularly.
Spammed aliases will be deleted. Currently, mike[5,7-9,12,13] have been
deleted. If email to mikeN bounces, try mikeN+1.
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: compiling berkely via project, solution
Date: Tue, 18 May 1999 10:53:45 +0200
Hi everyone,
Yesterday I asked for help with compiling Berkeley VIA on Linux 2.0.x.
This problem is already solved and it was trivial and I was clueless.
Just wanted to make sure that you won't waste your time on my stupid
question.
Bye,
Maciej
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Subject: Re: find device major/minor numbers via C program??
Date: 18 May 1999 11:48:45 +0200
"Dan Miller" <[EMAIL PROTECTED]> writes:
|> I'm trying to read device major/minor numbers programmatically, by looking
|> at the listing that I get back from readdir() ... according to W.R. Stevens,
|> I can use lstat(), and parse the .st_dev and .st_rdev fields, but this does
|> not work in my Linux 2.0.36 system; all devices are returning 0305 and
|> 0000 (respectively) in these fields, for all device files. I'm printing out
|> the device names that I'm passing to lstat(), and in all cases the names
|> are correct. What am I doing wrong??
Try compiling your program with -Wall. That should give you a clue.
--
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[EMAIL PROTECTED]
------------------------------
From: "Axel H�lzer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Date: Tue, 18 May 1999 11:11:21 +0200
Hi,
is there any solution to work with files larger than 2 GB on
Intel-processor based machines? I am running RedHat Linux 5.2 with
kernel 2.0.36. I heard about patch for kernelversions 2.2.x.
Thanks in advance
A X E L
[EMAIL PROTECTED]
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Subject: Re: Changes in signals (kernel > 2.2.1) ?
Date: 18 May 1999 11:53:15 +0200
[EMAIL PROTECTED] (Jason Neudorf) writes:
|> Somewhere between 2.2.1 and 2.2.6 signals change (2.2.5 maybe? I
|> read the patch diff summaries). Since the "2.2" series is release, I
|> assume changes are bad, but perhaps I've been taking advantage of
|> a quirk that shouldn't be used.
|>
|> I've been doing some work with a Tk widget using the meteor driver.
|> The meteor driver can be told to send a signal at every new frame.
|> I used this signal to update an X window.
|>
|> The problem occurs after a tcl "exec". Under 2.2.1, signals are not
|> disrupted. Under 2.2.6, signals are no longer sent after the tcl "exec".
|>
|> I define the sigaction struct using:
|>
|> static const struct sigaction sigact = (struct sigaction) {
|> gotframe, ((sigset_t) {{}}), SA_RESTART, NULL };
You should not initialize a struct sigaction statically, or at least not
depend on a particular order of the struct members (use designated
initializers). This is not portable.
--
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[EMAIL PROTECTED]
------------------------------
From: Brett Neely <[EMAIL PROTECTED]>
Subject: Re: 2.3.x -- development goals anybody?
Date: Tue, 18 May 1999 02:27:06 -0700
LinuxHQ - http://www.linuxhq.com - has a lot of information on
stable/development kernels, official/unofficial kernel patches, and
related news.
An interesting place to watch is at http://www.linux.org.uk/diary/ -
Alan Cox's diary. He writes about the various kernel code he's working
on.
Mike Dowling wrote:
>
> I'm just a little cruious, that's all.
>
> Now that the 2.3.x kernels are being developed, can anybody please describe
> briefly what the development goals are? Obviously new drivers for new
> hardware will be part of it, but what other major developments can we expect?
>
> Cheers,
> Mike Dowling
>
> --
> My email address [EMAIL PROTECTED] above is a valid email address.
> It is, in fact, a sendmail alias; the digit 'N' is incremented regularly.
> Spammed aliases will be deleted. Currently, mike[5,7-9,12,13] have been
> deleted. If email to mikeN bounces, try mikeN+1.
--
Brett Neely, Technical Support Engineer, Linuxcare, Inc.
415.354.4878 x505 tel, 415.701.7457 fax
[EMAIL PROTECTED], http://www.linuxcare.com
Linuxcare. At the center of Linux.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.setup,comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: A Real Puzzler, (try your hand)
Date: Tue, 18 May 1999 09:41:40 GMT
> Interestingly, I tried logging in from a few other boxes on the same
> subnet at the problem box and got differing results. From one
> machine,
This time could be taken by console messages. Kernel requires
quite some amount of time for console printing.
For a 14.4k modem console messages come quite slowly. This
is due to slow ppp link plus internet overhead. From any other machine
in the same subnet, you get much higher speeds due to much higher
speed of direct ethernet connections.
Amit Kale
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: Hostile Takeover of Linux
Date: Tue, 18 May 1999 09:31:23 GMT
On 17 May 1999 22:43:09 GMT bill davidsen ([EMAIL PROTECTED]) wrote:
| I'm also interested in the procedure itself, since real world problems
| tend to be solved with manuals rather than rote learning of every option
| of every command.
And those manuals are more and more found online, too.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: Andrew Bland <[EMAIL PROTECTED]>
Subject: RipTide Modem/Audio
Date: Tue, 18 May 1999 11:31:24 +0100
Hi Everyone,
Does anyone know if the kernel will ever support this hardware? I'm a tad
upset because I've bought a new PC and I get no sound under linux, nor modem. The
modem side I can live with (I kept my external one:)) .. but the sound .. well I used
to have a SB16 and that worked fine .. but it seems this RipTide chipset by Rockwell
is very new, I can hardly find out anything about it.
Thanx
Andy
--
------------------------------
From: Marko Meyer <[EMAIL PROTECTED]>
Subject: transname patch?
Date: 18 May 1999 11:50:55 +0200
Hi,
I'm searching for the transname patch for 2.2.x kernels. It seems to
me, that nobody is maintaining it at the moment?
Further, I've heard that name translation (as previously done by the
transname patch) will be / is added to the kernel. Are there any
informations on that?
Thanks and bye,
Marko.
--
Diplominformatiker (FH) Marko Meyer
My Homepage: http://www.tu-chemnitz.de/~marme
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: Accurate profiling with Pentium TSC
Date: 17 May 1999 16:26:16 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 14 May 1999 15:51:37 GMT, Andre McCurdy <[EMAIL PROTECTED]>
wrote:
>I'm trying to optimize some code by timing its execution using the Time
>Stamp Counter on a Pentium.
>
>What seems to be happening though is that the average executon time
>changes by a few percent between runs - even without any changes to the
Run your program n times, look at the average and std. dev. of the
execution time. if the distribution of running times is normal
(assuming the differences between runs are basically random) then
you will probably see that this difference is not really significant.
Furthermore, consider that the state of your machine is not 100% identical
once you've run the machine through the test- you've primed the cache, *but*
other programs are running and touching the cache, so that your program's
execution time is affected by whether your memory references are going
to cache or main memory.
you may want to look into the Intel performance counter patches for the
linux kernel (you'll need a ppro or pII or celeron)
http://beowulf.gsfc.nasa.gov/software/perf-0.6.tar.gz
--
================================================================================
Email: [EMAIL PROTECTED] David Konerding WWW: http://picasso.ucsf.edu/~dek
================================================================================
Snail: Graduate Group in Biophysics
Medical Sciences 926, Box 0446
University of California
San Francisco, CA 94143
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Changes in signals (kernel > 2.2.1) ?
Date: 18 May 1999 11:39:50 -0400
Reply-To: [EMAIL PROTECTED]
%% Andreas Schwab <[EMAIL PROTECTED]> writes:
as> |> static const struct sigaction sigact = (struct sigaction) {
as> |> gotframe, ((sigset_t) {{}}), SA_RESTART, NULL };
as> You should not initialize a struct sigaction statically, or at
as> least not depend on a particular order of the struct members (use
as> designated initializers). This is not portable.
Not sure it's clear from Andreas' message, but designated initializers
aren't portable either; they'll work with GCC and they'll be in the next
C standard, but most C compilers don't support them yet.
Just initialize using normal assignment; it's The Right Thing To Do.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Dave Weis <[EMAIL PROTECTED]>
Subject: Re: find device major/minor numbers via C program??
Date: Tue, 18 May 1999 09:53:12 -0500
On Mon, 17 May 1999, Dan Miller wrote:
> not work in my Linux 2.0.36 system; all devices are returning 0305 and
> 0000 (respectively) in these fields, for all device files. I'm printing out
> the device names that I'm passing to lstat(), and in all cases the names
> are correct. What am I doing wrong??
I'm guessing you have linux installed on /dev/hda5 (or at least the /dev
directory). You are receiving the device that the file you stat'ed is on.
I would imagine the rdev field would contain what you want (the
major/minor of the file you are stat'ing). It's odd that it doesn't. Grab
the source for the stat(1) program. It returns this information:
[djweis@beast djweis]$ stat /dev/hda
File: "/dev/hda"
Size: 0 Filetype: Block Device
Mode: (0666/brw-rw-rw-) Uid: ( 0/ root) Gid: ( 6/
disk)
Device: 48,0 Inode: 128234 Links: 1 Device type: 3,0
my root fs ^^ major/minor for hda^^^^^
i just wrote and ran this program and got 768 with is 0x300, the
major/minor for /dev/hda.
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
void main()
{
struct stat buf;
int retval;
retval = stat("/dev/hda", &buf);
printf("retval %d rdev %d\n", retval, buf.st_rdev);
}
hope this helps
dave
--
David Weis | 10520 New York Ave, Des Moines, IA 50322
[EMAIL PROTECTED] | Voice 515-278-0133 Ext 231
When they took the Fourth Amendment, I was quiet because I didn't deal drugs.
When they took the Sixth Amendment, I was quiet because I was innocent.
When they took the Second Amendment, I was quiet because I didn't own a gun.
Now they've taken the First Amendment and I can't say anything.
------------------------------
** 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
******************************
