From owner-freebsd-hackers Mon Oct 13 00:40:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26911 for hackers-outgoing; Mon, 13 Oct 1997 00:40:18 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26904 for ; Mon, 13 Oct 1997 00:40:15 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA01118 for ; Mon, 13 Oct 1997 00:33:58 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd001115; Mon Oct 13 07:33:52 1997 Date: Mon, 13 Oct 1997 00:32:38 -0700 (PDT) From: Julian Elischer To: hackers@freebsd.org Subject: good name for a (in fact 2) new module(s) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have two new major kernel modules to add soon. Part of all this is to think of good names for them before they hit the light of day.. once they've been released, I can't easily change the names and the CVS files will have been created etc. They are: A networking framework to allow the linking and operation of an arbitrary graph (think of nodes and edges) of processing modules within the kernel. e.g. a ppp framing modules, a frame-relay mux, a frame relay control module, debug modules. etc. At the moment this is called "netgraph" in the same line as netatalk, netinet, netipx, etc. This is scheduled to be made public by whistle on Jan. 1. It kind-of fills the same ecological niche as the sysV STREAMS, but is considerably different. I've discussed this with many including Mike Karels. Many of you will have seen early versions of this. Whistle's mpd (multilink PPP daemon) knows how to use this framework to do fun things with ISDN and frame relay links etc. The second module is a disk layering framework that works in conjunction with DEVFS. All direct-access devices (e.g. disks) are accessed via the framework, with arbitrary stacking allowed. Handlers are used to perform the actions implemented by each layer. Layers may provide such services as disk mirroring, or maybe just something as simple as MBR partitionning. All disk devices have the same major number through this interface and minor number assignation is dynamic through DEVFS. Each layer exports an identical interface to those above it or to the outside world. It would be quite possible (and easy) to further divide a disklabel partition into further partitions by disklabelling that partition. The present name for this module is the SLICE module, but I'm not sure that this is generic enough. I've been thinking of DASD (IBM's name for disk (Direct Access Storage Device) or DAS (similar). I'd have to do some 'bulk find and replace' operations but I'd rather do it now than later. Any thoughts about these names would be gratefully appreciated.. failing violent objections, we might look forward to seeing a /sys/dev/slice or /sys/dev/das (no, not DAAS for those .au members). and soon, /sys/netgraph. Netgraph has been in production here or 6 months and has proven EXTREMELY useful. I hope the SLICE code is as useful. It's also really needed to do DEVFS correctly, which is why you haven't seen any DEVFS work from me recently.. this is part of it.. julian