sys_sem* undefined

sys_sem* undefined

[Arne Henrichsen]

Hi,

I am running kernel 2.6.8 and have noticed that in
linux/sem.h the function declarations for sys_semop,
sys_semop etc have been removed (as far as I can see
from 2.6.4 onwards). Now when I compile my code I get
the sys_sem* undefined warning messages. Which header
file do I need to include now to get this support? 

Also when I want to load my module with insmod it
cannot find these symbols.

Thanks for the help.
Arne


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: sys_sem* undefined

[Randy.Dunlap]

On Wed, 25 Aug 2004 12:50:20 +0100 (BST) Arne Henrichsen wrote:

| Hi,
| 
| I am running kernel 2.6.8 and have noticed that in
| linux/sem.h the function declarations for sys_semop,
| sys_semop etc have been removed (as far as I can see
| from 2.6.4 onwards). Now when I compile my code I get
| the sys_sem* undefined warning messages. Which header
| file do I need to include now to get this support? 

grep(1) finds sys_semop here:

./linux/syscalls.h:446:asmlinkage long sys_semop(int semid, struct sembuf __user
 *sops,

Yes, include/linux/syscalls.h contains syscall prototypes.


| Also when I want to load my module with insmod it
| cannot find these symbols.

syscalls aren't called by name, so that's no surprise.


--
~Randy

Re: sys_sem* undefined

[Arne Henrichsen]

Hi Randy,

thanks for the help. I am very new to Linux
programming, and I do not understand what you mean
with  'syscalls are not called by name'. 

I did find the header file syscalls.h, recompiled my
code but it still says the following:

*** Warning: "sys_semop"
[/prj/builds/host/linux/prj.ko] undefined!
*** Warning: "sys_semctl"
[/prj/builds/host/linux/prj.ko] undefined!
*** Warning: "sys_semget"
[/prj/builds/host/linux/prj.ko] undefined!

And when I load the module, then it tells me:

insmod: error inserting './prj.ko': -1 Unknown symbol
in module

So, I call sys_sem* functions from my code. What else
must I do?

Thanks again.
Arne
  


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: sys_sem* undefined

[Arne Henrichsen]

Hi,

I realise now that one obviously calls these functions
via system calls. Ok, I have never done that before in
Linux. This is probably not the correct group to ask
this, but where is there a good place to start? Maybe
with a simple example on how to do system calls in
Linux?

Thanks
Arne
  


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: sys_sem* undefined

[Paulo Marques]

Arne Henrichsen wrote:
> Hi Randy,
> 
> thanks for the help. I am very new to Linux
> programming, and I do not understand what you mean
> with  'syscalls are not called by name'. 
> 
> I did find the header file syscalls.h, recompiled my
> code but it still says the following:
> 
> *** Warning: "sys_semop"
> [/prj/builds/host/linux/prj.ko] undefined!
> *** Warning: "sys_semctl"
> [/prj/builds/host/linux/prj.ko] undefined!
> *** Warning: "sys_semget"
> [/prj/builds/host/linux/prj.ko] undefined!
> 
> And when I load the module, then it tells me:
> 
> insmod: error inserting './prj.ko': -1 Unknown symbol
> in module
> 
> So, I call sys_sem* functions from my code. What else
> must I do?

Syscalls are supposed to be called from userspace, so that the kernel 
does something on behalf of an application.

Some syscalls have their do_<syscall name> equivalent because it makes 
sense to call them from inside the kernel, but others don't.

If you want to use semaphores inside the kernel I suggest you read the 
Rusty Rusell's Unreliable Guide to Kernel Locking first:

http://wwwos.inf.tu-dresden.de/~ch12/diplom/DocBook/kernel-locking/

I hope this helps,

-- 
Paulo Marques - www.grupopie.com

Re: sys_sem* undefined

[Randy.Dunlap]

On Thu, 26 Aug 2004 14:44:03 +0100 (BST) Arne Henrichsen wrote:

| Hi,
| 
| I realise now that one obviously calls these functions
| via system calls. Ok, I have never done that before in
| Linux. This is probably not the correct group to ask
| this, but where is there a good place to start? Maybe
| with a simple example on how to do system calls in
| Linux?

>From an application (userspace) or from inside the kernel?

There are many "howto add a system call to Linux" web pages
out there (use google).  Oh, you want "howto do a system call."

>From userspace, usually use a library:  app calls library
function, which does the syscall.  Or you can roll your
own syscalls.  The howtos on adding a system call to Linux
usually show you how to do that part also.[1]

--
~Randy

[1] written for 2.4.18:
http://www.xenotime.net/linux/syscall_ex/howto_adda_syscall.txt

Re: sys_sem* undefined

[Arne Henrichsen]

> From an application (userspace) or from inside the
> kernel?

I need to do the syscalls from kernel space. Basically
I am porting our custom vxWorks driver to Linux. We
want to basically keep the structure of the vxWorks
driver the same, so I am porting the individual
vxWorks functions such as semBcreate, semGive etc.
Thats why I want to use the SysV IPC semaphores, as
they seem to most closely resemble the vxWorks ones. I
know that there are much better ways of writing a
driver, but that wouldn't fit in with the currect
structure we have at the moment.

Now if I want to call lets say sys_semget() from
kernel space, must I use the _syscall3() function? I
saw some people using this. 

Thanks for the help.
Arne


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: sys_sem* undefined

[Pete]

Arne Henrichsen wrote:

>>From an application (userspace) or from inside the
>>kernel?
>>    
>>
>
>I need to do the syscalls from kernel space. Basically
>I am porting our custom vxWorks driver to Linux. We
>want to basically keep the structure of the vxWorks
>driver the same, so I am porting the individual
>vxWorks functions such as semBcreate, semGive etc.
>Thats why I want to use the SysV IPC semaphores, as
>they seem to most closely resemble the vxWorks ones. I
>know that there are much better ways of writing a
>driver, but that wouldn't fit in with the currect
>structure we have at the moment.
>
>Now if I want to call lets say sys_semget() from
>kernel space, must I use the _syscall3() function? I
>saw some people using this. 
>
>Thanks for the help.
>Arne
>
>
>	
>  
>
Speaking as someone who has traveled down this road previously, I would 
suggest that you re-engineer your driver instead of going with your 
current plan. I realize that you think this would be quicker and easier, 
but the maintenance headaches are pretty heavy as you get further into 
this. Doing a driver the "right" way to fit the kernel makes sense 
because it becomes very easy to maintain, whereas your method will 
require much more work for changes to kernel versions, or changes to 
core logic. I'm guessing the driver is pretty mature at this point, but 
you still live with maintaining with the kernel.

As a side note, there are a lot of things that you might assume should 
be a driver because that's sort of how it works in the VxWorks system, 
but may map just as well to userspace, or some combo of userspace and 
kernel space. Essentially, all software in VxWorks is part of the 
kernel, so it's easy to just assume that what you are doing must be in 
the kernel as well. Again, I've been working on a project for 5+ years 
that was 3+ years of VxWorks, and is now migrating to Linux. I had to go 
through a lot of this stuff as well.

Basically, I'm saying that there are better ways to do what you want to 
do, but it's gonna involve some more up front work for you. I'd be 
willing to chat more about this if you feel the urge off the list.

Pete Buelow