From owner-freebsd-arch@FreeBSD.ORG Thu Jul 13 11:15:00 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG 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 81D6416A4DA for ; Thu, 13 Jul 2006 11:15:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81EA943D46 for ; Thu, 13 Jul 2006 11:14:59 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (wtcfqp@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6DBEqP5067293 for ; Thu, 13 Jul 2006 13:14:57 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6DBEqQ6067292; Thu, 13 Jul 2006 13:14:52 +0200 (CEST) (envelope-from olli) Date: Thu, 13 Jul 2006 13:14:52 +0200 (CEST) Message-Id: <200607131114.k6DBEqQ6067292@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG In-Reply-To: <20060710193005.GA34287@crodrigues.org> X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 13 Jul 2006 13:14:57 +0200 (CEST) Cc: Subject: Re: [RFC] mount can figure out fstype automatically X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.ORG List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 11:15:00 -0000 Sorry for re-posting this, but I only posted to the -current list ... now I'm seeing that the real discussion seems to take place here on -arch. Craig Rodrigues wrote: > Scott Long wrote: > > So in your opinion and experience, what are the pros and cons of > > maintaining a table of magic numbers? > > One con: every time you add a new filesystem, you need to update > mount(8). Not a big deal, but it is something. How about this idea: Every filesystem registers a piece of "magic information" somewhere (maybe kenv or sysctl, or even a file somewhere in /etc or whatever). Then mount(8) just has to look at that list, compare in turn with the device in question, and call the respective filesystem if found (if the mount fails even though the magic matched, mount(8) could print a warning and continue looking at the remaining filesystems' magics). If a new filesystem is added, it registers its magic as explained above. No need to update mount(8) itself. For the case where multiple filesystems can share their structures (like UDF + ISO9660), a priority code could be assigned, so that the filesystem that's "more useful" (or more popular) is probed first. Also, filesystems that are difficult to recognize (like FAT) would get a low priority code, so they are probed last. Note that the user can always override the selection by manually specifying the filesystem with the -t flag of mount(8), so there shouldn't be any regression. Just my 2 cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio