Date: Fri, 25 Oct 2002 11:16:01 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@critter.freebsd.dk Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <20021025.111601.57619416.imp@bsdimp.com> In-Reply-To: <20131.1035563872@critter.freebsd.dk> References: <20021025.100623.66111903.imp@bsdimp.com> <20131.1035563872@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20131.1035563872@critter.freebsd.dk>
Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
: >There are large
: >numbers of machines that still have the compatibility stuff.
:
: I doubt it is a very large percentage because systems have been
: installed with sliced device named four many releases now, and people
: would have to actively go and edit their /etc/fstab (etc) to change it.
We haven't been warning people that they should do this. We should
introduce, at the very least, a warning if they have the old-style
stuff in their kernel.
: >If you
: >want to increse the already insane level of pain to upgrade to 5.0,
: >then go ahead and break them.
:
: You know, we may actually _decrease_ the insanity level a lot by
: requiring a reinstall.
That level of pain is going to be ugly.
: >I really don't like your beligerent "I'm right, you are wrong, so
: >flake off" attitude on this.
:
: When people have repeated "but I LIKE it this way" N times, my
: diplomacy tries to solve "The halting problem" rather than continue.
I think that's a bad interaction.
: > Provide justification for the change, or
: >go fix the breakage. So far you've just asserted it is right without
: >any sort of justification, which is completely unacceptible.
:
: The justification was given in ample amount 4+ years ago, but here
: are the high-lights again:
:
: 1: It confuses users. The reason why you don't hear much about
: this now is that for four years we have installed systems
: with consistent names by default.
In your opinion.
: 2: It does not reflect what is on the disk, which adds
: complexity and failure modes to our software, both userland
: kernel and bootcode.
This is true.
: 3: Aliasing disk devices is a bad idea. You don't want people
: to accidentally mount /dev/da0a and /dev/da0s1a at the same
: time so you have to add complexity to your kernel side code
: to prevent this.
This is also true
: 4: /dev/da0a is the legitimate name for a disk which has _only_
: a BSD disklabel on it. The name in no way signals to the user
: that there is an MBR somewhere that the user also needs to
: attend to in a number of circumstances.
:
: At typical failuremode here is: "My disk wont boot", "Right
: is the FreeBSD slice active in the MBR ?", "There is no
: MBR!", "Yes there is", "No there isn't!" etc etc.
That's a legit concern as well.
: 5: This entire thing is a bloody bikeshed! Nobody cares about
: the fact that we get an Disk IO system which is multi-architecture,
: modular, extensible, Giant-free etc etc, instead they focus
: on the one little detail they _do_ understand, and make a lot
: of noise, just to show how much they are "in the loop"!
Calling it a bikeshed is not a justification for failing to explain to
people why you did this.
Right now we have a huge backward compatibility problem, which
traditionally in this project has required a high level of
justification and warning to do. We must handle the old-skool systems
in a sane and reasonable way. We must provide some way for people
that have upgraded to know the problems with /etc/fstab, et al, so
they can take corrective actions. Panicing is not that way.
Mysteriously failing isn't that way. This is an extremely visible
part of the system and if you aren't going to support old-skool names,
then you better make damn well sure that they fail in a way that is
sane. The current failure modes aren't acceptible. Ideally, you'd
retain the compat slice names for another major release, but failing
that ideal, the onus is on you to ensure graceful failure.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021025.111601.57619416.imp>