RE: [RFC] xhci: Add a debugfs file to control bulk ring size.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Sarah,

I think I'd rather wait a bit longer for the proper ring segment dynamic allocation to work anyway.

Tim

-----Original Message-----
From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] 
Sent: Tuesday, September 20, 2011 1:50 PM
To: Greg KH
Cc: Sebastian Andrzej Siewior; Kruno Mrak; Tim Vlaar; linux-usb@xxxxxxxxxxxxxxx
Subject: Re: [RFC] xhci: Add a debugfs file to control bulk ring size.

On Tue, Sep 20, 2011 at 05:58:10AM -0700, Greg KH wrote:
> On Tue, Sep 20, 2011 at 11:26:54AM +0200, Sebastian Andrzej Siewior wrote:
> > * Greg KH | 2011-09-19 15:03:53 [-0700]:
> > 
> > >Once you add a userspace api like this, you can't ever remove it, 
> > >so I would recommend not doing this.
> > 
> > Do you consider the debugfs interface as an userspace api?
> 
> Yes, and Linus does as well and has said so many times publically.
> 
> > It was introduced for developers to debug things.
> 
> Yes it was, is this debugging something?

Heh, no. :)  I was going down the debugfs path because you told me module parameters to expand the rings weren't acceptable, and to use debugfs.  But you're right that this is basically adding a new userspace API, and if I can't rip this out later, I don't want to add it.

> > My understanding is that Sarah is getting rid of this once she 
> > rewrote the part of the code that needs this workaround.
> 
> Again, you just broke any tool that was used to using that interface.
> 
> As this really doesn't look like a debugging interface, put it in sysfs.

Ok, I'll have to decide whether it's worth it to create a sysfs file or just take a month to do the dynamic ring expansion properly.  I'm leaning towards just doing it properly, since we're so close to the merge window, and this feature is probably not going to make it into 3.2.

I'm also a bit concerned that the interface is too generic anyway.  One userspace driver can say "I want 100 ring segments" and then all the bulk endpoints attached to the xHCI host controller will be allocated
100 ring segments, even if they don't need it.  That's a waste of 100KB or more of DMA'able memory.  If it turns out some USB 3.0 devices need even bigger rings, and others don't, then we waste even more memory.

I think I'd rather take more time and do things right than incur some technical debt for an API that I don't really want to support in the long run.  Sorry Tim and Kruno, you'll have to wait a bit longer for your device to work under xHCI.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux