On Fri, Apr 22, 2016 at 02:38:45PM -0400, Dennis Dalessandro wrote:
> >Stuff like this should be a build bug:
> >/* NOTE: assumes unsigned long is 8 bytes */
>
> Our Kconfig depends on X86_64. Should we add a BUILD_BUG_ON or something?
Yes
> as we can maintain the same functionality, which
On Fri, Apr 22, 2016 at 02:38:45PM -0400, Dennis Dalessandro wrote:
> >Stuff like this should be a build bug:
> >/* NOTE: assumes unsigned long is 8 bytes */
>
> Our Kconfig depends on X86_64. Should we add a BUILD_BUG_ON or something?
Yes
> as we can maintain the same functionality, which
On Wed, Apr 20, 2016 at 02:36:16PM -0600, Jason Gunthorpe wrote:
On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:
The eprom device is for low level programming of the eprom on the
chip. We do not use i2c for this because the eprom is directly
attached to the chip and not
On Wed, Apr 20, 2016 at 02:36:16PM -0600, Jason Gunthorpe wrote:
On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:
The eprom device is for low level programming of the eprom on the
chip. We do not use i2c for this because the eprom is directly
attached to the chip and not
On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:
> The eprom device is for low level programming of the eprom on the
> chip. We do not use i2c for this because the eprom is directly
> attached to the chip and not accessible via i2c, requires register
> access.
Okay, but the
On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:
> The eprom device is for low level programming of the eprom on the
> chip. We do not use i2c for this because the eprom is directly
> attached to the chip and not accessible via i2c, requires register
> access.
Okay, but the
On Mon, Apr 18, 2016 at 11:45:49PM -0400, Ira Weiny wrote:
> I'm a bit confused by what you are suggesting that "people will have to patch
> the driver with some vendor version if they really need it."?
>
> Could you elaborate?
There are lots of drivers where we simply did not accept these
On Mon, Apr 18, 2016 at 11:45:49PM -0400, Ira Weiny wrote:
> I'm a bit confused by what you are suggesting that "people will have to patch
> the driver with some vendor version if they really need it."?
>
> Could you elaborate?
There are lots of drivers where we simply did not accept these
On Mon, Apr 18, 2016 at 11:24:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> > I wasn't arguing this should integrate into verbs in some way, only
> > that the way to access the driver-specific uAPI of a RDMA device should
> > be through
On Mon, Apr 18, 2016 at 11:24:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> > I wasn't arguing this should integrate into verbs in some way, only
> > that the way to access the driver-specific uAPI of a RDMA device should
> > be through
On Mon, Apr 18, 2016 at 11:24:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> > I wasn't arguing this should integrate into verbs in some way, only
> > that the way to access the driver-specific uAPI of a RDMA device should
> > be through
On Mon, Apr 18, 2016 at 11:24:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> > I wasn't arguing this should integrate into verbs in some way, only
> > that the way to access the driver-specific uAPI of a RDMA device should
> > be through
On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> I wasn't arguing this should integrate into verbs in some way, only
> that the way to access the driver-specific uAPI of a RDMA device should
> be through the RDMA common uAPI and not through a random char dev.
Well, it's stuff
On Mon, Apr 18, 2016 at 11:40:47AM -0600, Jason Gunthorpe wrote:
> I wasn't arguing this should integrate into verbs in some way, only
> that the way to access the driver-specific uAPI of a RDMA device should
> be through the RDMA common uAPI and not through a random char dev.
Well, it's stuff
On Mon, Apr 18, 2016 at 06:09:09AM -0700, Christoph Hellwig wrote:
> 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
On Mon, Apr 18, 2016 at 06:09:09AM -0700, Christoph Hellwig wrote:
> 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
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
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
On Sat, Apr 16, 2016 at 08:19:17PM +0100, Al Viro wrote:
While we are at it, could the person who'd come up with ui_lseek() be located
and made to stand up and explain the rationale behind the SEEK_END semantics
therein? To quote the manpage (and paraphrase just about any introductory
On Sat, Apr 16, 2016 at 08:19:17PM +0100, Al Viro wrote:
While we are at it, could the person who'd come up with ui_lseek() be located
and made to stand up and explain the rationale behind the SEEK_END semantics
therein? To quote the manpage (and paraphrase just about any introductory
On Sat, Apr 16, 2016 at 09:00:42AM +0300, Leon Romanovsky wrote:
> On Fri, Apr 15, 2016 at 05:37:32PM -0600, Jason Gunthorpe wrote:
> > On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
> >
> > > Intel as usual decided to do it in their way and the result is presented
> > > on this
On Sat, Apr 16, 2016 at 09:00:42AM +0300, Leon Romanovsky wrote:
> On Fri, Apr 15, 2016 at 05:37:32PM -0600, Jason Gunthorpe wrote:
> > On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
> >
> > > Intel as usual decided to do it in their way and the result is presented
> > > on this
On Sat, Apr 16, 2016 at 09:09:40AM +0300, Leon Romanovsky wrote:
On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote:
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
Do you have a technical reason that this patch series does not fix the
write/writev issue brought up by
On Sat, Apr 16, 2016 at 09:09:40AM +0300, Leon Romanovsky wrote:
On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote:
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
Do you have a technical reason that this patch series does not fix the
write/writev issue brought up by
On Fri, Apr 15, 2016 at 05:37:32PM -0600, Jason Gunthorpe wrote:
> On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
>
> > Intel as usual decided to do it in their way and the result is presented
> > on this mailing list.
>
> Dennis was pretty clear he was going to send the
On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote:
> On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
> Do you have a technical reason that this patch series does not fix the
> write/writev issue brought up by Al?
Sure, I truly believe that we can do common API in a months
On Fri, Apr 15, 2016 at 05:37:32PM -0600, Jason Gunthorpe wrote:
> On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
>
> > Intel as usual decided to do it in their way and the result is presented
> > on this mailing list.
>
> Dennis was pretty clear he was going to send the
On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote:
> On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
> Do you have a technical reason that this patch series does not fix the
> write/writev issue brought up by Al?
Sure, I truly believe that we can do common API in a months
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
> Intel as usual decided to do it in their way and the result is presented
> on this mailing list.
Dennis was pretty clear he was going to send the patches to address
Al's concern, which he has done.
I was also pretty clear I was
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
> Intel as usual decided to do it in their way and the result is presented
> on this mailing list.
Dennis was pretty clear he was going to send the patches to address
Al's concern, which he has done.
I was also pretty clear I was
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
>
> Intel as usual decided to do it in their way and the result is presented
> on this mailing list.
Excuse me, but this statement is completely unfair. We were specifically asked
by Al and Linus to fix our char device with
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
>
> Intel as usual decided to do it in their way and the result is presented
> on this mailing list.
Excuse me, but this statement is completely unfair. We were specifically asked
by Al and Linus to fix our char device with
On Fri, Apr 15, 2016 at 10:34:01AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 15, 2016 at 08:30:35PM +0300, Leon Romanovsky wrote:
> > Great, did you show it to other RDMA stakeholders except Intel?
> > I saw nothing posted on ML or proposed for initial discussion, which
> > will be held in the
On Fri, Apr 15, 2016 at 05:44:48PM +, Woodruff, Robert J wrote:
> > I fear it's kfabrics, which is an entirely crackpot idea and a total
> > non-starter, but for some reason Intel and their buddies keep wasting time
> > on it.
>
> What is being discussed her is not kfabrics. That is a
On Fri, Apr 15, 2016 at 10:34:01AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 15, 2016 at 08:30:35PM +0300, Leon Romanovsky wrote:
> > Great, did you show it to other RDMA stakeholders except Intel?
> > I saw nothing posted on ML or proposed for initial discussion, which
> > will be held in the
On Fri, Apr 15, 2016 at 05:44:48PM +, Woodruff, Robert J wrote:
> > I fear it's kfabrics, which is an entirely crackpot idea and a total
> > non-starter, but for some reason Intel and their buddies keep wasting time
> > on it.
>
> What is being discussed her is not kfabrics. That is a
> > Great, did you show it to other RDMA stakeholders except Intel?
> > I saw nothing posted on ML or proposed for initial discussion, which
> > will be held in the next week or two.
>
> I fear it's kfabrics, which is an entirely crackpot idea and a total
> non-starter, but for some reason Intel
> > Great, did you show it to other RDMA stakeholders except Intel?
> > I saw nothing posted on ML or proposed for initial discussion, which
> > will be held in the next week or two.
>
> I fear it's kfabrics, which is an entirely crackpot idea and a total
> non-starter, but for some reason Intel
> I fear it's kfabrics, which is an entirely crackpot idea and a total
> non-starter, but for some reason Intel and their buddies keep wasting time on
> it.
What is being discussed her is not kfabrics. That is a totally different out of
kernel pathfinding project at this point.
What is being
> I fear it's kfabrics, which is an entirely crackpot idea and a total
> non-starter, but for some reason Intel and their buddies keep wasting time on
> it.
What is being discussed her is not kfabrics. That is a totally different out of
kernel pathfinding project at this point.
What is being
On Fri, Apr 15, 2016 at 08:30:35PM +0300, Leon Romanovsky wrote:
> Great, did you show it to other RDMA stakeholders except Intel?
> I saw nothing posted on ML or proposed for initial discussion, which
> will be held in the next week or two.
I fear it's kfabrics, which is an entirely crackpot
On Fri, Apr 15, 2016 at 08:30:35PM +0300, Leon Romanovsky wrote:
> Great, did you show it to other RDMA stakeholders except Intel?
> I saw nothing posted on ML or proposed for initial discussion, which
> will be held in the next week or two.
I fear it's kfabrics, which is an entirely crackpot
On Fri, Apr 15, 2016 at 12:17:55PM -0400, Ira Weiny wrote:
> On Fri, Apr 15, 2016 at 07:01:26AM +0300, Leon Romanovsky wrote:
> > On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> > > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote:
> > > > On Thu, Apr 14, 2016 at
On Fri, Apr 15, 2016 at 12:17:55PM -0400, Ira Weiny wrote:
> On Fri, Apr 15, 2016 at 07:01:26AM +0300, Leon Romanovsky wrote:
> > On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> > > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote:
> > > > On Thu, Apr 14, 2016 at
On Fri, Apr 15, 2016 at 07:01:26AM +0300, Leon Romanovsky wrote:
> On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> > 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
On Fri, Apr 15, 2016 at 07:01:26AM +0300, Leon Romanovsky wrote:
> On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> > 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
On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> 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
> > >
On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> 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
> > >
On Thu, Apr 14, 2016 at 02:42:01PM -0400, Dennis Dalessandro wrote:
> >It certainly can't be years.
>
> Does fixing the current write()/writev() problem have any real
> impact on how we proceed for the "1 char dev to rule them all" idea?
We aren't going to take a bad uAPI into mainline. So how
On Thu, Apr 14, 2016 at 02:42:01PM -0400, Dennis Dalessandro wrote:
> >It certainly can't be years.
>
> Does fixing the current write()/writev() problem have any real
> impact on how we proceed for the "1 char dev to rule them all" idea?
We aren't going to take a bad uAPI into mainline. So how
On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:
> 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
>
On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:
> 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
>
On Thu, Apr 14, 2016 at 12:05:40PM -0600, Jason Gunthorpe wrote:
There are some pretty obvious paths to make this saner that could only
be a few weeks away, we haven't even had the first conversations
yet. I think you are completely wrong there is no 'line of sight'
It certainly can't be years.
On Thu, Apr 14, 2016 at 12:05:40PM -0600, Jason Gunthorpe wrote:
There are some pretty obvious paths to make this saner that could only
be a few weeks away, we haven't even had the first conversations
yet. I think you are completely wrong there is no 'line of sight'
It certainly can't be years.
On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> 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
> > >
On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> 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
> > >
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
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
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
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
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
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
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:
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:
64 matches
Mail list logo
