On 15.09.2015 20:46, Brian C. Lane wrote: [...]
Does there need to be a distinction made between native and non-native? If not, what I'd do is add ped_device_like_dasd as a static function to arch/linux.c (something like _device_is_like_dasd), and call it from the bottom else of _device_probe_type and set dev->type based on the check when all else fails.
As it happens, I've been there, but it's not really desirable as a) we would be misusing the device type (which really denotes the block driver/transport) b) the geometry check is just a hint that this might be a DASD and more specific checking in fdasd.c has to be performed, which in turn would probably need additional APIs to be exposed.
As you have it now you are exposing the function and we'd have to make an API bump for it, and nothing outside is ever going to use it. So I'd at least make it static so that it doesn't need to be exposed to libparted users.
I didn't consider the API impact (and I would like to avoid it). Let me try to come up with a version that ensures that the minimum and optimum alignments are handled properly within arch/linux.c only. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
