Linux-Development-Sys Digest #20, Volume #8      Thu, 13 Jul 00 21:13:15 EDT

Contents:
  Question on SysV  Semaphores (Damonaxl)
  Re: URGENT: NFS Mount RedHat 6.2 from Solaris ([EMAIL PROTECTED])
  Re: Version Control (J.H.M. Dassen (Ray))
  Re: sizeof() in gcc (John Gluck)
  linking error (Danny Tran)
  Re: sizeof() in gcc (John Gluck)
  Re: LINUX SMP (John Gluck)
  Re: Version Control (Bill Waddington)
  mpeg capture from video capture card (Thierry)
  Play mpeg without Xwindows (Thierry)
  Re: Problems with modules on 2.2.13 [SMP] (Chris J/#6)
  MIT threads - where? (Myke Morgan)
  can't see the kernel calls ("Peter Huang")
  Problem with gcc ... ("Keiichi")
  Re: When We will use the static library ? (Todd Knarr)

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

From: Damonaxl <[EMAIL PROTECTED]>
Subject: Question on SysV  Semaphores
Date: Fri, 14 Jul 2000 02:35:42 +0800

Is there anyone know how to write a non-blocking semaphores function?
I read the book written by Steven R (Unix Network Programming 2) that
there exist a non-blocking semaphores.  I found the code of that
try_wait function.
But i can't use it, it only give error.
Does anybody know why?

#include "semaphore.h"

int sem_trywait(sem_t *sem)
{
 struct sembuf op;

 if (sem->sem_magic != SEM_MAGIC) {
  errno = EINVAL;
  return(-1);
 }

 op.sem_num = 0;
 op.sem_op = -1;
 op.sem_flg = IPC_NOWAIT;
 if (semop(sem->sem_semid, &op, 1) < 0)
  return(-1);
 return(0);
}



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

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking,alt.linux,linux.redhat
Subject: Re: URGENT: NFS Mount RedHat 6.2 from Solaris
Date: Thu, 13 Jul 2000 18:55:03 GMT

We had problems too, because in Redhat 6.1 the man pages have
not been updated to match the new NFS system.

We are mounting from a Solaris 2.5.1 box (eek) and the 'insecure'
flags you mention below were not necessary.  However, we added
'no_root_squash' so we could back up the linux NFS server by logging
into the sun, mounting the Linux filesystems, and using the sun's tape
drive.

We had to stop/start NFS after changing /etc/exports.
Maybe this is no longer necessary.

In article <[EMAIL PROTECTED]>,
  "Barry P. Evans" <[EMAIL PROTECTED]> wrote:
>
> Well we got it working!
> We applied some patches (actually VA Linux did that for us) and then
> we added the following options to the sun boxen in /etc/exports file:
>    (rw,insecure,insecure_locks)
> and now the Sun boxes mount our Linux nfs drives!

> Now for some fine tuning of the speed parameters.  I'm told that using
> rsize=8192,wsize=8129 in our mount options may lead to some
spectacular
> increases in speed...  We'll soon see!

Please tell us whether this helped.
cheers -- Rick
--
Rick Leir
Pelyco Systems
rleir at pelyco dot ca replace at and dot


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

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

From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: Version Control
Date: Wed, 12 Jul 2000 22:35:54 +0200

Grant Edwards <[EMAIL PROTECTED]> wrote:
>In article <8kie76$uhi$[EMAIL PROTECTED]>, Bill Waddington wrote:
>>Can someone point me at a software version control utility/reference?
 
>RCS or CVS.

They're the most popular, but hardly the only ones, nor even the only free
ones. Think of Aegis and PRCS.

But as Kaz already pointed out, this is more appropriate in
comp.software.config-mgmt. Followup set.
-- 
Ray Dassen <[EMAIL PROTECTED]>

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

From: John Gluck <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Thu, 13 Jul 2000 14:54:40 -0400

Norm Dresner wrote:

> I'm getting a "parse error" on the (simplified) line
>     #if    ( sizeof(int) ) != 4
>
> Is this really illegal?

Yes

>
>
> Is there any other way to do size comparisons in the pre-processor?
>
>     Norm

Check the limits.h file...
It should give you enough info to determine the number of bytes for an
int and most anything else as well.


--
John Gluck  (Passport Kernel Design Group)

(613) 765-8392  ESN 395-8392

Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.




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

From: Danny Tran <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: linking error
Date: Thu, 13 Jul 2000 12:04:20 -0700

Hi  I'm using RedHat 6.2 for the x86.  I'm using a linker script which
is just the default script with some extra sections added.  The default
script is elf_i386.  I've made no changes for the elf program headers.
The documentation states the program headers should be handled
automatically.

The flags used to link
ld
  -m elf_i386 \
   -lc \
  -lm \
  -lpthread \
   -warn-section-align \
  -warn-common \
  -warn-constructors \
  -t \
  --verbose


The error:
/usr/bin/ld: warning: changing start of section .note.ABI-tag by 1 bytes

/usr/bin/ld: warning: changing start of section .gnu.version by 1 bytes
/usr/bin/ld: warning: changing start of section stbbram by 4 bytes
/usr/bin/ld: warning: changing start of section .plt by 1 bytes
/usr/bin/ld: warning: changing start of section .text by 12 bytes
/usr/bin/ld: warning: changing start of section .rodata by 10 bytes
/usr/bin/ld: warning: changing start of section .bss by 28 bytes
/usr/bin/ld: warning: changing start of section .nocache by 24 bytes
/usr/bin/ld: emerald.elf: Not enough room for program headers (allocated
6, need 7)
/usr/bin/ld: final link failed: Bad value

Any thoughts?

Thanks
-Danny


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

From: John Gluck <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Thu, 13 Jul 2000 15:06:59 -0400

Villy Kruse wrote:

> On Mon, 10 Jul 2000 16:37:15 GMT, Norm Dresner <[EMAIL PROTECTED]> wrote:
> >I'm getting a "parse error" on the (simplified) line
> >    #if    ( sizeof(int) ) != 4
> >
> >Is this really illegal?
> >
> >Is there any other way to do size comparisons in the pre-processor?
> >
> >    Norm
> >
> >
>
> You can write it as a proper C conditional statement.  Any decent compiler
> will recognize the condition is always false/true, whatever the case may
> be and eliminate the dead code.
>
>  if ( sizeof(int) != 4 ) {
>         alternative one;
>  } else {
>         alternative two;
>  }
>
> Read "decent compiler" as one that does eliminate dead code.
>
> Villy

That solution only works well if theres on or 2 spots you're trying to
include or not include code.
One should also not rely on the quality of a compiler where possible...

There is this nifty file called "limits.h" which is architecture and OS
dependant.
It contains all sorts of useful things like for example a define for INT_MAX
The file was specifically designed to keep people from turning into
contortonists to do very simple things

--
John Gluck  (Passport Kernel Design Group)

(613) 765-8392  ESN 395-8392

Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.




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

From: John Gluck <[EMAIL PROTECTED]>
Subject: Re: LINUX SMP
Date: Thu, 13 Jul 2000 15:16:18 -0400

Bob Davis wrote:

> Any good references on how Linux distributes processes to processors?
> Thanks,
> Bob

The source code.
Try these links

http://metalab.unc.edu/linux-source/
http://lxr.linux.no/

--
John Gluck  (Passport Kernel Design Group)

(613) 765-8392  ESN 395-8392

Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.




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

From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Re: Version Control
Date: Thu, 13 Jul 2000 20:45:06 GMT

Thanks To All,

Sorry about the off-topic post.  Man, there must be an NG for
everything!

Bill

--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

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

From: Thierry <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.hardware
Subject: mpeg capture from video capture card
Date: Thu, 13 Jul 2000 13:50:43 -0700

Hi,

Do you know an existing program (with sources) wich capture video from a
video capture card (bt chips) and save it in mpeg or quicktime format.
Without using Xwindows.

Thanks a lot.

thierry


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

From: Thierry <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Play mpeg without Xwindows
Date: Thu, 13 Jul 2000 13:52:57 -0700

Hi,

Is it possible to play a movie (mpeg or quicktime) without using Xwindows,
only in Shell screen.

Maybe using frame buffer ?

Thanks a lot for your help.

thierry



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

From: [EMAIL PROTECTED] (Chris J/#6)
Crossposted-To: comp.os.linux.misc
Subject: Re: Problems with modules on 2.2.13 [SMP]
Reply-To: [EMAIL PROTECTED]
Date: 13 Jul 2000 22:18:35 +0100

Paul Kimoto <[EMAIL PROTECTED]> wrote:
>
>Could this be a problem with CONFIG_MODVERSIONS?  (However, I thought that
>then the symbols usually looked more mangled ...)
>
>-- 
>Paul Kimoto

Well, I found the problem and it was partly down to RedHat doing things to
the Makefile, and me for not actually what RedHat had done to the makefile.

I'm used to nice, simple, clean, non-vendor-hacked source trees, so after 
building a kernel, muggins 'ere copied System.map quite innocently into
/boot.

After getting bored one day at work, about three weeks after I'd done this,
and a couple of days after being bored again so revisiting the problem and
from there posting the original post (with me here? :) I found that the 
kernel *wasn't* loading the symbols in System.map, but rather, annoyingly
enough, was loading the symbols from System.map-2.2.13-0.13.

Anyhow...after much cursing of Redhat, and the decision that there was no
way I was going to try and config a system that puts silly suffixes(*) 
on the end of files, I grabbed a clean 2.2.14 (I use 2.2.14 at home, I know
it works...2.2.15 and higher I've not touched yet), and built that.

No more mangled files with mangled names. Huzzah! :)

To return to your point though, regarding CONFIG_MODVERSIONS, I had all
versioning info switched on, and insmod/modprove is more prone to say something
akin to "Module built for kernel x.y.z" where x.y.z does not match 2.2.13 (or
2.2.14, now)...and refuses to load the module (trust me on this - I have a
binary-only module for a network card, and can I get linux to install it?
Can I hell ... 2.2.5 uni-processor binary doesn't want to go into a 2.2.14 SMP
system. Not really that suprised its not working :) Thankfully, the vendor
provided a generic modified tulip driver source, and together with a channel
bonding patch, I can get round the fact the module isn't working). 

So now all is good, stuff is froody, and the machine is working nicely. :)

Chris...

(*) the silly suffixes may be a controversial point here - but when you've
been playing with linux for 5 years, and never touched a vendor-kernel, the
last thing you expect(+) is for them to modify how the damn thing makes...

(+) well, I suppose if you research correctly, you'll be prepared for this
problem and get round it...but I do find it an annoyance.

-- 
@}-,'--------------------------------------------------  Chris Johnson --'-{@
    / "(it is) crucial that we learn the difference / [EMAIL PROTECTED]  \
   / between Sex and Gender. Therein lies the key  /                       \ 
  / to our freedom" -- LB                         / www.nccnet.co.uk/~sixie \ 

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

From: [EMAIL PROTECTED] (Myke Morgan)
Subject: MIT threads - where?
Date: 13 Jul 2000 21:46:53 GMT

Someone suggested to me to try the MIT threads package. From what I 
was told, this is a user space threading system which won't create a new 
cloned process for every thread.

I did a web search but only found a broken link at the MIT site. Can
anyone help me out with a location for this package? I'm using RedHat 6.2 
if that's helpfull.

--
I proclaim you, FOUR!


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

From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: can't see the kernel calls
Date: Thu, 13 Jul 2000 14:53:12 -0700


I tried to load the driver using "/sbin/insmod -f pcitest.o" and it is
telling me that it can't see
the kernel function calls. However, I check the include files and I make
sure that I included
all the files that I need. Does any one have any quick knowledge of the
problem.

The kernel calls such as printk can't can't be resolved. I included all the
correct header files


Peter





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

From: "Keiichi" <[EMAIL PROTECTED]>
Subject: Problem with gcc ...
Date: Thu, 13 Jul 2000 23:22:22 +0200

Hi

    I'm writing a kernel module and I have a problem with gcc (version
2.95.2). If i try to compile my module with :

   $ gcc -O6 -Wall -DCONFIG_KERNELD -DMODULE \
      -D__KERNEL__ -DLINUX -I/usr/linux/ -c -o ./object/main.o \
     ./src/main.c

