Linux-Development-Sys Digest #210, Volume #8     Thu, 12 Oct 00 09:13:12 EDT

Contents:
  Re: A new directory hierarchy standard - need opinions (Equinox)
  Re: LinuxThreads : problem with sigwait() ("Arthur H. Gold")
  Re: include file for printk() (Vivek Gupta)
  E2A4D600 Visio for Linux ([EMAIL PROTECTED])
  Re: utime(touch) gives EPERM - Bug in Linux??? (Villy Kruse)
  SMP problem: device driver for memory disk (Chris Nott)
  Re: memory utilities ("[EMAIL PROTECTED]")
  Where can I get Library source files? ("Lee, Yunseung")
  Re: How to access a unexported kernel symbol ? ("Anil Prasad")
  Re: Where can I get Library source files? (Josef Moellers)
  Trying to compile Nvidia drivers in a SMP system. ([EMAIL PROTECTED])

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

From: [EMAIL PROTECTED] (Equinox)
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
Date: Thu, 12 Oct 2000 04:43:10 GMT

On 11 Oct 2000 00:31:03 GMT, Todd Knarr <[EMAIL PROTECTED]>
wrote:

>>      Shouldn't the directory containing include
>>      files be under a src/ directory somewhere?
>
> Nope. Think a second. src/ contains source code. Where do the include
> files for, say, glibc go if you don't have the source code for glibc
> installed ( this would be most machines )? This doesn't show up when
> thinking about applications but does show up in the set of files needed
> to use a library vs. the set of files needed to build the library in the
> first place.

The include files for glibc would go in the location where the glibc
source would reside if it were present.  If the glibc source were to
reside in src/glibc-whatever/ , then the glibc includes would be
located in src/glibc-whatever/include/ or /src/glibc-whatever/headers/
or something similar.

The includes would need to be accessible from a common location, of
course, for the benefit of the compiler.  This is why God gave us
symlinks.  Of course, the result would be similar to /usr/include/ ,
but it doesn't need to be directly beneath /usr/ .  Perhaps this could
reside in the lib/ directories, as lib/include/ .

The main point here is that the hierarchies immediately beneath / ,
/usr/ , and /usr/local/ should be as similar as possible.  Exceptions
will occur, of course; but avoidable departures should be, well,
avoided.


>>      Why, then, do we have /opt/bin/ , /opt/lib/ , and
>>      so forth?
>
> Convention. /opt is broken down per-package. If you aren't referencing
> the /opt/{package} directories directly, you usually make a link from
> /usr/{bin|lib|...} ( or /usr/local/{bin|lib|...} to the appropriate files
> under /opt.

Exactly my point.  The "front-end" binaries of a package in opt/ would
be symlinked into the existing bin/ directory appropriate to its role
in the system.  A separate opt/bin/ would be unnecessary.


> Frankly I find /opt a kludge, but it's a reasonable solution when
> dealing with packages that like to own their entire directory tree
> and don't co-exist well in the same directories as other packages.

I think opt/ is a rather good solution for large packages.  As one
person (who sent a response via private e-mail) pointed out, it is
"much easier to blow the cruft away after it proves its true value."
It's only kludgey in that "proper" use of opt/ tends to cause either a
lot of symlinks, or an extremely long $PATH .  It follows that opt/
should only be used for packages whose complexity truly warrants such
segregation.  X11 is a prime example (see below).


>>      I interpret "add-on" to mean "not essential to system
>>      operation".  In light of this, why do we have /opt/ , instead of
>>      /usr/opt/ and /usr/local/opt/ ?
>
>Because either would be exactly equivalent to /opt?

Not so, by reason of location.  As the previously mentioned fellow
said in his message,

        /usr was for 'unvital' stuff like compilers, headers and
        nice-to-have executables.  / is for must-have-to-run.

I would amend this to say that the hierarchy under /usr/ (excepting
/usr/local/ ) is for non-vital stuff that came with the distribution,
and that the /usr/local/ hierarchy is for non-vital stuff that didn't
come with the distribution.

Therefore, 

1) /opt/ would be for large, complex packages that were required by
the system (not too many of these, if any at all -- hence my earlier
language suggesting that perhaps /opt/ shouldn't exist).  This also
raises the question, would "opt" be a fitting name for this directory?

2) /usr/opt/ would be for large, complex, non-vital packages that were
provided by the maintainers of the distribution.

3) /usr/local/opt/ would house large, complex packages added by the
local sysadmin.


>>   4) All special allowances for X11 need to be done away with.  It's
>>      just another program, but its current convoluted directory
>>      structure makes configuration and administration needlessly
>>      difficult.  Gathering up this monster's sprawling pieces and
>>      sticking them into /usr/opt/X11R6/ might not be a bad idea.
>
>Already done, isn't it? At least on my system everything for X11 lives
>under /usr/X11R6 except for the config files under /etc/X11.

