From owner-freebsd-hackers  Thu May  9 17:01:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id RAA09222
          for hackers-outgoing; Thu, 9 May 1996 17:01:58 -0700 (PDT)
Received: from eac.iafrica.com (h196-7-192-129.iafrica.com [196.7.192.129])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA09202
          for <hackers@freebsd.org>; Thu, 9 May 1996 17:01:54 -0700 (PDT)
Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id BAA03101; Fri, 10 May 1996 01:00:50 +0200
From: Robert Nordier <rnordier@iafrica.com>
Message-Id: <199605092300.BAA03101@eac.iafrica.com>
Subject: Re: [Q] Raw interface to block devices
To: terry@lambert.org (Terry Lambert)
Date: Fri, 10 May 1996 01:00:49 +0200 (SAT)
Cc: hackers@freebsd.org
In-Reply-To: <199605092159.OAA29636@phaeton.artisoft.com> from "Terry Lambert" at May 9, 96 02:59:46 pm
X-Mailer: ELM [version 2.4 PL24 ME8a]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert wrote:

> > There must be a better way to do this.  The stuff I've looked at
> > either trustingly waits forever on '/dev/tty', or refuses to even
> > consider 'floppy'.
> > 
> > Surely a library function is needed (or already exists).
> 
> The typically used approach is to stat the device to get the major
> and minor number, then iterate all devices looking for the same
> major, but a minor that's the same + 128 for the raw device (or
> whatever the magic relationship happens to be on whatever system).

Thanks, I'll look at that.

> Note that all of this starts to fall apart under devfs usage, which
> wants device iteration by parent as a result of a stat reference
> returning non-terminal devices as directories that can be ioctl'ed
> to turn them into devices.  This lets you get iterate devices by
> class without stats or opens on the actual devices themselves.
> 
> I guess I need to reintegrate the devfs code on my local machine
> and work on putting together an API for this when I get a chance.
> 8-(.

I guess devfs benefits are beginning to sink in at last. 8)

I suppose things like FS utilities don't absolutely _need_
idiot-proofing.  But it'd be nice to have stuff working more
robustly.

--
Robert Nordier