On Fri, Feb 08, 2019 at 11:24:31AM -0800, Ira Weiny wrote: > On Fri, Feb 08, 2019 at 06:57:48AM +0200, Leon Romanovsky wrote: > > On Thu, Feb 07, 2019 at 01:36:22PM -0700, Jason Gunthorpe wrote: > > > On Thu, Feb 07, 2019 at 10:31:48PM +0200, Leon Romanovsky wrote: > > > > > > > > That is a silly place to end up - there is no reason to use port == 0 > > > > > here as invalid, it should be fixed. > > > > > > > > What exactly do you suggest to fix? > > > > > > > > If user provides "port", it will need to pass rdma_is_port_valid() check. > > > > We have exactly zero drivers which know how to handle is_switch correctly. > > > > > > I do not want to see half implemented stuff, either follow the > > > existing convention for port number and is_switch in the core code or > > > delete the is_switch stuff. > > > > > > Since using -1 or something here is really trivial, that seesm like > > > the right answer > > > > It is out of the scope of existing series, which is focused on per-ID > > access. Maybe later, someone will find time to write code for imaginary flows > > with zero value, especially for UAPI where allowance of not-tested/not-working > > value (port == 0) can bring disaster later on. > > I was told a long time ago that there were vendors running embedded linux in > their switches where port == 0 was valid. > > Perhaps some vendors will speak up about this? I don't know if it is true any > longer and if it even applies in all port == 0 cases. It is not enough to allow "port == 0", everything exported through nldev.c was never tested with any such systems. Thanks > > Ira >
Attachment:
signature.asc
Description: PGP signature