True.  Most of X's problems lie in the scrambled internal structure of
the package.  But it still needs to be located in something like an
opt/ directory.  It just seems like having the X11R6 directory
directly under /usr/ is messy.


--Russell

============================================================
email (spam-disabled):
rdh *at* salug *dot* org

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

Date: Thu, 12 Oct 2000 01:15:47 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: LinuxThreads : problem with sigwait()

Oliver Kowalke wrote:
> 
> Hi,
> 
> I'm reading "Programming with POSIX Threads" from Butenhof. I have a problem
> with the function 'sigwait()'.
> 
> my program    :    creates a thread which waits on SIGINT. If SIGINT is 5
> times signaled it terminates.
> the problem    :    The program create 3 processes. Why? I've never called
> fork()!
> my system    :        Debian Linux 2.2
>                             glibc 2.1.3-10
> 
> Please, can you explain me the behaviour.
> 
> thx!
> 
> with regards,
> Oliver
Under linuxthreads, threads _are_ processes, created through
the system call clone() (of which fork is a special case),
which share the same address space (as opposed to the
copy-on-write behavior of fork).
The three processes you're seeing are the manager thread,
the initial thread and the new thread you've created using
pthread_create().

HTH,
--ag
> 
> ----> sigwait.c
> <---------------------------------------------------------------------------
> --------------------
> 
> #include <sys/types.h>
> #include <unistd.h>
> #include <pthread.h>
> #include <signal.h>
> #include "errors.h"
> 
> pthread_mutex_t  mutex = PTHREAD_MUTEX_INITIALIZER;
> pthread_cond_t  cond = PTHREAD_COND_INITIALIZER;
> int     interrupted = 0;
> sigset_t   signal_set;
> 
> /* Wait for the SIGINT signal. */
> void * signal_waiter( void * arg)
> {
>  int sig_number;
>  int signal_count = 0;
>  int status;
> 
>  while ( 1)
>  {
>   sigwait( & signal_set, & sig_number);
>   if ( sig_number == SIGINT)
>   {
>    printf("Got SIGINT (%d of 5)\n", signal_count + 1);
>    if ( ++signal_count >= 5)
>    {
>     status = pthread_mutex_lock( & mutex);
>     if ( status != 0)
>      err_abort( status, "Lock mutex");
>     interrupted = 1;
>     status = pthread_cond_signal( & cond);
>     if ( status != 0)
>      err_abort( status, "Signal condition");
>     status = pthread_mutex_unlock( & mutex);
>     if ( status != 0)
>      err_abort( status, "Unlock mutex");
>     break;
>    }
>   }
>   else
>    printf("Got othe signal.\n");
>  }
>  return NULL;
> }
> 
> int main( int argc, char * argv[])
> {
>  pthread_t  signal_thread_id;
>  int    status;
> 
>  sigemptyset( & signal_set);
>  sigaddset( & signal_set, SIGINT);
>  status = pthread_sigmask( SIG_BLOCK, & signal_set, NULL);
>  if ( status != 0)
>   err_abort( status, "Set signal mask");
> 
>  /* Create the sigwait thread. */
>  status = pthread_create( & signal_thread_id, NULL, signal_waiter, NULL);
>  if ( status != 0)
>   err_abort( status, "Create sigwaiter");
> 
>  /* Wait for the sigwait thread to receive SIGINT and signal the condition
> variable. */
>  status = pthread_mutex_lock( & mutex);
>  if ( status != 0)
>   err_abort( status, "Lock mutex");
>  while( !interrupted)
>  {
>   status = pthread_cond_wait( & cond, & mutex);
>   if ( status != 0)
>    err_abort( status, "Wait for interrupt");
>  }
>  status = pthread_mutex_unlock( & mutex);
>  if ( status != 0)
>   err_abort( status, "Unlock mutex");
>  printf("Main terminating with SIGINT\n");
>  return 0;
> }
> 
> --> errors.h
> <---------------------------------------------------------------------------
> ---
> 
> #ifndef __ERRORS_H
> #define __ERRORS_H
> 
> #include <unistd.h>
> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> 
> #ifdef DEBUG
> #define DPRINTF( arg) printf arg
> #else
> #define DPRINTF( arg)
> #endif
> 
> #define err_abort(code,text) \
> do \
> {  \
>  fprintf( stderr, "%s at \"%s\":%d: %s\n", text, __FILE__, __LINE__,
> strerror( code) ); \
>  abort(); \
> } while ( 0)
> #define errno_abort(text) \
> do \
> {  \
>  fprintf( stderr, "%s at \"%s\":%d: %s\n", text, __FILE__, __LINE__,
> strerror( errno) ); \
>  abort(); \
> } while ( 0) \
> 
> #endif // __ERRORS_H

