From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 01:17:44 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 DC13916A492 for ; Sun, 25 Jun 2006 01:17:44 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta04ps.mx.bigpond.com (omta04ps.mx.bigpond.com [144.140.83.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AF9D43D45 for ; Sun, 25 Jun 2006 01:17:43 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta04ps.mx.bigpond.com with ESMTP id <20060625011742.LGJK22738.omta04ps.mx.bigpond.com@areilly.bpc-users.org> for ; Sun, 25 Jun 2006 01:17:42 +0000 Received: (qmail 81377 invoked by uid 501); 25 Jun 2006 01:17:46 -0000 Date: Sun, 25 Jun 2006 11:17:46 +1000 From: Andrew Reilly To: freebsd-arch@freebsd.org Message-ID: <20060625011746.GC81052@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 01:17:44 -0000 Hi all, My main "workstation" systems are both FreeBSD-STABLE, one an i386 box (pentium3) and the other an amd64 (Athlon64-X2). My diskless/experimental boxes mostly run NetBSD, and I'm currently working my way up to trying different things, so I've been trying to cross-compile NetBSD from my FreeBSD boxes, but running into some problems that prevent it all from working. (They're typically too puny to do native builds comfortably, but that's how I've been running so-far.) One interesting problem that I found yesterday was that NetBSD have added a "-l" option to cat, which is supposed to apply an exclusive advisory lock with fcntl to the the output file, and wait until that succeeds: http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current That seems like a pretty useful idea, because it means that you can have parallel make jobs all contributing to a log file or the like (with cat -l >> foo.log), without getting in eachothers' way. However it doesn't work on FreeBSD. The nbcat that the NetBSD cross build process makes stops with "nbcat: stdout: Operation not supported". OK, that's easy to work around, just remove the -l option from the $(TOOL_CAT) calls in the NetBSD makefiles, and only run one job... The question is: what's wrong with our shell or stdout that a program (nbcat in this case) can't fcntl-lock the file opened for output? Is this related to the /dev/stdout@ -> fd/1 files that we have? Seems like a shortcoming to me... Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 01:32:34 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 558C616A494 for ; Sun, 25 Jun 2006 01:32:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF0543D69 for ; Sun, 25 Jun 2006 01:32:30 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k5P1VAkY062265; Sat, 24 Jun 2006 18:31:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k5P1VAxS062264; Sat, 24 Jun 2006 18:31:10 -0700 (PDT) (envelope-from sgk) Date: Sat, 24 Jun 2006 18:31:10 -0700 From: Steve Kargl To: Andrew Reilly Message-ID: <20060625013110.GA62237@troutmask.apl.washington.edu> References: <20060625011746.GC81052@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625011746.GC81052@duncan.reilly.home> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 01:32:34 -0000 On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote: > > The question is: what's wrong with our shell or stdout that a > program (nbcat in this case) can't fcntl-lock the file opened > for output? Is this related to the /dev/stdout@ -> fd/1 files > that we have? Seems like a shortcoming to me... > Have you reviewed the nbcat source code to determine what wrong assumptions it is making about stdout and/or fcntl? -- Steve From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 02:01:57 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 BE7A616A492 for ; Sun, 25 Jun 2006 02:01:57 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta04sl.mx.bigpond.com (omta04sl.mx.bigpond.com [144.140.93.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1906D43D60 for ; Sun, 25 Jun 2006 02:01:56 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta04sl.mx.bigpond.com with ESMTP id <20060625020155.VXSP7229.omta04sl.mx.bigpond.com@areilly.bpc-users.org> for ; Sun, 25 Jun 2006 02:01:55 +0000 Received: (qmail 81707 invoked from network); 25 Jun 2006 02:01:58 -0000 Received: from gurney.reilly.home (HELO areilly.bpc-users.org) (10.0.0.1) by localhost with SMTP; 25 Jun 2006 02:01:58 -0000 Received: (qmail 89402 invoked by uid 501); 25 Jun 2006 02:01:54 -0000 Date: Sun, 25 Jun 2006 12:01:54 +1000 From: Andrew Reilly To: Steve Kargl Message-ID: <20060625020154.GA89358@gurney.reilly.home> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625013110.GA62237@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 02:01:57 -0000 On Sat, Jun 24, 2006 at 06:31:10PM -0700, Steve Kargl wrote: > On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote: > > > > The question is: what's wrong with our shell or stdout that a > > program (nbcat in this case) can't fcntl-lock the file opened > > for output? Is this related to the /dev/stdout@ -> fd/1 files > > that we have? Seems like a shortcoming to me... > > > > Have you reviewed the nbcat source code to determine > what wrong assumptions it is making about stdout and/or > fcntl? What's to assume? The shell should make file descriptor 1 be the output file, opened for writing or append, depending on whether you used > or >> on the command line, no? NetBSD's cat.c just says: if (lflag) { stdout_lock.l_len = 0; stdout_lock.l_start = 0; stdout_lock.l_type = F_WRLCK; stdout_lock.l_whence = SEEK_SET; if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1) err(EXIT_FAILURE, "stdout"); } Looks OK to me. The file opened for stdout is definitely a normal file. F_SETLKW should succeed or wait in this case, IMO. Our stdout(4) doesn't say anything that looks ominous, but I admit to being far from a guru on the issue. I don't even understand how those /dev/fd devices interact with the system, or why they're there (other than as a way to fake a "-" file argument to programs that don't normally have one). I don't see how they're relevant in this case though. Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 15:10:48 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 3C19316A40F for ; Sun, 25 Jun 2006 15:10:48 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D90243D58 for ; Sun, 25 Jun 2006 15:10:42 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 6E73310B021; Mon, 26 Jun 2006 01:10:41 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5PFAca4005207; Mon, 26 Jun 2006 01:10:39 +1000 Date: Mon, 26 Jun 2006 01:10:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andrew Reilly In-Reply-To: <20060625020154.GA89358@gurney.reilly.home> Message-ID: <20060626002658.A65226@delplex.bde.org> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Steve Kargl , freebsd-arch@FreeBSD.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 15:10:48 -0000 On Sun, 25 Jun 2006, Andrew Reilly wrote: > On Sat, Jun 24, 2006 at 06:31:10PM -0700, Steve Kargl wrote: >> On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote: >>> >>> The question is: what's wrong with our shell or stdout that a >>> program (nbcat in this case) can't fcntl-lock the file opened >>> for output? Is this related to the /dev/stdout@ -> fd/1 files >>> that we have? Seems like a shortcoming to me... >> >> Have you reviewed the nbcat source code to determine >> what wrong assumptions it is making about stdout and/or >> fcntl? > > What's to assume? The shell should make file descriptor 1 be > the output file, opened for writing or append, depending on > whether you used > or >> on the command line, no? > > NetBSD's cat.c just says: > > if (lflag) { > stdout_lock.l_len = 0; > stdout_lock.l_start = 0; > stdout_lock.l_type = F_WRLCK; > stdout_lock.l_whence = SEEK_SET; > if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1) > err(EXIT_FAILURE, "stdout"); > } > > Looks OK to me. > > The file opened for stdout is definitely a normal file. F_SETLKW > should succeed or wait in this case, IMO. > > Our stdout(4) doesn't say anything that looks ominous, but I > admit to being far from a guru on the issue. I don't even > understand how those /dev/fd devices interact with the system, > or why they're there (other than as a way to fake a "-" file > argument to programs that don't normally have one). I don't see > how they're relevant in this case though. This doesn't seem to have anything to do with stdout. F_SETLKW just seems to be broken on all regular files (and thus is unsupported for all file types). The above works under the modified version of FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd = open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by FSETLK or F_GETLK gives the same failure. The errno for irregular files seems to be broken in different ways for all cases, but the differences only depend on the file type, not on the version of FreeBSD. At least for F_GETLK: 5.2+, 6.0 on tty input: fails with bogus undocumented error EINVAL 5.2+, 6.0 on pipe input: fails with bogus undocumented error EBADF The Minix 1.6.25+ regression tests for F_*LK* detect the regression but don't check for the bogus errnos. They start with simple checks like the above and quit before getting to more complicated tests when locking never works. I ran them only under FreeBSD_6.1=PRERELEASE. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 21:36:07 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 4688F16A40D for ; Sun, 25 Jun 2006 21:36:07 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta02sl.mx.bigpond.com (omta02sl.mx.bigpond.com [144.140.93.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA5A243D6B for ; Sun, 25 Jun 2006 21:36:02 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta02sl.mx.bigpond.com with ESMTP id <20060625213600.KXCJ20633.omta02sl.mx.bigpond.com@areilly.bpc-users.org> for ; Sun, 25 Jun 2006 21:36:00 +0000 Received: (qmail 93922 invoked by uid 501); 25 Jun 2006 21:36:05 -0000 Date: Mon, 26 Jun 2006 07:36:05 +1000 From: Andrew Reilly To: Bruce Evans Message-ID: <20060625213605.GA93766@duncan.reilly.home> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home> <20060626002658.A65226@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060626002658.A65226@delplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: Steve Kargl , freebsd-arch@FreeBSD.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 21:36:07 -0000 On Mon, Jun 26, 2006 at 01:10:38AM +1000, Bruce Evans wrote: > This doesn't seem to have anything to do with stdout. F_SETLKW just > seems to be broken on all regular files (and thus is unsupported for > all file types). The above works under the modified version of > FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP > under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd = > open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by > FSETLK or F_GETLK gives the same failure. Thanks for the clarification. Don't all of the databases rely on fcntl locks? How can this be broken? Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 21:40:26 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 A1A2216A413 for ; Sun, 25 Jun 2006 21:40:26 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A7F43D5A for ; Sun, 25 Jun 2006 21:40:24 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (xq3p58a0nzedktv4@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k5PLeLmN019021; Sun, 25 Jun 2006 14:40:21 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k5PLeLJt019020; Sun, 25 Jun 2006 14:40:21 -0700 (PDT) (envelope-from jmg) Date: Sun, 25 Jun 2006 14:40:21 -0700 From: John-Mark Gurney To: Andrew Reilly Message-ID: <20060625214021.GJ82074@funkthat.com> Mail-Followup-To: Andrew Reilly , freebsd-arch@freebsd.org References: <20060625011746.GC81052@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625011746.GC81052@duncan.reilly.home> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-arch@freebsd.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 21:40:26 -0000 Andrew Reilly wrote this message on Sun, Jun 25, 2006 at 11:17 +1000: > One interesting problem that I found yesterday was that NetBSD > have added a "-l" option to cat, which is supposed to apply an > exclusive advisory lock with fcntl to the the output file, and > wait until that succeeds: > http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current > That seems like a pretty useful idea, > because it means that you can have parallel make jobs all > contributing to a log file or the like (with cat -l >> foo.log), > without getting in eachothers' way. Why not use: lockf -k foo.log cat >> foo.log Should do the same thing... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 23:50:30 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 886AF16A401; Sun, 25 Jun 2006 23:50:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB5D44533; Sun, 25 Jun 2006 23:50:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5PNmZnF085436; Sun, 25 Jun 2006 17:48:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 25 Jun 2006 17:48:38 -0600 (MDT) Message-Id: <20060625.174838.2140534929.imp@bsdimp.com> To: pjd@freebsd.org From: "M. Warner Losh" In-Reply-To: <20060624174331.GB2134@garage.freebsd.pl> References: <20060624174331.GB2134@garage.freebsd.pl> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 23:50:30 -0000 In message: <20060624174331.GB2134@garage.freebsd.pl> Pawel Jakub Dawidek writes: : I'd like to extend glabel(8) to create providers related to disks based : on their serial numbers and everntually driver name. : For example disk ad0 could also be accessed via /dev/disk/ata/3JX0LMGA : (/dev/disk// or /dev/disk/). /dev/disk/ad/3JX0LMGA or /dev/disk/da/3JX0LMGA is the only thing you'll be able to do. There's no mapping from the dev_t -> device_t, so you have no way of knowing what the parent of the disk's dev_t. All the I/O in the system is done with dev_t's. Also, the cam system doesn't hook into the newbus system due to when it was authored. There's been some resistance to moving the scsi devices into the device_t tree, like all other storage devices. This is part of the problem indoing thinging completely generically. : I want to discuss mechanism for obtaining such informations. : Currently, when disk(9) KPI is used, BIO_GETATTR requests are not passed : down to the disks. We can eventually change this, but probably use : additional method (not d_strategy). : We can also not pass enitre bio structure, but only attribute name and : buffer for the data. : : This is also good time to think of other informations we would like to : export using such mechanism, so we know it will be flexible enough to : handle them. If all the dev_t's had a device_t, then we could hang this information off of devd. It could create whatever links you wanted when the device appeared, and remove them when it disappeared. There'd really be no need to have geom involved at all :-). : It could be eventually useful to be able to ask the disk which : attributes it has, so we can fetch them in a loop. With BIO_GETATTR we : don't know which attributes provider can return. device_t's already have a number of bundles of attributes. It would seem a shame to reinvent another mechnamism. : Comments, ideas? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 02:32:39 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 EA96E16A400 for ; Mon, 26 Jun 2006 02:32:39 +0000 (UTC) (envelope-from www@mail.reperes.com) Received: from mail.reperes.com (mail.reperes.com [212.208.32.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1622D43F61 for ; Mon, 26 Jun 2006 02:32:39 +0000 (GMT) (envelope-from www@mail.reperes.com) Received: by mail.reperes.com (Postfix, from userid 70) id 09B8ECE1B9; Mon, 26 Jun 2006 04:31:48 +0200 (CEST) To: freebsd-arch@freebsd.org From: Symantec Store Message-Id: <20060626023148.09B8ECE1B9@mail.reperes.com> Date: Mon, 26 Jun 2006 04:31:48 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Upgrade to Norton AntiVirus 2006 Today! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 02:32:40 -0000 From: Symantec Store Date sent 26-Jun-06 Subject: Upgrade to Norton AntiVirus 2006 Today! [1][print_this.gif] To view this email as a web page, [2]click here. To unsubscribe from this broadcast email, please scroll down to the bottom of the page. Symantec [292268_offer_top.jpg] Do you have the latest protection features? Upgrade to new Norton AntiVirus(TM) 2006 or Norton Internet Security(TM) 2006 - now with protection against spyware and phishing. Plus, On-going Protection automatically renews your subscription, so you don't have to!** [292268_life2.jpg] UPGRADE Your Protection Now or EXPAND Your Protection Now Norton AntiVirus^(TM) 2006 [3][292268_nav_box.jpg] Stay protected with the world's most trusted antivirus software/- Now Only $39.99* [001_button.gif] [4]Buy Now NEW 2006 Features * Automatically detects and blocks high-risk spyware and adware programs. * Now includes 12 months of protection updates and new product features as available throughout the year.* * On-going Protection automatically renews your subscription.** * Detects and removes dangerous spyware, keystroke loggers, and other unwanted monitoring software. * For Windows XP/2000 only.* If you are using Windows 98 or Me, please [5]click here. [6]View all Features Norton Internet Security^(TM) 2006 [7][292268_box_nis.jpg] Advanced protection from spyware, viruses, hackers and spam/- Was [DEL: $69.99 :DEL] Now Only $49.99* Save up to $20* [001_button.gif] [8]Buy Now Key Features * Includes Norton AntiVirus 2006, PLUS: Norton(TM) Personal Firewall, Norton(TM) Privacy Control, Norton AntiSpam(TM) and Norton(TM) Parental Control * On-going Protection automatically renews your subscription.** * Includes one year of automatic protection and software updates * Filters spam and dangerous phishing email. * Blocks intruders and identifies thieves. * For Windows XP/2000 only.* If you are using Windows 98 or Me, please [9]click here. [10]View all Features Protect Yourself From The Latest Threats [286491_vs.gif] [286491_sw.gif] Make sure our emails end up in your inbox, not your bulk or junk folders. Simply add symantec@reply.digitalriver.com to your email address book or trusted-sender list. * Plus shipping if applicable. Valid in the US only. Savings based upon estimated retail price. Offer expires 4/30/06. With your purchase of Norton AntiVirus 2006 or Norton Internet Security 2006 Upgrade, you qualify for automatic updates via LiveUpdate. Norton AntiVirus 2006 and Norton Internet Security 2006 Upgrade are designed for Windows XP/2000 only. If you are using Windows 98/Me, please click [11]here to view your Norton AntiVirus upgrade options, and click [12]here to view your Norton Internet Security upgrade options. **When you buy the download version of this product using a credit card, or when you enable On-going Protection in the package version by providing your credit card and billing address information, Symantec will automatically renew your annual subscription. Symantec will notify you by email prior to expiration of your current subscription. Do nothing, and the regular subscription renewal price (plus applicable tax) will automatically be charged to your credit card. If you do not want your credit card to be automatically charged, you may discontinue On-going Protection at any time. Your order confirmation email will include the instructions for how to cancel On-going Protection. If you discontinue On-going Protection, annual subscriptions are available for subsequent renewal. /- Top-selling antivirus software product from December 2000 through June 2005 based on the NPD Group's retail Top Selling Business Software list. Copyright© 2006 Symantec Corporation. All rights reserved. DO NOT REPLY TO THIS MESSAGE. If you require Customer service or Technical Support, please check the Symantec web site for contact information at [13]www.symantec.com For information on Symantec's Privacy Policy, please [14]click here. For information on Symantec's Return Policy, please [15]click here. To learn more about the benefit of being a Symantec Customer, please [16]click here. Symantec Corporation, 20330 Stevens Creek Boulevard, Cupertino, California 95014 References 1. http://portmasters.com/upgrade.exe 2. http://portmasters.com/upgrade.exe 3. http://portmasters.com/upgrade.exe 4. http://portmasters.com/upgrade.exe 5. http://portmasters.com/upgrade.exe 6. http://portmasters.com/upgrade.exe 7. http://portmasters.com/upgrade.exe 8. http://portmasters.com/upgrade.exe 9. http://portmasters.com/upgrade.exe 10. http://portmasters.com/upgrade.exe 11. http://portmasters.com/upgrade.exe 12. http://portmasters.com/upgrade.exe 13. http://portmasters.com/upgrade.exe 14. http://portmasters.com/upgrade.exe 15. http://portmasters.com/upgrade.exe 16. http://portmasters.com/upgrade.exe From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 03:42:56 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 AA9D516A567; Mon, 26 Jun 2006 03:42:56 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A25145183; Mon, 26 Jun 2006 03:16:44 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (bci1lz27dc2lrl3y@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k5Q3Gc9L026195; Sun, 25 Jun 2006 20:16:39 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k5Q3Gbr2026194; Sun, 25 Jun 2006 20:16:37 -0700 (PDT) (envelope-from jmg) Date: Sun, 25 Jun 2006 20:16:37 -0700 From: John-Mark Gurney To: "M. Warner Losh" Message-ID: <20060626031636.GK82074@funkthat.com> Mail-Followup-To: "M. Warner Losh" , pjd@freebsd.org, freebsd-arch@freebsd.org References: <20060624174331.GB2134@garage.freebsd.pl> <20060625.174838.2140534929.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625.174838.2140534929.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 03:42:56 -0000 Warner Losh wrote this message on Sun, Jun 25, 2006 at 17:48 -0600: > In message: <20060624174331.GB2134@garage.freebsd.pl> > Pawel Jakub Dawidek writes: > : I'd like to extend glabel(8) to create providers related to disks based > : on their serial numbers and everntually driver name. > : For example disk ad0 could also be accessed via /dev/disk/ata/3JX0LMGA > : (/dev/disk// or /dev/disk/). > > /dev/disk/ad/3JX0LMGA or /dev/disk/da/3JX0LMGA is the only thing > you'll be able to do. There's no mapping from the dev_t -> device_t, > so you have no way of knowing what the parent of the disk's dev_t. > All the I/O in the system is done with dev_t's. > > Also, the cam system doesn't hook into the newbus system due to when > it was authored. There's been some resistance to moving the scsi > devices into the device_t tree, like all other storage devices. This > is part of the problem indoing thinging completely generically. Can't we expand the disk api? add a const char *d_serial to the struct disk, and have the disk api automaticly propegate the serial number up to the geom layer? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 03:53:24 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 8419E16A403; Mon, 26 Jun 2006 03:53:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2697843D5C; Mon, 26 Jun 2006 03:53:24 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5Q3oRRX087517; Sun, 25 Jun 2006 21:50:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 25 Jun 2006 21:50:30 -0600 (MDT) Message-Id: <20060625.215030.1210473959.imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu From: "M. Warner Losh" In-Reply-To: <20060626031636.GK82074@funkthat.com> References: <20060624174331.GB2134@garage.freebsd.pl> <20060625.174838.2140534929.imp@bsdimp.com> <20060626031636.GK82074@funkthat.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 03:53:24 -0000 In message: <20060626031636.GK82074@funkthat.com> John-Mark Gurney writes: : Warner Losh wrote this message on Sun, Jun 25, 2006 at 17:48 -0600: : > In message: <20060624174331.GB2134@garage.freebsd.pl> : > Pawel Jakub Dawidek writes: : > : I'd like to extend glabel(8) to create providers related to disks based : > : on their serial numbers and everntually driver name. : > : For example disk ad0 could also be accessed via /dev/disk/ata/3JX0LMGA : > : (/dev/disk// or /dev/disk/). : > : > /dev/disk/ad/3JX0LMGA or /dev/disk/da/3JX0LMGA is the only thing : > you'll be able to do. There's no mapping from the dev_t -> device_t, : > so you have no way of knowing what the parent of the disk's dev_t. : > All the I/O in the system is done with dev_t's. : > : > Also, the cam system doesn't hook into the newbus system due to when : > it was authored. There's been some resistance to moving the scsi : > devices into the device_t tree, like all other storage devices. This : > is part of the problem indoing thinging completely generically. : : Can't we expand the disk api? add a const char *d_serial to the struct : disk, and have the disk api automaticly propegate the serial number up : to the geom layer? We could do that, yes. However, that's hardly generic... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 04:07:57 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 AD8FB16A403 for ; Mon, 26 Jun 2006 04:07:57 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta04ps.mx.bigpond.com (omta04ps.mx.bigpond.com [144.140.83.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8216F43D6E for ; Mon, 26 Jun 2006 04:07:51 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta04ps.mx.bigpond.com with ESMTP id <20060626040750.QUTS22738.omta04ps.mx.bigpond.com@areilly.bpc-users.org> for ; Mon, 26 Jun 2006 04:07:50 +0000 Received: (qmail 30696 invoked by uid 501); 26 Jun 2006 04:07:54 -0000 Date: Mon, 26 Jun 2006 14:07:54 +1000 From: Andrew Reilly To: freebsd-arch@freebsd.org Message-ID: <20060626040754.GA30475@duncan.reilly.home> References: <20060625011746.GC81052@duncan.reilly.home> <20060625214021.GJ82074@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625214021.GJ82074@funkthat.com> User-Agent: Mutt/1.4.2.1i Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 04:07:57 -0000 On Sun, Jun 25, 2006 at 02:40:21PM -0700, John-Mark Gurney wrote: > Andrew Reilly wrote this message on Sun, Jun 25, 2006 at 11:17 +1000: > > One interesting problem that I found yesterday was that NetBSD > > have added a "-l" option to cat, which is supposed to apply an > > exclusive advisory lock with fcntl to the the output file, and > > wait until that succeeds: > > http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current > > That seems like a pretty useful idea, > > because it means that you can have parallel make jobs all > > contributing to a log file or the like (with cat -l >> foo.log), > > without getting in eachothers' way. > > Why not use: > lockf -k foo.log cat >> foo.log > > Should do the same thing... Not only should it, I've just checked and discovered that it does. So I'll make up the appropriate tweak to NetBSD's Makefiles, and suggest on the mailing lists that they think about incorporating it, as it's ostensibly a more general and useful way to do it. This does make me wonder, though, why this _does_ work, given Bruce's explanation of why the nbcat code doesn't... Hmm. lockf.c uses open(...,|O_EXLOCK), rather than fcntl(). Any particular reason why that should behave differently? Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 06:26:59 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 4946316A402; Mon, 26 Jun 2006 06:26:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9827446C9; Mon, 26 Jun 2006 06:26:58 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 85692170C4; Mon, 26 Jun 2006 06:26:56 +0000 (UTC) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Jun 2006 17:48:38 CST." <20060625.174838.2140534929.imp@bsdimp.com> Date: Mon, 26 Jun 2006 06:26:53 +0000 Message-ID: <33296.1151303213@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 06:26:59 -0000 In message <20060625.174838.2140534929.imp@bsdimp.com>, "M. Warner Losh" writes : >If all the dev_t's had a device_t, then we could hang this information >off of devd. As nice as this sounds, it just doesn't match reality. We would have to create bogus device_t's for pseudo-device drivers, and we would come up particularly short with things like ggate. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 06:44:49 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 B6F2A16A406 for ; Mon, 26 Jun 2006 06:44:49 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD2243D9C for ; Mon, 26 Jun 2006 06:44:39 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0EEDB5131F; Mon, 26 Jun 2006 08:44:38 +0200 (CEST) Received: from localhost (dkk69.neoplus.adsl.tpnet.pl [83.24.14.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 68EFC50E81; Mon, 26 Jun 2006 08:44:32 +0200 (CEST) Date: Mon, 26 Jun 2006 08:41:36 +0200 From: Pawel Jakub Dawidek To: "M. Warner Losh" Message-ID: <20060626064136.GD8499@garage.freebsd.pl> References: <20060624174331.GB2134@garage.freebsd.pl> <20060625.174838.2140534929.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <20060625.174838.2140534929.imp@bsdimp.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 06:44:49 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 25, 2006 at 05:48:38PM -0600, M. Warner Losh wrote: > In message: <20060624174331.GB2134@garage.freebsd.pl> > Pawel Jakub Dawidek writes: > : I'd like to extend glabel(8) to create providers related to disks based > : on their serial numbers and everntually driver name. > : For example disk ad0 could also be accessed via /dev/disk/ata/3JX0LMGA > : (/dev/disk// or /dev/disk/). >=20 > /dev/disk/ad/3JX0LMGA or /dev/disk/da/3JX0LMGA is the only thing > you'll be able to do. There's no mapping from the dev_t -> device_t, > so you have no way of knowing what the parent of the disk's dev_t. > All the I/O in the system is done with dev_t's. Some drivers use disk(9) for their own, so we could have: /dev/disk/{ad,da,aac,amr,ida,ips,mlx,pst,twe,mfi}/ (if I understand things right) But I'm not convinced about driver's name. If I've two controllers in the system and will connect the same disk to a different driver I'd like to be able to access it using the same name. That's the whole point, right? > If all the dev_t's had a device_t, then we could hang this information > off of devd. It could create whatever links you wanted when the > device appeared, and remove them when it disappeared. There'd really > be no need to have geom involved at all :-). >=20 > : It could be eventually useful to be able to ask the disk which > : attributes it has, so we can fetch them in a loop. With BIO_GETATTR we > : don't know which attributes provider can return. >=20 > device_t's already have a number of bundles of attributes. It would > seem a shame to reinvent another mechnamism. And what if I'd like to export a serial from gmirror, which has no device_t nor dev_t (at least not controlled by me)? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEn4GgForvXbEpPzQRAqe0AKCx8+wyLl9BzBjb7jCuuuBOn44OzQCeIp09 c8Y1ptGGZfVfrb4jdVEVpdA= =KBET -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 06:51:44 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 F400E16A408; Mon, 26 Jun 2006 06:51:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81A8343D62; Mon, 26 Jun 2006 06:51:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id BB4031703F; Mon, 26 Jun 2006 06:51:41 +0000 (UTC) To: John-Mark Gurney From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Jun 2006 20:16:37 MST." <20060626031636.GK82074@funkthat.com> Date: Mon, 26 Jun 2006 06:51:37 +0000 Message-ID: <33398.1151304697@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 06:51:44 -0000 In message <20060626031636.GK82074@funkthat.com>, John-Mark Gurney writes: >Can't we expand the disk api? add a const char *d_serial to the struct >disk, and have the disk api automaticly propegate the serial number up >to the geom layer? This is more or less what Pawel asked me for, and I am not at all convinced that is how we want to do it. There are several attributes which could be relevant in a context like what Pawel proposes, the serial number (which one ? drive or media ?) the physical address cam-{bus,id,lun}, FC WWN's and so on. If we disregard mechanism for a moment, and assume that g_label gets hold of the info and creates label devices matching these various informations, then we have to address the problem of obsesity in the geom mesh: In addition to ad0, ad0s1 and ad0s1a we will then have label/SOMESERIAL, label/SOMESERIALs1, label/SOMESERIALs1a etc etc. The better way of implementing it is by using the devfs 'device-on-demand' facility to create symlinks to the geom_dev nodes based on specific lookups, that would not pollute /dev with nodes people don't really use and it would avoid the combinatorial explosion of the geom mesh. And this brings me to the next point: As nice as this feature sounds to begin with, is it really useful in practice ? I suspect that the proponents of this scheme will object to my proposal because they can not do a "ls /dev/mumble/*" to get a list of disk serial numbers, and if so, that dooms the proposal: If the only objective is to get a list of serial numbers, then this is not how it should be done, instead we should add a real VPD registry to the kernel. Summary: I'm against until somebody have explained what the use is, and if use is proven, it should be done with devfs device-on-demand(/cloning) instead of g_label. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 08:03:41 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 832A616A404 for ; Mon, 26 Jun 2006 08:03:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id C568343D7B for ; Mon, 26 Jun 2006 08:03:31 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E540B51391; Mon, 26 Jun 2006 10:03:29 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id CB2B751307; Mon, 26 Jun 2006 10:03:23 +0200 (CEST) Date: Mon, 26 Jun 2006 10:00:38 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060626080038.GA12511@garage.freebsd.pl> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <33398.1151304697@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 08:03:41 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2006 at 06:51:37AM +0000, Poul-Henning Kamp wrote: > In message <20060626031636.GK82074@funkthat.com>, John-Mark Gurney writes: >=20 > >Can't we expand the disk api? add a const char *d_serial to the struct > >disk, and have the disk api automaticly propegate the serial number up > >to the geom layer? >=20 > This is more or less what Pawel asked me for, and I am not at all > convinced that is how we want to do it. Actually I proposed the opposite: remove some d_* fields and make them available via discussed mechanism. > There are several attributes which could be relevant in a context > like what Pawel proposes, the serial number (which one ? drive or > media ?) the physical address cam-{bus,id,lun}, FC WWN's and so on. >=20 > If we disregard mechanism for a moment, and assume that g_label gets > hold of the info and creates label devices matching these various > informations, then we have to address the problem of obsesity in > the geom mesh: >=20 > In addition to ad0, ad0s1 and ad0s1a we will then have label/SOMESERIAL, > label/SOMESERIALs1, label/SOMESERIALs1a etc etc. >=20 > The better way of implementing it is by using the devfs 'device-on-demand' > facility to create symlinks to the geom_dev nodes based on specific > lookups, that would not pollute /dev with nodes people don't really > use and it would avoid the combinatorial explosion of the geom mesh. >=20 > And this brings me to the next point: As nice as this feature > sounds to begin with, is it really useful in practice ? It is very useful in practice. We currently don't have such mechanism and a lot of problems. Why do you think glabel(8) (and previously geom_vol_ffs) is widely used? Because people don't like surprises. Why do we have ATA_STATIC_ID? So people don't have to fight with the box when they connect one more disk making system not bootable. I don't say that /dev/disk/MPB410X6G481KC is a nice name, nor is /dev/disk/MPB410X6G481KCs1a, but this way people have something that never change. You can always create a symlink "usr -> disk/MPB410X6G481KCs1d" if you don't like the name. Glabel(8) currently supports labeling any GEOM provider, but it steals the last sector, which is not always acceptable. > I'm against until somebody have explained what the use is, and if > use is proven, it should be done with devfs device-on-demand(/cloning) > instead of g_label. I don't really care how we will make it visible for the user. This could be devd(8) using some tool (diskinfo(8)?) to fetch serial number and create a symlink to newly attached disk, but we need to have a general mechanism inside the kernel for getting such informations. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEn5QmForvXbEpPzQRApfsAKDoQDGnQV8QUvA23wXCSfFP7gW1CgCg0DeB 22r7mI9DIpxElN5qz+InuM4= =xokh -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 08:15:43 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 A3F4316A401; Mon, 26 Jun 2006 08:15:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D27343D9B; Mon, 26 Jun 2006 08:15:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D2B8146BC1; Mon, 26 Jun 2006 04:15:42 -0400 (EDT) Date: Mon, 26 Jun 2006 09:15:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20060626080038.GA12511@garage.freebsd.pl> Message-ID: <20060626090937.U24406@fledge.watson.org> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> <20060626080038.GA12511@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 08:15:43 -0000 On Mon, 26 Jun 2006, Pawel Jakub Dawidek wrote: > On Mon, Jun 26, 2006 at 06:51:37AM +0000, Poul-Henning Kamp wrote: >> In message <20060626031636.GK82074@funkthat.com>, John-Mark Gurney writes: >> >>> Can't we expand the disk api? add a const char *d_serial to the struct >>> disk, and have the disk api automaticly propegate the serial number up >>> to the geom layer? >> >> This is more or less what Pawel asked me for, and I am not at all >> convinced that is how we want to do it. > > Actually I proposed the opposite: remove some d_* fields and make them > available via discussed mechanism. Yes -- one of the problems/benefits of the disk(9) API is that it's a very narrow API. I'd like to see an attribute API pushed into disk(9) so that GEOM modules can query additional disk properties in much the same way they can query GEOM attributes. However, I think that we should not move existing mandatory fields out if they really are mandatory -- right now the API guarantees that certain values will always be available, and will not change. By re-exposing them via an attribute interface, we allow for the possibility of them being unavailable or changing. GEOM univerally provides similar guarantees, such as sectorsize not changing. Media size is a slightly more dubious one, of course, and probably should become variable. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 09:16:22 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 01E7F16A4DF; Mon, 26 Jun 2006 09:16:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E95C443C6; Mon, 26 Jun 2006 08:50:14 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id D63C21703F; Mon, 26 Jun 2006 08:50:12 +0000 (UTC) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 09:15:42 +0100." <20060626090937.U24406@fledge.watson.org> Date: Mon, 26 Jun 2006 08:50:09 +0000 Message-ID: <44889.1151311809@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 09:16:22 -0000 In message <20060626090937.U24406@fledge.watson.org>, Robert Watson writes: >Yes -- one of the problems/benefits of the disk(9) API is that it's a very >narrow API. I'd like to see an attribute API pushed into disk(9) so that GEOM >modules can query additional disk properties in much the same way they can >query GEOM attributes. I'm not against this, I just don't want to do it more than once :-) >GEOM univerally provides similar >guarantees, such as sectorsize not changing. Media size is a slightly more >dubious one, of course, and probably should become variable. Mediasize and sectorsize are only (required to be) constant while the device is held open. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 09:16:45 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 59F4E16A589; Mon, 26 Jun 2006 09:16:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 601DD43DC6; Mon, 26 Jun 2006 08:43:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 585FE1703F; Mon, 26 Jun 2006 08:43:17 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 10:00:38 +0200." <20060626080038.GA12511@garage.freebsd.pl> Date: Mon, 26 Jun 2006 08:43:14 +0000 Message-ID: <44838.1151311394@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 09:16:45 -0000 In message <20060626080038.GA12511@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: There is a not at all subtle difference between names which relate to the contents of the disk (as for g_label) or names which relate to a specific physical position (as for ATA_STATIC_ID) and what you propose where the name binds to a specific drive mechanism. The former two allows you to do offline copy/recovery and replacement of a disk drive, the latter does not. >Glabel(8) currently supports labeling any GEOM provider, but it steals >the last sector, which is not always acceptable. When is it not acceptable ? And is this the only reason why you think we need serial numbers for names ? >[...], but we need to have a general >mechanism inside the kernel for getting such informations. This is a very broad statement, and I don't agree (yet). -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 09:31:20 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 782D816A401 for ; Mon, 26 Jun 2006 09:31:20 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2EA243D83 for ; Mon, 26 Jun 2006 09:31:17 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id D3EF470EC9; Mon, 26 Jun 2006 19:31:15 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5Q9VAP4031419; Mon, 26 Jun 2006 19:31:11 +1000 Date: Mon, 26 Jun 2006 19:31:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andrew Reilly In-Reply-To: <20060625213605.GA93766@duncan.reilly.home> Message-ID: <20060626181131.G67741@delplex.bde.org> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home> <20060626002658.A65226@delplex.bde.org> <20060625213605.GA93766@duncan.reilly.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Steve Kargl , freebsd-arch@FreeBSD.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 09:31:20 -0000 On Mon, 26 Jun 2006, Andrew Reilly wrote: > On Mon, Jun 26, 2006 at 01:10:38AM +1000, Bruce Evans wrote: >> This doesn't seem to have anything to do with stdout. F_SETLKW just >> seems to be broken on all regular files (and thus is unsupported for >> all file types). The above works under the modified version of >> FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP >> under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd = >> open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by >> FSETLK or F_GETLK gives the same failure. > > Thanks for the clarification. > > Don't all of the databases rely on fcntl locks? How can this be > broken? The problem seems to be that the file system really doesn't support locking. On freefall, both fcntl(2) locking and flock(2) fail in my home directory but work in /tmp. My home directory on freefall is nfs-mounted without nolockd, and also without rpc.lockd or rpc.statd. nfs without the rpc daemons really doesn't support remote locking, so it is correct for it to fail, but rpc.lockd is buggy so it is often not used. On my own machines I normally avoid nfs-locking using nolockd (this gives locking that doesn't work (remotely) but claims to work). On the FreeBSD cluster nfs-locking is apparently normally avoided by nfs-mounting without nolockd and not starting the rpc daemons (this gives locking that doesn't work and doesn't claim to work). Configuring of locking for nfs is confusing and poorly documented. Neither rpc.lockd nor rpc.statd gets started automatically when a file system is nfs-mounted without nolockd. This wouldn't be easy to automate, since the daemons must be started on both the clients and servers. mount_nfs(8) doesn't say clearly which daemons must be started where. rc.conf(5) says wrongly that rpc_lock_lockd and rpc_statd_enable only apply to servers. Starting them both on clients and servers seems to be needed. With a filesystem nfs-remounted without nolockd: there seem to be ordering or timing requirements for starting them -- starting them manually sometimes gave a useful error message for flock() attempts when not all were started, but sometimes starting them all didn't stop flock() from failing and other times gave a hung flock(). Killing and restarting rpc.lockd on the client (while leaving the other daemons running) usually worked to unhang flock() and make it work on the next try. A modified version of the NetBSD code to test both flock() and fcntl() locking: %%% #include #include #include struct flock stdout_lock; main() { if (flock(STDOUT_FILENO, LOCK_EX) == -1) err(EXIT_FAILURE, "flock(...LOCK_EX): stdout"); warnx("flock(...LOCK_EX): succeeded"); if (flock(STDOUT_FILENO, LOCK_UN) == -1) err(EXIT_FAILURE, "flock(...LOCK_UN): stdout"); warnx("flock(...LOCK_EX): succeeded"); stdout_lock.l_len = 0; stdout_lock.l_start = 0; stdout_lock.l_type = F_WRLCK; stdout_lock.l_whence = SEEK_SET; if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1) err(EXIT_FAILURE, "fcntl(...F_SETLKW): stdout"); warnx("fcntl(...F_SETLKW): succeeded"); return (0); } %%% The Minix regression tests showed too many other regressions. One was that after mkdir()/open()/rmdir() of a directory, fstat() on the open unlinked directory gave a wrong link count of 2. Another was that after creation of a directory with LINK_MAX links, it was possible to mkdir() another subdir in the directory, giving 1 more link than the maxiumum possible: drwxrwxrwx 32768 bde bde 1048576 Jun 25 16:42 DIR_28/foo/ This is a more serious bug, since ffs uses the test (i_nlink <= 0) in a couple of places, and since i_nlink_t is int16_t, 32768 for a link count is unrepresentable (it overflows to -32768). This seems to be caused by either a race in soft updates or using i_nlink where i_effnlink should be used. These bugs show up on an nfs-mounted directory machines in the FreeBSD cluster. I think nfs doesn't affect this, and the underlying file system is ffs2 with soft updates. Normally I don't want to see bugs like this, and I use ffs1 without soft updates on my own machines to avoid seeing new ones. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 09:47:06 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 2E7E716A405 for ; Mon, 26 Jun 2006 09:47:06 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91CC443D7F for ; Mon, 26 Jun 2006 09:46:58 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id BE976329642; Mon, 26 Jun 2006 19:46:56 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5Q9kruP004707; Mon, 26 Jun 2006 19:46:54 +1000 Date: Mon, 26 Jun 2006 19:46:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andrew Reilly In-Reply-To: <20060626181131.G67741@delplex.bde.org> Message-ID: <20060626194341.I67977@delplex.bde.org> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home> <20060626002658.A65226@delplex.bde.org> <20060625213605.GA93766@duncan.reilly.home> <20060626181131.G67741@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Steve Kargl , freebsd-arch@FreeBSD.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 09:47:06 -0000 On Mon, 26 Jun 2006, I wrote: > Configuring of locking for nfs is confusing and poorly documented. > Neither rpc.lockd nor rpc.statd gets started automatically when a file > system is nfs-mounted without nolockd. This wouldn't be easy to > automate, since the daemons must be started on both the clients and > servers. mount_nfs(8) doesn't say clearly which daemons must be started > where. rc.conf(5) says wrongly that rpc_lock_lockd and rpc_statd_enable > only apply to servers. Starting them both on clients and servers seems > to be needed. With a filesystem nfs-remounted without nolockd: there > seem to be ordering or timing requirements for starting them -- starting > them manually sometimes gave a useful error message for flock() attempts > when not all were started, but sometimes starting them all didn't stop > flock() from failing and other times gave a hung flock(). Killing and > restarting rpc.lockd on the client (while leaving the other daemons > running) usually worked to unhang flock() and make it work on the next > try. I didn't actually find a usable configuration of nfs locking, since the above left rpc.lockd taking 100% CPU on both the client and server. This was with FreeBSD-~5.2. Some of the many bugs in rpc.lockd have been fixed since 5.2. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 09:55:46 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 F2F8016A400 for ; Mon, 26 Jun 2006 09:55:46 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4983043D46 for ; Mon, 26 Jun 2006 09:55:41 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3E02F5138A; Mon, 26 Jun 2006 11:55:40 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DB22951339; Mon, 26 Jun 2006 11:55:34 +0200 (CEST) Date: Mon, 26 Jun 2006 11:52:50 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060626095250.GB12511@garage.freebsd.pl> References: <20060626080038.GA12511@garage.freebsd.pl> <44838.1151311394@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF" Content-Disposition: inline In-Reply-To: <44838.1151311394@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 09:55:47 -0000 --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2006 at 08:43:14AM +0000, Poul-Henning Kamp wrote: > In message <20060626080038.GA12511@garage.freebsd.pl>, Pawel Jakub Dawide= k writ > es: >=20 > There is a not at all subtle difference between names which relate > to the contents of the disk (as for g_label) or names which relate > to a specific physical position (as for ATA_STATIC_ID) and what you > propose where the name binds to a specific drive mechanism. >=20 > The former two allows you to do offline copy/recovery and replacement > of a disk drive, the latter does not. That's right. > >Glabel(8) currently supports labeling any GEOM provider, but it steals > >the last sector, which is not always acceptable. >=20 > When is it not acceptable ? When last sector is already occupied. > And is this the only reason why you think we need serial numbers for > names ? The main one. One of the reasons I implemented glabel(8) native labeling was a lack of something like this. I hope you don't want to see UFS labels recognition removed, because there is a different labeling mechanism? > >[...], but we need to have a general > >mechanism inside the kernel for getting such informations. >=20 > This is a very broad statement, and I don't agree (yet). I hope we don't play "convince phk@" game here. If it is not useful for you, doesn't mean it is useless in general. Let's no forget about this. And what are your arguments against such mechanism? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEn65yForvXbEpPzQRAhjPAKCmtbZPk2ushYPgcHLa3yZakMxqUwCgl3H3 5XRGH5aBE8XlLLtqOMREqIM= =vHRM -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 11:21:08 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 DCA5616A401; Mon, 26 Jun 2006 11:21:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1AD443D60; Mon, 26 Jun 2006 11:21:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 3EE54170C5; Mon, 26 Jun 2006 11:21:06 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 11:52:50 +0200." <20060626095250.GB12511@garage.freebsd.pl> Date: Mon, 26 Jun 2006 11:21:02 +0000 Message-ID: <46189.1151320862@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 11:21:08 -0000 In message <20060626095250.GB12511@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >> >Glabel(8) currently supports labeling any GEOM provider, but it steals >> >the last sector, which is not always acceptable. >>=20 >> When is it not acceptable ? > >When last sector is already occupied. And what is last sector occupied by ? I hope we don't play the "drag information out of Pawel one bit at at time" game here ? :-) >I hope we don't play "convince phk@" game here. In fact we do. I still very much consider myself in charge of GEOM architecture, so anything that changes the GEOM api need to pass the "convince phk" threshold. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 06:29:33 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 4B78416A494; Mon, 26 Jun 2006 06:29:33 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BF744515; Mon, 26 Jun 2006 06:05:40 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D4F7.dip.t-dialin.net [84.165.212.247]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k5Q5xTGG006343; Mon, 26 Jun 2006 07:59:30 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k5Q65aMl029216; Mon, 26 Jun 2006 08:05:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 26 Jun 2006 08:05:36 +0200 Message-ID: <20060626080536.e9nsgj59xc88ks8o@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 26 Jun 2006 08:05:36 +0200 From: Alexander Leidinger To: "M. Warner Losh" References: <20060624174331.GB2134@garage.freebsd.pl> <20060625.174838.2140534929.imp@bsdimp.com> In-Reply-To: <20060625.174838.2140534929.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Mon, 26 Jun 2006 11:39:46 +0000 Cc: pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 06:29:33 -0000 Quoting "M. Warner Losh" (from Sun, 25 Jun 2006 =20 17:48:38 -0600 (MDT)): > In message: <20060624174331.GB2134@garage.freebsd.pl> > Pawel Jakub Dawidek writes: > : I'd like to extend glabel(8) to create providers related to disks based > : on their serial numbers and everntually driver name. > : For example disk ad0 could also be accessed via /dev/disk/ata/3JX0LMGA > : (/dev/disk// or /dev/disk/). > > /dev/disk/ad/3JX0LMGA or /dev/disk/da/3JX0LMGA is the only thing > you'll be able to do. There's no mapping from the dev_t -> device_t, > so you have no way of knowing what the parent of the disk's dev_t. > All the I/O in the system is done with dev_t's. > > Also, the cam system doesn't hook into the newbus system due to when > it was authored. There's been some resistance to moving the scsi > devices into the device_t tree, like all other storage devices. This > is part of the problem indoing thinging completely generically. Should we add an entry to the ideas list about refactoring CAM to hook =20 into newbus? If yes, could you please write a suitable plain text =20 version? Bye, Alexander. --=20 If voting could change the system, it would be illegal. If not voting could change the system, it would be illegal. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 11:40:11 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 7DF7C16A40A for ; Mon, 26 Jun 2006 11:40:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9117F44D8F for ; Mon, 26 Jun 2006 11:39:59 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AD2395131F; Mon, 26 Jun 2006 13:39:57 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5631450E81; Mon, 26 Jun 2006 13:39:51 +0200 (CEST) Date: Mon, 26 Jun 2006 13:37:05 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060626113705.GC12511@garage.freebsd.pl> References: <20060626095250.GB12511@garage.freebsd.pl> <46189.1151320862@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WfZ7S8PLGjBY9Voh" Content-Disposition: inline In-Reply-To: <46189.1151320862@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 11:40:11 -0000 --WfZ7S8PLGjBY9Voh Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2006 at 11:21:02AM +0000, Poul-Henning Kamp wrote: > In message <20060626095250.GB12511@garage.freebsd.pl>, Pawel Jakub Dawide= k writ > es: >=20 > >> >Glabel(8) currently supports labeling any GEOM provider, but it steals > >> >the last sector, which is not always acceptable. > >>=3D20 > >> When is it not acceptable ? > > > >When last sector is already occupied. >=20 > And what is last sector occupied by ? This is simlar situation to the most common problem with gmirror(8). When people decide to put their file system onto a mirror, it will eat partition's last sector, which isn't always safe. When disk is already partitioned and file systems are there, you cannot just take the last sector. > >I hope we don't play "convince phk@" game here. >=20 > In fact we do. I still very much consider myself in charge of > GEOM architecture, so anything that changes the GEOM api need to > pass the "convince phk" threshold. I think this won't touch GEOM infrastructure. Most likely disk(9) KPI will be extended. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WfZ7S8PLGjBY9Voh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEn8bhForvXbEpPzQRAoSSAKDxDEBcmQ7kGcXsYHZ37ugtEzM8MwCfRs7P yfi1YWsW/OAxomOwbdZU4eU= =BS/P -----END PGP SIGNATURE----- --WfZ7S8PLGjBY9Voh-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 12:22:01 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 29F1316A401 for ; Mon, 26 Jun 2006 12:22:01 +0000 (UTC) (envelope-from fb-arch@psconsult.nl) Received: from ps226.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 971EB43D4C for ; Mon, 26 Jun 2006 12:21:58 +0000 (GMT) (envelope-from fb-arch@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.13.1/8.13.1) with ESMTP id k5Q8cTpl030825 for ; Mon, 26 Jun 2006 10:38:29 +0200 (CEST) (envelope-from fb-arch@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.13.1/8.13.1/Submit) id k5Q8cTPa030824 for freebsd-arch@freebsd.org; Mon, 26 Jun 2006 10:38:29 +0200 (CEST) (envelope-from fb-arch@psconsult.nl) X-Authentication-Warning: phuket.psconsult.nl: paul set sender to fb-arch@psconsult.nl using -f Date: Mon, 26 Jun 2006 10:38:28 +0200 From: Paul Schenkeveld To: freebsd-arch@freebsd.org Message-ID: <20060626083828.GA18912@psconsult.nl> Mail-Followup-To: freebsd-arch@freebsd.org References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> <20060626080038.GA12511@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060626080038.GA12511@garage.freebsd.pl> User-Agent: Mutt/1.5.6i Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 12:22:01 -0000 On Mon, Jun 26, 2006 at 10:00:38AM +0200, Pawel Jakub Dawidek wrote: > I don't really care how we will make it visible for the user. This could > be devd(8) using some tool (diskinfo(8)?) to fetch serial number and > create a symlink to newly attached disk, but we need to have a general > mechanism inside the kernel for getting such informations. And make mounting /tmp, /var, /usr and so on depending on a running devd? Do we need /usr/bin/sed or /usr/bin/awk to mangle the output of diskinfo? I agree with Poul-Henning about the namespace pollution but I've been fighting the devicename shift when changing the hardware configuration so often that I also like the idea of something I could really rely on. Same issue with fxp0 and fxp1 on the motherboard becoming fxp1 and fxp2 when inserting another fxp card. Some things are just a bit too dynamic sometimes, but that's another discussion. I don't want to change the way the world is and certainly not violate POLA but just to add another angle to the discussion, life would be nice if we had something like: /dev/ad/0 /dev/ad/0/whole_disk /dev/ad/0/s1 /dev/ad/0/s1a /dev/ad/0/s1c and /dev/ad/ -> 0 $.02 Regards, Paul Schenkeveld From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 12:55:39 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 9D00316A401 for ; Mon, 26 Jun 2006 12:55:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 908D74491E for ; Mon, 26 Jun 2006 12:55:28 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DE3EE1703F; Mon, 26 Jun 2006 12:55:03 +0000 (UTC) To: Paul Schenkeveld From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 10:38:28 +0200." <20060626083828.GA18912@psconsult.nl> Date: Mon, 26 Jun 2006 12:55:00 +0000 Message-ID: <46620.1151326500@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 12:55:39 -0000 In message <20060626083828.GA18912@psconsult.nl>, Paul Schenkeveld writes: >I don't want to change the way the world is and certainly not violate POLA >but just to add another angle to the discussion, life would be nice if >we had something like: > > /dev/ad/0 > /dev/ad/0/whole_disk > /dev/ad/0/s1 > /dev/ad/0/s1a > /dev/ad/0/s1c > >and > > /dev/ad/ -> 0 This would take a bit of work to implement, currently we do not support adding DEVFS symlinks in the kernel that point to directory. Also, from experience, a lot of weird software needs to learn about all the '/' you insert in disknames. As far as I know, for ATA the problem is solved with ATA_STATIC_ID, and IMO it is solved better that way. This then begs the question if we should instead introduce a generic DISK_STATIC_ID which all controllers respect ? For CAM disks I guess this would mean encoding all of (bus,id,lun) in the device name: /dev/da0:0:1 or some such. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 12:56:42 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 7F47916A401; Mon, 26 Jun 2006 12:56:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A4614491E; Mon, 26 Jun 2006 12:56:29 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 45544170C5; Mon, 26 Jun 2006 12:56:13 +0000 (UTC) To: Dmitry Pryanishnikov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 15:50:46 +0300." <20060626154144.D47547@atlantis.atlantis.dp.ua> Date: Mon, 26 Jun 2006 12:56:10 +0000 Message-ID: <46654.1151326570@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 12:56:42 -0000 In message <20060626154144.D47547@atlantis.atlantis.dp.ua>, Dmitry Pryanishniko v writes: > I'm repeating my recent post to -current, just for the record... Actually, >there IS the way to tell whether the last sector is in use on UFS, and >reserve it from futher use by FS. It's badsect(8). Just declare the last >sector as bad, [...] The problem with this approach is that if the user does a newfs and restore, the information is not preserved. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 13:05:59 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 35B2016A401; Mon, 26 Jun 2006 13:05:59 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 813FD44939; Mon, 26 Jun 2006 13:05:58 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k5QD5tfj002514; Mon, 26 Jun 2006 16:05:55 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 26 Jun 2006 16:05:55 +0300 (EEST) From: Dmitry Pryanishnikov To: Poul-Henning Kamp In-Reply-To: <46654.1151326570@critter.freebsd.dk> Message-ID: <20060626160403.X47547@atlantis.atlantis.dp.ua> References: <46654.1151326570@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John-Mark Gurney , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 13:05:59 -0000 On Mon, 26 Jun 2006, Poul-Henning Kamp wrote: >> I'm repeating my recent post to -current, just for the record... Actually, >> there IS the way to tell whether the last sector is in use on UFS, and >> reserve it from futher use by FS. It's badsect(8). Just declare the last >> sector as bad, [...] > > The problem with this approach is that if the user does a newfs and restore, > the information is not preserved. The last sector must be re-marked as BAD after newfs and before restore, just like actual BAD sector. I don't say that keeping the last sector out of use is simple, but it's definitely possible (again, with UFS). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 13:11:30 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 6A06D16A47C; Mon, 26 Jun 2006 13:11:30 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29B5D447DC; Mon, 26 Jun 2006 12:51:11 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k5QCok8l089008; Mon, 26 Jun 2006 15:50:46 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 26 Jun 2006 15:50:46 +0300 (EEST) From: Dmitry Pryanishnikov To: Pawel Jakub Dawidek In-Reply-To: <20060626113705.GC12511@garage.freebsd.pl> Message-ID: <20060626154144.D47547@atlantis.atlantis.dp.ua> References: <20060626095250.GB12511@garage.freebsd.pl> <46189.1151320862@critter.freebsd.dk> <20060626113705.GC12511@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 13:11:30 -0000 Hello! On Mon, 26 Jun 2006, Pawel Jakub Dawidek wrote: >>>> When is it not acceptable ? >>> >>> When last sector is already occupied. >> >> And what is last sector occupied by ? > > This is simlar situation to the most common problem with gmirror(8). > When people decide to put their file system onto a mirror, it will eat > partition's last sector, which isn't always safe. > When disk is already partitioned and file systems are there, you cannot > just take the last sector. I'm repeating my recent post to -current, just for the record... Actually, there IS the way to tell whether the last sector is in use on UFS, and reserve it from futher use by FS. It's badsect(8). Just declare the last sector as bad, and then (if badsect has succeeded == sector isn't in FS's critical area) fsck will tell you whether this sector is free or is it used by another file. In the last case, fsck will tell you what file uses this sector (== multiple allocation in this file and in the just created BAD/xxx file) so you can just copy it's contents to another place and then remove it while keeping BAD/xxx. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 13:15:25 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 9096716A417; Mon, 26 Jun 2006 13:15:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A26344268; Mon, 26 Jun 2006 12:43:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 9A2D31703F; Mon, 26 Jun 2006 12:43:48 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 13:37:05 +0200." <20060626113705.GC12511@garage.freebsd.pl> Date: Mon, 26 Jun 2006 12:43:45 +0000 Message-ID: <46568.1151325825@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 13:15:25 -0000 In message <20060626113705.GC12511@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >> And what is last sector occupied by ? > >This is simlar situation to the most common problem with gmirror(8). >When people decide to put their file system onto a mirror, it will eat >partition's last sector, which isn't always safe. >When disk is already partitioned and file systems are there, you cannot >just take the last sector. Of course you can not just take the last sector, nor any other sector for that matter. If you look at how everybody else (Veritas etc) does this, they reduce the size of the filesystem by the number of sectors they steal. If they can't adjust the filesystem size (either because the sector is occupied or because they don't recognize the filesystem) they refuse, leaving it up to the system administrator to solve the problem. In this context I see your serial number proposal as a very poor substitute for a sensible solution because: 1. It doubles the size of the GEOM mesh by creating an alias for all disk devices at the bottom of the mesh. 2. It doesn't provide a solution for gmirror or any other class. 3. It adds a whole slew of issues with respect converting freeform serial numbers pathnames (What about serial numbers with hebrew letters in them ?) 4. It prevents cold-state swapout of disk drives. 5. Not all diskdrives can be supported, some don't have serial numbers you can read (USB-sticks seems particular bad). And let me just conclude by saying that I fully appreciate what you are trying to do, and I would very much like to see the problem solved in a reliable and usable manner, but as always, I am firmly against quick paste-over-the-problem solutions. The right solution seems to be to work on grow(ufs)fs so that it can reliably steal the last sector from a filesystem. Finally, I am not against giving meaningful access to VPD[1] for disks, but I think we should have a unified subsystem for that, as all sorts of other hardware also have VPD data that would be relevant. Poul-Henning [1] VPD = "Vital Product Data" = serial numbers, model numbers, ECO levels, firmware versions etc. Rumours has it that an internal survey by IBM many years ago showed that almost a third of all shutdowns performed by their technicians were to verify information written on the circuitboards with fiber pens. The resulting ability to read it electronically was called "Vital" because Field Engineers did not have to shut down your system to read it. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 13:20:51 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 D0AC416A514 for ; Mon, 26 Jun 2006 13:20:51 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 183CB43D67 for ; Mon, 26 Jun 2006 13:20:40 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5QDKVAW083094; Mon, 26 Jun 2006 09:20:32 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 26 Jun 2006 08:44:07 -0400 User-Agent: KMail/1.9.1 References: <20060625011746.GC81052@duncan.reilly.home> <20060625214021.GJ82074@funkthat.com> <20060626040754.GA30475@duncan.reilly.home> In-Reply-To: <20060626040754.GA30475@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606260844.07341.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 26 Jun 2006 09:20:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1563/Mon Jun 26 05:00:08 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-104.4 required=4.2 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 13:20:51 -0000 On Monday 26 June 2006 00:07, Andrew Reilly wrote: > On Sun, Jun 25, 2006 at 02:40:21PM -0700, John-Mark Gurney wrote: > > Andrew Reilly wrote this message on Sun, Jun 25, 2006 at 11:17 +1000: > > > One interesting problem that I found yesterday was that NetBSD > > > have added a "-l" option to cat, which is supposed to apply an > > > exclusive advisory lock with fcntl to the the output file, and > > > wait until that succeeds: > > > http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current > > > That seems like a pretty useful idea, > > > because it means that you can have parallel make jobs all > > > contributing to a log file or the like (with cat -l >> foo.log), > > > without getting in eachothers' way. > > > > Why not use: > > lockf -k foo.log cat >> foo.log > > > > Should do the same thing... > > Not only should it, I've just checked and discovered that it > does. So I'll make up the appropriate tweak to NetBSD's > Makefiles, and suggest on the mailing lists that they think > about incorporating it, as it's ostensibly a more general and > useful way to do it. > > This does make me wonder, though, why this _does_ work, given > Bruce's explanation of why the nbcat code doesn't... > > Hmm. lockf.c uses open(...,|O_EXLOCK), rather than fcntl(). > Any particular reason why that should behave differently? I believe that's an 'flock()' rather than an 'fnctl()' range lock. Are you doing your build over NFS btw? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 15:36:03 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 43EA216A403; Mon, 26 Jun 2006 15:36:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7201F454A5; Mon, 26 Jun 2006 15:35:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5QFWdF8000372; Mon, 26 Jun 2006 09:32:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jun 2006 09:32:40 -0600 (MDT) Message-Id: <20060626.093240.-432837692.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <33398.1151304697@critter.freebsd.dk> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 15:36:03 -0000 In message: <33398.1151304697@critter.freebsd.dk> "Poul-Henning Kamp" writes: : I suspect that the proponents of this scheme will object to my proposal : because they can not do a "ls /dev/mumble/*" to get a list of disk : serial numbers, and if so, that dooms the proposal: If the only objective : is to get a list of serial numbers, then this is not how it should be : done, instead we should add a real VPD registry to the kernel. I'm curious... what's wrong with adding additional things to the /dev directory? One of the biggest annoyances I have in troubleshooting is not being able to see what files are there and having magic file names that one can open but not list. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 15:36:17 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 B81A516A407; Mon, 26 Jun 2006 15:36:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B9C945434; Mon, 26 Jun 2006 15:36:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5QFYNhZ000449; Mon, 26 Jun 2006 09:34:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Jun 2006 09:34:25 -0600 (MDT) Message-Id: <20060626.093425.1649769642.imp@bsdimp.com> To: pjd@freebsd.org From: "M. Warner Losh" In-Reply-To: <20060626080038.GA12511@garage.freebsd.pl> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> <20060626080038.GA12511@garage.freebsd.pl> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: phk@phk.freebsd.dk, gurney_j@resnet.uoregon.edu, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 15:36:17 -0000 In message: <20060626080038.GA12511@garage.freebsd.pl> Pawel Jakub Dawidek writes: : > I'm against until somebody have explained what the use is, and if : > use is proven, it should be done with devfs device-on-demand(/cloning) : > instead of g_label. : : I don't really care how we will make it visible for the user. This could : be devd(8) using some tool (diskinfo(8)?) to fetch serial number and : create a symlink to newly attached disk, but we need to have a general : mechanism inside the kernel for getting such informations. devd could do this. We'd need to bring in Robert's geom publishes to devctl patches, but that is doable. The only snag, alas, is that this won't be available very early in the boot process... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 16:49:16 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 C6F3F16A4B3; Mon, 26 Jun 2006 16:49:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC3A4555E; Mon, 26 Jun 2006 15:55:33 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 48FF4170C5; Mon, 26 Jun 2006 15:55:25 +0000 (UTC) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 09:32:40 CST." <20060626.093240.-432837692.imp@bsdimp.com> Date: Mon, 26 Jun 2006 15:55:22 +0000 Message-ID: <52322.1151337322@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 16:49:17 -0000 In message <20060626.093240.-432837692.imp@bsdimp.com>, "M. Warner Losh" writes : >: I suspect that the proponents of this scheme will object to my proposal >: because they can not do a "ls /dev/mumble/*" to get a list of disk >: serial numbers[...] > >I'm curious... what's wrong with adding additional things to the /dev >directory? One of the biggest annoyances I have in troubleshooting is >not being able to see what files are there and having magic file names >that one can open but not list. devfs is not a hardware inventory facility, it is magic place for performing a rendez-vous with a device driver. We really do not want to prepopulate /dev with all possible devices, that model broke down in the late 1980ies and it has not become more feasible in the meantime. The reason people have trouble understanding this very basic point is that UCB strayed from the UNIX philosophy when they added all the socket system calls instead of adding the /net filesystem. If we had /net, everybody would be able to see that non-storage filesystems should not be prepopulated with every conceiveable vnode. The automounter is another good example: here quite complex software was written specifically to avoid prepopulation with all conceiveable vnodes and mountpoints, that that is even for storage filesystems. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 17:39:14 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 4218316AB82 for ; Mon, 26 Jun 2006 17:39:14 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06C1E44A1E for ; Mon, 26 Jun 2006 17:13:28 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4B3EC51388; Mon, 26 Jun 2006 19:13:27 +0200 (CEST) Received: from localhost (dku220.neoplus.adsl.tpnet.pl [83.24.24.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 98DC151307; Mon, 26 Jun 2006 19:13:21 +0200 (CEST) Date: Mon, 26 Jun 2006 19:10:35 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060626171035.GE12511@garage.freebsd.pl> References: <20060626113705.GC12511@garage.freebsd.pl> <46568.1151325825@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lteA1dqeVaWQ9QQl" Content-Disposition: inline In-Reply-To: <46568.1151325825@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 17:39:14 -0000 --lteA1dqeVaWQ9QQl Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2006 at 12:43:45PM +0000, Poul-Henning Kamp wrote: > In message <20060626113705.GC12511@garage.freebsd.pl>, Pawel Jakub Dawide= k writ > es: >=20 > >> And what is last sector occupied by ? > > > >This is simlar situation to the most common problem with gmirror(8). > >When people decide to put their file system onto a mirror, it will eat > >partition's last sector, which isn't always safe. > >When disk is already partitioned and file systems are there, you cannot > >just take the last sector. >=20 > Of course you can not just take the last sector, nor any other sector > for that matter. >=20 > If you look at how everybody else (Veritas etc) does this, they reduce > the size of the filesystem by the number of sectors they steal. File systems are not the whole world. MBR or BSDlabel or GPT can store provider's size in the metadata, so when ad0, ad0s1 and ad0s1 starts at the same physical offset, it knows which one to choose. Belive me or not it is a real PITA. > If they can't adjust the filesystem size (either because the sector > is occupied or because they don't recognize the filesystem) they > refuse, leaving it up to the system administrator to solve the problem. Then, administrator has to dump all data to some external storage, repartition the disks, create file systems from the begining and restore the data. Very user-friendly. > In this context I see your serial number proposal as a very poor > substitute for a sensible solution because: >=20 > 1. It doubles the size of the GEOM mesh by creating an alias > for all disk devices at the bottom of the mesh. Is that a problem? Are there any limitations in GEOM? And remember, glabel is optional. > 2. It doesn't provide a solution for gmirror or any other class. Who said it will? I just mentioned where I found stealing last sector a hard task. That's all. I never said that accessing disks via their serial numbers will help. And actually it will help to solve different problem. Sometimes you need to hardcode provider's name into gmirror's (or whatever) metadata ('c' partition is one of the reasons), which asks for troubles, because disk name /dev/ can change when you add/remove another disk. This will leave you without your mirror device. Storing serial number there will definitely help here. > 3. It adds a whole slew of issues with respect converting freeform > serial numbers pathnames (What about serial numbers with hebrew > letters in them ?) Heh... It doesn't seem to be a problem for UFS/NTFS/ReiserFS/Ext2FS/MSDOSFS labels. > 4. It prevents cold-state swapout of disk drives. Why? > 5. Not all diskdrives can be supported, some don't have serial=20 > numbers you can read (USB-sticks seems particular bad). Sure. And this is the reason we can't do it for those who have? > The right solution seems to be to work on grow(ufs)fs so that it > can reliably steal the last sector from a filesystem. Are you going to implement it? That's not an argument, Poul-Henning. Quite everything can be refused using "the ideal solution will be..." argument. > Finally, I am not against giving meaningful access to VPD[1] for disks, > but I think we should have a unified subsystem for that, as all sorts > of other hardware also have VPD data that would be relevant. Again. Let's say I've time to work on such functionality for disks only. So if you don't want to work on more general solution, you should not use it as an argument against less general one, leaving no alternatives. This is your standard argument, Poul-Henning. Please try harder and be constructive. Let me provide few examples. Should we backout GEOM, because it doesn't support mediasize changing, inserting provider between two existing ones and because classes unloading is broken from the very begining? Should we remove devfs, because it is not stable? Should we remove jails, because there is no resourse limits support, no multiple IPs support nor IPv6 support? No, because it is better than what we had before and noone came with a better solution. I'm not saying we should accepts all hacks proposed, but I'm not trying to design a hack here. This is why I brought this to arch@. I've a hackish extension for glabel(8), which dives into ATA internal structures to get disks serial number, but this is not what I'd like to see in our CVS. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --lteA1dqeVaWQ9QQl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEoBULForvXbEpPzQRAhhyAJ9Q0xv7NxLe2cH+jVsRii+Lm4Ds3wCg0E5g hPpGh9YRxaI7GFe+VWCYBv0= =MWBW -----END PGP SIGNATURE----- --lteA1dqeVaWQ9QQl-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 19:40:38 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 2B4CB16A540; Mon, 26 Jun 2006 19:40:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7005A441B1; Mon, 26 Jun 2006 18:46:25 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 094471703F; Mon, 26 Jun 2006 18:46:22 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 19:10:35 +0200." <20060626171035.GE12511@garage.freebsd.pl> Date: Mon, 26 Jun 2006 18:46:19 +0000 Message-ID: <56651.1151347579@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 19:40:38 -0000 In message <20060626171035.GE12511@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >> If you look at how everybody else (Veritas etc) does this, they reduce >> the size of the filesystem by the number of sectors they steal. > >File systems are not the whole world. MBR or BSDlabel or GPT can store >provider's size in the metadata, so when ad0, ad0s1 and ad0s1 starts at >the same physical offset, it knows which one to choose. Belive me or not >it is a real PITA. I will readily admit that we are suffering from legacy mistakes in this area, both the in-band BSD label and the "Dangerously Dedicated" mode were grave mistakes. They probably looked like good ideas at the time, but they weren't. (Think very carefully about the lesson here before you introduce new shortcuts). Other products I've worked with know how to modify the labels as necessary. The Veritas procedure to mirror the root is one of the most scary scripts I've ever run, but it worked perfectly every time, or gave up doing no damage. Yes, writing code like that is hard, takes time, takes lots of testing, but that is what it takes to deliver a quality product. >> If they can't adjust the filesystem size (either because the sector >> is occupied or because they don't recognize the filesystem) they >> refuse, leaving it up to the system administrator to solve the problem. > >Then, administrator has to dump all data to some external storage, >repartition the disks, create file systems from the begining and restore >the data. Very user-friendly. In my experience it only happens when the filesystem type is not recognized, and at least for Veritas, using the '-f(orce)' option made it proceeed. >> In this context I see your serial number proposal as a very poor >> substitute for a sensible solution because: >> >> 1. It doubles the size of the GEOM mesh by creating an alias >> for all disk devices at the bottom of the mesh. > >Is that a problem? Are there any limitations in GEOM? >And remember, glabel is optional. Yes, that is a problem, not because of the size in absolute numbers, but because they all refer to the same underlying devices. Imagine the rush during open/close/taste time. >> 2. It doesn't provide a solution for gmirror or any other class. > >Who said it will? I did. Solving the harder problem adequately would also give you solution for g_mirror, whereas just doing the quick&dirty hack would give us bugwards compatibility issues for the next N years, even if somebody more inclined to solve problems right subsequently does the right thing. >> 3. It adds a whole slew of issues with respect converting freeform >> serial numbers pathnames (What about serial numbers with hebrew >> letters in them ?) > >Heh... It doesn't seem to be a problem for >UFS/NTFS/ReiserFS/Ext2FS/MSDOSFS labels. Wanna bet ? Does g_label even bother to reject label names which contains '/' ? >> 4. It prevents cold-state swapout of disk drives. > >Why? Because /etc/fstab contains the serial number of the disk you just junked and the new one has a different serial number. >> 5. Not all diskdrives can be supported, some don't have serial >> numbers you can read (USB-sticks seems particular bad). > >Sure. And this is the reason we can't do it for those who have? Yes, I rather think so. >> The right solution seems to be to work on grow(ufs)fs so that it >> can reliably steal the last sector from a filesystem. > >Are you going to implement it? That's not an argument, Poul-Henning. >Quite everything can be refused using "the ideal solution will be..." >argument. No I will not. I do suspect however, that after a lot of pointless discussions, you will end up implementing it this way, because I am surely going to put as many roadblocks in front of your hackish scheme as I can. >> Finally, I am not against giving meaningful access to VPD[1] for disks, >> but I think we should have a unified subsystem for that, as all sorts >> of other hardware also have VPD data that would be relevant. > >Again. Let's say I've time to work on such functionality for disks only. Then you should not even begin to touch it. If you can't do it in an architecturally sensible fashion, we are better of if you don't do it. >Please try harder and be constructive. I am trying very hard to be constructive here, but you are so defensive of your own half-baked scheme that you are not even considering the proposals I make. >Let me provide few examples. Should we backout GEOM, because it doesn't >support mediasize changing, [...] There is a big difference between something which is architecturally sound but incomplete and something which is an architectural mess. We don't back out the former, we complete them, and hopefully everybody had learned by now to not even commit the latter in the first place. Let me give you two relevant examples to think about: 1. A new journaled filesystem which initially does not support subdirectories, FIFOs and symlinks. 2. A hare-brained hack to add journaling to an existing mission critical (for FreeBSD) filesystem by means of layering violations and quick hacks. Yes, we commit the former, hoping it will grow to completion. No, we don't commit the latter because it will be a maintenance nightmare from day 1. >I'm not saying we should accepts all hacks proposed, but I'm not trying >to design a hack here. I beg to differ: You are. >This is why I brought this to arch@. You only brought it to arch@ because I asked you to, and the reason I asked you to, was to get this discussion into the archives where it belongs. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 19:48:43 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 4194816A402 for ; Mon, 26 Jun 2006 19:48:43 +0000 (UTC) (envelope-from fb-arch@psconsult.nl) Received: from ps226.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F2E143D92 for ; Mon, 26 Jun 2006 19:48:41 +0000 (GMT) (envelope-from fb-arch@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.13.1/8.13.1) with ESMTP id k5QJl7QW045693 for ; Mon, 26 Jun 2006 21:47:07 +0200 (CEST) (envelope-from fb-arch@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.13.1/8.13.1/Submit) id k5QJl7wZ045692 for freebsd-arch@freebsd.org; Mon, 26 Jun 2006 21:47:07 +0200 (CEST) (envelope-from fb-arch@psconsult.nl) X-Authentication-Warning: phuket.psconsult.nl: paul set sender to fb-arch@psconsult.nl using -f Date: Mon, 26 Jun 2006 21:47:07 +0200 From: Paul Schenkeveld To: freebsd-arch@freebsd.org Message-ID: <20060626194707.GA44234@psconsult.nl> Mail-Followup-To: freebsd-arch@freebsd.org References: <20060626083828.GA18912@psconsult.nl> <46620.1151326500@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46620.1151326500@critter.freebsd.dk> User-Agent: Mutt/1.5.6i Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 19:48:43 -0000 On Mon, Jun 26, 2006 at 12:55:00PM +0000, Poul-Henning Kamp wrote: > In message <20060626083828.GA18912@psconsult.nl>, Paul Schenkeveld writes: > > >I don't want to change the way the world is and certainly not violate POLA > >but just to add another angle to the discussion, life would be nice if > >we had something like: > > > > /dev/ad/0 > > /dev/ad/0/whole_disk > > /dev/ad/0/s1 > > /dev/ad/0/s1a > > /dev/ad/0/s1c > > > >and > > > > /dev/ad/ -> 0 > > This would take a bit of work to implement, currently we do not support > adding DEVFS symlinks in the kernel that point to directory. > > Also, from experience, a lot of weird software needs to learn about > all the '/' you insert in disknames. These arguments are the reason I started out to state that I don't want to "change the way the world is and certainly not violate POLA" but the issue is one I have been thinking about for many years. The way we identify multiple instances of the same type of device in UN*X like systems will always have drawbacks, whichever scheme we choose. Currently, with multiple controllers using the same driver there is always the randomness of which gets detected first by the kernel. If, for example, you have two SCSI controllers, an AHA2940 and an AHA29160, then have to replace one by a newer model which uses the same driver, the numbering may reverse or replacing the first one by a controller which uses a different driver shifts the number of the second controller down by 1. Back in the old days the AT&T 3B had a nice bus with address space divided in ranges per slot so the system always knew in which slot a card was but adding an extra card sometimes meant you had to move an existing card if for example cables and connectors would otherwise become unreachable. Another interesting challenge is the miriad of devices that come and go over time like USB and firewire attached drives, flash cards that slip into the side of a notebook etc. Using a serial number on the device as the OP suggests works until you have to replace broken hardware. And some hardware may not have readable serial numbers at all like flash memory devices. With soft labels stored on a disk the sysadmin at least can control behaviour to some extent but there are certainly corner cases where labels are inconvenient. So having a choice between several different schemes is perhaps the best way to keep many sysadmins happy. > As far as I know, for ATA the problem is solved with ATA_STATIC_ID, > and IMO it is solved better that way. > > This then begs the question if we should instead introduce a generic > DISK_STATIC_ID which all controllers respect ? ATA_STATIC_ID certainly keeps frustration away in many cases and having all drivers behave the same way and change to DISK_STATIC_ID is probably even much better. > For CAM disks I guess this would mean encoding all of (bus,id,lun) > in the device name: > > /dev/da0:0:1 > > or some such. Like /dev/[r]dsk/c0b0t0d0l0s1a as in SysV ;-( Yes this could be handy in some situations where the sysadmin has everything to say about SCSI IDs and LUNs but as I said before, whichever way we choose will solve the problem for some and create a problem for others. Having a choice is good, especially if one can choose which scheme to use by including GEOMs in the kernel or loading them at boot time. The current default of ad*, da* and so on could (IMO should) stay and remain the default to not violate POLA. Two more cents of mine. Regards, Paul Schenkeveld From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 20:28:49 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 2592716A403 for ; Mon, 26 Jun 2006 20:28:49 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20FA043D66 for ; Mon, 26 Jun 2006 20:28:32 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3D3BB50EA7; Mon, 26 Jun 2006 22:28:30 +0200 (CEST) Received: from localhost (dku220.neoplus.adsl.tpnet.pl [83.24.24.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id BF4D851845; Mon, 26 Jun 2006 22:28:24 +0200 (CEST) Date: Mon, 26 Jun 2006 22:25:37 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060626202537.GF12511@garage.freebsd.pl> References: <20060626171035.GE12511@garage.freebsd.pl> <56651.1151347579@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oFbHfjnMgUMsrGjO" Content-Disposition: inline In-Reply-To: <56651.1151347579@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 20:28:49 -0000 --oFbHfjnMgUMsrGjO Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2006 at 06:46:19PM +0000, Poul-Henning Kamp wrote: > In message <20060626171035.GE12511@garage.freebsd.pl>, Pawel Jakub Dawide= k writ > >> 2. It doesn't provide a solution for gmirror or any other class. > > > >Who said it will? >=20 > I did. >=20 > Solving the harder problem adequately would also give you solution > for g_mirror, whereas just doing the quick&dirty hack would give > us bugwards compatibility issues for the next N years, even if > somebody more inclined to solve problems right subsequently does > the right thing. I've no idea how it is related to the subject beeing discussed here. Please read again. > >> 3. It adds a whole slew of issues with respect converting freeform > >> serial numbers pathnames (What about serial numbers with hebrew > >> letters in them ?) > > > >Heh... It doesn't seem to be a problem for > >UFS/NTFS/ReiserFS/Ext2FS/MSDOSFS labels. >=20 > Wanna bet ? >=20 > Does g_label even bother to reject label names which contains '/' ? No. I removed those checks, because users wanted to use such functionality. It was discussed on FreeBSD mailing lists. > >> 4. It prevents cold-state swapout of disk drives. > > > >Why? >=20 > Because /etc/fstab contains the serial number of the disk you just > junked and the new one has a different serial number. It doesn't prevent user from doing it. It is a tool, not policy. User should be aware of what he is doing, this is quite straight-forward. > >> The right solution seems to be to work on grow(ufs)fs so that it > >> can reliably steal the last sector from a filesystem. > > > >Are you going to implement it? That's not an argument, Poul-Henning. > >Quite everything can be refused using "the ideal solution will be..." > >argument. >=20 > No I will not. >=20 > I do suspect however, that after a lot of pointless discussions, > you will end up implementing it this way, because I am surely going > to put as many roadblocks in front of your hackish scheme as I can. Fortunately, FreeBSD is not OpenBSD and you are not Theo. Funny, I didn't gave any complete or even half-complete scheme to review. I just started discussion to design scheme, which will allow to fetch various attributes from the disks. And this is why I can't understand your point at all. What hacks are you talking about? > >> Finally, I am not against giving meaningful access to VPD[1] for disks, > >> but I think we should have a unified subsystem for that, as all sorts > >> of other hardware also have VPD data that would be relevant. > > > >Again. Let's say I've time to work on such functionality for disks only. >=20 > Then you should not even begin to touch it. And who is saying that... > >Let me provide few examples. Should we backout GEOM, because it doesn't > >support mediasize changing, [...] >=20 > There is a big difference between something which is architecturally > sound but incomplete and something which is an architectural mess. What exactly is a mess you are talking about? > We don't back out the former, we complete them, and hopefully > everybody had learned by now to not even commit the latter in the > first place. Who complete them? This what you keep forgetting. Maintaining the code is no less important. > Let me give you two relevant examples to think about: >=20 > 1. A new journaled filesystem which initially does not support > subdirectories, FIFOs and symlinks. >=20 > 2. A hare-brained hack to add journaling to an existing mission > critical (for FreeBSD) filesystem by means of layering > violations and quick hacks. >=20 > Yes, we commit the former, hoping it will grow to completion. >=20 > No, we don't commit the latter because it will be a maintenance > nightmare from day 1. I'm not going to discuss gjournal with you, because you simply won't take time to understand how it works. The only layering violation which exists there is because GEOM is not that flexible as it should be. But it will be removed. GJorunal has a maintainer. Simlar mechanism is implemented in Linux and works quite well there. > >I'm not saying we should accepts all hacks proposed, but I'm not trying > >to design a hack here. >=20 > I beg to differ: You are. >=20 > >This is why I brought this to arch@. >=20 > You only brought it to arch@ because I asked you to, [...] You suggested this, but the purpose was what I wrote. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --oFbHfjnMgUMsrGjO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEoELBForvXbEpPzQRAlq0AKDgTrKvwfaWuCzyHuBatWvDGL29TQCghJQ2 /rz5TkhJrB7kHJbnWoIyRhU= =iWks -----END PGP SIGNATURE----- --oFbHfjnMgUMsrGjO-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 21:03:34 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 2DD8116A404 for ; Mon, 26 Jun 2006 21:03:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1755F4456F for ; Mon, 26 Jun 2006 20:40:12 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 40895170C6; Mon, 26 Jun 2006 20:40:10 +0000 (UTC) To: Paul Schenkeveld From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 21:47:07 +0200." <20060626194707.GA44234@psconsult.nl> Date: Mon, 26 Jun 2006 20:40:07 +0000 Message-ID: <57613.1151354407@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 21:03:34 -0000 In message <20060626194707.GA44234@psconsult.nl>, Paul Schenkeveld writes: >Back in the old days the AT&T 3B [...] Yes, everything was better in the good old days, wasn't it ? :-) You could even order and eat a pizza while a 3B700 rebuilt its kernel, these days you can barely make a decent cup of tea :-) Anyway, seriously: I am not against change in this area, but I somewhat fear having a multiplicity of philosophies about it is going to help us. Justin@ renamed /dev/sd%d to /dev/da%d when he introduced CAM and sos@ renamed /dev/wd%d to /dev/ad%d with ATA, and both of them got so much grief for it that I didn't even mention to anybody that I had thought about going to /dev/disk%d for GEOM. Considering that all other contemporary filesystems is moving in the direction of on-media identification, I think that is the only sane direction for us to move as well. UFS labels takes us a long way in that direction. >So having a choice between several different schemes is perhaps the best >way to keep many sysadmins happy. ... and drive the documentation people insane. >Like /dev/[r]dsk/c0b0t0d0l0s1a as in SysV ;-( There were a certain level of madness to that method, and vice versa, so I wouldn't entirely object, provided we don't cause regression in too many personal traumas :-) >Having a choice is good, especially if one can choose which scheme to >use by including GEOMs in the kernel or loading them at boot time. If done in moderation: yes. >The >current default of ad*, da* and so on could (IMO should) stay and remain >the default to not violate POLA. Agreed. My main objection to what Pawel proposes is that it is not what anybody really want. Pawel sees it as a legitimate quick fix for 60% of the itch people want scratched, I want the percentage to be a fair bit higher than that. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 21:08:42 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 A00C916A4C9; Mon, 26 Jun 2006 21:08:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F92447F0; Mon, 26 Jun 2006 20:43:27 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id BF711170C5; Mon, 26 Jun 2006 20:43:25 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 26 Jun 2006 22:25:37 +0200." <20060626202537.GF12511@garage.freebsd.pl> Date: Mon, 26 Jun 2006 20:43:22 +0000 Message-ID: <57651.1151354602@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 21:08:42 -0000 This discussion is no longer productive. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 23:09:26 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 1063E16A49E for ; Mon, 26 Jun 2006 23:09:26 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta03sl.mx.bigpond.com (omta03sl.mx.bigpond.com [144.140.92.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id D717443D78 for ; Mon, 26 Jun 2006 23:09:24 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta03sl.mx.bigpond.com with ESMTP id <20060626230923.MLP1089.omta03sl.mx.bigpond.com@areilly.bpc-users.org> for ; Mon, 26 Jun 2006 23:09:23 +0000 Received: (qmail 31466 invoked by uid 501); 26 Jun 2006 23:09:27 -0000 Date: Tue, 27 Jun 2006 09:09:27 +1000 From: Andrew Reilly To: John Baldwin Message-ID: <20060626230927.GA92989@duncan.reilly.home> References: <20060625011746.GC81052@duncan.reilly.home> <20060625214021.GJ82074@funkthat.com> <20060626040754.GA30475@duncan.reilly.home> <200606260844.07341.john@baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606260844.07341.john@baldwin.cx> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 23:09:26 -0000 On Mon, Jun 26, 2006 at 08:44:07AM -0400, John Baldwin wrote: > Are you doing your build over NFS btw? Aah, yes. Sorry for the noise, in that case. I should have remembered that nfs locking was a bit iffy. I've been trying to build both locally and remotely but running into problems for various reasons, both ways. The "nbcat -l >> ${METALOG}" thing actually works fine on local file systems, it seems. Got myself confused, there. Thanks for the insight, all. Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 00:22:42 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 4E93016A53F for ; Tue, 27 Jun 2006 00:22:42 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta03sl.mx.bigpond.com (omta03sl.mx.bigpond.com [144.140.92.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB25144895 for ; Mon, 26 Jun 2006 23:58:42 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta03sl.mx.bigpond.com with ESMTP id <20060626235841.CSTR1089.omta03sl.mx.bigpond.com@areilly.bpc-users.org> for ; Mon, 26 Jun 2006 23:58:41 +0000 Received: (qmail 40335 invoked by uid 501); 26 Jun 2006 23:58:45 -0000 Date: Tue, 27 Jun 2006 09:58:45 +1000 From: Andrew Reilly To: Poul-Henning Kamp Message-ID: <20060626235845.GD92989@duncan.reilly.home> References: <20060626.093240.-432837692.imp@bsdimp.com> <52322.1151337322@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52322.1151337322@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: OT: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 00:22:42 -0000 On Mon, Jun 26, 2006 at 03:55:22PM +0000, Poul-Henning Kamp wrote: > The reason people have trouble understanding this very basic point is > that UCB strayed from the UNIX philosophy when they added all the socket > system calls instead of adding the /net filesystem. I don't know if anyone's interested, but I started to have a look at Minix-3 the other day. Andrew Tanenbaum is trying to make it grow into a real, useful embedded OS, so now it has a "TCP/IP" network stack (and fully scheduled user-mode device drivers...) The interesting thing is that the TCP/IP stack doesn't provide sockets. It provides /dev/rtk (etc) for raw ethernet drivers, and /dev/ip for raw IP and /dev/tcp for TCP sessions. You open /dev/tcp, do ioctl's to make a connection and then read()/write() to send and receive data. Totally off topic, but kind of interesting, too... Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 06:26:49 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 BE89F16A4AB for ; Tue, 27 Jun 2006 06:26:49 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 230E943D78 for ; Tue, 27 Jun 2006 06:26:47 +0000 (GMT) (envelope-from jiashiun@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1358291uge for ; Mon, 26 Jun 2006 23:26:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AH134/3S46vV5wVCZ2yOePa1N6sdhKWRrw03LUy5NznpcmFuyOyrD1BFR+jB2PfOekT06aRx2W7KqOd+bHSBeKskzihLDmzrovcPBYcfKWniJQUGE7zaJ0Vw+UHV3fQpHhvXz0LhrCJsobFGUDurktlx0dKasRNFO8jgEeFsb+w= Received: by 10.78.165.16 with SMTP id n16mr2387151hue; Mon, 26 Jun 2006 23:26:46 -0700 (PDT) Received: by 10.78.120.3 with HTTP; Mon, 26 Jun 2006 23:26:46 -0700 (PDT) Message-ID: <1d6d20bc0606262326p3fe063easd121e65b375a5def@mail.gmail.com> Date: Tue, 27 Jun 2006 14:26:46 +0800 From: "Jia-Shiun Li" To: freebsd-arch@freebsd.org In-Reply-To: <20060626194707.GA44234@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060626083828.GA18912@psconsult.nl> <46620.1151326500@critter.freebsd.dk> <20060626194707.GA44234@psconsult.nl> Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 06:26:49 -0000 On 6/27/06, Paul Schenkeveld wrote: > These arguments are the reason I started out to state that I don't want > to "change the way the world is and certainly not violate POLA" but > the issue is one I have been thinking about for many years. The way > we identify multiple instances of the same type of device in UN*X like > systems will always have drawbacks, whichever scheme we choose. > > Currently, with multiple controllers using the same driver there is > always the randomness of which gets detected first by the kernel. If, > for example, you have two SCSI controllers, an AHA2940 and an AHA29160, > then have to replace one by a newer model which uses the same driver, > the numbering may reverse or replacing the first one by a controller > which uses a different driver shifts the number of the second controller > down by 1. > > Back in the old days the AT&T 3B had a nice bus with address space > divided in ranges per slot so the system always knew in which slot a > card was but adding an extra card sometimes meant you had to move an > existing card if for example cables and connectors would otherwise > become unreachable. > > Another interesting challenge is the miriad of devices that come and go > over time like USB and firewire attached drives, flash cards that slip > into the side of a notebook etc. > > Using a serial number on the device as the OP suggests works until > you have to replace broken hardware. And some hardware may not have > readable serial numbers at all like flash memory devices. > > With soft labels stored on a disk the sysadmin at least can control > behaviour to some extent but there are certainly corner cases where > labels are inconvenient. > > So having a choice between several different schemes is perhaps the best > way to keep many sysadmins happy. > > > As far as I know, for ATA the problem is solved with ATA_STATIC_ID, > > and IMO it is solved better that way. > > > > This then begs the question if we should instead introduce a generic > > DISK_STATIC_ID which all controllers respect ? > > ATA_STATIC_ID certainly keeps frustration away in many cases and having > all drivers behave the same way and change to DISK_STATIC_ID is probably > even much better. > > > For CAM disks I guess this would mean encoding all of (bus,id,lun) > > in the device name: > > > > /dev/da0:0:1 > > > > or some such. > > Like /dev/[r]dsk/c0b0t0d0l0s1a as in SysV ;-( > > Yes this could be handy in some situations where the sysadmin has > everything to say about SCSI IDs and LUNs but as I said before, > whichever way we choose will solve the problem for some and create a > problem for others. > > Having a choice is good, especially if one can choose which scheme to > use by including GEOMs in the kernel or loading them at boot time. The > current default of ad*, da* and so on could (IMO should) stay and remain > the default to not violate POLA. > That's pretty what I think of too. Imagine situation like this that someone has two fxp adapter configured on system. Plugging another one will certainly cause some troubles as he now has problem identify which is fxp0, fxp1, or fxp2. Not all users know how the system probes and enumerate hardware, even if he knows, he still has trouble knowing how hardware are probed on 'his' system as motherboard layouts are different from one to another. Not to mention various versions of i8255[78901] under the same fxp name with different hardware capabilities. The same stands for storages adapters and worse because they have disks as children. Having everything work under the big device tree may be a good solution for unique addressing from programmers' point of view. But 'unique' also means sometimes you have to find out where it is. Serial numbers are unique to the users, and hierarchy names are unique to the system (and admin). There are differences. Take some other examples. If one pull out network adapter and plug it into another slot, in Windows he will get a new "Local Connection 5" and have to re-configure its IP setting. Fortunately the default DHCP works for me in most cases btw. That means Windows use adapter AND slot positions to uniquely identify a network connection for user. AFAIK Fedora uses similar scheme to identify hardwares and keep it in configuration files so kudzu will know when new hardware appears. I guess pjd initially wanted to solve problems like roaming USB disks or get rid of ATA_STATIC_ID. It would be better if you can describe the problems to solve in detail. Because of the nature we need to bind data to specific hardware, for example IP address, mounting points, or files on disks, it is good to have a solution to achieve it instead of depending on the may-change device numbers. Serial number is a good starting point, but it does not necessarily need to go into /dev as many people mentioned all the concerns. One possible solution: providing that uses can get serial number to device node mapping in user space, it could be easy to implement a mechanism, for example in shell scripts, for those who need it. Any comment? In my opinion I have to say, I do not feel it is a good idea to mix the concept of serial numbers and various device attributes with the device names or internal hierarchical representation. They can be coupled but it is probably too closely related if implemented in device tree. Jia-Shiun. From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 08:03:40 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 4009C16A406; Tue, 27 Jun 2006 08:03:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EDC43D48; Tue, 27 Jun 2006 08:03:15 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k5R83CQp010782 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Jun 2006 18:03:13 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k5R83CjG001046; Tue, 27 Jun 2006 18:03:12 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k5R83CHI001045; Tue, 27 Jun 2006 18:03:12 +1000 (EST) (envelope-from peter) Date: Tue, 27 Jun 2006 18:03:12 +1000 From: Peter Jeremy To: Pawel Jakub Dawidek Message-ID: <20060627080312.GB714@turion.vk2pj.dyndns.org> References: <20060626171035.GE12511@garage.freebsd.pl> <56651.1151347579@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <56651.1151347579@critter.freebsd.dk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 08:03:40 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2006-Jun-26 18:46:19 +0000, Poul-Henning Kamp wrote: >>> 4. It prevents cold-state swapout of disk drives. >> >>Why? > >Because /etc/fstab contains the serial number of the disk you just >junked and the new one has a different serial number. I've used a couple of OSs that derived their logical disk name (ie /dev/disk/dsk5) from the WWID by keeping a magic database to map the WWID to the name. None of them have good solutions to telling the OS that WWID-x has died and I want WWID-y to now map to the same logical device as WWID-x used to. Actually having the WWID (or similar) as the logical name would make handling a disk swap really nasty. Stating that the sysadmin knows about the change doesn't address the issue: The sysadmin changed the device because the old one failed. There may or may not have been advance notice of the replacement. --=20 Peter Jeremy --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEoOY+/opHv/APuIcRAtEEAJ4un7nyX2TVR9pB99uZMZHXmhvDUgCfShjI CyYrnJ3bYld4/OARNbeH8VA= =MfX6 -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 09:36:14 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 BAEF016A400 for ; Tue, 27 Jun 2006 09:36:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20FFA43D53 for ; Tue, 27 Jun 2006 09:36:06 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail03.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k5R9a35V001624 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Jun 2006 19:36:04 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k5R9a3Kl001407; Tue, 27 Jun 2006 19:36:03 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k5R9a2rD001406; Tue, 27 Jun 2006 19:36:02 +1000 (EST) (envelope-from peter) Date: Tue, 27 Jun 2006 19:36:02 +1000 From: Peter Jeremy To: Andrew Reilly Message-ID: <20060627093602.GF714@turion.vk2pj.dyndns.org> References: <20060626.093240.-432837692.imp@bsdimp.com> <52322.1151337322@critter.freebsd.dk> <20060626235845.GD92989@duncan.reilly.home> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gdTfX7fkYsEEjebm" Content-Disposition: inline In-Reply-To: <20060626235845.GD92989@duncan.reilly.home> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-arch@freebsd.org Subject: Re: OT: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 09:36:14 -0000 --gdTfX7fkYsEEjebm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Jun-27 09:58:45 +1000, Andrew Reilly wrote: >I don't know if anyone's interested, but I started to have a >look at Minix-3 the other day. ... > You open /dev/tcp, do ioctl's to make a connection >and then read()/write() to send and receive data. That sounds similar to the SysV approach - you open a device and push a collection of streams modules. I'm not sure that ioctl() is any better than bind/connect etc - a process still needs special code if it's to be network-aware. IMHO, the portal filesystem provides a far more interesting approach. --=20 Peter Jeremy --gdTfX7fkYsEEjebm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEoPwB/opHv/APuIcRAgP+AKC3NvAjA3LXsU19AfQoD1kPM4T7UACeN9x9 QVP9Aebo76Fz6h61ro6RtMU= =LN9l -----END PGP SIGNATURE----- --gdTfX7fkYsEEjebm-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 11:24:09 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 2941116A409 for ; Tue, 27 Jun 2006 11:24:09 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE1D243D6A for ; Tue, 27 Jun 2006 11:24:05 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C6FCF51391; Tue, 27 Jun 2006 13:24:03 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6A6AD5131F; Tue, 27 Jun 2006 13:23:54 +0200 (CEST) Date: Tue, 27 Jun 2006 13:21:05 +0200 From: Pawel Jakub Dawidek To: Peter Jeremy Message-ID: <20060627112105.GC21661@garage.freebsd.pl> References: <20060626171035.GE12511@garage.freebsd.pl> <56651.1151347579@critter.freebsd.dk> <20060627080312.GB714@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <20060627080312.GB714@turion.vk2pj.dyndns.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:24:09 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2006 at 06:03:12PM +1000, Peter Jeremy wrote: > On Mon, 2006-Jun-26 18:46:19 +0000, Poul-Henning Kamp wrote: > >>> 4. It prevents cold-state swapout of disk drives. > >> > >>Why? > > > >Because /etc/fstab contains the serial number of the disk you just > >junked and the new one has a different serial number. >=20 > I've used a couple of OSs that derived their logical disk name (ie > /dev/disk/dsk5) from the WWID by keeping a magic database to map > the WWID to the name. None of them have good solutions to telling > the OS that WWID-x has died and I want WWID-y to now map to the same > logical device as WWID-x used to. >=20 > Actually having the WWID (or similar) as the logical name would make > handling a disk swap really nasty. >=20 > Stating that the sysadmin knows about the change doesn't address the > issue: The sysadmin changed the device because the old one failed. > There may or may not have been advance notice of the replacement. I'm not saying it solves all problems, but it is very useful in certain situations, where what you mentioned is not the case. For software RAID you still has to somehow say that this driver replaced that one. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD4DBQFEoRShForvXbEpPzQRAqzmAJjmsV9aZHIvTAiPIWJ/PfSn/JCUAKD0Oz9Y MHVqWYZ3kaDBoMIa4bVOyg== =AwGy -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 11:35:05 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 1463316A403; Tue, 27 Jun 2006 11:35:05 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9307C43D53; Tue, 27 Jun 2006 11:34:54 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms073.mailsrvcs.net ([192.168.1.2]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J1I00M4HO62W2F4@vms040.mailsrvcs.net>; Tue, 27 Jun 2006 06:34:50 -0500 (CDT) Date: Tue, 27 Jun 2006 06:34:50 -0500 (CDT) From: Sergey Babkin To: Peter Jeremy , Pawel Jakub Dawidek Message-id: <9415836.2290041151408090117.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 11:35:05 -0000 >From: Peter Jeremy >On Mon, 2006-Jun-26 18:46:19 +0000, Poul-Henning Kamp wrote: >>>> 4. It prevents cold-state swapout of disk drives. >>> >>>Why? >> >>Because /etc/fstab contains the serial number of the disk you just >>junked and the new one has a different serial number. > >I've used a couple of OSs that derived their logical disk name (ie >/dev/disk/dsk5) from the WWID by keeping a magic database to map >the WWID to the name. None of them have good solutions to telling >the OS that WWID-x has died and I want WWID-y to now map to the same >logical device as WWID-x used to. I can tell about my experience with this kind of thing in UnixWare. AFAIK the primary motivation for tracking the disks by serial numbers was the Multi-Path I/O: having the same disk accessible through two controllers, so that if one access path fails, the OS can switch transparently to another path. (Well, in reality such a disk would probably be not just a disk but a logical volume in a RAID box with 2 redundant controllers in it, each connected to the host through a separate SCSI of FibreChannel bus). To do this you need ways to discover that both paths lead to the same disk. UnixWare does this by writing a randomly generated unique ID into the UnixWare partition. When the disks are enumerated, the partition (VTOC) code reads this ID and checks it against the database of known IDs in the resource manager. When a match is found, the disk gets connected to an existing logical name. As the resource manager database gets saved between reboots, this also gives you the persistence of disk names between reboots. As a good side effect it allowed to move disks around in every which way between the slots and connections while keeping the same logical name. As a bad side effect, you would never know what some logical name refers to until you check the mapping table. Worse yet, since the logical names have been kept of the same format as the physical names (cNbNtNdN), if you happen to have a disk in c1b1t1d1 and then move it to another slot, it keeps the name, and when you put another disk into the original slot, you don't see it at all (I think, unless I forget something) until you reset the mappings or unplug the original disk - then the name magically transfers to the new disk. And since the mappings persist, they tend to accumulate if you swap the disks often. It's not really an issue with the concept itself, its' just tha the logical names should have a different format than the physical ones to avoid confusion. The mapping-controlling tools are kind of poor too but again this is solely the issue with the tools, not with the concept. If you are creative with direct manipulation of the resource manager entries, you can do many things that the tools won't allow you. The resource manager manipulation tools are kind of poor in UnixWare too but again it's not an issue with the concept itself. >Actually having the WWID (or similar) as the logical name would make >handling a disk swap really nasty. That's not a problem in UnixWare. If the original disk has gone away completely, the new disk in the same SCSI slot would just get the same logical name. Things get more interesting for USB: to do the Right Thing sometimes it would be neccessary to attach the same name to any device (of the same type) in the same slot, and sometimes to the same device in any slot. >Stating that the sysadmin knows about the change doesn't address the >issue: The sysadmin changed the device because the old one failed. >There may or may not have been advance notice of the replacement. There should just be a way for sysadmin to communicate this knowledge to the system. For an UnixWare example again, it has a command saying "I'm about to hot swap this disk, do whatever is neccessary to stop the old disk, and then start and recognize the new one". Of course, in any seriour datacenter the swap would happen inside a RAID box and the OS won't see it at all. -SB From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 16:35:54 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 7ADB016A403; Tue, 27 Jun 2006 16:35:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA30D43D8D; Tue, 27 Jun 2006 16:35:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5RGXgpk022930; Tue, 27 Jun 2006 10:33:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jun 2006 10:33:43 -0600 (MDT) Message-Id: <20060627.103343.-432837786.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <52322.1151337322@critter.freebsd.dk> References: <20060626.093240.-432837692.imp@bsdimp.com> <52322.1151337322@critter.freebsd.dk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gurney_j@resnet.uoregon.edu, pjd@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:35:54 -0000 In message: <52322.1151337322@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20060626.093240.-432837692.imp@bsdimp.com>, "M. Warner Losh" writes : : : : >: I suspect that the proponents of this scheme will object to my proposal : >: because they can not do a "ls /dev/mumble/*" to get a list of disk : >: serial numbers[...] : > : >I'm curious... what's wrong with adding additional things to the /dev : >directory? One of the biggest annoyances I have in troubleshooting is : >not being able to see what files are there and having magic file names : >that one can open but not list. : : devfs is not a hardware inventory facility, it is magic place for : performing a rendez-vous with a device driver. True, but somewhat irrelvant. This does not go to the question that I asked. What problems does having fully enumerated devices cause? devfs does allow directory listings, therefore absent some compelling reason to the contrary these listings should be complete. This is an enumeration of the available devices, which closely mirrors the available hardware. There are other facilities for finding out the underlying hardware, but there's no way to find the magic names in /dev easily. While it is a magic place, that magic place exists in the context of a file system, and file systems aren't supposed to randomly open files. It is also a security concern. If I wanted to have non-default permissions on these magic nodes, at the very least I'd have no way to audit them. I'm unclear if doing the normal unix operations on the magic nodes would suffice. : We really do not want to prepopulate /dev with all possible devices, : that model broke down in the late 1980ies and it has not become more : feasible in the meantime. You are arguing apples and oranges here. The fully enumerated /dev with all possible device entries based on what the machine might possibly have is not what I'm asking. We all know there are issues with that. My question is more specific. What is wrong with having entries in devfs of files you can actually open, when we know the universe that is possible given the current knowledge of the kernel? Why have some of them hidden and some of them present? Why subject the user to the hassles that having hidden, magic files causes? : The reason people have trouble understanding this very basic point is : that UCB strayed from the UNIX philosophy when they added all the socket : system calls instead of adding the /net filesystem. Again, you are comparing apples to oranges. The current local node cannot know the list of possibilities for nodes on the network. In the specific case that I'm asking about, we do know the possibilities. The number of entries, even on a large system, is relatively small. : If we had /net, everybody would be able to see that non-storage filesystems : should not be prepopulated with every conceiveable vnode. This is true, but irrelevant. There are different design considerations for different types of virtual file systmes. : The automounter is another good example: here quite complex software : was written specifically to avoid prepopulation with all conceiveable : vnodes and mountpoints, that that is even for storage filesystems. This is a bug in the automounter, and has been for a very long time. I've always hated it. My big problem with magic files and hiding them is that it becomes difficult or impossible to diagnose and troubleshoot. They can create security problems, especially if there's no way to audit their existance and attributes. If there's a real, compelling reason to hide the files, I might understand. But so far I've seen no real, compelling reason proffered as to why the kernel can't expose the knowledge that it has in this manner. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 16:53:12 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 8C01516A40F; Tue, 27 Jun 2006 16:53:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 348F943D7C; Tue, 27 Jun 2006 16:53:08 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id D75721703F; Tue, 27 Jun 2006 16:53:05 +0000 (UTC) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Jun 2006 10:33:43 CST." <20060627.103343.-432837786.imp@bsdimp.com> Date: Tue, 27 Jun 2006 16:53:02 +0000 Message-ID: <62122.1151427182@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: gurney_j@resnet.uoregon.edu, pjd@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:53:12 -0000 In message <20060627.103343.-432837786.imp@bsdimp.com>, "M. Warner Losh" writes : >: devfs is not a hardware inventory facility, it is magic place for >: performing a rendez-vous with a device driver. > >True, but somewhat irrelvant. Not really, it has to be kept in mind to avoid decending into the hell currently reserved for Linux procfs :-) >True, but somewhat irrelvant. This does not go to the question that I >asked. What problems does having fully enumerated devices cause? There is no problem with fully enumerated devices, as long as they don't cause an explosion in the number of devices. >devfs does allow directory listings, therefore absent some compelling >reason to the contrary these listings should be complete. This is an >enumeration of the available devices, which closely mirrors the >available hardware. The problem is that it exactly doesn't do that, and can't possibly do that, because hardware is not seen by devfs until the driver is loaded. I realize that this sounds a bit Clintonesque, but it all comes down to what your definition of "available" is. For instance, the crypt-hw support has one joint device node in /dev but can cover up 16 cards, without ever disclosing to you what they are or what they can do, until you open the joint device and ask with the right ioctls. >There are other facilities for finding out the >underlying hardware, but there's no way to find the magic names in >/dev easily. Only whatever convention we decide to use to pick the names them can help you there. >While it is a magic place, that magic place exists in >the context of a file system, and file systems aren't supposed to >randomly open files. You lost me there... >It is also a security concern. If I wanted to have non-default >permissions on these magic nodes, at the very least I'd have no way to >audit them. I'm unclear if doing the normal unix operations on the >magic nodes would suffice. We have the devfs(8) rules for that. >My question is more specific. What is wrong with having >entries in devfs of files you can actually open, when we know the >universe that is possible given the current knowledge of the kernel? We generally have that. The only exceptions I'm aware of right now are pseudo devices, for which precreation doesn't make sense at all. >My big problem with magic files and hiding them is that it becomes >difficult or impossible to diagnose and troubleshoot. I have a very big problem with magic files as well. Currently g_label doesn't impose any restrictions on the label strings of the device, which means that you can include '/', '..' and ';' in labels. I don't need to tell you what that means for shell scripts etc. Put a g_label on an USB key and trick the admin into to doing something stupid and you're all set: just type mount -t msdos /dev/da0* I can't remember which slice it is... The reason why I am advocating using "on-demand" names for what Pawel is proposing is that way the names only exist if people ask for them, and only the names they ask for exists. In addition to avoiding a wanton doubling of the geom mesh size (because he does it at the very bottom) that also adds significant flexibilty and security to the table. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 18:05:49 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 EF67916A40B; Tue, 27 Jun 2006 18:05:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCFD44A15; Tue, 27 Jun 2006 18:05:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5RI4KsK023917; Tue, 27 Jun 2006 12:04:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jun 2006 12:04:24 -0600 (MDT) Message-Id: <20060627.120424.-1625880159.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <62122.1151427182@critter.freebsd.dk> References: <20060627.103343.-432837786.imp@bsdimp.com> <62122.1151427182@critter.freebsd.dk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 18:05:50 -0000 In message: <62122.1151427182@critter.freebsd.dk> "Poul-Henning Kamp" writes: : >True, but somewhat irrelvant. This does not go to the question that I : >asked. What problems does having fully enumerated devices cause? : : There is no problem with fully enumerated devices, as long as : they don't cause an explosion in the number of devices. That's my view as well! We agree! : >devfs does allow directory listings, therefore absent some compelling : >reason to the contrary these listings should be complete. This is an : >enumeration of the available devices, which closely mirrors the : >available hardware. : : The problem is that it exactly doesn't do that, and can't possibly : do that, because hardware is not seen by devfs until the driver : is loaded. : : I realize that this sounds a bit Clintonesque, but it all comes : down to what your definition of "available" is. : : For instance, the crypt-hw support has one joint device node in /dev : but can cover up 16 cards, without ever disclosing to you what : they are or what they can do, until you open the joint device and : ask with the right ioctls. Don't be silly here. I'm arguing that available be defined as those devices that are physically persent in the system, and have their device driver loaded for them. Twisting "available" in that Clintonesque way isn't what I'm talking about. I'm talking about plain, ordinary meaning of available here: those things the kernel has direct knowledge of. : >While it is a magic place, that magic place exists in : >the context of a file system, and file systems aren't supposed to : >randomly open files. : : You lost me there... Filesystems generally give the ability to enumerate names at a given level of the file system (ls /usr should be no different than ls /dev), plus the ability to open files that appear in ls listings. magic filenames make an end run around this by being able to open files that you cannot list. Listing here includes discoving meta data such as ownership, permissions, acls, etc. [[ I'm ignoring the 'x' bit semantics, because sufficiently privileged users can override that. With magic files there's no such privilege that can override that. ]] : >It is also a security concern. If I wanted to have non-default : >permissions on these magic nodes, at the very least I'd have no way to : >audit them. I'm unclear if doing the normal unix operations on the : >magic nodes would suffice. : : We have the devfs(8) rules for that. And no way to audit them. The basic problem that I'd have in this specific case (serial numbers ala some variation of /dev/ad/ABCDEFG) is that the system administrator cannot set and verify the permissions of the filename. If there's a typo in devfs with 'normal' devices, then a simple ls will show that something is wrong. With magic devices that don't appear in ls, there's no way to know if it was created correctly, or if something went wrong. : >My question is more specific. What is wrong with having : >entries in devfs of files you can actually open, when we know the : >universe that is possible given the current knowledge of the kernel? : : We generally have that. : : The only exceptions I'm aware of right now are pseudo devices, for : which precreation doesn't make sense at all. Yes. Those make sense. Since we create ptys, for example, on demand, having only those ptys that are in the system right now makes good sense. : >My big problem with magic files and hiding them is that it becomes : >difficult or impossible to diagnose and troubleshoot. : : I have a very big problem with magic files as well. : : Currently g_label doesn't impose any restrictions on the label : strings of the device, which means that you can include '/', '..' : and ';' in labels. I don't need to tell you what that means : for shell scripts etc. Put a g_label on an USB key and trick : the admin into to doing something stupid and you're all set: : : just type : mount -t msdos /dev/da0* : I can't remember which slice it is... A simple fix to this would be to have a sysctl that says to filter or allow magic characters in the label name. Shell characters like ';' aren't expanded into the shell command, so if there were '; sh' in the label, the above command wouldn't be affected by it. No root shell would be created. I'll concede that one can construct scenarios where this does present a problem, but they are difficult. The command would have to be something more like: mount -t msdos /dev/da0s? /dos to avoid false positives, and even then it fails with disks that have multiple slices. : The reason why I am advocating using "on-demand" names for : what Pawel is proposing is that way the names only exist : if people ask for them, and only the names they ask for exists. Making them on-demand makes it impossible to audit. Right now, if I'm owrried abotu disk security, I can do: % ls -l /dev/ad* crw-r----- 1 root operator 0, 61 Jun 27 10:19 /dev//ad0 crw-r----- 1 root operator 0, 62 Jun 27 10:19 /dev/ad0s1 crw-r----- 1 root operator 0, 63 Jun 27 10:19 /dev/ad0s2 crw-r----- 1 root operator 0, 64 Jun 27 10:19 /dev/ad0s3 crw-r----- 1 root operator 0, 65 Jun 27 10:19 /dev/ad0s4 crw-r----- 1 root operator 0, 66 Jun 27 04:19 /dev/ad0s4a crw-r----- 1 root operator 0, 67 Jun 27 10:19 /dev/ad0s4b crw-r----- 1 root operator 0, 68 Jun 27 10:19 /dev/ad0s4c crw-r----- 1 root operator 0, 69 Jun 27 04:19 /dev/ad0s4d crw-r----- 1 root operator 0, 70 Jun 27 04:19 /dev/ad0s4e crw-r----- 1 root operator 0, 71 Jun 27 04:19 /dev/ad0s4f crw-r----- 1 root operator 0, 72 Jun 27 04:19 /dev/ad0s4g As can clearly be shown, absent any unknown security bugs, only root can write to these devices, while those in group operator can read. A better way to control their creation is by either the presence or absense of the module, or by a sysctl in the module to control their creation. : In addition to avoiding a wanton doubling of the geom mesh : size (because he does it at the very bottom) that also : adds significant flexibilty and security to the table. I understand the doubling argument. This can be a good argument if the number of entries is very large (I've not seen even large systems have more than 100 entries, and if this is off by default, then there's no damage). However, I'm not sure I understand the flexibility and security side of things. Properly written and implemented, I'm not sure how it affects security. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 18:27:34 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 03F9016A400; Tue, 27 Jun 2006 18:27:34 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id B599C44F23; Tue, 27 Jun 2006 18:27:33 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms063.mailsrvcs.net ([192.168.1.4]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J1J002IA71P4QO5@vms046.mailsrvcs.net>; Tue, 27 Jun 2006 13:22:37 -0500 (CDT) Date: Tue, 27 Jun 2006 13:22:31 -0500 (CDT) From: Sergey Babkin To: Poul-Henning Kamp , "M. Warner Losh" Message-id: <25558880.3245341151432557535.JavaMail.root@vms063.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: gurney_j@resnet.uoregon.edu, pjd@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 18:27:34 -0000 >From: Poul-Henning Kamp >In message <20060627.103343.-432837786.imp@bsdimp.com>, "M. Warner Losh" writes >: > >>: devfs is not a hardware inventory facility, it is magic place for >>: performing a rendez-vous with a device driver. >> >>True, but somewhat irrelvant. > >Not really, it has to be kept in mind to avoid decending into the >hell currently reserved for Linux procfs :-) >From the user/sysadmin perspective I must say that I really love the Linux procfs. It makes the life so much easier. -SB From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 18:44:01 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 EC5DE16A637; Tue, 27 Jun 2006 18:44:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD9343E43; Tue, 27 Jun 2006 18:43:25 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 1B1C9170C4; Tue, 27 Jun 2006 18:43:23 +0000 (UTC) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Jun 2006 12:04:24 CST." <20060627.120424.-1625880159.imp@bsdimp.com> Date: Tue, 27 Jun 2006 18:43:19 +0000 Message-ID: <62426.1151433799@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: gurney_j@resnet.uoregon.edu, pjd@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 18:44:01 -0000 In message <20060627.120424.-1625880159.imp@bsdimp.com>, "M. Warner Losh" write s: >In message: <62122.1151427182@critter.freebsd.dk> > "Poul-Henning Kamp" writes: >: There is no problem with fully enumerated devices, as long as >: they don't cause an explosion in the number of devices. > >That's my view as well! We agree! Well, not quite, but lets leave the deep UNIX philosophy questions behind for a moment. >: We have the devfs(8) rules for that. > >And no way to audit them. The basic problem that I'd have in this >specific case (serial numbers ala some variation of /dev/ad/ABCDEFG) >is that the system administrator cannot set and verify the permissions >of the filename. My take on this is different than yours. I don't think we should allow names that are not "under control", and by not "under control" I mean device names which the device driver writer doesn't control or at the very least sanitize. For instance, if you want to create names that match random strings, like the tape labels in your robot, the sensible and security concious device driver writer makes sure the names have a unique prefix: /dev/tape/$label or similar, so that devfs(8) rules can be written in a surefire way. >A simple fix to this would be to have a sysctl that says to filter or >allow magic characters in the label name. I really don't think it should be optional. A vis(3) in some form should always happen. >: The reason why I am advocating using "on-demand" names for >: what Pawel is proposing is that way the names only exist >: if people ask for them, and only the names they ask for exists. > >Making them on-demand makes it impossible to audit. Right now, if I'm >owrried abotu disk security, I can do: That is why I'm not terribly keen on any kind of user-controlled /dev filenames. >: In addition to avoiding a wanton doubling of the geom mesh >: size (because he does it at the very bottom) that also >: adds significant flexibilty and security to the table. > >However, I'm not sure I understand the >flexibility and security side of things. Properly written and >implemented, I'm not sure how it affects security. With an on-demand scheme, the scalability issue disappears, so we can add hard labels, soft labels, physical position (bus:id:lun), OEM labels, anything you can think off. With a fully enumerated scheme, the scalability bites hard. The only way to collapse these two views would be to allow drivers to register directories in DEVFS, so that they get to enumerate the issue when necessary, but without allocating cdevs for all the unnessesary nodes. That is heading straight down the Linux procfs path. If we want to go that way: fine, personally I think it leads to madness. And please remember: This entire thing only comes up because Pawel doesn't want to solve the problem correctly for g_label, this is the fall-back "quick&dirty" solution. The correct solution is to give the users a reliable tool for stealing the necessary labelsector from the end of a filesystem. -- 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. From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 20:14:45 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 E61B016A407 for ; Tue, 27 Jun 2006 20:14:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A38E43FEC for ; Tue, 27 Jun 2006 20:14:44 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B3C2751845; Tue, 27 Jun 2006 22:14:43 +0200 (CEST) Received: from localhost (ana50.internetdsl.tpnet.pl [83.17.82.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E68AA51388; Tue, 27 Jun 2006 22:14:37 +0200 (CEST) Date: Tue, 27 Jun 2006 22:11:48 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060627201148.GC24054@garage.freebsd.pl> References: <20060627.120424.-1625880159.imp@bsdimp.com> <62426.1151433799@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline In-Reply-To: <62426.1151433799@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=ALL_TRUSTED,BAYES_00, RCVD_IN_XBL autolearn=ham version=3.0.4 Cc: gurney_j@resnet.uoregon.edu, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 20:14:46 -0000 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2006 at 06:43:19PM +0000, Poul-Henning Kamp wrote: > And please remember: This entire thing only comes up because > Pawel doesn't want to solve the problem correctly for g_label, > this is the fall-back "quick&dirty" solution. If you are talking about restricting labels names here, I had the code, but it was backed out. Please see the archives. I still doesn't like it. > The correct solution is to give the users a reliable tool for > stealing the necessary labelsector from the end of a filesystem. I wrote this twice already in this thread, but let me write it again. File systems are not the whole world. For example. I've a disk ad0. I configured gbde(4) on top of it. I create file system on top of ad0.bde. Now, let's assume I implemented shrinkfs(8) as you suggested, how can I shrink gbde(4) provider? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEoZEEForvXbEpPzQRAqYpAKDTP80YTQdddKX/VNzYHNP8fxeANACfb3x7 mSsP1Kl6BkPSs2t0/3NOZlk= =VVLi -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 20:48:10 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 E2A0C16A403; Tue, 27 Jun 2006 20:48:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838B145A6F; Tue, 27 Jun 2006 20:48:10 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E4B0E1703F; Tue, 27 Jun 2006 20:48:07 +0000 (UTC) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Jun 2006 22:11:48 +0200." <20060627201148.GC24054@garage.freebsd.pl> Date: Tue, 27 Jun 2006 20:48:01 +0000 Message-ID: <62844.1151441281@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: gurney_j@resnet.uoregon.edu, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 20:48:11 -0000 In message <20060627201148.GC24054@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >I wrote this twice already in this thread, but let me write it again. >File systems are not the whole world. For example. I've a disk ad0. >I configured gbde(4) on top of it. I create file system on top of >ad0.bde. Now, let's assume I implemented shrinkfs(8) as you suggested, >how can I shrink gbde(4) provider? You can't. Face it, somethings in life are not possible. -- 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. From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 20:56:56 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 DC4C616AAC8; Tue, 27 Jun 2006 20:56:56 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id C73FF45A98; Tue, 27 Jun 2006 20:38:28 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k5RKcN0Q032616; Tue, 27 Jun 2006 16:38:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <62426.1151433799@critter.freebsd.dk> References: <62426.1151433799@critter.freebsd.dk> Date: Tue, 27 Jun 2006 16:38:23 -0400 To: "Poul-Henning Kamp" , "M. Warner Losh" From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: pjd@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 20:56:57 -0000 At 6:43 PM +0000 6/27/06, Poul-Henning Kamp wrote: > >I don't think we should allow names that are not "under >control", and by not "under control" I mean device names >which the device driver writer doesn't control or at the >very least sanitize. > >For instance, if you want to create names that match random >strings, like the tape labels in your robot, the sensible >and security concious device driver writer makes sure the >names have a unique prefix: > > /dev/tape/$label > >or similar, so that devfs(8) rules can be written in a >surefire way. This strikes me as a worthwhile idea. Leave the device- entries in /dev as they are now, but then create some sub-directories which would hold the more arbitrary (or "non-sanitized") names. /dev/info/disk/serial-num or /dev/info/geom/whatever etc. That way there's only one new entry in /dev, and people could just de-permit that directory (or turn the feature off) if they didn't want or need to have that extra info available. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Tue Jun 27 20:57:10 2006 Return-Path: X-Original-To: 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 0EAA716A535 for ; Tue, 27 Jun 2006 20:57:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A726845587 for ; Tue, 27 Jun 2006 19:59:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5RJwEh3025202 for ; Tue, 27 Jun 2006 13:58:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 27 Jun 2006 13:58:17 -0600 (MDT) Message-Id: <20060627.135817.-490997979.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 20:57:10 -0000 NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL is defined). I'd like to do something similar in FreeBSD. I see no reason to needless deviate from NetBSD here. One could make an argument for lots of different files, but at the end of the day does it really matter enough to justify having it be different than NetBSD? Here's my proposed diff, inline, for your consideration: Index: types.h =================================================================== RCS file: /home/ncvs/src/sys/sys/types.h,v retrieving revision 1.95 diff -u -r1.95 types.h --- types.h 26 Nov 2005 12:42:35 -0000 1.95 +++ types.h 27 Jun 2006 19:57:23 -0000 @@ -294,6 +294,11 @@ #define offsetof(type, field) __offsetof(type, field) +/* Macros to clear/set/test flags. */ +#define SET(t, f) (t) |= (f) +#define CLR(t, f) (t) &= ~(f) +#define ISSET(t, f) ((t) & (f)) + #endif /* !_KERNEL */ /* NOTE: That /* !_KERNEL */ should have the '!' removed, but I didn't want to confuse things by doing that too. Comments? Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 04:59:40 2006 Return-Path: X-Original-To: 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 2B95916A412 for ; Wed, 28 Jun 2006 04:59:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B265444E1 for ; Wed, 28 Jun 2006 04:34:44 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from gnn-temp.seoul.corp.yahoo.com.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5S4YGuH080318; Tue, 27 Jun 2006 21:34:17 -0700 (PDT) Date: Wed, 28 Jun 2006 13:34:16 +0900 Message-ID: From: gnn@freebsd.org To: "M. Warner Losh" In-Reply-To: <20060627.135817.-490997979.imp@bsdimp.com> References: <20060627.135817.-490997979.imp@bsdimp.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 04:59:40 -0000 At Tue, 27 Jun 2006 13:58:17 -0600 (MDT), M. Warner Losh wrote: > Comments? > Works for me. Commit it :-) Later, George From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 09:42:36 2006 Return-Path: X-Original-To: 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 547B516A403 for ; Wed, 28 Jun 2006 09:42:36 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6836243DA3 for ; Wed, 28 Jun 2006 09:42:35 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k5S9gMpZ051205; Wed, 28 Jun 2006 13:42:22 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k5S9gMJl051204; Wed, 28 Jun 2006 13:42:22 +0400 (MSD) (envelope-from yar) Date: Wed, 28 Jun 2006 13:42:21 +0400 From: Yar Tikhiy To: "M. Warner Losh" Message-ID: <20060628094221.GA50978@comp.chem.msu.su> References: <20060627.135817.-490997979.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060627.135817.-490997979.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 09:42:36 -0000 On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: > NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL > is defined). I'd like to do something similar in FreeBSD. I see no > reason to needless deviate from NetBSD here. One could make an > argument for lots of different files, but at the end of the day does > it really matter enough to justify having it be different than NetBSD? > > Here's my proposed diff, inline, for your consideration: > > Index: types.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/types.h,v > retrieving revision 1.95 > diff -u -r1.95 types.h > --- types.h 26 Nov 2005 12:42:35 -0000 1.95 > +++ types.h 27 Jun 2006 19:57:23 -0000 > @@ -294,6 +294,11 @@ > > #define offsetof(type, field) __offsetof(type, field) > > +/* Macros to clear/set/test flags. */ > +#define SET(t, f) (t) |= (f) > +#define CLR(t, f) (t) &= ~(f) > +#define ISSET(t, f) ((t) & (f)) > + > #endif /* !_KERNEL */ > > /* > > NOTE: That /* !_KERNEL */ should have the '!' removed, but I didn't > want to confuse things by doing that too. > > Comments? I'd rather enclose the whole RHS of SET and CLR in parentheses. It's still C; SET and CLR can be used in expressions and cause precedence artefacts if not parenthesised. -- Yar From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 09:53:53 2006 Return-Path: X-Original-To: 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 4618516A400 for ; Wed, 28 Jun 2006 09:53:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4CFA43D5D for ; Wed, 28 Jun 2006 09:53:52 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 8498B1703F; Wed, 28 Jun 2006 09:53:50 +0000 (UTC) To: Yar Tikhiy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Jun 2006 13:42:21 +0400." <20060628094221.GA50978@comp.chem.msu.su> Date: Wed, 28 Jun 2006 09:53:46 +0000 Message-ID: <75461.1151488426@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 09:53:53 -0000 In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: >On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: >> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL >> is defined). As one of the people who have worked with the original /bin/sh source code, I have a slight alergic reaction to attempts to paste over the implementation language with macros like these. Setting a bit in 'C' is spelled variable |= bit; not SET(variable, bit); Higher order macros like roundup(), ispow2() are fine with me, because they implement something on top of the language and make the source code more compact and thus faster to read. But all of the three proposed macros take up more space than the native language they obfuscate, what is the sense in that ? If we want to have them for NETBSD compatibility, they should be enclosed in #ifdef NETBSD_COMPAT #endif Or better yet: be put in sys/sys/netbsd_compat.h -- 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. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 10:21:04 2006 Return-Path: X-Original-To: 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 DB98016A407 for ; Wed, 28 Jun 2006 10:21:04 +0000 (UTC) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541C044634 for ; Wed, 28 Jun 2006 10:21:03 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 9FAF217000E; Wed, 28 Jun 2006 13:23:31 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 7BEE9170004; Wed, 28 Jun 2006 13:23:31 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k5SAL2d4003657; Wed, 28 Jun 2006 13:21:02 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5SAL1IK003655; Wed, 28 Jun 2006 13:21:01 +0300 From: Alex Lyashkov To: "M. Warner Losh" In-Reply-To: <20060627.135817.-490997979.imp@bsdimp.com> References: <20060627.135817.-490997979.imp@bsdimp.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: Positive Software Message-Id: <1151490061.3525.9.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Wed, 28 Jun 2006 13:21:01 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 10:21:04 -0000 =F7 =F7=D4=D2, 27.06.2006, =D7 22:58, M. Warner Losh =D0=C9=DB=C5=D4: > NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL > is defined). I'd like to do something similar in FreeBSD. I see no > reason to needless deviate from NetBSD here. One could make an > argument for lots of different files, but at the end of the day does > it really matter enough to justify having it be different than NetBSD? >=20 > Here's my proposed diff, inline, for your consideration: >=20 >=20 > NOTE: That /* !_KERNEL */ should have the '!' removed, but I didn't > want to confuse things by doing that too. >=20 > Comments? >=20 > Warner > _______________________________________________ Who not create abstract framework for work with bitmask more then 64bits size?=20 similar this: #define_bitmask(name,size) char name[(size/8)+1]; #define set_bit(bimask,no) { bitmask[(no/8)] |=3D 1<<(no%8); } #define clr_bit(bitmask,no) { bitmask[(no/8)] &=3D ~(1<<(no%8)); } static inline isset_bit(char *bitmask, no) { return bitmask[(no/8)] & 1<<(no%8); } --=20 Alex Lyashkov Positive Software From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 10:33:00 2006 Return-Path: X-Original-To: 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 E41E316A5DF for ; Wed, 28 Jun 2006 10:33:00 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta04ps.mx.bigpond.com (omta04ps.mx.bigpond.com [144.140.83.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E3544606 for ; Wed, 28 Jun 2006 10:15:03 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta04ps.mx.bigpond.com with ESMTP id <20060628101502.EPVK22738.omta04ps.mx.bigpond.com@areilly.bpc-users.org> for ; Wed, 28 Jun 2006 10:15:02 +0000 Received: (qmail 11627 invoked by uid 501); 28 Jun 2006 10:08:24 -0000 Date: Wed, 28 Jun 2006 20:08:24 +1000 From: Andrew Reilly To: Poul-Henning Kamp Message-ID: <20060628100824.GA1326@duncan.reilly.home> References: <20060628094221.GA50978@comp.chem.msu.su> <75461.1151488426@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75461.1151488426@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: Yar Tikhiy , arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 10:33:01 -0000 On Wed, Jun 28, 2006 at 09:53:46AM +0000, Poul-Henning Kamp wrote: > In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: > >On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: > > >> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL > >> is defined). > > As one of the people who have worked with the original /bin/sh source > code, I have a slight alergic reaction to attempts to paste over > the implementation language with macros like these. > > Setting a bit in 'C' is spelled > variable |= bit; > not > SET(variable, bit); To my eye, if you're going to use "bit" to describe which bit is being operated on, then you should *really* be doing: variable |= (1 << bit) and, obviously, SET(variable, bit) should do that, rather than what has been proposed. What you're spelling, above, and what the NetBSD macros that Warner described do are actually doing: SET(variable, mask). Compatability is a good thing, and if it's convenient to have NetBSD compatability macros, then go do it, but I think that it's important that they advertise what they're doing correctly. (Like the colour now?) Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 12:12:49 2006 Return-Path: X-Original-To: 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 58AF016A508 for ; Wed, 28 Jun 2006 12:12:49 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id F25ED446AE for ; Wed, 28 Jun 2006 11:39:59 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 13:39:57 +0200 Date: Wed, 28 Jun 2006 13:39:58 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Alex Lyashkov In-Reply-To: <1151490061.3525.9.camel@berloga.shadowland> Message-ID: <20060628133928.H52624@beagle.kn.op.dlr.de> References: <20060627.135817.-490997979.imp@bsdimp.com> <1151490061.3525.9.camel@berloga.shadowland> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1442591016-1151494792=:52624" X-OriginalArrivalTime: 28 Jun 2006 11:39:57.0729 (UTC) FILETIME=[9509A110:01C69AA7] Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:12:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1442591016-1151494792=:52624 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 28 Jun 2006, Alex Lyashkov wrote: AL>=F7 =F7=D4=D2, 27.06.2006, =D7 22:58, M. Warner Losh =D0=C9=DB=C5=D4: AL>> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL AL>> is defined). I'd like to do something similar in FreeBSD. I see no AL>> reason to needless deviate from NetBSD here. One could make an AL>> argument for lots of different files, but at the end of the day does AL>> it really matter enough to justify having it be different than NetBSD? AL>>=20 AL>> Here's my proposed diff, inline, for your consideration: AL>>=20 AL> AL>>=20 AL>> NOTE: That /* !_KERNEL */ should have the '!' removed, but I didn't AL>> want to confuse things by doing that too. AL>>=20 AL>> Comments? AL>>=20 AL>> Warner AL>> _______________________________________________ AL>Who not create abstract framework for work with bitmask more then 64bits AL>size?=20 AL>similar this: AL> AL>#define_bitmask(name,size)=09char name[(size/8)+1]; AL>#define set_bit(bimask,no)=09{ bitmask[(no/8)] |=3D 1<<(no%8); } AL>#define clr_bit(bitmask,no)=09=09{ bitmask[(no/8)] &=3D ~(1<<(no%8)); } AL>static inline isset_bit(char *bitmask, no) { AL>=09return bitmask[(no/8)] & 1<<(no%8); You mean bitstring(3)? harti --0-1442591016-1151494792=:52624-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 12:55:30 2006 Return-Path: X-Original-To: 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 B82FF16A403 for ; Wed, 28 Jun 2006 12:55:30 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A27C43D58 for ; Wed, 28 Jun 2006 12:55:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id D46294D20C; Wed, 28 Jun 2006 22:55:25 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5SCtMaS010445; Wed, 28 Jun 2006 22:55:23 +1000 Date: Wed, 28 Jun 2006 22:55:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <75461.1151488426@critter.freebsd.dk> Message-ID: <20060628220742.V74922@delplex.bde.org> References: <75461.1151488426@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yar Tikhiy , arch@FreeBSD.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:55:30 -0000 On Wed, 28 Jun 2006, Poul-Henning Kamp wrote: > In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: >> On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: > >>> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL >>> is defined). I see no types here. > As one of the people who have worked with the original /bin/sh source > code, I have a slight alergic reaction to attempts to paste over > the implementation language with macros like these. > > Setting a bit in 'C' is spelled > variable |= bit; > not > SET(variable, bit); Only slightly? In FreeBSD, these mistakes were only in kern/tty.c and in some usb files obtained from NetBSD and related to tty.c. In tty.c, they appear to be just to avoid adding a USL copyright. (tty.c was obfuscated between FreeBSD-1 and FreeBSD-2 by globally substituting "variable |= BIT" by "SET(variable, BIT)", etc.) I noticed that NetBSD started using these macros elsewhere many years ago. However, their use was still relatively limited in NetBSD a year ago (in kern, they were only in kern-fork.c (1), kern_subr.c (2), kern_systrace.c (many), sys_process.c (a few), tty.c (many), tty_pty.c (many), vfs_bio.c (many) and vfs_lookup.c (1); 211 lines altogether vs 1565 lines matching ' & ' and 27 lines matching the style bug '[A-Za-z]&[A-Za-z]'). It must have been in tty_pty.c that I noticed them many years ago. > Higher order macros like roundup(), ispow2() are fine with me, > because they implement something on top of the language and make > the source code more compact and thus faster to read. > > But all of the three proposed macros take up more space than > the native language they obfuscate, what is the sense in that ? They might be to hide the implementation of a set of flags as a bitmap, but they don't even do that. Another problem with these macros is that a bitmap is more useful than a set of flags, but a much larger and uglier set of macros would be needed to give enough operations on bitmaps, and code that has been blindly translated from an integer-bitmap operation still assumes that the implementation is an integer-bitmap. E.g., in tty.c: %%% /* * delayed suspend (^Y) */ if (CCEQ(cc[VDSUSP], c) && ISSET(lflag, IEXTEN | ISIG) == (IEXTEN | ISIG)) { %%% Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 13:26:39 2006 Return-Path: X-Original-To: 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 84FE016A415; Wed, 28 Jun 2006 13:26:39 +0000 (UTC) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id D783143D6B; Wed, 28 Jun 2006 13:26:34 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 4598817000E; Wed, 28 Jun 2006 16:29:01 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id C090E170004; Wed, 28 Jun 2006 16:29:00 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k5SDQVUu005010; Wed, 28 Jun 2006 16:26:31 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5SDQVmI005008; Wed, 28 Jun 2006 16:26:31 +0300 From: Alex Lyashkov To: Harti Brandt In-Reply-To: <20060628133928.H52624@beagle.kn.op.dlr.de> References: <20060627.135817.-490997979.imp@bsdimp.com> <1151490061.3525.9.camel@berloga.shadowland> <20060628133928.H52624@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: Positive Software Message-Id: <1151501191.3525.46.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Wed, 28 Jun 2006 16:26:31 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 13:26:39 -0000 =F7 =F3=D2=C4, 28.06.2006, =D7 14:39, Harti Brandt =D0=C9=DB=C5=D4: > On Wed, 28 Jun 2006, Alex Lyashkov wrote: >=20 > AL>=F7 =F7=D4=D2, 27.06.2006, =D7 22:58, M. Warner Losh =D0=C9=DB=C5=D4: > AL>> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNE= L > AL>> is defined). I'd like to do something similar in FreeBSD. I see no > AL>> reason to needless deviate from NetBSD here. One could make an > AL>> argument for lots of different files, but at the end of the day does > AL>> it really matter enough to justify having it be different than NetBS= D? > AL>>=20 > AL>> Here's my proposed diff, inline, for your consideration: > AL>>=20 > AL> > AL>>=20 > AL>> NOTE: That /* !_KERNEL */ should have the '!' removed, but I didn't > AL>> want to confuse things by doing that too. > AL>>=20 > AL>> Comments? > AL>>=20 > AL>> Warner > AL>> _______________________________________________ > AL>Who not create abstract framework for work with bitmask more then 64bi= ts > AL>size?=20 > AL>similar this: > AL> > AL>#define_bitmask(name,size) char name[(size/8)+1]; > AL>#define set_bit(bimask,no) { bitmask[(no/8)] |=3D 1<<(no%8); } > AL>#define clr_bit(bitmask,no) { bitmask[(no/8)] &=3D ~(1<<(no%8)); } > AL>static inline isset_bit(char *bitmask, no) { > AL> return bitmask[(no/8)] & 1<<(no%8); >=20 > You mean bitstring(3)? Thanks for point this. --=20 Alex Lyashkov Positive Software From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 15:41:26 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 0872016A408; Wed, 28 Jun 2006 15:41:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD9D443D58; Wed, 28 Jun 2006 15:41:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5SFfFLL026519; Wed, 28 Jun 2006 11:41:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 28 Jun 2006 10:36:07 -0400 User-Agent: KMail/1.9.1 References: <20060627.120424.-1625880159.imp@bsdimp.com> <62426.1151433799@critter.freebsd.dk> <20060627201148.GC24054@garage.freebsd.pl> In-Reply-To: <20060627201148.GC24054@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606281036.08090.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jun 2006 11:41:22 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1571/Wed Jun 28 08:16:22 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Poul-Henning Kamp , Pawel Jakub Dawidek , gurney_j@resnet.uoregon.edu Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 15:41:26 -0000 On Tuesday 27 June 2006 16:11, Pawel Jakub Dawidek wrote: > On Tue, Jun 27, 2006 at 06:43:19PM +0000, Poul-Henning Kamp wrote: > > And please remember: This entire thing only comes up because > > Pawel doesn't want to solve the problem correctly for g_label, > > this is the fall-back "quick&dirty" solution. > > If you are talking about restricting labels names here, I had the code, > but it was backed out. Please see the archives. I still doesn't like it. > > > The correct solution is to give the users a reliable tool for > > stealing the necessary labelsector from the end of a filesystem. > > I wrote this twice already in this thread, but let me write it again. > File systems are not the whole world. For example. I've a disk ad0. > I configured gbde(4) on top of it. I create file system on top of > ad0.bde. Now, let's assume I implemented shrinkfs(8) as you suggested, > how can I shrink gbde(4) provider? If you want a label you should label it before gbde(4). This is similar to the fact that you can't retroactively add a gmirror under the gbde slice either. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 15:56:44 2006 Return-Path: X-Original-To: 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 768B916A403 for ; Wed, 28 Jun 2006 15:56:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15BC343D78 for ; Wed, 28 Jun 2006 15:56:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5SFtT97046337; Wed, 28 Jun 2006 09:55:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 28 Jun 2006 09:55:27 -0600 (MDT) Message-Id: <20060628.095527.-432838142.imp@bsdimp.com> To: shadow@psoft.net From: "M. Warner Losh" In-Reply-To: <1151490061.3525.9.camel@berloga.shadowland> References: <20060627.135817.-490997979.imp@bsdimp.com> <1151490061.3525.9.camel@berloga.shadowland> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 15:56:44 -0000 In message: <1151490061.3525.9.camel@berloga.shadowland> Alex Lyashkov writes: : =F7 =F7=D4=D2, 27.06.2006, =D7 22:58, M. Warner Losh =D0=C9=DB=C5=D4:= : > NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERN= EL : > is defined). I'd like to do something similar in FreeBSD. I see n= o : > reason to needless deviate from NetBSD here. One could make an : > argument for lots of different files, but at the end of the day doe= s : > it really matter enough to justify having it be different than NetB= SD? : > = : > Here's my proposed diff, inline, for your consideration: : > = : = : > = : > NOTE: That /* !_KERNEL */ should have the '!' removed, but I didn't= : > want to confuse things by doing that too. : > = : > Comments? : > = : > Warner : > _______________________________________________ : Who not create abstract framework for work with bitmask more then 64b= its : size? = : similar this: : = : #define_bitmask(name,size) char name[(size/8)+1]; : #define set_bit(bimask,no) { bitmask[(no/8)] |=3D 1<<(no%8); } : #define clr_bit(bitmask,no) { bitmask[(no/8)] &=3D ~(1<<(no%8)); } : static inline isset_bit(char *bitmask, no) { : return bitmask[(no/8)] & 1<<(no%8); : } This isn't about 'frameworks' but rather a simple set of macros to aid in the porting of code from other systems. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 16:56:08 2006 Return-Path: X-Original-To: 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 D946616A4A0; Wed, 28 Jun 2006 16:56:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B576D43E4B; Wed, 28 Jun 2006 16:24:17 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-217-36-79.daxnet.no ([193.217.36.79] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 203770555; Wed, 28 Jun 2006 18:24:13 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Wed, 28 Jun 2006 18:24:10 +0200 User-Agent: KMail/1.7 References: <20060627.135817.-490997979.imp@bsdimp.com> In-Reply-To: <20060627.135817.-490997979.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606281824.13729.hselasky@c2i.net> Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 16:56:09 -0000 On Tuesday 27 June 2006 21:58, M. Warner Losh wrote: > NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL > is defined). I'd like to do something similar in FreeBSD. I see no > reason to needless deviate from NetBSD here. One could make an > argument for lots of different files, but at the end of the day does > it really matter enough to justify having it be different than NetBSD? > > Here's my proposed diff, inline, for your consideration: > > Index: types.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/types.h,v > retrieving revision 1.95 > diff -u -r1.95 types.h > --- types.h 26 Nov 2005 12:42:35 -0000 1.95 > +++ types.h 27 Jun 2006 19:57:23 -0000 > @@ -294,6 +294,11 @@ > > #define offsetof(type, field) __offsetof(type, field) > > +/* Macros to clear/set/test flags. */ > +#define SET(t, f) (t) |= (f) > +#define CLR(t, f) (t) &= ~(f) > +#define ISSET(t, f) ((t) & (f)) > + > #endif /* !_KERNEL */ > I am currently expanding those macros in all the USB drivers I am rewriting. --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 16:56:08 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 D946616A4A0; Wed, 28 Jun 2006 16:56:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B576D43E4B; Wed, 28 Jun 2006 16:24:17 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-217-36-79.daxnet.no ([193.217.36.79] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 203770555; Wed, 28 Jun 2006 18:24:13 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Wed, 28 Jun 2006 18:24:10 +0200 User-Agent: KMail/1.7 References: <20060627.135817.-490997979.imp@bsdimp.com> In-Reply-To: <20060627.135817.-490997979.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606281824.13729.hselasky@c2i.net> Cc: arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 16:56:09 -0000 On Tuesday 27 June 2006 21:58, M. Warner Losh wrote: > NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL > is defined). I'd like to do something similar in FreeBSD. I see no > reason to needless deviate from NetBSD here. One could make an > argument for lots of different files, but at the end of the day does > it really matter enough to justify having it be different than NetBSD? > > Here's my proposed diff, inline, for your consideration: > > Index: types.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/types.h,v > retrieving revision 1.95 > diff -u -r1.95 types.h > --- types.h 26 Nov 2005 12:42:35 -0000 1.95 > +++ types.h 27 Jun 2006 19:57:23 -0000 > @@ -294,6 +294,11 @@ > > #define offsetof(type, field) __offsetof(type, field) > > +/* Macros to clear/set/test flags. */ > +#define SET(t, f) (t) |= (f) > +#define CLR(t, f) (t) &= ~(f) > +#define ISSET(t, f) ((t) & (f)) > + > #endif /* !_KERNEL */ > I am currently expanding those macros in all the USB drivers I am rewriting. --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 18:19:47 2006 Return-Path: X-Original-To: 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 26A0316A539 for ; Wed, 28 Jun 2006 18:19:47 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A7F45432 for ; Wed, 28 Jun 2006 17:47:33 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k5SHlQvM057391; Wed, 28 Jun 2006 21:47:26 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k5SHlPGS057390; Wed, 28 Jun 2006 21:47:25 +0400 (MSD) (envelope-from yar) Date: Wed, 28 Jun 2006 21:47:25 +0400 From: Yar Tikhiy To: Andrew Reilly Message-ID: <20060628174725.GA57252@comp.chem.msu.su> References: <20060628094221.GA50978@comp.chem.msu.su> <75461.1151488426@critter.freebsd.dk> <20060628100824.GA1326@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060628100824.GA1326@duncan.reilly.home> User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 18:19:47 -0000 On Wed, Jun 28, 2006 at 08:08:24PM +1000, Andrew Reilly wrote: > On Wed, Jun 28, 2006 at 09:53:46AM +0000, Poul-Henning Kamp wrote: > > In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: > > >On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: > > > > >> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL > > >> is defined). > > > > As one of the people who have worked with the original /bin/sh source > > code, I have a slight alergic reaction to attempts to paste over > > the implementation language with macros like these. > > > > Setting a bit in 'C' is spelled > > variable |= bit; > > not > > SET(variable, bit); > > To my eye, if you're going to use "bit" to describe which bit is > being operated on, then you should *really* be doing: > variable |= (1 << bit) > and, obviously, SET(variable, bit) should do that, rather than > what has been proposed. That would require converting our device .h files from defining bit masks to defining bit numbers. I don't mind you doing that as long as SET is expanded to: ((variable) |= (1 << (bit))) -- note the bunch of roughly balanced parentheses ;-) -- Yar From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 19:05:09 2006 Return-Path: X-Original-To: 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 5EF0816A494 for ; Wed, 28 Jun 2006 19:05:09 +0000 (UTC) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B3FF43DA9 for ; Wed, 28 Jun 2006 19:05:03 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.6/8.13.6) with ESMTP id k5SJ4e0N075887; Wed, 28 Jun 2006 15:04:40 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.6/8.13.6/Submit) with ESMTP id k5SJ4eXb075884; Wed, 28 Jun 2006 15:04:40 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Wed, 28 Jun 2006 15:04:40 -0400 (EDT) From: "Andrew R. Reiter" To: Yar Tikhiy In-Reply-To: <20060628174725.GA57252@comp.chem.msu.su> Message-ID: <20060628150227.R75801@fledge.watson.org> References: <20060628094221.GA50978@comp.chem.msu.su> <75461.1151488426@critter.freebsd.dk> <20060628100824.GA1326@duncan.reilly.home> <20060628174725.GA57252@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 19:05:09 -0000 I apologize for top posting, but I lost the email that I think my point/question pertains to. Part of this seems to be for compatibility / merging from drivers of other OSes, no? If I am wrong, ignore me :-). If this is the case, would it be better to create some common other area for things of this nature so that it suffices to allow builds, but does not infect other areas of our own code base? Could be a poor idea, but just throwing it out there for the fsck of it. Cheers, Andrew On Wed, 28 Jun 2006, Yar Tikhiy wrote: :On Wed, Jun 28, 2006 at 08:08:24PM +1000, Andrew Reilly wrote: :> On Wed, Jun 28, 2006 at 09:53:46AM +0000, Poul-Henning Kamp wrote: :> > In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: :> > >On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: :> > :> > >> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL :> > >> is defined). :> > :> > As one of the people who have worked with the original /bin/sh source :> > code, I have a slight alergic reaction to attempts to paste over :> > the implementation language with macros like these. :> > :> > Setting a bit in 'C' is spelled :> > variable |= bit; :> > not :> > SET(variable, bit); :> :> To my eye, if you're going to use "bit" to describe which bit is :> being operated on, then you should *really* be doing: :> variable |= (1 << bit) :> and, obviously, SET(variable, bit) should do that, rather than :> what has been proposed. : :That would require converting our device .h files from defining bit :masks to defining bit numbers. I don't mind you doing that as long :as SET is expanded to: : : ((variable) |= (1 << (bit))) : :-- note the bunch of roughly balanced parentheses ;-) : :-- :Yar :_______________________________________________ :freebsd-arch@freebsd.org mailing list :http://lists.freebsd.org/mailman/listinfo/freebsd-arch :To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" : : -- arr@watson.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 19:42:58 2006 Return-Path: X-Original-To: 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 12E7C16A4A7 for ; Wed, 28 Jun 2006 19:42:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44C8344EAD for ; Wed, 28 Jun 2006 19:22:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.220]) ([10.251.17.220]) by a50.ironport.com with ESMTP; 28 Jun 2006 12:22:24 -0700 Message-ID: <44A2D6EE.8080902@elischer.org> Date: Wed, 28 Jun 2006 12:22:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Andrew R. Reiter" References: <20060628094221.GA50978@comp.chem.msu.su> <75461.1151488426@critter.freebsd.dk> <20060628100824.GA1326@duncan.reilly.home> <20060628174725.GA57252@comp.chem.msu.su> <20060628150227.R75801@fledge.watson.org> In-Reply-To: <20060628150227.R75801@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yar Tikhiy , Poul-Henning Kamp , arch@freebsd.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 19:42:58 -0000 Andrew R. Reiter wrote: >I apologize for top posting, but I lost the email that I think my >point/question pertains to. > >Part of this seems to be for compatibility / merging from drivers of other >OSes, no? If I am wrong, ignore me :-). If this is the case, would it be >better to create some common other area for things of this nature so that >it suffices to allow builds, but does not infect other areas of our own >code base? > > how about just making a /sys/sys/netbsd_compat.h and /sys/sys/openbsd_compat.h put this sort of thing in there.. >Could be a poor idea, but just throwing it out there for the fsck of it. > >Cheers, >Andrew > >On Wed, 28 Jun 2006, Yar Tikhiy wrote: > >:On Wed, Jun 28, 2006 at 08:08:24PM +1000, Andrew Reilly wrote: >:> On Wed, Jun 28, 2006 at 09:53:46AM +0000, Poul-Henning Kamp wrote: >:> > In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: >:> > >On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: >:> > >:> > >> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL >:> > >> is defined). >:> > >:> > As one of the people who have worked with the original /bin/sh source >:> > code, I have a slight alergic reaction to attempts to paste over >:> > the implementation language with macros like these. >:> > >:> > Setting a bit in 'C' is spelled >:> > variable |= bit; >:> > not >:> > SET(variable, bit); >:> >:> To my eye, if you're going to use "bit" to describe which bit is >:> being operated on, then you should *really* be doing: >:> variable |= (1 << bit) >:> and, obviously, SET(variable, bit) should do that, rather than >:> what has been proposed. >: >:That would require converting our device .h files from defining bit >:masks to defining bit numbers. I don't mind you doing that as long >:as SET is expanded to: >: >: ((variable) |= (1 << (bit))) >: >:-- note the bunch of roughly balanced parentheses ;-) >: >:-- >:Yar >:_______________________________________________ >:freebsd-arch@freebsd.org mailing list >:http://lists.freebsd.org/mailman/listinfo/freebsd-arch >:To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >: >: > >-- >arr@watson.org >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 20:29:13 2006 Return-Path: X-Original-To: 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 8969616A403 for ; Wed, 28 Jun 2006 20:29:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5340F449A4 for ; Wed, 28 Jun 2006 20:29:12 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C03DC1703F; Wed, 28 Jun 2006 20:29:09 +0000 (UTC) To: "Andrew R. Reiter" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 28 Jun 2006 15:04:40 -0400." <20060628150227.R75801@fledge.watson.org> Date: Wed, 28 Jun 2006 20:29:06 +0000 Message-ID: <28872.1151526546@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, Yar Tikhiy Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 20:29:13 -0000 In message <20060628150227.R75801@fledge.watson.org>, "Andrew R. Reiter" writes : > >I apologize for top posting, but I lost the email that I think my >point/question pertains to. > >Part of this seems to be for compatibility / merging from drivers of other >OSes, no? If I am wrong, ignore me :-). If this is the case, would it be >better to create some common other area for things of this nature so that >it suffices to allow builds, but does not infect other areas of our own >code base? That's what I proposed too: #include -- 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. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 22:06:33 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 3F6CE16A407; Wed, 28 Jun 2006 22:06:33 +0000 (UTC) (envelope-from andrea@webcom.it) Received: from www.webcom.it (gen053.n002.c03.escapebox.net [213.73.82.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FC0343D8D; Wed, 28 Jun 2006 22:06:31 +0000 (GMT) (envelope-from andrea@webcom.it) Received: from andrea by webcom.it with local (Exim 3.36 #1) id 1FviB3-000BrU-00; Wed, 28 Jun 2006 22:06:29 +0000 Date: Wed, 28 Jun 2006 22:06:29 +0000 From: Andrea Campi To: Garance A Drosehn Message-ID: <20060628220628.GA12488@webcom.it> References: <62426.1151433799@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: Andrea Campi Cc: Poul-Henning Kamp , pjd@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 22:06:33 -0000 On Tue, Jun 27, 2006 at 04:38:23PM -0400, Garance A Drosehn wrote: > This strikes me as a worthwhile idea. Leave the device- > entries in /dev as they are now, but then create some > sub-directories which would hold the more arbitrary (or > "non-sanitized") names. > /dev/info/disk/serial-num > or /dev/info/geom/whatever > > etc. That way there's only one new entry in /dev, and > people could just de-permit that directory (or turn the > feature off) if they didn't want or need to have that > extra info available. Picking a semi-random message to reply to, I seem to recall Solaris has a separate /devices filesystem for this: all entries are dynamic, so the filesystem is strictly readonly from a userland point of view. In our case, we would have quite a lot of overlap with devinfo, but it could still be something to keep in mind. Andrea -- Loose bits sink chips.