Implement Functionality Currently Missing in dup

[Wei Shen]

Hi Joel,

Thanks for your reply.

On 3/24/08, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
> Look at the psxfile01 test.  I think that's the one that has some specific
> test cases which do not work.  It could be IMFS specific or in the ioctl.
> My recollection is that there no attempt to "dupe" the file state.


psxfile01 does not test dup. I found some tests in psx13, but seems that all
of them succeed.

>From the source code, I found three places in the dup implementation that do
not strictly follow POSIX.
(1) I still think store file open file description separately from the
fd_array is a must. POSIX requires two FDs after dup share the same open
file description, and attributes like read/write positions, locks, etc.
except for the close-on-exec flag.

(2) fcntl with F_DUPFD should try to find "a new file descriptor which shall
be the lowest numbered available (that is, not already open) file descriptor
greater than or equal to the third argument". Currently, RTEMS'
implementation does check whether the 3rd argument is an available FD.

(3) Seems that, the free FD list is not correctly implemented, so dup can
not find a lowest available FD as required by POSIX.

Am I right? Any other missing functionality to fix?

You might also want to look at Asynchronous IO and List IO functions.  They
> are in the same area and should be interesting.  Probably not much more
> than
> having a server task interact with the requests those functions make.


I would like to, but then it would be difficult for me to finish the GSoC
proposal on time. I have planned to work out a proposal draft today, but it
already seems difficult now for the unclarity of the dup task. If you do not
require me to finish analysis on the problems but just list it as a goal in
the proposal, I can make up them after the submission due.

Regards,
Wei Shen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080324/83844cc7/attachment-0001.html>