Hello sage and Yehuda,
yes nwat told me that u64 was an alias for unsigned long which is
default C compiler data type.
I wasn't cautious.
I read some other things like the cygwin mount.cc /mount.h files ...
they include cifs and nfs filetype things like samba too. We could
integrate a new data type in it with our ceph-win32-client.
Obviously everyone would prefere something with a nice point and click
window to setup their ceph-win32-client. But as a starter... maybe we
could understand better the way windows handle file systems starting
from cygwin/mount files.
Regards,
signature
*Alphé Salas*
Ingeniero T.I
asalas@xxxxxxxxx*<http://www.kepler.cl>*
On 11/05/13 18:59, Yehuda Sadeh wrote:
On Tue, Nov 5, 2013 at 1:49 PM, Alphe Salas Michels<asalas@xxxxxxxxx> wrote:
Hello sage,
I followed your lead and went a bit further in my source code reading and I
notice serveral problems:
first most of the id use in ceph osd_clients, mds_clients, mon_client use
the data type u64 which will be a problem
as most of the windows in use are windows XP or Windows server 2003 in 32
bits. As they are used for id tag for
things like snapshot pages (if I understand well) that can be a problem for
a port no?
What I read so far was
mount.ceph files > kernel/fs/ceph files which contains the mds_client files
and the kernel ioctl interface ... > include / linux / ceph files which
integrates libcephfs.h. and all the needed files
there is three clients, there is auth.h a messenger, a msgpool, buffer,
rados that depends on msgr that include in every aspect of the messages
formation one or more __le64 message.
I m far from understanding the whole code and the interactions betwin all
the files and which we can skip and which we can keep.
how can we translate those data type into 32bit in order for ceph cluster to
understand them and ceph-windows-client to transmit them?
It is possible to define 64 bit variables on 32 bit architectures. The
compiler handles it for you.
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
