linux-kernel - Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus

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]

Date:	Wed, 22 Jun 2011 13:46:37 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
	Brian Swetland <swetland@...gle.com>,
	Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	davinci-linux-open-source 
	<davinci-linux-open-source@...ux.davincidsp.com>
Subject: Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus

On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen <ohad@...ery.com> wrote:
>> Add a virtio-based IPC bus, which enables kernel users to communicate
>> with remote processors over shared memory using a simple messaging
>> protocol.
>
> Wow, sometimes one writes a standard and people use it.  Thanks!

And we really liked it: virtio_rpmsg_bus.c, the virtio driver which
does most of the magic here ended up pretty small thanks to virtio.
and the performance numbers are really good, too.

>> +     /* Platform must supply pre-allocated uncached buffers for now */
>> +     vdev->config->get(vdev, VPROC_BUF_ADDR, &addr, sizeof(addr));
>> +     vdev->config->get(vdev, VPROC_BUF_NUM, &num_bufs, sizeof(num_bufs));
>> +     vdev->config->get(vdev, VPROC_BUF_SZ, &buf_size, sizeof(buf_size));
>> +     vdev->config->get(vdev, VPROC_BUF_PADDR, &vrp->phys_base,
>> +                                             sizeof(vrp->phys_base));
>
> The normal way is to think of the config space as a structure, and use
> offsets rather than using an enum value to distinguish the fields.

Yes, I was (mis-)using the config space for now to talk with
platform-specific code (on the host), and not with the peer, so I
opted for simplicity.

But this is definitely one thing that is going away: I don't see any
reason why not just use dma_alloc_coherent (or even dma_pool_create)
directly from the driver here in order to get those buffers.

>> +#define RPMSG_NAME_SIZE                      32
>> +#define RPMSG_DEVICE_MODALIAS_FMT    "rpmsg:%s"
>> +
>> +struct rpmsg_device_id {
>> +     char name[RPMSG_NAME_SIZE];
>> +     kernel_ulong_t driver_data      /* Data private to the driver */
>> +                     __attribute__((aligned(sizeof(kernel_ulong_t))));
>> +};
>
> This alignment directive seems overkill...

Yes, looks like I can remove this. thanks.

>> +#define VIRTIO_ID_RPMSG              10 /* virtio remote processor messaging */
>
> I think you want 6.  Plan 9 jumped ahead to grab 9 :)

6 it is :)

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/