DISK(9)

πŸ’Ύ DISK(9) β€” kernel disk storage API πŸ’Ύ

okay bestie, gather round, because this is the disk(9) manual page from the Kernel Developer's Manual, and it's literally the whole vibe of "hey kernel driver, tell everyone about your disk". no cap.


✨ NAME ✨

disk β€” kernel disk storage API 🫢


🌸 SYNOPSIS 🌸

#include <geom/geom_disk.h>

struct disk *
disk_alloc(void);

void
disk_create(struct disk *disk, int version);

void
disk_gone(struct disk *disk);

void
disk_destroy(struct disk *disk);

int
disk_resize(struct disk *disk, int flags);

void
disk_add_alias(struct disk *disk, const char *alias);

πŸ’… DESCRIPTION πŸ’…

so the disk storage API is the lil' matchmaker that lets kernel device drivers for disk-like storage devices advertise themselves to the rest of the kernel, including GEOM(4) and devfs(5). it's giving "introducing my device to the group chat". ✨

every disk device gets described by a struct disk structure, which holds a whole bunch of parameters for the disk device, function pointers for the various methods that might get performed on the device, plus some private data storage for the device driver. and on top of that, some fields are reserved for GEOM to manage access to the device and its statistics. πŸ’–

GEOM owns struct disk, periodt. drivers have to allocate storage for it with disk_alloc(), fill in the fields, and call disk_create() when the device is ready to service requests. disk_add_alias() adds an alias for the disk and must be called before disk_create(), but you can call it multiple times, no problem. for each alias you add, a device node gets created with make_dev_alias(9) β€” same way primary device nodes get created with make_dev(9) for d_name and d_unit. πŸŽ€

be careful bestie: make sure that only one driver creates aliases for any given name. we don't do duplicate drama here. 😭

disk_resize() can be called by the driver after modifying d_mediasize to notify GEOM about the disk capacity change. the flags field should be set to either M_WAITOK, or M_NOWAIT. 🌈

disk_gone() orphans all of the providers associated with the drive, setting an error condition of ENXIO in each one. plus, it prevents a re-taste on last close for writing if an error condition has been set in the provider. and after you call disk_destroy(), the device driver is not allowed to access the contents of struct disk anymore. like, at all. it's over, babe. πŸ’€

the disk_create() function takes a second parameter, version, which must always be passed DISK_VERSION. if GEOM detects that the driver is compiled against an unsupported version, it will ignore the device and print a warning on the console. 😬


🌟 Descriptive Fields 🌟

these fields identify the disk device described by the structure instance. you must fill them in prior to submitting the structure to disk_create(), and they may not be subsequently changed. so get it right the first time, queen. πŸ‘‘

  • u_int d_flags β€” optional flags telling the storage framework what optional features or descriptions the storage device driver supports. currently supported flags are DISKFLAG_OPEN (maintained by storage framework), DISKFLAG_CANDELETE (maintained by device driver), and DISKFLAG_CANFLUSHCACHE (maintained by device driver). ✨
  • const char * d_name β€” holds the name of the storage device class, e.g., β€œahd”. this value typically uniquely identifies a particular driver device, and it must not conflict with devices serviced by other device drivers. iykyk. πŸ’–
  • u_int d_unit β€” holds the instance of the storage device class, e.g., β€œ4”. this namespace is managed by the device driver, and assignment of unit numbers might be a property of probe order, or in some cases topology. together, the d_name and d_unit values will uniquely identify a disk storage device. πŸ¦‹

πŸŽ€ Disk Device Methods πŸŽ€

