From owner-freebsd-arch Sun Jul 23 0:29:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 72D2137B9A6; Sun, 23 Jul 2000 00:29:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id AAA81988; Sun, 23 Jul 2000 00:29:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 23 Jul 2000 00:29:54 -0700 (PDT) From: Kris Kennaway To: "Louis A. Mamakos" Cc: "Jeroen C. van Gelderen" , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-Reply-To: <200007230408.AAA76739@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Jul 2000, Louis A. Mamakos wrote: > I've got some raw data sampled from my Bt848 video capture card that > I'm interested in having you evaluate. Each of the datasets has about 2.7 bits of entropy per colour channel per pixel (they're 8-bit colour values) - surprisingly, there's not much variation between the datasets, although that's probably because my algorithm is blind to the actual structure of the image. I'm trying to figure out how to use Matlab so I can play with some more advanced tests. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 23 7:22:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from danbala.tuwien.ac.at (danbala.ifoer.tuwien.ac.at [128.130.168.64]) by hub.freebsd.org (Postfix) with ESMTP id D15C337B757; Sun, 23 Jul 2000 07:22:16 -0700 (PDT) (envelope-from wiz@danbala.tuwien.ac.at) Received: (from wiz@localhost) by danbala.tuwien.ac.at (8.8.8/8.8.8) id QAA17137; Sun, 23 Jul 2000 16:21:48 +0200 (MEST) Date: Sun, 23 Jul 2000 16:21:48 +0200 From: Thomas Klausner To: Jason R Thorpe , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, tech-kern@netbsd.org, tech@openbsd.org Cc: wiz@netbsd.org Subject: Re: minherit(2) API Message-ID: <20000723162148.D16217@danbala.tuwien.ac.at> References: <20000709150924.N23637@danbala.tuwien.ac.at> <20000711221235.W11576@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000711221235.W11576@dr-evil.shagadelic.org>; from thorpej@zembu.com on Tue, Jul 11, 2000 at 10:12:36PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mutt made be believe that Jason R Thorpe wrote: > DONATE_COPY is not implemented in UVM. I'm not sure it was ever > implemented anywhere. "Copy and delete" is really "move", right? > Anyway, it's not clear those semantics are really useful at all. Okay, so let's skip that one. Any other comments? I think I can change it in NetBSD -- anyone willing to do the necessary changes in FreeBSD and OpenBSD? Bye, Thomas -- Thomas Klausner - wiz@danbala.tuwien.ac.at I wanted to emulate some of my heroes, but I didn't know their op-codes. --dowe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 23 12:23: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dt052n3e.san.rr.com (dt052n3e.san.rr.com [204.210.33.62]) by hub.freebsd.org (Postfix) with ESMTP id 55DDB37B56D for ; Sun, 23 Jul 2000 12:23:06 -0700 (PDT) (envelope-from DougB@yahoo-inc.com) Received: from yahoo-inc.com (master [10.0.0.2]) by dt052n3e.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA39715; Sun, 23 Jul 2000 12:22:58 -0700 (PDT) (envelope-from DougB@yahoo-inc.com) Message-ID: <397B4612.901888DF@yahoo-inc.com> Date: Sun, 23 Jul 2000 12:22:58 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: arch@FreeBSD.ORG Subject: Re: Quantifying entropy References: <12075.964301487@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > > Me too! This is completely unproductive. I'm getting close to the > > point of putting "entropy" and "random" into my kill file. > > The only way I can see this discussion being useful is if we come up > with some way to subscribe one's /dev/random to one of our mailing > lists. That would be a fine source of entropy, would it not? :-) Only if my /dev/random killfile'ed Brett first. His input stream is too predictable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 4:52:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3F93C37B7BD for ; Mon, 24 Jul 2000 04:52:16 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id EAA24514; Mon, 24 Jul 2000 04:50:39 -0700 Date: Mon, 24 Jul 2000 04:50:42 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jack Rusher Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-Reply-To: <397A5DB9.846B905@integratus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Thoughts? > > If something is going to be modified to understand this, I would > like it to be vinum. Most of my uses for FCAL attached storage > involve some form of volume management. So does this mean you want to see the WWN/VPD info smarts in vinum? I think that vinum is already good, like VxVM also, in that once you label a disk (i.e., borg it into vinum), it's boot-time to boot-time address becomes can become less relevant. However, with all due respect to Greg, I want a solution that doesn't require vinum. > > This approach does, of course, bring up the notion of a /devfs > directory that contains the real disk information and a set of links > in /dev (or /dev/dsk) that map the common names to the right > devices. One of the big wins of using links to do this is that > moving the disks around won't change where they appear in the > /dev/da[0..N] namespace. > > Solaris style boot -r, anyone? No, no, no. A 1000 times no. I have 30 Megabytes of mail from my time at Sun in death matches over this back in 1991 that easily match the vitriol of the current Linux IDE/ATA flamewar meltdown. The whole /dev/dsk/XXX goop was/is a complete disaster in that it half-assed mushes together some bogus fixed name and address semantics into a symlink to try and give you some location info in the 'friendly' name (as opposed to the completely unambiguous physical pathname of the 'all-singing, all-dancing' devgs that Sun hasn't delivered yet but you currently get *something* of in SOlaris). I think that the constancy of the /dev/daX namespace is relevant only as long as that is the name in /etc/fstab. Presumably the grand plans of Poul for devfs will give one the same as the 'all-singing, all-dancing' devfs, but I have no idea when that will show up as a usable entity. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 11:15:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 4F87D37BC61; Mon, 24 Jul 2000 11:15:33 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA01939; Mon, 24 Jul 2000 13:15:27 -0500 (CDT) Date: Mon, 24 Jul 2000 13:15:27 -0500 From: Alan Cox To: Thomas Klausner Cc: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: minherit(2) API Message-ID: <20000724131527.A6681@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think I can change it in NetBSD -- anyone willing to do the > necessary changes in FreeBSD and OpenBSD? I'll do it. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 12: 8: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 807DE37BCE8 for ; Mon, 24 Jul 2000 12:07:57 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA06892; Mon, 24 Jul 2000 21:06:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: Jack Rusher , freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-reply-to: Your message of "Mon, 24 Jul 2000 04:50:42 PDT." Date: Mon, 24 Jul 2000 21:06:27 +0200 Message-ID: <6890.964465587@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt, We have many storage devices which doesn't sport a serial number, so any "I mean this particular disk, no matter where you find it" scheme will have to be based on "in-sector" labels, be it FreeBSD or other labels. The BSD disklabel already have a field for disk-name which can be used for this, what we need is to collect these names as we see them and provide a "is this disk attached and if so where" function to look it up. This would be pretty ugly in the current setup, but pretty straight forward in the "Geom" stuff I'm working on when I have time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 13:49: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 3004537BB6A for ; Mon, 24 Jul 2000 13:48:58 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 23385 invoked from network); 24 Jul 2000 20:48:52 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 24 Jul 2000 20:48:52 -0000 Message-ID: <397CABB4.1CAAC7C3@integratus.com> Date: Mon, 24 Jul 2000 13:48:52 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > I think that vinum is already good, like VxVM also, in that once you label a > disk (i.e., borg it into vinum), it's boot-time to boot-time address becomes > can become less relevant. Yes, there is self descriptive meta data on VxVM and vinum drives. However, you need some way to tell vinum which drives to eat. I think it would be useful to be able to specify this in a WWN aware fashion. > The whole /dev/dsk/XXX goop was/is a complete disaster in that it half-assed > mushes together some bogus fixed name and address semantics into a symlink > to try and give you some location info in the 'friendly' name (as opposed > to the completely unambiguous physical pathname of the 'all-singing, There are some problems with trying to do this with WWN (or any other serial number) as the only entry point to the device. Namely, you can't be sure that the device will have any such serial number. Also, it makes it a pain in the ass for the casual user if they can't just say "/dev/da0, please." > I think that the constancy of the /dev/daX namespace is relevant only as > long as that is the name in /etc/fstab. There are other issues having to do with what happens when you pull a disk out and copy the contents onto another drive (upgrade to bigger primary disk, for instance). You want to just stick the drive back in the machine and have everything boot and work normally. This only works if the fstab looks at the first SCSI drive by a positional name. The other option is to use disklabels (instead of disk serial numbers) to identify the disks. You can provide a label copy tool to clone a disk, but you run into trouble when you have two disks that are clones of one another in the same system. You also have trouble if one of the disks is the Windows/Linux/whatever partition of your workstation and has a label scheme that doesn't play nice with the BSD scheme. What do you call that disk in the device tree? All I am trying to illustrate here is that there are some cases where it is better to have absolute names and some cases where positional abstraction is the right answer. It would be nice if we could have a compromise of the two techniques that lets you look at your storage in the way that makes the most sense for your application. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 13:51:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id CB9F137BB1F for ; Mon, 24 Jul 2000 13:51:12 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 23410 invoked from network); 24 Jul 2000 20:51:11 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 24 Jul 2000 20:51:11 -0000 Message-ID: <397CAC40.6E2DD4DB@integratus.com> Date: Mon, 24 Jul 2000 13:51:12 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs References: <6890.964465587@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > The BSD disklabel already have a field for disk-name which can be > used for this, what we need is to collect these names as we see them > and provide a "is this disk attached and if so where" function to > look it up. How do you get around fstab entries like this: /dev/acd0c /cdrom cd9660 ro,noauto 0 0 ...without some idea of a positional device entry? -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 13:56: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 8800137BCED for ; Mon, 24 Jul 2000 13:55:55 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA07680; Mon, 24 Jul 2000 22:55:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jack Rusher Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-reply-to: Your message of "Mon, 24 Jul 2000 13:51:12 PDT." <397CAC40.6E2DD4DB@integratus.com> Date: Mon, 24 Jul 2000 22:55:45 +0200 Message-ID: <7678.964472145@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <397CAC40.6E2DD4DB@integratus.com>, Jack Rusher writes: >Poul-Henning Kamp wrote: >> >> The BSD disklabel already have a field for disk-name which can be >> used for this, what we need is to collect these names as we see them >> and provide a "is this disk attached and if so where" function to >> look it up. > > How do you get around fstab entries like this: > >/dev/acd0c /cdrom cd9660 ro,noauto 0 0 > >...without some idea of a positional device entry? We will obviously have to support both media-id and positional addressing, I don't think anybody seriously thought a media-id based system would be enough on its own ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 14: 6: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 3857537BCB0 for ; Mon, 24 Jul 2000 14:06:04 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 23658 invoked from network); 24 Jul 2000 21:06:02 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 24 Jul 2000 21:06:02 -0000 Message-ID: <397CAFBA.3E95BB4B@integratus.com> Date: Mon, 24 Jul 2000 14:06:02 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs References: <7678.964472145@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > We will obviously have to support both media-id and positional > addressing, I don't think anybody seriously thought a media-id > based system would be enough on its own ? I had gotten the notion from mjacob's last e-mail that he was against a hybrid mechanism. My feeling is that we need such a beast. I have yet to see a design that works better than the (admittedly hacked up) Solaris approach. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 14:26:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7B56237B90A for ; Mon, 24 Jul 2000 14:26:55 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA26494; Mon, 24 Jul 2000 14:26:08 -0700 Date: Mon, 24 Jul 2000 14:25:32 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: Jack Rusher , freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-Reply-To: <6890.964465587@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, this doesn't address directly things like tape devices or ses instances (e.g.)- basically anything that is SCSI or Fibre Channel addressable has some kind of WWN or Serial Number for the device itself, but there is more or less general consensus from linux to Veritas to here that an ondisk label (past initial import) is the right thing to do. Again- I think that this and the full devfs is a usable methodology. I still would like some feedback as to whether or not linking mount (and mt, e.g.) with libcam so I can use device VPD info or WWNs would be just too awful for FreeBSD. This way it can be used now, without vinum. On Mon, 24 Jul 2000, Poul-Henning Kamp wrote: > > Matt, > > We have many storage devices which doesn't sport a serial number, > so any "I mean this particular disk, no matter where you find it" > scheme will have to be based on "in-sector" labels, be it FreeBSD > or other labels. > > The BSD disklabel already have a field for disk-name which can be > used for this, what we need is to collect these names as we see them > and provide a "is this disk attached and if so where" function to > look it up. > > This would be pretty ugly in the current setup, but pretty straight > forward in the "Geom" stuff I'm working on when I have time. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 14:29:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 964EA37BED6 for ; Mon, 24 Jul 2000 14:29:34 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA07890; Mon, 24 Jul 2000 23:29:24 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: Jack Rusher , freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-reply-to: Your message of "Mon, 24 Jul 2000 14:25:32 PDT." Date: Mon, 24 Jul 2000 23:29:23 +0200 Message-ID: <7888.964474163@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthe w Jacob writes: >Again- I think that this and the full devfs is a usable methodology. I still >would like some feedback as to whether or not linking mount (and mt, e.g.) >with libcam so I can use device VPD info or WWNs would be just too awful for >FreeBSD. This way it can be used now, without vinum. Sounds awful to me, but I guess it depends a lot on the implementation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 14:41: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 64D1A37BD1B for ; Mon, 24 Jul 2000 14:40:56 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA26560; Mon, 24 Jul 2000 14:40:54 -0700 Date: Mon, 24 Jul 2000 14:40:19 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jack Rusher Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-Reply-To: <397CABB4.1CAAC7C3@integratus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think that vinum is already good, like VxVM also, in that once you label a > > disk (i.e., borg it into vinum), it's boot-time to boot-time address becomes > > can become less relevant. > > Yes, there is self descriptive meta data on VxVM and vinum drives. > However, you need some way to tell vinum which drives to eat. Okay- yeah, that's right.... > I think > it would be useful to be able to specify this in a WWN aware fashion. Sure- that'd make it like VxVM then. I sorta thought it was there already. > > > The whole /dev/dsk/XXX goop was/is a complete disaster in that it half-assed > > mushes together some bogus fixed name and address semantics into a symlink > > to try and give you some location info in the 'friendly' name (as opposed > > to the completely unambiguous physical pathname of the 'all-singing, > > There are some problems with trying to do this with WWN (or any other > serial number) as the only entry point to the device. Namely, you can't > be sure that the device will have any such serial number. Also, it > makes it a pain in the ass for the casual user if they can't just say > "/dev/da0, please." It wasn't meant to be exclusionary- just additive. And the WWN and VPD serial number are alternate methods, both possibly qualified by lun. The 128 bit WWN that you can get as page 0x83 *can* be per LUN, but all disk drives are currently 64 bit WWNs. > > I think that the constancy of the /dev/daX namespace is relevant only as > > long as that is the name in /etc/fstab. > > There are other issues having to do with what happens when you pull a > disk out and copy the contents onto another drive (upgrade to bigger > primary disk, for instance). You want to just stick the drive back in > the machine and have everything boot and work normally. This only works > if the fstab looks at the first SCSI drive by a positional name. Yes- of course. > > The other option is to use disklabels (instead of disk serial numbers) > to identify the disks. You can provide a label copy tool to clone a But you've fundamentally changed the object. It no longer is disk WWN XXXX- it's now disk WWN YYYY. You just happen to have ensured that the contents of YYYY or the same as XXXX. > disk, but you run into trouble when you have two disks that are clones > of one another in the same system. You also have trouble if one of the > disks is the Windows/Linux/whatever partition of your workstation and > has a label scheme that doesn't play nice with the BSD scheme. What do > you call that disk in the device tree? Exactly. That's the drawback of a label based scheme in some sense- which is why I want to use properties of the device that are immutable and irrespective of the data content. That doesn't mean that at a different point labels are not desirable! It's just that this is a different identification level. > > All I am trying to illustrate here is that there are some cases where > it is better to have absolute names and some cases where positional > abstraction is the right answer. It would be nice if we could have a > compromise of the two techniques that lets you look at your storage in > the way that makes the most sense for your application. Absolutely. At Sun, the take on it was that the devfs (derived from either an OBP prom tree or built via harwired root nexus and conf fragments for the original sun4 proof of concept) representation would be unambiguously physical, while /dev names would be logical. I argued that /dev/sd[0..n] was perfectly adequate in this model (rather than trying to encode position information into the name as the /dev/[r]dsk names do). Furthermore, naming disks (at least) by volume name (the "Fred" volume) is even more convenient. As you say- sometimes you want physical names. Sometimes you convenient logical. Physical names invariably end up being hard for anyone to use. Logical or convenient names aren't adequate to formally address a device without some under-the-hood magic to persistently get the right (current) physical address. This all has more immediacy than a 'would be nice' for me. One approach that Qlogic (and JNI) have taken with HBA drivers is to attempt to maintain a persistent 'target<>WWN/port' binding in card NVRAM. This allows that which was 'probed/logged in' as target 93 to stay target 93 even if it changes to a different loop position- also it gives the correct hint as to how to bind it if this is a fabric device. I *really* don't want to implement this for my *BSD/Linux Qlogic driver as this raises all sorts of other problematic issues. I'd much rather see some framework in FreeBSD (and NetBSD and OpenBSD.... Linux has a devfs going...) to accomodate this. But that isn't there yet and won't be for a while. I want to solve this for 5.0 for sure. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 14:45: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CEA9937BCE5 for ; Mon, 24 Jul 2000 14:45:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA26565; Mon, 24 Jul 2000 14:41:49 -0700 Date: Mon, 24 Jul 2000 14:41:14 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: Jack Rusher , freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-Reply-To: <7888.964474163@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, that's why I rolled it out here - to get a taste test. I'll do a prototype- maybe in a week or so- and then announce some diffs and we'll see whether it causes a group gag reflex then. On Mon, 24 Jul 2000, Poul-Henning Kamp wrote: > In message , Matthe > w Jacob writes: > > >Again- I think that this and the full devfs is a usable methodology. I still > >would like some feedback as to whether or not linking mount (and mt, e.g.) > >with libcam so I can use device VPD info or WWNs would be just too awful for > >FreeBSD. This way it can be used now, without vinum. > > Sounds awful to me, but I guess it depends a lot on the implementation. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 15:12:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 49E5337BD04 for ; Mon, 24 Jul 2000 15:12:06 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 25695 invoked from network); 24 Jul 2000 22:12:01 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 24 Jul 2000 22:12:01 -0000 Message-ID: <397CBF31.BABAB0F8@integratus.com> Date: Mon, 24 Jul 2000 15:12:01 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > It wasn't meant to be exclusionary- just additive. And the WWN and VPD > serial number are alternate methods, both possibly qualified by lun. This seems perfectly sensible. I am interested to see if there will be some method to give a common access method (excuse the pin) that solves both sets of requirements (abstract and direct). This is one of the areas in which FreeBSD can really step ahead of the other server OSs. > physical, while /dev names would be logical. I argued that /dev/sd[0..n] was > perfectly adequate in this model (rather than trying to encode position > information into the name as the /dev/[r]dsk names do). Furthermore, naming The c0d0t0s0 naming convention is a funny idea, I agree. It is sort of worst of both worlds. :-) > disks (at least) by volume name (the "Fred" volume) is even more convenient. This is a nice feature. Do we want all three things (physical, logical, and name) as potential disk ids? If so, how do you tell the tools which name space you are working in? Some sort of accesor character before the "name"? Search order? What about duplicates (i.e. someone names the disk "sd0")? > I'd much rather see some framework in FreeBSD (and NetBSD and OpenBSD.... > Linux has a devfs going...) to accomodate this. But that isn't there yet and > won't be for a while. I want to solve this for 5.0 for sure. Some of the implementation details of the JINI model are pretty hairy. It would be pretty wasteful if that stuff had to end up in every driver. Something else that I would like to see done with devfs and procfs in the future of FreeBSD is the ability to unify these namespaces over several machines. There was some really good work done at SunLabs for a thing called Solaris MC that allowed single system image over a set of machines. They used a networked version of the ddi/devfs facility and added vprocs to the proc structure to allow one machine to address the processes and devices on another. This leads to some very nice parallel computation, load balancing, and HA implications. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 15:34: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id AEEF937BD7B for ; Mon, 24 Jul 2000 15:34:00 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA58508; Mon, 24 Jul 2000 16:31:41 -0600 (MDT) (envelope-from ken) Date: Mon, 24 Jul 2000 16:31:41 -0600 From: "Kenneth D. Merry" To: Matthew Jacob Cc: Poul-Henning Kamp , Jack Rusher , freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs Message-ID: <20000724163141.A58251@panzer.kdm.org> References: <6890.964465587@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Mon, Jul 24, 2000 at 02:25:32PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 24, 2000 at 14:25:32 -0700, Matthew Jacob wrote: > > Well, this doesn't address directly things like tape devices or ses instances > (e.g.)- basically anything that is SCSI or Fibre Channel addressable has some > kind of WWN or Serial Number for the device itself, but there is more or less > general consensus from linux to Veritas to here that an ondisk label (past > initial import) is the right thing to do. > > Again- I think that this and the full devfs is a usable methodology. I still > would like some feedback as to whether or not linking mount (and mt, e.g.) > with libcam so I can use device VPD info or WWNs would be just too awful for > FreeBSD. This way it can be used now, without vinum. I think that might be good for a first shot at it, but it might be nice to eventually have a way of dealing with more than just CAM-attached devices. e.g., you could have some sort of generic kernel registry/database/list that each peripheral driver instance would register itself with, along with a serial number of some sort. da0 would register its serial number of ABC138557232, and da1 would register its serial number of XyZ138475393, and ad0 would register its serial number of XLP83733312. You could have a name located in the disklabel take precendence over an in-disk serial number if it is present, and possibly have an automatically generated serial number to name table that is loaded in by the loader. So you could have a name for your tape drive, even though you can't put a disklabel on it. (Such a table might be generated by sysinstall, or by some other program.) You'd probably also want to have a way to include positional information as a qualifying argument for the case where you have more than one device with identical identifiers. So if you had two disks with the name "Fred" in the disklabel, you would need to call one "Fred@scbus0:1:0" and the other "Fred@scbus1:3:0". If you had two identical disklabel names, you could conceivably qualify them by the disk serial number, if available, but otherwise you'd have to fall back on the positional information. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 16:35:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 89D5A37B783 for ; Mon, 24 Jul 2000 16:35:24 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA26959; Mon, 24 Jul 2000 16:35:16 -0700 Date: Mon, 24 Jul 2000 16:34:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jack Rusher Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-Reply-To: <397CBF31.BABAB0F8@integratus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This seems perfectly sensible. I am interested to see if there will > be some method to give a common access method (excuse the pin) that > solves both sets of requirements (abstract and direct). This is one of > the areas in which FreeBSD can really step ahead of the other server > OSs. Yes, that's the idea there... :-) > > physical, while /dev names would be logical. I argued that /dev/sd[0..n] was > > perfectly adequate in this model (rather than trying to encode position > > information into the name as the /dev/[r]dsk names do). Furthermore, naming > > The c0d0t0s0 naming convention is a funny idea, I agree. It is sort > of worst of both worlds. :-) To quote Le Carre: "It was such a dull monument to such long and dreary war". > > > disks (at least) by volume name (the "Fred" volume) is even more convenient. > > This is a nice feature. Do we want all three things (physical, > logical, and name) as potential disk ids? If so, how do you tell the > tools which name space you are working in? Some sort of accesor > character before the "name"? Search order? What about duplicates (i.e. > someone names the disk "sd0")? Umm- that's the user's lookout, frankly. When you get to this level, you start to need a volume management GUI (and as someone who despises GUIs, it costs me dear to say that....) > > > I'd much rather see some framework in FreeBSD (and NetBSD and OpenBSD.... > > Linux has a devfs going...) to accomodate this. But that isn't there yet and > > won't be for a while. I want to solve this for 5.0 for sure. > > Some of the implementation details of the JINI model are pretty > hairy. It would be pretty wasteful if that stuff had to end up in every > driver. :-; > Something else that I would like to see done with devfs and procfs in > the future of FreeBSD is the ability to unify these namespaces over > several machines. There was some really good work done at SunLabs for a > thing called Solaris MC that allowed single system image over a set of > machines. They used a networked version of the ddi/devfs facility and > added vprocs to the proc structure to allow one machine to address the > processes and devices on another. This leads to some very nice parallel > computation, load balancing, and HA implications. Yes. But I'd like to solve the other problems first! ;-) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 24 16:48:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EAE7637B5B7 for ; Mon, 24 Jul 2000 16:48:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA26998; Mon, 24 Jul 2000 16:44:04 -0700 Date: Mon, 24 Jul 2000 16:43:28 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Poul-Henning Kamp , Jack Rusher , freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs In-Reply-To: <20000724163141.A58251@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think that might be good for a first shot at it, but it might be nice to > eventually have a way of dealing with more than just CAM-attached devices. > > e.g., you could have some sort of generic kernel registry/database/list > that each peripheral driver instance would register itself with, along > with a serial number of some sort. > > da0 would register its serial number of ABC138557232, and da1 would > register its serial number of XyZ138475393, and ad0 would register its > serial number of XLP83733312. > > You could have a name located in the disklabel take precendence over an > in-disk serial number if it is present, and possibly have an automatically > generated serial number to name table that is loaded in by the loader. So > you could have a name for your tape drive, even though you can't put a > disklabel on it. (Such a table might be generated by sysinstall, or by > some other program.) > > You'd probably also want to have a way to include positional information as > a qualifying argument for the case where you have more than one device with > identical identifiers. So if you had two disks with the name "Fred" in the > disklabel, you would need to call one "Fred@scbus0:1:0" and the other > "Fred@scbus1:3:0". > > If you had two identical disklabel names, you could conceivably qualify > them by the disk serial number, if available, but otherwise you'd have to > fall back on the positional information. All of this is good- and useful. Some of which is addressed in a full devfs. Some of which in possibly enhancing vinum. I'm looking right for a short term solution unless the others show up (which I haven't the time nor charter to chase). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 5:59:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from merc94.us.sas.com (merc94.us.sas.com [149.173.6.4]) by hub.freebsd.org (Postfix) with ESMTP id 3B7B037BB30 for ; Tue, 25 Jul 2000 05:59:28 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from merc94.us.sas.com ([127.0.0.1]) by merc94.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PDG9CXVW; Tue, 25 Jul 2000 08:59:26 -0400 Received: from 10.28.149.26 by merc94.us.sas.com (InterScan E-Mail VirusWall NT); Tue, 25 Jul 2000 08:59:26 -0400 (Eastern Daylight Time) Received: from tribble.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA23348; Tue, 25 Jul 2000 08:59:25 -0400 Received: from localhost (brdean@localhost) by tribble.unx.sas.com (8.9.3/8.9.1) with ESMTP id IAA51874; Tue, 25 Jul 2000 08:59:24 -0400 (EDT) (envelope-from brdean@unx.sas.com) X-Authentication-Warning: tribble.unx.sas.com: brdean owned process doing -bs Date: Tue, 25 Jul 2000 08:59:24 -0400 (EDT) From: Brian Dean To: freebsd-arch@freebsd.org Subject: isatty() reports false results Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Recently, while setting up a VPN using pppd to establish a link across an 'ssh' connection, I discovered that 'isatty()' will report that a pseudo-tty is not really a tty if the slave side of the master/slave pair has not yet been opened. This is due to the logic in kern/tty_pty.c, ptyioctl() where all but 4 ioctl's return EAGAIN if the slave side of the connection has not yet been opened. The flaw in 'isatty()' is that it calls 'tcgetattr()', but only checks for a -1 return code, and ignores the errno to determine the true cause of the error return. My approach to fixing this is to make 'isatty()' a little smarter utilizing the following logic (WARNING - an untested patch follows [it will be fully tested before being committed]): Index: isatty.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/isatty.c,v retrieving revision 1.3 diff -u -r1.3 isatty.c --- isatty.c 1998/06/09 08:32:23 1.3 +++ isatty.c 2000/07/25 02:56:04 @@ -52,7 +52,18 @@ #ifdef _THREAD_SAFE if (_FD_LOCK(fd, FD_READ, NULL) == 0) { #endif - retval = (tcgetattr(fd, &t) != -1); + if (tcgetattr(fd, &t) == -1) { + /* + * check for pty controller open, but tty + * slave not yet open + */ + if (errno == EAGAIN) + retval = 1; + else + retval = 0; + } + else + retval = 1; #ifdef _THREAD_SAFE _FD_UNLOCK(fd, FD_READ); } else { My question - does anyone know if this logic will break anything else, i.e., a case where a call to 'tcgetattr()' with a descriptor that *does not* refer to a tty will return EAGAIN? I haven't seen anything that does so; the pseudo-tty driver seems to be unique in this regard, so I'm thinking this change should fix 'isatty()' and not break anything else in the process (famous last words :)). Lastly, any suggestions for a better alternative? Thanks, -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 11: 5:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id BC1AD37B7A2; Tue, 25 Jul 2000 11:05:46 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id MAA46146; Tue, 25 Jul 2000 12:05:45 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200007251805.MAA46146@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: wilko@FreeBSD.ORG Cc: Matthew Jacob , freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: Your message of "Fri, 21 Jul 2000 23:39:03 +0200." <20000721233903.A21976@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 2000 12:06:32 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >So, I think it would be nice if 128 bit WWN could also be handled. Well, don't call it a WWN. Call it, perhaps, a "devid". Make the specification of what exactly a "devid" is flexible so it can be composed for non-SCSI devices, and you are on the right track. 128bits may be too small for some types of devices or if you want to add other information besides the WWN to the "devid". "devids" should not be exported through libcam, but through a more generic interface. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 12:13:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 78C4037BBF2 for ; Tue, 25 Jul 2000 12:13:34 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA30479; Tue, 25 Jul 2000 12:13:31 -0700 Date: Tue, 25 Jul 2000 12:13:34 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <200007251805.MAA46146@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG But there is a fully qualified 128 bit WWN. It's type 6, and it's in page 0x83 of VPD info for Inquiry in SPC2. On Tue, 25 Jul 2000, Justin T. Gibbs wrote: > >So, I think it would be nice if 128 bit WWN could also be handled. > > Well, don't call it a WWN. Call it, perhaps, a "devid". Make the > specification of what exactly a "devid" is flexible so it can be > composed for non-SCSI devices, and you are on the right track. > 128bits may be too small for some types of devices or if you want to > add other information besides the WWN to the "devid". > > "devids" should not be exported through libcam, but through a more > generic interface. > > -- > Justin > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 12:27:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 2F62A37BD77 for ; Tue, 25 Jul 2000 12:27:23 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id NAA48018; Tue, 25 Jul 2000 13:27:19 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200007251927.NAA48018@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: "Justin T. Gibbs" , freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: Your message of "Tue, 25 Jul 2000 12:13:34 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 2000 13:28:06 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >But there is a fully qualified 128 bit WWN. It's type 6, and it's in page 0x83 >of VPD info for Inquiry in SPC2. But not all devices are SCSI and not all SCSI devices have WWNs, so calling the FreeBSD representation of a virtual device identifier a WWN will lead to confusion when the identifier doesn't come from a WWN. The CAM3 spec talks a bit about virtual device identifiers and leaves it up to the implementer to decide what data is appropriate to make it unique. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 12:41:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B815237BFA5 for ; Tue, 25 Jul 2000 12:41:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA30664; Tue, 25 Jul 2000 12:41:10 -0700 Date: Tue, 25 Jul 2000 12:41:13 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <200007251927.NAA48018@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Jul 2000, Justin T. Gibbs wrote: > > > >But there is a fully qualified 128 bit WWN. It's type 6, and it's in page 0x83 > >of VPD info for Inquiry in SPC2. > > But not all devices are SCSI and not all SCSI devices have WWNs, so > calling the FreeBSD representation of a virtual device identifier > a WWN will lead to confusion when the identifier doesn't come from > a WWN. The CAM3 spec talks a bit about virtual device identifiers > and leaves it up to the implementer to decide what data is appropriate > to make it unique. Oh- I see what you mean. Let me reiterate or try to make clear what I was saying before: I'm not trying to make a completely generic solution here. I'm trying to get something that isn't *too* egregious that will solve problems right now with respect to shuffling attachments of SCSI and Fibre Channel disks. Something that can ship in the next release. Thus I was not trying to solve the virtual ID problem as a generic. This is also why the semantics in fstab have that ugly OSF/1 style look of, e.g.: wwn@0x21000000abcdef01,0 /space ufs rw 1 2 vpdsn@"LF10234 Seagate",0 /space1 ufs rw 1 2 which makes the identifier being used unambiguous (whether folks get confused even with this is a separate issue...!). The correct, long term solution, like the Solaris "all-singing, all-dancing" devfs, may take years to be correctly designed and agreed to before it comes out (it already has). With incredible respect for all the people involved in that, I have to say I (and FreeBSD) needs something *now*. This is always a balancing act. Linux probably leans too close to the 'now'- which is why they have to do major system rewrites every 6-9 months. NetBSD leans far too close to the "get it complete 'right' first!' end- which has it's own problems. I'm hoping that FreeBSD can fit between these extremes. -matt P.S.: for bonus points, who out there who knows where I've worked and what evil I've foisted on the world (he gleefully rubs his hands) can identify a similar naming scheme to the one proposed above and where it currently is quite contentedl being used (well, being used) by (literally) thousands of NT, Solaris, IRIX, SunOS, and AIX users (might be a few more platforms by now)? -mat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 12:43: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 60FD337B924 for ; Tue, 25 Jul 2000 12:42:57 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA13765; Tue, 25 Jul 2000 21:42:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Justin T. Gibbs" Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 13:28:06 MDT." <200007251927.NAA48018@pluto.plutotech.com> Date: Tue, 25 Jul 2000 21:42:22 +0200 Message-ID: <13763.964554142@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007251927.NAA48018@pluto.plutotech.com>, "Justin T. Gibbs" write s: >> >>But there is a fully qualified 128 bit WWN. It's type 6, and it's in page 0x83 >>of VPD info for Inquiry in SPC2. > >But not all devices are SCSI and not all SCSI devices have WWNs, so >calling the FreeBSD representation of a virtual device identifier >a WWN will lead to confusion when the identifier doesn't come from >a WWN. The CAM3 spec talks a bit about virtual device identifiers >and leaves it up to the implementer to decide what data is appropriate >to make it unique. In my mind it would make more sense to make an API to examine the disklabels (of various sorts) and pick the "FreeBSD device identifier" from there. That way all devices, SCSI, ATA, IDE, RAID, Flash and so on can be handled. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 12:51:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3007437B86E for ; Tue, 25 Jul 2000 12:51:26 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA30744; Tue, 25 Jul 2000 12:50:59 -0700 Date: Tue, 25 Jul 2000 12:51:01 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <13763.964554142@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In my mind it would make more sense to make an API to examine the > disklabels (of various sorts) and pick the "FreeBSD device identifier" > from there. > > That way all devices, SCSI, ATA, IDE, RAID, Flash and so on can be > handled. For devices that have been so labelled, yes, and that the label in question can be written to the device media (or stored in the device). This means that you have an import step. Not the worst thing in the world, but it does indeed restrict usage and sharing on a SAN- you can't rewrite the 50 NT volume labels on the SAN to find a FreeBSD identifier. And ocmpanies won't use FreeBSD if that is what we will require (this, I in fact, *do* know from stuff at Veritas- ask me some time what hacks that have to happen to make sure, when exporting volumes in target mode, you have to take to make sure that NT doesn't emit it's love label all over your FreeBSD volumes!). As I've said- I would like to have what you propose available. I would prefer it. But I also would like to solve directly addressing via immutable hardware properties (which vary as to type from device to device) direct access to some devices. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 13: 0:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id D63D837B86E for ; Tue, 25 Jul 2000 13:00:12 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA13951; Tue, 25 Jul 2000 22:00:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 12:51:01 PDT." Date: Tue, 25 Jul 2000 22:00:05 +0200 Message-ID: <13949.964555205@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthew Jacob writes: > >> In my mind it would make more sense to make an API to examine the >> disklabels (of various sorts) and pick the "FreeBSD device identifier" >> from there. >> >> That way all devices, SCSI, ATA, IDE, RAID, Flash and so on can be >> handled. > >For devices that have been so labelled, yes, and that the label in question >can be written to the device media (or stored in the device). This means that >you have an import step. Not the worst thing in the world, but it does indeed >restrict usage and sharing on a SAN- you can't rewrite the 50 NT volume labels >on the SAN to find a FreeBSD identifier. Ahh, but if they are NT volumes, the are unlikely to be UFS filesystems, and in that case I'm sure we would simply adopt the NT labels, no ? Maybe the solution here is that each device and indeed partition can have multiple labels, and any one of those are good enough for /etc/fstab ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 13:42: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4479C37B8CA for ; Tue, 25 Jul 2000 13:42:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA30935; Tue, 25 Jul 2000 13:38:25 -0700 Date: Tue, 25 Jul 2000 13:37:46 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <13949.964555205@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> handled. > > > >For devices that have been so labelled, yes, and that the label in question > >can be written to the device media (or stored in the device). This means that > >you have an import step. Not the worst thing in the world, but it does indeed > >restrict usage and sharing on a SAN- you can't rewrite the 50 NT volume labels > >on the SAN to find a FreeBSD identifier. > > Ahh, but if they are NT volumes, the are unlikely to be UFS filesystems, > and in that case I'm sure we would simply adopt the NT labels, no ? What if they're 'no' labels? You can do newfs -t ufs da0 SIZE right? You don't *need* to have a label.... > Maybe the solution here is that each device and indeed partition can > have multiple labels, and any one of those are good enough for /etc/fstab ? What I want is labels. But also what I want is a property that doesn't depend on writing anything on the device media itself. It's stretching it a bit, but not too far, to say I want to have cd9660 persistently addressable volumes. I may not know, from session to session, the contents actual ISO volume label. And I can't write anything to it. But the device itself has a persistent property of (VPD info Drive Serial number, or WWN in the Fibre Channel case (say)). Why can't I choose to track that particular device (part of one of those huge Sanyo CD changers, say...) by the non-label persistent identifier and not have to worry about the bus address changes? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 13:47:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 80FA537B864 for ; Tue, 25 Jul 2000 13:47:50 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA14273; Tue, 25 Jul 2000 22:47:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 13:37:46 PDT." Date: Tue, 25 Jul 2000 22:47:42 +0200 Message-ID: <14271.964558062@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Maybe the solution here is that each device and indeed partition can >> have multiple labels, and any one of those are good enough for /etc/fstab ? > >What I want is labels. But also what I want is a property that doesn't depend >on writing anything on the device media itself. I guess my terminology is too lose here. What I had in mind were a way in which any particular physical (or logical) "storage area" (to put it on the most general footing possible) can register a number of "aliases" for their device-driver-newbus-whatever name. Ie: My /dev/ad0 could have the following "aliases": /dev/ad0 "IBM SOMETHING Serial# 4958393453" (found in ATA pages) "Scratch disk 1" (found in bsd disklabel) "/mnt/scratch" (found in UFS "last mount point") and I could use any one of these in my /etc/fstab -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 13:53:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E233337B916 for ; Tue, 25 Jul 2000 13:53:33 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA31014; Tue, 25 Jul 2000 13:53:19 -0700 Date: Tue, 25 Jul 2000 13:52:39 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <14271.964558062@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ie: > > My /dev/ad0 could have the following "aliases": > > /dev/ad0 > "IBM SOMETHING Serial# 4958393453" (found in ATA pages) > "Scratch disk 1" (found in bsd disklabel) > "/mnt/scratch" (found in UFS "last mount point") > > and I could use any one of these in my /etc/fstab Yes. That's the ticket- although with that model you may stub your toe with a programmer's metonymy (mistaking the container for the thing contained). Were you thinking it could be that freeform? That is, not have any selectors to qualify as to how the name might be decoded? So you'd just look it up in a database? This raises the question as to whether this database is dynamic and who maintains it. This does fit more with a real devfs tho.... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14: 4:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id B7EF337B949 for ; Tue, 25 Jul 2000 14:04:18 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 10391 invoked from network); 25 Jul 2000 21:04:18 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 25 Jul 2000 21:04:18 -0000 Message-ID: <397E00D2.1F736032@integratus.com> Date: Tue, 25 Jul 2000 14:04:18 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > Were you thinking it could be that freeform? That is, not have any selectors > to qualify as to how the name might be decoded? So you'd just look it up > in a database? This raises the question as to whether this database is > dynamic and who maintains it. I fear the potential for a /etc/mnttab style mistake in the context of this kind of database. There are definitely some issues as to how this would be maintained and what sort of interface would be involved. Also, from a user interface perspective, how do you describe what domain the alias belongs to? If you decide not to, do you just set a fixed search order and go with the first match? Do we end up with a nsswitch.conf style file that gives order instructions? An /etc/hosts style table of name translations? Eek. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14: 7:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 393CB37BA0A for ; Tue, 25 Jul 2000 14:07:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA14393; Tue, 25 Jul 2000 23:07:17 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 13:52:39 PDT." Date: Tue, 25 Jul 2000 23:07:17 +0200 Message-ID: <14391.964559237@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthe w Jacob writes: > >> Ie: >> >> My /dev/ad0 could have the following "aliases": >> >> /dev/ad0 >> "IBM SOMETHING Serial# 4958393453" (found in ATA pages) >> "Scratch disk 1" (found in bsd disklabel) >> "/mnt/scratch" (found in UFS "last mount point") >> >> and I could use any one of these in my /etc/fstab > >Yes. That's the ticket- although with that model you may stub your toe with a >programmer's metonymy (mistaking the container for the thing contained). > >Were you thinking it could be that freeform? That is, not have any selectors >to qualify as to how the name might be decoded? So you'd just look it up in a >database? This raises the question as to whether this database is dynamic and >who maintains it. Yes, I think it should be just "ascii string" and the various sources of these strings prefix themselves with a suitable identifier, so the above would probably be: "/dev/ad0" "canonical device names" are prefixed with a slash "HW:IBM SOMETHING Serial# 4958393453" "BSD:Scratch disk 1" "MNT:/mnt/scratch" or something in that spirit. I'm not sure allowing spaces is a good idea, so maybe they should just silently be turned into underscore. >This does fit more with a real devfs tho.... Right, it sure does. I don't know if you followed some of the recent discussions about DEVFS, but one of my ideas is that cloning be implemented so that if the DEVFS doesn't find the name somebody tries to namei(), it will poll a list of driver functions (registered by the drivers) and if any of the drivers can instatiate the requested name they do so and the lookup succeeds from there. Doing it that way with a devfs means that you could actually open /dev/HW:BLABLA and if the cam driver recognized this as it's cue to examine the SCSI serial numbers it would do so and if it found one matching it would instantiate the device and your open would succeed. The advantage to that scheme is that we don't clutter /dev with 7 different names for each disk, only the names people try to open are present. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:17:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 48DEF37B949 for ; Tue, 25 Jul 2000 14:17:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA31140; Tue, 25 Jul 2000 14:14:28 -0700 Date: Tue, 25 Jul 2000 14:13:49 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <14391.964559237@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure allowing spaces is a good idea, so maybe they should > just silently be turned into underscore. Drive serial numbers are, sigh, ASCII strings with spaces..... Personally, I'd like to see the name more strongly defined. We already require in fstab a strong definition of what the content is (filesystem type 'zot'). We require a mount point. We have an inadequate but strong definition of the device to associate with the mount point with the filesystem of type 'zot'. I'd propose that the device definition could be fuzzier but still needs defined selectors to avoid overlap and chaos. > >This does fit more with a real devfs tho.... > > Right, it sure does. > > I don't know if you followed some of the recent discussions about > DEVFS, but one of my ideas is that cloning be implemented so that > if the DEVFS doesn't find the name somebody tries to namei(), it > will poll a list of driver functions (registered by the drivers) > and if any of the drivers can instatiate the requested name they > do so and the lookup succeeds from there. > > Doing it that way with a devfs means that you could actually > open /dev/HW:BLABLA and if the cam driver recognized this as > it's cue to examine the SCSI serial numbers it would do so > and if it found one matching it would instantiate the device > and your open would succeed. > > The advantage to that scheme is that we don't clutter /dev > with 7 different names for each disk, only the names people > try to open are present. Hmmmmm ... Ehrrmmmm.... Ummm..... Okay- then you'll get the same feel as the automounter gives when you do an ls of '/net/freefall.freebsd.org'- a bit of a hang as this occurs and requires any actual probing. This better only be done via a policy setting. Otherwise, the devices have to return their last 'best information' about whether they can get at that device. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:22:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id DE5A337BBEF for ; Tue, 25 Jul 2000 14:22:21 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA14497; Tue, 25 Jul 2000 23:22:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 14:13:49 PDT." Date: Tue, 25 Jul 2000 23:22:09 +0200 Message-ID: <14495.964560129@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthe w Jacob writes: >> >This does fit more with a real devfs tho.... >> >> Right, it sure does. >> >> I don't know if you followed some of the recent discussions about >> DEVFS, but one of my ideas is that cloning be implemented so that >> if the DEVFS doesn't find the name somebody tries to namei(), it >> will poll a list of driver functions (registered by the drivers) >> and if any of the drivers can instatiate the requested name they >> do so and the lookup succeeds from there. >> >> Doing it that way with a devfs means that you could actually >> open /dev/HW:BLABLA and if the cam driver recognized this as >> it's cue to examine the SCSI serial numbers it would do so >> and if it found one matching it would instantiate the device >> and your open would succeed. >> >> The advantage to that scheme is that we don't clutter /dev >> with 7 different names for each disk, only the names people >> try to open are present. > >Hmmmmm ... Ehrrmmmm.... Ummm..... > >Okay- then you'll get the same feel as the automounter gives when you do an ls >of '/net/freefall.freebsd.org'- a bit of a hang as this occurs and requires >any actual probing. No, there will not be a hang. The "ls /dev" will return only the currently instantiated names. Think about the PTY driver. The ls should only show the PTY's actually in use, not the potential 2000 ptys of the system. In the same way, if we did it my way, all the serial numbers and all that would not appear in the ls, until you had actually open(2)'ed a device using that name. Ie: # ls /dev/HW* # disklabel /dev/HW:BLABLA__2983942394 > /dev/null # ls /dev/HW* /dev/HW:BLABLA__2983942394 # The Delay happens for the disklabel command, which is the one which tries to use a non-instantiated name. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:31:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 22A3A37B6A1 for ; Tue, 25 Jul 2000 14:31:16 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA31193; Tue, 25 Jul 2000 14:31:06 -0700 Date: Tue, 25 Jul 2000 14:30:27 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <14495.964560129@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >Okay- then you'll get the same feel as the automounter gives when you do an ls > >of '/net/freefall.freebsd.org'- a bit of a hang as this occurs and requires > >any actual probing. > > No, there will not be a hang. The "ls /dev" will return only the currently > instantiated names. Think about the PTY driver. The ls should only > show the PTY's actually in use, not the potential 2000 ptys of the system. Okay- that I understand. > In the same way, if we did it my way, all the serial numbers and all > that would not appear in the ls, until you had actually open(2)'ed > a device using that name. Ie: > .... Okay. This I would find do-able. That's the real devfs then. A related problem is how to device discovery so you would know what name to give to disklabel or to put in /etc/fstab- but that's a separate discussion. Which then brings me back to where I came in the middle of this film- if this is gonna happen for FreeBSD 5.0 for sure, then I don't need to do the partial solution. I'm sure that there's much much much more discussion that needs to occur. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:33: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 07A6A37B999 for ; Tue, 25 Jul 2000 14:32:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA14569; Tue, 25 Jul 2000 23:32:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 14:30:27 PDT." Date: Tue, 25 Jul 2000 23:32:51 +0200 Message-ID: <14567.964560771@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthe w Jacob writes: >Okay. This I would find do-able. That's the real devfs then. A related >problem is how to device discovery so you would know what name to give to >disklabel or to put in /etc/fstab- but that's a separate discussion. > >Which then brings me back to where I came in the middle of this film- if this >is gonna happen for FreeBSD 5.0 for sure, then I don't need to do the partial >solution. I'm sure that there's much much much more discussion that needs to >occur. If I can do anything about it: Yes, a real devfs will be in 5.0. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:36:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 8B66437BAF4 for ; Tue, 25 Jul 2000 14:36:23 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 11614 invoked from network); 25 Jul 2000 21:36:21 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 25 Jul 2000 21:36:21 -0000 Message-ID: <397E0855.CEC23FF@integratus.com> Date: Tue, 25 Jul 2000 14:36:21 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? References: <14495.964560129@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > # ls /dev/HW* > # disklabel /dev/HW:BLABLA__2983942394 > /dev/null > # ls /dev/HW* > /dev/HW:BLABLA__2983942394 What is the suggested interface for listing the available (but not currently in use) devices? In the normal /dev way of looking at things, you can get a listing of device names from the directory namespace. Where does that info live in this scheme? -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:40:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 8612E37B9C8 for ; Tue, 25 Jul 2000 14:40:44 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA14655; Tue, 25 Jul 2000 23:40:30 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jack Rusher Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Tue, 25 Jul 2000 14:36:21 PDT." <397E0855.CEC23FF@integratus.com> Date: Tue, 25 Jul 2000 23:40:30 +0200 Message-ID: <14653.964561230@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <397E0855.CEC23FF@integratus.com>, Jack Rusher writes: >Poul-Henning Kamp wrote: >> >> # ls /dev/HW* >> # disklabel /dev/HW:BLABLA__2983942394 > /dev/null >> # ls /dev/HW* >> /dev/HW:BLABLA__2983942394 > > What is the suggested interface for listing the available (but not >currently in use) devices? In the normal /dev way of looking at things, >you can get a listing of device names from the directory namespace. >Where does that info live in this scheme? You can still get a listing of the "canonical" names like "/dev/ad0", "/dev/ad0s1c" and so on. It is only "potential names" which are not listed until they have been instantiated. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 14:43:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id DECBA37BA8D for ; Tue, 25 Jul 2000 14:43:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA31261; Tue, 25 Jul 2000 14:42:56 -0700 Date: Tue, 25 Jul 2000 14:42:16 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jack Rusher Cc: Poul-Henning Kamp , freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <397E0855.CEC23FF@integratus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > # disklabel /dev/HW:BLABLA__2983942394 > /dev/null > > # ls /dev/HW* > > /dev/HW:BLABLA__2983942394 > > What is the suggested interface for listing the available (but not > currently in use) devices? In the normal /dev way of looking at things, > you can get a listing of device names from the directory namespace. > Where does that info live in this scheme? ad hoc, even as it is now- 'camcontrol devlist' and parsing dmesg output. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 15: 0:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 9E1F837B638 for ; Tue, 25 Jul 2000 15:00:18 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 12626 invoked from network); 25 Jul 2000 22:00:18 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 25 Jul 2000 22:00:18 -0000 Message-ID: <397E0DF2.FDC595C5@integratus.com> Date: Tue, 25 Jul 2000 15:00:18 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? References: <14653.964561230@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > You can still get a listing of the "canonical" names like "/dev/ad0", > "/dev/ad0s1c" and so on. > > It is only "potential names" which are not listed until they have > been instantiated. Um... forgive me if this is obvious and the cough syrup I had this morning is weighing me down, but how do you know to which object (by which I mean storage device, partition, etc) the "canonical" name points to? Matthew Jacob wrote: > > ad hoc, even as it is now- 'camcontrol devlist' and parsing dmesg output. This is what I was afraid of. It strikes me that this sort of sucks, and that there really should be a better way. This is the sort of thing that a devfs is meant to make go away, isn't it? -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 15:38:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C98D037BAA3 for ; Tue, 25 Jul 2000 15:38:19 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA31435; Tue, 25 Jul 2000 15:38:13 -0700 Date: Tue, 25 Jul 2000 15:37:33 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jack Rusher Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <397E0DF2.FDC595C5@integratus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Matthew Jacob wrote: > > > > ad hoc, even as it is now- 'camcontrol devlist' and parsing dmesg output. > > This is what I was afraid of. It strikes me that this sort of sucks, Yes. > and that there really should be a better way. This is the sort of thing > that a devfs is meant to make go away, isn't it? No- not really. A devfs should allow one to dynamically bind a meaningful name to a device- so you don't get stuck with inodes on disk that don't point to what you think the name in /dev (which is what you use in /etc/fstab or other apps) points to. Complete discovery of all potential devices that can then be instantiated in /dev is a related but separate problem. Why is this so? Well, it's so because it makes the problem set more manageable. The list of all possible devices that can be instantiated is related to which drivers you have loaded. But the loading of drivers in order to know whether to really instantiate a node in /dev is related to information held possibly by *another* driver (one which may not be a 'device', and, unlike the assumptions of the Solaris model of nexus drivers, may not have an obligate parent relationship). That is to say, the devfs that I believe is being considered here is not the hierarchical model that Solaris uses. That being the case, it has no reason to try and represent the hierarchical device tree topology (as does the Solaris model). If that is true, then the entities in the FreeBSD devfs are not the exhaustive current list of all possible known devices, and information about *what* to try and instantiate has to come from another mechanism. The suggestions of 'camcontrol' and 'dmesg' are just to illustrate that there's another big problem to solve after devfs. [ I'm sure Poul && Julian && others will correct me smartly if I've misunderstood or misrepresented the current devfs intents/design ] -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 17:27:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id CFAB937BC6A for ; Tue, 25 Jul 2000 17:27:30 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id CAA69391; Wed, 26 Jul 2000 02:35:07 +0200 (CEST) (envelope-from adrian) Date: Wed, 26 Jul 2000 02:35:06 +0200 From: Adrian Chadd To: Matthew Jacob Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000726023506.A68912@ywing.creative.net.au> References: <397E0DF2.FDC595C5@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Tue, Jul 25, 2000 at 03:37:33PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 25, 2000, Matthew Jacob wrote: > > Matthew Jacob wrote: > > > > > > ad hoc, even as it is now- 'camcontrol devlist' and parsing dmesg output. > > > > This is what I was afraid of. It strikes me that this sort of sucks, > > Yes. > > > and that there really should be a better way. This is the sort of thing > > that a devfs is meant to make go away, isn't it? > > No- not really. A devfs should allow one to dynamically bind a meaningful name > to a device- so you don't get stuck with inodes on disk that don't point to > what you think the name in /dev (which is what you use in /etc/fstab or other > apps) points to. > > Complete discovery of all potential devices that can then be instantiated in > /dev is a related but separate problem. > > Why is this so? Well, it's so because it makes the problem set more > manageable. The list of all possible devices that can be instantiated is > related to which drivers you have loaded. But the loading of drivers in order > to know whether to really instantiate a node in /dev is related to information > held possibly by *another* driver (one which may not be a 'device', and, > unlike the assumptions of the Solaris model of nexus drivers, may not have an > obligate parent relationship). Right, so if I understand all this discussion right, you want to be able to take a name which can represent a changing target, and present that in devfs, correct? Being totally naieve(sp?) here, but why can't you just tie in the devfs namei() into newbus somehow? Is there any reason why you can't have some form of device hierarchy inside /dev besides the (mostly) flat namespace that already exists? Think things like vinum. I like the /dev/vinum/volumename abstraction. If you are doing Fibrechannel stuff (which I'll admit I know *nothing* about) and you want to be able to reference a target which could possibly change between reboots, why not just have the CAM subsystem register /dev/scsi/ with devfs, and handle things itself in there? Or, you could abstract it further, and have /dev/disklabel/ and let the disklabel code handle mapping a name to a device? I think this is what phk mentioned earlier about polling a list of drivers, I'd just like to bring the concept out into the open more for discussion. Adrian -- Adrian Chadd Now 17-year-olds can't play a _video game_ because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 19: 0:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 747CF37B56C for ; Tue, 25 Jul 2000 19:00:33 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 61A5528FD1; Wed, 26 Jul 2000 09:00:29 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 4A47F28F50; Wed, 26 Jul 2000 09:00:29 +0700 (ALMST) Date: Wed, 26 Jul 2000 09:00:29 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <14391.964559237@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Jul 2000, Poul-Henning Kamp wrote: > I don't know if you followed some of the recent discussions about > DEVFS, but one of my ideas is that cloning be implemented so that :) > if the DEVFS doesn't find the name somebody tries to namei(), it > will poll a list of driver functions (registered by the drivers) > and if any of the drivers can instatiate the requested name they > do so and the lookup succeeds from there. [skip] > The advantage to that scheme is that we don't clutter /dev > with 7 different names for each disk, only the names people > try to open are present. This might be overriden by device driver if it wishes to make all known aliases visible. I've played a bit with this at the beginning of this year, and found that seeing both /dev/ad1s2a and /dev/testdisk:a (the second is a hardlink to the first) is very useful. Current slice code needs to be tweaked slightly to handle this, but better it needs to be rewritten. CVS logs shows that Julian tried to do that, but code and related comments was removed for some reason. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 23:42:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 49B9337B697; Tue, 25 Jul 2000 23:42:39 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id XAA60024; Tue, 25 Jul 2000 23:42:39 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Jul 2000 23:42:39 -0700 (PDT) From: Kris Kennaway To: "Jeroen C. van Gelderen" Cc: arch@freebsd.org Subject: Re: Quantifying entropy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 22 Jul 2000, Kris Kennaway wrote: > Some interesting numbers: > > The shannon entropy of this sample as a pure probability distribution is > 8.50 bits/sample (they're 16-bit signed values). > > Compressing with gzip -9 and comparing the file sizes gives an entropy > estimate of 10.4 bits/sample. > > Compressing with bzip2 -9 gives an estimate of 7.90 bits/sample, > suggesting there is indeed some time-correlation in the signal noise. Actually I just worked out why bzip2 gave this result: bzip2 treats the data as an 8-bit source, and from that perspective my data has 7.92 bits of entropy per 16-bits :-) (because the spectrum is peaked around 320 (when interpreted as unsigned 16-bit quantities), every second byte is most likely to be an '00' or '01', thus skewing the 8-bit distribution) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 25 23:57:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7EA6E37BDE6; Tue, 25 Jul 2000 23:57:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id XAA61784; Tue, 25 Jul 2000 23:57:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 25 Jul 2000 23:57:53 -0700 (PDT) From: Kris Kennaway To: "Jeroen C. van Gelderen" , markm@freebsd.org Cc: arch@freebsd.org Subject: Estimating entropy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been looking for some good entropy estimation algorithms which are suitable for running "online", i.e. at runtime to estimate the content of a set of samples. I haven't had much success so far - the only two things I can think of are to keep a pool of the last n samples from a source, and then either: 1) gzip them and use the resulting compressed size * a multiplier (e.g. 0.5) to estimate the entropy. 2) Keep a frequency table and calculate or estimate the shannon entropy periodically. This may be feasible if we treat the samples as 8-bit sources, as you only have to loop over 256 values and calculate a log_2 of the probabilities (although lack of FP in the kernel would complicate this) However, the following paper looks interesting - I didnt read it in detail yet, but it may also be suitable. http://www.geocities.com/SiliconValley/Code/4704/universal.pdf It seems that any online (low-cost) estimation function is going to be easy to fool by feeding it low-entropy inputs designed to pass the tests. This is likely only a problem for entropy samples obtained from userland, if we were to allow untrusted processes to submit entropy which is given a non-zero weight. On the other hand, if we only allow "trusted" root processes to submit entropy with a non-zero weight then it should be okay. Any thoughts? Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 0:10:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 90F2237BA6B; Wed, 26 Jul 2000 00:10:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id AAA32551; Wed, 26 Jul 2000 00:10:47 -0700 Date: Wed, 26 Jul 2000 00:10:50 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adrian Chadd Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000726023506.A68912@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Right, so if I understand all this discussion right, you want to be able > to take a name which can represent a changing target, and present that > in devfs, correct? > > Being totally naieve(sp?) here, but why can't you just tie in the devfs > namei() into newbus somehow? Is there any reason why you can't have some > form of device hierarchy inside /dev besides the (mostly) flat namespace > that already exists? > > Think things like vinum. I like the /dev/vinum/volumename abstraction. If > you are doing Fibrechannel stuff (which I'll admit I know *nothing* about) > and you want to be able to reference a target which could possibly change > between reboots, why not just have the CAM subsystem register /dev/scsi/ > with devfs, and handle things itself in there? Or, you could abstract it > further, and have /dev/disklabel/ and let the disklabel > code handle mapping a name to a device? You could sort of do that too. You've described two organizational systems (disklabels, vinumvolumes) which are both valuable and persistent (once you make a disklabel and once you make a vinumvolume). Your other example isn't quite how things are working or what I'm getting at. If I have a pure parallel (SPI) SCSI disk device, I have something which is physically addressable as a (more formally, an ITLQ Nexus). This, depending on the order of other things around and, possibly, the forced binding in a config file, is then addressed by the system as the da device, unit N. But if you physically change the bus and or subtract other devices, that which was daN at one time is now daM. If I have a Fibre Channel device, it is emulating a SCSI disk device- that is, you still present to it as a Target, although the mechanism by which you map D_IDs and Ports to a 'Target' is substantantially virtual and different from Parallel SCSI. But the same issues apply as above, only more so. Inserting a device into an active causes all loop members to renegotiate their physical loop addresses (AL_PAs)- you're not guaranteed to re-acquire the one you had before. Thus your 'Target' can change while you're running. But the Qlogic driver handles this- at least while you're running by following the moved devices around based upon their WWN (see below on this). The point here I've been trying to make is that I can address and track both the parallel SCSI disk devices and the FC disk devices by parameters that are guaranteeed to be unique and that do *not* depend on the current physical bus address and do *not* depend on writing anything on the media. Disks (SCSI and FC) can be addressed by the Vital Product Data Serial # page. Fibre Channel devices can also be addressed by ther World Wide Name. Both are easy entities to get at (the Serial # stuff is already incorporated into CAM. The Qlogic driver already tracks WWNs- and just needs to propagate them upstream to be used). The namei actions in devfs could in fact parse a WWN or a VPD/Serial# name and do the right thing (look for it and find it on whichever SCSI bus or FC port it's one, whatever the current da instance number is). That'd be great. If you work with vinum, or wish to use disklabel on such volumes, then after you've imported things into vinum or used disklabel, you could also access such devices via the mechanisms you propose above. If you *don't* work with vinum, or don't/can't write disklabels, you still have a unique identifier by which to access the device that doesn't depend upon it's address at this moment. > I think this is what phk mentioned earlier about polling a list of drivers, > I'd just like to bring the concept out into the open more for discussion. It's more than drivers. It's also collection subsystems. What I really envision for Fibre Channel is an FC4 layer that each FC host adapter registers entities with (as a WWN,PortID,PortType)- these would be a one-to-many mapping because you could have access to the same device on multiple FC ports (particularly for fabrics). Right now this FC4 layer in FreeBSD lives solely in the portdb part of the fcparam part of the Qlogic driver's softc (see sys/dev/isp/ispvar.h, ~line 253), but hopefully we'll have a second FC solution for FreeBSD in 5.0 (I'm thinking about the LSI-Logic card)- in which case this info needs to be shared somewhere- and it's not really a CAM thingie because FC-IP (Fibre Channel-IP) entities can/will be there as well. Sorry- longwinded comment, but the point here is that this info doesn't and shouldn't fit into the 'driver to be polled' model. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 0:17:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 1C73A37B518; Wed, 26 Jul 2000 00:17:20 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id AAA65173; Wed, 26 Jul 2000 00:17:20 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 26 Jul 2000 00:17:19 -0700 (PDT) From: Kris Kennaway To: "Jeroen C. van Gelderen" , markm@freebsd.org Cc: arch@freebsd.org Subject: Re: Estimating entropy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Jul 2000, Kris Kennaway wrote: > I've been looking for some good entropy estimation algorithms which are > suitable for running "online", i.e. at runtime to estimate the content of > a set of samples. I haven't had much success so far - the only two things > I can think of are to keep a pool of the last n samples from a source, and > then either: I should add that these are general-purpose estimators. The previous /dev/random uses a higher-order timing differential to estimate time-based measurements, although I don't currently understand the reasoning behind the algorithm. Does anyone have pointers to the literature about this? Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 0:48:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id A4DEB37B955 for ; Wed, 26 Jul 2000 00:48:22 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id JAA70227; Wed, 26 Jul 2000 09:56:11 +0200 (CEST) (envelope-from adrian) Date: Wed, 26 Jul 2000 09:56:11 +0200 From: Adrian Chadd To: Matthew Jacob Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000726095611.B68912@ywing.creative.net.au> References: <20000726023506.A68912@ywing.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Wed, Jul 26, 2000 at 12:10:50AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 26, 2000, Matthew Jacob wrote: > You could sort of do that too. You've described two organizational systems > (disklabels, vinumvolumes) which are both valuable and persistent (once you > make a disklabel and once you make a vinumvolume). > > Your other example isn't quite how things are working or what I'm getting at. [snip fibre channel explanation bits, thanks!] > It's more than drivers. It's also collection subsystems. What I really > envision for Fibre Channel is an FC4 layer that each FC host adapter registers > entities with (as a WWN,PortID,PortType)- these would be a one-to-many mapping > because you could have access to the same device on multiple FC ports > (particularly for fabrics). Right now this FC4 layer in FreeBSD lives solely > in the portdb part of the fcparam part of the Qlogic driver's softc (see > sys/dev/isp/ispvar.h, ~line 253), but hopefully we'll have a second FC > solution for FreeBSD in 5.0 (I'm thinking about the LSI-Logic card)- in which > case this info needs to be shared somewhere- and it's not really a CAM thingie > because FC-IP (Fibre Channel-IP) entities can/will be there as well. > Sorry- longwinded comment, but the point here is that this info doesn't and > shouldn't fit into the 'driver to be polled' model. ok. There should not be a reason why you can't simply register your FC devices as '/dev/fc/$label' or even '/dev/$label' rather than '/dev/da1a'. A "true" devfs would not pretend to impose a "%s%d", majorstring, minorunit type namespace in front of all devices, and so neither should you. If you have a generic FC layer which handles mapping physical devices to logical devices, I can't see a problem here. Without understand how the disklabel code works, I then can't see a reason why a generic 'disklabel' layer can't be introduced for interested devices to supply their own label rather than be given da/ad -- and furthering that, register multiple device names for the same devsw. The addalias and friends in the existing VFS code will handle multiple namespace entries for the same device, which is what works right now. Have I missed anything? -- Adrian Chadd Now 17-year-olds can't play a _video game_ because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 0:53:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 4A73437B652; Wed, 26 Jul 2000 00:53:46 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id JAA16937; Wed, 26 Jul 2000 09:53:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Adrian Chadd Cc: Matthew Jacob , freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-reply-to: Your message of "Wed, 26 Jul 2000 09:56:11 +0200." <20000726095611.B68912@ywing.creative.net.au> Date: Wed, 26 Jul 2000 09:53:40 +0200 Message-ID: <16935.964598020@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000726095611.B68912@ywing.creative.net.au>, Adrian Chadd writes: >ok. There should not be a reason why you can't simply register your FC >devices as '/dev/fc/$label' or even '/dev/$label' rather than '/dev/da1a'. >A "true" devfs would not pretend to impose a "%s%d", majorstring, minorunit >type namespace in front of all devices, and so neither should you. >If you have a generic FC layer which handles mapping physical devices to >logical devices, I can't see a problem here. Devfs will give each device a "canonical name" and as many aliases as you like. The aliases will show up as symlinks. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 1:33:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id C77F437BE17; Wed, 26 Jul 2000 01:33:12 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA74633; Wed, 26 Jul 2000 01:33:12 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 26 Jul 2000 01:33:12 -0700 (PDT) From: Kris Kennaway To: "Jeroen C. van Gelderen" , markm@freebsd.org Cc: arch@freebsd.org Subject: Re: Estimating entropy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Jul 2000, Kris Kennaway wrote: > 2) Keep a frequency table and calculate or estimate the shannon entropy > periodically. This may be feasible if we treat the samples as 8-bit > sources, as you only have to loop over 256 values and calculate a log_2 of > the probabilities (although lack of FP in the kernel would complicate > this) I was thinking about this on the way home, and we can do a big optimisation here if we assume that the measurement have a gaussian distribution (which is probably fairly reasonable for most sources, at least to a first approximation). In that case we only need to know the mean and variance of the last n samples (e.g. stored in a circular buffer), which can be computed incrementally without having to do a full pass over the entire n samples each time, and the entropy has a simple closed-form solution. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 3:19:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (markm.ops.uunet.co.za [196.31.2.167]) by hub.freebsd.org (Postfix) with ESMTP id E637237B5F6; Wed, 26 Jul 2000 03:19:34 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id MAA00605; Wed, 26 Jul 2000 12:19:39 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007261019.MAA00605@grimreaper.grondar.za> To: Kris Kennaway Cc: arch@FreeBSD.org Subject: Re: Estimating entropy References: In-Reply-To: ; from Kris Kennaway "Tue, 25 Jul 2000 23:57:53 MST." Date: Wed, 26 Jul 2000 12:19:39 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1) gzip them and use the resulting compressed size * a multiplier (e.g. > 0.5) to estimate the entropy. Computationally expensive, but easy to do; the compressed data is also a half-decent way of getting the stuff into the pools, as it adds a layer of hashing/mixing. > 2) Keep a frequency table and calculate or estimate the shannon entropy > periodically. This may be feasible if we treat the samples as 8-bit > sources, as you only have to loop over 256 values and calculate a log_2 of > the probabilities (although lack of FP in the kernel would complicate > this) I have been looking for articles on Shannon entropy; all I can find is a theorem that covers ergodic systems. Do you have any online references? > However, the following paper looks interesting - I didnt read it in detail > yet, but it may also be suitable. > > http://www.geocities.com/SiliconValley/Code/4704/universal.pdf Thanks! > It seems that any online (low-cost) estimation function is going to be > easy to fool by feeding it low-entropy inputs designed to pass the tests. > This is likely only a problem for entropy samples obtained from userland, > if we were to allow untrusted processes to submit entropy which is given a > non-zero weight. On the other hand, if we only allow "trusted" root > processes to submit entropy with a non-zero weight then it should be okay. Sane. We need to "disconnect" as much of the entropy harvesting from the attacker as possible. The harvesting needs to use internal state where it can (that's why I want to hook namei()). Syscons is an exception; and I'd like to fix that (syscons can be "attacked" by (say) holding down a key). > > Any thoughts? > > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe > > -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 3:50:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 48F6D37BE2C; Wed, 26 Jul 2000 03:50:26 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id DAA96954; Wed, 26 Jul 2000 03:50:26 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 26 Jul 2000 03:50:26 -0700 (PDT) From: Kris Kennaway To: Mark Murray Cc: arch@FreeBSD.org Subject: Re: Estimating entropy In-Reply-To: <200007261019.MAA00605@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Jul 2000, Mark Murray wrote: > > 2) Keep a frequency table and calculate or estimate the shannon entropy > > periodically. This may be feasible if we treat the samples as 8-bit > > sources, as you only have to loop over 256 values and calculate a log_2 of > > the probabilities (although lack of FP in the kernel would complicate > > this) > > I have been looking for articles on Shannon entropy; all I can find > is a theorem that covers ergodic systems. Do you have any online > references? It's pretty simple: if you have an information source which outputs data with a given probability distribution p(x) (technically speaking a statistical ensemble of sources, in order to define the probability) then the entropy content is S = - \Int_x dx p(x) ln_2 p(x) Where \Int_x is an integral over x. If x is a discrete variable (as it is in most/all of the cases we'll be looking at) then replace \Int_x dx with \Sigma_x (i.e. sum over all possible output values) Basically, (Shannon) entropy is a measure (in bits) of how much information you learn by performing the measurement, given that some measurements are more likely than others and therefore not as much of a "surprise" (you probably knew this, but for the benefit of anyone else who might not..) It's also the absolute minimum length a given piece of data can be compressed to by a general-purpose, "perfect" compression algorithm, which is why gzip is a decent metric for it. The requirement about ergodic systems means basically that the way a single system behaves if you watch it for a long period of time is the same as a large number of identical systems (in different states) behave when observed at a single instant (the aformentioned statistical ensemble assumption). There's also another implicit assumption about a "stationary" distribution which basically means it's not time-varying: if you have a probability distribution which changes over time then shannon entropy will not be a true measure of the information content of the source, because it doesn't take into account temporal patterns which may decrease the actual information content. See the code I posted a few days ago for a C implementation which calculates the entropy of the PCM input which should make the above clearer. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 3:53:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id F1B2037BE2C; Wed, 26 Jul 2000 03:53:23 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id DAA97086; Wed, 26 Jul 2000 03:53:23 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 26 Jul 2000 03:53:23 -0700 (PDT) From: Kris Kennaway To: Mark Murray Cc: arch@FreeBSD.org Subject: Re: Estimating entropy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Jul 2000, Kris Kennaway wrote: > S = - \Int_x dx p(x) ln_2 p(x) log_2(p(x)) Oops. log_2 is of course the base-2 logarithm. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 4:15:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.ctimail3.com (main1.my3mail.com [203.80.96.151]) by hub.freebsd.org (Postfix) with ESMTP id 613A637BF23 for ; Wed, 26 Jul 2000 04:15:24 -0700 (PDT) (envelope-from July3@wsi-hk.com) Received: from oemcomputer27 (207user29.ctimail3.com [203.80.207.29]) by mail.ctimail3.com (8.9.3/8.9.3) with SMTP id TAA02259 for ; Wed, 26 Jul 2000 19:14:54 +0800 (HKT) Message-Id: <200007261114.TAA02259@mail.ctimail3.com> From: "Peter Forsythe" To: "freebsd-arch@freebsd.org" Date: Wed, 26 Jul 2000 19:11:00 +0800 Subject: Workplace English and Summer Specials Reply-To: July3@wsi-hk.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This email is an update of Hong Kong government's Workplace English Campaign, and of Wall Street Institute English specials for July. If you wish to be removed, or are not in Hong Kong, please click on remove@wsi-hk.com]. The Workplace English Campaign of the Hong Kong government is now in Phase II -- which is significantly more flexible than Phase I, including funding up to $HK4,500. We at Wall Street Institute have assisted over 500 individual applications. Please contact us if you would like to know how you or your colleagues benefit from this program -- 2575 6888. SUMMER SPECIALS: Those enrolling in July are eligible for THREE FREE MONTHS of English learning. Anyone enrolling in July can also take part in a draw to win a TWO WEEK TRIP to Toronto, Sydney or London, including accommodation. Phone us for more details (2575 6888) or fill in the form below and fax or email by return. Looking forward to hearing from you. Peter Forsythe Fax form to 2575 1999 or email to July@wsi-hk.com: ---------------------------------------------------------------- Please send me more information on WEC and Summer Specials: Name _____________________________ Address___________________________ Phone_____________________________ Fax_______________________________ ------------------------------------------------------------------ (For remove, put "remove" in subject line or click on remove@wsi-hk.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 11: 3:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B9D6C37BBAE; Wed, 26 Jul 2000 11:03:06 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA01774; Wed, 26 Jul 2000 11:03:06 -0700 Date: Wed, 26 Jul 2000 11:03:09 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adrian Chadd Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000726095611.B68912@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ok. There should not be a reason why you can't simply register your FC > devices as '/dev/fc/$label' or even '/dev/$label' rather than '/dev/da1a'. > A "true" devfs would not pretend to impose a "%s%d", majorstring, minorunit > type namespace in front of all devices, and so neither should you. > If you have a generic FC layer which handles mapping physical devices to > logical devices, I can't see a problem here. I don't have a problem other then the lack of existence of a devfs I can use today, no, I suppose not. I'd rather, as I keep saying, have both- certainly if there's any possibility of *not* having a devfs I can use soon. > > Without understand how the disklabel code works, I then can't see a reason > why a generic 'disklabel' layer can't be introduced for interested devices > to supply their own label rather than be given da/ad -- and furthering that, > register multiple device names for the same devsw. The addalias and friends > in the existing VFS code will handle multiple namespace entries for the > same device, which is what works right now. Well, okay, whatever.... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 14:45: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 0304337C057 for ; Wed, 26 Jul 2000 14:45:00 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 25689 invoked from network); 26 Jul 2000 21:44:54 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 26 Jul 2000 21:44:54 -0000 Message-ID: <397F5BD6.5104F1E4@integratus.com> Date: Wed, 26 Jul 2000 14:44:54 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > No- not really. A devfs should allow one to dynamically bind a meaningful > name to a device- so you don't get stuck with inodes on disk that don't > point to what you think the name in /dev (which is what you use in > /etc/fstab or other apps) points to. > > Complete discovery of all potential devices that can then be instantiated in > /dev is a related but separate problem. Hmm. I understand why you would want to divide and conquer on this problem, but it seems to me that you would want to do you top level design in a way that allows these things to coexist and be developed one at a time. From a "driver figures out what to load" perspective, I find it very useful to have drives hanging from a controller in a tree structure so that I can write tools that are able to intelligently figure out how to balance I/O over controllers. What is the win from avoiding a tree based device layout? Adrian Chadd's notion of a node under dev (say, /dev/fc0 for the first fibre channel controller) that returns listings of underlying devices (by sending queries to the drivers) has some potential merit. There is the chance, however, that I am thinking about things from too much of a Plan9 perspective. I just like the idea of using file system semantics for databases; especially with links to provide multiple names for a resource. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 17:50:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 1D51437BC5A for ; Wed, 26 Jul 2000 17:50:03 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 26676 invoked from network); 27 Jul 2000 00:49:58 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 27 Jul 2000 00:49:58 -0000 Date: Thu, 27 Jul 2000 10:49:55 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Brian Dean Cc: freebsd-arch@FreeBSD.ORG Subject: Re: isatty() reports false results In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Jul 2000, Brian Dean wrote: > My question - does anyone know if this logic will break anything else, > i.e., a case where a call to 'tcgetattr()' with a descriptor that > *does not* refer to a tty will return EAGAIN? I haven't seen anything Probably not. POSIX.1 says that tcgetattr() shall return EBADF for non- open files and ENOTTY for non-terminals. These are the only errors mentioned in POSIX.1. Returning EAGAIN is probably a bug. OTOH, checking for only EAGAIN is a bug if there are any other undocumented error returns. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 18:47:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 6C6AC37BF39 for ; Wed, 26 Jul 2000 18:47:35 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id SAA16199; Wed, 26 Jul 2000 18:47:34 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200007270147.SAA16199@beastie.mckusick.com> To: Andrzej Bialecki Subject: Re: SysctlFS Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: Your message of "Wed, 12 Jul 2000 14:45:10 +0200." <20000712144510.A11316@ywing.creative.net.au> Date: Wed, 26 Jul 2000 18:47:34 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Wed, 12 Jul 2000 14:45:10 +0200 From: Adrian Chadd To: Andrzej Bialecki Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS On Wed, Jul 12, 2000, Andrzej Bialecki wrote: > Hi, > > I've been tweaking the sysctls here and there for some time > now, and I'd like to see what is the current opinion on > implementing sysctl tree as a filesystem. Most of the work > I've done with dynamic sysctls is very similar to what > happens with filesystem. Also, filesystem model allows for > much more fine-grained access control. > If you are still interested in doing this, see `man kernfs' which is a prototype of a filesystem designed to show (and in some cases modify) kernel information. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 19: 2: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id B942F37BFD8 for ; Wed, 26 Jul 2000 19:02:03 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id TAA16258; Wed, 26 Jul 2000 19:01:58 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200007270201.TAA16258@beastie.mckusick.com> To: Peter Jeremy Subject: Re: Snapshots in the Fast Filesystem Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Mon, 17 Jul 2000 11:15:39 +1000." <00Jul17.111555est.115264@border.alcanet.com.au> Date: Wed, 26 Jul 2000 19:01:58 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Mon, 17 Jul 2000 11:15:39 +1000 From: Peter Jeremy Subject: Re: Snapshots in the Fast Filesystem In-reply-to: <200007060342.UAA23667@beastie.mckusick.com>; from mckusick@mckusick.com on Wed, Jul 05, 2000 at 08:42:18PM -0700 To: Kirk McKusick Cc: arch@FreeBSD.ORG On 2000-Jul-05 20:42:18 -0700, Kirk McKusick wrote: >I have completed an initial implementation of snapshots for the >fast filesystem (UFS/FFS). Thank you very much. Having used the snapshot mechanisms in Compaq's AdvFS, I can say that this will be wonderful. Having read the README that you committed, I have a few questions: Disk space overheads: Does creating a snapshot require any additional disk space? I realize that updates will require additional space for the `before' image, but what other metadata overheads are there? There is about a 0.1% disk space overhead to initially create a snapshot. Thus on a 10Gb filesystem, the initial snapshot will consume about 10Mb. Running out of space: Is there any special behaviour when an active FS with one or more snaphsots runs out of disk space? Does the (oldest?) snapshot become invalid to free up space, or is the behaviour indistinguishable from running out of space without snapshots? How does this interact with the UFS minfree boundary? I cheated on this one :-) I allow the snapshots to consume space from the minfree reserve. Once the limit is hit, most processes will die with filesystem full errors, so the rate of change on the filesystem comes to a halt. Speed: Is it possible to reduce the time during which FS activity is suspended? As you point out, one use for snapshots is doing point-in- time backups (I do this currently with Compaq Tru64 AdvFS filesystems). From past experience, I've found that Oracle is very sensitive to FS activity blocks - after about 1 sec, Oracle will abort if it's FS activity is blocked. It's possible that other applications have similar behaviour. Peter The bulk of the suspend time is spent flushing out all the dirty buffers and metadata to get a consistent on-disk copy. I do not know any way to make that go faster, nor do I know a way to do it without suspending filesystem operations. Applications that are sensitive to 1-second I/O suspensions are likely to be problematic. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 19:36:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id BD2B737B6DF; Wed, 26 Jul 2000 19:36:14 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id TAA24105; Wed, 26 Jul 2000 19:36:14 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 26 Jul 2000 19:36:13 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: arch@freebsd.org Subject: How much security should ldconfig enforce? Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am building a bike shed, and I was wondering if you could advise me about what color it should be. :-) Just kidding -- this is about ldconfig. Last night I committed some security-related changes that somebody submitted to me. The changes make ldconfig refuse to pay attention to directories which are world-writable or not owned by root. In the commit message I also stated a desire to strengthen it further by disallowing group-writable directories. One committer wrote to me and said he didn't like that last idea. His reason was that in some scenarios multiple developers might want to collaborate in such a way that any of them could add shared libraries to certain directories which were writable by their common group. He went on to say that even the changes I already committed seemed a bit too strict, and that if a user wants to run an insecure machine for some reason then ldconfig shouldn't take away the sword he wishes to fall upon. I am sympathetic to these points and am ambivalent about how strict ldconfig ought to be. Here are some different behaviors it could be made to have: 1. It could allow anything, just like it did before I made my commit. 2. It could strictly enforce secure ownerships, groups, and permissions -- i.e., keep last night's commit and add group writability checking too. 3. It could default to strictly secure but accept a command-line option to relax the constraints. And an rc.conf knob could be added to control whether or not it was strict at boot time. What do you folks think about this? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 21: 1: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id 71EF837B643 for ; Wed, 26 Jul 2000 21:01:02 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FYC000CP89FVQ@mta5.rcsntx.swbell.net> for arch@FreeBSD.ORG; Wed, 26 Jul 2000 22:56:04 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA37368; Wed, 26 Jul 2000 22:54:23 -0500 (CDT envelope-from chris) Date: Wed, 26 Jul 2000 22:54:22 -0500 From: Chris Costello Subject: Re: How much security should ldconfig enforce? In-reply-to: To: John Polstra Cc: arch@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000726225421.G30816@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, July 26, 2000, John Polstra wrote: > 1. It could allow anything, just like it did before I made my commit. > > 2. It could strictly enforce secure ownerships, groups, and > permissions -- i.e., keep last night's commit and add group > writability checking too. > > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. I like the third option. You should be able to shoot yourself in the foot if you _really_ want to. -- |Chris Costello |Those who can, do. Those who cannot, teach. Those who cannot teach, HACK! `--------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 22:55: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 87DD037C064 for ; Wed, 26 Jul 2000 22:54:54 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id XAA07246; Wed, 26 Jul 2000 23:54:52 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id XAA15587; Wed, 26 Jul 2000 23:54:51 -0600 (MDT) (envelope-from nate) Date: Wed, 26 Jul 2000 23:54:51 -0600 (MDT) Message-Id: <200007270554.XAA15587@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Polstra Cc: arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. > > What do you folks think about this? I vote #3. It gives us a more secure 'default', but allows people with special configurations to tweak it for their particular 'less secure' environments. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 23:16:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 9355937C0BF for ; Wed, 26 Jul 2000 23:16:06 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id IAA16104; Thu, 27 Jul 2000 08:15:49 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007270615.IAA16104@grimreaper.grondar.za> To: John Polstra Cc: arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? References: In-Reply-To: ; from John Polstra "Wed, 26 Jul 2000 19:36:13 MST." Date: Thu, 27 Jul 2000 08:15:48 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Just kidding -- this is about ldconfig. Last night I committed > some security-related changes that somebody submitted to me. The > changes make ldconfig refuse to pay attention to directories which are > world-writable or not owned by root. In the commit message I also > stated a desire to strengthen it further by disallowing group-writable > directories. I thought that was good :-) > 1. It could allow anything, just like it did before I made my commit. Not a good idea, but... > 2. It could strictly enforce secure ownerships, groups, and > permissions -- i.e., keep last night's commit and add group > writability checking too. ...your correspondent had a point, however. > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. Could it relax constraints on a per-directory basis, so that folk who want a shared lib dir with *this* privelige *here* can do that? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 23:25:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A834E37C037 for ; Wed, 26 Jul 2000 23:25:19 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA34938; Thu, 27 Jul 2000 00:25:16 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA36358; Thu, 27 Jul 2000 00:25:13 -0600 (MDT) Message-Id: <200007270625.AAA36358@harmony.village.org> To: John Polstra Subject: Re: How much security should ldconfig enforce? Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 26 Jul 2000 19:36:13 PDT." References: Date: Thu, 27 Jul 2000 00:25:12 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Polstra writes: : I am building a bike shed, and I was wondering if you could advise : me about what color it should be. :-) 'Blue, no green' : What do you folks think about this? I see two types of system on a regular basis. One is where you are running stock everything and writable anything is a big problem. The other is where I'm developing things all over the place and want shared libaries to be writable or at least the dirs they are in. Sometimes I'll want to further have ldconfig these dirs too. So, my suggestion would be to have -S option. That way people that want to have extra high security can have it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 26 23:56:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id 2DF9237BA43 for ; Wed, 26 Jul 2000 23:56:15 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id JAA73017; Thu, 27 Jul 2000 09:04:00 +0200 (CEST) (envelope-from adrian) Date: Thu, 27 Jul 2000 09:03:59 +0200 From: Adrian Chadd To: John Polstra Cc: arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727090359.A71137@ywing.creative.net.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jdp@polstra.com on Wed, Jul 26, 2000 at 07:36:13PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 26, 2000, John Polstra wrote: > I am building a bike shed, and I was wondering if you could advise > me about what color it should be. :-) [snip] > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. > > What do you folks think about this? Hrm. If you change the default behaviour, POLA might kick in. Not that I mind. I agree with the above changes, with or without POLA considerations. Adrian -- Adrian Chadd Now 17-year-olds can't play a _video game_ because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 0:31:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 7180037B91A for ; Thu, 27 Jul 2000 00:31:17 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id RAA09155; Thu, 27 Jul 2000 17:00:25 +0930 (CST) (envelope-from grog) Date: Thu, 27 Jul 2000 17:00:25 +0930 From: Greg Lehey To: Jack Rusher Cc: mjacob@feral.com, freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs Message-ID: <20000727170025.E36365@wantadilla.lemis.com> References: <397CABB4.1CAAC7C3@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <397CABB4.1CAAC7C3@integratus.com>; from jar@integratus.com on Mon, Jul 24, 2000 at 01:48:52PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 24 July 2000 at 13:48:52 -0700, Jack Rusher wrote: > Matthew Jacob wrote: >> >> I think that vinum is already good, like VxVM also, in that once you label a >> disk (i.e., borg it into vinum), it's boot-time to boot-time address becomes >> can become less relevant. > > Yes, there is self descriptive meta data on VxVM and vinum drives. > However, you need some way to tell vinum which drives to eat. Vinum eats the drives it finds. When it's started, it goes looking for all partitions with partition type "Vinum", and it gets the name from the Vinum label. >> I think that the constancy of the /dev/daX namespace is relevant only as >> long as that is the name in /etc/fstab. > > There are other issues having to do with what happens when you pull a > disk out and copy the contents onto another drive (upgrade to bigger > primary disk, for instance). You want to just stick the drive back in > the machine and have everything boot and work normally. This only works > if the fstab looks at the first SCSI drive by a positional name. > > The other option is to use disklabels (instead of disk serial numbers) > to identify the disks. You can provide a label copy tool to clone a > disk, but you run into trouble when you have two disks that are clones > of one another in the same system. Vinum solves this position by taking the most recent label. Vinum labels include a "last modified" field. > You also have trouble if one of the disks is the > Windows/Linux/whatever partition of your workstation and has a label > scheme that doesn't play nice with the BSD scheme. What do you call > that disk in the device tree? You need both possibilities. It would be simple enough to allow both device names (with explicit pathname) and volume names (without) in /etc/fstab. > All I am trying to illustrate here is that there are some cases > where it is better to have absolute names and some cases where > positional abstraction is the right answer. It would be nice if we > could have a compromise of the two techniques that lets you look at > your storage in the way that makes the most sense for your > application. Agreed. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 0:32:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id BF36D37B959 for ; Thu, 27 Jul 2000 00:32:20 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id JAA73182 for freebsd-arch@freebsd.org; Thu, 27 Jul 2000 09:40:15 +0200 (CEST) (envelope-from adrian) Date: Thu, 27 Jul 2000 09:40:15 +0200 From: Adrian Chadd To: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000727094015.B71137@ywing.creative.net.au> References: <397F5BD6.5104F1E4@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <397F5BD6.5104F1E4@integratus.com>; from jar@integratus.com on Wed, Jul 26, 2000 at 02:44:54PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 26, 2000, Jack Rusher wrote: > Matthew Jacob wrote: > > > > No- not really. A devfs should allow one to dynamically bind a meaningful > > name to a device- so you don't get stuck with inodes on disk that don't > > point to what you think the name in /dev (which is what you use in > > /etc/fstab or other apps) points to. > > > > Complete discovery of all potential devices that can then be instantiated in > > /dev is a related but separate problem. > > Hmm. I understand why you would want to divide and conquer on this > problem, but it seems to me that you would want to do you top level > design in a way that allows these things to coexist and be developed one > at a time. > > From a "driver figures out what to load" perspective, I find it very > useful to have drives hanging from a controller in a tree structure so > that I can write tools that are able to intelligently figure out how to > balance I/O over controllers. What is the win from avoiding a tree > based device layout? > > Adrian Chadd's notion of a node under dev (say, /dev/fc0 for the first > fibre channel controller) that returns listings of underlying devices > (by sending queries to the drivers) has some potential merit. There is > the chance, however, that I am thinking about things from too much of a > Plan9 perspective. I just like the idea of using file system semantics > for databases; especially with links to provide multiple names for a > resource. Kind of. From my understanding of the way devices/VFS holds together, the underlying devsw can't change while the machine is running, so your (SCSI/IDE/Fibrechannel) device drivers and whatever disklabel layer you use would have to keep the devsw mapping static. Your disklabel layer would then register say, /dev/dsk/, and then it can control what names are returned. But it doesn't even have to do this if you wanted to keep the device labels in /dev and call them, say, /dev/disk-$label, you should be able to do that with make_dev(). Matt - if I understand your initial idea right, all you wanted was a way to map a fibrechannel disk label to a name in a devfs, so that when the underlying device shifted 'address', you would still be able to reference it without difficulty? Was there anything else ? Adrian -- Adrian Chadd Now 17-year-olds can't play a _video game_ because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 0:45:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C02F437BA8F for ; Thu, 27 Jul 2000 00:45:13 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6R7jBP13151; Thu, 27 Jul 2000 00:45:11 -0700 (PDT) Date: Thu, 27 Jul 2000 00:45:11 -0700 From: Alfred Perlstein To: John Polstra Cc: arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727004510.S17222@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jdp@polstra.com on Wed, Jul 26, 2000 at 07:36:13PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Polstra [000726 19:36] wrote: > > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. > > What do you folks think about this? I think this sounds the best, it protects our users but also allows them the flexibility they may need. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 5: 8: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.43.150]) by hub.freebsd.org (Postfix) with ESMTP id 3B40A37B738 for ; Thu, 27 Jul 2000 05:07:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id JAA00220; Thu, 27 Jul 2000 09:30:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John Polstra Cc: arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? In-reply-to: Your message of "Wed, 26 Jul 2000 19:36:13 PDT." Date: Thu, 27 Jul 2000 09:30:58 +0200 Message-ID: <218.964683058@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >3. It could default to strictly secure but accept a command-line >option to relax the constraints. And an rc.conf knob could be added >to control whether or not it was strict at boot time. > >What do you folks think about this? Following on the "tools, not policy" the 3rd option has support. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 5:50:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 7E85337B52C for ; Thu, 27 Jul 2000 05:50:32 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 44DDF195F4; Thu, 27 Jul 2000 07:50:27 -0500 (CDT) Received: (from nectar@localhost) by hamlet.nectar.com (8.9.3/8.9.3) id HAA09003; Thu, 27 Jul 2000 07:50:27 -0500 (CDT) (envelope-from nectar@spawn.nectar.com) Date: Thu, 27 Jul 2000 07:50:27 -0500 From: "Jacques A. Vidrine" To: John Polstra Cc: arch@freebsd.org Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727075027.C8974@hamlet.nectar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jdp@polstra.com on Wed, Jul 26, 2000 at 07:36:13PM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 26, 2000 at 07:36:13PM -0700, John Polstra wrote: > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. I like this option, but the knob should be compile-time, IMHO. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 5:53:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id B2F9A37B51D for ; Thu, 27 Jul 2000 05:53:18 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13Hn9b-000C53-00; Thu, 27 Jul 2000 14:52:47 +0200 Date: Thu, 27 Jul 2000 14:52:47 +0200 From: Neil Blakey-Milner To: "Jacques A. Vidrine" Cc: John Polstra , arch@freebsd.org Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727145247.A46416@mithrandr.moria.org> References: <20000727075027.C8974@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000727075027.C8974@hamlet.nectar.com>; from n@nectar.com on Thu, Jul 27, 2000 at 07:50:27AM -0500 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 2000-07-27 (07:50), Jacques A. Vidrine wrote: > On Wed, Jul 26, 2000 at 07:36:13PM -0700, John Polstra wrote: > > 3. It could default to strictly secure but accept a command-line > > option to relax the constraints. And an rc.conf knob could be added > > to control whether or not it was strict at boot time. > > I like this option, but the knob should be compile-time, IMHO. Why? You expect someone to check out sources and recompile the program to make it secure when you can instead use a command line option? Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 6:39:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 0AB3737B944 for ; Thu, 27 Jul 2000 06:39:22 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 8534D195F4; Thu, 27 Jul 2000 08:39:20 -0500 (CDT) Received: (from nectar@localhost) by hamlet.nectar.com (8.9.3/8.9.3) id IAA09065; Thu, 27 Jul 2000 08:39:20 -0500 (CDT) (envelope-from nectar@spawn.nectar.com) Date: Thu, 27 Jul 2000 08:39:20 -0500 From: "Jacques A. Vidrine" To: Neil Blakey-Milner Cc: John Polstra , arch@freebsd.org Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727083920.A9036@hamlet.nectar.com> References: <20000727075027.C8974@hamlet.nectar.com> <20000727145247.A46416@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000727145247.A46416@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Thu, Jul 27, 2000 at 02:52:47PM +0200 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 27, 2000 at 02:52:47PM +0200, Neil Blakey-Milner wrote: > > I like this option, but the knob should be compile-time, IMHO. > > Why? > > You expect someone to check out sources and recompile the program to > make it secure when you can instead use a command line option? No, I expect by default that it be built in secure mode. I expect that if someone wants to shoot herself in the foot, she can twiddle make.conf and rebuild from source to disable this option. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 6:45:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id CF2A737B869 for ; Thu, 27 Jul 2000 06:45:06 -0700 (PDT) (envelope-from darius@guppy.dons.net.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id XAA37652; Thu, 27 Jul 2000 23:14:37 +0930 (CST) (envelope-from darius@guppy.dons.net.au) Received: (from darius@localhost) by guppy.dons.net.au (8.9.3/8.9.3) id XAA02286; Thu, 27 Jul 2000 23:14:27 +0930 (CST) (envelope-from darius) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20000727083920.A9036@hamlet.nectar.com> Date: Thu, 27 Jul 2000 23:14:27 +0930 (CST) From: "Daniel O'Connor" To: "Jacques A. Vidrine" Subject: Re: How much security should ldconfig enforce? Cc: arch@freebsd.org, John Polstra , Neil Blakey-Milner Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Jul-00 Jacques A. Vidrine wrote: > On Thu, Jul 27, 2000 at 02:52:47PM +0200, Neil Blakey-Milner wrote: >> You expect someone to check out sources and recompile the program to >> make it secure when you can instead use a command line option? > No, I expect by default that it be built in secure mode. > > I expect that if someone wants to shoot herself in the foot, she can > twiddle make.conf and rebuild from source to disable this option. If the default behaviour is safe (ie by default it checks permissions) then I don't see that it is necessary to make it a build time option. If you are playing with options you don't understand then you're asking for trouble :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 6:48:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 5596437B8FC for ; Thu, 27 Jul 2000 06:48:24 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13Ho17-000CK0-00; Thu, 27 Jul 2000 15:48:05 +0200 Date: Thu, 27 Jul 2000 15:48:05 +0200 From: Neil Blakey-Milner To: "Jacques A. Vidrine" Cc: John Polstra , arch@freebsd.org Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727154804.A47282@mithrandr.moria.org> References: <20000727075027.C8974@hamlet.nectar.com> <20000727145247.A46416@mithrandr.moria.org> <20000727083920.A9036@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000727083920.A9036@hamlet.nectar.com>; from n@nectar.com on Thu, Jul 27, 2000 at 08:39:20AM -0500 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 2000-07-27 (08:39), Jacques A. Vidrine wrote: > > You expect someone to check out sources and recompile the program to > > make it secure when you can instead use a command line option? > > No, I expect by default that it be built in secure mode. > > I expect that if someone wants to shoot herself in the foot, she can > twiddle make.conf and rebuild from source to disable this option. I don't think we should make policy decisions that require people to go off and bend over backwards to do something that isn't necessarily insecure. Otherwise, people will do horrible things with sudo and start giving out passwords, since that'll be easier than escaping our policy. If it's an option, then when that person uses the option, they know what they're doing. The extra 54 bytes is not going to be missed by anyone. While we're providing a safety net by overriding root's ability to do stupid things, we're also blatantly overriding root's ability to do what we consider to be stupid things but which aren't necessarily stupid things. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 8:15:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0AB7837BA89 for ; Thu, 27 Jul 2000 08:15:39 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA93314; Thu, 27 Jul 2000 11:14:56 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 27 Jul 2000 11:14:55 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Jacques A. Vidrine" Cc: John Polstra , arch@freebsd.org Subject: Re: How much security should ldconfig enforce? In-Reply-To: <20000727075027.C8974@hamlet.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Jul 2000, Jacques A. Vidrine wrote: > On Wed, Jul 26, 2000 at 07:36:13PM -0700, John Polstra wrote: > > 3. It could default to strictly secure but accept a command-line > > option to relax the constraints. And an rc.conf knob could be added > > to control whether or not it was strict at boot time. > > I like this option, but the knob should be compile-time, IMHO. I would support either the "revert" or (3) option, but definitely not support this being a compile-time flag. I should not have to recompile the operating system to allow our netsec group to have a /netsec/lib with different maintainers for different operating systems. Especially in NFS environments, placing requirements on permissions and ownership for directories is a very poor idea. In general, the UNIX mechanism has been to implement tools, but not policies, for which we already have quite a sufficient discretionary access control mechanism. In general, we don't check permissions on the /etc directory, we assume that it is set correctly during the install, and that if the user wants to change it, that is their perogative. The same goes for group files, etc. In the future, once we have a mandatory access control policy, integrity protection can be used to protect users from shared libraries of low integrity. So my preference here is: permissions and ownership in the base install are fine. The default compile (and preferably install) should allow users to include group-writable shared library paths, if not world-writable paths. Consider our adduser implementation: each user is in their own group anyway :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 9:28: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id AB9E837BC3E for ; Thu, 27 Jul 2000 09:28:04 -0700 (PDT) (envelope-from jhb@pike.osd.bsdi.com) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id JAA76361; Thu, 27 Jul 2000 09:27:12 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200007271627.JAA76361@pike.osd.bsdi.com> Subject: Re: SysctlFS In-Reply-To: <200007270147.SAA16199@beastie.mckusick.com> from Kirk McKusick at "Jul 26, 2000 06:47:34 pm" To: Kirk McKusick Date: Thu, 27 Jul 2000 09:27:11 -0700 (PDT) Cc: abial@webgiro.com, arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kirk McKusick wrote: > Date: Wed, 12 Jul 2000 14:45:10 +0200 > From: Adrian Chadd > To: Andrzej Bialecki > Cc: freebsd-arch@FreeBSD.ORG > Subject: Re: SysctlFS > > On Wed, Jul 12, 2000, Andrzej Bialecki wrote: > > Hi, > > > > I've been tweaking the sysctls here and there for some time > > now, and I'd like to see what is the current opinion on > > implementing sysctl tree as a filesystem. Most of the work > > I've done with dynamic sysctls is very similar to what > > happens with filesystem. Also, filesystem model allows for > > much more fine-grained access control. > > > > If you are still interested in doing this, see `man kernfs' > which is a prototype of a filesystem designed to show (and > in some cases modify) kernel information. > > Kirk McKusick Andrezj, You might want to talk to Kelly Yancey as well. I know he has a nearly-finished implementation of sysctlfs lying around. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 9:40:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D429337BC1D for ; Thu, 27 Jul 2000 09:40:20 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6RGeDW24673; Thu, 27 Jul 2000 09:40:13 -0700 (PDT) Date: Thu, 27 Jul 2000 09:40:13 -0700 From: Alfred Perlstein To: "Jacques A. Vidrine" Cc: John Polstra , arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727094013.T17222@fw.wintelcom.net> References: <20000727075027.C8974@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000727075027.C8974@hamlet.nectar.com>; from n@nectar.com on Thu, Jul 27, 2000 at 07:50:27AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jacques A. Vidrine [000727 05:50] wrote: > On Wed, Jul 26, 2000 at 07:36:13PM -0700, John Polstra wrote: > > 3. It could default to strictly secure but accept a command-line > > option to relax the constraints. And an rc.conf knob could be added > > to control whether or not it was strict at boot time. > > I like this option, but the knob should be compile-time, IMHO. Compile time options died in the early 90's dude. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 10: 8:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from merc94.us.sas.com (merc94.us.sas.com [149.173.6.4]) by hub.freebsd.org (Postfix) with ESMTP id 995C737B7B5; Thu, 27 Jul 2000 10:08:25 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from merc94.us.sas.com ([127.0.0.1]) by merc94.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PDG9FJZJ; Thu, 27 Jul 2000 13:08:23 -0400 Received: from 10.28.149.26 by merc94.us.sas.com (InterScan E-Mail VirusWall NT); Thu, 27 Jul 2000 13:08:22 -0400 (Eastern Daylight Time) Received: from tribble.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA03903; Thu, 27 Jul 2000 13:08:22 -0400 Received: from localhost (brdean@localhost) by tribble.unx.sas.com (8.9.3/8.9.1) with ESMTP id NAA62436; Thu, 27 Jul 2000 13:08:21 -0400 (EDT) (envelope-from brdean@unx.sas.com) X-Authentication-Warning: tribble.unx.sas.com: brdean owned process doing -bs Date: Thu, 27 Jul 2000 13:08:21 -0400 (EDT) From: Brian Dean To: Bruce Evans Cc: freebsd-arch@FreeBSD.ORG, luoqi@FreeBSD.ORG Subject: Re: isatty() reports false results In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Jul 2000, Bruce Evans wrote: > Probably not. POSIX.1 says that tcgetattr() shall return EBADF for non- > open files and ENOTTY for non-terminals. These are the only errors > mentioned in POSIX.1. Returning EAGAIN is probably a bug. OTOH, checking > for only EAGAIN is a bug if there are any other undocumented error returns. It looks like this behaviour of the pty ioctl() was introduced a little over a year ago in revision 1.58 of kern/tty_pty.c. The commit log (by luoqi) only says "Ignore some ioctls on the master until the slave is open." The commit log does not make clear any other reason regarding what was trying to be solved by this change. Can anyone (Luoqi?) elaborate on the reasons? Maybe we can solve the problem in another way that allows us to conform to the POSIX return codes that Bruce refers to above. I looked at my NetBSD box and they do not short circuit these ioctl()'s in this case. They must be handling this in another way, though I have not had a chance to dig into their code further. I do note that when I modified my local kernel to defeat this change, my system paniced pretty quickly when I attempt an incoming telnet connection which uses the ptys. And this is primarily why I was looking at modifying 'isatty()' to be smarter instead of messing around in the pty driver. I suppose, at worst, we could move the TIOCGETA handling to precede the check for the slave being open. Would that be valid? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 11: 4:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id BE67637B64D for ; Thu, 27 Jul 2000 11:04:11 -0700 (PDT) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id B0E37195F4; Thu, 27 Jul 2000 13:04:07 -0500 (CDT) Date: Thu, 27 Jul 2000 13:04:07 -0500 From: "Jacques A. Vidrine" To: Alfred Perlstein Cc: John Polstra , arch@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727130407.A35888@spawn.nectar.com> References: <20000727075027.C8974@hamlet.nectar.com> <20000727094013.T17222@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000727094013.T17222@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Jul 27, 2000 at 09:40:13AM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 27, 2000 at 09:40:13AM -0700, Alfred Perlstein wrote: > > I like this option, but the knob should be compile-time, IMHO. > Compile time options died in the early 90's dude. :) Heh. What I _really_ felt was that the ``secure'' behavior should be the only normally available, and if someone felt differently they can patch the source themselves :-) But I didn't feel comfortable taking such a drastic position so I guess I just picked the worst of both worlds. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 13:13:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BC3A737BD63; Thu, 27 Jul 2000 13:13:15 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id QAA10252; Thu, 27 Jul 2000 16:13:08 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 27 Jul 2000 16:13:08 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Isaac Waldron Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Writing device drivers (ioctl issue) In-Reply-To: <005301bff73b$bf8a3460$0100000a@waldron.house> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Jul 2000, Isaac Waldron wrote: > I started working on a port of FreeMWare/plex86 (www.plex86.org) to FreeBSD > yesterday, and have run into a small problem. The basic idea is that I need > to write a kernel module that implements some ioctls for a new psuedo-device > that will eventually reside at /dev/plex86. > > The issue I'm running into is with the function I'm writing to handle the > ioctls for the device. For one of the ioctls, the code needs to get some > data from the file descriptor that was passed to the original call to > ioctl(2). This is easily accomplished in linux, because the file descriptor > is passed as the second argument to the device_ioctl function. > > Is there an easy way to get at the same data (the file descriptor passed to > ioctl(2) by the calling program, in a kernel-style "struct file *", not the > standard "struct FILE *") in FreeBSD? Or will it be neccesary to change the > ioctl structure slightly and therefore need to change some of the higher > level functions in plex? I ran into this same problem when modifying the vmmon VMWare driver for FreeBSD to support mulitple emulator instances. FreeBSD's VFS does not have a concept of stateful file access: there are open's and close's, but the VOP_READ/WRITE operations are not associated with sessions. This influences the way in which drivers are implemented for BSD (and platforms like it.) For example, rather than having one /dev/bpf with multiple "open" instances, we have /dev/bpf{0,1,...}, and a process needing a session will sequentially attempt to open devices until it finds one that doesn't return EBUSY. The driver, in this case, limits the number of open references to 1. There are a number of possible solutions to this problem, including the Linux solution solution of passing the file descriptor down the VFS stack so that VFS layers can attach attach information to the file descriptor providing session information. In this manner, VOP_READ/WRITE can determine which session is active, and behave appropriately. I dislike this solution: right now, file descriptors are a property of the process and ABI, and the VFS is unaware of them. Having a stacked file system suggests that the single hook in the file descriptor is insufficient to maintain per-layer information associated with a session, also. It also makes a mess of access to files from within the kernel, where file descriptors are not used. My preferred solution, and I actually hacked around with a kernel a bit to do this, is to make the VFS provide (optional) stateful vnode sessions. vop_open() would gain an additional call-by-reference argument, probably a void**. When NULL, the caller would be requesting a stateless vnode open, and all would be as today. When non-NULL, this would allow the vnode provider to return a cookie/rock/void pointer to state information for the session. Other VOP's would similarly accept back this cookie, allowing the VOP provider to inspect it (if non-NULL) and behave appropriately with state. vop_close() could be used to release the cookie. This would provide the ability for file systems and callers to optionally make use of state, without violating the seperation of file descriptors/open file records and the VFS. It would also allow stacking to occur, as each vnode private data layer/layered cookie struct could do appropriate layer transformations to get the right cookie for the next layer down. I.e., there would be a sensical semantic for stacked file systems to provide stateful access. My changes are incomplete as I was working on it on the plane, and comments on the idea would be welcome. One thing this would allow is for us to not heavily replicate device nodes in /dev for multi-instance virtual devices. The BPF example is a useful one here: while the kernel currently supports dynamically allocated BPF devices, /dev has to have BPF entries manually added. The same goes for tunnel devices, et al. While a real devfs would fix this, the semantic is also useful for drivers ported from Linux (and other platforms with stateful vnode access) that expect to be able to open /dev/vmmon, and get a new unique session. For /dev/vmnet, it means the driver can detect multiple sessions on the same device, and act appropriately. In vmnet, each vmnet device acts like an ethernet bridge for the sessions open on it, so you can bind different VMWare sessions to different virtual network segments, potentially more than one VMWare session to each network segment. Or, you can binary-modify VMWare each run time to open a different /dev/{whatever}, or ge the developer to use a /dev/whatever{0,1,2,3...} model, for which there is much precedent in Linux (BPF, ttys, etc). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 13:36:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id B2BEE37BEDC for ; Thu, 27 Jul 2000 13:36:21 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e6RKaBR18831; Thu, 27 Jul 2000 16:36:11 -0400 (EDT) Date: Thu, 27 Jul 2000 16:36:11 -0400 (EDT) From: Luoqi Chen Message-Id: <200007272036.e6RKaBR18831@lor.watermarkgroup.com> To: bde@zeta.org.au, brdean@unx.sas.com Subject: Re: isatty() reports false results Cc: freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 27 Jul 2000, Bruce Evans wrote: > > > Probably not. POSIX.1 says that tcgetattr() shall return EBADF for non- > > open files and ENOTTY for non-terminals. These are the only errors > > mentioned in POSIX.1. Returning EAGAIN is probably a bug. OTOH, checking > > for only EAGAIN is a bug if there are any other undocumented error returns. > > It looks like this behaviour of the pty ioctl() was introduced a > little over a year ago in revision 1.58 of kern/tty_pty.c. The commit > log (by luoqi) only says "Ignore some ioctls on the master until the > slave is open." The commit log does not make clear any other reason > regarding what was trying to be solved by this change. Can anyone > (Luoqi?) elaborate on the reasons? Maybe we can solve the problem in > another way that allows us to conform to the POSIX return codes that > Bruce refers to above. > IIRC, TIOCSET* ioctls on a master without the slave being open would cause a panic. In the initial fix I committed (rev 1.58), I returned success for these ioctls without doing anything. But later I changed to return an error code (EAGAIN) at Bruce's suggestion. > I looked at my NetBSD box and they do not short circuit these > ioctl()'s in this case. They must be handling this in another way, > though I have not had a chance to dig into their code further. I do > note that when I modified my local kernel to defeat this change, my > system paniced pretty quickly when I attempt an incoming telnet > connection which uses the ptys. And this is primarily why I was > looking at modifying 'isatty()' to be smarter instead of messing > around in the pty driver. > > I suppose, at worst, we could move the TIOCGETA handling to precede > the check for the slave being open. Would that be valid? > The master is not in the normal sense a tty, I think we could just change the return code from EAGAIN to ENOTTY to conform to the POSIX standard. As for isatty(), I don't think we need to change anything, it is a pilot error to call isatty() on the master side of the pty. > -Brian > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 14:32:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 7303F37B523 for ; Thu, 27 Jul 2000 14:32:41 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.7/nospam) with UUCP id XAA02136 for arch@freebsd.org; Thu, 27 Jul 2000 23:32:35 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 9E90F8894; Thu, 27 Jul 2000 21:33:01 +0200 (CEST) Date: Thu, 27 Jul 2000 21:33:01 +0200 From: Ollivier Robert To: arch@freebsd.org Subject: Re: How much security should ldconfig enforce? Message-ID: <20000727213301.A43542@keltia.freenix.fr> Mail-Followup-To: Ollivier Robert , arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jdp@polstra.com on Wed, Jul 26, 2000 at 07:36:13PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to John Polstra: > 1. It could allow anything, just like it did before I made my commit. > > 2. It could strictly enforce secure ownerships, groups, and > permissions -- i.e., keep last night's commit and add group > writability checking too. > > 3. It could default to strictly secure but accept a command-line > option to relax the constraints. And an rc.conf knob could be added > to control whether or not it was strict at boot time. #3 seems to me the Right Thing[tm]. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 14:47:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by hub.freebsd.org (Postfix) with ESMTP id 035B337C103 for ; Thu, 27 Jul 2000 14:47:46 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: Network Richmond, LLC. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id RAA23179; Thu, 27 Jul 2000 17:47:19 -0400 (EDT) Date: Thu, 27 Jul 2000 17:47:19 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: John Baldwin Cc: Kirk McKusick , abial@webgiro.com, arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: <200007271627.JAA76361@pike.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Jul 2000, John Baldwin wrote: > > > > If you are still interested in doing this, see `man kernfs' > > which is a prototype of a filesystem designed to show (and > > in some cases modify) kernel information. > > > > Kirk McKusick > > Andrezj, > > You might want to talk to Kelly Yancey as well. I > know he has a nearly-finished implementation of sysctlfs lying around. > Yes, and just as Kirk mentioned, I used kernfs as a reference :) I'll be out of town this weekend, but I'll try and get something posted next week. I think others said recently that they had done similar work, also. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 16:18:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 33C9137C127 for ; Thu, 27 Jul 2000 16:18:57 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 8529 invoked from network); 27 Jul 2000 23:18:56 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 27 Jul 2000 23:18:56 -0000 Message-ID: <3980C360.BB897C3A@integratus.com> Date: Thu, 27 Jul 2000 16:18:56 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Chadd Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? References: <397F5BD6.5104F1E4@integratus.com> <20000727094015.B71137@ywing.creative.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Adrian Chadd wrote: > > Kind of. From my understanding of the way devices/VFS holds together, the > underlying devsw can't change while the machine is running, so your > (SCSI/IDE/Fibrechannel) device drivers and whatever disklabel layer you > use would have to keep the devsw mapping static. ...which strikes me as pretty lousy. New disks can come and go (especially if they are attached to a fabric). In fact, in a more general sense, a lot of things can be dynamically registered and deregistered using modern bus architectures. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 16:27:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from merc94.us.sas.com (merc94.us.sas.com [149.173.6.4]) by hub.freebsd.org (Postfix) with ESMTP id 2C5BF37BC5F for ; Thu, 27 Jul 2000 16:27:28 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from merc94.us.sas.com ([127.0.0.1]) by merc94.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PDG9FVC0; Thu, 27 Jul 2000 19:27:26 -0400 Received: from 10.28.149.26 by merc94.us.sas.com (InterScan E-Mail VirusWall NT); Thu, 27 Jul 2000 19:27:26 -0400 (Eastern Daylight Time) Received: from tribble.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA03248; Thu, 27 Jul 2000 19:27:26 -0400 Received: from localhost (brdean@localhost) by tribble.unx.sas.com (8.9.3/8.9.1) with ESMTP id TAA78169; Thu, 27 Jul 2000 19:27:26 -0400 (EDT) (envelope-from brdean@unx.sas.com) X-Authentication-Warning: tribble.unx.sas.com: brdean owned process doing -bs Date: Thu, 27 Jul 2000 19:27:26 -0400 (EDT) From: Brian Dean To: Luoqi Chen Cc: bde@zeta.org.au, freebsd-arch@FreeBSD.ORG Subject: Re: isatty() reports false results In-Reply-To: <200007272036.e6RKaBR18831@lor.watermarkgroup.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Jul 2000, Luoqi Chen wrote: > > I suppose, at worst, we could move the TIOCGETA handling to precede > > the check for the slave being open. Would that be valid? > > > The master is not in the normal sense a tty, I think we could just change > the return code from EAGAIN to ENOTTY to conform to the POSIX standard. > As for isatty(), I don't think we need to change anything, it is a pilot > error to call isatty() on the master side of the pty. The way this section of code gained my attention was when I was setting up a VPN using ppp over ssh. For example, my setup gets instantiated using something like this: % /usr/local/bin/pty-redir \ /usr/bin/ssh -t -e none -o 'Batchmode yes' \ -i $key -l $user $host > ~/vpndev % /usr/sbin/pppd `cat ~/vpndev` $localip:$remoteip In the above, pty-redir allocates a pty, opens the master side of it, prints out the name of the slave side, dup2()'s the master side as stdin and stdout, forks off ssh, then exits. This leaves ssh using the master side as stdin/stdout. On the remote host, the login shell for $user is just /usr/sbin/pppd. The local invocation of pppd uses the slave side of the pty which talks to the remote side and establishes the connection. [This, btw, shows some of the true elegance of Unix - the ability to chain together several seemingly unrelated processes in order instantiate a construct that the original authors of the individual pieces did not necesarily intend or conceive.] Where the pty ioctl() code gets involved is with the '-t' option to ssh. This options causes ssh to request that the remote sshd allocate a pty for the remote pppd which it seems to need. Ssh wants to validate that stdin is really a tty before making the request to the remote side. To do this it calls 'isatty()', which ends up being called on the master side of a pty pair in this case. Perhaps ssh is trying to be smarter than it should be? So based on your statement above, about pilot error, should the validation check be removed from 'ssh'? I have no problem with that, assuming we can maintain this diff or get the contributors to make the same change. Then again, this also seems like a simple matter of timing. If I modify pty-redir slightly to add a delay after the parent exits, but before the child execs ssh, that will give the local pppd a chance to open the slave side before ssh tries to call isatty(). Kind've kludgy, but it works (most of the time - under high system load it may not work). The only problem is that, if we don't change either 'isatty()', or 'ssh', or the pty driver, then others are going to run into this same problem if, like me, they come across the Linux VPN HOW-TO and use it for ideas in setting up a VPN on FreeBSD :(. Our pty driver seems to behave differently in this respect to Linux and NetBSD (and probably others as well). -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 18:27:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id E5CC637C17C for ; Thu, 27 Jul 2000 18:27:28 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 1B41228FD1; Fri, 28 Jul 2000 08:27:21 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 061BC28F50; Fri, 28 Jul 2000 08:27:21 +0700 (ALMST) Date: Fri, 28 Jul 2000 08:27:20 +0700 (ALMST) From: Boris Popov To: Kelly Yancey Cc: John Baldwin , Kirk McKusick , abial@webgiro.com, arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Jul 2000, Kelly Yancey wrote: > > You might want to talk to Kelly Yancey as well. I > > know he has a nearly-finished implementation of sysctlfs lying around. > > > > Yes, and just as Kirk mentioned, I used kernfs as a reference :) > I'll be out of town this weekend, but I'll try and get something > posted next week. I think others said recently that they had done similar > work, also. Yes, I've wrote sysctlfs (scfs) just as an explorer for sysctl name space and as very simple sample filesystem. Yesterday, it has been modified to compile on recent -current. In addition, it demonstrates (ab)use of VOP_GETEXTATTR(). For those who interested: ftp://ftp.butya.kz/misc/scfs.tar.gz -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 18:47:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 55EC537C1AD; Thu, 27 Jul 2000 18:47:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA07548; Thu, 27 Jul 2000 18:47:09 -0700 Date: Thu, 27 Jul 2000 18:47:13 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adrian Chadd Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000727094015.B71137@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Matt - if I understand your initial idea right, all you wanted was a way > to map a fibrechannel disk label to a name in a devfs, so that when the > underlying device shifted 'address', you would still be able to reference > it without difficulty? Was there anything else ? No- I want to map a *device*- I don't *particularly* care what it's name is (the thing put in /etc/fstab or handed to 'mt')- but I do not necessarily want to have to write to it (for a label) to address it. I can guarantee that the address won't shift while the system is running. The other aspect of this is that these are unique names. This makes High Availability device management a *snap*. It's WWNXXXXX on all systems on the same fabric. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 18:50:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BC7CF37C1A5; Thu, 27 Jul 2000 18:50:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA07557; Thu, 27 Jul 2000 18:48:42 -0700 Date: Thu, 27 Jul 2000 18:48:45 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jack Rusher Cc: Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <3980C360.BB897C3A@integratus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Which is also why I want to do this possibly *without* the current instantiation of devfs. On Thu, 27 Jul 2000, Jack Rusher wrote: > Adrian Chadd wrote: > > > > Kind of. From my understanding of the way devices/VFS holds together, the > > underlying devsw can't change while the machine is running, so your > > (SCSI/IDE/Fibrechannel) device drivers and whatever disklabel layer you > > use would have to keep the devsw mapping static. > > ...which strikes me as pretty lousy. New disks can come and go > (especially if they are attached to a fabric). In fact, in a more > general sense, a lot of things can be dynamically registered and > deregistered using modern bus architectures. > > -- > Jack Rusher, Senior Engineer | mailto:jar@integratus.com > Integratus, Inc. | http://www.integratus.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 18:50:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 9501737C199 for ; Thu, 27 Jul 2000 18:50:43 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA99951; Thu, 27 Jul 2000 21:49:59 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 27 Jul 2000 21:49:58 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Boris Popov Cc: Kelly Yancey , John Baldwin , Kirk McKusick , abial@webgiro.com, arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Jul 2000, Boris Popov wrote: > For those who interested: ftp://ftp.butya.kz/misc/scfs.tar.gz Should read: ftp://ftp.butya.kz/pub/misc/scfs.tar.gz Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 21:29: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 9E6E837B9FB for ; Thu, 27 Jul 2000 21:29:02 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id VAA00962; Thu, 27 Jul 2000 21:28:42 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id VAA25123; Thu, 27 Jul 2000 21:28:42 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Thu, 27 Jul 2000 21:28:42 -0700 (PDT) Message-Id: <200007280428.VAA25123@vashon.polstra.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Cc: mark@grondar.za Subject: Re: How much security should ldconfig enforce? In-Reply-To: <200007270615.IAA16104@grimreaper.grondar.za> References: <200007270615.IAA16104@grimreaper.grondar.za> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200007270615.IAA16104@grimreaper.grondar.za>, Mark Murray wrote: > Could it relax constraints on a per-directory basis, so that folk > who want a shared lib dir with *this* privelige *here* can do that? Oh, it _could_, since it is software and software can do anything. :-) But I personally am only willing to take it so far. If it gets too involved, somebody else is going to have to do it. I think it would help if I explained (not for you -- for the group at large) just what ldconfig does and does not do. I will ignore the a.out version, since it is obsolete. What the ELF ldconfig does is very simple: It takes the list of directories from the command line and writes them into "/var/run/ld-elf.so.hints", along with a magic number and a length field and stuff like that. That's all it does. It doesn't read these directories, it doesn't build a hash table, it doesn't do anything except record the directory names. I should also mention that on any sensible system, the hints file which ldconfig updates is writable only by root. That means you more or less have to be root to run ldconfig in the first place, unless you have gone and manually changed the permissions of the hints file. I just mention these things because a few of the replies made me think that not everybody understood them. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 27 21:39:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 24D1E37B9C5; Thu, 27 Jul 2000 21:39:12 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id VAA00982; Thu, 27 Jul 2000 21:39:10 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id VAA25171; Thu, 27 Jul 2000 21:39:09 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Thu, 27 Jul 2000 21:39:09 -0700 (PDT) Message-Id: <200007280439.VAA25171@vashon.polstra.com> To: arch@FreeBSD.ORG Reply-To: arch@FreeBSD.ORG Cc: rwatson@FreeBSD.ORG Subject: Re: How much security should ldconfig enforce? In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Robert Watson wrote: > I would support either the "revert" or (3) option, but definitely > not support this being a compile-time flag. Don't worry, it isn't going to be a compile-time flag. :-) > So my preference here is: permissions and ownership in the base > install are fine. The default compile (and preferably install) > should allow users to include group-writable shared library paths, > if not world-writable paths. One thing to consider is that the hints file is only writable by root. In fact, ldconfig sets it to mode 444 every time it updates it. So your average user can't even _run_ ldconfig in any mode except to list the existing hints file. Allowing group-writable shared library directories is useless for adding new directories because you still have to persuade root to run the ldconfig command for you. OTOH, if ldconfig has already been run then you can add new files to an existing directory without rerunning ldconfig. (That's specific to ELF. It won't work for a.out.) Does this change your opinion? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 3: 9:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 656BE37B9D6; Fri, 28 Jul 2000 03:09:41 -0700 (PDT) (envelope-from wkb@freebie.demon.nl) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13I75D-0003Vh-00; Fri, 28 Jul 2000 10:09:35 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.9.3/8.9.3) id LAA03507; Fri, 28 Jul 2000 11:08:27 +0200 (CEST) (envelope-from wkb) Date: Fri, 28 Jul 2000 11:08:27 +0200 From: Wilko Bulte To: Matthew Jacob Cc: Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000728110827.A3470@freebie.demon.nl> Reply-To: wilko@freebsd.org References: <20000727094015.B71137@ywing.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Thu, Jul 27, 2000 at 06:47:13PM -0700 X-OS: FreeBSD 4.1-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 27, 2000 at 06:47:13PM -0700, Matthew Jacob wrote: > > > Matt - if I understand your initial idea right, all you wanted was a way > > to map a fibrechannel disk label to a name in a devfs, so that when the > > underlying device shifted 'address', you would still be able to reference > > it without difficulty? Was there anything else ? > > No- I want to map a *device*- I don't *particularly* care what it's name is > (the thing put in /etc/fstab or handed to 'mt')- but I do not necessarily want > to have to write to it (for a label) to address it. I can guarantee that the After all this is not NT ('it is harmless to write a signature'). > address won't shift while the system is running. Can you? Assuming a LIP on a FC-AL that is setup for soft addressing and where devices come/go. > The other aspect of this is that these are unique names. This makes High > Availability device management a *snap*. It's WWNXXXXX on all systems on the > same fabric. Yep.. and that is what you really want. -- Wilko Bulte wilko@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 3:29:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id 975D537B9B3 for ; Fri, 28 Jul 2000 03:29:47 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id MAA76387 for freebsd-arch@freebsd.org; Fri, 28 Jul 2000 12:37:31 +0200 (CEST) (envelope-from adrian) Date: Fri, 28 Jul 2000 12:37:30 +0200 From: Adrian Chadd To: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000728123730.C71137@ywing.creative.net.au> References: <20000727094015.B71137@ywing.creative.net.au> <20000728110827.A3470@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000728110827.A3470@freebie.demon.nl>; from wkb@freebie.demon.nl on Fri, Jul 28, 2000 at 11:08:27AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 28, 2000, Wilko Bulte wrote: > On Thu, Jul 27, 2000 at 06:47:13PM -0700, Matthew Jacob wrote: > > > > > Matt - if I understand your initial idea right, all you wanted was a way > > > to map a fibrechannel disk label to a name in a devfs, so that when the > > > underlying device shifted 'address', you would still be able to reference > > > it without difficulty? Was there anything else ? > > > > No- I want to map a *device*- I don't *particularly* care what it's name is > > (the thing put in /etc/fstab or handed to 'mt')- but I do not necessarily want > > to have to write to it (for a label) to address it. I can guarantee that the > > After all this is not NT ('it is harmless to write a signature'). > > > address won't shift while the system is running. > > Can you? Assuming a LIP on a FC-AL that is setup for soft addressing and > where devices come/go. > > > The other aspect of this is that these are unique names. This makes High > > Availability device management a *snap*. It's WWNXXXXX on all systems on the > > same fabric. > > Yep.. and that is what you really want. So why not just call make_dev with the wwnXXXXXX as the device name ? (Assuming that the device nodes exist in /dev, I don't see this as being a problem even now, and if you wanted to you could make a script to query the FC controllers in your system and create devices in /dev/ (or /dev/dsk/, /dev/fc/, whatever you wanted ..) Adrian -- Adrian Chadd Now 17-year-olds can't play a _video game_ because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 6: 5: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 2BE8937C1EE; Fri, 28 Jul 2000 06:04:52 -0700 (PDT) (envelope-from wkb@freebie.demon.nl) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13I9op-0007Ws-00; Fri, 28 Jul 2000 13:04:51 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.9.3/8.9.3) id PAA05534; Fri, 28 Jul 2000 15:01:43 +0200 (CEST) (envelope-from wkb) Date: Fri, 28 Jul 2000 15:01:43 +0200 From: Wilko Bulte To: Adrian Chadd Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000728150143.A5518@freebie.demon.nl> Reply-To: wilko@freebsd.org References: <20000727094015.B71137@ywing.creative.net.au> <20000728110827.A3470@freebie.demon.nl> <20000728123730.C71137@ywing.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000728123730.C71137@ywing.creative.net.au>; from adrian@freebsd.org on Fri, Jul 28, 2000 at 12:37:30PM +0200 X-OS: FreeBSD 4.1-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 28, 2000 at 12:37:30PM +0200, Adrian Chadd wrote: > On Fri, Jul 28, 2000, Wilko Bulte wrote: > > On Thu, Jul 27, 2000 at 06:47:13PM -0700, Matthew Jacob wrote: > > > The other aspect of this is that these are unique names. This makes High > > > Availability device management a *snap*. It's WWNXXXXX on all systems on the > > > same fabric. > > > > Yep.. and that is what you really want. > > So why not just call make_dev with the wwnXXXXXX as the device name ? > (Assuming that the device nodes exist in /dev, I don't see this as being > a problem even now, and if you wanted to you could make a script to query > the FC controllers in your system and create devices in /dev/ (or /dev/dsk/, > /dev/fc/, whatever you wanted ..) Other than that 64/128 bit WWNs are a royal pain in daily use this should work. -- Wilko Bulte wilko@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 6:26: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id C3C1A37C301; Fri, 28 Jul 2000 06:25:54 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.16 #1) id 13IA9A-0003vf-00; Fri, 28 Jul 2000 15:25:52 +0200 Received: from a3932.pppool.de ([213.6.57.50] helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.16 #1) id 13IA99-0003dm-00; Fri, 28 Jul 2000 15:25:52 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id OAA12917; Fri, 28 Jul 2000 14:09:32 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200007281209.OAA12917@Magelan.Leidinger.net> Date: Fri, 28 Jul 2000 14:09:31 +0200 (CEST) From: Alexander Leidinger Subject: Re: How much security should ldconfig enforce? To: rwatson@FreeBSD.ORG Cc: n@nectar.com, jdp@polstra.com, arch@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27 Jul, Robert Watson wrote: > So my preference here is: permissions and ownership in the base install > are fine. The default compile (and preferably install) should allow users > to include group-writable shared library paths, if not world-writable > paths. Consider our adduser implementation: each user is in their own > group anyway :-). Not ldconfig related: What about adding checks to /etc/security for permission critial parts of the system (perhaps controled by periodic.conf)? Bye, Alexander. -- 0 and 1. Now what could be so hard about that? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 6:34: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1AF1937C1B0; Fri, 28 Jul 2000 06:33:57 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id GAA09491; Fri, 28 Jul 2000 06:33:35 -0700 Date: Fri, 28 Jul 2000 06:33:38 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: wilko@freebsd.org Cc: Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000728110827.A3470@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > No- I want to map a *device*- I don't *particularly* care what it's name is > > (the thing put in /etc/fstab or handed to 'mt')- but I do not necessarily want > > to have to write to it (for a label) to address it. I can guarantee that the > > After all this is not NT ('it is harmless to write a signature'). No, no, no. Some folks are serious about you can't do this in their SAN. Also, what about read-only devices? > > > address won't shift while the system is running. > > Can you? Assuming a LIP on a FC-AL that is setup for soft addressing and > where devices come/go. Look at isp_pdb_sync in isp.c, around line ~1609- I mean that I can guarantee that with respect to the system, while it is running, the 'target' won't change. The loopids can wander all over the map... > > > The other aspect of this is that these are unique names. This makes High > > Availability device management a *snap*. It's WWNXXXXX on all systems on the > > same fabric. > > Yep.. and that is what you really want. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 6:34:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id 91FF537C313 for ; Fri, 28 Jul 2000 06:34:39 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id PAA76743 for freebsd-arch@freebsd.org; Fri, 28 Jul 2000 15:42:38 +0200 (CEST) (envelope-from adrian) Date: Fri, 28 Jul 2000 15:42:38 +0200 From: Adrian Chadd To: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000728154238.D71137@ywing.creative.net.au> References: <20000727094015.B71137@ywing.creative.net.au> <20000728110827.A3470@freebie.demon.nl> <20000728123730.C71137@ywing.creative.net.au> <20000728150143.A5518@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000728150143.A5518@freebie.demon.nl>; from wkb@freebie.demon.nl on Fri, Jul 28, 2000 at 03:01:43PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 28, 2000, Wilko Bulte wrote: [snip] > > > > same fabric. > > > > > > Yep.. and that is what you really want. > > > > So why not just call make_dev with the wwnXXXXXX as the device name ? > > (Assuming that the device nodes exist in /dev, I don't see this as being > > a problem even now, and if you wanted to you could make a script to query > > the FC controllers in your system and create devices in /dev/ (or /dev/dsk/, > > /dev/fc/, whatever you wanted ..) > > Other than that 64/128 bit WWNs are a royal pain in daily use this should > work. Well, figuring out what data should be used to construct a device name is up to the driver, right? :-) Adrian -- Adrian Chadd Now 17-year-olds can't play a _video game_ because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 6:54:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BB26137C1C9; Fri, 28 Jul 2000 06:54:33 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id GAA09587; Fri, 28 Jul 2000 06:54:32 -0700 Date: Fri, 28 Jul 2000 06:54:36 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adrian Chadd Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000728123730.C71137@ywing.creative.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So why not just call make_dev with the wwnXXXXXX as the device name ? > (Assuming that the device nodes exist in /dev, I don't see this as being > a problem even now, and if you wanted to you could make a script to query > the FC controllers in your system and create devices in /dev/ (or /dev/dsk/, > /dev/fc/, whatever you wanted ..) Ummm..... That's a thought- but that requires a devfs so that they'll show up in /dev won't it? Without that, it's also a question of /dev pollution. Again, I think everyone's missing a point here. I can create /dev node called /dev/wwn/XXXXXX or whatever- by doing that it's the same thing as the solaris symlink thing- at the time of creation, this then would have to point to, say, the *current* da instance #. At the next reboot, this is out of date. Tra la. But now that I think about it, if I just beef up camcontrol (and CAM, slightly) to spit out WWWns like it now spits out serial #'s, I could have an rc script do the right thing about (re)making all /dev/wwn/XXXXXs (hells bells- I can even make /dev/wwn an MFS filesystem)). Hmm. Let me think about this! This might be an adequate interim solution that does not require teaching mount about WWNs or Serial#s. It wouldn't work for the root filesystem, but, frankly, all the folks running around asking to boot off their SAN (like was the requirement for the new Solaris FC4 layer coming out just now in 2.8.1 (it was worked on in 1997!) are completely in cloud cukoo land- I mean, ATA drives are just peachy, and if it's a large shop maintenance type problem, netbooting is fine, thank you. Hmm! Thanks! This might have pointes me in the right direction for an interim solution. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 8:22:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 1D8E937C259 for ; Fri, 28 Jul 2000 08:22:38 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id IAA04068; Fri, 28 Jul 2000 08:22:10 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id IAA25946; Fri, 28 Jul 2000 08:22:10 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Fri, 28 Jul 2000 08:22:10 -0700 (PDT) Message-Id: <200007281522.IAA25946@vashon.polstra.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Cc: Alexander@Leidinger.net Subject: Re: How much security should ldconfig enforce? In-Reply-To: <200007281209.OAA12917@Magelan.Leidinger.net> References: <200007281209.OAA12917@Magelan.Leidinger.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200007281209.OAA12917@Magelan.Leidinger.net>, Alexander Leidinger wrote: > > Not ldconfig related: Please keep it out of this thread, then! Thank you. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 28 9:13:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 193D037BE95; Fri, 28 Jul 2000 09:13:54 -0700 (PDT) (envelope-from wkb@freebie.demon.nl) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13IClj-000B1g-01; Fri, 28 Jul 2000 16:13:52 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.9.3/8.9.3) id SAA06771; Fri, 28 Jul 2000 18:13:13 +0200 (CEST) (envelope-from wkb) Date: Fri, 28 Jul 2000 18:13:13 +0200 From: Wilko Bulte To: Matthew Jacob Cc: wilko@freebsd.org, Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000728181312.A6724@freebie.demon.nl> Reply-To: wilko@freebsd.org References: <20000728110827.A3470@freebie.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Fri, Jul 28, 2000 at 06:33:38AM -0700 X-OS: FreeBSD 4.1-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 28, 2000 at 06:33:38AM -0700, Matthew Jacob wrote: > > > > No- I want to map a *device*- I don't *particularly* care what it's name is > > > (the thing put in /etc/fstab or handed to 'mt')- but I do not necessarily want > > > to have to write to it (for a label) to address it. I can guarantee that the > > > > After all this is not NT ('it is harmless to write a signature'). > > No, no, no. Some folks are serious about you can't do this in their SAN. Also, > what about read-only devices? Sorry, I should have put a ;-) after that line. I've seen it happen too often that NT scribbles it's darned signature on LUNs hanging off a fabric. OK, the RAIDboxes had not been setup correctly to only allow the right machines (so excluding the NT ones) access, but still. Writing is evil here. > > Can you? Assuming a LIP on a FC-AL that is setup for soft addressing and > > where devices come/go. > > Look at isp_pdb_sync in isp.c, around line ~1609- I mean that I can guarantee > that with respect to the system, while it is running, the 'target' won't > change. The loopids can wander all over the map... OK, makes sense now. Bottom line is you trace them on the only thing guaranteed to be unique: the WWN. If someone is interested in knowing what happens when a duplicate WWN is present on a single fabric: it is entertaining.. Once had to figure out what happens. -- Wilko Bulte wilko@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 29 23:23:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (24.67.218.186.bc.wave.home.com [24.67.218.186]) by hub.freebsd.org (Postfix) with ESMTP id AB75737B598 for ; Sat, 29 Jul 2000 23:23:22 -0700 (PDT) (envelope-from jburkhol@home.com) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 3CB0FBB75 for ; Sat, 29 Jul 2000 23:23:18 -0700 (PDT) X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@freebsd.org Subject: rfc: asnames.h elf kernel symbol mangling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Jul 2000 23:23:18 -0700 From: Jake Burkholder Message-Id: <20000730062318.3CB0FBB75@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I understand building a.out kernels is no longer supported, therefore I'd like to remove the name-mangling macros in i386/include/asnames.h, which were used in the transition. The names used in assembly files need to have the leading underscore removed, so they use the real elf symbols instead of the macros. This file is also used to provide accessors for per-cpu variables used from assembly language, which may change with SMPng; not having the other macros there too will make things easier. The patch is here: http://people.freebsd.org/~jake/asnames.diff Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message