On Sat, 3 Oct 1998, Greg A. Woods wrote:

> That's always seemed either like "magic" numbers, or inappripriate
> overloading to me.

Well, feel free to change the name to /dev/sd0.raw or whatever you
like. At some point, all numbers in a computer are arbitrary.

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

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

Right now it's (disk number * 8 + 2). Why would (disk number * 16
+ 15) or whatever be any better? And what would we do with partition
c afterwards? Make it disappear? And why not call the new one
/dev/rxdNp? Or better yet, why not make rxdNp the new partiton that
can actually be used, and leave the old minor number and name in
place so that those used to the old system (all BSD users in the
world) don't get confused?

> > There's no reason I can see to put support for DOS partition tables
> > in the kernel.
> 
> 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.

No, it's general crap related to limits on the number of cylinders,
heads and sectors an old BIOS can deal with versus what's really
out there now. It's a nightmare, I agree, but this will not solve
it.

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

Me too.

> 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 you need any kernel support for this. In fdisk,
yes. In the kernel, why?

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

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

In that case, the whole argument is worth ending now. PCs are the
majority of the customer base of NetBSD, many other designs (such
as Alpha and recent Sparc systems) have PC characteristics (such
as the "simple and stupid" PCI bus), and we have to deal with those
reasonably well. And this segment of the market is growing, while
the rest is shrinking.

cjs
--
Curt Sampson  <cjs@portal.ca>  604-257-9400    De gustibus, aut bene aut nihil.
Any opinions expressed are mine and mine alone.
The most widely ported operating system in the world: http://www.netbsd.org