svn commit: r304142 - head/usr.sbin/bsdinstall/partedit

[Dag-Erling Smørgrav]

Nathan Whitehorn <nwhitehorn at freebsd.org> writes:
> Dag-Erling Smørgrav <des at des.no> writes:
> > [...]  And you keep refusing to address the fact that most drivers
> > don't report a stripe size, except by repeating your claim that they
> > do, with no evidence to back it up.  Feel free to 'grep -r
> > stripesize /usr/src/sys/dev'.  Go on, I'll wait.
> And yet, if you look at the GEOM XML, it is reported and there. And,
> look, it's even right for the AF 512e disks in my machine!

Yes, that is one of the few cases where we get it right, as previously
mentioned.  But it only works because it's known to us (listed in the
quirk table) and directly attached.  If you replace that drive with a
brand new one a year from now, you have no guarantee that the new drive
will be recognized as an AF drive.

> I've literally never seen a case where we don't already do the right
> thing here.

The I can only conclude that you have very little real-world experience.
I have mentioned several examples to you, and even told you how to
confirm, by inspecting the source code, that most drivers do *not* set
the stripe size.

> It's correct, as far as I can tell, 100% of the time on all possible
> variants of AF disks.

You keep repeating this, as if it somehow proves me wrong.  It doesn't.

> One could argue that calling this the "stripesize" is a hack, and I
> would agree,

One could, but one would be wrong.

> As for grepping, the CAM disk drivers are all in sys/cam, not sys/dev,
> as I'm sure you know, and you will find all the code that handles this
> there.

Only for directly attached drives, and most drives do not report the
correct physical sector size, which is why we have quirk tables.

> We should just fix the driver for whatever weird disk you have in your
> machine (what is it, by the way?).

Oh please.  Now you're just being an <expletive>.

DES
-- 
Dag-Erling Smørgrav - des at des.no