On Thu, Jan 26, 2017 at 10:17:58AM +0100, Greg KH wrote:
> Ok, but do you feel the "loop method" of using a char device node to
> create/control these devices is a good model to follow for new devices
> like ndb?
Yes. We've done the same for NVMe over fabrics.
On Thu, Jan 26, 2017 at 12:40:47AM -0800, Christoph Hellwig wrote:
> On Wed, Jan 25, 2017 at 03:36:20PM -0600, Eric Blake wrote:
> > How do you get an fd to existing nbd block device? Your intent is to
> > use an ioctl to request creating/opening a new nbd device that no one
> > else is using;
On Wed, Jan 25, 2017 at 03:36:20PM -0600, Eric Blake wrote:
> How do you get an fd to existing nbd block device? Your intent is to
> use an ioctl to request creating/opening a new nbd device that no one
> else is using; opening an existing device in order to send that ioctl
> may have negative
On 01/25/2017 03:30 PM, Greg KH wrote:
>> Given (because of NBD_DO_IT) we need an ioctl anyway, and we have
>> an ioctl that isn't going to go away, it would seem better if possible
>> to stick with ioctls, and not introduce either a dependency
>> on netlink (which would presumably bloat static
On Wed, Jan 25, 2017 at 06:25:11PM +, Alex Bligh wrote:
>
> > On 25 Jan 2017, at 16:48, Alex Gartrell wrote:
> >
> >
> > If nbd were *all* netlink I think that that'd be fine, but you'd have
> > problems implementing the NBD_DOIT function in that fashion. So I'd
> >
On Wed, Jan 25, 2017 at 9:23 AM, Arnd Bergmann wrote:
>
> They all have their own set of problems, but the needs of nbd as a network
> storage interface seem most closely resemble what we have for other network
> related interfaces, where we typically use netlink to do the setup,
> On 25 Jan 2017, at 16:48, Alex Gartrell wrote:
>
>
> If nbd were *all* netlink I think that that'd be fine, but you'd have
> problems implementing the NBD_DOIT function in that fashion. So I'd
> rather stick to the char device ioctl thing because it's more
> consistent
On Wed, Jan 25, 2017 at 04:48:27PM +, Alex Gartrell wrote:
> On 1/25/17, 6:23 AM, "arndbergm...@gmail.com on behalf of Arnd Bergmann"
> wrote:
> > We have multiple established ways to deal with this kind of problem, the
> > most
> > common
On 1/25/17, 6:23 AM, "arndbergm...@gmail.com on behalf of Arnd Bergmann"
wrote:
> On Wed, Jan 25, 2017 at 2:47 PM, Josef Bacik wrote:
> > On Tue, Jan 24, 2017 at 2:11 AM, Greg KH wrote:
> >> On Mon,
On Wed, Jan 25, 2017 at 2:47 PM, Josef Bacik wrote:
> On Tue, Jan 24, 2017 at 2:11 AM, Greg KH wrote:
>> On Mon, Jan 23, 2017 at 10:52:42AM -0500, Josef Bacik wrote:
>>> On Mon, Jan 23, 2017 at 10:03 AM, Greg KH
>>> Loop
On Tue, Jan 24, 2017 at 2:11 AM, Greg KH
wrote:
> On Mon, Jan 23, 2017 at 10:52:42AM -0500, Josef Bacik wrote:
>> On Mon, Jan 23, 2017 at 10:03 AM, Greg KH
>>
>> wrote:
>> > On Mon, Jan 23, 2017 at 09:57:52AM -0500, Josef Bacik wrote:
On Tue, Jan 24, 2017 at 08:11:52AM +0100, Greg KH wrote:
> On Mon, Jan 23, 2017 at 10:52:42AM -0500, Josef Bacik wrote:
> > I explained it in the changelog and my response to Wouter. NBD preallocates
> > all of its /dev/nbd# devices at modprobe time, so there's no way to add new
> > devices as we
On Mon, Jan 23, 2017 at 10:52:42AM -0500, Josef Bacik wrote:
> On Mon, Jan 23, 2017 at 10:03 AM, Greg KH
> wrote:
> > On Mon, Jan 23, 2017 at 09:57:52AM -0500, Josef Bacik wrote:
> > > On Mon, Jan 23, 2017 at 9:52 AM, Greg KH
> > > wrote:
On Mon, Jan 23, 2017 at 10:03 AM, Greg KH
wrote:
> On Mon, Jan 23, 2017 at 09:57:52AM -0500, Josef Bacik wrote:
>> On Mon, Jan 23, 2017 at 9:52 AM, Greg KH
>> wrote:
>> > On Mon, Jan 23, 2017 at 09:42:08AM -0500, Josef Bacik wrote:
>>
On Mon, Jan 23, 2017 at 09:57:52AM -0500, Josef Bacik wrote:
> On Mon, Jan 23, 2017 at 9:52 AM, Greg KH wrote:
> > On Mon, Jan 23, 2017 at 09:42:08AM -0500, Josef Bacik wrote:
> > >
> > >
> > > On Sat, Jan 21, 2017 at 4:05 AM, Greg KH
> > >
On Mon, Jan 23, 2017 at 09:42:08AM -0500, Josef Bacik wrote:
>
>
> On Sat, Jan 21, 2017 at 4:05 AM, Greg KH wrote:
> > On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote:
> > > This patch mirrors the loop back device behavior with a few
> > > changes.
On Sat, Jan 21, 2017 at 4:05 AM, Greg KH
wrote:
> On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote:
>> This patch mirrors the loop back device behavior with a few
>> changes. First
>> there is no DEL operation as NBD doesn't get as much churn as loop
On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote:
> This patch mirrors the loop back device behavior with a few changes. First
> there is no DEL operation as NBD doesn't get as much churn as loop devices do.
> Secondly the GET_NEXT operation can optionally create a new NBD device or
On Fri, Jan 20, 2017 at 04:56:52PM -0500, Josef Bacik wrote:
> This patch mirrors the loop back device behavior with a few changes. First
> there is no DEL operation as NBD doesn't get as much churn as loop devices do.
> Secondly the GET_NEXT operation can optionally create a new NBD device or
This patch mirrors the loop back device behavior with a few changes. First
there is no DEL operation as NBD doesn't get as much churn as loop devices do.
Secondly the GET_NEXT operation can optionally create a new NBD device or not.
Our infrastructure people want to not allow NBD to create new
20 matches
Mail list logo