|
Mario Charest
01/09/2009 2:42 PM
post19783
|
Is the SPAWN_PADDR64_SAFE flag pass down the children?
We do on -P pterm xxx and it seems the program xxx is not allow to run above 4G.
|
|
|
|
|
|
Adam Mallory
01/09/2009 4:00 PM
post19791
|
The flag isn't inherited in further spawns. This is to avoid unintended
consequences such as trying to figure out why some task/driver is
failing randomly due to large spawn chains or accidental environment
inheritance.
The exception would be if you fork(). The address space attributes are
copied since there is really no other way to do it.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Friday, January 09, 2009 2:42 PM
> To: ostech-core_os
> Subject: SPAWN_PADDR64_SAFE
>
>
> Is the SPAWN_PADDR64_SAFE flag pass down the children?
>
> We do on -P pterm xxx and it seems the program xxx is not allow to run
> above 4G.
>
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19783
|
|
|
|
|
|
Mario Charest
01/11/2009 5:15 PM
post19815
|
Maybe a propagate type of flag then?
Because it makes think like on -P sh ...., or on -P pterm program messy to use
we have to change all our script to "on -P pterm program" to "on pterm on -P program" which isn't so bad unless you do
a sin and see all the on running.
________________________________________
From: Adam Mallory [community-noreply@qnx.com]
Sent: Friday, January 09, 2009 4:00 PM
To: ostech-core_os
Subject: RE: SPAWN_PADDR64_SAFE
The flag isn't inherited in further spawns. This is to avoid unintended
consequences such as trying to figure out why some task/driver is
failing randomly due to large spawn chains or accidental environment
inheritance.
The exception would be if you fork(). The address space attributes are
copied since there is really no other way to do it.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Friday, January 09, 2009 2:42 PM
> To: ostech-core_os
> Subject: SPAWN_PADDR64_SAFE
>
>
> Is the SPAWN_PADDR64_SAFE flag pass down the children?
>
> We do on -P pterm xxx and it seems the program xxx is not allow to run
> above 4G.
>
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19783
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post19791
|
|
|
|
|
|
Adam Mallory
01/12/2009 9:55 AM
post19843
|
Another spawn flag? Ugh, I don't thing we'll want to do that. Once a
flag is in place we'll have to support it forever and they aren't
infinite in number available anyways.
In this scenario, I would suggest writing a custom launcher for your app
and then spawning that launcher to ensure the flag is set properly no
matter how the spawn chain you have setup occurs.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Sunday, January 11, 2009 5:16 PM
> To: ostech-core_os
> Subject: RE: SPAWN_PADDR64_SAFE
>
> Maybe a propagate type of flag then?
>
> Because it makes think like on -P sh ...., or on -P pterm program
messy
> to use
> we have to change all our script to "on -P pterm program" to "on
pterm on
> -P program" which isn't so bad unless you do a sin and see all the on
> running.
>
> ________________________________________
> From: Adam Mallory [community-noreply@qnx.com]
> Sent: Friday, January 09, 2009 4:00 PM
> To: ostech-core_os
> Subject: RE: SPAWN_PADDR64_SAFE
>
> The flag isn't inherited in further spawns. This is to avoid
unintended
> consequences such as trying to figure out why some task/driver is
> failing randomly due to large spawn chains or accidental environment
> inheritance.
>
> The exception would be if you fork(). The address space attributes
are
> copied since there is really no other way to do it.
>
> --
> Cheers,
> Adam
>
> QNX Software Systems
> [ amallory@qnx.com ]
> ---------------------------------------------------
> With a PC, I always felt limited by the software available.
> On Unix, I am limited only by my knowledge.
> --Peter J. Schoenster
>
> > -----Original Message-----
> > From: Mario Charest [mailto:community-noreply@qnx.com]
> > Sent: Friday, January 09, 2009 2:42 PM
> > To: ostech-core_os
> > Subject: SPAWN_PADDR64_SAFE
> >
> >
> > Is the SPAWN_PADDR64_SAFE flag pass down the children?
> >
> > We do on -P pterm xxx and it seems the program xxx is not allow to
run
> > above 4G.
> >
> >
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19783
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19791
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19815
|
|
|
|
|
|
Mario Charest
01/12/2009 10:21 AM
post19847
|
> -----Original Message-----
> From: Adam Mallory [mailto:community-noreply@qnx.com]
> Sent: January-12-09 9:55 AM
> To: ostech-core_os
> Subject: RE: SPAWN_PADDR64_SAFE
>
> Another spawn flag? Ugh, I don't thing we'll want to do that. Once a
> flag is in place we'll have to support it forever and they aren't
> infinite in number available anyways.
>
> In this scenario, I would suggest writing a custom launcher for your
> app
> and then spawning that launcher to ensure the flag is set properly no
> matter how the spawn chain you have setup occurs.
Not sure what you mean by launcher?
>
>
> --
> Cheers,
> Adam
>
> QNX Software Systems
> [ amallory@qnx.com ]
> ---------------------------------------------------
> With a PC, I always felt limited by the software available.
> On Unix, I am limited only by my knowledge.
> --Peter J. Schoenster
> > -----Original Message-----
> > From: Mario Charest [mailto:community-noreply@qnx.com]
> > Sent: Sunday, January 11, 2009 5:16 PM
> > To: ostech-core_os
> > Subject: RE: SPAWN_PADDR64_SAFE
> >
> > Maybe a propagate type of flag then?
> >
> > Because it makes think like on -P sh ...., or on -P pterm program
> messy
> > to use
> > we have to change all our script to "on -P pterm program" to "on
> pterm on
> > -P program" which isn't so bad unless you do a sin and see all the
> on
> > running.
> >
> > ________________________________________
> > From: Adam Mallory [community-noreply@qnx.com]
> > Sent: Friday, January 09, 2009 4:00 PM
> > To: ostech-core_os
> > Subject: RE: SPAWN_PADDR64_SAFE
> >
> > The flag isn't inherited in further spawns. This is to avoid
> unintended
> > consequences such as trying to figure out why some task/driver is
> > failing randomly due to large spawn chains or accidental environment
> > inheritance.
> >
> > The exception would be if you fork(). The address space attributes
> are
> > copied since there is really no other way to do it.
> >
> > --
> > Cheers,
> > Adam
> >
> > QNX Software Systems
> > [ amallory@qnx.com ]
> > ---------------------------------------------------
> > With a PC, I always felt limited by the software available.
> > On Unix, I am limited only by my knowledge.
> > --Peter J. Schoenster
> >
> > > -----Original Message-----
> > > From: Mario Charest [mailto:community-noreply@qnx.com]
> > > Sent: Friday, January 09, 2009 2:42 PM
> > > To: ostech-core_os
> > > Subject: SPAWN_PADDR64_SAFE
> > >
> > >
> > > Is the SPAWN_PADDR64_SAFE flag pass down the children?
> > >
> > > We do on -P pterm xxx and it seems the program xxx is not allow to
> run
> > > above 4G.
> > >
> > >
> > >
> > > _______________________________________________
> > > OSTech
> > > http://community.qnx.com/sf/go/post19783
> >
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19791
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19815
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19843
>
|
|
|
|
|
|
Adam Mallory
01/12/2009 11:21 AM
post19865
|
> Not sure what you mean by launcher?
A custom application that spawns the app with the flags you wish.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
>
> >
> >
> > --
> > Cheers,
> > Adam
> >
> > QNX Software Systems
> > [ amallory@qnx.com ]
> > ---------------------------------------------------
> > With a PC, I always felt limited by the software available.
> > On Unix, I am limited only by my knowledge.
> > --Peter J. Schoenster
> > > -----Original Message-----
> > > From: Mario Charest [mailto:community-noreply@qnx.com]
> > > Sent: Sunday, January 11, 2009 5:16 PM
> > > To: ostech-core_os
> > > Subject: RE: SPAWN_PADDR64_SAFE
> > >
> > > Maybe a propagate type of flag then?
> > >
> > > Because it makes think like on -P sh ...., or on -P pterm program
> > messy
> > > to use
> > > we have to change all our script to "on -P pterm program" to "on
> > pterm on
> > > -P program" which isn't so bad unless you do a sin and see all the
> > on
> > > running.
> > >
> > > ________________________________________
> > > From: Adam Mallory [community-noreply@qnx.com]
> > > Sent: Friday, January 09, 2009 4:00 PM
> > > To: ostech-core_os
> > > Subject: RE: SPAWN_PADDR64_SAFE
> > >
> > > The flag isn't inherited in further spawns. This is to avoid
> > unintended
> > > consequences such as trying to figure out why some task/driver is
> > > failing randomly due to large spawn chains or accidental
environment
> > > inheritance.
> > >
> > > The exception would be if you fork(). The address space
attributes
> > are
> > > copied since there is really no other way to do it.
> > >
> > > --
> > > Cheers,
> > > Adam
> > >
> > > QNX Software Systems
> > > [ amallory@qnx.com ]
> > > ---------------------------------------------------
> > > With a PC, I always felt limited by the software available.
> > > On Unix, I am limited only by my knowledge.
> > > --Peter J. Schoenster
> > >
> > > > -----Original Message-----
> > > > From: Mario Charest [mailto:community-noreply@qnx.com]
> > > > Sent: Friday, January 09, 2009 2:42 PM
> > > > To: ostech-core_os
> > > > Subject: SPAWN_PADDR64_SAFE
> > > >
> > > >
> > > > Is the SPAWN_PADDR64_SAFE flag pass down the children?
> > > >
> > > > We do on -P pterm xxx and it seems the program xxx is not allow
to
> > run
> > > > above 4G.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > OSTech
> > > > http://community.qnx.com/sf/go/post19783
> > >
> > >
> > > _______________________________________________
> > > OSTech
> > > http://community.qnx.com/sf/go/post19791
> > >
> > > _______________________________________________
> > > OSTech
> > > http://community.qnx.com/sf/go/post19815
> >
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post19843
> >
>
>
>...
|
|
|
|
|
|
Mario Charest
01/12/2009 11:23 AM
post19867
|
> -----Original Message-----
> From: Adam Mallory [mailto:community-noreply@qnx.com]
> Sent: January-12-09 11:21 AM
> To: ostech-core_os
> Subject: RE: SPAWN_PADDR64_SAFE
>
> > Not sure what you mean by launcher?
>
> A custom application that spawns the app with the flags you wish.
>
How would that be different than using "on -P". A custom launcher would solve the pterm <program> case.
>
> --
> Cheers,
> Adam
>
> QNX Software Systems
> [ amallory@qnx.com ]
> ---------------------------------------------------
> With a PC, I always felt limited by the software available.
> On Unix, I am limited only by my knowledge.
> --Peter J. Schoenster
>
> >
> > >
> > >
> > > --
> > > Cheers,
> > > Adam
> > >
> > > QNX Software Systems
> > > [ amallory@qnx.com ]
> > > ---------------------------------------------------
> > > With a PC, I always felt limited by the software available.
> > > On Unix, I am limited only by my knowledge.
> > > --Peter J. Schoenster
> > > > -----Original Message-----
> > > > From: Mario Charest [mailto:community-noreply@qnx.com]
> > > > Sent: Sunday, January 11, 2009 5:16 PM
> > > > To: ostech-core_os
> > > > Subject: RE: SPAWN_PADDR64_SAFE
> > > >
> > > > Maybe a propagate type of flag then?
> > > >
> > > > Because it makes think like on -P sh ...., or on -P pterm
> program
> > > messy
> > > > to use
> > > > we have to change all our script to "on -P pterm program" to "on
> > > pterm on
> > > > -P program" which isn't so bad unless you do a sin and see all
> the
> > > on
> > > > running.
> > > >
> > > > ________________________________________
> > > > From: Adam Mallory [community-noreply@qnx.com]
> > > > Sent: Friday, January 09, 2009 4:00 PM
> > > > To: ostech-core_os
> > > > Subject: RE: SPAWN_PADDR64_SAFE
> > > >
> > > > The flag isn't inherited in further spawns. This is to avoid
> > > unintended
> > > > consequences such as trying to figure out why some task/driver is
> > > > failing randomly due to large spawn chains or accidental
> environment
> > > > inheritance.
> > > >
> > > > The exception would be if you fork(). The address space
> attributes
> > > are
> > > > copied since there is really no other way to do it.
> > > >
> > > > --
> > > > Cheers,
> > > > Adam
> > > >
> > > > QNX Software Systems
> > > > [ amallory@qnx.com ]
> > > > ---------------------------------------------------
> > > > With a PC, I always felt limited by the software available.
> > > > On Unix, I am limited only by my knowledge.
> > > > --Peter J. Schoenster
> > > >
> > > > > -----Original Message-----
> > > > > From: Mario Charest [mailto:community-noreply@qnx.com]
> > > > > Sent: Friday, January 09, 2009 2:42 PM
> > > > > To: ostech-core_os
> > > > > Subject: SPAWN_PADDR64_SAFE
> > > > >
> > > > >
> > > > > Is the SPAWN_PADDR64_SAFE flag pass down the children?
> > > > >
> > > > > We do on -P pterm xxx and it seems the program xxx is not allow
> to
> > > run
> > >...
|
|
|
|
|
|
Adam Mallory
01/12/2009 11:31 AM
post19870
|
> How would that be different than using "on -P". A custom launcher
would
> solve the pterm <program> case.
It's different because you would use on (no -P) to spawn the pterm with
the command of spawning the launcher instead of trying to inherit the
attribute down the chain.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
|
|
|
|
|
|
Mario Charest
01/12/2009 11:39 AM
post19876
|
> -----Original Message-----
> From: Adam Mallory [mailto:community-noreply@qnx.com]
> Sent: January-12-09 11:32 AM
> To: ostech-core_os
> Subject: RE: SPAWN_PADDR64_SAFE
>
> > How would that be different than using "on -P". A custom launcher
> would
> > solve the pterm <program> case.
>
> It's different because you would use on (no -P) to spawn the pterm with
> the command of spawning the launcher instead of trying to inherit the
> attribute down the chain.
Our biggest system starts about 50 pterms. That solution doesn`t really apply.
>
> --
> Cheers,
> Adam
>
> QNX Software Systems
> [ amallory@qnx.com ]
> ---------------------------------------------------
> With a PC, I always felt limited by the software available.
> On Unix, I am limited only by my knowledge.
> --Peter J. Schoenster
>
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post19870
>
|
|
|
|
|
|
Adam Mallory
01/12/2009 1:28 PM
post19892
|
> Our biggest system starts about 50 pterms. That solution doesn`t
really
> apply.
I'm not sure why not; it's work sure but nothing too difficult. If you
feel that strongly about it, you are welcome to submit a feature request
of course.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
|
|
|
|
|
|
Mario Charest
01/12/2009 1:44 PM
post19894
|
> -----Original Message-----
> From: Adam Mallory [mailto:community-noreply@qnx.com]
> Sent: January-12-09 1:29 PM
> To: ostech-core_os
> Subject: RE: SPAWN_PADDR64_SAFE
>
>
> > Our biggest system starts about 50 pterms. That solution doesn`t
> really apply.
>
> I'm not sure why not;
It`s the same thing as doing "on -n<node> pterm on -P <program>" which is what we had to do and that's messy.
> it's work sure but nothing too difficult. If you
> feel that strongly about it, you are welcome to submit a feature
> request of course.
Nah, I'm mainly trying to make the point that usage of over 4Gig of address space is not user-friendly. I trust that you
have given much thought about this but it's my personal option the SPAWN_PADDR64_SAFE flag should be somehow
inheritable.
Mario out ;-)
|
|
|
|
|
|
Adam Mallory
01/12/2009 2:07 PM
post19897
|
> Nah, I'm mainly trying to make the point that usage of over 4Gig of
> address space is not user-friendly. I trust that you have given much
> thought about this but it's my personal option the SPAWN_PADDR64_SAFE
flag
> should be somehow inheritable.
Well, it was more of a compromise of not breaking existing software,
allowing them to optionally exploit the larger memory without changing
code (ie. launcher) and not creating a configuration nightmare by
allowing inheritance or too much transparency since failure could go
undetected for long times.
All of that while doing the extension in a way that allowed a much
easier integration for customers compared to the methods used by Windows
(ie. AWE) and other Oss with memory mapped file games.
I don't disagree with you on a purely technical level - more tweaking
ability can't be bad. The pragmatic side of me thinks that I'd rather
err on the side of correct but reserved behaviour versus maximum memory
usage and some hard to detect and debug errors that can masquerade as
data corruption, crashed OS etc. That's just me though.
Initially I thought marking the binaries themselves would have been much
better. The problem was that due to a variety of reasons the time line
was tight and quite limited where changes could be made when I got
involved. Perhaps re-examining that would be more fruitful than adding
yet another flag to an already complicated and well abused API. ;)
Thanks for the feedback though! While we may not agree, it's certainly
always appreciated.
--
Cheers,
Adam
QNX Software Systems
[ amallory@qnx.com ]
---------------------------------------------------
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
|
|
|
|
|
|
