rados_dll: A Windows port of librados

rados_dll: A Windows port of librados

[Alistair Israel]

Hi, ceph.

We are pleased to announce our first milestone in bringing Ceph to the
Windows platform, by porting librados into rados.dll.

https://github.com/AcalephStorage/rados_dll

Many thanks to dketor@gmail.com and the ceph-dokan project for
providing the springboard and early consultation with which we were
able to embark upon this course (we've also forked ceph-dokan and are
looking to be active contributors to that project).

### Overview

  * rados_dll is built using mingw, like ceph-dokan
  * Currently, it builds rados.dll, used by rados_client.exe
  * rados.dll provides the librados C API (linking C++ using .DLLs is
problematic)
  * rados_client.exe follows example code here
(http://ceph.com/docs/master/rados/api/librados-intro/) to drive
rados.dll, connect to a Ceph cluster and perform I/O
  * LGLP v2.1

### Details

Currently, rados_dll is built, similar to ceph-dokan, from source
files copied over from ceph/src and with _WIN32 specific
modifications. It is built using gcc, and uses winsock.

### Next steps

We've had to disable cephx authentication for now, obviously we need
to get this ported and working properly.

Currently, the build environment has to be carefully prepared by hand.
We're looking to add scripts to help ease and automate that process.

We're looking to streamline merging of changes from 'upstream' ceph.
First, we intend to remove unmodified source files from the src/
directory and use upstream ceph/src directly.

Next, we're looking to use tools (e.g. diff/patch, sed) to the apply
_WIN32 specific modifications in an automated manner whenever possible
to generate _WIN32 sources.

We hope to gain enough traction and credibility to contribute _WIN32
specific sections (with appropriate guards) to ceph core code.
Eventually, hopefully, we might be able to build rados.dll (along with
other Ceph components that can be ported to Windows) directly from a
single set of source files.

Finally, our Makefile is hand-written (as with ceph-dokan), and we
welcome any help to be able to standardise on using the autotools
toolchain to automate that as well (or integrate with upstream).

### Roadmap

We're looking at tackling RBD soon, and provide a native, Windows
system-level block device backed by Ceph. ;)

We welcome any and all comments, suggestions, and support.

### Who we are

Acaleph is a small startup headquartered in Singapore, but operating mostly from
the Philippines, and we provide Ceph deployment, integration, support
and other services.

Julio Telan is a graduating student from De La Salle University
spending his internship at Acaleph, mentored by yours truly.

Cheers!

Alistair A. Israel, alistair@acale.ph
Julio Telan, julio_telan@dlsu.edu.ph

Re: rados_dll: A Windows port of librados

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

Hi,

On 19/03/2015 06:35, Alistair Israel wrote:
> Hi, ceph.
> 
> We are pleased to announce our first milestone in bringing Ceph to the
> Windows platform, by porting librados into rados.dll.
> 
> https://github.com/AcalephStorage/rados_dll
> 
> Many thanks to dketor@gmail.com and the ceph-dokan project for
> providing the springboard and early consultation with which we were
> able to embark upon this course (we've also forked ceph-dokan and are
> looking to be active contributors to that project).
> 
> ### Overview
> 
>   * rados_dll is built using mingw, like ceph-dokan
>   * Currently, it builds rados.dll, used by rados_client.exe
>   * rados.dll provides the librados C API (linking C++ using .DLLs is
> problematic)
>   * rados_client.exe follows example code here
> (http://ceph.com/docs/master/rados/api/librados-intro/) to drive
> rados.dll, connect to a Ceph cluster and perform I/O
>   * LGLP v2.1
> 
> ### Details
> 
> Currently, rados_dll is built, similar to ceph-dokan, from source
> files copied over from ceph/src and with _WIN32 specific
> modifications. It is built using gcc, and uses winsock.
> 
> ### Next steps
> 
> We've had to disable cephx authentication for now, obviously we need
> to get this ported and working properly.
> 
> Currently, the build environment has to be carefully prepared by hand.
> We're looking to add scripts to help ease and automate that process.
> 
> We're looking to streamline merging of changes from 'upstream' ceph.
> First, we intend to remove unmodified source files from the src/
> directory and use upstream ceph/src directly.
> 
> Next, we're looking to use tools (e.g. diff/patch, sed) to the apply
> _WIN32 specific modifications in an automated manner whenever possible
> to generate _WIN32 sources.
> 
> We hope to gain enough traction and credibility to contribute _WIN32
> specific sections (with appropriate guards) to ceph core code.
> Eventually, hopefully, we might be able to build rados.dll (along with
> other Ceph components that can be ported to Windows) directly from a
> single set of source files.
> 
> Finally, our Makefile is hand-written (as with ceph-dokan), and we
> welcome any help to be able to standardise on using the autotools
> toolchain to automate that as well (or integrate with upstream).

Wouldn't it be easier to use cygwin and build on either automake / autotools. Maybe CMake is a possible solution as well ? I confess that I've not used cygwin in a long time ;-)

