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>