these fields identify various disk device methods, if implemented:

  • disk_open_t * d_open β€” optional: invoked when the disk device is opened. if no method is provided, open will always succeed. slay, no gatekeeping. ✨
  • disk_close_t * d_close β€” optional: invoked when the disk device is closed. although an error code may be returned, the call should always terminate any state setup by the corresponding open method call. 🌸
  • disk_strategy_t * d_strategy β€” mandatory: invoked when a new struct bio is to be initiated on the disk device. this one is not optional bestie, it's the main character. πŸ‘‘
  • disk_ioctl_t * d_ioctl β€” optional: invoked when an I/O control operation is initiated on the disk device. please note that for security reasons these operations should not be able to affect other devices than the one on which they are performed. stay in your lane, respectfully. πŸ™ˆ
  • dumper_t * d_dump β€” optional: if configured with dumpon(8), this function is invoked from a very restricted system state after a kernel panic to record a copy of the system RAM to the disk. 😭 this is the "we're so back" function.
  • disk_getattr_t * d_getattr β€” optional: if this method is provided, it gives the disk driver the opportunity to override the default GEOM response to BIO_GETATTR requests. this function should return -1 if the attribute is not handled, 0 if the attribute is handled, or an errno to be passed to g_io_deliver(). πŸ’…
  • disk_gone_t * d_gone β€” optional: if this method is provided, it will be called after disk_gone() is called, once GEOM has finished its cleanup process. once this callback is called, it is safe for the disk driver to free all of its resources, as it will not be receiving further calls from GEOM. 🫢

πŸ’– Mandatory Media Properties πŸ’–

these fields identify the size and granularity of the disk device. they must stay stable from return of the drivers open method until the close method is called, but it is perfectly legal to modify them in the open method before returning. ✨

  • u_int d_sectorsize β€” the sector size of the disk device in bytes.
  • off_t d_mediasize β€” the size of the disk device in bytes.
  • u_int d_maxsize β€” the maximum supported size in bytes of an I/O request. requests larger than this size will be chopped up by GEOM. πŸ”ͺ

πŸ¦‹ Optional Media Properties πŸ¦‹

these optional fields can provide extra information about the disk device. do not initialize these fields if the field/concept does not apply. they must stay stable from return of the drivers open method until the close method is called, but it is perfectly legal to modify them in the open method before returning. πŸ’œ

  • u_int d_fwsectors, u_int d_fwheads β€” the number of sectors and heads advertised on the disk device by the firmware or BIOS. these values are almost universally bogus, but on some architectures necessary for the correct calculation of disk partitioning. 😭 iconic honestly.
  • u_int d_stripeoffset, u_int d_stripesize β€” these two fields can be used to describe the width and location of natural performance boundaries for most disk technologies. please see src/sys/geom/notes for details. πŸ”₯
  • char d_ident[DISK_IDENT_SIZE] β€” this field can and should be used to store disk's serial number if the d_getattr method described above isn't implemented, or if it does not support the GEOM::ident attribute. πŸŽ€
  • char d_descr[DISK_IDENT_SIZE] β€” this field can be used to store the disk vendor and product description.
  • uint16_t d_hba_vendor β€” this field can be used to store the PCI vendor ID for the HBA connected to the disk.
  • uint16_t d_hba_device β€” this field can be used to store the PCI device ID for the HBA connected to the disk.
  • uint16_t d_hba_subvendor β€” this field can be used to store the PCI subvendor ID for the HBA connected to the disk.
  • uint16_t d_hba_subdevice β€” this field can be used to store the PCI subdevice ID for the HBA connected to the disk.

🌈 Driver Private Data 🌈

this field may be used by the device driver to store a pointer to private data to implement the disk service. it's your little pocket, bestie. πŸ“

  • void * d_drv1 β€” private data pointer. typically used to store a pointer to the drivers softc structure for this disk device.

⭐ SEE ALSO ⭐

GEOM(4), devfs(5), MAKE_DEV(9)


πŸ‘‘ AUTHORS πŸ‘‘

this manual page was written by Robert Watson. πŸ’– thank you for your service, king.


πŸ’€ BUGS πŸ’€

disk aliases are not a general purpose aliasing mechanism, but are intended only to ease the transition from one name to another. they can be used to ensure that nvd0 and nda0 are the same thing. they cannot be used to implement the diskX concept from macOS. soz, that's just not what this is. πŸ™ˆ


and that's the whole page, bestie!! this one came from the Debian flavour of the manual, dated August 3, 2017, and it's filed under DISK(9). go forth and advertise your disks responsibly. πŸ’…βœ¨

πŸ“¦ where this page comes from