-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"I'd sooner fly another combat mission than ride the Cyclone
again" -- Joseph Heller

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

From: Vivek Gupta <[EMAIL PROTECTED]>
Subject: Re: include file for printk()
Date: Wed, 11 Oct 2000 23:46:57 -0700

I guess you have to include linux/module.h

Vivek

Zhihui Zhang wrote:
> 
> When I compile a kernel module, it says:
> 
> warning: implicit declaration of function 'printk_R1b7d4074"
> 
> I guess I need to include some header file for this or what?  Thanks for
> your help.
> 
> -Zhihui



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

From: [EMAIL PROTECTED]
Subject: E2A4D600 Visio for Linux
Date: Thu,12 Oct 2000 02:32:06+2000

  Announcing complete new universal drafting program for Linux, FreeBSD, and Sun 
Solaris.

        LinuxCAD release for FreeBSD, a native FreeBSD build , not an emulation !!!

                     the details to be found on 

                         WWW.LINUXCAD.COM

   Now version 2.26 that has many added features is ready to ship and download.
      Useful for preparing any kind of visual diagramming presentation
        for any industry or knowledge field, creation of illustrations for books
      and reports.

     LinuxCAD is more Visual Language for Business then Microsoft Visio ever was !!!
  Initially introduced in 1995  LinuxCAD today is very powerful and rock stable 
application program for Linux.  

  The software comes with more than 1500
symbols that allows to use L i n u x C A D as a replacement for such diagramming
tool as Microsoft Visio. That is absolutely right LinuxCAD is more convenient then 
Visio
and can be used to replace Microsoft Power Point as well.
   LinuxCAD provides features of such programs as AutoCAD, Visio, Power Point 
and Corel Draw in a single program for Linux.
   linux cad can be used in:
       organizational charts ,
       business process diagramms,
       information network and computer system diagrams,
-->    software development flowcharting ,
-->    entity relationship diagramming,
       network planning,
       system administration diagramming and you actually can start
       your sysadmin tasks from inside linux cad,
-->    mechanical engineering drafting,
       pcb and schematic design ( easily integrated with routing programs ),
       geographicsl information systems,
       any kind of drafting where integration with database is important,
       floor plans for buildings and facilities,
-->    architectural drafting,
       front end for programmable rendering systems like opengl,
-->    front end for any software that may require graphics editor functions,
       can be used to replace acad in every application later is used !!!
       can be used to replace visio diagramming tool in every application later is 
used !!!
  This message posted in single instance and it is not a spam.
Software Forge Inc.
( developers of the most advanced application software for Linux OS ).
   847 891 5971

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

From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: utime(touch) gives EPERM - Bug in Linux???
Date: 12 Oct 2000 08:01:09 GMT

On 11 Oct 2000 17:55:45 GMT, Rick Ellis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Dr. Peer Griebel <[EMAIL PROTECTED]> wrote:
>
>>I just discovered that I can't successfully "touch" a file (I don't
>>own the file):
>>
>>      > ls -l myfile
>>      -rw-rw-rw-   1 ralph     users        123 Okt 10 13:46 myfile
>>        > touch myfile
>>      touch: myfile: operation not permitted
>>
>>As you can see the file has write permission (the directory also). But
>>the file belongs to somebody else - not me. This error occurs in
>>2.2.10, in 2.2.14 - but not in 2.0.36.
>
>You need write permission for the directory entry not the file itself.
>


Says who?  You need directory write permission to create and delete
files, not to modify the file itself, and that includes modifying
the atime and mtime.  Further test kernel 2.2.12:

If you have write permission you can set the mtime to current time
also if you don't own the file.  You can't however set the time to
a time different from the current time, unless you own the file.

Whether that is mandated by POSIX or other standard I have no idea.
Somone have the POSIX text available (or unix98)?



Villy

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

From: Chris Nott <[EMAIL PROTECTED]>
Subject: SMP problem: device driver for memory disk
Date: Thu, 12 Oct 2000 19:05:27 +1100

Hi,

We recently discovered a concurrency problem when we tried our driver in
an SMP system.  After a month of trying to track it down under the i386
and alpha smp kernels, we have come to the conclusion that the problem
may actually be a kernel bug that we are exposing. 

Our device is a high-speed memory card, which the device driver makes
look like a disk (with partition table support etc).  The device is
dma-driven and has no seek delays..  When we run a test program that
writes a file and then reads it back testing with a predetermined
pattern to test for errors, the program returns no errors (on UP and SMP
kernels).  When we run multiple versions of this program, one or more of
the processes eventually gets stuck on the open (if they are left
eventually all but one will "deadlock" - consuming cpu time but
unkillable).  Once one or more of the processes have "failed to
proceed", any attempt to sync will freeze as well.

