Date: Tue, 19 Feb 2019 02:21:04 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Toomas Soome <tsoome@me.com>, Ian Lepore <ian@FreeBSD.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344238 - head/stand/common Message-ID: <87a39bba-c5d7-4429-79dd-123c8bd757fe@yandex.ru> In-Reply-To: <2EAE5156-2C63-47FC-977F-0D9676CABF7F@me.com> References: <201902172332.x1HNW9ut059440@repo.freebsd.org> <2EAE5156-2C63-47FC-977F-0D9676CABF7F@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
18.02.2019 16:09, Toomas Soome пишет: >> This restores the old functionality by resetting d_offset to the start >> of the raw slice after disk_open() returns. For good measure, d_partition >> is also set back to -1, although that doesn't currently affect anything. >> >> I would have preferred to make disk_open() avoid such rude assumptions and >> if you ask for partition -1 you get the raw slice. But the commit history >> shows that someone already did that once (r239058), and had to revert it >> (r239232), so I didn't even try to go down that road. > > > What was the reason for the revert? I still do think the current disk_open() approach is not good because it does break the promise to get MBR partition (see common/disk.h). The reason is that someone has reported that after the change the system fails to boot. > Of course I can see the appeal for something like “boot disk0:” but case like that should be solved by iterating partition table, and not by making API to do wrong thing - if I did ask to for disk0s0: I really would expect to get disk0s0: and not disk0s0a: > > But anyhow, it would be good to understand the actual reasoning behind that decision. -- WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87a39bba-c5d7-4429-79dd-123c8bd757fe>