Support for search by disk id module

Support for search by disk id module

[Mat628]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

Hi,

I wanted to verify/clarify what would be an acceptable format for a disk id to be used as a search parameter for a module to return the associated device.

Where on Linux, devices are mapped to a hardware specific path.
For hard disks it is

type-product_serial(-partition#)

ata-ST42443343DR_6GE23Y09
ata-ST42443343DR_6GE23Y09-part1

But for a USB flash drive it is

type-vendor_product_serial-(?physical id?)-(part#)

usb-SanDisk_Ultra_4E53324345657878876543-0:0-part1

where product = model name

Would it be okay to shorten this for USB flash drive to

type-product_serial-(part#) ?

usb-Ultra_4E53324345657878876543-part1

To help keep it to a minimal amount of characters the user would have to type. While ensuring the shortened version would not impact its reliability to return the correct device. Even the 'type' could be removed if that is okay with you?

Best regards,

Matt

[-- Attachment #2: Type: text/html, Size: 1524 bytes --]

Re: Support for search by disk id module

[Andrei Borzenkov]

15.04.2017 13:55, Mat628 пишет:
> Hi,
> 
> I wanted to verify/clarify what would be an acceptable format for a disk id to be used as a search parameter for a module to return the associated device.
> 
> Where on Linux, devices are mapped to a hardware specific path.
> For hard disks it is
> 
> type-product_serial(-partition#)
> 

There is no established standard and this changed over time. GRUB uses
platform firmware to access devices, so it can only use information
firmware exports. In general we have no way to query for this information.


> ata-ST42443343DR_6GE23Y09
> ata-ST42443343DR_6GE23Y09-part1
> 
> But for a USB flash drive it is
> 
> type-vendor_product_serial-(?physical id?)-(part#)
> 
> usb-SanDisk_Ultra_4E53324345657878876543-0:0-part1
> 
> where product = model name
> 
> Would it be okay to shorten this for USB flash drive to
> 
> type-product_serial-(part#) ?
> 
> usb-Ultra_4E53324345657878876543-part1
> 
> To help keep it to a minimal amount of characters the user would have to type. While ensuring the shortened version would not impact its reliability to return the correct device. Even the 'type' could be removed if that is okay with you?
> 
> Best regards,
> 
> Matt
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: Support for search by disk id module

[Mat628]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

There is no established standard and this changed over time. GRUB uses
platform firmware to access devices, so it can only use information
firmware exports. In general we have no way to query for this information.

Would it be considered acceptable to call nativedisk.mod to allow for query
of this information? i.e. instead of hd0 it would ata0 or usb0.

[-- Attachment #2: Type: text/html, Size: 545 bytes --]

Re: Support for search by disk id module

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Sat, Apr 15, 2017, 21:27 Mat628 <mat628@protonmail.com> wrote:

>
> There is no established standard and this changed over time. GRUB uses
> platform firmware to access devices, so it can only use information
> firmware exports. In general we have no way to query for this information.
>
>
> Would it be considered acceptable to call nativedisk.mod to allow for
> query
> of this information? i.e. instead of hd0 it would ata0 or usb0.
>
No. Nativedisk solves some very specific problems. It's not for general use

> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 1418 bytes --]

Re: Support for search by disk id module

[Andrei Borzenkov]

15.04.2017 14:27, Mat628 пишет:
> There is no established standard and this changed over time. GRUB uses
> platform firmware to access devices, so it can only use information
> firmware exports. In general we have no way to query for this information.
> 
> Would it be considered acceptable to call nativedisk.mod to allow for query
> of this information? i.e. instead of hd0 it would ata0 or usb0.
> 

a) You cannot really "call into" nativedisk; it replaces biosdisk which
has some consequences, like not being able to load anything that relies
on BIOS (most obvious is chainloading)

b) any solution should work for all platforms, not only i386-pc.

Re: Support for search by disk id module

[Mat628]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

No. Nativedisk solves some very specific problems. It's not for general use
Okay the reason I was asking is to help solve the problem of reliably finding the correct device for a LUKS device with detached header. I previously wrote a search by disk/part UUID/GUID module which returned the device when given the disk/part UUID/GUID for either an 'MSDOS' or 'GPT' type partition or a 'biosdisk' or 'efidisk' with the partition types respectfully.

I now have a working search by disk id module for an 'ata' or 'usb' disk that will return the device when given the disk id. I was also able to add these commands directly to cryptodisk. And have successfully been able to mount using

insmod nativedisk
cryptomount --diskid ata-ST42443343DR_6GE23Y09-part1

If the user has a LUKS device with a detached header or plain dm-crypt device would you consider that to be more of a specific use case?

[-- Attachment #2: Type: text/html, Size: 1109 bytes --]