linux-kernel - Re: [PATCH 0/4] mailbox: mailbox-test: support single channel with separate Tx and Rx buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56BDA8E3.8060800@arm.com>
Date:	Fri, 12 Feb 2016 09:41:55 +0000
From:	Sudeep Holla <sudeep.holla@....com>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Sudeep Holla <sudeep.holla@....com>,
	Jassi Brar <jassisinghbrar@...il.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] mailbox: mailbox-test: support single channel with
 separate Tx and Rx buffer



On 12/02/16 09:17, Lee Jones wrote:
> On Thu, 11 Feb 2016, Sudeep Holla wrote:
>
>> Hi Lee, Jassi,
>>
>> Assuming mailbox-test was designed to be generic, I am trying to extend
>> it to support single channel with separate Tx and Rx buffer. With these
>> changes I am able to test arm_mhu driver. However I couldn't understand
>> the intention of converting buffer to ASCII hex dump in read method.
>> I have a local change to remove that so that it can deal with any data
>> in any format(e.g. some protocol format)
>
> Not sure quite what you mean.  Hexdump can handle any data?  If the
> hex value read isn't an ASCII value, a '.' is printed on the right
> hand side.  What data are you expecting that you can't analyse with
> hexdump?
>

Sorry for not being clear. Hexdump can handle any data. I do see that
it displays quite nicely at the driver level which is nice.

However my question was why is the the buffer copied to user space is
not the original raw data, rather it's ASCII converted which is good for
nice logging.

One of the use-case the testing guys wants is the check the protocol
specification using this. In their case they expect the test driver to
send the raw data as is from the driver rather than the converted ASCII
buffer. I tend to agree with them for 2 reasons:

1. userspace can do the conversion if required
2. the input buffer is not converted(i.e. in the write path), so it's
    bit of inconsistent there.

-- 
Regards,
Sudeep