Urgent: 5000 Euro Reward

bridged with qnx.rtos
NDT

programmatically mounting a SMB share

Post by NDT » Wed Sep 21, 2005 1:26 pm

Hi,

I'm trying to mount a remote Windows machine share onto a local
directory. I know how to do it on the command line, but it's hard to find
any documentation on how to do it inside a program (if it's possible at
all). I'm using QNX 6.3.

I suppose the mount() function doesn't work for this kind of thing,
because the first argument is a device to mount, and a Windows machine on
the network isn't really considered a device...?

Can anyone help ?

Pierre AUBERT

Re: programmatically mounting a SMB share

Post by Pierre AUBERT » Wed Sep 21, 2005 3:03 pm

Hi,

NDT wrote:
Hi,

I'm trying to mount a remote Windows machine share onto a local
directory. I know how to do it on the command line, but it's hard to find
any documentation on how to do it inside a program (if it's possible at
all). I'm using QNX 6.3.

I suppose the mount() function doesn't work for this kind of thing,
because the first argument is a device to mount, and a Windows machine on
the network isn't really considered a device...?



The mount function works :
if you want to mount the share "share" on the server "smbserver" using
the username "user"
with password "pass" on the directory /mnt/win :

mount ("//SMBSERVER:SMBSERVER:SHARE", "/mnt/win", 0, "cifs",
"user,pass", -1)
Can anyone help ?



Shashank

Re: programmatically mounting a SMB share

Post by Shashank » Wed Sep 21, 2005 3:05 pm

You can use the fs-cifs command to mount a windows diretory on to a QNX
directory.

fs-cifs -a hostname:/Windows_share_name /network username password

will mount the windows directory "Window_share_name" on to you local QNX
"/network" directory.

Within your program, build this command into an array and invoke it using
the "popen" function.

Shashank




"NDT" <noreply@noreply.org> wrote in message
news:dgrmt0$t8p$1@inn.qnx.com...
Hi,

I'm trying to mount a remote Windows machine share onto a local
directory. I know how to do it on the command line, but it's hard to find
any documentation on how to do it inside a program (if it's possible at
all). I'm using QNX 6.3.

I suppose the mount() function doesn't work for this kind of thing,
because the first argument is a device to mount, and a Windows machine on
the network isn't really considered a device...?

Can anyone help ?

Pierre AUBERT

Re: programmatically mounting a SMB share

Post by Pierre AUBERT » Wed Sep 21, 2005 3:43 pm

Pierre AUBERT wrote:
Hi,

NDT wrote:

Hi,

I'm trying to mount a remote Windows machine share onto a local
directory. I know how to do it on the command line, but it's hard to
find
any documentation on how to do it inside a program (if it's possible at
all). I'm using QNX 6.3.

I suppose the mount() function doesn't work for this kind of thing,
because the first argument is a device to mount, and a Windows
machine on
the network isn't really considered a device...?



The mount function works :
if you want to mount the share "share" on the server "smbserver" using
the username "user"
with password "pass" on the directory /mnt/win :

mount ("//SMBSERVER:SMBSERVER:SHARE", "/mnt/win", 0, "cifs",
"user,pass", -1)
Sorry for the little mistake, the mount call must be (don't forget the
'/' in the share name) :
mount ("//SMBSERVER:SMBSERVER:/SHARE", "/mnt/win", 0, "cifs",
"user,pass", -1);
Can anyone help ?



Shashank

Re: Photon Application priority

Post by Shashank » Mon Mar 20, 2006 2:48 pm

Hello,

We have a few photon applications running in the foreground and our servo
running in the background. When, we increase the priority of our servo,
photon really slows down. I would like to increase the priority of photon. I
tried increasing the priority of the photon window manager"pwm" but it made
no difference. Which process controls the photon apps?

I would apprecaite your input.

Thanks,
Shashank

John Nagle

Re: Photon Application priority

Post by John Nagle » Tue Mar 21, 2006 7:00 pm

Shashank wrote:
Hello,

We have a few photon applications running in the foreground and our servo
running in the background. When, we increase the priority of our servo,
photon really slows down. I would like to increase the priority of photon. I
tried increasing the priority of the photon window manager"pwm" but it made
no difference. Which process controls the photon apps?

I would apprecaite your input.

Thanks,
Shashank
Sounds like you have a more fundamental problem. When just
the servo program is running, what's the CPU load?

John Nagle

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Ryan J. Allen

Re: process name vs. file name

Post by Ryan J. Allen » Mon Apr 10, 2006 8:28 pm

ysw wrote:
Yes, I do use the usemsg, and also ldrel to place my own QNX_info
section. As soon as I disable them the .note section is filled with
01.01. I can even delete the this section after I call usemsg and
ldrel. Actually, it is fine with me if any information is plased
there. What wonders me is why that data is taken as a process name.
Ultimately this is not the expected behavior. I have filed a PR for this.

I've noticed that the problem happens when using ldrel. usemsg, by
default, uses ldrel to insert the use message into the binary. By
supplying the -o argument to usemsg you can force it to use objcopy.
This is the make project (with qconfig.mk, qtargets.mk, and etc.) on
self-hosted Neutrino (6.3.0 SP2) platform.
If usemsg -o is an acceptable workaround for you you can insert the
following into your common.mk to have the build system invoke usemsg
with the -o parameter:

UM_HOST = $(QNX_HOST)/usr/bin/usemsg -o
UM_nto_x86_wcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_x86_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_mips_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_ppc_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_sh_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE
UM_nto_arm_gcc = $(UM_HOST) -s __USAGENTO -s __USAGE

Regards,

--
Ryan J. Allen
ryallen@qnx.com

Post Reply

Return to “qnx.rtos”