Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Chris Patterson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace 
deprecated readdir_r() with readdir()"):
> I'm far from the expert here, but it would appear that both NetBSD's
> and FreeBSD's libc readdir()/readdir_r() implementations are
> consistent in their locking mechanisms [1,2].  As such, I would expect
> readdir() to be equally as safe as readdir_r() for their users.  As
> you noted, there does not appear to be any documented distinction
> within their man pages [3,4] with regards to thread safety and it
> seems reasonable that they would have documented these limitations, if
> present.

Thanks for chasing up this breakage.  However, I think that:

1. This is a fundamentally wrong way to go about assessing the proper
way to use a supposedly-portable API.  The right way is to refer to
the published specification, in the first instance.  That published
specification says that readdir() is not threadsafe.

2. There may be good reasons to deviate from a formal specification.
Formal specifications can be wrong (for example, they can differ from
established practice, or unuseable, or incoherent).  But there has
been no discussion (at least in this thread on xen-devel) which might
suggest that the POSIX specification is wrongheaded here.

3. Perhaps the documentation accompanying, or discussion justifying,
the glibc readdir deprecation warning, will provide something
resembling what I discuss in (2).

4. I am not satisfied with an approach which enumerates all the
currently-supported dom0 operating systems.  These patches should be
accompanied by an explantion of a good reason to believe that all
operating systems we are likely to ever want to run on (or be able to
run on) will also provide a threadsafe readdir.

5. I am not opposed to replacing readdir_r with readdir in areas of
code which do not need the threadsafety properties.  (Eg, in xl.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel