From owner-freebsd-current Tue Dec 15 19:31:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA13297 for freebsd-current-outgoing; Tue, 15 Dec 1998 19:31:50 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA13288 for ; Tue, 15 Dec 1998 19:31:48 -0800 (PST) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id TAA19404; Tue, 15 Dec 1998 19:31:33 -0800 (PST) Date: Tue, 15 Dec 1998 19:31:33 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199812160331.TAA19404@math.berkeley.edu> To: grog@lemis.com Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour Cc: dan@math.berkeley.edu, freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I can't see any particular reason to restrict the minor number format > if it's not necessary. So we have 4 densities, n (<=4?) speeds and > compression. That makes 5 bits. Then we have non-rewind, a maximum > of 16 units per drive and (on a PC) probably not more than 16 > controllers. A total of 14 bits of minor number out of the 24 > available: in other words, there should be no problem finding a minor > number format which fits. One good reason for restricting the minor number format is that 16384 (i.e. 2^14) different entries for tape devices in /dev would be painful beyound belief. I claim that the idea of specifying tape drive operating parameters via minor device number was a really bad idea from almost the very beginning (unix v6 I believe) and should have been abandoned after the ioctl() system call became available. Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message