Implement Functionality Currently Missing in dup

Joel Sherrill joel.sherrill at OARcorp.com
Mon Mar 24 15:31:26 UTC 2008


Wei Shen wrote:
> Hi Joel,
>  
> Thanks for your reply.
>  
> On 3/24/08, *Joel Sherrill* <joel.sherrill at oarcorp.com 
> <mailto: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.
>  
This sounds reasonable BUT...

At this point, I would have to read the opengroup.org description of the
services and probably look at the GNU/Linux  and *BSD implementations
to be sure.  AND..

The GSOC timeline allows for a familiarization period which could
be used to nail the solution and design.
> (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.
>  
Sounds like a missing error check.
> (3) Seems that, the free FD list is not correctly implemented, so dup 
> can not find a lowest available FD as required by POSIX.
>  
>
I am not sure about this statement.  POSIX generally does not require 
specifics
like this to be depended upon by the program.  This is the opengroup.org
page for dup() and I do not see a requirement for > file descriptor

http://www.opengroup.org/onlinepubs/009695399/functions/dup.html

But the fcntl() page does state that..

http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html

I think this is strange but the behavior required is implementable
by scanning the array of file descriptors malloc'ed at program startup.

But the requirement to share locks DOES seem to imply the need for
an array of file descriptor pointers to underlying file descriptor
structures.

Can someone else take a read on this? It is a pretty big difference in
implementation based upon just a phrase in a 1000 page standard. :)

I think the answer is to propose that you will implement missing
dup(), dup2(), and fcntl(XXX) functionality as specified by POSIX
and opengroup.org.  Then site the URLs for the appropriate pages.
This doesn't commit you to any specific implementation decisions
and is in keeping with a "proposal."
> Am I right? Any other missing functionality to fix?
>
The person who wrote that code is sick. :(

But psx13 has a note in the screen that dup does not deal properly
with the flags.  I do not know if this comment is still correct or not.

I think it is safe to say you will add missing functionality and
make it POSIX compliant.
>
>     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.
>  
Part of writing a good proposal in real life is leaving wiggle room to
pick the correct solution. If you knew the answer, you wouldn't have
work to do. :-D 

Don't fret over these. 


--joel
> Regards,
> Wei Shen


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985





More information about the users mailing list