[Fwd: Re: [PATCH] 2/2 mtd: Add support for the Dreamcast VMU flash]

[Adrian McMenamin]

On Thu, March 20, 2008 11:20 am, Jörn Engel wrote:
> On Thu, 20 March 2008 11:56:54 -0000, Adrian McMenamin wrote:
>> >> +
>> >> +	((unsigned long *)sendbuf)[0] = cpu_to_be32(MAPLE_FUNC_MEMCARD);
>> >> +	((unsigned long *)sendbuf)[1] = cpu_to_be32(partition << 24 | num);
>> >
>> > unsigned long is larger than 32bit on many architectures.  Better
>> > variant:
>> > 	__be32 *sendbuf;
>>
>>
>> No, it's not. This is part of a bus subsystem where different parts of
>> the
>> incoming packets may or may not be in big endian format. Eg for block
>> writes the then the opening blocks may be in big endian format but the
>> data to be written is not.
>
> Data to be written is usually treated as opaque void* pointer.  You
> don't need to know what's in it, just the pointer and the length.  But
> once you dereference the data, it is no longer opaque and you better
> know its endianness.
>
> So why do you use void* for data you actually dereference?


Because for other devices data can be passed as 16 bit structures as well
as 32 bit ones.


>.
>
> A couple of lines down you have "return -ENOMEM;".  Notice the "-"?  As
> a general rule, negative return values in the kernel are errors,
> positive or zero are non-errors.  Exceptions exist, but they tend to
> surprise users and cause subtle bugs.
>

Ah. I understand your point better now. I'd basically saw that too - but I
didn't realise that is what you meant.