On Thu, Oct 8, 2020 at 1:00 AM Leon Romanovsky leon@kernel.org wrote:
On Thu, Oct 08, 2020 at 12:38:00AM -0700, Dan Williams wrote:
On Thu, Oct 8, 2020 at 12:01 AM Leon Romanovsky leon@kernel.org wrote: [..]
All stated above is my opinion, it can be different from yours.
Yes, but we need to converge to move this forward. Jason was involved in the current organization for registration, Greg was angling for this to be core functionality. I have use cases outside of RDMA and netdev. Parav was ok with the current organization. The SOF folks already have a proposed incorporation of it. The argument I am hearing is that "this registration api seems hard for driver writers" when we have several driver writers who have already taken a look and can make it work. If you want to follow on with a simpler wrappers for your use case, great, but I do not yet see anyone concurring with your opinion that the current organization is irretrievably broken or too obscure to use.
Can it be that I'm first one to use this bus for very large driver (>120K LOC) that has 5 different ->probe() flows?
For example, this https://lore.kernel.org/linux-rdma/20201006172317.GN1874917@unreal/ hints to me that this bus wasn't used with anything complex as it was initially intended.
I missed that. Yes, I agree that's broken.
And regarding registration, I said many times that init()/add() scheme is ok, the inability to call to uninit() after add() failure is not ok from my point of view.
Ok, I got to the wrong conclusion about your position.