We have managed to find that the place the program is failing is in
ext2_truncate, accessing one of the inode blocks (usually an indirect or
double-indirect).  All this (combined with some analysis using kdb, gdb
and some custom kernel debugging patches) leads us to believe that at
some point a buffer is getting "stuck", stopping the process that has
written it to fail next time it tries to open for write (truncating the
file).  It does not, however, stop other accesses to the device from
occuring (normally I would expect this to be a problem ending a request
and therefore tying up the devices request queue).

So, keeping in mind our device has 0 seek times and a maximum throughput
of 110mb/s (although we typically see sustained 35mb/s under linux,
which is less than other operating systems (freebsd: 65-110mb/s, aix: up
to 110mb/s)), is there any possibility of there being a subtle race
condition that might cause this?  My only suspicion at the moment is
that end_request is not completing correctly but appears to complete to
the driver.

This problem does not appear to happen when using memory-mapped i/o
instead of dma.  I have plenty more questions regarding how/why the
linux block device driver interface works the way it does.. :)

Thanks for any help you can provide,
Chris.

--
     Chris Nott
      Engineer
Virtual Logic PTY LTD
<http://www.vl.com.au>

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

From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: memory utilities
Date: Thu, 12 Oct 2000 10:39:53 +0200

Hi,

What do exactly mean by this,
Can't you just check /proc/memory and /proc/swaps

Richard.


Weiguang Shi wrote:

> Hi people,
>
> Which tool can I use to check the memory(physical&virtual) sizes under linux?
> If you have more tools to recommend to monitor/deal with memory,
> could you please let me know too?
>
> Thanks very much
> Weiguang


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

From: "Lee, Yunseung" <[EMAIL PROTECTED]>
Subject: Where can I get Library source files?
Date: Thu, 12 Oct 2000 20:31:00 +0900

Hi all...

I need to library source files.( eg libc.a )
Where can I get these library source files?
Thanks in advance.

- YS Lee



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

From: "Anil Prasad" <[EMAIL PROTECTED]>
Subject: Re: How to access a unexported kernel symbol ?
Date: 12 Oct 2000 11:41:28 GMT


>While writing a module, sometimes there is a need to access some kernel
> symbol that is not exported , it is, can not be found in /proc/ksyms.
> Say , the global variable : main_table .  Practically, it can be handled
> by directly accessing /dev/kmem. But, is there any other ways to do that
you can try get_module_symbol(NULL, "symbol name") if that symbol is
present in some module.


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

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Where can I get Library source files?
Date: Thu, 12 Oct 2000 14:39:32 +0200

"Lee, Yunseung" wrote:
> =

> Hi all...
> =

> I need to library source files.( eg libc.a )
> Where can I get these library source files?
> Thanks in advance.
> =

> - YS Lee

If your system is rpm-based:
        rpm -qf /usr/lib/libc.a
will tell you where the libc.a came from, then
        rpm -qi libc
will tell you that the source rpm is something like
        libc-2.1.2-25.src.rpm
This must either be included on the distribution CD or your distributor
should be able to tell you where it can be obtained.

-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
        If failure had no penalty success would not be a prize (T. Pratchett)

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

From: [EMAIL PROTECTED]
Subject: Trying to compile Nvidia drivers in a SMP system.
Date: Thu, 12 Oct 2000 12:36:10 GMT

Im trying to install Nvidia drivers into my linux 2.2.16-22 SMP kernel,
but there are no precompiled drivers for me since I use redhat 7. (rh
6.2 worked fine)
Anyhow Ive installed a src.rpm containing the nvidia drivers, and been
able to compile it correctly. But the problem shows up when I install
the newly created rpm. I get the following error:

=====================
[root@grumpy extensions]# insmod NVdriver
Using /lib/modules/2.2.16-22smp/video/NVdriver
/lib/modules/2.2.16-22smp/video/NVdriver: kernel-module version mismatch
/lib/modules/2.2.16-22smp/video/NVdriver was compiled for kernel version
2.2.16-22 while this kernel is version 2.2.16-22smp.
=====================

Then I got the advice to "make mrproper", setup the SMP support with
"make xconfig" (setting the SMP flag), then "make dep" to fix all
dependencies (?).
This should have solved the whole thing, BUT it still compiles for the
non-smp kernel, getting the same error above...

Could anyone shed some light on this problem, and how I can solve it ?

Any help is appreciated..
//Erik


Sent via Deja.com http://www.deja.com/
Before you buy.

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


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