linux-kernel - Re: allocate an official device major number for virtio device?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2016 14:43:35 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Jeff Sharkey <jsharkey@...roid.com>
Cc:	Jin Qian <jinqian@...roid.com>, "Ning, Yu" <yu.ning@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Turner <digit@...gle.com>,
	"pprabhu@...gle.com" <pprabhu@...gle.com>
Subject: Re: allocate an official device major number for virtio device?

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Thu, Mar 03, 2016 at 03:12:04PM -0700, Jeff Sharkey wrote:
> Adding a bit more context, in Android when we receive a uevent about a
> new disk we use a separate userspace utility (sgdisk) to inspect the
> partitions it contains, and we construct our own mknod() for the
> partitions that we're interested in.  (We're doing this manually
> because Android doesn't have devtmpfs.)

Note, you can easily fix the 'no devtmpfs' issue :)

Well, not "easily" but note that because Android diverged from the
traditional (i.e. standard) device naming scheme, you all really are on
your own here, this is your own hole you have dug yourself into, I have
very little sympathy at all, sorry.

> Disks with GPT can have up to 128 partitions, but when mknod()'ing the
> partition devices I need to carefully ignore any partitions beyond the
> maximum number of partitions supported by the underlying device
> system, otherwise I risk jumping into the next disk.  The maximum
> number of partitions appears to be well-known for certain major device
> numbers (Documentation/devices.txt says 15 for SCSI, or reading
> perdev_minors for MMC).
> 
> Is there a good way to determine this upper limit for disks surfaced
> through virtio_blk?  Currently I've been using the major device number
> as a heuristic, which is what kicked off this entire discussion.

The kernel should know about this already, doesn't /sys/dev/block/
already contain pointers to the known partitions?  If not, how are you
creating a partition that the kernel doesn't know about?

And why not just use libudev and the disk probing tools that it provides
already for all of this instead of using something "non-standard" (i.e.
sgdisk)?  It already has worked all of this out for you, why reimplement
the wheel again?

thanks,

greg k-h