--p8PhoBjPxaQXD0vg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 22, 2004 at 03:16:26PM -0700, Jason Thorpe wrote:
> >Removable media are one of the most useful cases for named
> >partitions.
>=20
> The line is fairly blurred about what is and what is not removable=20
> media these days.  Consider Fibre Channel and iSCSI ... is your big=20
> RAID array removable media?  Well, no, but because it's on a network,=20
> it "sort of" is :-)

All the more relevant then :)

> >It should be reasonably simple to have a wedge discovery
> >that looks at the volume name from a fat, iso9660 etc fs and creates a
> >wedge corresponding to that name. Having a (constant) path-based name
> >would also be good (for when you don't care).
>=20
> Can you give me an example of the type of path-based name you're=20
> talking about?  You mean like WWN?  A WWN only names the disk, not the=20
> partitions on it...

Something like we do now. For the "just let me access whatever's in
the drive, I don't want to have to know/care what particular disk it
is" case.

Many flash usb widgets have an partition table on them, but its very
rare that there's more than one whole-disk partition defined.

A corollary might be Solaris' vold, which makes mounts on insertion by
name, but also gives you /cdrom/cdrom0 symlinks.

> I haven't tried to address floppy density issues here.  Currently,=20
> wedges are not allowed to overlap, and I don't think floppy density is=20
> a problem appropriately solved with wedges.

Agreed, nor with partitions.

So, as Bill suggested, leave them as minor numbers on the fd driver.
Once minor numbers stop encoding partition info on the sd/wd/..
drivers, the ambiguity is resolved :) (The biggest confusion with
current fd really stems from the minor devs being *named* in the same
way as partitions, rather than just the use of minor numbers to encode
this to the driver).

We might then have wedges associated with each of the minor density
devs, which was what I was getting at earlier.  They don't appear to
overlap (different underlying fd dev) but fd would need to do some
interlocking to prevent concurrent opens of the minor devices, via
wedge or otherwise.

Also, of course there'll be a bsd-disklabel wedge loader, and some
kind of scheme to make compatible naming and migration easy, later.

> >Many fd's these days are presented to us as sd (via usb) anyway, so a
> >more generic solution is needed.
>=20
> Do those drives even work with 720K disks?

No idea, I'd assume they can at least read them.  Perhaps they present
a different sd geometry via autosensing media?  There's also the 2.88M
case to consider, as well as the LS-120 variants (which are probably
always sd?).

The density selection is only really important to fdformat, after then
the choice is made for later block access, so it could also all move
there via a setdensity ioctl.

--
Dan.


--p8PhoBjPxaQXD0vg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBUgBmEAVxvV4N66cRAhqgAKCSMRpuJ07fwlRY3nbUCfynprb7CgCdFXYU
C8dxnn8rApmDtSJlpfMLGiw=
=2ZcQ
-----END PGP SIGNATURE-----

--p8PhoBjPxaQXD0vg--