DragonFly BSD
DragonFly submit List (threaded) for 2004-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [PATCH] fix /boot/loader for extended slices


From: Hiten Pandya <hmp@xxxxxxxxxxxxx>
Date: Mon, 20 Dec 2004 01:18:32 +0000

Matthew Dillon wrote:
:>     So what we need is some serious testing, e.g. like creating multiple
:>     extended dos partitions two recursions deep and seeing if the partition
:>     data is properly passed between the loader and kernel.
:
:First, your patch works just fine for me.
:
:Now, some comments on how the DOS extended partitions work, which I can
:only infer from how the various fdisk programs work.
:
:I have only three fdisk programs which allow for extended partitions:
:the ones from linux and NetBSD, and also the commercial Windows app
:from Acronis  -- well, and the MS versions of fdisk too, of course.
:
:They all behave the same when dealing with extended partitions -- that
:is, they create the *primary* extended partition entry automatically
:if there isn't one already.  If there is an extended partition already
:then it sticks your new logical drive at the end of the existing chain
:of extended partitions.  You never get the chance to create a second
:*primary* extended slice.
:
:In other words, there will always be only one slice of type 05 among
:the four primary partitions because there is no way to create a second
:one.  I even tried editing an existing partition to make it a type 05
:and got an error message.  Verboten!
:
:Second comment:   I restricted the reading of each chained XPT to the
:first two entries in the table because (on my machines) the last two
:entries are always zeros.  The first entry is the pointer to the
:partition you really want (e.g. type a5 for DFLY) and the second
:entry in the table is the pointer to the next XPT (i.e. always type
:05.)  There didn't seem to be any point in reading the last two.
:
:Doesn't matter -- your patch, as I said works fine.  Thanks!

    Ok.  I'll add some additional comments and then commit my modified patch.
    It's unclear what the official specification allows but the patched
    scanning code does check for zero'd entries and should handle those
    cases, and it does match what the kernel does.

-Matt
Matthew Dillon <dillon@xxxxxxxxxxxxx>

http://howtos.linux.com/howtos/Large-Disk-HOWTO-13.shtml


-Hiten



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]