Date: Mon, 21 Apr 1997 19:13:23 -0400 From: Bakul Shah <bakul@torrentnet.com> To: Warner Losh <imp@village.org> Cc: hackers@FreeBSD.ORG Subject: Re: disklabel -- owner? Message-ID: <199704212313.TAA02238@chai.plexuscom.com> In-Reply-To: Your message of "Sun, 20 Apr 1997 19:52:09 MDT." <E0wJ8H3-00013d-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> : - It should try to infer some common things by looking at disk
> : blocks. Sort of like what file() does.
>
> I'm not sure I understand what this means. I mean what would I look
> at and do based on that?
What I meant is before munging a disk your program should find out
what is on the disk. Just like file(), it may have to apply
heuristics (such as what a boot block looks like, what a superblock,
root dir. looks like, where it may be in relation to the beginning
of a partition and so on). Based on what is discovered a user may
choose to reuse some of the exisiting information. Probably for
your V2.0!
On occasion I have found it useful to guess some critical parameter
(such as sectors/track or where a partition starts) and retrieve a
data block based on such a change. It would be useful if the
heuristics can be reapplied after changing such parameters.
> : - It should *explain* various actions and consequences of such
> : actions. A built-in FAQ would be handy.
> I'm not sure I understand this completely.
Sometimes a simple choice is based on some complex reasoning or has
nonobvious consequences. In order to help the user make such a
choice you need to explain things. The depth of explanation depends
on one's skills and experience so this help should be user driven.
If you did your tax return using TurboTax then you'd know what I am
talking about :-) The tax guides are immensely useful when you are
trying to figure out things like whether you should deduct for a
home office or not. The consequence for *that* decision is that the
cost basis of the house has changed and when you sell your house
computing taxes gets more complicated. But I digress.
The point is that the *user* has may have no idea of what happens
when he says yes to a simple question like `reformat? (Y/N)' or how
many partitions he should make or what the size of his swap
partition should be.
[And I disagree with Terry when he says if you need a FAQ it is
an interface design error].
> hints rather than hard and fast rules. disktab does describe
> properties of various disks.
What I meant is that it should *not* use partition info. since that
is not a property of a disk. Also, like MIB, PPD etc. it should be
in a OS/{scsi,ide,...} neutral fashion and disktab is not quite it.
For old disks a database like this is very useful as they don't
always return the info or the driver doesn't do the right thing.
> But table driven so that others can have other rules of thumb. The
> above, btw, are bogus for many reasons. They are just an example of
> the ideas I'd like to have.
Good idea(s)!
> : - It should be easy to extend as disk manufacturers are going to
> : add some new kind of disk sooner or later, which will require
> : adding some code goop.
> No code should be required. Anything like this would be table driven.
You have too much faith in the disk vendors when they can't even do
SCSI right!
> : - It should allow *moving* a partition or a slice.
> Beyond the scope of my time for some time to come, unless someone
> wants to fund this at my usual rate :-)
Notice I said *move* not expand/shrink. Think of this as equivalent
to `memmove()' instead of `memcpy()'! Not hard to do.
> However, I wanna get something simple done for v1.0. To make Michael
> Smith happy, I'm going to try to do this with tcl and Tk with glue
> utilities as needed. ^^^
Sigh.... At least the disk specific code should be separable from
a tcl/tk frontend.
> Thanks for the suggestions. I'm hoping that once I punch a hole
> through the wall of this problem, that the pent up frustration will
> help expand the hole into a nice doorway that could eventually be
> integrated back into sysinstall, or its heirs, userpers or follow on
> programs.
Amen!
-- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704212313.TAA02238>