apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From генерал Пурпоз <kb2...@gmail.com>
Subject Re[2]: Porting APR to QNX4: portability problems.
Date Mon, 29 Jan 2007 23:21:05 GMT
Hello William,

Monday, January 29, 2007, 11:19:58 PM, you wrote:
> Yes - apr and apr-util are designed for modern operating systems.  We had
> deliberately chosen not to provide full interoperability with legacy OS
> and micro-OS's.  There are a number of portability solutions out there,
> what distinguishes APR is (we hope) it's usefulness at authoring server
> daemons and other applications that demand modern features.
An embedded systems may be interested in APR's features as well.

> OpenSSL is already being leveraged on our development trunk and in
> the coming 1.3.x versions
Does this mean, for example, that SVN would not need the "neon"

> WOOT!  I'm glad to hear this; there are many factors in modern applications
> which demand huge-integer representation (apr_time_t, for example).
I've ported the GMP v4.2.1 (it's early version v2.0.2 was bundled with
the ssh-1.2.33 to handle all the BigNum crunching), that's the perfect
example of truely portable code!
If I were to look for huge-integer representation I'd chosen GMP for
that. (I'm sorry - I begin to rant again! :) )

>> it would be great to be able to send
>>  "svn checkout URL@REV //other-node-ID/path/to/a/working/dir"...
> Well, this isn't actually a flaw since you can't accomplish this (moving
> from box X to box Y and anticipating a proper representation.  C:/ isn't
> represented as //thisbox/local-C-share either.)
I believe I must look into it.

The main feature of QNX (both generations of that OS, v4 and v6) is
the native networking capability. QNX4's networking is called FLEET,
QNX6's is QNET, both are non-IP.

It is well possible to 'open("//5/path/to/a/file",...)' from any other
node. Since it is transparent - the above svn trick should come for
free (on QNXes), I believe.

>> In the light of the above - if I get the fullpath of local resource
>> I'll return "/foo" but if I get non-local "//node-ID/foo" - should I
>> keep it as is?
>> //0/foo =========== /foo
>> //my-node-ID/foo == /foo
>> //other-node/foo == //other-node/foo

> I wouldn't want to reduce the second case, we don't do that on any other
> platform.

> But I'd DEFINITELY agree //0/ should be reduced to /.  //0/ They are
> identical, and / is easier to write.  In fact, Win32 should probably learn
> to reduce //?/C:/ to C:/ if we aren't doing that now (we may be doing so.)
Thinking about it more I start feeling the better way would be exacly
the opposite:
/foo =============== //node-ID/foo
//0/foo ============ //node-ID/foo
//node-ID/foo ====== //node-ID/foo
//other-node/foo === //other-node/foo
This would straighten things up (a user may input whatever he wishes
and get the valid result on *ANY* node). At some point it could evolve
into the APR_HAS_FLEET and APR_HAS_QNET features. Then the APR-based
QNX applications would use their native capabilities for all
non-IP-reachable resources (instead of the '//file:/bla/bla').

Please comment.

I've done some tests here, the 'qnx_fullpath()' is very powerfull
stuff. It resolves even through the symlinks.
If I have '/bin/sh' a symlink to '/bin/ksh', the full path of
'/bin/sh' is reported as '//node-ID/bin/ksh'.

It handles inputs like the '../../bla/bla' nicely as well. The
'qnx_fullpath()''s output is unique and unambigiuos whithin all the
networked QNX boxen. (Each box has unique node-ID whithin a given
FLEET|QNET network of an enterprize.)

So, to summarize, regarding the above '/bin/sh':
- the root must be '//node-ID/'
- the path must be 'bin/' - without the leading slash, with the
  trailing one
The same regarding the '/' and all it's variants:
- the root must be '//node-ID/'
- the path must be NULL
Is this understanding correct?

As a sidenote: can someone give me the textual description of each
test in the "filenames.c" suite?
Thank you in advance.

Best regards,
 Anthony               mailto:kb2wjw@gmail.com

View raw message