From owner-freebsd-hackers  Fri May  5 17:28:49 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id RAA18140
          for hackers-outgoing; Fri, 5 May 1995 17:28:49 -0700
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA18133
          ; Fri, 5 May 1995 17:28:45 -0700
Received: (from julian@localhost) by ref.tfs.com (8.6.8/8.6.6) id RAA04681; Fri, 5 May 1995 17:28:14 -0700
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199505060028.RAA04681@ref.tfs.com>
Subject: Re: SLICES and bits in the device numbers
To: fredriks@mcs.com (Lars Fredriksen)
Date: Fri, 5 May 1995 17:28:13 -0700 (PDT)
Cc: dufault@hda.com, bde@zeta.org.au, hackers@FreeBSD.org, julian@FreeBSD.org
In-Reply-To: <m0s7Q1e-0003kwC@mercury.mcs.com> from "Lars Fredriksen" at May 5, 95 11:14:46 am
Content-Type: text
Content-Length: 958       
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> 
> Couldn't we use the "bus" device for all lowlevel stuff like formatting,
> tuning, tape fixing etc? What I mean is that we open /dev/scsi0 and 
> blast the scsi request straight in that way. It does mean some code
> duplication between the different drivers and the "control" program,
> but if we are running out of bits, it might be worth it.
 but you couldn't blast a format at sd0 but at sb0t0l0 or whatever,
which might be easier to get wrong?

my own suggestion is that slice1 (presently whole disk slice) be divided
into a couple of sub-devices..
0: whole disk
1: MBR block (if it exists)
2: control (ioctl only) device

the st driver already has a control device..
What a control device actually means is dependent on the kind of device,
(setting modes permanently on tapes is one example)
so I see no reason to not make it's definition device specific,
unless you want to make teh SCSI code define this..
(which may not be what we want)

julian