From owner-freebsd-arch Wed Feb 26 13:33:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B993837B401 for ; Wed, 26 Feb 2003 13:33:50 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E69C443FA3 for ; Wed, 26 Feb 2003 13:33:49 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1QLXmEv028751 for ; Wed, 26 Feb 2003 22:33:49 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org Subject: (almost) Ready to ditch device major numbers. From: Poul-Henning Kamp Date: Wed, 26 Feb 2003 22:33:48 +0100 Message-ID: <28750.1046295228@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We are now (almost) ready to ditch device major numbers if we want to. For POSIXMISTAKE like reasons we cannot abolish major-minor numbers entirely, but at least we can automate them enough to make them a non-pain. There are some things we can _not_ do, the main one being assign the same major-minor tupple to two devices at the same time. Since the minor is under control of the device driver, this more or less means that we cannot automagically share major numbers between two or more different cdevsw structurs. We will therefore still have a limit of <256 device drivers until we also tackle minor-number assignment (something which is much harder and much more intrusive and therefore maybe not even feasible) but at least the limit will be "256 loaded drivers" and not "256 drivers for which we have assigned minor numbers. Here is a suggested sequence of events, not a timeline by any strech of the imagination, merely things we can do and the order we can do them in: 1) Build a bitmap of registered majors (from conf/majors) at kernel-compile so the kernel can know which majors we can risk KLD's to use. 2) Introduce "MAJOR_AUTO" or similar for use in cdevsw structures. This should autoallocate the highest free major number for that cdevsw without people having to go to the trouble of registering a number from sys/conf/majors. The major number will be non-persistent and will vary from boot to boot. Tools like tripwire will hate us for it, but such tools need to learn about DEVFS anyway. 3) Stop allocating major numbers from conf/majors, unless very special requirements mandate they have to be static across boots and systems. 4) Start actively revoking registrations from conf/majors for in-our-tree drivers which works just great with MAJOR_AUTO. 5) Remove the d_maj field from struct cdevsw entirely and make dynamic allocation the default. Comments welcome. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message