From owner-freebsd-current Sat Sep 26 20:10:39 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id UAA29780
for freebsd-current-outgoing; Sat, 26 Sep 1998 20:10:39 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from yonge.cs.toronto.edu (yonge.cs.toronto.edu [128.100.2.11])
by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA29762
for <current@FreeBSD.ORG>; Sat, 26 Sep 1998 20:10:28 -0700 (PDT)
(envelope-from dholland@cs.toronto.edu)
Received: from qew.cs.toronto.edu ([128.100.1.13]) by yonge.cs.toronto.edu with SMTP id <86552-25414>; Sat, 26 Sep 1998 23:10:09 -0400
Received: by qew.cs.toronto.edu id <37768-5346>; Sat, 26 Sep 1998 23:03:57 -0400
Subject: Re: Current is Really Broken(tm)
From: David Holland <dholland@cs.toronto.edu>
To: phk@critter.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 26 Sep 1998 23:03:49 -0400
Cc: gibbs@narnia.plutotech.com, current@FreeBSD.ORG
In-Reply-To: <8655.906831168@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 26, 98 01:32:48 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <98Sep26.230357edt.37768-5346@qew.cs.toronto.edu>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> <ARCHITECTURE>
>
> For any SLICE/GEOMETRY implementation, the discovery and instantiation
> of the network of handlers and devices is the most tricky part,
> no doubt about that.
>
> There are two basic ways to skin that cat:
I think this is a false dichotomy; the way I'd probably implement it
if I set out on such a project is neither of these, but a mixture, as
follows:
- knowledge of various kinds of disklabel is built into disklabel
drivers in the kernel. But this knowledge is kept encapsulated.
- if being able to have everything automatically appear is important,
you also write a probe routine that you put in the kernel.
- but you do not try to activate these disklabel devices, or the
probe, automatically from the kernel, except maybe once someplace
near the end of the boot sequence. Instead, you have someplace a
daemon that receives notifications when a new disk appears and
tries to work out something intelligent to do with it. (The probe
routine could be here instead of the kernel, too, maybe.)
As far as the other problems you bring up:
- if you weren't worried about kernel bloat, you could have one of
the device nodes generated by the disklabel hold some abstract
representation of the partition table, and automatically intercept
and handle modifications appropriately.
- if you were worried about kernel bloat, you just might disallow
writing to the partition table while a partition device was active.
This would be easy, because /dev/wd0 would be busy while the
partitions were available, and none of the other /dev/wd0* would
make the partition table visible. A slightly more dangerous option
is to create a /dev/wd0-table device that held the table and
automatically forced a reread if the table was modified. You also
require a process to issue an ioctl before writing the table, to
keep it from happening by accident.
- you don't have any trouble with booting; either you put the
partition table probe code in the kernel (IMO a perfectly
reasonable place for it), or configure the boot drive's partition
table format at kernel build time, or require require the boot
drive to have some (probably machine-specific) particular partition
table format.
- read-write locking of partitions is exactly the same problem as it
is right now. That is, it's messy, but not directly relevant.
> </ARCHITECTURE>
--
- David A. Holland | (please continue to send non-list mail to
dholland@cs.utoronto.ca | dholland@hcs.harvard.edu. yes, I moved.)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message