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 21:53:34
[ On Fri, October 2, 1998 at 23:51:28 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem
>
> > 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.
> 
> That's nothing to do with the driver. Please read the code.

The "convention" is "encoded" in the driver by the mere fact that the
driver forces you to use a partition that starts at cylinder zero, track
zero, sector zero in order to read the disk label.

To break this "convention" on would either have to add a new ioctl to
the driver such that the label can be read and written without having to
directly touch any physical disk sectors, *or* for the driver to always
provide a minor number by which the raw disk can be accessed from end to
end regardless of what's in the current label (either on disk or in core).

> I don't see where you need any kernel support for this. In fdisk,
> yes. In the kernel, why?

I think it would make things easier, more consistent, more orthogonal
and more elegan.  Wnen I once used systems which did provide in-kernel
handling of the fdisk partitions things were *far* more logical and easy
to understand, and mistakes were impossible to make because everything
had to fit together and remain consistent.

> > 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.
> 
> There's more than just a table. There's a bit of code to deal with
> to. Code that's completely useless on any other system.

That code need not be included in any kernel that's running on sane
hardware that doesn't have a PC BIOS.

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