On Apr 11, 2012, at 3:39 PM, Greg Farnum wrote:
> On Wednesday, April 11, 2012 at 3:18 PM, Noah Watkins wrote:
>> One could pair the pointer with a magic value in a separate structure, but even libc doesn't go to these lengths to protect users...
>
> At that point we'd run a pretty high risk of segfaulting when trying to deref and look at the magic value anyway. Nothing useful we can do here, I think. :/
Actually I meant:
struct container {
int magic;
struct ceph_mount_info *ptr;
};
ceph_chdir(struct container something);
Then, container.magic should equal INITIALIZED where INITIALIZED is "some value that is unlikely to ever be present at a memory location where container is allocated". Lol… overkill and not bullet-proof.
> On Wednesday, April 11, 2012 at 3:29 PM, Noah Watkins wrote:
>
>>
>> On Apr 11, 2012, at 11:32 AM, Greg Farnum wrote:
>>
>>> On Wednesday, April 11, 2012 at 11:25 AM, Noah Watkins wrote:
>>>>
>>>> On Apr 11, 2012, at 11:22 AM, Greg Farnum wrote:
>>>>
>>>>> On Wednesday, April 11, 2012 at 11:12 AM, Noah Watkins wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> -Noah
>>>>> I'm not sure where the "-1004" came from,
>>>>
>>>>
>>>>
>>>> ceph_mount(..) seems to return some random error codes (-1000, 1001) already :)
>>>
>>> <grumble> legacy undocumented grr </grumble>
>>> Let's try to use standard error codes where available, and (if we have to create our own) document any new ones with user-accessible names and explanations. I don't know which one is "best" but I see a lot of applicable choices when scanning errno-base et al.
>>
>>
>>
>> If I'm choosing from from errno-base I might go with
>>
>> #define ENXIO 6 /* No such device or address */
>>
>> It's used:
>>
>> osd/OSD.cc (http://OSD.cc)
>> void OSD::handle_misdirected_op(PG *pg, OpRequest *op)
>> …
>> reply_op_error(op, -ENXIO)
>>
>> I'm wondering if you happen to know if this will be propagated back to the client? I'd be nice to have an exclusive not-mounted condition on the client side.
>>
>> -Noah
> Unfortunately it is. (I just grepped and see it's returned by both the MDS and the OSD, but it's not in Objecter et al so it's not filtered out anywhere.)
>
> ENODEV isn't returned from anything; do you think that makes sense?
> -Greg
>
>
>
--
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
