Linux-Development-Sys Digest #72, Volume #8       Wed, 9 Aug 00 16:13:10 EDT

Contents:
  Re: Using JNI on Linux (Florian Schmidt)
  alignment of return addresses on stack (sampanna)
  problems with printk ("Olivier Accili")
  Re: What is the difference between soft link and hard link? 
([EMAIL PROTECTED])
  Linux Thread FAQ (M Dipperstein)
  kernel experiements ("Christos Karayiannis")
  Re: alignment of return addresses on stack (Johan Kullstam)
  Re: What is the difference between soft link and hard link? (Mario Klebsch)
  Re: Using JNI on Linux (Michael M. Welch)
  AWK script port from Linux to HP-UX (Steve Parker)
  PTHREAD_CREATE from Child Process (Jeffrey Hawkins)
  Re: PTHREAD_CREATE from Child Process ([EMAIL PROTECTED])
  share libraries in Linux ("Peter Huang")
  Re: AWK script port from Linux to HP-UX (Kaz Kylheku)
  shared variables in dll ("Peter Huang")
  Re: problems with printk ("RM")
  Re: Using JNI on Linux (Florian Schmidt)
  Re: PTHREAD_CREATE from Child Process (Kaz Kylheku)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Florian Schmidt)
Crossposted-To: comp.lang.java.programmer,comp.lang.java.help
Subject: Re: Using JNI on Linux
Date: Wed, 09 Aug 2000 11:11:15 GMT

On 9 Aug 2000 05:39:26 GMT, [EMAIL PROTECTED] (Michael M. Welch)
wrote:

>    Thanks VERY much to everyone who chipped in with help.  The problem
>was indeed in an improper creation of the shared library due to a VERY
>silly mistake on my part.  The Java program was finding the library OK, 
>but failing to load it because of that problem.  Thanks especially to 
>Robert Lynch who e-mailed me back and forth on Friday to help me figure 
>it out.  8-)

share your wisdom ;)


--
Florian Schmidt
[EMAIL PROTECTED]

------------------------------

From: sampanna <[EMAIL PROTECTED]>
Subject: alignment of return addresses on stack
Date: Wed, 09 Aug 2000 17:09:41 +0530
Reply-To: [EMAIL PROTECTED]

aloha.
i seem to have a problem here...
gcc appears to store return eip addresses on the stack aligned on 16
byte boundaries...is this necessary for the architecture(i386) or is it
a gcc optimization? if it is a gcc optimization, how do i prevent it?


sam



------------------------------

From: "Olivier Accili" <[EMAIL PROTECTED]>
Subject: problems with printk
Date: Wed, 9 Aug 2000 13:53:36 +0200
Reply-To: "Olivier Accili" <[EMAIL PROTECTED]>

Hello,

Did someone heard something like esp register could not be at the right
place after printk usages ?

I explain:
I have a 2.0.34 kernel and I use printk to trace some values (3) in a kernel
function (sys_i386.c file).
After printk esp register is smaller than before of 12 bytes so I have to
correct it by myself.

My code is:
printk("esp is: %lx    gs is: %lx    tss.esp0 is:
%ls\n",v_esp,v_gs,current->tss.esp0);


Does anyone know why ?

Thanks in advance.



------------------------------

From: [EMAIL PROTECTED]
Subject: Re: What is the difference between soft link and hard link?
Date: Wed, 09 Aug 2000 12:01:04 GMT

On Tue, 08 Aug 2000 17:12:34 +0200 Josef Moellers <[EMAIL PROTECTED]> 
wrote:

| Yi-Hsiu Chou wrote:
|> 
|> Hi..
|>    I want to know what is the difference between soft link and
|> hard , and if they will use inode ?
|
| A soft link is a file which contains a pathname which will be used to
| further search for the file.
| A hard link is just an additional name for the same inode.

Some people will miss the concept of how a Unix filesystem is built,
and how this relates to hard links.  I hope this explanation will help:

Most Unix filesystems start with an array of inodes on disk.  The inodes
are structures that describe file objects of all types, and are the
starting point to find the data.  However, inodes contain no names.
They are referenced directly by number.

Some of the file types are directories.  A directory is a list of names
with a number which points to the inode.  A hardlink is a misnomer which
really describes a situation where 2 or more names, which can be in the
same directory or in different directories, refers to the same inode.
Each such name is equal to any other; there is no superior/inferior
relation between them.

Any hardlink name can be removed at any time.  Doing so only removes
the name reference, not the actual file, until the very last name is
removed.  The inode keeps a counter of the number of "links" it has,
so when the count reaches zero, the file is gone.

If a file has the name "abc", and you make a hardlink as "xyz" by doing:
  ln abc xyz
there are now 2 names for the original inode.  You can now remove "abc":
  rm abc
and the file remains, but under only the name "xyz".

Since each different partition/filesystem has its own inode numbers,
any inode reference has to be within the same filesystem.  If you have
just one big partition/filesystem, then you have no limitations.  But
if you have split up the file tree into multiple filesystems, then the
name sharing is limited to within the same filesystem.  Symbolic, or
"soft" links, are how one gets around that limitation.  Symbolic links
are sort of like a sign that says "I've moved, find me at this other
location" but with one difference, you keep going back to the same place
every time.  If the pointed-to file is removed, the it is gone, but the
symbolic link is still there, pointing into thin air.  If the symbolic
link is removed first, the pointed-to file is not affected.

Directories cannot be hardlinked, that is, they cannot have more than
one name because some nasty things happen if they do (there are ways
to force this, but don't try unless you know how to clean up the mess).
Symbolic links, however, work fine for directories.

-- 
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil  (at)  ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]

------------------------------

From: M Dipperstein <[EMAIL PROTECTED]>
Subject: Linux Thread FAQ
Date: Wed, 9 Aug 2000 05:57:17 -0700

I am fairly new to the world of Linux development and I have developed
a many-to-many thread package for SMP Linux for a thesis project.  I
would like to make the package available for the Linux community.  If
possible, I would like to have the package included in the Thread FAQ
for Linux.  I have tried e-mailing Sean Walton, the author of the FAQ,
and the e-mail has bounced.  Is the Thread FAQ still maintained? Are
there any protocols for updating the FAQ?  What are the traditional
methods for releasing Linux works?

For those who are interested the package is still a bit young, with
several avenues that may be explored.  However it is stable, and
demonstrates good performance for problems, such as grid solvers,
which increase their percent of cache hits as more threads are added.

-Mike


------------------------------

From: "Christos Karayiannis" <[EMAIL PROTECTED]>
Subject: kernel experiements
Date: Wed, 9 Aug 2000 16:16:58 +0300

I would like to try some changes to the linux kernel.
Where could I find a FAQ describing the whole process (from begining to the
end) of patching the kernel using as patch a modified .c kernel file?

                                                            Christos



------------------------------

Subject: Re: alignment of return addresses on stack
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 09 Aug 2000 10:13:19 -0400

sampanna <[EMAIL PROTECTED]> writes:

> aloha.
> i seem to have a problem here...
> gcc appears to store return eip addresses on the stack aligned on 16
> byte boundaries...is this necessary for the architecture(i386)

not necessary, but alignment might be a good idea.

> or is it
> a gcc optimization?

yes.  the processor can fetch things on a nice power of two memory
boundary much more quickly than if it straddles it.

> if it is a gcc optimization, how do i prevent
> it?

if you are not using much floating point, then use this setting 
-mpreferred-stack-boundary=2

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
sysengr

------------------------------

From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: What is the difference between soft link and hard link?
Date: Wed, 9 Aug 2000 14:49:47 +0200

[EMAIL PROTECTED] writes:

>Directories cannot be hardlinked, that is, they cannot have more than
>one name because some nasty things happen if they do

Directories always have hard links. The minimum link count on a
directory is 2. If there are child directores in the directory, the
link count increases witch each child directory.

The reason is simple:

1st link is the directory (stored in its parent dir).
2nd link is '.' stored in the directory
3rd, 4tt, .. link is '..' stored in each child direcory.

73, Mario
-- 
Mario Klebsch                                           [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB  1483 30CE 9FB2 A047 9CE0
 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5  8B98 9464 53FF 9382 F518

------------------------------

From: [EMAIL PROTECTED] (Michael M. Welch)
Crossposted-To: comp.lang.java.programmer,comp.lang.java.help
Subject: Re: Using JNI on Linux
Date: 9 Aug 2000 17:02:30 GMT

In article <[EMAIL PROTECTED]>,
Florian Schmidt <[EMAIL PROTECTED]> wrote:
>On 9 Aug 2000 05:39:26 GMT, [EMAIL PROTECTED] (Michael M. Welch)
>wrote:
>
>>    Thanks VERY much to everyone who chipped in with help.  The problem
>>was indeed in an improper creation of the shared library due to a VERY
>>silly mistake on my part.  The Java program was finding the library OK, 
>>but failing to load it because of that problem.  Thanks especially to 
>>Robert Lynch who e-mailed me back and forth on Friday to help me figure 
>>it out.  8-)
>
>share your wisdom ;)

     Oh, believe me if there were any *wisdom* to share here, I'd have
