Linux-Development-Sys Digest #869, Volume #7 Wed, 17 May 00 18:13:18 EDT
Contents:
Re: a RPC howto for the hopeless? (J.H.M. Dassen (Ray))
Re: Need ideas for university funded project for linux (David Steuber)
Re: Windows98 IDE driver screwed up Linux UDMA disk access? (Paul D. Smith)
Linux Mutexes and Conditions & 2.3.99 (Bill Waddington)
Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
Re: Need ideas for university funded project for linux (Mongoose)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Problem with aha152x module (David Ronis)
Re: Linux Mutexes and Conditions & 2.3.99 (Kaz Kylheku)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: a RPC howto for the hopeless?
Date: Tue, 16 May 2000 22:17:06 +0200
Travis Hein <[EMAIL PROTECTED]> wrote:
>I am fairly new at linux programming, and would like to learn more about
>how to use the Remote Procedure Call facilities in sunrpc.o module.
Your best bet is to do "man -k RPC" and study the documentation listed, like
rpcgen(1) and rpc(3).
Nowadays, it may be better to look into a higher-level approach like CORBA
rather than doing RPC directly though.
HTH,
Ray
--
Ray Dassen <[EMAIL PROTECTED]>
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: David Steuber <[EMAIL PROTECTED]>
Date: Wed, 17 May 2000 19:59:59 GMT
Mongoose <[EMAIL PROTECTED]> writes:
' I am attempting to start a college project and have two of my
' ideas already being worked on. So I wanted to know what other people
' had for suggestions for linux projects? I was thinking of something
' along the lines of a project that would help promote the use of linux.
' What is something that most people could use? Something that could
' make a good 1 year R&D project?
Linux could really use a good framework for developing multimedia
applications and authoring multimedia content.
This means plugable codecs.
This means support for multimedia hardware.
--
David Steuber | Hi! My name is David Steuber, and I am
NRA Member | a hoploholic.
All bits are significant. Some bits are more significant than others.
-- Charles Babbage Orwell
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Windows98 IDE driver screwed up Linux UDMA disk access?
Date: 17 May 2000 16:27:30 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Stefaan A Eeckels) writes:
sae> That really should have removed all the effects of the new
sae> driver.
I would expect that settings such as those manipulated by hdparm would
survive a power-cycle; couldn't the Windows driver have set those as
well?
>> May 16 21:43:59 homebase kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
>> May 16 21:43:59 homebase kernel: hda: dma_intr: error=0x40 { UncorrectableError
}, LBAsect=952, sector=889
>> May 16 21:43:59 homebase kernel: end_request: I/O error, dev 03:01 (hda), sector
889
sae> Now that's an easy one: you've got a bad sector, and the machine
sae> tells you nicely which one: 889. As this sector falls in the File
sae> Allocation Table, the Linux driver disables writes to the disk,
sae> to avoid damage to the logical structure.
Hmm. I dunno. I'm pretty suspicious. First, this disk is only a year
old (I know, disks sometimes go bad, but still). Second, it seems very
coincidental that this error just happened to appear at the same time as
Windows wouldn't boot with that bad driver. Third, I don't see how this
explains why Linux hangs on boot until I turned off DMA in the BIOS,
which I never had to do before.
I guess it could be just a big coincidence...
sae> I suggested that to avoid going through booting from Windows, or
sae> using hda's MBR.
Ah. Good idea.
sae> No need to fix anything. Your problem is due to hda going bad
sae> (EIDE drives correct bad tracks automatically. When they start
sae> showing them to the OS, it means that the alternate track table
sae> is overflowing. If I were you, I'd get a new drive.
Hmm hmm. That would suck (not the new drive part so much as
transferring all the @$#%& data).
If the drive were going that bad, wouldn't I be able to see it from
Windows, too, somehow? So far as I can tell, Windows has no problems
with the disk.
I'll try dosfsck and see if I can find any disk checking tools in
Windows.
Also, as I said, I still don't see why Linux can't boot anymore until I
turn off DMA. Surely _that_ at least should be fixed somehow?
sae> There's also a bit of tuning you can do to make your system
sae> run somewhat faster:
Cool.
Thanks for all your help!
--
===============================================================================
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: Bill Waddington <[EMAIL PROTECTED]>
Subject: Linux Mutexes and Conditions & 2.3.99
Date: Wed, 17 May 2000 21:00:14 GMT
Hello,
Is anyone else using Kaz Kylheku's Linux Mutexes and Conditions stuff
with 2.3.99? (http://users.footprints.net/~kaz/lmc.html)
I have patched it for 2.3.99-pre3 as follows:
diff -Naur lmc/mutex.c newlmc/mutex.c
--- lmc/mutex.c Mon Jul 19 22:34:15 1999
+++ newlmc/mutex.c Wed May 17 13:17:11 2000
@@ -41,14 +41,15 @@
void cond_init(cond_t *cv)
{
- cv->queue = NULL;
+ init_waitqueue_head(&cv->queue);
}
int cond_wait(cond_t *cv, mutex_t *mx)
{
- struct wait_queue wait = { current, NULL };
+ wait_queue_t wait;
int ret;
+ init_waitqueue_entry(&wait, current);
add_wait_queue(&cv->queue, &wait);
current->state = TASK_INTERRUPTIBLE;
@@ -66,10 +67,11 @@
int cond_timed_wait_rel(cond_t *cv, mutex_t *mx, long jiff_delta)
{
- struct wait_queue wait = { current, NULL };
+ wait_queue_t wait;
int ret;
long remaining;
+ init_waitqueue_entry(&wait, current);
add_wait_queue(&cv->queue, &wait);
current->state = TASK_INTERRUPTIBLE;
diff -Naur lmc/mutex.h newlmc/mutex.h
--- lmc/mutex.h Mon Jul 19 22:34:15 1999
+++ newlmc/mutex.h Wed May 17 13:12:56 2000
@@ -11,7 +11,6 @@
#define MUTEX_H
#include <linux/sched.h>
-#include <asm/spinlock.h>
typedef struct {
spinlock_t spin;
@@ -19,7 +18,7 @@
} mutex_t;
typedef struct {
- struct wait_queue *queue;
+ wait_queue_head_t queue;
} cond_t;
enum { COND_WAIT_SUCCESS, COND_WAIT_SIGNAL, COND_WAIT_TIMEOUT };
This to match the new wait queue stuff and to avoid including
include/asm/spinlock.h directly (seems to be for SMP only).
The reason I ask (you were beginning to wonder...) is to ask the
thousand eyes in this NG if this looks OK. I am using it in a char
driver that uses kiobufs to do user buffer DMA, and that I want to be
able to use on SMP and UP boxes. It is running now, except that
occasionally when running two DR11s doing endless loopback self tests on
a UP (P-167), both boards return from cond_timed_wait_rel() with a
timeout - at approximately the same time. On a PIII-450 they _seem_ to
run indefinitely. The boards (and driver code) are intended to run
independently. It is as if both board's wakeups are missed - or
interrupts (or scheduling) was held up for the 10s timeout period (seems
_way_ unlikely!).
There are many things that could be wrong - all of them with the driver.
It would help to know if I am on the right track with the LMC portion
of things.
Thanks
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 21:10:43 GMT
Mongoose <[EMAIL PROTECTED]> writes:
> On Wed, 17 May 2000 15:01:04 GMT, [EMAIL PROTECTED] wrote:
> >Mongoose <[EMAIL PROTECTED]> writes:
> >The way I see it, Linux needs the following, at minimum, before it can
> >be a legitimate competitor to Windows:
> >1. A streamlined, easy install process;
> Theres distros that have that now. Caldera I think? You can play
> tetris while linux is installing on your machine.
Dunno. I've just heard very bad things about some of the installers,
namely that they either work perfectly or not at all. And, of course,
we should be able to turn off the easy-to-use installer and get our
hands dirty.
> >2. An office suite roughly as functional as Office, and at least as
> > easy to use;
> Staroffice which is basically a clone of MSoffice, and Corel Office
> Suite. Both very good office suites for linux.
I've used StarOffice (not Corel Office), and it's not roughly as
functional as Office. Also, it's not GPLed. I have hopes that
GNOME's office suite will come through (and it's very nice, though
crash-intensive, so far).
> >3. A GUI package installation mechanism that's as easy to use as
> > InstallShield (trivial if we get a file manager for GNOME or KDE); and
> Maybe, theres a few out there but no one uses them except commercial
> companies. Most programs use the standard configure; make; make
> install line
Yeah. And that's a serious problem. Do you realize how fucking
annoying it is to have to install 150MB of source, dedicate 1.5 hours
to configuring and building, and then find out that there's some God
forsaken shared library I need to install before it will work? Not
that I have gone through this several times with XEmacs on RedHat
boxes, or anything.
I want to click on a damn button and have the program install. I want
the option to do it by hand if I have to, but installing anything on
Linux is a nightmare if you have to build it from the source. Note
also that "make install" will occasionally break, depending on your
distribution. And they all seem to be going in tangential directions
on this one.
There's just no excuse for not having an adequate installer. We have
two excellent package-management tools, dpkg (and apt) and rpm. All
we have to do is put a shiny new GUI front-end on them.
Not that I am bitter.
[...]
> It seems that there are alot of linux programs out there that do
> these things people need, its just that its hard to find them all.
Yeah. Because there are 573,283 Linux packages, 572,911 of which do
exactly the same thing, and 290 of which are cutesy man pages.
We need some Machiavellian masochist to sift through all the packages
for Linux, pick the best ones, and throw out the rest. I think
anything that hasn't been changed for 5 years should go; we might have
to make an exception for e2fsck, but as a rule, it would probably
eliminate half the packages.
> As for ease of use, most linux users are intellegent computer users
> and don't need guis to configure and install stuff.
This is a lie.
I'm an intelligent computer user. I have manually, painstakingly
configured my Debian system by hand, because there are either no
usable GUIs to do it or they don't get put on my X menu (so I install
them and forget them). I hate doing it, and I have to refer back to
the man pages - which, by the way, are indecipherable even if you know
what you're doing - roughly every two seconds. And then we have the
fact that UNIX folks just love to abbreviate, and apparently consider
it a matter of personal style and creativity. I use "fn" for
"function," God help me, but I'm not so big a moron that I'd do it in
a configuration file. Most of the otherwise-intelligent people who
write the programs we use every day are guilty of that and worse
crimes, though.
I much, much, much prefer being able to right-click on something and
hit "Properties." I also like being able to press F1 when the mouse
is over a confusing field and get an explanation of it. (The
explanation often isn't a help, and I expect that would carry over to
Linux, but at least there's no flipping around between screens.)
Please excuse the rant. But Linux has been a pain in the ass to
configure since I started using it in the early 90's, and it's
improved not at all since then.
> This is the problem though, they don't care enough to create
> programs to help newbies install and use linux and so linux is being
> held back.
I care enough. I'm just no good at GUI programming.
> I don't see linux taking off any time soon either but the more help
> it gets, the more popular it will be.
I don't think we should squander this opportunity. The reason I get
so locquatious when it comes to Linux is that I really like some parts
of it, and really hate others. Same thing for Windows, but the really
funny part is that the two are, for me, almost perfectly complementary.
I see an opportunity for us to improve Linux so that it can be like it
is now, or like Windows, or like anything at all, and change between
the two with only about five minutes' effort.
It's just that there's such a huge opportunity here, and it seems like
so few people are willing to take advantage of it. Myself included,
but I, unfortunately, don't have a separate computer available to do
Linux development. (Is there a Linux for SGI boxes yet?)
There I go, ranting again. Please excuse this one too.
--
Eric P. McCoy ([EMAIL PROTECTED])
non-combatant, n. A dead Quaker.
- Ambrose Bierce, _The Devil's Dictionary_
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 21:14:27 GMT
[EMAIL PROTECTED] (eyez) writes:
> quoting <[EMAIL PROTECTED]>:
> >Mongoose <[EMAIL PROTECTED]> writes:
> >In order to beat Windows, client-side, we need:
> >1. A GUI interface to *all* configuration files;
> Ugh. that's why i LEFT windows.
I'm not saying that you should *have* to go through the GUI, just that
you can if you want to.
I concur, though, that for some applications (recovery and
auto-configs/-installs, to name two) it's a really bad idea. And it's
a trap that Windows has never managed to get out of. (It's why the
"Windows Resource Kit" includes a bunch of UNIX utilities.)
> maybe the whole world SHOULDN'T run linux. It's not a system that's
> made to be like windows.
Perhaps it wasn't made to have a GUI (and I'm not saying "Windows," I'm
saying "a GUI"), but it's certainly become a part of it over time.
--
Eric P. McCoy ([EMAIL PROTECTED])
non-combatant, n. A dead Quaker.
- Ambrose Bierce, _The Devil's Dictionary_
------------------------------
From: Mongoose <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 21:32:09 GMT
On Wed, 17 May 2000 21:10:43 GMT, [EMAIL PROTECTED] wrote:
>> >3. A GUI package installation mechanism that's as easy to use as
>> > InstallShield (trivial if we get a file manager for GNOME or KDE); and
>
>> Maybe, theres a few out there but no one uses them except commercial
>> companies. Most programs use the standard configure; make; make
>> install line
>
>Yeah. And that's a serious problem. Do you realize how fucking
>annoying it is to have to install 150MB of source, dedicate 1.5 hours
>to configuring and building, and then find out that there's some God
>forsaken shared library I need to install before it will work? Not
>that I have gone through this several times with XEmacs on RedHat
>boxes, or anything.
Well you could just download a binary that has all the libraries it
needs statically compiled into it. The problem here is that if a new
version of the library comes out your screwed because your stuck with
the library thats compiled in the binary. So if your compiled to Mesa
and a new version of Mesa comes out thats twice as fast as the
original, you could install it and upgrade your game or whatever uses
it if you dynamically link to the library.
>> It seems that there are alot of linux programs out there that do
>> these things people need, its just that its hard to find them all.
>
>Yeah. Because there are 573,283 Linux packages, 572,911 of which do
>exactly the same thing, and 290 of which are cutesy man pages.
>
>We need some Machiavellian masochist to sift through all the packages
>for Linux, pick the best ones, and throw out the rest. I think
>anything that hasn't been changed for 5 years should go; we might have
>to make an exception for e2fsck, but as a rule, it would probably
>eliminate half the packages.
Ya this is true, freshmeat needs some better organization, or a
voting system. Since everyone can make applications for free, that
leads to so much crap being made.
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 17 May 2000 16:57:07 -0500
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Mongoose <[EMAIL PROTECTED]> writes:
>> Staroffice which is basically a clone of MSoffice, and Corel Office
>> Suite. Both very good office suites for linux.
>
>I've used StarOffice (not Corel Office), and it's not roughly as
>functional as Office.
Is there something specific that you couldn't do with it?
>> >3. A GUI package installation mechanism that's as easy to use as
>> > InstallShield (trivial if we get a file manager for GNOME or KDE); and
>
>> Maybe, theres a few out there but no one uses them except commercial
>> companies. Most programs use the standard configure; make; make
>> install line
>
>Yeah. And that's a serious problem. Do you realize how fucking
>annoying it is to have to install 150MB of source, dedicate 1.5 hours
>to configuring and building, and then find out that there's some God
>forsaken shared library I need to install before it will work? Not
>that I have gone through this several times with XEmacs on RedHat
>boxes, or anything.
Odd, I've got an xemacs from the default install...
>I want to click on a damn button and have the program install. I want
>the option to do it by hand if I have to, but installing anything on
>Linux is a nightmare if you have to build it from the source. Note
>also that "make install" will occasionally break, depending on your
>distribution. And they all seem to be going in tangential directions
>on this one.
Have you found something you wanted where you couldn't find a
recent source rpm already tuned for your base installation
that you could tweak and rebuild with a couple of rpm commands?
>
>There's just no excuse for not having an adequate installer. We have
>two excellent package-management tools, dpkg (and apt) and rpm. All
>we have to do is put a shiny new GUI front-end on them.
What is wrong with clicking on an rpm file with the kde
file manager/browser? It will automatically start kpackage
so you can click the install button. Toss in the powertools
CD and go wild.
>Not that I am bitter.
Have you been doing it the hard way?
>> It seems that there are alot of linux programs out there that do
>> these things people need, its just that its hard to find them all.
>
>Yeah. Because there are 573,283 Linux packages, 572,911 of which do
>exactly the same thing, and 290 of which are cutesy man pages.
>
>We need some Machiavellian masochist to sift through all the packages
>for Linux, pick the best ones, and throw out the rest. I think
>anything that hasn't been changed for 5 years should go; we might have
>to make an exception for e2fsck, but as a rule, it would probably
>eliminate half the packages.
If it is free and useful you'll probably find it in either the
RedHat or Mandrake base RPMs or on the powertools CD. Or
the VALinux variation - all pretty much binary-rpm compatible.
>I much, much, much prefer being able to right-click on something and
>hit "Properties." I also like being able to press F1 when the mouse
>is over a confusing field and get an explanation of it. (The
>explanation often isn't a help, and I expect that would carry over to
>Linux, but at least there's no flipping around between screens.)
So what is the problem with doing this in the KDE desktop?
>Please excuse the rant. But Linux has been a pain in the ass to
>configure since I started using it in the early 90's, and it's
>improved not at all since then.
Huh? A recent Mandrake/RedHat does most of what you say
is missing right out of the box.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Problem with aha152x module
Date: Wed, 17 May 2000 22:01:53 GMT
Hi, I've built 2.2.15 on a very fast i686 which has an aha152x SCSI
card.
I finally managed to get everything to work [the card is a dog though
and was a pain to configure], with the driver configured as a module.
However, if I set things up so that the driver auto-installs, then my
app first fails to recognize it, but will do so if I restart. For
example, xsane will first not show my scanner, (UMAX Astra 1200S), but
will when if I try immediately again.
It looks like something is timing out too quickly. Any suggestions?
David
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Linux Mutexes and Conditions & 2.3.99
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 22:06:30 GMT
On Wed, 17 May 2000 21:00:14 GMT, Bill Waddington
<[EMAIL PROTECTED]> wrote:
>This to match the new wait queue stuff and to avoid including
>include/asm/spinlock.h directly (seems to be for SMP only).
Thanks for the patches; I already reworked your ikon_*.[ch] files into
a similar patch. I guess I should have waited. ;)
>The reason I ask (you were beginning to wonder...) is to ask the
>thousand eyes in this NG if this looks OK. I am using it in a char
>driver that uses kiobufs to do user buffer DMA, and that I want to be
>able to use on SMP and UP boxes. It is running now, except that
>occasionally when running two DR11s doing endless loopback self tests on
>a UP (P-167), both boards return from cond_timed_wait_rel() with a
>timeout - at approximately the same time. On a PIII-450 they _seem_ to
>run indefinitely. The boards (and driver code) are intended to run
>independently. It is as if both board's wakeups are missed - or
>interrupts (or scheduling) was held up for the 10s timeout period (seems
>_way_ unlikely!).
It does look like a lost wakeup. Are you using a predicate variable correctly?
E.g.
/* in the waiting code */
mutex_lock(&mutex);
/*...*/
while (!predicate)
cond_timed_wait_rel(&mutex, &cond, jifdelay);
/*...*/
mutex_unlock(&mutex);
/* in the signalling code */
mutex_lock(&mutex);
predicate = 1;
mutex_unlock(&mutex);
cond_signal(&cond);
You must lock the mutex when setting the predicate, else you will end up losing
the wakeup. Without this, when you execute ``predicate = 1'' or its
logical equivalent in your driver, the thread could be in the critical region,
just after the point where it finished checking the predicate and is about to
sleep.
--
#exclude <windows.h>
------------------------------
** 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
******************************