Cheers

> 
> ### Roadmap
> 
> We're looking at tackling RBD soon, and provide a native, Windows
> system-level block device backed by Ceph. ;)
> 
> We welcome any and all comments, suggestions, and support.
> 
> ### Who we are
> 
> Acaleph is a small startup headquartered in Singapore, but operating mostly from
> the Philippines, and we provide Ceph deployment, integration, support
> and other services.
> 
> Julio Telan is a graduating student from De La Salle University
> spending his internship at Acaleph, mentored by yours truly.
> 
> Cheers!
> 
> Alistair A. Israel, alistair@acale.ph
> Julio Telan, julio_telan@dlsu.edu.ph
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: rados_dll: A Windows port of librados

[Sage Weil]

Hi Alistair,

On Thu, 19 Mar 2015, Alistair Israel wrote:
> Hi, ceph.
> 
> We are pleased to announce our first milestone in bringing Ceph to the
> Windows platform, by porting librados into rados.dll.
> 
> https://github.com/AcalephStorage/rados_dll

This is exciting!
 
> Many thanks to dketor@gmail.com and the ceph-dokan project for
> providing the springboard and early consultation with which we were
> able to embark upon this course (we've also forked ceph-dokan and are
> looking to be active contributors to that project).
> 
> ### Overview
> 
>   * rados_dll is built using mingw, like ceph-dokan
>   * Currently, it builds rados.dll, used by rados_client.exe
>   * rados.dll provides the librados C API (linking C++ using .DLLs is
> problematic)
>   * rados_client.exe follows example code here
> (http://ceph.com/docs/master/rados/api/librados-intro/) to drive
> rados.dll, connect to a Ceph cluster and perform I/O
>   * LGLP v2.1
> 
> ### Details
> 
> Currently, rados_dll is built, similar to ceph-dokan, from source
> files copied over from ceph/src and with _WIN32 specific
> modifications. It is built using gcc, and uses winsock.
> 
> ### Next steps
> 
> We've had to disable cephx authentication for now, obviously we need
> to get this ported and working properly.
> 
> Currently, the build environment has to be carefully prepared by hand.
> We're looking to add scripts to help ease and automate that process.
> 
> We're looking to streamline merging of changes from 'upstream' ceph.
> First, we intend to remove unmodified source files from the src/
> directory and use upstream ceph/src directly.
> 
> Next, we're looking to use tools (e.g. diff/patch, sed) to the apply
> _WIN32 specific modifications in an automated manner whenever possible
> to generate _WIN32 sources.
> 
> We hope to gain enough traction and credibility to contribute _WIN32
> specific sections (with appropriate guards) to ceph core code.
> Eventually, hopefully, we might be able to build rados.dll (along with
> other Ceph components that can be ported to Windows) directly from a
> single set of source files.

I'm glad to see this.  As I said to Ketor about ceph-dokan, the goal 
should definitely be get the portability changes upstream.  There are a 
few other porting effots underway (Solaris, AIX; aarch64, MIPS) and 
ultimately we want to make sure we're building portability wrappers around 
the appropriate pieces to avoid a tangle of #ifdef's or hard to maintain 
forks.  As you isolate these changes, let us know so we can start 
testing and merging them.

> Finally, our Makefile is hand-written (as with ceph-dokan), and we
> welcome any help to be able to standardise on using the autotools
> toolchain to automate that as well (or integrate with upstream).

Would CMake make your life easie?

sage

> ### Roadmap
> 
> We're looking at tackling RBD soon, and provide a native, Windows
> system-level block device backed by Ceph. ;)
> 
> We welcome any and all comments, suggestions, and support.
> 
> ### Who we are
> 
> Acaleph is a small startup headquartered in Singapore, but operating mostly from
> the Philippines, and we provide Ceph deployment, integration, support
> and other services.
> 
> Julio Telan is a graduating student from De La Salle University
> spending his internship at Acaleph, mentored by yours truly.
> 
> Cheers!
> 
> Alistair A. Israel, alistair@acale.ph
> Julio Telan, julio_telan@dlsu.edu.ph
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: rados_dll: A Windows port of librados

[Ketor D]

Hi Sage,
     I read the the rados_dll code and in my option it is very similar
to ceph-dokan,  like just add librados code to ceph-dokan.
     It's very easy to implement librados, librbd in ceph-dokan,
because all base code is ported to MinGW.

     I update the ceph-dokan from 0.67 to 0.92 for a long time, and
push it to all cephers in 0.88.
     With my experience I think if we need to split the client-side
code from all Ceph code.After split, all port work will be much more
easier to merge to upstream.
     Recently I am trying to port the cephx auth to MinGW, after this
ceph-dokan and libraodos can use cephx for mount.

     And also Alistair, would you like to help port your librados code
to ceph-dokan project with a clean pull request?

Ketor

Re: rados_dll: A Windows port of librados

[Alistair Israel]

On Fri, Mar 20, 2015 at 10:45 AM, Ketor D <d.ketor@gmail.com> wrote:

> And also Alistair, would you like to help port your librados code
> to ceph-dokan project with a clean pull request?

Hi, Ketor!

At this point we figured it'd easier in both the short term (and
better long-term) to just start merging changes into "/ceph/src" (as a
submodule, of a fork of ceph/ceph) rather than maintaining a copy of
the files under "/src".

One of the difficulties we had with making changes with ceph-dokan was
how different the file structure alone was from upstream ceph. I
actually have a fork of ceph-dokan that mirrors the directory
structure of rados_dll and ceph/ceph, I can issue a PR for that (it
allows for clean merge).

From there, we can continue collaborating on both projects separately
for now, until we have enough overlap and commonality that it makes
sense to merge the two.

What do you think?

Alistair

Re: rados_dll: A Windows port of librados

[Ketor D]

Hi Alistair,
     I think you just import my code from ceph-dokan and don't know
where is the most difficulties in merging upstream ceph.
     File structure is not problem, the difficulties is the code in
include/common/msg/osd/mon/mds is very different from upstream.
     If I try to merge ceph-dokan into upstream, the merge work will
affect the upstream developing a lot.

     So now I just update the ceph-dokan with upstream ceph, and add
most of the client-side code in ceph-dokan. With this work, I will
also try to refactor the code modifed for mingw and make it more
similar to upstream.
     Also mingw is on developing, in the latest relase ceph-dokan can
reduce many ugly mod for mingw. So we can wait for mingw to be more
stable for a while.
     And after these work, it will be the timing for merging into upstream.

Ketor


On Tue, Mar 24, 2015 at 8:14 PM, Alistair Israel <aisrael@gmail.com> wrote:
> On Fri, Mar 20, 2015 at 10:45 AM, Ketor D <d.ketor@gmail.com> wrote:
>
>> And also Alistair, would you like to help port your librados code
>> to ceph-dokan project with a clean pull request?
>
> Hi, Ketor!
>
> At this point we figured it'd easier in both the short term (and
> better long-term) to just start merging changes into "/ceph/src" (as a
> submodule, of a fork of ceph/ceph) rather than maintaining a copy of
> the files under "/src".
>
> One of the difficulties we had with making changes with ceph-dokan was
> how different the file structure alone was from upstream ceph. I
> actually have a fork of ceph-dokan that mirrors the directory
> structure of rados_dll and ceph/ceph, I can issue a PR for that (it
> allows for clean merge).
>
> From there, we can continue collaborating on both projects separately
> for now, until we have enough overlap and commonality that it makes
> sense to merge the two.
>
> What do you think?
>
> Alistair
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rados_dll: A Windows port of librados

[Alistair Israel]

Thank you Loïc and Sage for the encouragement!

Yes, we'll look into CMake if it simplifies managing the build.
However, a "stretch goal" is to possibly have the same autotools build
scripts generate .exe and .dll files from the same source files (it at
all feasible or desirable). So, that's at least one reason to go with
Makefiles for now.

So, yes, for now we'll just go with #ifdef's all around until a
reasonable pattern of abstraction emerges, then platform-specific code
can be factored out into neater compartments (methods, classes,
files).