all works fine, but if i try to use :

   $ gcc -O6 -Wall -DCONFIG_KERNELD -DMODULE \
      -D__KERNEL__ -DLINUX -c -o ./object/main.o \
     ./src/main.c

i get the followings errors :

In file included from /usr/include/linux/sched.h:13,
                 from /usr/include/linux/mm.h:4,
                 from /usr/include/linux/slab.h:14,
                 from /usr/include/linux/malloc.h:4,
                 from /usr/include/linux/proc_fs.h:5,
                 from ./src/main.c:47:
/usr/include/linux/times.h:5: parse error before `clock_t'
/usr/include/linux/times.h:5: warning: no semicolon at end of struct or
union
/usr/include/linux/times.h:6: warning: data definition has no type or
storage class
/usr/include/linux/times.h:7: parse error before `tms_cutime'
/usr/include/linux/times.h:7: warning: data definition has no type or
storage class
/usr/include/linux/times.h:8: parse error before `tms_cstime'
/usr/include/linux/times.h:8: warning: data definition has no type or
storage class
In file included from /usr/include/linux/timex.h:142,
                 from /usr/include/linux/sched.h:14,
                 from /usr/include/linux/mm.h:4,
                 from /usr/include/linux/slab.h:14,
                 from /usr/include/linux/malloc.h:4,
                 from /usr/include/linux/proc_fs.h:5,
                 from ./src/main.c:47:
/usr/include/linux/time.h:10: parse error before `time_t'
/usr/include/linux/time.h:10: warning: no semicolon at end of struct or
union
/usr/include/linux/time.h:12: parse error before `}'
/usr/include/linux/time.h: In function `timespec_to_jiffies':
/usr/include/linux/time.h:32: dereferencing pointer to incomplete type
/usr/include/linux/time.h:33: dereferencing pointer to incomplete type
/usr/include/linux/time.h: In function `jiffies_to_timespec':
/usr/include/linux/time.h:45: dereferencing pointer to incomplete type
/usr/include/linux/time.h:46: dereferencing pointer to incomplete type
/usr/include/linux/time.h: At top level:
/usr/include/linux/time.h:50: parse error before `time_t'
/usr/include/linux/time.h:50: warning: no semicolon at end of struct or
union
/usr/include/linux/time.h:51: warning: data definition has no type or
storage class
/usr/include/linux/time.h:83: field `it_interval' has incomplete type
/usr/include/linux/time.h:84: field `it_value' has incomplete type
/usr/include/linux/time.h:88: field `it_interval' has incomplete type
/usr/include/linux/time.h:89: field `it_value' has incomplete type
In file included from /usr/include/linux/sched.h:14,
                 from /usr/include/linux/mm.h:4,
                 from /usr/include/linux/slab.h:14,
                 from /usr/include/linux/malloc.h:4,
                 from /usr/include/linux/proc_fs.h:5,
                 from ./src/main.c:47:
