- Dev - lists.ceph.io

by Sage Weil

Hi everyone, CDM is tonight at 0100 UTC (9pm ET, 6pm PT). https://bluejeans.com/908675367/ https://tracker.ceph.com/projects/ceph/wiki/Planning The agenda so far: https://tracker.ceph.com/projects/ceph/wiki/CDM_04-SEP-2019 - [Yehuda] wandering log: a multi-reader, multi-writer FIFO queue striped over rados objects. This satisfies some rgw multisite use-cases, but should be a generic library that can be used for other things as well. - [Sage] rados: return bufferlist with write operations. Historically we've recorded a return code only. The idea here is to also allow a (bounded) return buffer with arbitrary data from writes. - [Ivo] github actions workflows for Ceph. Portable dev/packaging/testing/benchmarking workflows based on github actions.. See you tonight! sage

4 years, 8 months

1
0
0 0

***** SPAM 6.0 ***** Re: Photographic equipment factory direct sales

by shaozhuo1368

4 years, 8 months

1
0
0 0

***** SPAM 7.4 ***** Re: RF passive components manufacturer(reduce your procurement costs and help for your business )

by Robin

4 years, 8 months

1
0
0 0

Re: 2019 fashion Sportswear

by yizi5159030833

4 years, 8 months

1
0
0 0

Re: special cable manufacturer

by wadeyuy

4 years, 8 months

1
0
0 0

***** SPAM 8.2 ***** Re: RF passive components manufacturer(reduce your procurement costs and help for your business )

by Robin

Dear friend, Good day! We are the manufacturer of RF passive components located in China. Our main products: power splitter,directional coupler, dummy load,attenuator,RF Connector，Antenna and so oncovering 698-2700MHz,340-2700MHz,698-3800MHz，137-960MHz.136-174MHz. // Each line of our passive components share the low pim:-150dBc/-160dBc // With 6 RF engineers with expertise and best customer service, I think our produncts will reduce your procurement costs and help for your business, welcome to contact me. Best Rgds Robin Hefei Bolite Electronic And Technology Co.,Ltd 385 HuangShan Road,Hefei City ,Anhui Province , 230088. CHINA Ph: +86-0551-63668566 /Fax:86-0551-3668566-802

4 years, 8 months

1
0
0 0

Re: High-end and low-cost photographic equipment

by Joyce

4 years, 8 months

1
0
0 0

Ceph broken on big-endian systems

by Ulrich Weigand

Hello, we've been trying to get Ceph to work on IBM Z, a big-endian system, and have been running into various serious issues relating to endian conversion code. The main issue we've been seeing is that while the old-style decode/encode machinery in include/encoding.h automatically byte-swaps all integers on big-endian systems (to ensure the serialized format is always little endian), the *new-style* machinery in include/denc.h does not. This seemed confusing at first since there is quite a bit of code there that appears intended to perform exactly that function, e.g. template<typename T> struct ExtType<T, std::enable_if_t<std::is_same_v<T, int32_t> || std::is_same_v<T, uint32_t>>> { using type = __le32; }; However, it turns out that at this point __le32 is actually just an alias for __u32, so this whole machinery doesn't really do anything at all. Looking at the old code in encoding.h, I notice that it works similarly, but uses ceph_le32 instead of __le32. The former is a C++ class that actually does perform byte-swap on access. Even more confusing, there is this code in include/types.h: // temporarily remap __le* to ceph_le* for benefit of shared kernel/userland headers #define __le16 ceph_le16 #define __le32 ceph_le32 #define __le64 ceph_le64 #include "ceph_fs.h" #include "ceph_frag.h" #include "rbd_types.h" #undef __le16 #undef __le32 #undef __le64 which --sometimes-- redefines __le32 as ceph_le32, but those redefines are not active at the point denc.h is included. So it would appear that the usage of __le32 in denc.h is incorrect, and this code should be using ceph_le32 instead. Is this right? But even so, grepping for __le32 throughout the code base shows quite a bit of additional places where it is used, most of which also appear to make the assumption that byte-swaps automatically happen. In addition, there appear to be some places where e.g. ceph_fs.h is included directly, without going via types.h -- and in those places, we suddenly no longer get the byte-swaps ... Now I was wondering whether the best way forward might be to just have __le32 always be defined as ceph_le32 when compiling user space code. But then I noticed that it used to be that way, but that was deliberated changed by this commit back in 2010: commit 737b5043576153817a6b4195b292672585df10d3 Author: Sage Weil <sage(a)newdream.net> Date: Fri May 7 13:45:00 2010 -0700 endian: simplify __le* type hackery Instead of preventing linux/types.h from being included, instead name our types ceph_le*, and remap using #define _only_ when including the shared kernel/userspace headers. So I'm a bit at a loss to understand how all this is supposed to be working. Any suggestions would be welcome -- we'd be willing to implement whatever's needed, but would like some guidance as to how the solution should look like ... Bye, Ulrich

4 years, 8 months

2
6
1 0

Re: customized women's knitted clothing service

by rongsha66178

4 years, 8 months

1
0
0 0

***** SPAM 6.0 ***** Re: 2019 fashion Sportswear

by yizi5159030833

4 years, 8 months

1
0
0 0

2024

2023

2022

2021

2020

2019

Dev