From owner-freebsd-hackers  Thu May  9 15:00:14 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA24197
          for hackers-outgoing; Thu, 9 May 1996 15:00:14 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA24186
          for <hackers@FreeBSD.org>; Thu, 9 May 1996 15:00:10 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA29636; Thu, 9 May 1996 14:59:46 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199605092159.OAA29636@phaeton.artisoft.com>
Subject: Re: [Q] Raw interface to block devices
To: rnordier@iafrica.com (Robert Nordier)
Date: Thu, 9 May 1996 14:59:46 -0700 (MST)
Cc: hackers@FreeBSD.org
In-Reply-To: <199605092114.XAA02591@eac.iafrica.com> from "Robert Nordier" at May 9, 96 11:14:48 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> I have a function
> 
>    int process(const char *fs);
> 
> which expects 'fs' to refer to a device which may hold a filesystem.
> 
> The function actually works with the raw device, but allows the
> user some flexibility.  Eg:
> 
>    process("/dev/rfd0"); or
>    process("/dev/fd0");
> 
> An obvious, though clumsy, approach is:
> 
>    stat()
>    if {S_IFCHR, S_IFBLK}
>       derive the other name by deleting/inserting an 'r' somewhere
>       stat()
>       check for (reversed) {S_IFCHR, S_IFBLK}
> 
> This tries to ensure we are not dealing with (say) '/dev/tty'; and
> to come up with the device name needed.

I think this is probably a mistake in implementation.


> However, something like
> 
>    ln -s /dev/fd0 floppy
> 
> causes problems.
> 
> 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).

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-(.


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