All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Matthew Broomfield <mattysweeps@google.com>
Cc: linux-block@vger.kernel.org, ming.lei@redhat.com
Subject: Re: ublk: expose ublk device info in sysfs or support ioctls on ublk-control
Date: Fri, 7 Feb 2025 13:13:40 -0700	[thread overview]
Message-ID: <Z6ZpdKDo7Ao803NP@kbusch-mbp> (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?
> 
> 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)

It's really not that difficult to make an equivalent ioctl from an
existing uring_cmd.

I think it would be even easier if the ioctl was exposed on the
/dev/ublkcX device instead of the general purpose ublk-control. This way
you can just use the path of the device you want to query instead of
having to look up its dev_id.

  reply	other threads:[~2025-02-07 20:13 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 [this message]
2025-02-08  6:03 ` Ming Lei

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=Z6ZpdKDo7Ao803NP@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=mattysweeps@google.com \
    --cc=ming.lei@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.