Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 31 Jul 2014 23:45:40 +0000 (UTC)
From: "Colin Patrick McCabe (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12434080.1251312517420.91374.1406850340966@arcas>
In-Reply-To: <JIRA.12434080.1251312517420@arcas>
References: <JIRA.12434080.1251312517420@arcas>
Subject: [jira] [Commented] (HDFS-573) Porting libhdfs to Windows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081689#comment-14081689 ] 

Colin Patrick McCabe commented on HDFS-573:
-------------------------------------------

bq. I have just one question though. My initial inclination was to put TYPE_CHECKED_PRINTF_FORMAT in platform.h as well. However, I then backed that out and put the ifdef in exception.h, because it has never been clear to me if exception.h is part of the public API

The only header file that's part of the public API is {{hdfs.h}}.  That's the only one we export to end-users... nobody can even get access to the other ones without a Hadoop source tree.  You should feel free to change, add, or remove things from any header file without worrying about compatibility, as long as that header is not {{hdfs.h}}.

bq. BTW Colin, thanks for the code review. The work so far has been aimed at a straight port, warts and all, but I'm happy to roll in a few more small fixes for existing problems while I'm in here. I'll work on a v2 of the patch.

Thanks, Chris.  I think what you've got looks pretty good... I wish all libhdfs patches could be this good :)

> Porting libhdfs to Windows
> --------------------------
>
>                 Key: HDFS-573
>                 URL: https://issues.apache.org/jira/browse/HDFS-573
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: libhdfs
>         Environment: Windows, Visual Studio 2008
>            Reporter: Ziliang Guo
>            Assignee: Chris Nauroth
>         Attachments: HDFS-573.1.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> The current C code in libhdfs is written using C99 conventions and also uses a few POSIX specific functions such as hcreate, hsearch, and pthread mutex locks.  To compile it using Visual Studio would require a conversion of the code in hdfsJniHelper.c and hdfs.c to C89 and replacement/reimplementation of the POSIX functions.  The code also uses the stdint.h header, which is not part of the original C89, but there exists what appears to be a BSD licensed reimplementation written to be compatible with MSVC floating around.  I have already done the other necessary conversions, as well as created a simplistic hash bucket for use with hcreate and hsearch and successfully built a DLL of libhdfs.  Further testing is needed to see if it is usable by other programs to actually access hdfs, which will likely happen in the next few weeks as the Condor Project continues with its file transfer work.
> In the process, I've removed a few what I believe are extraneous consts and also fixed an incorrect array initialization where someone was attempting to initialize with something like this: JavaVMOption options[noArgs]; where noArgs was being incremented in the code above.  This was in the hdfsJniHelper.c file, in the getJNIEnv function.


--
This message was sent by Atlassian JIRA
(v6.2#6252)