Re: [PATCH] rgw: Added an encoder for time_t to fix compilation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'd be happier if we could avoid time_t altogether and use utime_t.
The problem is that librados and the objecter interface who require
time_t for stat() and mtime(), so we just mirror that. Is there a
reason why not to use utime_t? That'll allow us to have better time
resolution when the underlying file system allows that.

On Mon, Jun 24, 2013 at 10:19 AM, Sage Weil <sage@xxxxxxxxxxx> wrote:
>> Sorry, wrong patch attached.
>>
>> Here comes the updated version.
>
> This might work, but I'm worried that utime_t is probably typedef'd to a
> unsigned long or something and we may accidentally call into the uint32_t
> or uint64_t method (whichever it is for that platform).  I would prefer
> something like
>
>
> Mything::encode(bufferlist& bl) const
> {
>   ...
>   uint64_t t = time;
>   ::encode(t, bl);
>   ...
> }
>
> and similarly in decode to
>
>   uint64_t t;
>   ::decode(t, bl);
>   time = t;
>
> sage
>
>>
>> Best regards.
>>
>> On Mon, Jun 24, 2013 at 4:36 PM, christophe courtaut
>> <christophe.courtaut@xxxxxxxxx> wrote:
>> > Here come a new patch.
>> >
>> > I do not generate an encoder/decoder using WRITE_RAW_ENCODER anymore.
>> >
>> > Instead i added a encoder/decoder for time_t using a __u64.
>> >
>> > On Thu, Jun 20, 2013 at 10:44 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote:
>> >> On Thu, Jun 20, 2013 at 6:57 AM, christophe courtaut
>> >> <christophe.courtaut@xxxxxxxxx> wrote:
>> >>> On the rgw-wip-geo-2 branch, the encode decode function are called
>> >>> with time_t now,
>> >>> but there is no encode/decode function created for time_t type.
>> >>>
>> >>> http://tracker.ceph.com/issues/5402 refs #5402
>> >>>
>> >>> This patch adds a WRITE_RAW_ENCODER to support this type.
>> >>>
>> >>> --
>> >>> Christophe Courtaut
>> >>
>> >>
>> >> The problem here is that we can't use the generic encoder / decoder as
>> >> time_t may have different size on different architectures. We should
>> >> just have a fixed size encoding for it (probably 64 bit albeit the
>> >> waste).
>> >>
>> >> Thanks,
>> >> Yehuda
>> >
>> >
>> >
>> > --
>> > Christophe Courtaut
>>
>>
>>
>> --
>> Christophe Courtaut
>>
--
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




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux