Date: Wed, 1 Nov 1995 17:40:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@rocky.sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@rocky.sri.MT.net, jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Re: More nits Message-ID: <199511020040.RAA00822@phaeton.artisoft.com> In-Reply-To: <199511012300.QAA15788@rocky.sri.MT.net> from "Nate Williams" at Nov 1, 95 04:00:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Terry, notice *what* the subject is. It's not about changing how things
> > > are done, but *when* things are done. :)
> >
> > That would be "Re: More nits".
>
> That's the subject of the email, but not the subject of your diatribe.
Wrong. You are misrepresenting me.
> > And the partition editor is fdisk.
>
> Right, and *after* you leave the fdisk editor, should Jordan ask to
> install the MBR then? Sounds like a 'different' tool than fdisk to me.
He didn't say *after*, he said *when*. As in "a consequent action of".
As in "implemented by the exit code rather than by code following the
exit".
[ ... ]
> See above. "I will have it ask when you leave the editor". This
> implies to me (especially after having used the intall tools for *many*
> intalls) that 'when I leave the editor' sysinstall will ask me questions
> on my MBR. I take this to mean that 'right after' I leave the editor
> (because you *MUST* write the partition table *BEFORE* the new MBR will
> be valid) I will have the option of installing a 'new' MBR to select my
> 'new' partition. :)
I take this to mean "when" just like he said in the quoted text above.
He didn't say "I will have it ask after you leave the editor".
-----
> > > [ Irrelevant ranting about fdisk and devfs deleted ]
> > >
> > > Since *NONE* of this stuff is relevant until *after* FreeBSD is booted,
> > > how is at all related to the partition menu? The MBR stuff is necessary
> > > for the PC hardware, and once FreeBSD is running it's no longer an
> > > issue.
> >
> > So now FreeBSD is not running when the install takes place? BZZZZZZZT.
>
> Yes, but what does this have to do with devfs? We *don't* have devfs,
> and writing a MBR entry doesn't need it. For God sake's, it can only
> exist in *one* place on the disk, and can't exist *ANY* other place on
> the disk. Why do I need a devfs to find it, since it *never* moves.
The devfs is the rationale for not munging it uncermoniously into
the fdisk utility itself. Which is what I was objecting to. I don't
give a damn how it ends up appearing to the user, it's whether the
way it is implemented is going to cause it to have to be reimplemented
later or not, when both approaches are otherwise *identical* cost and
the end appearance to the user is *identical*.
To answer your question, you need the devfs to find where it goes
because it may not go anywhere at all.
You obviously missed the discussion about installing BSD onto
WD1007 drives, which only works with a *naked* BSD partition, where
the disk MBR *is* the BSD second stage boot because of the non-linear
nature of WD1007 BIOS translation when the controller's sector sparing
option has been enabled.
Without a devfs, you can make a standalone utility that looks for
0xaa55... AND WHICH ISN'T PART OF THE FDISK CODE: meaning it gets
run *after* and not *when* you leave the editor.
THIS IS BROKEN, since it doesn't use devfs like a future version would,
but it's less broken than rolling platform specific code into a
supposedly platform independent utility (fdisk).
An install without a DOS partition table and MBR works on the WD1007
because there isn't a sector reserved by the BIOS for sparing in the
first 8k + sizeof(disklabel) of the drive (another good reason to
avoid jacking the second stage boot up to 100k, like some have
suggested recently).
Putting the MBR write in the fdisk puts another nail in the coffin
of being able to install without a DOS partition table. I'm not
saying that an install without a DOS partition table shouldn't
be the default: it should. But it should be *possible* to run on
older hardware, don't you think? And that requires *removing* the
partition table requirement, not *adding* to it.
Currently, the stupid code won't allow installs without DOS partition
tables, and so WD1007 installs require setting two jumpers (W8 & W14)
and doing a low level format on the stupid drive.
THIS IS BROKEN. A user is likely to bail rather than install FreeBSD
at this point. It is a pain to get the utility, it's a pain to get
the drive data necessary, and it's a pain to get the jumper settings
for your particular controller revision.
Pain, pain, pain == no install of FreeBSD.
Then the stupid code won't allow an install if the BSD area of the
disk spans cylinder 1024 because the stupid bad144 code in the second
stage boot can't read the bad sector replacements, which may not be
in use anyway.
THIS IS BROKEN. The user is likely to bail to Linux, rather than install
FreeBSD at this point, since then at least he can use his whole drive
instead of just phisical cylinders 0-1023 on a 2000+ cylinder 700M ESDI
disk. Here we make the requirement that they kill the translation
that makes the rest of the drive visible to DOS, then we turn around
and make the rest of the invisible to FreeBSD.
Pain == a limit unique to FreeBSD == no install of FreeBSD.
Because the bad144 code puts the replacement sectors at the end of the
disk.
THIS IS ALSO BROKEN. The devfs comes in here because it supports the
idea of "media perfection" as a seperate logical layer (non-collapsable).
And the replacement sectors can be made to *always* be below 1023.
Pain == a limit unique to FreeBSD == no install of FreeBSD.
Alternately, you could "fix" bad144, leaving in the limitations that the
disklabel and superblock blocks can still go bad and hose you, but
removing the one of the three problems that happens to be inconveniencing
you in this particular case. That would be expedient, so it's probably
what Microsoft and USL would do (quetionable company).
> > > Huh? Moving where he installs the MBR to a different spot on the menu
> > > is hardly adding a *wart* to the slice API.
> >
> > Making it a default prompt after editing the partitions in fdisk would be.
>
> Why? It's the most logical place to put it, hence the reason it was
> brought up in the first place.
No. Making it "a default prompt in the *install program* after *exiting*
the fdisk utility such that it is *apparently* a prompt after editing
the partitions in fdisk" is the most logical place to put it.
> Dare I ask, where would you put in in the menu, knowing that it is a
> *mandatory* question.
The same place, of course, just in a different underlying utility, said
utility NOT BEING FDISK ITSELF. Or I'd put it *before* the partitioning,
since it's possible that the MBR you want to write is the BSD second
stage boot, not the DOS MBR replacement at all. And the partition
table you will be editing may not exist until you write an MBR that
contains a partition table.
You are doing what Jordan did, confusing logical and implementational
architectures. This particular case is a bleed-through boundry where
the implementation should match the logical abstraction to prevent
having to *rewrite everything*, yet again, when the devfs *is* online.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511020040.RAA00822>