Cheers!
Alistair

On Thu, Mar 19, 2015 at 11:27 PM, Sage Weil <sage@newdream.net> wrote:
> Hi Alistair,
>
> On Thu, 19 Mar 2015, Alistair Israel wrote:
>> Hi, ceph.
>>
>> We are pleased to announce our first milestone in bringing Ceph to the
>> Windows platform, by porting librados into rados.dll.
>>
>> https://github.com/AcalephStorage/rados_dll
>
> This is exciting!
>
>> Many thanks to dketor@gmail.com and the ceph-dokan project for
>> providing the springboard and early consultation with which we were
>> able to embark upon this course (we've also forked ceph-dokan and are
>> looking to be active contributors to that project).
>>
>> ### Overview
>>
>>   * rados_dll is built using mingw, like ceph-dokan
>>   * Currently, it builds rados.dll, used by rados_client.exe
>>   * rados.dll provides the librados C API (linking C++ using .DLLs is
>> problematic)
>>   * rados_client.exe follows example code here
>> (http://ceph.com/docs/master/rados/api/librados-intro/) to drive
>> rados.dll, connect to a Ceph cluster and perform I/O
>>   * LGLP v2.1
>>
>> ### Details
>>
>> Currently, rados_dll is built, similar to ceph-dokan, from source
>> files copied over from ceph/src and with _WIN32 specific
>> modifications. It is built using gcc, and uses winsock.
>>
>> ### Next steps
>>
>> We've had to disable cephx authentication for now, obviously we need
>> to get this ported and working properly.
>>
>> Currently, the build environment has to be carefully prepared by hand.
>> We're looking to add scripts to help ease and automate that process.
>>
>> We're looking to streamline merging of changes from 'upstream' ceph.
>> First, we intend to remove unmodified source files from the src/
>> directory and use upstream ceph/src directly.
>>
>> Next, we're looking to use tools (e.g. diff/patch, sed) to the apply
>> _WIN32 specific modifications in an automated manner whenever possible
>> to generate _WIN32 sources.
>>
>> We hope to gain enough traction and credibility to contribute _WIN32
>> specific sections (with appropriate guards) to ceph core code.
>> Eventually, hopefully, we might be able to build rados.dll (along with
>> other Ceph components that can be ported to Windows) directly from a
>> single set of source files.
>
> I'm glad to see this.  As I said to Ketor about ceph-dokan, the goal
> should definitely be get the portability changes upstream.  There are a
> few other porting effots underway (Solaris, AIX; aarch64, MIPS) and
> ultimately we want to make sure we're building portability wrappers around
> the appropriate pieces to avoid a tangle of #ifdef's or hard to maintain
> forks.  As you isolate these changes, let us know so we can start
> testing and merging them.
>
>> Finally, our Makefile is hand-written (as with ceph-dokan), and we
>> welcome any help to be able to standardise on using the autotools
>> toolchain to automate that as well (or integrate with upstream).
>
> Would CMake make your life easie?
>
> sage
>
>> ### Roadmap
>>
>> We're looking at tackling RBD soon, and provide a native, Windows
>> system-level block device backed by Ceph. ;)
>>
>> We welcome any and all comments, suggestions, and support.
>>
>> ### Who we are
>>
>> Acaleph is a small startup headquartered in Singapore, but operating mostly from
>> the Philippines, and we provide Ceph deployment, integration, support
>> and other services.
>>
>> Julio Telan is a graduating student from De La Salle University
>> spending his internship at Acaleph, mentored by yours truly.
>>
>> Cheers!
>>
>> Alistair A. Israel, alistair@acale.ph
>> Julio Telan, julio_telan@dlsu.edu.ph
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>



-- 
http://about.me/alistair.israel
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rados_dll: A Windows port of librados

[Gregory Farnum]

On Tue, Mar 24, 2015 at 4:26 AM, Alistair Israel <aisrael@gmail.com> wrote:
> Thank you Loïc and Sage for the encouragement!
>
> Yes, we'll look into CMake if it simplifies managing the build.
> However, a "stretch goal" is to possibly have the same autotools build
> scripts generate .exe and .dll files from the same source files (it at
> all feasible or desirable). So, that's at least one reason to go with
> Makefiles for now.

