Linux-Development-Sys Digest #362, Volume #6 Mon, 1 Feb 99 18:14:15 EST
Contents:
Re: GNUPro for Linux - Recommendations (Frank Sweetser)
Re: Ignorant Socalists (was disheartened gnome developer) (Marco Anglesio)
porting rh4.2 to rh5.1 (Phongsak Prasithsangaree)
Re: Writing driver, need advice (herman)
Re: help!!! On reinstalling Red Hat ("Jürgen Exner")
Re: Ignorant Socalists (was disheartened gnome developer) (jedi)
Re: Writing driver, need advice (Matt Kressel)
Rewriting IDLE Process - Need Strategic Advice - part 1 (Carl Spalletta)
Re: Rewriting IDLE Process - Need Strategic Advice - part 1 (George MacDonald)
Re: Ignorant Socalists (was disheartened gnome developer) (John Hasler)
Re: Modest next goal for Linux (Raymond Lillard)
Re: How to flush the file cache ? (Pasha Zusmanovich)
----------------------------------------------------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: GNUPro for Linux - Recommendations
Date: 01 Feb 1999 11:48:36 -0500
Dan McLaughlin <[EMAIL PROTECTED]> writes:
> >Any recommendations for GNUPro for Linux? At $79, it seemed like a
> >good deal, but wonder if anyone's used it.
> Its pretty nice. It uses more quite a bit more memory than vanilla
> gdb. I had to go from 64 to 190 debugging my 19 MB executable, but the
> ease of use over plain gdb makes it worth it. Put the cursor over a
> variable and a floating yellow postit type dialog tells you its value.
> That plus the data view (each object on the stack is viewed in a tree
> menu that you can expand to see the whole thing) alone is worth it.
> The "compile" environment doesn't seem any different from the usual
> egcs installation - I don't know if why they bothered.
out of curiosity, is there anything that it offers that DDD doesn't?
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0 i586 | at public servers
There ain't nothin' in this world that's worth being a snot over.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Marco Anglesio)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Ignorant Socalists (was disheartened gnome developer)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 01 Feb 1999 19:57:19 GMT
On Mon, 1 Feb 1999 18:22:19 GMT, John Hasler <[EMAIL PROTECTED]> wrote:
>The Microsoft monopoly is not the result of competition in the free market.
>It is the result of government action to prevent competition and limit the
>free market: copyright.
But Microsoft is not an arm of the state; in fact, the state and Microsoft
have been before the courts almost continuously for the last ten years.
>Thus Microsoft is more socialistic than Linux. Linux is downright
>anarchistic. And that's just fine.
Anarchy as an economic philosophy? :) Nope, MS is at pretty much the apex
of capitalism - an organization that defies the state's authority (and
hence the legitimacy of the state's control) to pursue its goals more
effectively. Linux would be pretty much the nadir of classical capitalism
- spontaneous evolution, gratis *and* external to the direction of the
state, of a product.
Of course, this isn't socialist, either, although it's probably closer to
socialist than it is to capitalist. A failure of nomenclature.
marco
--
Marco Anglesio The press isn't cynical enough. They're the only Americans
[EMAIL PROTECTED] capable of this kind of embarrassing, greenhorn
http://www.the-wire.com/~mpa civic wonder anymore. (James Poniewozik)
------------------------------
From: Phongsak Prasithsangaree <[EMAIL PROTECTED]>
Subject: porting rh4.2 to rh5.1
Date: Mon, 01 Feb 1999 13:51:50 -0600
Hi all,
We are developing a program and successfully compiled under RH4.2. Now
we are trying to compile this program under RH5.1.
We have got a lot of problem such as missing include files, g++ and gcc
library conflict.
Can anyone tell us how to compile this program under RH5.1?
Thank you.
==========================
Phongsak
------------------------------
From: herman <[EMAIL PROTECTED]>
Subject: Re: Writing driver, need advice
Date: 01 Feb 1999 12:03:48 PST
Matt,
Thanks for the great suggestions. I forgot to put the data rate, its arount
150KB/sec. This skews the collection scheme to the point where there will
always be data available. This is why the VxD did both FIFO input and disk
file output at the driver level. Do you think the proposed scheme will
handle that kind of data rate in Linux? My concern is if the whole process
can sustain that type of throughput. I guess that was the question behind my
original question.
The DAQ board suggestion is good, I will look that up.
I also have the Rubini book. It is a great course in how to write a driver.
Thanks for your advice.
Herman
Matt Kressel wrote:
> herman wrote:
> >
>
> What rate of data collection would be going on here? I would suggest
> making a block device node, say /dev/mydriver or something. Have your
> user level app read from this device using a simple read call on the
> device file. In the kernel, have an interrupt write to a circular
> buffer. You will need to make this buffer large enough so that overflow
> is not possible. The user process reading from the device file should
> be run as root, and you can change its priority with the system call
> "setpriority" (via a libc function call) to the highest. The read from
> the device file will block when there is no data, and a data chunk will
> be read when there is. From user land, you can just read /dev/mydriver
> forever in a tight loop, writing the data to a file.
>
> So the program flow goes something like this (K means Kernel, U means
> User app)
>
> K) Register block device file node and malloc circular memory buffer
>
> K) Register interrupt for device
>
> U) Read from /dev/mydriver in loop (waits for data)
>
> K) Have user app U) sleep on interrupt (i.e. suspended until there is
> data)
>
> K) Interrupt! Write to circular buffer, wake up sleeping process U)
>
> U) Wakes up! Gets data from kernel space (via read), copies to file
>
> K) The read from kernel space triggers adjustment of circular buffer
> (i.e. move pointer)
>
> U) Loops and waits for more data
>
> K) etc.
>
> Note that there is a lot of kernel <--> user space copying going on
> here. Kernel 2.2.x is supposedly better at this type of thing so you
> may want to consider that. Copying data in multiples of the system's
> page size (4Kb on x86) will speed things up too. You may also want to
> look at some source for DAQ boards because they are doing simliar things
> like taking data in real time from a board and dumping to a file. I
> would also suggest that you keep the output file open until you are done
> writing so that it would be faster.
>
> A great book for this sort of thing is "Linux Device Drivers" by
> Allesandro Rubini (sp?). It covers kernel 2.0.x, but some 2.2.x stuff
> is in there.
>
> Hope this helps,
> -Matt
>
> --
> Matthew O. Kressel | INTERNET: [EMAIL PROTECTED]
> +--------- Northrop Grumman Corporation, Bethpage, NY ---------+
> +--------- TEL: (516) 346-9101 FAX: (516) 346-9740 ------------+
------------------------------
From: "Jürgen Exner" <[EMAIL PROTECTED]>
Subject: Re: help!!! On reinstalling Red Hat
Date: Mon, 1 Feb 1999 09:57:57 -0800
Scott MacDonald wrote in message <[EMAIL PROTECTED]>...
>Hi, I have a linux box someone gave me with red hat 5.1. He says he doesn't
>remember the password(yeah right,) so I need to reinstall(I have a red hat
>cd). Well, can someone tell me the best way to reformat the hardrive and
>reinstall linux clean? I have the cd, but no boot floppy disk. When I try
to
>boot to Win98 floppy disk, it doesn't even see it, and lilo does its thing.
>Can I copy fdisk from redhat cd to a floppy and use it if I can get the box
>to boot to floppy before it goes to the hardrive? Any help would be greatly
>appreciated because I can' t get pass this login prompt! thanks!
There is absolutely no need to reinstall.
Please see the Linux FAQ, question 6.11: "I have screwed up my system and
can't login to fix it" for instructions on how to reset the root password.
jue
--
Jürgen Exner; microsoft.com, UID: jurgenex
Sorry for this anti-spam inconvenience
------------------------------
From: [EMAIL PROTECTED] (jedi)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Ignorant Socalists (was disheartened gnome developer)
Date: Mon, 1 Feb 1999 12:24:55 -0800
On Mon, 01 Feb 1999 19:57:19 GMT, Marco Anglesio <[EMAIL PROTECTED]> wrote:
>On Mon, 1 Feb 1999 18:22:19 GMT, John Hasler <[EMAIL PROTECTED]> wrote:
>>The Microsoft monopoly is not the result of competition in the free market.
>>It is the result of government action to prevent competition and limit the
>>free market: copyright.
>
>But Microsoft is not an arm of the state; in fact, the state and Microsoft
>have been before the courts almost continuously for the last ten years.
>
>>Thus Microsoft is more socialistic than Linux. Linux is downright
>>anarchistic. And that's just fine.
>
>Anarchy as an economic philosophy? :) Nope, MS is at pretty much the apex
>of capitalism - an organization that defies the state's authority (and
...at which point consumers no longer drive merchants but
rather merchants dictate to consumers. PC OEM's are a great
example of this sort of thing.
While corporations don't contitute governments yet they
certainly can exert similar influence in their domains
of dominance.
>hence the legitimacy of the state's control) to pursue its goals more
>effectively. Linux would be pretty much the nadir of classical capitalism
>- spontaneous evolution, gratis *and* external to the direction of the
>state, of a product.
>
>Of course, this isn't socialist, either, although it's probably closer to
>socialist than it is to capitalist. A failure of nomenclature.
All I can gather as a consumer is that my choices are shrinking.
That rather more resembles any description of command economies
than it does capitalism. Linux & FreeBSD have worked against that
market dwindling. It rather matters less who the commands are
comming from (if they're not coming from consumers) but that they
are coming from some entity.
--
Herding Humans ~ Herding Cats
Neither will do a thing unless they really want to, or |||
is coerced to the point where it will scratch your eyes out / | \
as soon as your grip slips.
In search of sane PPP docs? Try http://penguin.lvcm.com
------------------------------
From: Matt Kressel <[EMAIL PROTECTED]>
Subject: Re: Writing driver, need advice
Date: Mon, 1 Feb 1999 18:40:26 GMT
herman wrote:
>
> Hi,
>
> I'm trying to write a driver for a high data flow device that interfaces
> through PCI. The device has a FIFO which when full needs to be emptied
> and dumped to disk file for continuous recording.
>
> I have been slugging at VxD code given as a reference example, but the
> world of exe, dll, and vxd is hazy. What I make out is the example code
> actually handles the FIFO and disk transfers at the driver level. The
> Vireo development kit was used to write the VxD. All the data
> collection runs in the interrupt loop with flags set at the user level
> to inform status and progress. The disk file is opened and written to
> through use of Vireo low level routines at the driver level.
>
> The architecture of Linux is different and I need some advice as how to
> structure the rewrite of this driver. My guess is that the file i/o has
> to be done at the user level, with the FIFO service at the driver
> (kernel) level. The FIFO routines will be invoked by the "FIFO full"
> interrupt. I then would put the data in a user buffer and the disk i/o
> will be done by the data collection application (user level).
>
> Is this the correct approach? What about execution priorities for the
> collection application to make sure all the data makes it to the disk
> file without overflow?
What rate of data collection would be going on here? I would suggest
making a block device node, say /dev/mydriver or something. Have your
user level app read from this device using a simple read call on the
device file. In the kernel, have an interrupt write to a circular
buffer. You will need to make this buffer large enough so that overflow
is not possible. The user process reading from the device file should
be run as root, and you can change its priority with the system call
"setpriority" (via a libc function call) to the highest. The read from
the device file will block when there is no data, and a data chunk will
be read when there is. From user land, you can just read /dev/mydriver
forever in a tight loop, writing the data to a file.
So the program flow goes something like this (K means Kernel, U means
User app)
K) Register block device file node and malloc circular memory buffer
K) Register interrupt for device
U) Read from /dev/mydriver in loop (waits for data)
K) Have user app U) sleep on interrupt (i.e. suspended until there is
data)
K) Interrupt! Write to circular buffer, wake up sleeping process U)
U) Wakes up! Gets data from kernel space (via read), copies to file
K) The read from kernel space triggers adjustment of circular buffer
(i.e. move pointer)
U) Loops and waits for more data
K) etc.
Note that there is a lot of kernel <--> user space copying going on
here. Kernel 2.2.x is supposedly better at this type of thing so you
may want to consider that. Copying data in multiples of the system's
page size (4Kb on x86) will speed things up too. You may also want to
look at some source for DAQ boards because they are doing simliar things
like taking data in real time from a board and dumping to a file. I
would also suggest that you keep the output file open until you are done
writing so that it would be faster.
A great book for this sort of thing is "Linux Device Drivers" by
Allesandro Rubini (sp?). It covers kernel 2.0.x, but some 2.2.x stuff
is in there.
Hope this helps,
-Matt
--
Matthew O. Kressel | INTERNET: [EMAIL PROTECTED]
+--------- Northrop Grumman Corporation, Bethpage, NY ---------+
+--------- TEL: (516) 346-9101 FAX: (516) 346-9740 ------------+
------------------------------
From: [EMAIL PROTECTED] (Carl Spalletta)
Subject: Rewriting IDLE Process - Need Strategic Advice - part 1
Date: Mon, 01 Feb 1999 22:10:13 GMT
I thought it would be a nice touch to rewrite the idle process to do
some useful work.
The new Idle process would do an incremental partial defrag
possibly followed up by a "shredding" of discarded files.
By an incremental defrag, I mean one that is highly interruptible
and may be performed on an ext2 filesys mounted r/w.
By a partial defrag, I mean one that does not consist of putting all
files in block sequence and each file contiguous on the disk, but
something that significantly reduces seek times notwithstanding.
By shredding, I mean writing garbage into all unallocated blocks, so
deleted data would be unrecoverable. I have heard that Big Brother has
the means to recover even data written over with all ones or zeros or
any other predictable sequence.
I have done a lot of analysis of this and it appears to be feasible
but before getting into it, there's something I have to know.
Question #1 - Am I attempting to reinvent the wheel here, or what??
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Subject: Re: Rewriting IDLE Process - Need Strategic Advice - part 1
Date: Mon, 01 Feb 1999 22:42:26 GMT
Carl Spalletta wrote:
>
> I thought it would be a nice touch to rewrite the idle process to do
> some useful work.
>
> The new Idle process would do an incremental partial defrag
> possibly followed up by a "shredding" of discarded files.
>
> By an incremental defrag, I mean one that is highly interruptible
> and may be performed on an ext2 filesys mounted r/w.
>
> By a partial defrag, I mean one that does not consist of putting all
> files in block sequence and each file contiguous on the disk, but
> something that significantly reduces seek times notwithstanding.
>
> By shredding, I mean writing garbage into all unallocated blocks, so
> deleted data would be unrecoverable. I have heard that Big Brother has
> the means to recover even data written over with all ones or zeros or
> any other predictable sequence.
>
Apparently one can take a drive apart and examine the disk for layers
of writes. Each time a write occurs it is never "exactly" on the same
spot so there are shadows of previous writes left in the magnetic
material. - "Ghosts of writes past". So the success of your shredding
is limited to the persistence of the person trying to get at the data.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Ignorant Socalists (was disheartened gnome developer)
Date: Mon, 1 Feb 1999 18:22:19 GMT
mp writes:
> It's only a "fact" in your perfervid imagination. I gather from your
> conversation that you are a Windows user because it is a product of "the
> most effective, powerful and largest economy the world has ever seen",
> and that you abhor linux because it is the miserable, impoverished and
> dirty product of "Socialism."
The Microsoft monopoly is not the result of competition in the free market.
It is the result of government action to prevent competition and limit the
free market: copyright.
Linux is the result of individuals cooperating and competing on the Net, a
market so free that they are not limited to trading only for money.
Thus Microsoft is more socialistic than Linux. Linux is downright
anarchistic. And that's just fine.
--
John Hasler This posting is in the public domain.
[EMAIL PROTECTED] Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
------------------------------
From: Raymond Lillard <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Date: Mon, 01 Feb 1999 09:13:00 -0800
John De Hoog wrote:
>
> Edwin van der Elst <[EMAIL PROTECTED]> wrote...
> >Point your mouse at the desktop (background)
> >and keep the left mouse button down.
> >CPU goes to 100%
>
> I tried what you suggested (on NT 4), but the CPU usage barely moved off of
> its 2% line. Maybe you're thinking of the Mac?
I just tried this no NT4-SP3 and yes, my CPU usage immediately
shot to 100%. How do you explain this?
Ray
------------------------------
From: Pasha Zusmanovich <[EMAIL PROTECTED]>
Subject: Re: How to flush the file cache ?
Date: Mon, 01 Feb 1999 23:55:27 +0200
Isn't dd if=/dev/hda(or whatever) of=/dev/null count=(lot of... say the
size of the whole memory) more simple?
Stefaan A Eeckels wrote:
>
> In article <[EMAIL PROTECTED]>,
> Renaud Lottiaux <[EMAIL PROTECTED]> writes:
> > Jeff McWilliams wrote:
> >>
> >> Try issueing the sync command. that's what I do right before I want to
> >> unmount a zip disk and right after I've just copied a bunch of files to
> >> it. It forces the system to complete all pending writes... at least
> >> that's how it works for me. See the man page for sync
> >
> > Sorry, my question was not correctly formulated...
> > I don't want to write back to disk durty data but
> > to clean out the file cache. When using the "sync"
> > command, pending writes are completed, but data
> > stay in cache.
> >
> > I would like to REMOVE all data from the cache
> > to be sure that next read will be performed
> > from the disk and not from the cache.
> That's easy - you know that Linux switches dynamically
> between process space and file cache, but gives
> precedence to program space, hence it's enough
> to write a program that consumes a lot of memory,
> say through a "malloc()":
>
> #include <linux/kernel.h>
> #include <linux/sys.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> #define MB 1048576
>
> int
> main (int argc, char *argv[])
> {
> struct sysinfo info;
> long sz;
> char *bigbuf;
>
> sysinfo(&info);
>
> /* Grab all there is but not too much to swap */
> sz = info.freeram + info.bufferram;
> printf("BEFORE: Available: %3.3lf Mbytes; in buffers: %3.3lf Mbytes\n",
> (double)info.freeram/MB, (double)info.bufferram/MB);
>
> /* Alloc lots of memory */
> if (bigbuf = malloc(sz))
> {
> /* Touch it */
> memset(bigbuf, 'Z', sz);
> }
> else
> {
> fprintf(stderr, "Cannot malloc %ld\n", sz);
> exit(1);
> }
> free(bigbuf);
> printf("AFTER : Available: %3.3lf Mbytes; in buffers: %3.3lf Mbytes\n",
> (double)info.freeram/MB, (double)info.bufferram/MB);
> return 0;
> }
>
> This little program should get rid of most of the files in the
> cache.
>
> Take care,
>
> --
> Stefaan
> --
>
> PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
> ___________________________________________________________________
> Perfection is reached, not when there is no longer anything to add,
> but when there is no longer anything to take away. -- Saint-Exupéry
--
Pasha Zusmanovich -------o x x "What i tell you three times is true."
[EMAIL PROTECTED] o o x L.Carroll, "The Hunting of the Snark"
www.actcom.co.il/~pasha x x o---------------------------------------
------------------------------
** 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
******************************
