#50 open() errno is not ENOENT on vxWorks 6.3 PowerPC

[Wes Eddy]

(using ION 3.1.3)

This is low priority, as there is a workaround and it only seems to impact vxWorks on PowerPC, from what I can tell.

The code looking for an ION configuration file around line 1570 of ici/library/ion.c depends on an expected ENOENT errno value set by the open call when trying to open a file that doesn't exist.

I haven't actually figured out why yet, but on vxWorks 6.3 on PPC604, the errno is set to something different (0xd40005) rather than ENOENT, which causes ionadmin to cease with the "can't open SDR config file" message. I believe it should simply allow defaults to apply in the case that any error value is returned by the open call (not just when you have an errno of ENOENT). In the "SIMLINUX" vxWorks simulator on x86, errno is set properly and everything works normally, so I don't quite know what's up with the system library on PowerPC.

The workaround for this problem is to always use an ION configuration file (even if it's just filled with default values), so it isn't serious.

[Scott Burleigh]

I see your point, Wes, but on reflection I'm not sure I agree that the current behavior is incorrect. The intent is to distinguish between user error (like misspelling the file name) and a possibly serious system error like insufficient kernel memory. If anything, I think I'd be inclined to go the other way: on any error at all, stop the initialization and tell the user something needs to be fixed -- interpret a NULL config file name as "use system defaults" (maybe interpret file name "." as "compose default config file name" as is currently done for NULL) and otherwise require that the named config file open successfully. Let's think about this some more before making a change.

[Wes Eddy]

That makes sense to me.

In my case, the "surprise" was that ION behaves differently on Linux
versus vxWorks due to specifically looking for ENOENT.

I agree with you that widening the error response to consistently
happen when the file can't be opened for any reason is a good idea.
This would be consistent across platforms, which is important.

On 9/11/2014 12:09 AM, Scott Burleigh wrote:

I see your point, Wes, but on reflection I'm not sure I agree that the
current behavior is incorrect. The intent is to distinguish between user
error (like misspelling the file name) and a possibly serious system
error like insufficient kernel memory. If anything, I think I'd be
inclined to go the other way: on any error at all, stop the
initialization and tell the user something needs to be fixed --
interpret a NULL config file name as "use system defaults" (maybe
interpret file name "." as "compose default config file name" as is
currently done for NULL) and otherwise require that the named config
file open successfully. Let's think about this some more before making a
change.

---

[bugs:#50] http://sourceforge.net/p/ion-dtn/bugs/50 open() errno is
not ENOENT on vxWorks 6.3 PowerPC

Status: open
Group: 3.2.1
Created: Tue Jul 29, 2014 05:50 PM UTC by Wes Eddy
Last Updated: Tue Jul 29, 2014 05:50 PM UTC
Owner: nobody

(using ION 3.1.3)

This is low priority, as there is a workaround and it only seems to
impact vxWorks on PowerPC, from what I can tell.

The code looking for an ION configuration file around line 1570 of
ici/library/ion.c depends on an expected ENOENT errno value set by the
open call when trying to open a file that doesn't exist.

I haven't actually figured out /why/ yet, but on vxWorks 6.3 on PPC604,
the errno is set to something different (0xd40005) rather than ENOENT,
which causes ionadmin to cease with the "can't open SDR config file"
message. I believe it should simply allow defaults to apply in the case
that any error value is returned by the open call (not just when you
have an errno of ENOENT). In the "SIMLINUX" vxWorks simulator on x86,
errno is set properly and everything works normally, so I don't quite
know what's up with the system library on PowerPC.

The workaround for this problem is to always use an ION configuration
file (even if it's just filled with default values), so it isn't serious.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/ion-dtn/bugs/50/
https://sourceforge.net/p/ion-dtn/bugs/50

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions

--
Wes Eddy
MTI Systems

[Scott Burleigh]

Okay, I think we have converged on this one. I'm posting a change set to the misc-v3.2.2 feature branch to implement the fix.