linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oded Gabbay <oded.gabbay@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	Omer Shpigelman <oshpigelman@habana.ai>,
	Tomer Tayar <ttayar@habana.ai>
Subject: Re: [PATCH v2 7/7] habanalabs: create two char devices per ASIC
Date: Tue, 30 Jul 2019 14:23:57 +0300	[thread overview]
Message-ID: <CAFCwf11VFEN0o1sAxPjuv3SvoebD_C4QLrsc9Ea8GiVRdztbnA@mail.gmail.com> (raw)
In-Reply-To: <20190730104207.GB7325@kroah.com>

On Tue, Jul 30, 2019 at 1:42 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jul 30, 2019 at 12:47:24PM +0300, Oded Gabbay wrote:
> > This patch changes the driver to create two char devices for each ASIC
> > it discovers. This is done to allow system/monitoring applications to
> > query the device for stats, information, idle state and more, while also
> > allowing the deep-learning application to send work to the ASIC.
> >
> > One char device is the original device, hlX. IOCTL calls through this
> > device file can perform any task on the device (compute, memory, queries).
> > The open function for this device will fail if it was called before but
> > the file-descriptor it created was not completely released yet (the
> > release callback function is not called from the kernel until all
> > instances of that FD are closed). The driver needs to keep this behavior
> > to support backward compatibility with existing userspace, which count
> > that the open will fail if the device is "occupied".
> >
> > The second char device is called "hl_controlDx", where x is the minor
> > number of the original char device + 64 (HL_CONTROL_MINOR). Applications
> > that open this device can only call the INFO IOCTL. There is no limitation
> > on the number of applications opening this device.
> >
> > Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
>
> This reminds me of the old tty "control" devices we finally got rid of
> many years ago.  The more things change... :)
>
> Anyway, looks sane to me.  If you are ok with this userspace api, no
> objection from me.
>
> Only one comment below:
>
> > --- a/drivers/misc/habanalabs/habanalabs.h
> > +++ b/drivers/misc/habanalabs/habanalabs.h
> > @@ -51,6 +51,8 @@
> >  /* MMU */
> >  #define MMU_HASH_TABLE_BITS          7 /* 1 << 7 buckets */
> >
> > +#define HL_CONTROL_MINOR             64
>
> Don't try to segment your "dev" and "control" device nodes by minor
> number range, as you will run into problems once you have a system with
> more than 64 of these in the box at once.
>
> Just use the whole range, and do:
>         dev = minor N
>         control = minor N+1
> and so on.  That makes your control device node an "odd" minor and your
> "real" device an "even".
>
> Given that all existing systems should be using devtmpfs, you should not
> have any problem with changing the minor number of them at the next
> reboot, right?
>
> thanks,
>
> greg k-h

I agree, will change that and re-send.
Oded

      reply	other threads:[~2019-07-30 11:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30  9:47 [PATCH v2 0/7] habanalabs: support info queries by multiple processes Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 1/7] habanalabs: add handle field to context structure Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 2/7] habanalabs: kill user process after CS rollback Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 3/7] habanalabs: show the process context dram usage Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 4/7] habanalabs: rename user_ctx as compute_ctx Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 5/7] habanalabs: maintain a list of file private data objects Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 6/7] habanalabs: change device_setup_cdev() to be more generic Oded Gabbay
2019-07-30  9:47 ` [PATCH v2 7/7] habanalabs: create two char devices per ASIC Oded Gabbay
2019-07-30 10:42   ` Greg KH
2019-07-30 11:23     ` Oded Gabbay [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFCwf11VFEN0o1sAxPjuv3SvoebD_C4QLrsc9Ea8GiVRdztbnA@mail.gmail.com \
    --to=oded.gabbay@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oshpigelman@habana.ai \
    --cc=ttayar@habana.ai \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).