/usr/include/linux/timex.h:163: field `time' has incomplete type
In file included from /usr/include/linux/fs.h:266,
                 from /usr/include/linux/tty.h:20,
                 from /usr/include/linux/sched.h:21,
                 from /usr/include/linux/mm.h:4,
                 from /usr/include/linux/slab.h:14,
                 from /usr/include/linux/malloc.h:4,
                 from /usr/include/linux/proc_fs.h:5,
                 from ./src/main.c:47:
/usr/include/linux/hpfs_fs_i.h:5: parse error before `ino_t'
/usr/include/linux/hpfs_fs_i.h:5: warning: no semicolon at end of struct or
union
/usr/include/linux/hpfs_fs_i.h:12: parse error before `:'
In file included from /usr/include/linux/fs.h:268,
                 from /usr/include/linux/tty.h:20,
                 from /usr/include/linux/sched.h:21,
                 from /usr/include/linux/mm.h:4,
                 from /usr/include/linux/slab.h:14,
                 from /usr/include/linux/malloc.h:4,
                 from /usr/include/linux/proc_fs.h:5,
                 from ./src/main.c:47:
/usr/include/linux/msdos_fs_i.h:36: parse error before `off_t'
/usr/include/linux/msdos_fs_i.h:36: warning: no semicolon at end of struct
or union
In file included from /usr/include/linux/fs.h:269,
                 from /usr/include/linux/tty.h:20,
                 from /usr/include/linux/sched.h:21,
                 from /usr/include/linux/mm.h:4,
                 from /usr/include/linux/slab.h:14,
                 from /usr/include/linux/malloc.h:4,
                 from /usr/include/linux/proc_fs.h:5,
                 from ./src/main.c:47:
