public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Matthew Broomfield <mattysweeps@google.com>
Cc: linux-block@vger.kernel.org
Subject: Re: ublk: expose ublk device info in sysfs or support ioctls on ublk-control
Date: Sat, 8 Feb 2025 14:03:19 +0800	[thread overview]
Message-ID: <Z6bzpx5jxH3F8ebP@fedora> (raw)
In-Reply-To: <CALEiSPxGXy5faNFiiPt_tOF=K2cS=02RVdjw1JGuokNV7JPHJw@mail.gmail.com>

On Fri, Feb 07, 2025 at 11:50:33AM -0800, Matthew Broomfield wrote:
> Hi all,
> 
> It would be great if there was a sysfs file which exposed "struct
> ublksrv_ctrl_dev_info" so programs written in languages without
> io_uring libraries (such as python) could easily read this information
> for management, testing, or record keeping. Ideally if possible this
> could be something like "/sys/block/ublkbX/ublk_info". Is this
> possible?

It is doable, but depends if it is necessary.

The device info can be stored in FS by ublk server, and the file
lifetime can be aligned with the ublk device, then python tool
can read it from FS directly.

> 
> Alternatively, the "/dev/ublk-control" file could support ioctls which
> mimic the io_uring cmds such as UBLK_CMD_GET_DEV_INFO,
> UBLK_CMD_ADD_DEV, etc. This would be more powerful as the block device
> lifecycle management program could be completely independent of both
> io_uring and the program which handles the block IO. However I'm
> skeptical it's worth it in the long run to create a ioctl -> io_uring
> adapter. (As opposed to languages natively supporting io_uring)

I'd suggest to not add ioctl, uring_cmd is async, which can help to
setup ublk device in completely async way, and I remember that someone
has asked if lots of ublk device can be created in single pthread
context.


Thanks,
Ming


      parent reply	other threads:[~2025-02-08  6:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-07 19:50 ublk: expose ublk device info in sysfs or support ioctls on ublk-control Matthew Broomfield
2025-02-07 20:13 ` Keith Busch
2025-02-08  6:03 ` Ming Lei [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=Z6bzpx5jxH3F8ebP@fedora \
    --to=ming.lei@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mattysweeps@google.com \
    /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