[lkml]   [2014]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 1/6] mailbox: add core framework
On Fri, Feb 14, 2014 at 08:48:25PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Courtney Cavin wrote:
> > On Tue, Feb 11, 2014 at 09:35:01AM +0100, Arnd Bergmann wrote:
> > > On Monday 10 February 2014 16:23:48 Courtney Cavin wrote:
> > Then again, I think that the context management stuff is the exception as well,
> > and I think that can/should also be handled in a higher level. Regardless, I
> > went ahead and drafted the async flags idea out anyway, so here's some
> > pseudo-code. I also tried to shoe-horn in 'peek', and you can see how that
> > turns out. Let me know if this is something like what you had in mind.
> The async implementation looks good to me, assuming we actually need both
> sync and async operations, which I can't tell for sure.

Yea, I would like some further input on that specifically. I have added
Linus Walleij and Jassi Brar, who have had good input on mailboxes in
the past, and somehow I missed in this series.

> For the peek operation, it wouldn't work for the ethernet case, which
> has to call it from atomic context in net_rx_action.

It wouldn't work if the mbox is not requested with MBOX_ASYNC, but
otherwise that should be fine, as it would just peek into the kfifo.
That doesn't seem like a desirable method for ethernet use-case though,
as it ends up being two extra copies.

> > /**
> > * so this is where this lock makes things difficult, as this function
> > * might_sleep(), but only really because of the lock. Either we can
> > * remove the lock and force the adapter to do its own locking
> > * spinlock-style, or we can accept the sleep here, which seems a bit
> > * stupid in a peek function. Neither option is good. Additionally,
> > * there's no guarantee that the adapter doesn't operate over a bus
> > * which itself might_sleep(), exacerbating the problem.
> > */
> > mutex_lock(&mbox->adapter->lock);
> > rc = mbox->adapter->ops->peek_message(mbox->adapter, mbox->chan, msg);
> > mutex_lock(&mbox->adapter->lock);
> If we decide that peek() must not sleep, any driver that operates on a
> slow bus could just always report "no data" here.

Yes indeed, or it could just not implement peek, which seems reasonable.

> Moving the locking into the mbox driver here sounds appropriate.

I don't really like doing that for the entirety of the mbox core, as it
makes the simple adapters harder to write properly. Since peek is not
a typical use-case, perhaps we could remove the locking for just peek,
and have a Big Fat Warning in the description of how to properly
implement it?

> Arnd

Thanks for the input!


 \ /
  Last update: 2014-02-14 22:01    [W:0.101 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site