Date: Wed, 31 Jan 1996 14:52:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: invalid primary partition table: no magic Message-ID: <199601312152.OAA10765@phaeton.artisoft.com> In-Reply-To: <199601310338.OAA11342@godzilla.zeta.org.au> from "Bruce Evans" at Jan 31, 96 02:38:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >uriah # vnconfig -c /dev/rvn0 fooimage
> >uriah # Jan 30 23:51:48 uriah /kernel: vn0: invalid primary partition table: no magic
>
> >It's starting to get annoying. Not only that any /dev/zero-created
> >empty file that we are about to disklabel during the release process
> >causes this bogus warning (until it's disklabeled -B), but fooimage
> >above was an cd9660 image, so the warning is not of much use.
>
> >Since the warning is not of interest for ``ordinary people'' anyway,
> >i'd vote for hiding it behind some debugging option (perhaps enabled
> >via sysconfig).
>
> It is an error for disks that should have a partition table, but
> since there is no way of telling which disks those are, it is hard
> to tell when to suppress the warning.
>
> For emulating physical disks that don't have partition tables or labels,
> don't use the `-s labels' option to vnconfig.
I think this falls into the category of the "how do I attach a label"
problems, which in turn fall into the "why is a label expected" problems.
I think the magic here is to allow devfs ioctl()'s to specify logical
device manager controls to instantiate management in the first place.
This provides a general soloution for integrating an existing OS's
arbitrary logical partitioning, media perfection, and volume spanning
with only minor changes to the BSD code.
This sounds kind of weird unless you've seen some of the discussions
of devfs based logical device management that I've had with Julian
(and a couple of other people who've asked about fixing DOSFS device
tromping, adding VFAT long name support, or supporting NTFS).
Here is one excerpt of a system configuration followed by a devfs
based logical device registration process. The idea of "how to
handle a new disk" follows the excerpted material:
=============================================================================
Consider the following:
There exists two SCSI and one IDE controllers such that:
o SCSI controller 0 has a 1G disk such that:
o DOS partition table
o 500M VFAT partition
o 500M BSD partition shuch that:
o 100M /
o 32M swap
o 120M /var
o 248M /usr
o SCSI controller 0 has a CDROM
o SCSI controller 1 has a 500M disk such that:
o DOS partition table
o 200M DOS partition
o 300M Extended DOS partition such that:
o 80M DOS Partition
o 188M Linux EXT2FS Partition
o 32M Linux Swap Partition
o IDE controller 0 has a 500M disk such that:
o DOS Partition table
o 250M VFAT Partition
o 250M Extended DOS partition such that:
o 250M VFAT Partition
Each one of these items needs to be accessable.
SCO (SCSI controller 0) registers: creates /dev/dsk/sc0
SC0 probes a physical device 0: creates /dev/dsk/sc0/t0u0
SCO registers device.
Logical driver "DOS partitioning"
=> claims device creates /dev/dsk/sc0/t0u0/p0
creates /dev/dsk/sc0/t0u0/p1
=> registers /dev/dsk/sc0/t0u0/p0 (no claimant *)
=> registers /dev/dsk/sc0/t0u0/p1
Logical driver "BSD slices"
=> claims device creates /dev/dsk/sc0/t0u0/p1/s0
creates /dev/dsk/sc0/t0u0/p1/s1
creates /dev/dsk/sc0/t0u0/p1/s2
creates /dev/dsk/sc0/t0u0/p1/s3
=> registers /dev/dsk/sc0/t0u0/p1/s0 (no claimant *)
=> registers /dev/dsk/sc0/t0u0/p1/s1 (no claimant *)
=> registers /dev/dsk/sc0/t0u0/p1/s2 (no claimant *)
=> registers /dev/dsk/sc0/t0u0/p1/s3 (no claimant *)
SCO probes a physical device 3: creates /dev/dsk/sc0/t3u0
SCO registers device (no claimant *)
SC1 (SCSI controller 1) registers: creates /dev/dsk/sc1
SC1 probes a physical device 1: creates /dev/dsk/sc1/t1u0
Logical driver "DOS partitioning"
=> claims device creates /dev/dsk/sc1/t1u0/p0
creates /dev/dsk/sc1/t1u0/p1
=> registers /dev/dsk/sc1/t1u0/p0 (no claimant *)
=> registers /dev/dsk/sc1/t1u0/p1
Logical driver "DOS extended partitioning"
=> claims device creates /dev/dsk/sc1/t1u0/p1/e0
creates /dev/dsk/sc1/t1u0/p1/e1
creates /dev/dsk/sc1/t1u0/p1/e2
=> registers /dev/dsk/sc1/t1u0/p1/e0 (no claimant *)
=> registers /dev/dsk/sc1/t1u0/p1/e1 (no claimant *)
=> registers /dev/dsk/sc1/t1u0/p1/e2 (no claimant *)
WC0 (IDE controller 0) registers: creates /dev/dsk/wc0
WCO probes a physical device 0: creates /dev/dsk/wc0/t0
Logical driver "DOS partitioning"
=> claims device creates /dev/dsk/wc0/t0/p0
creates /dev/dsk/wc0/t0/p1
=> registers /dev/dsk/wc0/t0/p0 (no claimant *)
=> registers /dev/dsk/wc0/t0/p1
Logical driver "DOS extended partitioning"
=> claims device creates /dev/dsk/wc0/t0/p1/e0
=> registers /dev/dsk/wc0/t0/p1/e0 (no claimant *)
Each logical device has a physical device a start sector, and a length,
at a bare minimum. Some logical devices substitute a pseudo-device for
the physical device, and the pseudo device performs operations on the
real physical device on the requesters behalf. Like bad sector mapping,
or 64 sector ofsetting for OnTrack DiskManager 6.x or 7.x (neither shown
in the above example).
As long as we realize that directories are accessed via getdents and
files via read/write, we can still treat the devices as raw devices
even though they show up as directory vnodes. That means we don't
need /dev/dsk/wc0, /dev/dsk/wc0/t0, and /dev/wc0/t0/p0 to be seperate
devices to let us access the controller, the first raw disk (including
partition table), or the VFAT partition, erspectively. We can use
the directories as devices.
Because we get range restriction guarantees, FS events in the kernel
on the /dev/wc0/t0/p0 devie can't screw up the contents of any other
slice, period. No matter what bad calculations the MSDOSFS makes.
So now we have the device/slice mess straightened out.
(*) One thing we may want to consider is that the "no claimant" cases
above are nearly the perfect mechanism to cause a callback to the
VFS code to ask each VFS if it want to "claim" a device -- causing
it to be mounted.
On the VFATFS itself (I'd prefer long name semantics if allowable, so
I'm calling it that instead of MSDOSFS), one of the first things to
consider is that long name storage is in Unicode.
The impact of either supporting Unicode at the user interface level,
or of integrating a file systems that can support Unicode at a lower
level is a big one.
The largest impact is in path parsing. The first step to allowing
Unicode and non-Unicode semantics to exist (for both VFATFS and NTFS
uniformity) is to move the path parsing buffer manipulation code up
above the VFS layer. In the current BSD, the path buffer is freed
on a per FS basis, which is really quite broken if the buffer can
be dimorphic for char and wchar_t values (which it must be for the
16 bit Unicode storage model used in VFAT, since short names are
stored as DOS ASCII: code page 435).
This implies that both Unicode and non-Unicode path components may be
simultaneously required by an underlying FS. Because we must consider
more than one Unicode FS to exist below the VFS layer, we must create
the path dimorphism support above the VFS itself (in what is typically
called the "vncalls" layer in an SVR4 system).
[ ... ]
=============================================================================
OK. Now we add a disk, ID 1, to SC0. This adds:
SC0 probes a physical device 1: creates /dev/dsk/sc0/t1u0
SCO registers device (no claimant *)
Note: This may be the result of a hot plug of a SCSI device followed
by a callback to a configuration manager to trigger notification
of "device arrival". The same thing applies to CDROM's, 3.5"
floppies, ZIP drives, PCMCIA flash RAM, etc. -- anything that
actually *has* a notification mechanism. A user program for
"reprobe" or explicit notificaton of the configuration manager
can be provided for pluggable devices without a notification
mechanism. Finally, notification of a user space daemon can
be used to trigger Windows96-like "autorun" behaviour on CROM
and similar media for easy upgrade from standard distribution
media.
The user wants to partition the device, and starts a logical partitioning
tool. This tool does the following:
1) IOCTL's the /dev/dsk/sc0/t1u0 device to get a list of
applicable logical device drivers which may be applied
to the device.
2) Presents a picklist to the caller. This might resemble:
a) Add media perfection and rexeport same device
b) Add DOS partitioning and export partition devices
c) Add BSD partitioning and export partition devices
d) Insert this device in a volume spanning set
3) Based on an identifier returned with the logical device
and a device class descriptor, allow the users to perform
operations applicable to that logical device. One of these
operations is instantiating one of the drivers. This takes
the place of raw disk I/O for partitioning, etc..
4) Save and Exit. Device reregistration is triggered on close
and export proceeds normally.
Note that the tool in this instance is data-driven from the registered
logical devices and the class designation that comes from the controller
target identification on a per driver basis (ie: you aren't allowed to
partition CDROM's, for instance).
For a vnconfiged device, a device /dev/dsk/vn0 is exported in the
DEVFS name space. It may be acted upon normally. Because the "hosted
device" bit is set, DOS partitioning is not offered. If the hosted
drive already has a media perfection layer present (ie: bad144), then
media perfection is not offered.
A newly exported /dev/dsk/vn0 will not have a claimant unless it is
a reexport of an "existing" device (a vnconfig of a previously vnconfiged
device).
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?199601312152.OAA10765>