Linux-Development-Sys Digest #99, Volume #8 Thu, 24 Aug 00 12:13:16 EDT
Contents:
Re: Kernel panic: VFS: (pinson cedric)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? (Tony Gale)
Re: all threads in a process share the same pid? (Alexander Viro)
Re: crypt(3) ("Z")
Stealing Colors from Applications ("Eoin Ryan")
Device driver programming (Bruno Ascenso)
Re: crypt(3) (Andreas Jaeger)
Re: Mount of Zip doesn't work since linux-2.4.0-test2 (bill davidsen)
Re: Embedded linux ("Mark Langsdorf")
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: crypt(3) (Fro-Man)
Re: crypt(3) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: pinson cedric <[EMAIL PROTECTED]>
Subject: Re: Kernel panic: VFS:
Date: Thu, 24 Aug 2000 12:53:52 +0200
Reply-To: [EMAIL PROTECTED]
Karl Heyes a �crit :
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Koch) wrote:
> > Hello all,
> >
> > I have trouble on recompiling a kernel, ie. when boot a system with the
> > new kernel, a message "Kernel panic: VFS: Unable to mount root fs on
> > 08:02" is displayed and freez.
> >
>
> I'm guessing that is trying to mount /dev/sda2 on /
>
> use rdev on the [b]zImage or pass root= option when
> booting. There isn't any config opton for this, the build scripts
> take you current root partition as the one intended unless you've
> editing the ROOT_DEV macro in the Makefile.
>
> > I use Slackware 7.0, kernel 2.2.13.
> >
> > I think it is my wrong configuration to a file .config that caused the
> > trouble.
> >
> > Could anybody give me answers for questions:
> >
> > Q1. What item or option shuld I select? Q2. Is there any good document
> > or book for correct
> > configuration("help" for each item is a little bit hard to
> > understand for me. I'd like to understand meaning of each item.)?
>
> I usually use make menuconfig which has access to the help texts, but not
> all options are documented.
>
> karl
humm i' had this error and in fact i forgot to check ext2fsextended in my
kernel ( filesystem)
if it help you
psc80
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Thu, 24 Aug 2000 11:34:26 GMT
In comp.os.linux.development.apps Tony Gale <[EMAIL PROTECTED]> wrote:
> Coincidentally, Linus was asked what form of fix for the shared PIDs
> problem would be acceptable, he replyed:
This is _great_ news. Do you happen to have a pointer to the original
text? The reason I ask is that from what I've seen, and what everyone
I've talked this over with privately, Linus was dead set against any
pthreads patches. Or, more accuratly, it seemed a long shot that any
solution wouldn't be too ugly. ;)
> ---------------------------------------
> Acceptable solution:
> - add "tgid" (thread group ID) to "struct task_struct"
> - CLONE_PID will leave tgid unchanged.
> - non-CLONE_PID will set "tgid" to the same as pid
> - get_pid() checks that the new pid is not the tgid of any process.
Does anyone have an estimate on how much userspace this will break, if
any? I'd love to see this in the next development kernel.
On that note, is there still a LinuxThreads list? I know the
maintainer must be watching this thread.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Tony Gale)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: 24 Aug 2000 11:51:55 GMT
In article <6L7p5.44224$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
>
> This is _great_ news. Do you happen to have a pointer to the original
> text? The reason I ask is that from what I've seen, and what everyone
> I've talked this over with privately, Linus was dead set against any
> pthreads patches. Or, more accuratly, it seemed a long shot that any
> solution wouldn't be too ugly. ;)
It's here
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-34/0450.html
>
>> ---------------------------------------
>> Acceptable solution:
>> - add "tgid" (thread group ID) to "struct task_struct"
>> - CLONE_PID will leave tgid unchanged.
>> - non-CLONE_PID will set "tgid" to the same as pid
>> - get_pid() checks that the new pid is not the tgid of any process.
>
> Does anyone have an estimate on how much userspace this will break, if
> any? I'd love to see this in the next development kernel.
>
> On that note, is there still a LinuxThreads list? I know the
> maintainer must be watching this thread.
>
The solution Linus has proposed seems relatively simple (at least to me)
and is an inversion of the way Xavier hinted that people have tried to
implement it in the past - i.e. making threads actually have the same
PID vs. giving threads an additional thread group ID and using that as
the PID at the user level.
It means you don't have to change the scheduler et al.
Xavier did the LinuxThreads implementation, and I'd be interested to
hear his thoughts on how far this will 'fix' the POSIX non-compliances
that LinuxThreads currently has.
BTW, the thread (which you can get to from the URL above) also discusses
other LWP/CLONE/user level/kernel level threading stuff - but I don't
think there's anything else new in there.
-tony
--
E-Mail: Tony Gale <[EMAIL PROTECTED]>
The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: 24 Aug 2000 09:12:24 -0400
In article <YChn5.34266$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>> It's quite irritating.
>
>On the other hand, having your software compile and run on every *nix
>variant except Linux is more irritating.
By the same logics we should have Missed'em'V streams in the kernel.
BTW, do you realize that clone(2) is not unique to Linux? Take *BSD or Plan 9
and check for rfork(2). It's pretty much the same beast (modulo different
interpretation of the bitmap argument).
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "Z" <[EMAIL PROTECTED]>
Subject: Re: crypt(3)
Date: Thu, 24 Aug 2000 15:31:05 +0100
Once upon a while Fro-Man <[EMAIL PROTECTED]> wrote:
>
> Hopefully this is a simple question:
>
> /* excerpt from man page */
> #define _XOPEN_SOURCE
> #include <unistd.h>
>
> char *crypt(const char *key, const char *salt);
> /* end of excerpt */
>
> The char* that crypt returns, what is it? Is it malloc()'d memory or
> static somewhere? I have tried compiling it with with free()'ing the
> returned pointer, but it segfaults. If it isn't malloc()'d, where'd it
> come from?
>
I've downloaded the code of glibc-crypt-2.0.6 and it looks like the
buffer that holds the crypted string is global data but not malloced.
Therefor a call to free is no good at this pointer. Dispite
this fact it could also be possible that the returned reference does not
have to be the memory that was allocated in crypt but could be for
example part of a struct where free still would not get the address
of the pointer it used at allocation.
>
> Also, for some reason when I try to compile I do not seem to be getting
> the correct include files. Or atleast the declaration for the crypt
> function does not seem to exist where the man pages says it does. I can
> easily get the error to go away if I just declare it within my program,
> but that seems kind of messy. I'd just rather inlcude it correctly.
>
> ~/src/example/crypt > gcc -Wall encrypt.c -c
> encrypt.c: In function `main':
> encrypt.c:13: warning: implicit declaration of function `crypt'
> encrypt.c:13: warning: assignment makes pointer from integer without a
> cast
it looks like you either forgot to include unistd.h or forgot
to define _XOPEN_SOURCE.
Try to compile and link the whole thing as:
gcc -Wall -D_XOPEN_SOURCE -o encrypt encrypt.c -lcrypt
Hope this helps.
Z
> ~/src/example/crypt > gcc -Wall encrypt.o -lcrypt
> ~/src/example/crypt >
>
> TIA
>
> # Aaron Day # [EMAIL PROTECTED] # http://www.csis.gvsu.edu/~daya #
>
> Ever get that feeling you are being watched?...
> Its a skunk.
>
--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days. Eric S. Raymond
------------------------------
From: "Eoin Ryan" <[EMAIL PROTECTED]>
Subject: Stealing Colors from Applications
Date: Thu, 24 Aug 2000 14:28:09 +0100
Hi all,
This is actually a problem on a Solaris machine and probably shouldn't be in
here, but as it's more of a development problem I thought I'd send it in
here as well.
Does anyone know a way of preventing applications from stealing colors from
other applications? What's happening is this; when running my java proggie
in conjunction with other GUI's my program is left without any colors. When
passing the mouse over menu items the menu item disappears behind a wall of
black. None of the colors of the icons load properly, neither does the
title bar. The only way of getting the colors back is to quit the other
apps, and restart mine.
We've had a similar problem a couple of weeks back with another application,
which was fixed by changing the color depth to 24, however this solution
doesn't appear to work in this case.
Running Solaris 7, jdk 1.2.2.
Thanks,
Eoin.
------------------------------
From: Bruno Ascenso <[EMAIL PROTECTED]>
Subject: Device driver programming
Date: Thu, 24 Aug 2000 15:18:55 +0100
Hi,
I' working on device driver for a network card I have. The driver is
almost done and has a lot of code.
Since, I didn't need its symbols to be known outside, I simply used the
macro EXPORT_NO_SYMBOLS;
and didn't declare any functions as static.
Now, I need to export a couple of functions to some other module, but
don't want do remove the macro and polute so much the namespace.
What I'd like to know is if it's possible to do something to export
nothing but the symbols I need without going through the code and
declare everything as static.
I tried simply EXPORT_SYMBOL() in the symbols I need but it doesn't
work. I was unable to see the symbol outside.
-- B. Ascenso
____________________________________________________________________________
WATM2000:
Wireless ATM over DSSS 802.11 cards
E-mail: [EMAIL PROTECTED]
URL: http://feldspato.ist.utl.pt/~watm2000
Authors:
Bruno Ascenso: [EMAIL PROTECTED]
Bruno Santos : [EMAIL PROTECTED]
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: crypt(3)
Date: 24 Aug 2000 16:43:08 +0200
>>>>> Fro-Man writes:
> Hopefully this is a simple question:
> /* excerpt from man page */
> #define _XOPEN_SOURCE
> #include <unistd.h>
> char *crypt(const char *key, const char *salt);
> /* end of excerpt */
> The char* that crypt returns, what is it? Is it malloc()'d memory or
> static somewhere? I have tried compiling it with with free()'ing the
> returned pointer, but it segfaults. If it isn't malloc()'d, where'd it
> come from?
>From Unix98:
Upon successful completion, crypt() returns a pointer to the
encoded string. The first two characters of the returned value are
those of the salt argument.
> Also, for some reason when I try to compile I do not seem to be getting
> the correct include files. Or atleast the declaration for the crypt
> function does not seem to exist where the man pages says it does. I can
> easily get the error to go away if I just declare it within my program,
> but that seems kind of messy. I'd just rather inlcude it correctly.
Did you define _XOPEN_SOURCE before the inclusion of any header file?
Read "Feature Test Macros" in the libc manual with e.g.:
$ info libc "Feature Test Macros"
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
http://www.suse.de/~aj
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Mount of Zip doesn't work since linux-2.4.0-test2
Date: 24 Aug 2000 15:29:01 GMT
In article <[EMAIL PROTECTED]>, softrat` <[EMAIL PROTECTED]> wrote:
| bill davidsen wrote:
| >
| <snip>
| five years and then calling the same color purple because you like the
| > sound of it.
| >
| You probably need to update your package modutils. Documentation/Changes
| for kernel 2.4.0-test5 recommends version 2.3.10 or later. I am using
| version 2.3.14-1.
Unless it translates 'sd_mod' to 'sd' by magic, I don't think my
scripts will work any better. I agree the original name was poorly
chosen, but changing it means that things fail at boot time on many
systems, when trying to use SCSI disks, for instance.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
Make the rules? I don't make the rules. I don't even FOLLOW the rules!
------------------------------
From: "Mark Langsdorf" <[EMAIL PROTECTED]>
Subject: Re: Embedded linux
Date: Thu, 24 Aug 2000 10:26:45 -0500
"David" <[EMAIL PROTECTED]> wrote in message
news:7g4p5.8008$[EMAIL PROTECTED]...
> Is anyone here working on any embedded Linux systems? If so, what
> do you use?
On the x86 side, there's two good choices: Lineo and Lynuxworks.
SuSE is supposed to be working on something, but no release date,
and I haven't heard much good about Red Hat's offering.
Lineo's Embeddix SDK is very powerful, though it's a bit of
pain to extend for custom device drivers. It's also pricey for the
Linux market: $5000 per development seat.
Lynuxworks solution (Blue Cat?) is much cheaper, but not as
fully featured. They're also primarily pushing their proprietary
RTOS (Lynx), which can be a bit of a downer.
-Mark Langsdorf
These are my own opinions, and do not reflect the views of AMD, Inc
or anyone else inside of AMD.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Thu, 24 Aug 2000 15:28:56 GMT
In comp.os.linux.development.apps Alexander Viro
<[EMAIL PROTECTED]> wrote:
> By the same logics we should have Missed'em'V streams in the kernel.
> BTW, do you realize that clone(2) is not unique to Linux? Take *BSD or Plan 9
> and check for rfork(2). It's pretty much the same beast (modulo different
> interpretation of the bitmap argument).
Well, I do think streams should be there, but that's a whole nother
issue. ;)
In essence though, it's not even a good analogy. Even System V
included sockets, although the TLI was "obviously superior." The point
is LinuxThreads are nowhere near the Posix standard, yet the
"obviously better" defense gets trodden out with stunning
regularity. Noone would have an issue with clone(2) if you could
actually _make_ threads with it, the point is right now, you can't.
As I said before, I don't have any problem at all with people using it
to make the current "process threads" What I _do_ take issue to is the
perpetual argument that goes something like this:
"Linux has pthreads."
"No, it doesn't. For example, pids aren't shared which breaks some
programs."
"Well, you didn't really want them anyway, because Posix threads
suck."
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Thu, 24 Aug 2000 15:37:10 GMT
In comp.os.linux.development.apps Tony Gale <[EMAIL PROTECTED]> wrote:
> It's here
> http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-34/0450.html
Thank you.
> The solution Linus has proposed seems relatively simple (at least to me)
> and is an inversion of the way Xavier hinted that people have tried to
> implement it in the past - i.e. making threads actually have the same
> PID vs. giving threads an additional thread group ID and using that as
> the PID at the user level.
> It means you don't have to change the scheduler et al.
It's funny you mention that, because originally my thought was that
all we needed to do was have seperate pids and tids. A number of
people have insisted that we need a new scheduler and seperate
structures. I'd always assumed it was due to some ugliness in the
standard. (I don't own a copy)
> Xavier did the LinuxThreads implementation, and I'd be interested to
> hear his thoughts on how far this will 'fix' the POSIX non-compliances
> that LinuxThreads currently has.
I think, and I could be wrong, that it will still be possible to
violate the standard, unless some system calls are modified to be
"thread aware" at the same time. It looks to me like it would fix most
of the big issues though. And, more importantly, _all_ of the kernel
ones.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Fro-Man <[EMAIL PROTECTED]>
Subject: Re: crypt(3)
Date: Thu, 24 Aug 2000 11:39:04 -0400
On 24 Aug 2000, Andreas Jaeger wrote:
> >>>>> Fro-Man writes:
> > Hopefully this is a simple question:
> > /* excerpt from man page */
> > #define _XOPEN_SOURCE
> > #include <unistd.h>
> > char *crypt(const char *key, const char *salt);
> > /* end of excerpt */
> > The char* that crypt returns, what is it? Is it malloc()'d memory or
> > static somewhere? I have tried compiling it with with free()'ing the
> > returned pointer, but it segfaults. If it isn't malloc()'d, where'd it
> > come from?
> From Unix98:
> Upon successful completion, crypt() returns a pointer to the
> encoded string. The first two characters of the returned value are
> those of the salt argument.
Yes, but that doesn't answer if it was malloc()'d or if it was a static
string. I have since found out it is static, but nothing said that
before. And it seems kind of silly to have a static string in such an
instance like this, instead of a malloc()'d one.
> > Also, for some reason when I try to compile I do not seem to be getting
> > the correct include files. Or atleast the declaration for the crypt
> > function does not seem to exist where the man pages says it does. I can
> > easily get the error to go away if I just declare it within my program,
> > but that seems kind of messy. I'd just rather inlcude it correctly.
> Did you define _XOPEN_SOURCE before the inclusion of any header file?
> Read "Feature Test Macros" in the libc manual with e.g.:
> $ info libc "Feature Test Macros"
I figured this out... Thanks. I had my includes and defines as such:
#include <stdio.h>
#define _XOPEN_SOURCE
#include <unistd.h>
which created the warnings... When I changed it to:
#define _XOPEN_SOURCE
#include <stdio.h>
#include <unistd.h>
it worked find...
Aaron Day / Keep the milk in /
[EMAIL PROTECTED] / the cow, if you /
http://www.csis.gvsu.edu/~daya / don't want it to sour /
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: crypt(3)
Date: Thu, 24 Aug 2000 15:52:12 GMT
Fro-Man <[EMAIL PROTECTED]> wrote:
> Yes, but that doesn't answer if it was malloc()'d or if it was a static
> string. I have since found out it is static, but nothing said that
> before. And it seems kind of silly to have a static string in such an
> instance like this, instead of a malloc()'d one.
It should be in the man page, I think he fact that it isn't is just a
historical artifact. It's always been a static buffer, and everyone
knows it sort of thing. ;)
Having it return a malloc'd instance, however, is _not_ a better idea
for two reasons. First, very few people are actually concerned with
keeping the hash around after the next call to crypt(). On top of
that, there are significant numbers of functions which return data in
a static buffer besides crypt(), so it's more in keeping with the rest of
the library.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