done it by now.  Unfortunately all I have to offer is my sheer and
unadulterated stupidity.

     Back in my original message, I mentioned that the part about which
I was most fuzzy was indeed the creation of the shared library in Linux.
So to be sure I did it *exactly* write I copied the commands straight
from an example of using JNI on Linux that I found in a Java Tip and
javaworld.com.  The example used a C library, not C++ like I was using
but I did want to be sure to get everything else just right, so I copied
and pasted the exact command they used and made a mental note to change
their gcc to g++ for me.  

     Unfortunately though, absent-mindedness set in and the mental note
was never translated into physical action.  And when the program bombed,
I was so concerned with the LD_LIBRARY_PATH and with the *rest* of the
compliation and linking command for the library that I just never did
notice those to little c's still sitting there instead of *'s.  I had 
written a C++ program that used this exact same C++ library and it was
able to adapt to the fact that the C++ library was actually created in
C-style and run successfully.  But the Java program could not similarly
adapt to properly load a library that was created in C-style but was 
actually a C++ library.  Nonetheless, the fact that C++ program failed
to exhibit any symptoms of my mistake threw me off in that it caused me
to try to find other areas at which to look for the problem.

     Only after Robert Lynch helped me figure out that yes indeed the
library *was* being located, just not loaded successfully and then asked
me specifically what command was I using to compile and link the library
did I notice it.  As I was writing my response to him, I pulled the 
command into the editor and suddenly the c's jumped out at me like a
sore thumb and I couldn't believe I had forgotten to change them.  

     I quit out of my response message to Robert, changed them to *'s, 
tried the program again and problem solved.  Duuuuuuuuuuuuuuuuh.

     How's THAT for "wisdom"?  8-)


- Michael
  http://www.Michael.Welch.net/
--
Michael M. Welch
[EMAIL PROTECTED]
http://www.Michael.Welch.net/

------------------------------

From: Steve Parker <[EMAIL PROTECTED]>
Subject: AWK script port from Linux to HP-UX
Date: Wed, 09 Aug 2000 14:32:52 -0400

Hi,

I was hoping somebody could assist me with as AWK porting question.

The below script works fine on Linux.  However, on HP-UX 10.2, I get the
following error:
"Input line ........ cannot exceed 3000 bytes"

Does anyone have any clue what this problem might be caused by?

Any help is very much appreciated.

thanks,
steve


====================== AWK script ========================

BEGIN {  ORS = " "; RS = ">"; charCount = 0; notFinished = 1; }

insideTag = 0
openStartTag = 0
####
# Loop through current record
####
{ for (i = 1; i <= NF; i++) {

        if (insideTag == 1) openStartTag++
        if ( match($i, /<(.)*/) ) {
          insideTag = 1
          openStartTag = 1
        }

        if (openStartTag <= 1) {

          ####
          # Remove remainder of HTML tags
          ####
          gsub(/<(\/)*(.)*/, "", $i)
          gsub(/\&nbsp;/, "", $i)


          ####
          # Print the field
          ####
          if (length($i) > 0) {
            lastCharCount = charCount
            charCount = charCount + length($i) + 1
            if (charCount <= 250) {
              print $i
              totalCount++
            }
            else if (notFinished == 1) {
              notFinished = 0
              bufferCount = lastCharCount + 1
              while (bufferCount <= 250) {
                bufferCount = bufferCount + 1
                print ""
              }
            }
          }
        }
  }
}



