On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote: > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote: > > This patch series removes the write() interface for user access in favor of an > > ioctl() based approach. This is in response to the complaint that we had > > different handlers for write() and writev() doing different things and expecting > > different types of data. See: > > I think we should wait on applying these patches until we globally sort out > what to do with the rdma uapi. > > It just doesn't make alot of sense for drivers to have their own personal > char devices. :( I looked through the patches I tend to disagree - while we should wait for a global UAPI for anything that's actually RDMA/verbs related these seem to be misc little bits specific to the driver that have no business in any sort of generic RDMA API. > A second char dev for the eeprom? How is that OK? Why aren't you using > the I2C layer for this? ... but this is a really good question, although the right layer to plug this in would be the eeprom code in drivers/nvmem/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