He was actually asking about CMake because you'll see that we have
CMake in-tree as an alternate build manager. It's not quite complete
yet (it doesn't build the unit tests and things), but we keep hearing
rumbles about it being better, it looks to do builds faster, etc. So
if that's an easier solution for you to support on Windows it might be
a good idea to do that instead of autotools.
-Greg

>
> So, yes, for now we'll just go with #ifdef's all around until a
> reasonable pattern of abstraction emerges, then platform-specific code
> can be factored out into neater compartments (methods, classes,
> files).
>
> Cheers!
> Alistair
>
> On Thu, Mar 19, 2015 at 11:27 PM, Sage Weil <sage@newdream.net> wrote:
>> Hi Alistair,
>>
>> On Thu, 19 Mar 2015, Alistair Israel wrote:
>>> Hi, ceph.
>>>
>>> We are pleased to announce our first milestone in bringing Ceph to the
>>> Windows platform, by porting librados into rados.dll.
>>>
>>> https://github.com/AcalephStorage/rados_dll
>>
>> This is exciting!
>>
>>> Many thanks to dketor@gmail.com and the ceph-dokan project for
>>> providing the springboard and early consultation with which we were
>>> able to embark upon this course (we've also forked ceph-dokan and are
>>> looking to be active contributors to that project).
>>>
>>> ### Overview
>>>
>>>   * rados_dll is built using mingw, like ceph-dokan
>>>   * Currently, it builds rados.dll, used by rados_client.exe
>>>   * rados.dll provides the librados C API (linking C++ using .DLLs is
>>> problematic)
>>>   * rados_client.exe follows example code here
>>> (http://ceph.com/docs/master/rados/api/librados-intro/) to drive
>>> rados.dll, connect to a Ceph cluster and perform I/O
>>>   * LGLP v2.1
>>>
>>> ### Details
>>>
>>> Currently, rados_dll is built, similar to ceph-dokan, from source
>>> files copied over from ceph/src and with _WIN32 specific
>>> modifications. It is built using gcc, and uses winsock.
>>>
>>> ### Next steps
>>>
>>> We've had to disable cephx authentication for now, obviously we need
>>> to get this ported and working properly.
>>>
>>> Currently, the build environment has to be carefully prepared by hand.
>>> We're looking to add scripts to help ease and automate that process.
>>>
>>> We're looking to streamline merging of changes from 'upstream' ceph.
>>> First, we intend to remove unmodified source files from the src/
>>> directory and use upstream ceph/src directly.
>>>
>>> Next, we're looking to use tools (e.g. diff/patch, sed) to the apply
>>> _WIN32 specific modifications in an automated manner whenever possible
>>> to generate _WIN32 sources.
>>>
>>> We hope to gain enough traction and credibility to contribute _WIN32
>>> specific sections (with appropriate guards) to ceph core code.
>>> Eventually, hopefully, we might be able to build rados.dll (along with
>>> other Ceph components that can be ported to Windows) directly from a
>>> single set of source files.
>>
>> I'm glad to see this.  As I said to Ketor about ceph-dokan, the goal
>> should definitely be get the portability changes upstream.  There are a
>> few other porting effots underway (Solaris, AIX; aarch64, MIPS) and
>> ultimately we want to make sure we're building portability wrappers around
>> the appropriate pieces to avoid a tangle of #ifdef's or hard to maintain
>> forks.  As you isolate these changes, let us know so we can start
>> testing and merging them.
>>
>>> Finally, our Makefile is hand-written (as with ceph-dokan), and we
>>> welcome any help to be able to standardise on using the autotools
>>> toolchain to automate that as well (or integrate with upstream).
>>
>> Would CMake make your life easie?
>>
>> sage
>>
>>> ### Roadmap
>>>
>>> We're looking at tackling RBD soon, and provide a native, Windows
>>> system-level block device backed by Ceph. ;)
>>>
>>> We welcome any and all comments, suggestions, and support.
>>>
>>> ### Who we are
>>>
>>> Acaleph is a small startup headquartered in Singapore, but operating mostly from
>>> the Philippines, and we provide Ceph deployment, integration, support
>>> and other services.
>>>
>>> Julio Telan is a graduating student from De La Salle University
>>> spending his internship at Acaleph, mentored by yours truly.
>>>
>>> Cheers!
>>>
>>> Alistair A. Israel, alistair@acale.ph
>>> Julio Telan, julio_telan@dlsu.edu.ph
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>
>
>
> --
> http://about.me/alistair.israel
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html