------------------------------

From: Jeffrey Hawkins <[EMAIL PROTECTED]>
Subject: PTHREAD_CREATE from Child Process
Date: Wed, 09 Aug 2000 13:32:26 -0500

Has anybody ran into a problem with trying to create
a Thread from a Child Process ?  I am currently adapting
a Software Package, that does this, from AIX to LinuxPPC.
I am encountering a problem where the Thread is created,
but the Pthread_Create Call never returns to the invoking
Child Process.

If I remove the usage of the Child Process, and do the 
Pthread_Create from the Main Parent Process, everything
works fine.  However, a lot of the Application Package
Software relies on being able to create threads under
Child Processes, so it would be a major effort to change
the Application Software.

I am currently running a 2.1.3 version of the GLIBC,
which has some other Threads Fixes, but nothing related
to my problem...

Is this functionality supported on Linux Threads ? 
Is this problem related to the tracking of the Parent
Process ID within Threads ?

Any help would be appreciated...

Jeff

-- 
********************************************************
                                                      
Jeffrey Hawkins

Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering

Address: DEPT:  DQ525
         MS:    IL-02-1055A
         1301 East Algonquin Road
         Schaumburg, IL 60196

Phone:   (847)576-7463
FAX:     (847)576-7737

********************************************************

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: PTHREAD_CREATE from Child Process
Date: Wed, 09 Aug 2000 19:13:19 GMT

Jeffrey Hawkins <[EMAIL PROTECTED]> wrote:
> Is this functionality supported on Linux Threads ? 
> Is this problem related to the tracking of the Parent
> Process ID within Threads ?

The problem is that Linux doesn't support POSIX threads. The
SHARED_PID argument to clone() isn't useable from user space, so the
best any library can currently do is create seperate proccesses that
share the same data segment, not PID's.

AFAIK, you should be able to create threads in child processes, but
they won't be able to access anything in the parent process. There may
be a limitation on "nested threads" in glibc I'm not aware of
though. My problem was in trying to port something that waited on
children of other threads, which is impossible in Linux. Fortunatly,
the author is rewriting it.

My own research into the subject was less than encouraging. Various
people consider the POSIX standard "technically stupid" or favor a
solution entirely in userspace. The userspace argument has merit, but
it's impossible to me to see how you could implement shared PID's
without any help from the kernel.

On the other hand, at least some people, including some of the
"technically stupid" crowd, have indicated that they don't consider
implementing shared id's a bad thing, provided it can be done in a
clean and useful manner.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

------------------------------

From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: share libraries in Linux
Date: Wed, 9 Aug 2000 12:02:40 -0700

Hi all

Is there any way that I can allow different processes using a share library
to share resources,
such as global variables. I'm trying to create a higher level device driver
in the user space to complement the kernel loadable module that I create. In
Windows, I can declare certain variables in a dll to be share by all the
processes utilizing the dll. In Linux, does such capability exist. If so,
how do I implement it. If not, are there any ways that I can implement the
equavalent feature, (shared variable in the dll) in Linux. I'm thinking of a
daemon might do the trick but I don't know much about daemon's in Linux
either. Thanks for the help.

Peter



------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: AWK script port from Linux to HP-UX
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 Aug 2000 19:17:43 GMT

On Wed, 09 Aug 2000 14:32:52 -0400, Steve Parker <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I was hoping somebody could assist me with as AWK porting question.
>
>The below script works fine on Linux.  However, on HP-UX 10.2, I get the
>following error:
>"Input line ........ cannot exceed 3000 bytes"
>
>Does anyone have any clue what this problem might be caused by?

The problem is lack of robustness in legacy implementations of UNIX utilities.
The awk program on Linux is GNU awk. You can install this on HP-UX.

Anyway, since your issue occurs with a proprietary program that is part of
HP-UX, don't you think you should raise your question in a HP-UX newsgroup
rather than a Linux newsgroup?

-- 
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.

------------------------------

From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: shared variables in dll
Date: Wed, 9 Aug 2000 12:12:49 -0700


Hi all