/usr/include/linux/umsdos_fs_i.h:62: field `msdos_info' has incomplete type
/usr/include/linux/umsdos_fs_i.h:69: parse error before `off_t'
/usr/include/linux/umsdos_fs_i.h:69: warning: no semicolon at end of struct
or union
/usr/include/linux/umsdos_fs_i.h:73: parse error before `}'
....

<snip : very long ... >

    I don't understand. Why does it work with the '-I/usr/include' option
and fails withou it ? I though it wasn't necessary because /usr/include is a
common location for the '#include' directive files ...

    Am i wrong ?

    My code is (with very strong snippages ...) :

#include <linux/kernel.h>
#include <linux/module.h>

#if CONFIG_MODVERSIONS==1
#define MODVERSIONS
#include <linux/modversions.h>
#endif

#include <linux/proc_fs.h>
#include <linux/ioport.h>
#include <asm/segment.h>
#include <asm/io.h>

// <snip>
// i have defined some constants, functions and variables ...

int init_module()
{
  int erreur;
  if((erreur = check_region(BASE, NB_PORTS)))
    return erreur;
  request_region(BASE, NB_PORTS, NAME);
  if((erreur = proc_register(&autocom, &ports_entry)))
    return erreur;
  if((erreur = proc_register(&autocom, &rncs_entry)))
    return erreur;
  if((erreur = proc_register(&proc_root, &autocom)))
    return erreur;
  if ((erreur = request_irq(IRQ, interrupt_handler, 0, NAME, NULL)))
    return erreur;
  return 0;
}

void cleanup_module()
{
  free_irq(IRQ, NULL);
  release_region(BASE, NB_PORTS);
  proc_unregister(&proc_root, autocom.low_ino);
}


Bye

--
Sylvain DEFRESNE (alias Keiichi)




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

From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: When We will use the static library ?
Date: 14 Jul 2000 00:35:34 GMT

In comp.os.linux.development.system <8kjtc6$va7$[EMAIL PROTECTED]> 
[EMAIL PROTECTED] wrote:
> Under the /usr/lib there are many *.a and they are very big :-(
> Are they useful? What kind of situation we will use them,
> Can I kill all of them? I had been move them to other place,

The .a libraries are only used when linking object modules to produce
an executable. During the link phase, the actual contents of the static
library modules needed will be pulled into the executable itself. If
you don't build your own programs that link against those libraries,
chances are you won't need the static versions at all. You'll notice
in package-management systems that libxyzzy.so will be included in the
xyzzy package, but libxyzzy.a will be in the xyzzy-devel package along
with header files and such because it's only needed for development.

The main use for static libraries is in building static executables: ones
with _all_ of the library code included in the executable itself so they
don't depend on any system libraries at all. This is useful for basic
utilities like the shell, cp, e2fsck, ldconfig and such, so that you
can still boot and run basic programs _after_ you have just completely
trashed libc.so and none of your normal programs linked against the
shared-object version of the libraries will run. You shouldn't use the
static-linked versions normally, but having them will save your butt
when you have to recover from a severely hosed system.

-- 
I'm a science officer. It's my job to have a better idea.
                                -- Dax

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


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