Re: disk driver interface

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Dec 29,  3:00am, Michael van Elst wrote:
} 
} Currently NetBSD has three programming interfaces to determine
} disk geometry from userland.
} 
} - ioctl DIOCGDINFO. The traditional interface, limited to 32bit
}   numbers or disks < 2TB because its data structure corresponds
}   to the binary on-disk structure.
} 
} - the "get-properties" command to the drvctl(4) driver. drvctl(4)
}   is missing on some ports and some disk drivers don't make
}   geometry properties available.
} 
} - ioctl DIOCGWEDGEINFO. Works only for wedges but not for the
}   disk drivers themselves. This is fine for operations on
}   data blocks of a wedge but doesn't help e.g. partitioning
}   tools. It also does not provide the sector size.
} 
} To solve this, we could
} 
} - create a new DIOCGDINFO version that uses larger numbers. AFAIK
}   that is about what OpenBSD does. The on-disk structure could be
}   translated but writing a label might be incompatible if partitions
}   are defined beyond the 2TB limit.
} 
} - make drvctl(4) mandatory and make all disk drivers provide
}   geometry properties.

     I would tend to go with this since it is used for a lot more
then just getting the geometry of a drive.

} - make DIOCGWEDGEINFO available for the disk drivers and
}   ignore wedge-related information.
} 
} - import FreeBSD DIOCGMEDIASIZE (and DIOCGSECTORSIZE) ioctls.
} 
} 
} Comments?

     I really don't care about this silly little issue.  But, as
a side note, I will note that gpt(8) (which originated this thread)
came from FreeBSD so it already has support for the FreeBSD ioctls
and would use them in preference to drvctl(4) method if they existed.

}-- End of excerpt from Michael van Elst