My previous message might be too vague. But what I'm trying to find out is
for multiple applications that map a particular dll to share a variable
inside the dll. Please let me know if there is a way to do that. Thanks

Peter





------------------------------

Reply-To: "RM" <[EMAIL PROTECTED]>
From: "RM" <[EMAIL PROTECTED]>
Subject: Re: problems with printk
Date: Wed, 9 Aug 2000 15:34:20 -0400

Check the optimization settings for GCC.  Some compilers (saw it with
MSVC6.0, think I saw something that sounds the same under GCC) will
"optimize" by keeping track of stack usage across multiple function calls,
then perform a single cleanup call whenever appropriate (i.e. before a loop,
within a loop, or before function end). This would explain the 12-bytes for
your code (three 32-bit long ints).

Question is, why is the format string identifier "%ls" for the tss.esp0? If
this is not a typo, It could also be the source of your problems.

Sorry I can't be more specific about where to look or which command line
option to tweak...

Cheers,
Robb Main.

Olivier Accili <[EMAIL PROTECTED]> wrote in message
news:8mrgqo$[EMAIL PROTECTED]...
> Hello,
>
> Did someone heard something like esp register could not be at the right
> place after printk usages ?
>
> I explain:
> I have a 2.0.34 kernel and I use printk to trace some values (3) in a
kernel
> function (sys_i386.c file).
> After printk esp register is smaller than before of 12 bytes so I have to
> correct it by myself.
>
> My code is:
> printk("esp is: %lx    gs is: %lx    tss.esp0 is:
> %ls\n",v_esp,v_gs,current->tss.esp0);
>
>
> Does anyone know why ?
>
> Thanks in advance.
>
>



------------------------------

From: [EMAIL PROTECTED] (Florian Schmidt)
Crossposted-To: comp.lang.java.programmer,comp.lang.java.help
Subject: Re: Using JNI on Linux
Date: Wed, 09 Aug 2000 19:34:56 GMT

On 9 Aug 2000 17:02:30 GMT, [EMAIL PROTECTED] (Michael M. Welch)
wrote:

>     I quit out of my response message to Robert, changed them to *'s, 
>tried the program again and problem solved.  Duuuuuuuuuuuuuuuuh.
>
>     How's THAT for "wisdom"?  8-)


at least i won't do the same mistake after u mentioned it. thx..


--
Florian Schmidt
[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: PTHREAD_CREATE from Child Process
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 Aug 2000 19:30:10 GMT

On Wed, 09 Aug 2000 13:32:26 -0500, Jeffrey Hawkins
<[EMAIL PROTECTED]> wrote:
>Has anybody ran into a problem with trying to create
>a Thread from a Child Process ?  I am currently adapting
>a Software Package, that does this, from AIX to LinuxPPC.
>I am encountering a problem where the Thread is created,
>but the Pthread_Create Call never returns to the invoking
>Child Process.

Not long ago I did a code inspection to specifically look for fork() related
problems in LinuxThreads and ended up fixing a bunch of bugs.  These bugfixes
are not available in any glibc release (other than the 2.1.91 and 2.1.92 beta
test releases) but they probably fix the problem you are having.  The fixes
address the global locks in libio, the pthread_atfork global lock itself and
the lock used by pthread_once.  (Now, if a fork() occurs while a pthread_once
callback is in progress, then in the child, the behavior will be as if that
initialization never took place).

The main problem in 2.1.3 and older is that some global locks are not taken
care of correctly at fork() time so the child process can inherit certain locks
in a bad state.  It is possible that your child process is deadlocking on one
of these locks.  Or possibly, there is something wrong with the child's new
thread manager.

Note that according to POSIX, the child of a multithreaded process can only
execute async-safe library functions, so strictly speaking, what you are doing
is not well-defined. However, it is *intended* to work and so it is a bug
if it does not.

>I am currently running a 2.1.3 version of the GLIBC,
>which has some other Threads Fixes, but nothing related
>to my problem...

Sadly, fork() and threads simply do not mix very well in glibc 2.1.3 and older.
See if your problem goes away if you use the latest pre-2.2 test release. If
not, then you should submit a bug report.

-- 
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.

------------------------------


** 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
******************************

Reply via email to