Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 10/03/1998 00:40:46
[ On Fri, October 2, 1998 at 20:12:28 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem
>
> On Fri, 2 Oct 1998, Greg A. Woods wrote:
> >
> > I'd really love to see some /dev node that represents the *raw* disk,
> > ignoring any and all translations and partitioning.
> 
> Well look in /dev, then. It's been there all the time: /dev/rxdNc
> (or d on the i386 port).

That's always seemed either like "magic" numbers, or inappripriate
overloading to me.  It's one thing to have a "convention" where a
certain slice represents the entire physical device, but yet another
thing entirely to encode that convention into the driver.  I'd much
rather see another minor number used to represent the raw disk,
especially since there's no big shortage of them any more.

> There's no reason I can see to put support for DOS partition tables
> in the kernel. You can simply have a userland program set up the
> BSD partition table entry to point to the appropriate place on the
> disk, which is just as effective, and avoids kernel bloat.

Well, OK, but the fact it's missing is one of the thing that leads lots
of PC-weenie types to a great deal of confusion.  Explicitly supporting
them and enforcing their rules first, the disklabel rules second, would
also avoid lots of think-o's and type-o's.

I do like the ability to avoid them to a certian extent though,
esp. since the only piece of software I ever need to use which knows
about fdisk tables is the BIOS for booting, and once the kernel has
started I would prefer never to see a trace of them again.

Unfortunately it seems there are lots of people who want to use fdisk
slices for booting other non-unix operating systems.  That's the context
where I think full kernel support for them is "good".

I don't see where the "bloat" is though -- just one more table for the
driver to sort through before it sets up partition to physical mapping.

Anyway I shouldn't really talk too much about PCs, esp. since I'm
unlikely to ever do anything terribly substantial with/to/for them....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>