*BSD News Article 27928


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!mvb.saic.com!MathWorks.Com!yeshua.marcam.com!charnel!xmission!u.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (Terry Lambert)
Newsgroups: comp.os.386bsd.development
Subject: Re: Coexisting on the PC
Date: 3 Mar 1994 04:10:27 GMT
Organization: Weber State University, Ogden, UT
Lines: 96
Message-ID: <2l3nvj$fpc@u.cc.utah.edu>
References: <CLz6un.A9G@rex.uokhsc.edu>
NNTP-Posting-Host: cs.weber.edu

In article <CLz6un.A9G@rex.uokhsc.edu> benjamin-goldsteen@uokhsc.edu writes:
[ ... discussion of device naming conventions ... ]

This is argued out on the mailing lists more frequently than I would like,
so before this is reposted, I thought I'd issue a preeemptive strike.

System V (I know, supposedly dirty word) resolves the naming issues by:

cAtBdCsD

Where A, B, C, and D are single hex digits and decode as:

A:	Controller # (2 bits -- 0-3)
B:	Target # (3 bits -- 0-7)
C:	Logical unit # (7 bits -- 0-127)
D:	Logical partition # (remainder: number of bits in a minor number
	should probably be bumped up, but 0-f is OK for now)

Thus the example of a SCSI disk without LUN support at ID 3 on the first
SCSI controller on the disk is:

/dev/dsk/c0t3d0s0		Block device
/dev/rdsk/c0t3d0s0		Character device

Other SCSI devices are addressed the same way, but this is not entirely
a SCSI specific issue, since, a logical collapse of the name space (ie:
use LUN 0 all the time) can work for other disk types, while a collapse
of the logical parition as either a density select or something else
can work for devices other than fixed disks.

Special case slices need to be kept only for the seperate paritions and for
the entirety of the disk; for the entirety of the disk, this could be hidden
in the name space for the device (ie: /dev/dsk/c0t3d0), but this would not
fix the name space issue with regard to minor device number, since one
would still need to be assigned for the whole disk; better to reserve 0
as "the whole disk" -- by which I refer to the BSD partition only, not
all logical paritions in the DOS partition table.  There are reasons for
this, disccused later, and the primary restriction on this is that the
BSD use portion of the disk must be contiguous (one DOS logical parition).

Some information, like the DOS parition table, would still bne accessable
from any slice target that ended on the device, by way of ioctl(); the
same ioctl() would allow fdisk style manipulation of the table as well,
so several device driver specific ioctl() command arguments would be
necessary.

Since BSD drivers don't care about geometry, only about absolute sector
number, this means getting the information is sufficient to allow the
mounting of DOS partitions as long as the DOS FS mount took the DOS
parition number s an argument and used the generic "whole disk device"
without causing it to be marked as mounted.  This resolves the issue of
having to have a disklabel entry that points off the logical parition to
enable mounting of DOS file systems; it assumes the interpretation of
the DOS parition table data is by means of the DOS apparent geometry,
which is either reported each time by way of a vm86() INT 13 AH=8 call,
or more easily done, by having the information passed to the kernel by
way of the BIOS boot blocks that can make the call on the kernels behalf
before entering protected mode.

The implication is that the DOS information, in being logically seperate,
can be OS specific and sperated in the processer specific protion of the
the kernel, specifically in the block I/O subsyetm, which does the
interpretation of the disk label.  Thus DOS partition tables are on all
386 and 486 systems (unless conditionally compiled out for, say, an MBUS
system or other system without the ability to run DOS, like an Intel 320),
but not elsewhere.

This should adequately resolve ALL naming issues without "polluting" the
device namespace with DOS (and HPFS, etc.) naming junk nased on the need
to manipulate partition information on a shared drive.



For the future, there should be logical volume management (this is one
thing AIX did right) to allow partition resizing without too much pain and
to allow partitions to span multiple physical disks.  This should be hidden
in the block I/O subsystem above the physical disk (and DOS partition)
management but below the block consumption layer used by logical BSD
partitioning.

Also for the future should be determining the physical geometry of a
hardware translated drive (ie: a ZBR SCSI drive) to ensure seek
optimization and other types of optimization can take pace, with an
option per driver soft-override to let smart controllers and drives have
that turned off (since controller based elevator seeking could be
pessimized by this).


Other than that, there's very little to doing disk I/O.  8-).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.