Howdy. Whilst playing with the Nto 2.11 beta release for QNX4 (you know, that
developer thingie), I ran into an “undocumented feature” (potential bug) with
mkifs. It seems that if you try to make entries in your build file that point
to a startup file in your current directory instead of wherever mkifs normally
wants to look for such files (/usr/nto/x86/lib or /x86/boot/sys for QNX4 or RtP
respectively), it produces an unusable startup module. For example, here’s my
build file:
sh=fesh
devc-ser8250
stty
pidin
ls
----------- end of ifs.build -------------
If you change the second line from “startup-enc” to
“startup-enc=./startup-enc”, startup_vaddr in the header changes from 0x3C58
(which works fine) to 0x26998 (which reboots when jumped to in the IPL). mkifs
doesn’t complain about anything either way, it’s just that one way works, and
the other way causes you to swear a lot. Behavior is identical (but off by
8 bytes) for the QNX4 hosted development environment, as well as mkifs on RtP.
Even if there’s literature somewhere that says “Don’t do that”, it would be
nice if mkifs would complain to you about relative pathnames or something.
I think you’re confusing the format of the bootfile with the format of the
buildfile - the bootfile (between the braces) doesn’t support the
‘targname=hostname’ format. When you entered ‘startup-enc=./startup-enc’,
all you were doing was setting an environment variable. I’ll leave this to
you to verify but just entering ‘./startup-enc’ SHOULD do the trick. If it
doesn’t, then we have a bug and I’ll have to fix it…
Howdy. Whilst playing with the Nto 2.11 beta release for QNX4 (you know, that
developer thingie), I ran into an “undocumented feature” (potential bug) with
mkifs. It seems that if you try to make entries in your build file that point
to a startup file in your current directory instead of wherever mkifs normally
wants to look for such files (/usr/nto/x86/lib or /x86/boot/sys for QNX4 or RtP
respectively), it produces an unusable startup module. For example, here’s my
build file:
sh=fesh
devc-ser8250
stty
pidin
ls
----------- end of ifs.build -------------
If you change the second line from “startup-enc” to
“startup-enc=./startup-enc”, startup_vaddr in the header changes from 0x3C58
(which works fine) to 0x26998 (which reboots when jumped to in the IPL). mkifs
doesn’t complain about anything either way, it’s just that one way works, and
the other way causes you to swear a lot. > > Behavior is identical (but off by
8 bytes) for the QNX4 hosted development environment, as well as mkifs on RtP.
Even if there’s literature somewhere that says “Don’t do that”, it would be
nice if mkifs would complain to you about relative pathnames or something.
-Warren
–
Kris Warkentin kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
You are correct, sir. It thought I wanted an envirovar. How about an extra
warning for slightly dain bramaged people like me that says something like:
“You idiot! You didn’t specify a dang startup module!”? Of course you could
change the phraseology as you see fit…
I think you’re confusing the format of the bootfile with the format of the
buildfile - the bootfile (between the braces) doesn’t support the
‘targname=hostname’ format. When you entered ‘startup-enc=./startup-enc’,
all you were doing was setting an environment variable. I’ll leave this
to
you to verify but just entering ‘./startup-enc’ SHOULD do the trick. If
it
doesn’t, then we have a bug and I’ll have to fix it…>
Regards,
Kris
Warren Peece <> warren@nospam.com> > wrote:
Howdy. Whilst playing with the Nto 2.11 beta release for QNX4 (you
know, that
developer thingie), I ran into an “undocumented feature” (potential bug)
with
mkifs. It seems that if you try to make entries in your build file that
point
to a startup file in your current directory instead of wherever mkifs
normally
wants to look for such files (/usr/nto/x86/lib or /x86/boot/sys for QNX4
or RtP
respectively), it produces an unusable startup module. For example,
here’s my
build file:
sh=fesh
devc-ser8250
stty
pidin
ls
----------- end of ifs.build -------------
If you change the second line from “startup-enc” to
“startup-enc=./startup-enc”, startup_vaddr in the header changes from
0x3C58
(which works fine) to 0x26998 (which reboots when jumped to in the IPL).
mkifs
doesn’t complain about anything either way, it’s just that one way
works, and
the other way causes you to swear a lot. > > Behavior is identical (but
off by
8 bytes) for the QNX4 hosted development environment, as well as mkifs
on RtP.
Even if there’s literature somewhere that says “Don’t do that”, it would
be
nice if mkifs would complain to you about relative pathnames or
something.
-Warren
\
Kris Warkentin kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
You are correct, sir. It thought I wanted an envirovar. How about an extra
warning for slightly dain bramaged people like me that says something like:
“You idiot! You didn’t specify a dang startup module!”? Of course you could
change the phraseology as you see fit…
I think you’re confusing the format of the bootfile with the format of the
buildfile - the bootfile (between the braces) doesn’t support the
‘targname=hostname’ format. When you entered ‘startup-enc=./startup-enc’,
all you were doing was setting an environment variable. I’ll leave this
to
you to verify but just entering ‘./startup-enc’ SHOULD do the trick. If
it
doesn’t, then we have a bug and I’ll have to fix it…>
Regards,
Kris
Warren Peece <> warren@nospam.com> > wrote:
Howdy. Whilst playing with the Nto 2.11 beta release for QNX4 (you
know, that
developer thingie), I ran into an “undocumented feature” (potential bug)
with
mkifs. It seems that if you try to make entries in your build file that
point
to a startup file in your current directory instead of wherever mkifs
normally
wants to look for such files (/usr/nto/x86/lib or /x86/boot/sys for QNX4
or RtP
respectively), it produces an unusable startup module. For example,
here’s my
build file:
sh=fesh
devc-ser8250
stty
pidin
ls
----------- end of ifs.build -------------
If you change the second line from “startup-enc” to
“startup-enc=./startup-enc”, startup_vaddr in the header changes from
0x3C58
(which works fine) to 0x26998 (which reboots when jumped to in the IPL).
mkifs
doesn’t complain about anything either way, it’s just that one way
works, and
the other way causes you to swear a lot. > > Behavior is identical (but
off by
8 bytes) for the QNX4 hosted development environment, as well as mkifs
on RtP.
Even if there’s literature somewhere that says “Don’t do that”, it would
be
nice if mkifs would complain to you about relative pathnames or
something.
-Warren
\
Kris Warkentin kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
–
Kris Warkentin kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
You are correct, sir. It thought I wanted an envirovar. How about an extra
warning for slightly dain bramaged people like me that says something like:
“You idiot! You didn’t specify a dang startup module!”? Of course you could
change the phraseology as you see fit…
Ah, but you did specify a startup module - procnto. It wasn’t the right
one of course, but mkifs didn’t know that.
C’mon guys. It can’t be that difficult to write a piece of software
that’s smarter than I am… Make it do what I want it to do, not what I
tell it to do.
Warren Peece <> Warren@nospam.com> > wrote:
You are correct, sir. It thought I wanted an envirovar. How about an
extra
warning for slightly dain bramaged people like me that says something
like:
“You idiot! You didn’t specify a dang startup module!”? Of course you
could
change the phraseology as you see fit…
Ah, but you did specify a startup module - procnto. It wasn’t the right
one of course, but mkifs didn’t know that.
C’mon guys. It can’t be that difficult to write a piece of software
that’s smarter than I am… Make it do what I want it to do, not what I
tell it to do. >
Something along the lines of the DWIMNDWIS shell? ;v)
<cburgess@qnx.com> wrote in message news:8vktv9$rtj$2@nntp.qnx.com…
| Warren Peece <Warren@nospam.com> wrote:
| > C’mon guys. It can’t be that difficult to write a piece of software
| > that’s smarter than I am… Make it do what I want it to do, not what I
| > tell it to do.
|
| Something along the lines of the DWIMNDWIS shell? ;v)
Exact-a-mundo. When we reach the point where I can just lay my hands upon my
monitor and just think about what I want the computer to do, then I’ll be
happy.
| Something along the lines of the DWIMNDWIS shell? ;v)
Exact-a-mundo. When we reach the point where I can just lay my hands upon my
monitor and just think about what I want the computer to do, then I’ll be
happy. >
That could be dangerous. Maybe there should always be a confirmation?
“Are you sure want me to kill Bob? All lifeforce will lost? (y/n)”
| Something along the lines of the DWIMNDWIS shell? ;v)
Exact-a-mundo. When we reach the point where I can just lay my hands
upon my
monitor and just think about what I want the computer to do, then I’ll
be
happy. >
That could be dangerous. Maybe there should always be a confirmation?
“Are you sure want me to kill Bob? All lifeforce will lost? (y/n)”
I like to prophesize the next step in evolution is a human with a build-in
serial port.
“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:8vmbf4$o1o$1@nntp.qnx.com…
|
|
| <cburgess@qnx.com> wrote in message news:8vm8ms$mh6$1@nntp.qnx.com…
| > > | Something along the lines of the DWIMNDWIS shell? ;v)
| >
| > > Exact-a-mundo. When we reach the point where I can just lay my hands
| upon my
| > > monitor and just think about what I want the computer to do, then I’ll
| be
| > > happy.
| >
| > That could be dangerous. Maybe there should always be a confirmation?
| >
| > “Are you sure want me to kill Bob? All lifeforce will lost? (y/n)”
| >
|
| I like to prophesize the next step in evolution is a human with a build-in
| serial port.
Get with the times Mario, it’s gonna be Fibre Channel!
| I like to prophesize the next step in evolution is a human with a
build-in
| serial port.
Get with the times Mario, it’s gonna be Fibre Channel!
Wrong again. It’ll be wireless of some sort. .-<;v0
Actually God sent me an image that I can’t put any words on.
The device doesn’t yet exists, it doesn’t have a name.
I use “serial port” as a methaphor for lack of better word.
The device will be based on “beyond light speed” particle.
Behavior is identical (but off by
