From owner-freebsd-arch Sun Jan 28 8: 8:48 2001 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 9652C37B400 for ; Sun, 28 Jan 2001 08:08:20 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id IAA38768; Sun, 28 Jan 2001 08:00:09 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200101281600.IAA38768@beastie.mckusick.com> To: Garance A Drosihn Subject: Re: Snapshots in the Fast Filesystem Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Thu, 25 Jan 2001 21:06:55 EST." Date: Sun, 28 Jan 2001 08:00:09 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Thu, 25 Jan 2001 21:06:55 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Snapshots in the Fast Filesystem Cc: Kirk McKusick On Sept 23/2000, Barry Pederson wrote: >On July 05/2000, Kirk McKusick wrote: > > >> I have completed an initial implementation of snapshots for the >> fast filesystem (UFS/FFS). I have put up a tarball on >> >> http://people.freebsd.org/~mckusick/snap.tgz >> >> I am looking for comments and feedback on these changes. I am >> proposing to put them into 5.0-current on Tuesday July 11th >> unless I get feedback indicating that folks are not happy > > with this addition. > > .................... > > So, as you can see, this is definitely alpha-quality code. >> Much remains to be done to make it really useful in >> production systems. But, I wanted to let folks get a chance >> to try it out and start reporting bugs. > > >I've been fooling with this in 5.0-CURRENT, and have have found >it to be a terribly, terribly cool feature. > [...skipping...] > >Lastly, I'm curious if it's possible that snapshots will be MFC'd >into 4.x at some point? or will this be a 5.0 and up only feature? I thought I would stir the waters again and ask how this new feature seems to be working out in -current. Is there much chance of it working with the 4.x-branch of releases? I realize there's a lot of work here, and that it may very well need to be tied into some of the smp-related work in 5.0 (wrt big-locks, etc), so I won't mind if it can't make it any sooner. Mainly I just wanted to reiterate that this sounds like a very cool feature (particularly given how huge disks are getting, a snapshot facility seems like a good use of that spare space), and that I'm looking forward to it whenever it does appear. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu Snapshots require a lot of hooks in the kernel to be fully functional. In addition there are still several nasty bugs in them which need to be worked through (I understand the problem, it is finding a clean fix that is the problem). For these reasons, I do not expect them to be MFC'd back to the 4.X kernel. I do hope to have them fully debugged and operational by the time that 5.0 is released. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 28 9:16:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id BDDC637B6A1 for ; Sun, 28 Jan 2001 09:16:21 -0800 (PST) Received: (qmail 686 invoked by uid 1000); 28 Jan 2001 17:14:49 -0000 Date: Sun, 28 Jan 2001 19:14:49 +0200 From: Peter Pentchev To: arch@FreeBSD.org Cc: chris@calldei.com, Randell Jesup Subject: Re: add -I ignoremask option to du(1) Message-ID: <20010128191449.A513@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, chris@calldei.com, Randell Jesup References: <20001214034803.C575@ringworld.oblivion.bg> <20001230012354.B20546@holly.calldei.com> <20001230095122.A4285@ringworld.oblivion.bg> <20001230160755.E20546@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rjesup@wgate.com on Tue, Jan 02, 2001 at 03:19:01PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So, what's the consensus on that one? :) Or should somebody give a roll call, and count votes? :) G'luck, Peter -- I've heard that this sentence is a rumor. On Tue, Jan 02, 2001 at 03:19:01PM -0500, Randell Jesup wrote: > Chris Costello writes: > >On Saturday, December 30, 2000, Peter Pentchev wrote: > >> This doesn't 1. exclude subdirectories; 2. provide per-directory stats. > >> In no way does it solve the problem I mentioned in the part you quoted - > >> excluding CVS/ subdirs from du output on a source tree. > > > > Sorry. Try: > > > >find . -maxdepth 1 \! \( -path '*CVS*' \) | xargs du -skc > > Nope. First, this considers files to be the same as directories. > Second, this only excludes CVS directories from the top level - deeper CVS > directories are included. > > Suffice it to say this series of attempts indicates that find/etc is > NOT a reasonable(*) way to implement this (reasonable) request. > > Add the argument to du(1). > > Randell > > (*): since no one here in what should be one of the most experienced group > of BSD hackers has posted a workable "unix-style" method, I conclude > that it's either not possible, or at least is so non-obvious as to be > effectively non-existant to any but the most experienced user. > > That's the problem with the old-school Unix philosophy of no program doing > more than one thing, and stringing them together - the "stringing them > together" part often ends up being as complicated a task as programming a > solution into the program itself - or even more complicated. That's ok > (sort of) if everyone using it is a programmer, and doesn't mind > reinventing the wheel every few days. It's not ok for 99% of users. > > Sure, shell's are programming languages - but I don't really want to write > a program just to find out how much disk space I'm using, or to sort the > output of ls (another old argument), etc. > > ps. yes, I am a shell-script hacker to a degree, and have written shells, > and used shells in all sorts of evil ways - but I don't want to tell > everyone else to try to do that. > > -- > Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) > rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 28 20:20:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D7D6837B400; Sun, 28 Jan 2001 20:19:51 -0800 (PST) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f0T4Jnf09875; Sun, 28 Jan 2001 23:19:49 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200101290419.f0T4Jnf09875@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Daniel Eischen Cc: arch@FreeBSD.org Subject: Re: libc_r badness In-Reply-To: Message from Daniel Eischen of "Sun, 28 Jan 2001 22:32:56 EST." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Jan 2001 23:19:36 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > [ Why is this developers and not -current??? ] (Actually, it should be -arch. That's a lapse in my judgement. Moving there...) > On Sun, 28 Jan 2001, Brian F. Feldman wrote: > > The only problem I have is that libc_r still doesn't depend on libc, so ALL > > old apps that are linked in what was previously the correct way immediately > > break. However, chances are it's so hard to make a correctly compiled old > > binary with just libc_r and not libc, there are likely to be many that don't > > break ;) > > John Polstra made the -pthread option work for the new libc_r (so it > automatically links in both libc_r and libc) a few days ago. This option > should be deprecated eventually, so one shouldn't get used to it. But > this will allow ports that haven't been modified yet to continue to work. > > This is -current, and a HEADS UP was sent saying that you have to rebuild > your threaded apps. It's breaking it gratuitiously though. What's the reasoning behind not having libc_r depend on libc? You can't use libc_r without libc, and you certainly would have to go through a hell of a lot of trouble to replace libc with something libc_r would link with. What good does libc_r do linking standalone? > > Is there a good reason not to do this? > > Yes, because libc_r shouldn't contain libc. That was the whole point > of the changes I recently made to libc and libc_r. That doesn't make it contain libc. It makes it depend on libc. Tell me, why can't libc_r depend on libc, and what good does libc_r do without libc? And, if libc_r is useless without libc, why can't it depend on libc automatically? I still see the same benefit of having libc be modular whether or not libc_r sticks it in the ELF library dependency section for its own use. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 28 22:46:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 97AA837B404 for ; Sun, 28 Jan 2001 22:45:51 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f0T6jQW23655; Mon, 29 Jan 2001 08:45:29 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101290645.f0T6jQW23655@gratis.grondar.za> To: "Sue Wainer" Cc: "Freebsd-Arch" Subject: Re: kldunload, and calling uninit function References: In-Reply-To: ; from "Sue Wainer" "Sun, 28 Jan 2001 02:43:42 EST." Date: Mon, 29 Jan 2001 08:45:24 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am having problems getting my SYSUNINIT function called when I do a > kldunload. Is there a particular reason that you need to use SYS[UN]INIT? I tried those, and had little luck. What workes much better for me was the "modevent" method - look in sys/dev/random/randomdev.c > I have reduced my source file to containing nothing more than > a sysinit and sysunit function, both of which only print out a > diagnostic. I believe the setdef files look OK. I have traced through > the loader symbol look up function, and the sysinit_set name is there, > but the sysuninit_set name is not. I do get the diagnostic printed > from my sysinit function. There is very little use of the SYSUNINIT macro in the kernel, and I believe it to be broken, as last time I used it, I got compile errors from it. Give me a yell if you need a hand getting the (better) MODULE_* macros going instead. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 2:52:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 5471237B400 for ; Mon, 29 Jan 2001 02:52:32 -0800 (PST) Received: (from brian@localhost) by storm.FreeBSD.org.uk (8.11.1/8.11.1) id f0TAqVK58112 for freebsd-arch@FreeBSD.org; Mon, 29 Jan 2001 10:52:31 GMT (envelope-from brian) Date: Mon, 29 Jan 2001 10:52:31 GMT From: Brian Somers Message-Id: <200101291052.f0TAqVK58112@storm.FreeBSD.org.uk> To: freebsd-arch@FreeBSD.org Subject: Cloned open support Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm considering having a crack at adding support for cloned opens. Before I start, I guess I've got two questions: 1. Is anybody else doing this. 2. Given that I'll need to change the d_open prototype (and thus cdevsw), I'm going to affect every device driver in the tree - although only changing the first arg to a (dev_t) pointer, making things pretty easy to change and not too unexpected for anyone that's written sysv drivers. Is it acceptable to simply not support old drivers ? I've considered trying to do things so that they're backwards compatible, but I think the answer is that it'd be too much of a crutch in the future. Ok, ok, three questions ! 3. Should I ask for review anywhere else besides here ? Ta. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 3:43:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 1736437B400 for ; Mon, 29 Jan 2001 03:43:29 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TBhWK20364; Mon, 29 Jan 2001 12:43:32 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 10:52:31 GMT." <200101291052.f0TAqVK58112@storm.FreeBSD.org.uk> Date: Mon, 29 Jan 2001 12:43:32 +0100 Message-ID: <20362.980768612@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291052.f0TAqVK58112@storm.FreeBSD.org.uk>, Brian Somers writes: >Hi, > >I'm considering having a crack at adding support for cloned opens. >Before I start, I guess I've got two questions: > >1. Is anybody else doing this. Not actively. >2. Given that I'll need to change the d_open prototype (and > thus cdevsw) I'm not sure that is really a good idea. If you look at the device name clone stuff I think I have made it possible to handle it there. The idea being that you call it on "/dev/pty" and it will clone "/dev/pty38" for you and return the dev_t for that. You then complete the open on that dev_t. I have not quite thought it through though. Either way, I think cloning open should be kept out of d_open one way or another. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 4:31:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id A53B437B404 for ; Mon, 29 Jan 2001 04:30:50 -0800 (PST) Received: (from brian@localhost) by storm.FreeBSD.org.uk (8.11.1/8.11.1) id f0TCSgP60147; Mon, 29 Jan 2001 12:28:42 GMT (envelope-from brian) Date: Mon, 29 Jan 2001 12:28:42 GMT From: Brian Somers Message-Id: <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk> To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.org Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 12:43:32 +0100" <20362.980768612@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >2. Given that I'll need to change the d_open prototype (and > > thus cdevsw) > > I'm not sure that is really a good idea. > > If you look at the device name clone stuff I think I have made > it possible to handle it there. > > The idea being that you call it on "/dev/pty" and it will clone > "/dev/pty38" for you and return the dev_t for that. You then > complete the open on that dev_t. I have not quite thought > it through though. > > Either way, I think cloning open should be kept out of d_open > one way or another. The thing is that I believe the driver needs to be able to decide what minor number will be opened. This idea is taken from the Solaris implementation. For example, I have a theoretical driver that does this: o Makes minor 0 available in /dev as a control device o Makes minor 1 available as something that'll be cloned. o The descriptor returned from opening minor 1 may itself me made available via namefs (a vfs that allows you to turn a descriptor into a mountpoint to give other users access to it) and may be opened again. Such descriptors are not cloned. Although this sounds exotic, it's quite practical, and impossible to do outside of the driver. I think deciding on the minor outside the driver is too limiting. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 4:45:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 58AB137B402 for ; Mon, 29 Jan 2001 04:44:58 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TCj1K20822; Mon, 29 Jan 2001 13:45:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.org Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 12:28:42 GMT." <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk> Date: Mon, 29 Jan 2001 13:45:01 +0100 Message-ID: <20820.980772301@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk>, Brian Somers writes: >The thing is that I believe the driver needs to be able to >decide what minor number will be opened. This idea is taken >from the Solaris implementation. For example, I have a >theoretical driver that does this: I'm not arguing that the driver should not do the decisionmaking, only that it should not be done in the d_open routine. By the time you get to the d_open, you have already committed, and possibly reused or even shared a vnode with somebody else. If you do it at namei time, you can create the right vnode before you go (further) down the open path. That is how our cloning works: When devfs doesn't find what you are looking for, it will poll all drivers and ask if they can create the dev_t for it. If one of the drivers returns a dev_t, a devfs vnode is instantiated and everybody are happy. >o Makes minor 0 available in /dev as a control device No worries: make_dev(..., minor = 0, "/dev/foo"); >o Makes minor 1 available as something that'll be cloned. Nope, decide on a name which is cloned; and recognize it in foo_clone(dev_t *dev, ...) Allocate the next free minor and if (strcmp(name, "fooclone")) return; ... /* find free minor */ *dev = make_dev(..., minor = n, "dev/foo%03d", n); return; This should work as far as I know. Userland needs to find the right pathname, preferably without too much magic. fstat(2) + devname(3) is probably doing that just fine for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 4:48:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3080F37B404; Mon, 29 Jan 2001 04:48:04 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA25823; Mon, 29 Jan 2001 07:47:41 -0500 (EST) Date: Mon, 29 Jan 2001 07:47:41 -0500 (EST) From: Daniel Eischen To: "Brian F. Feldman" Cc: arch@FreeBSD.org Subject: Re: libc_r badness In-Reply-To: <200101290419.f0T4Jnf09875@green.dyndns.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 On Sun, 28 Jan 2001, Brian F. Feldman wrote: > Daniel Eischen wrote: > > [ Why is this developers and not -current??? ] > > (Actually, it should be -arch. That's a lapse in my judgement. Moving > there...) > > > On Sun, 28 Jan 2001, Brian F. Feldman wrote: > > > The only problem I have is that libc_r still doesn't depend on libc, so ALL > > > old apps that are linked in what was previously the correct way immediately > > > break. However, chances are it's so hard to make a correctly compiled old > > > binary with just libc_r and not libc, there are likely to be many that don't > > > break ;) > > > > John Polstra made the -pthread option work for the new libc_r (so it > > automatically links in both libc_r and libc) a few days ago. This option > > should be deprecated eventually, so one shouldn't get used to it. But > > this will allow ports that haven't been modified yet to continue to work. > > > > This is -current, and a HEADS UP was sent saying that you have to rebuild > > your threaded apps. > > It's breaking it gratuitiously though. What's the reasoning behind not > having libc_r depend on libc? You can't use libc_r without libc, and you > certainly would have to go through a hell of a lot of trouble to replace > libc with something libc_r would link with. What good does libc_r do > linking standalone? This is true, but it still seems like another band-aid. The version bump in -current is only 2 months old. It's not like this is -stable and affecting a large user base. > > > Is there a good reason not to do this? > > > > Yes, because libc_r shouldn't contain libc. That was the whole point > > of the changes I recently made to libc and libc_r. > > That doesn't make it contain libc. It makes it depend on libc. Tell me, > why can't libc_r depend on libc, and what good does libc_r do without libc? > And, if libc_r is useless without libc, why can't it depend on libc > automatically? I still see the same benefit of having libc be modular > whether or not libc_r sticks it in the ELF library dependency section for > its own use. Libpthread does not depend on libc under Solaris. I am still against this change. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6: 2:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 17C1E37B404 for ; Mon, 29 Jan 2001 06:02:17 -0800 (PST) Received: (from brian@localhost) by storm.FreeBSD.org.uk (8.11.1/8.11.1) id f0TE0hY61432; Mon, 29 Jan 2001 14:00:43 GMT (envelope-from brian) Date: Mon, 29 Jan 2001 14:00:43 GMT From: Brian Somers Message-Id: <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk> To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.org Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 13:45:01 +0100" <20820.980772301@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >The thing is that I believe the driver needs to be able to > >decide what minor number will be opened. This idea is taken > >from the Solaris implementation. For example, I have a > >theoretical driver that does this: > > I'm not arguing that the driver should not do the decisionmaking, > only that it should not be done in the d_open routine. > > By the time you get to the d_open, you have already committed, > and possibly reused or even shared a vnode with somebody else. I was thinking along the lines of just VN_RELE'ing it and making up another at this point. > If you do it at namei time, you can create the right vnode > before you go (further) down the open path. > > That is how our cloning works: > > When devfs doesn't find what you are looking for, it will > poll all drivers and ask if they can create the dev_t for it. > > If one of the drivers returns a dev_t, a devfs vnode is > instantiated and everybody are happy. > > >o Makes minor 0 available in /dev as a control device > > No worries: > > make_dev(..., minor = 0, "/dev/foo"); > > >o Makes minor 1 available as something that'll be cloned. > > Nope, decide on a name which is cloned; and recognize it > in foo_clone(dev_t *dev, ...) Allocate the next free minor and > > if (strcmp(name, "fooclone")) > return; > ... /* find free minor */ > *dev = make_dev(..., minor = n, "dev/foo%03d", n); > return; > > This should work as far as I know. Userland needs to find the > right pathname, preferably without too much magic. fstat(2) + > devname(3) is probably doing that just fine for that. Hmm, I'm not sure I like the idea of a user being able to open things they can't see beforehand (permissions seem to be one problem)... My thoughts were along the lines of doing the make_dev(... minor=1, "dev/fooclone" ...) in foo_attach() as we do now, then tweaking the dev_t in foo_open(). The namei() bit is necessary to get to the point that you know you're talking about a device and can call any foo_clone() etc. So, how about this then (or is this what you're already saying): make_dev() is called during attach as normal. devfs's vfs lookup routine checks if the cdevsw of the thing it finds has D_CLONE, and if so asks the owning driver via a new foo_isclone() cdevsw function if it'd like to change the dev_t it's about to give back to the namei side of things. Would that work ? I haven't looked at the devfs stuff, but I wouldn't imagine there would be any problems doing this... > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6: 2:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 40DEC37B402 for ; Mon, 29 Jan 2001 06:02:24 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0TE2A451479; Mon, 29 Jan 2001 06:02:10 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101291402.f0TE2A451479@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: <200101291052.f0TAqVK58112@storm.FreeBSD.org.uk> Date: Mon, 29 Jan 2001 06:02:10 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers wrote: > Hi, > > I'm considering having a crack at adding support for cloned opens. > Before I start, I guess I've got two questions: > > 1. Is anybody else doing this. > > 2. Given that I'll need to change the d_open prototype (and > thus cdevsw), I'm going to affect every device driver in the > tree - although only changing the first arg to a (dev_t) > pointer, making things pretty easy to change and not too > unexpected for anyone that's written sysv drivers. Not necessary. dev_t *is* a pointer. Add a flag to the device flags to indicate that it allows clone opens, and maybe teach specfs a little about it (ie: that the unit will be reassigned on a clone open) and you're done. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:14:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id AE9CC37B69C for ; Mon, 29 Jan 2001 06:13:50 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TEDtK21281; Mon, 29 Jan 2001 15:13:55 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.org Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 14:00:43 GMT." <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk> Date: Mon, 29 Jan 2001 15:13:55 +0100 Message-ID: <21279.980777635@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk>, Brian Somers writes: >Hmm, I'm not sure I like the idea of a user being able to open >things they can't see beforehand (permissions seem to be one >problem)... Permissions are controled by the driver with the make_dev() call. Later when we get a devd(8) daemon knitted together it will get the chance to set the modes before the open completes. >make_dev() is called during attach as normal. >devfs's vfs lookup routine checks if the cdevsw of the thing it >finds has D_CLONE, and if so asks the owning driver via a new >foo_isclone() cdevsw function if it'd like to change the dev_t >it's about to give back to the namei side of things. The clone function is not tied to a devsw{}, but uses an EVENTHANDLER but otherwise that is what happens already. The reason I have not tied the clone function to the devsw is that it is not strictly a function of any particular minor node, but rather a fully fledged driver method. The cdevsw-> is per device-node (or per minor if you want), the choice of EVENTHANDLER is more a matter of not reinventing the bikeshed once more than one of particular suitability. It does have the right qualities though. Look at some of the various *_clone routines to see how it works, ccd_clone(), pty_clone() and disk_clone() are all very instructive in each their own way. Is there any functionality you need which this cloning doesn't provide you ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:16:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 5731037B69D for ; Mon, 29 Jan 2001 06:15:58 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TEFvK21318; Mon, 29 Jan 2001 15:15:57 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 06:02:10 PST." <200101291402.f0TE2A451479@mobile.wemm.org> Date: Mon, 29 Jan 2001 15:15:57 +0100 Message-ID: <21316.980777757@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291402.f0TE2A451479@mobile.wemm.org>, Peter Wemm writes: >Brian Somers wrote: >> Hi, >> >> I'm considering having a crack at adding support for cloned opens. >> Before I start, I guess I've got two questions: >> >> 1. Is anybody else doing this. >> >> 2. Given that I'll need to change the d_open prototype (and >> thus cdevsw), I'm going to affect every device driver in the >> tree - although only changing the first arg to a (dev_t) >> pointer, making things pretty easy to change and not too >> unexpected for anyone that's written sysv drivers. > >Not necessary. dev_t *is* a pointer. Add a flag to the device flags to >indicate that it allows clone opens, and maybe teach specfs a little about >it (ie: that the unit will be reassigned on a clone open) and you're done. But but but... we already *have* cloning Peter. It doesn't need a dedicated minordevice and it works for everything but vinum(4), and that is not because it cannot do what vinum(4) needs, but because vinum(4) needs somebody to do it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:23:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id EE2F437B6A0 for ; Mon, 29 Jan 2001 06:23:14 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0TEMs451812; Mon, 29 Jan 2001 06:22:54 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101291422.f0TEMs451812@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: <21316.980777757@critter> Date: Mon, 29 Jan 2001 06:22:54 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <200101291402.f0TE2A451479@mobile.wemm.org>, Peter Wemm writes: > >Brian Somers wrote: > >> Hi, > >> > >> I'm considering having a crack at adding support for cloned opens. > >> Before I start, I guess I've got two questions: > >> > >> 1. Is anybody else doing this. > >> > >> 2. Given that I'll need to change the d_open prototype (and > >> thus cdevsw), I'm going to affect every device driver in the > >> tree - although only changing the first arg to a (dev_t) > >> pointer, making things pretty easy to change and not too > >> unexpected for anyone that's written sysv drivers. > > > >Not necessary. dev_t *is* a pointer. Add a flag to the device flags to > >indicate that it allows clone opens, and maybe teach specfs a little about > >it (ie: that the unit will be reassigned on a clone open) and you're done. > > But but but... we already *have* cloning Peter. It doesn't need > a dedicated minordevice and it works for everything but vinum(4), > and that is not because it cannot do what vinum(4) needs, but > because vinum(4) needs somebody to do it. Who said anything about vinum? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:25:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 9AABA37B69E for ; Mon, 29 Jan 2001 06:24:56 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0TEOc451827; Mon, 29 Jan 2001 06:24:38 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101291424.f0TEOc451827@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: <20820.980772301@critter> Date: Mon, 29 Jan 2001 06:24:38 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk>, Brian Somers wri tes: > >o Makes minor 0 available in /dev as a control device > > No worries: > > make_dev(..., minor = 0, "/dev/foo"); > > >o Makes minor 1 available as something that'll be cloned. > > Nope, decide on a name which is cloned; and recognize it > in foo_clone(dev_t *dev, ...) Allocate the next free minor and > > if (strcmp(name, "fooclone")) > return; > ... /* find free minor */ > *dev = make_dev(..., minor = n, "dev/foo%03d", n); > return; > > This should work as far as I know. Userland needs to find the > right pathname, preferably without too much magic. fstat(2) + > devname(3) is probably doing that just fine for that. Well, how do we support Unix98 /dev/ptmx then? This is not an academic question, Linux apps are starting to do it this way and if we want to run anything that uses ptys.... int fdm fds; char *slavename; extern char *ptsname(); fdm = open("/dev/ptmx", O_RDWR); /* open master */ grantpt(fdm); /* change permission ofslave */ unlockpt(fdm); /* unlock slave */ slavename = ptsname(fdm); /* get name of slave */ fds = open(slavename, O_RDWR); /* open slave */ Opening the master allocates you a private unit of the device with its own minor number. grantpt() is a wrapper that calls a setuid program to chown the /dev/pts/%03d slave to the new owner. unlockpt() does an ioctl on the master that tells it to revoke all access to the slave and kill off any existing processes that have fd's to it. It allows the new process to now open it with guarantees that there are no races (you now own it, mode 600) and everything/everyone esle got nuked. You can then open the slave at your leisure. There is no need to "create" /dev/ptm/%03d as it is all multiplexed off the single node. One /dev/pts/%03d is created when a master node is opened. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:27:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 1D0D337B69E for ; Mon, 29 Jan 2001 06:27:33 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TERWK21536; Mon, 29 Jan 2001 15:27:32 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 06:22:54 PST." <200101291422.f0TEMs451812@mobile.wemm.org> Date: Mon, 29 Jan 2001 15:27:32 +0100 Message-ID: <21534.980778452@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291422.f0TEMs451812@mobile.wemm.org>, Peter Wemm writes: >> But but but... we already *have* cloning Peter. It doesn't need >> a dedicated minordevice and it works for everything but vinum(4), >> and that is not because it cannot do what vinum(4) needs, but >> because vinum(4) needs somebody to do it. > >Who said anything about vinum? I did. I'm puzzled at what it is that Brian wants to do which cannot be done with our current cloning code. I was afraid that mentioning things DEVFS/clone can/cannot do would trigger a pointless digression into who is responsible for adding DEVFS support to vinum, I mentioned that specifically as a premptive strike :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:39:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 1646D37B6A7 for ; Mon, 29 Jan 2001 06:39:32 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TEdSK21578; Mon, 29 Jan 2001 15:39:28 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 06:24:38 PST." <200101291424.f0TEOc451827@mobile.wemm.org> Date: Mon, 29 Jan 2001 15:39:27 +0100 Message-ID: <21576.980779167@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291424.f0TEOc451827@mobile.wemm.org>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> In message <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk>, Brian Somers wri > tes: > >> >o Makes minor 0 available in /dev as a control device >> >> No worries: >> >> make_dev(..., minor = 0, "/dev/foo"); >> >> >o Makes minor 1 available as something that'll be cloned. >> >> Nope, decide on a name which is cloned; and recognize it >> in foo_clone(dev_t *dev, ...) Allocate the next free minor and >> >> if (strcmp(name, "fooclone")) >> return; >> ... /* find free minor */ >> *dev = make_dev(..., minor = n, "dev/foo%03d", n); >> return; >> >> This should work as far as I know. Userland needs to find the >> right pathname, preferably without too much magic. fstat(2) + >> devname(3) is probably doing that just fine for that. > >Well, how do we support Unix98 /dev/ptmx then? This is not an academic >question, Linux apps are starting to do it this way and if we want to run >anything that uses ptys.... > > int fdm fds; > char *slavename; > extern char *ptsname(); > > fdm = open("/dev/ptmx", O_RDWR); /* open master */ > grantpt(fdm); /* change permission ofslave */ > unlockpt(fdm); /* unlock slave */ > slavename = ptsname(fdm); /* get name of slave */ > fds = open(slavename, O_RDWR); /* open slave */ > >Opening the master allocates you a private unit of the device with its own >minor number. We will support it just like that. pts_clone() will recognize the "ptmx" name. Create a new dev_t and return it. Getting the name can be done with fstat(2) and devname(3). A transformation to slave name is needed but that will always be needed. and it will DTRT. In fact, I think you can implement this in less than 20 lines of code total. In pty_clone() you add recognition for "ptmx" as a name, but create the pty with the "real" name (pty%c%c). The rest of the code is needed in the ptsname() function. I'm not quite sure what the grantpt() and unlockpt() does, but it sounds like ioctl(2) implemeted stuff on the fdm handle, being dealt with in the pty driver. >grantpt() is a wrapper that calls a setuid program to chown the /dev/pts/%03d >slave to the new owner. ARGH! -- Ohh, allright, you said Linux. You can do that in the pty_clone() function in the make_dev() call so this can become a null function. >unlockpt() does an ioctl on the master that tells it to revoke all access >to the slave and kill off any existing processes that have fd's to it. It >allows the new process to now open it with guarantees that there are no >races (you now own it, mode 600) and everything/everyone esle got nuked. Check, we will not even open a slave if this hasn't been done already. >You can then open the slave at your leisure. > >There is no need to "create" /dev/ptm/%03d as it is all multiplexed off >the single node. One /dev/pts/%03d is created when a master node is opened. We don't have that choice, we need to have separate vnodes on the master side also or we can't track the open/dup/close counts reliably. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 6:47: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id AC8BC37B402 for ; Mon, 29 Jan 2001 06:46:48 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TEklK21636; Mon, 29 Jan 2001 15:46:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) Cc: Peter Wemm , Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 15:39:27 +0100." <21576.980779167@critter> Date: Mon, 29 Jan 2001 15:46:47 +0100 Message-ID: <21634.980779607@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <21576.980779167@critter>, Poul-Henning Kamp writes: >>Well, how do we support Unix98 /dev/ptmx then? This is not an academic >>question, Linux apps are starting to do it this way and if we want to run >>anything that uses ptys.... >> >> int fdm fds; >> char *slavename; >> extern char *ptsname(); >> >> fdm = open("/dev/ptmx", O_RDWR); /* open master */ >> grantpt(fdm); /* change permission ofslave */ >> unlockpt(fdm); /* unlock slave */ >> slavename = ptsname(fdm); /* get name of slave */ >> fds = open(slavename, O_RDWR); /* open slave */ >> >>Opening the master allocates you a private unit of the device with its own >>minor number. > >We will support it just like that. pts_clone() will recognize the "ptmx" >name. Create a new dev_t and return it. Getting the name can be done >with fstat(2) and devname(3). A transformation to slave name is needed >but that will always be needed. and it will DTRT. > >In fact, I think you can implement this in less than 20 lines of code total. There is one more thing you have to do: in fs/devfs/devfs_vnops.c you need to modify the loop right before the "notfound:" label to recognize the new entry by the dev_t instead of the name, since the clone function creates a dev_t for another name. That will probably be faster in the normal case as well... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 9:26:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from web1.renley.com (unknown [210.176.231.28]) by hub.freebsd.org (Postfix) with ESMTP id 2583B37B69B; Mon, 29 Jan 2001 09:25:30 -0800 (PST) Received: from 210.176.231.28 (unverified [203.149.188.102]) by web1.renley.com (Rockliffe SMTPRA 2.1.2) with SMTP id ; Tue, 30 Jan 2001 01:34:00 +0800 Date: Tue, 30 Jan 2001 01:34:00 +0800 Message-ID: Reply-To: l705723712@yahoo.com From: l705723712@yahoo.com To: 20guido@freebsd.org Subject:狂人資訊軟體更新資訊 本次新增一百三十多片．．．．．．狂人資訊軟體更新資訊狂人資訊軟體更新資訊 本次新增一百三十多片．．．狂人資訊軟體更新資訊 本次新增一百三十多片．． MIME-Version: 1.0 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: base64 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1MYW5ndWFnZSIg Y29udGVudD0iemgtdHciPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJ ZCIgY29udGVudD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+q2Wpubr0 r7g8L3RpdGxlPg0KPC9oZWFkPg0KDQo8Ym9keT4NCg0KPGRpdiBhbGlnbj0iY2VudGVyIj4N CiAgPGNlbnRlcj4NCiAgPHRhYmxlIGJvcmRlcj0iMSIgd2lkdGg9IjQ1MSIgaGVpZ2h0PSIx MyI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSI0NTEiIGhlaWdodD0iMTMiIGJnY29s b3I9IiM4MDgwODAiPjxzdHJvbmc+DQogICAgICAgIDxhIGhyZWY9Imh0dHA6Ly9nby50by9j cmF6eXgxIj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiNGRkZGRkYiPg0KICAgICAgICA8bWFy cXVlZSBhbGlnbj0ibWlkZGxlIiBiZWhhdmlvcj0iYWx0ZXJuYXRlIj6rZam5qGekSLjqsFSl 5qx5pKSk37r0r7g8L21hcnF1ZWU+DQogICAgICAgIDwvZm9udD4NCiAgICAgICAgPC9hPg0K ICAgICAgICA8L3N0cm9uZz48L3RkPg0KICAgIDwvdHI+DQogIDwvdGFibGU+DQogIDwvY2Vu dGVyPg0KPC9kaXY+DQo8Zm9udCBTSVpFPSIzIj4NCjxibG9ja3F1b3RlPg0KICA8YmxvY2tx dW90ZT4NCiAgICA8YmxvY2txdW90ZT4NCiAgICAgIDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBj b2xvcj0iI0ZGMDAwMCI+oXWp2rW0sbWo/KF2pbuvuLBUrqe90MJJv++hQDxhIGhyZWY9Im1h aWx0bzpmcmVlYmFua25vQDEwOC56em4uY29tIj6zb7jMPC9hPjwvZm9udD48L3A+DQogICAg ICA8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPqW7r7imYqasqOyxeqq6 pl7C0K7JoUGlsrftusmzdKjDq0/D0qdSsKOxeqq6uOquxqFDpbuvuKjDpKO3UbN5pqi0Y6nK tGDA9KFJPC9mb250PjwvcD4NCiAgICAgIDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0i I0ZGMDAwMCI+oXXEQLdOsbWo/KF2pbuvuLBUrqe90MJJv++hQDxhIGhyZWY9Im1haWx0bzpm cmVlYmFua3llc0AxMDguenpuLmNvbSI+s2+4zDwvYT48L2ZvbnQ+PC9wPg0KICAgICAgPHAg YWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIjRkYwMDAwIj6lu6+4pmKmrKjssXqquqZewtCr 4aFBpbKxTqhDprizzLdzuOqwVLBluUaxeqq6q0i9Y6FDsXqqurC3sWShQbROrE+n2q3Mqrqw XbRJoUk8L2ZvbnQ+PC9wPg0KICAgICAgPHAgYWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIj RkYwMDAwIj6hdaZzpN+vfcNhoXalu6+4q0i9Y6rMvdCvZLdOPC9mb250PjwvcD4NCiAgICAg IDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+pnCqR7F6rE+kz6v+qKmk SKRooUG90L1UqXexeqq6uXG4o6S6s6OsT6W/qqmqurNuxemhQzwvZm9udD48L3A+DQogICAg ICA8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPqZwqkexeqV1rE+3Ua5p snuxeqq6pVykT6FBoXWmYbJ5rE+26qq6oXY8L2ZvbnQ+PC9wPg0KICAgICAgPHAgYWxpZ249 ImxlZnQiPjxmb250IGNvbG9yPSIjRkYwMDAwIj6mcKpHsXqsT6ZQpuaqurjcoUG0Tr3Qptum 5qtPraunYaFJPC9mb250PjwvcD4NCiAgICA8L2Jsb2NrcXVvdGU+DQogIDwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvZm9udD4NCjxwIGFsaWduPSJjZW50ZXIiPqFAPC9wPg0K PHAgYWxpZ249ImNlbnRlciI+PGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL2Z0cC53b3Js ZC5uZXQudHcvfmNvb2xidWcvMDAuanBnIiB3aWR0aD0iNjQwIiBoZWlnaHQ9IjQyMCI+PC9w Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEgNClBNIDEx OjQ2OjU4DQoyMDAxLzEvMjkNCjEwMDAwMw0KIj48L2E+DQo8L0hUTUw+DTxIVE1MPg0KPEEg bmFtZT0iDQqoZ6RIDQpQTSAxMTo0NzozMA0KMjAwMS8xLzI5DQoxMDAwMDMNCiI+PC9hPg0K PC9IVE1MPg08SFRNTD4NCjxBIG5hbWU9Ig0KqGekSA0KQU0gMTI6MTg6NTINCjIwMDEvMS8z MA0KMTAwMDAzDQoiPjwvYT4NCjwvSFRNTD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEi46rBU s27F6afzt3O46rBUIKW7pri3c7xXpECmyqRUpFGmaKT5oUShRKFEqGekSLjqsFSzbsXpp/O3 c7jqsFQgpbumuLdzvFekQKbKpFQNCkFNIDEyOjIwOjU1DQoyMDAxLzEvMzANCjEwMDAwMw0K Ij48L2E+DQo8L0hUTUw+DTxIVE1MPg0KPEEgbmFtZT0iDQqoZ6RIuOqwVLNuxemn87dzuOqw VCClu6a4t3O8V6RApsqkVKRRpmik+aFEqGekSLjqsFSzbsXpp/MNCkFNIDEyOjIxOjA1DQoy MDAxLzEvMzANCjEwMDAwMw0KIj48L2E+DQo8L0hUTUw+DTxIVE1MPg0KPEEgbmFtZT0iDQqo Z6RIuOqwVLNuxekNCkFNIDEyOjM3OjEzDQoyMDAxLzEvMzANCjEwMDAwMw0KIj48L2E+DQo8 L0hUTUw+DTxIVE1MPg0KPEEgbmFtZT0iDQqoZ6RIuOqwVLNuxemn87dzuOqwVCClu6a4DQpB TSAxMjo1NDo0NA0KMjAwMS8xLzMwDQoxMDAwMDMNCiI+PC9hPg0KPC9IVE1MPg08SFRNTD4N CjxBIG5hbWU9Ig0KqGekSLjqsFSzbsXpp/O3c7jqsFQgpbumuLdzvFekQKbKpFSkUaZopPmh RKFEoUShRA0KQU0gMDE6MDc6MjINCjIwMDEvMS8zMA0KMTAwMDAzDQoiPjwvYT4NCjwvSFRN TD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEi46rBUs27F6afzt3O46rBUIKW7pri3c7xXpECm yqRUpFGmaA0KQU0gMDE6MTE6NTgNCjIwMDEvMS8zMA0KMTAwMDAzDQoiPjwvYT4NCjwvSFRN TD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEi46rBUs27F6afzt3O46rBUIKW7pri3c7xXpECm yqRUpFGmaKT5oUShRKFEDQpBTSAwMToxNDowNw0KMjAwMS8xLzMwDQoxMDAwMDMNCiI+PC9h Pg0KPC9IVE1MPg08SFRNTD4NCjxBIG5hbWU9Ig0KqGekSLjqsFSzbsXpp/O3c7jqsFQgpbum uLdzvFcNCkFNIDAxOjI2OjI1DQoyMDAxLzEvMzANCjEwMDAwMw0KIj48L2E+DQo8L0hUTUw+ DQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 9:45:48 2001 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 BD04F37B400; Mon, 29 Jan 2001 09:45:30 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f0THjT251763; Mon, 29 Jan 2001 09:45:29 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0THjTK57657; Mon, 29 Jan 2001 09:45:29 -0800 (PST) (envelope-from jdp) Date: Mon, 29 Jan 2001 09:45:29 -0800 (PST) Message-Id: <200101291745.f0THjTK57657@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: green@freebsd.org Subject: Re: libc_r badness In-Reply-To: <200101290419.f0T4Jnf09875@green.dyndns.org> References: <200101290419.f0T4Jnf09875@green.dyndns.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200101290419.f0T4Jnf09875@green.dyndns.org>, Brian F. Feldman wrote: > Tell me, why can't libc_r depend on libc, and what good does libc_r > do without libc? And, if libc_r is useless without libc, why can't > it depend on libc automatically? I still see the same benefit of > having libc be modular whether or not libc_r sticks it in the ELF > library dependency section for its own use. Those automatic dependencies only work for dynamically-linked programs. Statically-linked programs wouldn't be helped by this. Generally speaking, everything is useless without libc. Our now-defunct temporary situation of using libc _or_ libc_r is the only exception I'm aware of except for special-case stand-alone components which don't execute in a normal program context. Since everything needs libc, it is not recorded as an explicit dependency. Instead, the compiler provides it automatically unless you ask it not to with -nostdlib. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch鐷yam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 10:11:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 75C7637B400; Mon, 29 Jan 2001 10:11:19 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0TIBJ454801; Mon, 29 Jan 2001 10:11:19 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101291811.f0TIBJ454801@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: arch@FreeBSD.ORG Cc: green@FreeBSD.ORG Subject: Re: libc_r badness In-Reply-To: <200101291745.f0THjTK57657@vashon.polstra.com> Content-Transfer-Encoding: 8bit Date: Mon, 29 Jan 2001 10:11:19 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > In article <200101290419.f0T4Jnf09875@green.dyndns.org>, > Brian F. Feldman wrote: > > > Tell me, why can't libc_r depend on libc, and what good does libc_r > > do without libc? And, if libc_r is useless without libc, why can't > > it depend on libc automatically? I still see the same benefit of > > having libc be modular whether or not libc_r sticks it in the ELF > > library dependency section for its own use. > > Those automatic dependencies only work for dynamically-linked > programs. Statically-linked programs wouldn't be helped by this. There are two issues.. One is to have -lc_r on its own pull in libc to avoid POLA for apps that use ld(1) directly (doesn't work for static, no big deal). The second (seperate) issue is exising dynamic binaries on people's -current systems (eg: ports). Adding the LDADD+= -lc repairs the existing binaries that were linked with the old gcc specs and libc_r. I do not envy recompiling my handful of threaded apps. Not all are from ports. > Generally speaking, everything is useless without libc. Our > now-defunct temporary situation of using libc _or_ libc_r is the only > exception I'm aware of except for special-case stand-alone components > which don't execute in a normal program context. Since everything > needs libc, it is not recorded as an explicit dependency. Instead, > the compiler provides it automatically unless you ask it not to with > -nostdlib. Actually, there might be a good reason to do this.. (ie: add -lc_r) - it records the specific major version of libc that a program was compiled/ linked against. eg: libfoo.so.3 depends on libc.so.4 (old sigset). meanwhile you have libc.so -> libc.so.5 on your system and compile with the older -lfoo.. If libfoo.so.3 depended specifically on the older libc, then it will call sigaction() etc with the (old) sigsets that it (ie: osigaction) expects. The main program (having been linked against the new will be passing around new sigsets and will call sigaction in libc.so.5 with the new sigsets. Speaking from experience, we've had a lot of pain at yahoo over this implied dependency on "whatever version of libc that the calling program was linked against". I expect that having two versions of libc loaded wouldn't some new wrinkles, but it outright does not work without it. In a few cases we've used LD_PRELOAD and a few other hacks and relinks to get it to the point where we have several versions of a .so loaded and it works of sorts. (Yes, a recompile does follow, but we run into this when we have 4.x systems and infrastructure libs that have 3.x binary application packages pushed onto them). Anyway, that's something to think about. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 10:34:50 2001 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 41FFB37B6E5 for ; Mon, 29 Jan 2001 10:34:31 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f0TIYN252031; Mon, 29 Jan 2001 10:34:23 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0TIYL957823; Mon, 29 Jan 2001 10:34:21 -0800 (PST) (envelope-from jdp) Date: Mon, 29 Jan 2001 10:34:21 -0800 (PST) Message-Id: <200101291834.f0TIYL957823@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: peter@netplex.com.au Subject: Re: libc_r badness In-Reply-To: <200101291811.f0TIBJ454801@mobile.wemm.org> References: <200101291811.f0TIBJ454801@mobile.wemm.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200101291811.f0TIBJ454801@mobile.wemm.org>, Peter Wemm wrote: > John Polstra wrote: > > > > Those automatic dependencies only work for dynamically-linked > > programs. Statically-linked programs wouldn't be helped by this. > > There are two issues. You raise some good points. > One is to have -lc_r on its own pull in libc to avoid POLA for apps > that use ld(1) directly (doesn't work for static, no big deal). The > second (seperate) issue is exising dynamic binaries on people's > -current systems (eg: ports). Adding the LDADD+= -lc repairs the > existing binaries that were linked with the old gcc specs and > libc_r. I do not envy recompiling my handful of threaded apps. Not > all are from ports. OK, I misunderstood the goal when I replied before. I can see that it would be helpful to have libc_r depend explicitly on libc in order to make existing binaries work again. > > Since everything needs libc, it is not recorded as an explicit > > dependency. Instead, the compiler provides it automatically > > unless you ask it not to with -nostdlib. > > Actually, there might be a good reason to do this.. (ie: add -lc_r) - it > records the specific major version of libc that a program was compiled/ > linked against. eg: libfoo.so.3 depends on libc.so.4 (old sigset). > meanwhile you have libc.so -> libc.so.5 on your system and compile with the > older -lfoo.. If libfoo.so.3 depended specifically on the older libc, then > it will call sigaction() etc with the (old) sigsets that it (ie: osigaction) > expects. The main program (having been linked against the new > will be passing around new sigsets and will call sigaction in libc.so.5 with > the new sigsets. Have you actually used this much, i.e., having two different libc.so.* versions loaded into the same program image? I am not sure that it won't work, but it gives me mild heart palpitations to think about it. We have pretty good symbol scoping now inside the dynamic linker, but still it seems like there is a lot of potential for strange behavior which would be very hard to diagnose. For example, malloc uses some static variables to keep track of things. If there are two libcs then there are two mallocs and two sets of those variables. It seems like there's potential for them to step on each other's toes. Again, I haven't proved that it won't work, but I have a feeling there would be cases where it would fail in very confusing ways. Our current method of linking things at least guards against having multiple libc versions that might interfere with each other. > Anyway, that's something to think about. :-) I agree it's worth thinking about. I'm just worried that it could seem to work at first, and then we'd discover horrible world problems a few weeks down the line that might be hard to recover from. Mr. Worry Wart -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch鐷yam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 10:37:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 5057A37B6C8 for ; Mon, 29 Jan 2001 10:37:05 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id f0TIbDE09662; Mon, 29 Jan 2001 18:37:16 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id f0TIcO203434; Mon, 29 Jan 2001 18:38:24 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200101291838.f0TIcO203434@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Peter Wemm Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Cloned open support In-Reply-To: Message from Peter Wemm of "Mon, 29 Jan 2001 06:02:10 PST." <200101291402.f0TE2A451479@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jan 2001 18:38:24 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Brian Somers wrote: > > Hi, > > > > I'm considering having a crack at adding support for cloned opens. > > Before I start, I guess I've got two questions: > > > > 1. Is anybody else doing this. > > > > 2. Given that I'll need to change the d_open prototype (and > > thus cdevsw), I'm going to affect every device driver in the > > tree - although only changing the first arg to a (dev_t) > > pointer, making things pretty easy to change and not too > > unexpected for anyone that's written sysv drivers. > > Not necessary. dev_t *is* a pointer. Add a flag to the device flags to Ach, I was thinking userland-dev_t aka udev_t :-/ Yes, the prototypes don't need to change :-D > indicate that it allows clone opens, and maybe teach specfs a little about > it (ie: that the unit will be reassigned on a clone open) and you're done. I don't think it's that easy. I believe the vnode that's attached to the specinfo needs to be discarded (and any VN_RELE()s done) when the open routine changes dev->si_udev, and probably dev->si_udev needs to be put back. The specinfo code then needs to create a new vnode and return that from VOP_OPEN() - changing the VOP_OPEN() prototype to be passed a vnode **.... I tried before to get things to work by adjusting the vnode that's passed into VOP_OPEN(), but failed miserably - probably because I don't fully understand the relationship between vnodes and the namei stuff.... I *guess* it's cleaner to create the new vnode so that the namei caching side of things can do it's job on the clone device. > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 11:40:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id EF32E37B404 for ; Mon, 29 Jan 2001 11:40:03 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TJe1K23399; Mon, 29 Jan 2001 20:40:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 18:38:24 GMT." <200101291838.f0TIcO203434@hak.lan.Awfulhak.org> Date: Mon, 29 Jan 2001 20:40:01 +0100 Message-ID: <23397.980797201@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101291838.f0TIcO203434@hak.lan.Awfulhak.org>, Brian Somers writes: >> Brian Somers wrote: >> > Hi, >> > >> > I'm considering having a crack at adding support for cloned opens. >> > Before I start, I guess I've got two questions: >> > >> > 1. Is anybody else doing this. >> > >> > 2. Given that I'll need to change the d_open prototype (and >> > thus cdevsw), I'm going to affect every device driver in the >> > tree - although only changing the first arg to a (dev_t) >> > pointer, making things pretty easy to change and not too >> > unexpected for anyone that's written sysv drivers. >> >> Not necessary. dev_t *is* a pointer. Add a flag to the device flags to > >Ach, I was thinking userland-dev_t aka udev_t :-/ Yes, the >prototypes don't need to change :-D It would have to change, it would have to be pointer to pointer to do it the way you propose. >I *guess* it's cleaner to create the new vnode so that the namei >caching side of things can do it's job on the clone device. That was my conclusion as well :-) In addition it allows cloning in some cases which would otherwise not be possible. One I know various people have been seen drooling over is media determined disk names. The driver and label/slice code could read various identifiers off the disk and allow people to do things like: mount /dev/disk/serial/234723842 /mnt -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 13:59:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 626F737B402 for ; Mon, 29 Jan 2001 13:59:05 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0TLro345857; Mon, 29 Jan 2001 13:53:51 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk> Date: Mon, 29 Jan 2001 13:58:48 -0800 (PST) From: John Baldwin To: Brian Somers Subject: Re: Cloned open support Cc: freebsd-arch@FreeBSD.org, Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-Jan-01 Brian Somers wrote: >> >2. Given that I'll need to change the d_open prototype (and >> > thus cdevsw) >> >> I'm not sure that is really a good idea. >> >> If you look at the device name clone stuff I think I have made >> it possible to handle it there. >> >> The idea being that you call it on "/dev/pty" and it will clone >> "/dev/pty38" for you and return the dev_t for that. You then >> complete the open on that dev_t. I have not quite thought >> it through though. >> >> Either way, I think cloning open should be kept out of d_open >> one way or another. > > The thing is that I believe the driver needs to be able to > decide what minor number will be opened. This idea is taken > from the Solaris implementation. For example, I have a > theoretical driver that does this: > > o Makes minor 0 available in /dev as a control device > o Makes minor 1 available as something that'll be cloned. > o The descriptor returned from opening minor 1 may itself > me made available via namefs (a vfs that allows you to > turn a descriptor into a mountpoint to give other users > access to it) and may be opened again. Such descriptors > are not cloned. > > Although this sounds exotic, it's quite practical, and > impossible to do outside of the driver. > > I think deciding on the minor outside the driver is too > limiting. Why not use an ioctl on the control device to get a minor number to use? The ioctl could then do a make_dev() on the appropriate device to create it. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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 Mon Jan 29 14:16:41 2001 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 CD8A837B402; Mon, 29 Jan 2001 14:16:21 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0TMGL101787; Mon, 29 Jan 2001 14:16:21 -0800 (PST) Date: Mon, 29 Jan 2001 14:16:21 -0800 From: Alfred Perlstein To: John Baldwin Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: Cloned open support Message-ID: <20010129141621.F26076@fw.wintelcom.net> References: <200101291228.f0TCSgP60147@storm.FreeBSD.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Mon, Jan 29, 2001 at 01:58:48PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010129 14:00] wrote: > > On 29-Jan-01 Brian Somers wrote: > >> >2. Given that I'll need to change the d_open prototype (and > >> > thus cdevsw) > >> > >> I'm not sure that is really a good idea. > >> > >> If you look at the device name clone stuff I think I have made > >> it possible to handle it there. > >> > >> The idea being that you call it on "/dev/pty" and it will clone > >> "/dev/pty38" for you and return the dev_t for that. You then > >> complete the open on that dev_t. I have not quite thought > >> it through though. > >> > >> Either way, I think cloning open should be kept out of d_open > >> one way or another. > > > > The thing is that I believe the driver needs to be able to > > decide what minor number will be opened. This idea is taken > > from the Solaris implementation. For example, I have a > > theoretical driver that does this: > > > > o Makes minor 0 available in /dev as a control device > > o Makes minor 1 available as something that'll be cloned. > > o The descriptor returned from opening minor 1 may itself > > me made available via namefs (a vfs that allows you to > > turn a descriptor into a mountpoint to give other users > > access to it) and may be opened again. Such descriptors > > are not cloned. > > > > Although this sounds exotic, it's quite practical, and > > impossible to do outside of the driver. > > > > I think deciding on the minor outside the driver is too > > limiting. > > Why not use an ioctl on the control device to get a minor number to > use? The ioctl could then do a make_dev() on the appropriate device > to create it. Yes, but will it swap the current open fd with the new device? Afaik the idea is to remove the race condition. -- -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 Mon Jan 29 14:23:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id AA25837B400; Mon, 29 Jan 2001 14:23:40 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TMNhK24997; Mon, 29 Jan 2001 23:23:43 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: John Baldwin , Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 14:16:21 PST." <20010129141621.F26076@fw.wintelcom.net> Date: Mon, 29 Jan 2001 23:23:43 +0100 Message-ID: <24995.980807023@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Why not use an ioctl on the control device to get a minor number to >> use? The ioctl could then do a make_dev() on the appropriate device >> to create it. > >Yes, but will it swap the current open fd with the new device? > >Afaik the idea is to remove the race condition. Guys, we *already have* cloning support that either does or can do all of this with only minor adjustments. You are sitting in a car discussing how to invent the wheel :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 14:31:23 2001 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 AD77237B402; Mon, 29 Jan 2001 14:31:06 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0TMSY102216; Mon, 29 Jan 2001 14:28:34 -0800 (PST) Date: Mon, 29 Jan 2001 14:28:34 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: John Baldwin , Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support Message-ID: <20010129142834.G26076@fw.wintelcom.net> References: <20010129141621.F26076@fw.wintelcom.net> <24995.980807023@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <24995.980807023@critter>; from phk@critter.freebsd.dk on Mon, Jan 29, 2001 at 11:23:43PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [010129 14:23] wrote: > > >> Why not use an ioctl on the control device to get a minor number to > >> use? The ioctl could then do a make_dev() on the appropriate device > >> to create it. > > > >Yes, but will it swap the current open fd with the new device? > > > >Afaik the idea is to remove the race condition. > > Guys, we *already have* cloning support that either does or can > do all of this with only minor adjustments. /me hands you a wrench > > You are sitting in a car discussing how to invent the wheel :-) then we are waiting to be enlightened. :) thanks, -- -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 Mon Jan 29 14:32:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 70E2A37B402; Mon, 29 Jan 2001 14:32:29 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0TMWXK25094; Mon, 29 Jan 2001 23:32:33 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: John Baldwin , Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support In-Reply-To: Your message of "Mon, 29 Jan 2001 14:28:34 PST." <20010129142834.G26076@fw.wintelcom.net> Date: Mon, 29 Jan 2001 23:32:33 +0100 Message-ID: <25092.980807553@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010129142834.G26076@fw.wintelcom.net>, Alfred Perlstein writes: >> Guys, we *already have* cloning support that either does or can >> do all of this with only minor adjustments. > >/me hands you a wrench >> >> You are sitting in a car discussing how to invent the wheel :-) > >then we are waiting to be enlightened. :) I've already explained it once in this thread I belive ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 16: 3:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hera.drwilco.net (10dyn120.dh.casema.net [212.64.31.120]) by hub.freebsd.org (Postfix) with ESMTP id 9624937B69E; Mon, 29 Jan 2001 16:03:35 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0U0Q1b05909; Tue, 30 Jan 2001 01:26:01 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010130002432.00b5f100@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jan 2001 00:31:38 +0100 To: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG From: "Rogier R. Mulhuijzen" Subject: Is anybody working on bridging code & a question for -arch on userland/kernel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 1) Is anyone working on the bridging code? I'm going to extend the ng_bridge node with Spanning Tree Protocol and I wouldn't want to be duplicating work. I checked in -current, but I thought I'd check on -net as well. (And -arch because of my next question) 2) Where does one draw the line at handling stuff in the kernel or userspace. The algorithms that are used in the Spanning Tree Protocol aren't very complicated, and I'm pretty sure I could contain everything in kernel space, but what is the Right Thing to do? Everything in kernelspace, or running a userland daemon that does all the calculating, decision making and time tracking? DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 16:11:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E220E37B404; Mon, 29 Jan 2001 16:11:26 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0U0BNx48599; Mon, 29 Jan 2001 16:11:23 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101300011.f0U0BNx48599@iguana.aciri.org> Subject: Re: Is anybody working on bridging code & a question for -arch on userland/kernel In-Reply-To: <4.3.2.7.0.20010130002432.00b5f100@mail.drwilco.net> from "Rogier R. Mulhuijzen" at "Jan 30, 2001 0:31:38 am" To: drwilco@drwilco.net (Rogier R. Mulhuijzen) Date: Mon, 29 Jan 2001 16:11:13 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 > 1) Is anyone working on the bridging code? I'm going to extend the > ng_bridge node with Spanning Tree Protocol and I wouldn't want to be > duplicating work. I checked in -current, but I thought I'd check on -net as > well. (And -arch because of my next question) i am doing some minor fixes to the non-netgraph version of the bridging code. > 2) Where does one draw the line at handling stuff in the kernel or > userspace. The algorithms that are used in the Spanning Tree Protocol > aren't very complicated, and I'm pretty sure I could contain everything in > kernel space, but what is the Right Thing to do? Everything in kernelspace, > or running a userland daemon that does all the calculating, decision making > and time tracking? i'd rather do as much as possible in userspace, and issue appropriate calls (basically sysctl or similar to enable/disable forwarding on some of the bridged interfaces) when necessary. If you need a specific control interface i will be glad to implement it, and your spanningTreed will be much much easier to implement, test, maintain and reuse for different bridging things (not to mention that a single box can act as multiple independent bridges for which you want multiple spanning trees). let me know if you have some spanning tree code that you want to test/integrate. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 17:10: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id A84A237B698 for ; Mon, 29 Jan 2001 17:09:42 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id SAA27242; Mon, 29 Jan 2001 18:04:59 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp05.primenet.com, id smtpdAAAFqaqk1; Mon Jan 29 18:04:52 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id SAA11860; Mon, 29 Jan 2001 18:09:23 -0700 (MST) From: Terry Lambert Message-Id: <200101300109.SAA11860@usr07.primenet.com> Subject: Re: libc_r badness To: arch@FreeBSD.ORG Date: Tue, 30 Jan 2001 01:09:23 +0000 (GMT) Cc: peter@netplex.com.au In-Reply-To: <200101291834.f0TIYL957823@vashon.polstra.com> from "John Polstra" at Jan 29, 2001 10:34:21 AM X-Mailer: ELM [version 2.5 PL2] 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 > > One is to have -lc_r on its own pull in libc to avoid POLA for apps > > that use ld(1) directly (doesn't work for static, no big deal). The > > second (seperate) issue is exising dynamic binaries on people's > > -current systems (eg: ports). Adding the LDADD+= -lc repairs the > > existing binaries that were linked with the old gcc specs and > > libc_r. I do not envy recompiling my handful of threaded apps. Not > > all are from ports. > > OK, I misunderstood the goal when I replied before. I can see that it > would be helpful to have libc_r depend explicitly on libc in order to > make existing binaries work again. You are supposed to be able to just link libc_r against libc, and ELF is supposed to support this, so that everything "just works". It was one of my concerns about the weak symbol reshuffle that, if I have a libc_r that's linked against libc (so that a program linked against libc_r gets libc as well), then if you replace a libc function, that the automatic linkage "does the right thing", and uses your function, when calling from libc_r, and not the libc function. The problem with this is that the system calls aren't in the implementation space, per se, any more, so it'd be very hard to wrap them again, transparently to the libc_r that has to call the real system calls from the libc to implement threaded calls. There are really two problems on top of this, then: 1) It seems to me that, in static linking, archives are no longer really treated as archives, so that object code is only pulled in, if referenced; this seems related to #2, which is: 2) In linking, at lik time, the linker should act as if it were going to be loaded with RTLD_NOD, instead of RTLD_LAZY, even though in parctice, RTLD_LAZY will be the preferred (default) method of operation. Archie Cobbs had a nice problem with Kaffe and JNI, having to do with the fact that ELF second order dependencies were not flagged as failing. The easiest way to see #2 is to build two shared libraries, foo and fee, and have like-named functions in each: fee() { foo(); } foo() { write( 1, "boom!\n", 6) } And link your program shared, and dlopen() fee, call fee, and watch foo not be there and your program explode. You can also do this with a shared link, going 3 deep, but the cause is less obvious, being in the bowels of ld.so. I spent several days going after a fix for this, but making it do correct symbol accounting turned into a nightmare really quickly. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 18:54:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 954E137B404 for ; Mon, 29 Jan 2001 18:53:50 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0U2ro459515 for ; Mon, 29 Jan 2001 18:53:50 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101300253.f0U2ro459515@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: arch@FreeBSD.org Subject: Re: libc_r badness In-Reply-To: <200101291834.f0TIYL957823@vashon.polstra.com> Content-Transfer-Encoding: 8bit Date: Mon, 29 Jan 2001 18:53:50 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > In article <200101291811.f0TIBJ454801@mobile.wemm.org>, > Peter Wemm wrote: [..] > > > Since everything needs libc, it is not recorded as an explicit > > > dependency. Instead, the compiler provides it automatically > > > unless you ask it not to with -nostdlib. > > > > Actually, there might be a good reason to do this.. (ie: add -lc_r) - it > > records the specific major version of libc that a program was compiled/ > > linked against. eg: libfoo.so.3 depends on libc.so.4 (old sigset). > > meanwhile you have libc.so -> libc.so.5 on your system and compile with the > > older -lfoo.. If libfoo.so.3 depended specifically on the older libc, then > > it will call sigaction() etc with the (old) sigsets that it (ie: osigaction ) > > expects. The main program (having been linked against the new > > will be passing around new sigsets and will call sigaction in libc.so.5 wit h > > the new sigsets. > > Have you actually used this much, i.e., having two different libc.so.* > versions loaded into the same program image? I am not sure that it > won't work, but it gives me mild heart palpitations to think about it. Likewise, it scares the hell out of me too. Just try mixing up malloc() from one libc with free() from another and see how far one gets.. Most of our troubles come from different dependencies of (custom) libperl and zillions of shared objects. I have seen a bunch of places where programs have ended up with libc.so.3 and libc.so.4 and it wasn't pretty. I believe it pretty much worked but that was more due to luck than anything because libc.so.3 we mostly used custom C++ libraries that used libc for little more than syscall stubs. Ironically, going the other way around seems to cause more failures. ie: using a *later* version of a shared library (a 4.x binary - an interface to a kld we use on our 4.x systems) with 3.x libraries and apps seems to cause a lot more trouble than multiple libc's seem to. I do not remember the problems too well, but if I recall correctly it was undefined symbols (syscalls). It may have been solved by linking libproxyio.so against the 4.x libc. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 29 19:35:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6903537B400 for ; Mon, 29 Jan 2001 19:35:12 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA16084; Mon, 29 Jan 2001 22:34:37 -0500 (EST) Date: Mon, 29 Jan 2001 22:34:37 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: libc_r badness In-Reply-To: <200101300253.f0U2ro459515@mobile.wemm.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 On Mon, 29 Jan 2001, Peter Wemm wrote: > John Polstra wrote: > > Have you actually used this much, i.e., having two different libc.so.* > > versions loaded into the same program image? I am not sure that it > > won't work, but it gives me mild heart palpitations to think about it. > > Likewise, it scares the hell out of me too. Just try mixing up malloc() > from one libc with free() from another and see how far one gets.. > > Most of our troubles come from different dependencies of (custom) libperl > and zillions of shared objects. I have seen a bunch of places where programs > have ended up with libc.so.3 and libc.so.4 and it wasn't pretty. I believe > it pretty much worked but that was more due to luck than anything because > libc.so.3 we mostly used custom C++ libraries that used libc for little more > than syscall stubs. In the past, libc_r.so versions have moved in lock step with libc, so even if we did have libc_r depend on libc (assuming it could be), there wouldn't be a problem. Now that applications can be linked with both libc_r and libc, the libc_r version number does not have to be bumped when libc is. If libc_r depends on libc, then the next time you bump the libc version and rebuild world, you'll end up with this problem. I suppose you could continue bumping version numbers in lock step, but why if there is no reason to? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 30 0: 4:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 2D07137B503 for ; Tue, 30 Jan 2001 00:04:39 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0U84b462385; Tue, 30 Jan 2001 00:04:37 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101300804.f0U84b462385@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: libc_r badness In-Reply-To: Date: Tue, 30 Jan 2001 00:04:37 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Mon, 29 Jan 2001, Peter Wemm wrote: > > John Polstra wrote: > > > Have you actually used this much, i.e., having two different libc.so.* > > > versions loaded into the same program image? I am not sure that it > > > won't work, but it gives me mild heart palpitations to think about it. > > > > Likewise, it scares the hell out of me too. Just try mixing up malloc() > > from one libc with free() from another and see how far one gets.. > > > > Most of our troubles come from different dependencies of (custom) libperl > > and zillions of shared objects. I have seen a bunch of places where progra ms > > have ended up with libc.so.3 and libc.so.4 and it wasn't pretty. I believe > > it pretty much worked but that was more due to luck than anything because > > libc.so.3 we mostly used custom C++ libraries that used libc for little mor e > > than syscall stubs. > > In the past, libc_r.so versions have moved in lock step with libc, so > even if we did have libc_r depend on libc (assuming it could be), there > wouldn't be a problem. Now that applications can be linked with both > libc_r and libc, the libc_r version number does not have to be bumped > when libc is. If libc_r depends on libc, then the next time you bump > the libc version and rebuild world, you'll end up with this problem. > I suppose you could continue bumping version numbers in lock step, but > why if there is no reason to? No, if we bumped libc.so.5 -> libc.so.6, then the -lc dependency in libc_r.so.5 would change to libc.so.6 in the same buildworld. There is no need or value in having the versions in locked together. We could still freely bump libc.so and/or libc_r.so. However, it gets interesting in this scenario: cc -o app -l libc_r.so.5 -l libc.so.6 suppose we make a change to sigaction to change the size of signal sets and we introduce a new syscall number. bump libc's version buildworld libc_r.so.5 now depends on libc.so.7. (and suppose it makes internal calls ti sigaction, but *suppose* that libc_r didn't have any sigset exposure) ./app - which depends on libc_r.so.5 and libc.so.6. libc_r.so.5 will also pull in a copy of libc.so.7 into the namespace tree and you have two libc's loaded - but not level in the namespace. "./app" will make it's sigaction calls with the old sigset which will resolve to libc.so.6 using the old compatability syscall. libc_r.so.5 will make its internal sigaction calls with the new sigset and resolve to the new sigaction in libc.so.7 and will use the new syscall number with them. This is a contrived example, because sigset changes would almost certainly affect libc_r as well and would require a bump there too. But the example does show what can be done. I get headaches thinking about this stuff. For example, which malloc() and stdio etc would get used? Would libc_r use the new one but the app use the old one? Ouch. :-] Hmm.. if we did this, then perhaps we'd better keep them in lockstep.. ie: if libc is bumped, also bump libc_r (no need for the other way around though). That would avoid the two different libc's being loaded at the same time. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 30 5:26:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9D9C537B6AB for ; Tue, 30 Jan 2001 05:26:08 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA26953; Tue, 30 Jan 2001 08:25:41 -0500 (EST) Date: Tue, 30 Jan 2001 08:25:40 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: libc_r badness In-Reply-To: <200101300804.f0U84b462385@mobile.wemm.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 On Tue, 30 Jan 2001, Peter Wemm wrote: > Daniel Eischen wrote: > > On Mon, 29 Jan 2001, Peter Wemm wrote: > > > John Polstra wrote: > > > > Have you actually used this much, i.e., having two different libc.so.* > > > > versions loaded into the same program image? I am not sure that it > > > > won't work, but it gives me mild heart palpitations to think about it. > > > > > > Likewise, it scares the hell out of me too. Just try mixing up malloc() > > > from one libc with free() from another and see how far one gets.. > > > > > > Most of our troubles come from different dependencies of (custom) libperl > > > and zillions of shared objects. I have seen a bunch of places where progra > ms > > > have ended up with libc.so.3 and libc.so.4 and it wasn't pretty. I believe > > > it pretty much worked but that was more due to luck than anything because > > > libc.so.3 we mostly used custom C++ libraries that used libc for little mor > e > > > than syscall stubs. > > > > In the past, libc_r.so versions have moved in lock step with libc, so > > even if we did have libc_r depend on libc (assuming it could be), there > > wouldn't be a problem. Now that applications can be linked with both > > libc_r and libc, the libc_r version number does not have to be bumped > > when libc is. If libc_r depends on libc, then the next time you bump > > the libc version and rebuild world, you'll end up with this problem. > > I suppose you could continue bumping version numbers in lock step, but > > why if there is no reason to? > > No, if we bumped libc.so.5 -> libc.so.6, then the -lc dependency in > libc_r.so.5 would change to libc.so.6 in the same buildworld. There is no > need or value in having the versions in locked together. We could still > freely bump libc.so and/or libc_r.so. Right, but an older application will pull in libc.so.5 and libc_r.so.5, but libc_r.so.5 will (now, after buildworld) also pull in libc.so.6. > However, it gets interesting in this scenario: > cc -o app -l libc_r.so.5 -l libc.so.6 > > suppose we make a change to sigaction to change the size of signal sets > and we introduce a new syscall number. > > bump libc's version > > buildworld > > libc_r.so.5 now depends on libc.so.7. (and suppose it makes internal > calls ti sigaction, but *suppose* that libc_r didn't have any sigset > exposure) > > ./app - which depends on libc_r.so.5 and libc.so.6. libc_r.so.5 will also > pull in a copy of libc.so.7 into the namespace tree and you have two libc's > loaded - but not level in the namespace. "./app" will make it's sigaction > calls with the old sigset which will resolve to libc.so.6 using the old > compatability syscall. libc_r.so.5 will make its internal sigaction calls > with the new sigset and resolve to the new sigaction in libc.so.7 and will > use the new syscall number with them. Right, this is exactly what I was trying to say above. > This is a contrived example, because sigset changes would almost certainly > affect libc_r as well and would require a bump there too. But the example > does show what can be done. > > I get headaches thinking about this stuff. For example, which malloc() > and stdio etc would get used? Would libc_r use the new one but the app > use the old one? Ouch. :-] And which locks (spinlocks, mutexes) in libc.so.5 and libc.so.6 will get used? > Hmm.. if we did this, then perhaps we'd better keep them in lockstep.. > ie: if libc is bumped, also bump libc_r (no need for the other way around > though). That would avoid the two different libc's being loaded at the same > time. In a perfect world, we would have made the libc/libc_r change the same day as the library versions were bumped and we'd have no problem. I see no reason to have libc_r.so depend on libc.so other than to have threaded apps that were built in the last 2 months continue to work without being recompiled. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 30 6:47:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8DB0537B491 for ; Tue, 30 Jan 2001 06:47:20 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA20721; Wed, 31 Jan 2001 01:44:29 +1100 Date: Wed, 31 Jan 2001 01:44:14 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Valentin Nechayev Cc: arch@freebsd.org Subject: Re: dynamic vs static sysctls? In-Reply-To: <20010130144848.A76120@lucky.net> 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, 30 Jan 2001, Valentin Nechayev wrote: > Hello Bruce Evans! > > Tue, Jan 30, 2001 at 22:11:24, bde wrote about "Re: cvs commit: src/sys/dev/ata ata-disk.c": > > > If I had 512 channels (the maximum number of ad disks supported), it > > might be: > > > > hw.atamodes: dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,... > > > > Quick now, change the mode for ad345 (hint: it's probably not just the 345th > > element in the string). > > > > Supporting this poor user interface isn't even easy for the driver -- it takes > > about 40 lines of code to translate the string. > > You think it should be hw.isa0.ata172.slave.atamode, don't you? > (Followup please to -arch with subject "Re: dynamic vs static sysctls?", > please;))) I think it should be an ioctl :-). If it must be a sysctl, then it should be something more like dev.ata.ad345.iomode (select by device name) and dev.ata.ata234-slave.iomode (select by interface number) to provide a reasonable user interface, and something with the device numbers last to avoid bloating the sysctl tree. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 30 9:10:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.org (adsl-64-169-104-72.dsl.lsan03.pacbell.net [64.169.104.72]) by hub.freebsd.org (Postfix) with ESMTP id B61ED37B4EC for ; Tue, 30 Jan 2001 09:10:14 -0800 (PST) Received: by obsecurity.org (Postfix, from userid 1000) id 3A3D1BA2B4; Tue, 30 Jan 2001 09:10:45 -0800 (PST) Date: Tue, 30 Jan 2001 09:10:45 -0800 From: Kris Kennaway To: Valentin Nechayev Cc: Bruce Evans , arch@FreeBSD.org Subject: Re: Re: dynamic vs static sysctls? Message-ID: <20010130091045.A52258@xor.obsecurity.org> References: <200101300213.f0U2DY459123@mobile.wemm.org> <20010130144848.A76120@lucky.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010130144848.A76120@lucky.net>; from netch@lucky.net on Tue, Jan 30, 2001 at 02:48:48PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2001 at 02:48:48PM +0200, Valentin Nechayev wrote: > > hw.atamodes: dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dm= a,dma,:-8,dma,dma,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,d= ma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,= dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma= ,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dm= a,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,d= ma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,= dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma= ,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dm= a,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,d= ma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,= pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma= ,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dm= a,dma,dma,pio,dm! > a,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,:-%, Actually, it's worse than that..apparently the driver suppresses all leading controllers which are not present: I had a controller which provided ad4 through ad7, and wanted to change the modes (Promise Ultra 100, which was giving me massive filesystem corruption), but hw.atamodes said this: hw.atamodes: dma, dma, dma, dma, However what it really meant was this: hw.atamodes: ---, ---, ---, ---, dma, dma, dma, dma, and I couldn't alter the settings without knowing this and adding back the missing four entries. Kris --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6dvWVWry0BWjoQKURAmBrAJ9ub7xBrumgEiQtv/Rz8uZFhDOv1gCg0pwL jbFVS/afvM+t32mmLAsLwLE= =VKvv -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 30 9:22:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 3C4F037B4EC for ; Tue, 30 Jan 2001 09:22:30 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f0TB2WP23667; Mon, 29 Jan 2001 12:02:32 +0100 (CET) (envelope-from adrian) Date: Mon, 29 Jan 2001 12:02:27 +0100 From: Adrian Chadd To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Cloned open support Message-ID: <20010129120227.A23655@roaming.cacheboy.net> References: <200101291052.f0TAqVK58112@storm.FreeBSD.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101291052.f0TAqVK58112@storm.FreeBSD.org.uk>; from brian@Awfulhak.org on Mon, Jan 29, 2001 at 10:52:31AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 29, 2001, Brian Somers wrote: > Hi, > > I'm considering having a crack at adding support for cloned opens. > Before I start, I guess I've got two questions: > > 1. Is anybody else doing this. I'm not, but I'd like this to also be able to percolate through VFS. This way, synthetic filesystems such as procfs can attach temporary state per file, keeping things "consistent" between reads. (which does not happen right now.) Just to keep in mind, adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 30 21:33:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 54B4237B6A7 for ; Tue, 30 Jan 2001 21:33:11 -0800 (PST) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.1+3.4W/3.7W-rina.r-0.1-11.01.2000) with ESMTP id f0V5X5g05152; Wed, 31 Jan 2001 14:33:07 +0900 (JST) Date: Wed, 31 Jan 2001 14:33:04 +0900 Message-ID: From: Seigo Tanimura To: arch@FreeBSD.org Subject: Bumping up {MAX,DFL}*SIZ in i386 Cc: Seigo Tanimura User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 12) (Channel Islands) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Last night I ran a program processing very large amount of data. As the program ate up all of the available address space for data, I increased MAXDSIZ to 1.5GB so that the program ran successfully. Now that even an entry-model workstation can equip memory up to 1GB or more, MAXDSIZ and DFLDSIZ should be increased so that a process can make use of large memory. On the other hand, MAXDSIZ is also likely to hit VM_MAXUSER_ADDRESS, which is generally 3GB and may be 2GB if the size of KVM is expanded to the maximum. MAXDSIZ should thus not exceed 2GB. I propose the following values for the new user address space constraints: MAXTSIZ and DFLTSIZ: 256MB MAXDSIZ and DFLDSIZ: 1.5GB MAXSSIZ: 128MB Total: 1.875G (= 2G - 128M) MAXTSIZ and DFLTSIZ is bumped as we may want to run a large binary. A large binary calls for deep function calls, hence MAXSSIZ is bumped as well. These values are likely to be the final ones for i386 before jumping into ia64. Any comments or flames? -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 1:25:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (unknown [213.162.128.50]) by hub.freebsd.org (Postfix) with ESMTP id 730C737B65D for ; Wed, 31 Jan 2001 01:25:26 -0800 (PST) Received: by mimer.webgiro.com (Postfix, from userid 66) id D96BC2DC0B; Wed, 31 Jan 2001 10:31:56 +0100 (CET) Received: by mx.webgiro.com (Postfix, from userid 1001) id 075F37817; Wed, 31 Jan 2001 10:25:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 0507C10E1B; Wed, 31 Jan 2001 10:25:40 +0100 (CET) Date: Wed, 31 Jan 2001 10:25:39 +0100 (CET) From: Andrzej Bialecki To: Kris Kennaway Cc: Valentin Nechayev , Bruce Evans , arch@FreeBSD.org Subject: Re: Re: dynamic vs static sysctls? In-Reply-To: <20010130091045.A52258@xor.obsecurity.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 On Tue, 30 Jan 2001, Kris Kennaway wrote: > On Tue, Jan 30, 2001 at 02:48:48PM +0200, Valentin Nechayev wrote: > > > > hw.atamodes: dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,:-8,dma,dma,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,dma,dma,pio,dm! > > a,dma,dma,dma,dma,dma,dma,pio,dma,dma,dma,dma,dma,:-%, > > Actually, it's worse than that..apparently the driver suppresses all > leading controllers which are not present: I had a controller which > provided ad4 through ad7, and wanted to change the modes (Promise > Ultra 100, which was giving me massive filesystem corruption), but > hw.atamodes said this: > > hw.atamodes: dma, dma, dma, dma, > > However what it really meant was this: > > hw.atamodes: ---, ---, ---, ---, dma, dma, dma, dma, > > and I couldn't alter the settings without knowing this and adding back > the missing four entries. I'd like to point out that sysctl_add_oid(9) was created exactly to address issues like that. The original problem (as I understand it) with this particular sysctl was that it wasn't possible to create additional sysctl nodes for each ata channel/disk on the fly (without compiling them into kernel in advance). But now it's possible, so IMHO the code should be changed to create the subtree on the fly, based on the actual presence of the hardware: hw.atamode.ata0: --- hw.atamode.ata1: --- hw.atamode.ata2: dma hw.atamode.ata3: dma ... This scheme accomodates also removable media, as you can add and remove oids as you see it fit during runtime. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 1:46:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B52E137B4EC for ; Wed, 31 Jan 2001 01:46:41 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA26915; Wed, 31 Jan 2001 20:46:30 +1100 Date: Wed, 31 Jan 2001 20:46:15 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Seigo Tanimura Cc: arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFL}*SIZ in i386 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, 31 Jan 2001, Seigo Tanimura wrote: > I propose the following values for the new user address space > constraints: > > MAXTSIZ and DFLTSIZ: 256MB > MAXDSIZ and DFLDSIZ: 1.5GB > MAXSSIZ: 128MB > > Total: 1.875G (= 2G - 128M) > > MAXTSIZ and DFLTSIZ is bumped as we may want to run a large binary. A > large binary calls for deep function calls, hence MAXSSIZ is bumped as > well. > > These values are likely to be the final ones for i386 before jumping > into ia64. > > Any comments or flames? I think these limits shouldn't exist, for the following reasons: (1) DFLTSIZ already doesn't exist :-). (2) MAXTSIZ doesn't actually work. It is only used to limit the size of the initial text section for the aout and gzip image activators, and in compatibility code. It has no effect for elf text sections or dynamically loaded text sections. (3) MAXDSIZ is mainly used to limit the RLIMIT_DATA rlimits even for root, and together with the other limits, to ensure that the text, data and stack fit in considerably less than the available address space so that there is plenty of space to mmap() things. This should be mostly under application control, and mostly would be if the rlimits weren't arbitrarily limited. The details behind (3) show a possible problem with your change. mmap(0, ...) only allocates data above approx. MAXDSIZ, so increasing MAXDSIZ from 0.5G to 1.5G breaks mmapping of everything in files of sizes between about 1.4G and 2.4G (see a recent PR about cmp(1)). I think mmap(0, ...) should start at vm_daddr + rlim_max_for_data instead of vm_daddr + MAXDSIZE. Similarly for the elf loader address (don't load anything that isn't under program control in the middle of the memory, since this fragments memory). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 12: 4:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id BA70F37B65D for ; Wed, 31 Jan 2001 12:04:27 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0VK4Hv23602; Wed, 31 Jan 2001 14:04:17 -0600 (CST) (envelope-from dan) Date: Wed, 31 Jan 2001 14:04:17 -0600 From: Dan Nelson To: Seigo Tanimura Cc: arch@FreeBSD.ORG Subject: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) Message-ID: <20010131140416.C21193@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: ; from "Seigo Tanimura" on Wed Jan 31 14:33:04 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 31), Seigo Tanimura said: > Now that even an entry-model workstation can equip memory up to 1GB > or more, MAXDSIZ and DFLDSIZ should be increased so that a process > can make use of large memory. On the other hand, MAXDSIZ is also > likely to hit VM_MAXUSER_ADDRESS, which is generally 3GB and may be > 2GB if the size of KVM is expanded to the maximum. MAXDSIZ should > thus not exceed 2GB. On a similar note, is there any reason for us to have DFLTPHYS at 64k anymore? With the insane interface speeds of SCSI and ATA devices nowadays, you can easily hit 600 I/Os per second on sequential reads (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was bumped to say, 1mb? -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 12: 8: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id EE3CD37B65D for ; Wed, 31 Jan 2001 12:07:51 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA26929; Wed, 31 Jan 2001 21:07:46 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Dan Nelson Cc: Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) References: <20010131140416.C21193@dan.emsphone.com> From: Dag-Erling Smorgrav Date: 31 Jan 2001 21:07:45 +0100 In-Reply-To: Dan Nelson's message of "Wed, 31 Jan 2001 14:04:17 -0600" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson writes: > On a similar note, is there any reason for us to have DFLTPHYS at 64k > anymore? With the insane interface speeds of SCSI and ATA devices > nowadays, you can easily hit 600 I/Os per second on sequential reads > (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was > bumped to say, 1mb? I think so; we can't do DMA transfers larger than 64k (128k in word mode) - at least for ISA devices, I don't know much about PCI. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 12:22:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id BB41737B69F for ; Wed, 31 Jan 2001 12:21:59 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0VKMDW00902; Wed, 31 Jan 2001 12:22:13 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101312022.f0VKMDW00902@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dag-Erling Smorgrav Cc: Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-reply-to: Your message of "31 Jan 2001 21:07:45 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Jan 2001 12:22:13 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Dan Nelson writes: > > On a similar note, is there any reason for us to have DFLTPHYS at 64k > > anymore? With the insane interface speeds of SCSI and ATA devices > > nowadays, you can easily hit 600 I/Os per second on sequential reads > > (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was > > bumped to say, 1mb? > > I think so; we can't do DMA transfers larger than 64k (128k in word > mode) - at least for ISA devices, I don't know much about PCI. It's 128K right now, actually. The problem is that a lot of older devices have limits which cap them at 64K. (Typically, 16-bit bytecount registers, or 16- or 17-slot scatter/gather tables.) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 12:23:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A80C637B6A4 for ; Wed, 31 Jan 2001 12:23:25 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA16801; Wed, 31 Jan 2001 12:23:10 -0800 Date: Wed, 31 Jan 2001 12:23:11 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dag-Erling Smorgrav Cc: Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) 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 What do you mean for ISA? I thought you could do a lot more. Anyway, I mean, get real... PCI has been the main bus now for some years and it can do a full 32 bits.... let's move on now, please... On 31 Jan 2001, Dag-Erling Smorgrav wrote: > Dan Nelson writes: > > On a similar note, is there any reason for us to have DFLTPHYS at 64k > > anymore? With the insane interface speeds of SCSI and ATA devices > > nowadays, you can easily hit 600 I/Os per second on sequential reads > > (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was > > bumped to say, 1mb? > > I think so; we can't do DMA transfers larger than 64k (128k in word > mode) - at least for ISA devices, I don't know much about PCI. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > > 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 Wed Jan 31 12:30:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 9ADEF37B67D for ; Wed, 31 Jan 2001 12:30:21 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0VKUfW00945; Wed, 31 Jan 2001 12:30:42 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101312030.f0VKUfW00945@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-reply-to: Your message of "Wed, 31 Jan 2001 12:23:11 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Jan 2001 12:30:41 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What do you mean for ISA? I thought you could do a lot more. > > Anyway, I mean, get real... PCI has been the main bus now for some years and > it can do a full 32 bits.... let's move on now, please... PCI DMA engines are still pretty sucky. In most cases though, 128K is a sensible size to be wiring for a single transfer; remember that most decent controllers will let you have a nontrivial number of outstanding transfers posted simultaneously. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 14: 8:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4DEB737B698; Wed, 31 Jan 2001 14:08:30 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0VM8Tm17958; Wed, 31 Jan 2001 14:08:29 -0800 (PST) (envelope-from dillon) Date: Wed, 31 Jan 2001 14:08:29 -0800 (PST) From: Matt Dillon Message-Id: <200101312208.f0VM8Tm17958@earth.backplane.com> To: Mike Smith Cc: Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) References: <200101312022.f0VKMDW00902@mass.dis.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Dan Nelson writes: :> > On a similar note, is there any reason for us to have DFLTPHYS at 64k :> > anymore? With the insane interface speeds of SCSI and ATA devices :> > nowadays, you can easily hit 600 I/Os per second on sequential reads :> > (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was :> > bumped to say, 1mb? :> :> I think so; we can't do DMA transfers larger than 64k (128k in word :> mode) - at least for ISA devices, I don't know much about PCI. : :It's 128K right now, actually. The problem is that a lot of older :devices have limits which cap them at 64K. (Typically, 16-bit bytecount :registers, or 16- or 17-slot scatter/gather tables.) : There are a number of places in the kernel where increasing DFLTPHYS will create stack bloating problems, too much reservation of KVM, hit certain inefficiencies in the buffer cache, and cause other insundry problems. Also, increasing DFLTPHYS is not going to make one iota of difference insofar as DMA goes. Since most of the high bandwidth devices already supporting DMA chaining and since we have to translate virtual to physical addresses anyway -- the chaining granularity is often 4K no matter what you do. And, finally, while large I/O's may seem to be a good idea, they can actually interfere with the time-share mechanisms that smooth system operation. If you queue a 1 MByte I/O to a disk device, that disk device is locked up doing that one I/O for a long time (in cpu-time terms). Having a large number of bytes queued for I/O on one device can interfere with the performance of another device. In short, your performance is not going to get better and could very well get worse. What is important to system performance is more the ability to maintain an I/O pipeline and less in the cpu overhead required to keep the pipeline full. I test SCSI performance every year or so and, frankly, once you get above a DMA size 4K all you gain are a few additional cpu cycles. You gain nothing in transfer rate or overall system performance. So my recommendation: don't do it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 15:47:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D8B9037B503 for ; Wed, 31 Jan 2001 15:47:22 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0VNkx926833; Wed, 31 Jan 2001 16:47:07 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101312347.f0VNkx926833@harmony.village.org> To: netch@lucky.net Subject: Re: dynamic vs static sysctls? Cc: arch@freebsd.org In-reply-to: Your message of "Tue, 30 Jan 2001 14:48:48 +0200." <20010130144848.A76120@lucky.net> References: <20010130144848.A76120@lucky.net> <200101300213.f0U2DY459123@mobile.wemm.org> Date: Wed, 31 Jan 2001 16:46:59 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010130144848.A76120@lucky.net> Valentin Nechayev writes: : You think it should be hw.isa0.ata172.slave.atamode, don't you? : (Followup please to -arch with subject "Re: dynamic vs static sysctls?", : please;))) I'd think it would be hints.ad.344.atamode="dma" personally. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 16: 6:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D7F5037B491 for ; Wed, 31 Jan 2001 16:06:39 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f11068926954; Wed, 31 Jan 2001 17:06:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102010006.f11068926954@harmony.village.org> To: Andrzej Bialecki Subject: Re: dynamic vs static sysctls? Cc: Kris Kennaway , Valentin Nechayev , Bruce Evans , arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 31 Jan 2001 10:25:39 +0100." References: Date: Wed, 31 Jan 2001 17:06:08 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Andrzej Bialecki writes: : changed to create the subtree on the fly, based on the actual presence of : the hardware: : : hw.atamode.ata0: --- : hw.atamode.ata1: --- : hw.atamode.ata2: dma : hw.atamode.ata3: dma : ... The problem with this scheme is that you don't have all the information about a device under one part of the treem. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 16: 8:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E99B637B491 for ; Wed, 31 Jan 2001 16:08:26 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1108O926986; Wed, 31 Jan 2001 17:08:24 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102010008.f1108O926986@harmony.village.org> To: John Baldwin Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Cc: arch@freebsd.org In-reply-to: Your message of "Wed, 31 Jan 2001 16:03:00 PST." References: Date: Wed, 31 Jan 2001 17:08:24 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : during boot. One thing that Mike Smith would like to do (or so he has : told me) is to have aa env top-level sysctl node that mapped any names : below it to equivalent kernel environment variables, which would require : some subtle changes to the way sysctl works, but nothing too drastic. I'd like to see that as well. I'd also like to see the hints settable after boot so that you can tweak things. But they are close to sysctls in many ways (except for the API for getting the data). One problem is that sysctl is readable by the whole world and root can write anything. This is both too permissive and too strict. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 16:25:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 5FA5537B491 for ; Wed, 31 Jan 2001 16:25:23 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f110Ja325567; Wed, 31 Jan 2001 16:19:36 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <200102010008.f1108O926986@harmony.village.org> Date: Wed, 31 Jan 2001 16:25:06 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Feb-01 Warner Losh wrote: > In message John Baldwin writes: >: during boot. One thing that Mike Smith would like to do (or so he has >: told me) is to have aa env top-level sysctl node that mapped any names >: below it to equivalent kernel environment variables, which would require >: some subtle changes to the way sysctl works, but nothing too drastic. > > I'd like to see that as well. I'd also like to see the hints settable > after boot so that you can tweak things. But they are close to > sysctls in many ways (except for the API for getting the data). > > One problem is that sysctl is readable by the whole world and root can > write anything. This is both too permissive and too strict. This is why I think ACL's for sysctl's that are administered via a sysctlfs wouldn't be such a bad thing. However, sysctl(9) already allows for dynamic addition, removal, setting, etc. of nodes already, so simply importing the kernel environment into the sysctl tree at boot might be the easiest thing to do. However, I think that, say, hw.snd.pcm0.hwvol_mixer, is more of a hardware attribute then a kernel environment attribute, which env.hint.pcm.0.hwvol_mixer kind of implies. I don't see env as being a good dumping ground for hardware configuration, so I'd almost rather have devices export any important information via a sysctl that lives in the proper part of the sysctl tree rather than just stuck under env. Also, for dynamic sysctl's, it is easier to use 'pcm0' for a node than a '0' node under a 'pcm' tree. This is because device_get_nameunit() gives us a string we can just pass to sysctl_add_oid(), whereas device_get_unit() returns an integer that we'd have to malloc a string for and sprintf() into or something. (I guess we could do _really_ evil things where we return a pointer into the nameunit string that starts with the unit number). > Warner -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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 Wed Jan 31 17: 4:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 90D5537B69E; Wed, 31 Jan 2001 17:04:19 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1114I927261; Wed, 31 Jan 2001 18:04:19 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102010104.f1114I927261@harmony.village.org> To: John Baldwin Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Cc: arch@FreeBSD.org In-reply-to: Your message of "Wed, 31 Jan 2001 16:25:06 PST." References: Date: Wed, 31 Jan 2001 18:04:18 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : This is why I think ACL's for sysctl's that are administered via a sysctlfs : wouldn't be such a bad thing. I think that it is significantly more difficult a problem than you might think. : However, I think that, say, hw.snd.pcm0.hwvol_mixer, is more of a hardware : attribute then a kernel environment attribute, which env.hint.pcm.0.hwvol_mixer : kind of implies. I don't see env as being a good dumping ground for hardware : configuration, so I'd almost rather have devices export any important : information via a sysctl that lives in the proper part of the sysctl tree : rather than just stuck under env. I respectfully disagree. While we are using the kernel environment for this, that's just an unimportant implementation detail. hint.pcm.0.hwvol_mixer implies to me an attribute of unit 0 of pcm. With the hw.snd tree, you have to look in many places for the meta information for the device. Some stuff is in the config space, some stuff is in the snd tree, and other stuff is who knows where. That makes it hard to implement a generic meta information editor and infrastructure. : Also, for dynamic sysctl's, it is easier to : use 'pcm0' for a node than a '0' node under a 'pcm' tree. This is because : device_get_nameunit() gives us a string we can just pass to sysctl_add_oid(), : whereas device_get_unit() returns an integer that we'd have to malloc a string : for and sprintf() into or something. (I guess we could do _really_ evil things : where we return a pointer into the nameunit string that starts with the unit : number). This precludes us from having device names that end in a number. That's currnetly supported and works well, at least for loadable modules. I think that drivers have no business using sysctl directly. We need to have a good system that allows them to get hierarchical information dynamically. It may be the case that this is done with sysctl under the covers, it may not. Since it would likely be universal and easy to use, arguments about the relative ease of implementation at this level likely aren't going to be very important at all. If we enhance the device interface to allow this, it wouldn't matter how thigns were implemented. Right now kernel environment variables are a handy communication device between the loader and the kernel such that no changes were needed there. Once they are into the kernel, the way the work are an implementation detail that really should be ignored for designing a good interface for driver writers to use. I'll admit that the current interface for resource_int_value and resource_query_string are poorly documented. They also don't allow for easy setting once the probe/attach code has run. We need to fix that. I'm of the mind that we need to have a single, unified tree (maybe managed by sysctl, maybe not). That tree would then cause callbacks to the drivers to happen when the values in them change so the driver can react to them or ignore them as they happen. The sysctl tree could be used for this behind the scenes updating. Drivers could register those items that it understands. This would easily allow us to write a generic meta data editor. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 17:27:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id F1EE637B684 for ; Wed, 31 Jan 2001 17:27:21 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f111LY327047; Wed, 31 Jan 2001 17:21:34 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <200102010104.f1114I927261@harmony.village.org> Date: Wed, 31 Jan 2001 17:27:05 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Feb-01 Warner Losh wrote: > In message John Baldwin writes: >: This is why I think ACL's for sysctl's that are administered via a sysctlfs >: wouldn't be such a bad thing. > > I think that it is significantly more difficult a problem than you > might think. The actual implementation of a sysctlfs with ACL's? It's already been written at least twice (minus the ACL's though, and determining good backing store for them that is persistent is probably the most difficulty part of that). >: However, I think that, say, hw.snd.pcm0.hwvol_mixer, is more of a hardware >: attribute then a kernel environment attribute, which >: env.hint.pcm.0.hwvol_mixer >: kind of implies. I don't see env as being a good dumping ground for >: hardware >: configuration, so I'd almost rather have devices export any important >: information via a sysctl that lives in the proper part of the sysctl tree >: rather than just stuck under env. > > I respectfully disagree. While we are using the kernel environment > for this, that's just an unimportant implementation detail. > hint.pcm.0.hwvol_mixer implies to me an attribute of unit 0 of pcm. > With the hw.snd tree, you have to look in many places for the meta > information for the device. Some stuff is in the config space, some > stuff is in the snd tree, and other stuff is who knows where. That > makes it hard to implement a generic meta information editor and > infrastructure. Well, I don't think that env.hint is any better of a dumping ground than hw. :) Both have their roots in other places, and I get the feeling you would like a logical tree tied directly to the devives, so that you would have something like: int device_get_attribute(device_t dev, const char *name, int *len, void *value); int device_set_attribute(device_t dev, const char *name, int *len, void *value); Where 'name' is the name of a node under some arbitrary tree whose immediately preceding branches are either 'foo0' or 'foo.0'. One implementation might be to create a 'devices' top-level sysctl node to stick this under. *shrug* If you allow implicit creation of attributes, then that API might be enough, so long as when a device goes away, it's entire tree goes away. Another choice might be to require explicit adding/removing of per-device attributes. You also might want to have devclass attributes (the pcm snd_unit is an example of this.) Is this what you are looking for? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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 Wed Jan 31 21:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C914D37B491; Wed, 31 Jan 2001 21:46:54 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f115ks928525; Wed, 31 Jan 2001 22:46:54 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102010546.f115ks928525@harmony.village.org> To: John Baldwin Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 31 Jan 2001 17:27:05 PST." References: Date: Wed, 31 Jan 2001 22:46:54 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : Well, I don't think that env.hint is any better of a dumping ground than hw. :) : Both have their roots in other places, and I get the feeling you would like a : logical tree tied directly to the devives, so that you would have something : like: Yes. I would. hw.snd moves some meta information to a different part of the tree than other meta information. : int : device_get_attribute(device_t dev, const char *name, int *len, void *value); : : int : device_set_attribute(device_t dev, const char *name, int *len, void *value); : : Where 'name' is the name of a node under some arbitrary tree whose immediately : preceding branches are either 'foo0' or 'foo.0'. Yes. That's right. I'd be tempted to have it be the full path to the device, but that doesn't make a lot of sense given that devices are uniquely named. : If you allow implicit creation of attributes, then that API might be : enough, so long as when a device goes away, it's entire tree goes : away. Another choice might be to require explicit adding/removing : of per-device attributes. You also might want to have devclass : attributes (the pcm snd_unit is an example of this.) I wouldn't want the whole tree to go away when the device went away. I'd like to see it persist after the device goes away. This would allow me to have a TV card, say, come up in PAL mode all the time. Or my removable ethernet always prefer thinet over 10baseT. I'd like to have some way of know which attributes a driver supports so that a generic tool could configure them easily. Hints right now doesn't allow for this. The drivers fetch the resource and that's that. If you spelled something wrong, you have no way of knowing it other than the device not changing its behavior. : Is this what you are looking for? A lot closer. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 31 23:30:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 052C337B684; Wed, 31 Jan 2001 23:30:00 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f117TxW09445; Wed, 31 Jan 2001 23:29:59 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102010729.f117TxW09445@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Baldwin Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c In-Reply-To: Date: Wed, 31 Jan 2001 23:29:59 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > Both have their roots in other places, and I get the feeling you > would like a logical tree tied directly to the devives, so that you > would have something like: > > int > device_get_attribute(device_t dev, const char *name, int *len, void *value); > > int > device_set_attribute(device_t dev, const char *name, int *len, void *value); > > Where 'name' is the name of a node under some arbitrary tree whose > immediately preceding branches are either 'foo0' or 'foo.0'. There is only one real problem, and it is a big one. At the point of device_probe, there is no name or unit set. "fxp0" does not exist until after the probe has finished and the bus mechanism has decided that the device auction is over. Until then, it is "unknown" unit -1. This means that the usual probe mechanism cannot take advantage of hints. There are some exceptions.. the isa bus does lots of magic and is driven by the unit name/number, rather than a detected resource. ISAPNP stuff would run into this problem more if the probe mechanism did anything more than matching the pnpid. If it did printf's etc they come out as: unknown-: <.....> This is not impossible to work around. And it needs it in order to be able to do decent wiring of devices. I still want to be able to wire IDE devices the same that we can wire scsi devices... only the scsi wiring is missing the ability to reserve (say) ahc0 for some specific pci slot. I have a fairly old checked out tree with this partially implemented somewhere. I had in mind a mechanism to merge the resources and device tree together, but keeping a persistant resource tree. The 'at' binding would be interpreted by the bus parent, for example. And the other resources would be available in a manner not too unlike the API above. It would work something like this.. Suppose: hint.fxp.0.at="pci0.6.0" hint.fxp.0.flags=0x100 hint.fxp.0.speed=100 hint.fxp.0.duplex="full" So, when pci0 was doing its probes and was about to assign a unit number for a "fxp" driver, it would scan for the at= and would check if the at= matched the current address. If so, it would try and give unit 0 to that instance. If not, it would find the next available unwired unit. Then.. for the instance that ended up with unit 0, the flags, speed and duplex attributes would be attached to that device, and the fxpattach stuff (and indeed the rest of the driver) could do a device_get_resource(dev, "speed", RES_INT, sizeof(speed), &speed) Note there are several keys to this.. - the driver should tell the framework what sort of "thing" it wants.. ie: interpret the resource as an int, or give me a string, or whatever. - the key for the at= bindings is that the parent must decide if it is a match or not. We cannot know ahead of time what the tree geometry is going to look like, so we have defer it till the last minute. the pci driver would see "pci0.6.0" and decide that yes, we are "pci0" and that we are currently looking at device 6 function 0, so we are matching this set of resources. Hmm, in fact, there is nothing much stopping this stuff being available to the probe routine either.. we could temporarily assign a unit and name to the device instance that matched the driver that the probe was being done for. The scsi bus implementation of this stuff is really evil and although it works, it needs to be cleaned up and nicely encapsulated so that the same gross hackery isn't needed in every bus device. :-( Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 1 3:51:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 074E237B491 for ; Thu, 1 Feb 2001 03:51:03 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OIDL-0009ZB-00; Thu, 01 Feb 2001 11:47:47 +0000 Date: Thu, 1 Feb 2001 11:47:47 +0000 From: Tony Finch To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.org Subject: Re: Cloned open support Message-ID: <20010201114747.K70673@hand.dotat.at> References: <200101291400.f0TE0hY61432@storm.FreeBSD.org.uk> <21279.980777635@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <21279.980777635@critter> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > >Later when we get a devd(8) daemon knitted together it will >get the chance to set the modes before the open completes. Is it possible to do non-blocking open()s? (Other than via KSEs) Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Well, as long as they can think we'll have our problems. But those whom we're using cannot think." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 1 3:54:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (fxp0.halvsten.ip.cybercity.dk [212.242.40.114]) by hub.freebsd.org (Postfix) with ESMTP id 23C2B37B684 for ; Thu, 1 Feb 2001 03:54:36 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f11BrXZ04162; Thu, 1 Feb 2001 12:53:33 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Tony Finch Cc: Brian Somers , freebsd-arch@FreeBSD.org Subject: Re: Cloned open support In-Reply-To: Your message of "Thu, 01 Feb 2001 11:47:47 GMT." <20010201114747.K70673@hand.dotat.at> Date: Thu, 01 Feb 2001 12:53:33 +0100 Message-ID: <4160.981028413@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010201114747.K70673@hand.dotat.at>, Tony Finch writes: >Poul-Henning Kamp wrote: >> >>Later when we get a devd(8) daemon knitted together it will >>get the chance to set the modes before the open completes. > >Is it possible to do non-blocking open()s? (Other than via KSEs) This doesn't really affect the blocking/non-blocking open implementation in any way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 1 14:40:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id F310737B491 for ; Thu, 1 Feb 2001 14:40:33 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA19905; Thu, 1 Feb 2001 15:35:19 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAjFayXM; Thu Feb 1 15:35:13 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA17852; Thu, 1 Feb 2001 15:40:08 -0700 (MST) From: Terry Lambert Message-Id: <200102012240.PAA17852@usr08.primenet.com> Subject: Re: Cloned open support To: dot@dotat.at (Tony Finch) Date: Thu, 1 Feb 2001 22:40:08 +0000 (GMT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), brian@Awfulhak.org (Brian Somers), freebsd-arch@FreeBSD.ORG In-Reply-To: <20010201114747.K70673@hand.dotat.at> from "Tony Finch" at Feb 01, 2001 11:47:47 AM X-Mailer: ELM [version 2.5 PL2] 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 > >Later when we get a devd(8) daemon knitted together it will > >get the chance to set the modes before the open completes. > > Is it possible to do non-blocking open()s? (Other than via KSEs) O_NDELAY. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 1 16:39:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id F2A3637B4EC; Thu, 1 Feb 2001 16:38:58 -0800 (PST) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f120cqX17295; Thu, 1 Feb 2001 16:38:52 -0800 From: "Jonathan Graehl" To: Cc: "Jonathan Lemon" Subject: socket connect status from kqueue events? Date: Thu, 1 Feb 2001 16:39:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How are TCP connect failures (timed out, connection refused, icmp error) reflected in the corresponding kqueue event? I can determine when a connection call has completed by using EVFILT_WRITE (the socket is immediately writable when connected), but other than checking for ENOTCONN or ECONNRESET using getpeername(fd,NULL,0), I don't know how I can determine whether the connect succeeded or not, and, if it didn't, what the cause was (ICMP errors followed by timeout, timeout with no response, or RST immediately ending attempt). I would prefer not to use getpeername. I suppose I could also attempt to do something with the possibly-connected socket, and wait for an error on failure, or do getsockopt(SO_ERROR...), which might possibly give me the actual error resulting from the failed connect attempt? Please tell me there is a flag somewhere in the event structure for an EVFILT_WRITE event which can indicate at least whether the connection has failed or not (there is a difference between the other end closing immediately, which should show up as EV_EOF, and the connection never being established in the first place). Also, are there any plans to allow for local and remote endpoints to both be specified before bind/listen/connect, to avoid the excessive use of SO_REUSEADDR? -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ phone: 858-642-7562 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 1 19: 8: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 5075537B4EC for ; Thu, 1 Feb 2001 19:07:44 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.1/8.11.1) id f1235ih22220 for arch@freebsd.org; Fri, 2 Feb 2001 03:05:44 GMT (envelope-from nik) Date: Fri, 2 Feb 2001 03:05:43 +0000 From: Nik Clayton To: arch@freebsd.org Subject: [andrew@ugh.net.au: docs/23745: man page for vcount(9)] Message-ID: <20010202030540.B21835@canyon.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, Anyone up for a review? Cheers. N ----- Forwarded message from andrew@ugh.net.au ----- Date: Fri, 22 Dec 2000 16:54:27 +1100 (EST) From: andrew@ugh.net.au To: FreeBSD-gnats-submit@freebsd.org Subject: docs/23745: man page for vcount(9) >Number: 23745 >Category: docs >Synopsis: man page for vcount(9) >Description: When trying to understand a part of the kernel I found a number of undocumented functions. I documented vcount based on the comments in the code...I think I've got it right but haven't manged to get any reviewers as yet. >How-To-Repeat: >Fix: .\" -*- nroff -*- .\" .\" Copyright (c) 2000 Andrew Stevenson .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" .\" If this man page travels to places exotic (like projects other than .\" FreeBSD) I would love to hear about it. .\" Andrew .\" .\" $Id$ .\" .Dd November 4th, 2000 .Os .Dt VCOUNT 9 .Sh NAME .Nm vcount , .Nm count_dev .Nd get total number of references to a device. .Sh SYNOPSIS .Fd #include .Fd #include .Fd #include .Ft int .Fn vcount "struct vnode *vp" .Ft int .Fn count_dev "dev_t dev" .Sh DESCRIPTION .Fn vcount is used to get the number of users of (code with references to) a particular device. It allows for the fact that multiple vnodes may reference the same device. .Fn count_dev does the same thing as vcount but takes a dev_t rather than a vnode pointer as an argument. .Sh RETURN VALUES .Fn vcount and .Fn count_dev both return the number of users of the device. .Sh SEE ALSO .Xr VFS 9 , .Xr vnode 9 , .Pa src/sys/kern/vfs_subr.c .Sh AUTHORS This man page was written by .An Andrew Stevenson . >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message ----- End forwarded message ----- -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 3 11:47:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id CD5F537B491; Sat, 3 Feb 2001 11:47:10 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA13387; Sat, 3 Feb 2001 11:46:58 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda13385; Sat Feb 3 11:46:43 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f13Jkaf26424; Sat, 3 Feb 2001 11:46:36 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdt26422; Sat Feb 3 11:46:14 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f13JkBA08356; Sat, 3 Feb 2001 11:46:11 -0800 (PST) Message-Id: <200102031946.f13JkBA08356@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdwA8352; Sat Feb 3 11:45:45 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Matt Dillon Cc: Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-reply-to: Your message of "Wed, 31 Jan 2001 14:08:29 PST." <200101312208.f0VM8Tm17958@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 2001 11:45:44 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101312208.f0VM8Tm17958@earth.backplane.com>, Matt Dillon writes: > > :> Dan Nelson writes: > :> > On a similar note, is there any reason for us to have DFLTPHYS at 64k > :> > anymore? With the insane interface speeds of SCSI and ATA devices > :> > nowadays, you can easily hit 600 I/Os per second on sequential reads > :> > (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was > :> > bumped to say, 1mb? > :> > :> I think so; we can't do DMA transfers larger than 64k (128k in word > :> mode) - at least for ISA devices, I don't know much about PCI. > : > :It's 128K right now, actually. The problem is that a lot of older > :devices have limits which cap them at 64K. (Typically, 16-bit bytecount > :registers, or 16- or 17-slot scatter/gather tables.) > : [comments deleted] > > And, finally, while large I/O's may seem to be a good idea, they can > actually interfere with the time-share mechanisms that smooth system > operation. If you queue a 1 MByte I/O to a disk device, that disk > device is locked up doing that one I/O for a long time (in cpu-time > terms). Having a large number of bytes queued for I/O on one device > can interfere with the performance of another device. In short, > your performance is not going to get better and could very well get > worse. I remember an IBM MVS course course that made this point abundantly clear. The short of it was that if your system was primarily used as a batch system, e.g. response time didn't matter but throughput did, use large block sizes. If on the other hand your primary workload was time sharing or transaction processing applications, smaller block sizes would improve response times but reduce throughput. Large block sizes tend to monopolise I/O channels. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 3 13: 4:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 30CD037B401; Sat, 3 Feb 2001 13:03:59 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f13L3nO55354; Sat, 3 Feb 2001 14:03:50 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200102032103.f13L3nO55354@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matt Dillon Cc: Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: Your message of "Wed, 31 Jan 2001 14:08:29 PST." <200101312208.f0VM8Tm17958@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 2001 14:03:49 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And, finally, while large I/O's may seem to be a good idea, they can > actually interfere with the time-share mechanisms that smooth system > operation. Large I/Os, while interesting for disks, are often *required* for dealing with non-disk devices. If I want to read a tape generated from an SGI, for example, the records may be 1MB in size. Almost all of our PCI SCSI controllers can perform such a large I/O, but DFLTPHYS prevents you from servicing such an I/O. On devices like tape, you can't break up the I/O to the device into chunks smaller than the block size. We *need* a way to perform I/Os that span more than one buffer so we can avoid the DFLTPHYS limit. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 3 13:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6CF0337B65D; Sat, 3 Feb 2001 13:23:30 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA30330; Sat, 3 Feb 2001 13:23:17 -0800 Date: Sat, 3 Feb 2001 13:23:14 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: Matt Dillon , Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: <200102032103.f13L3nO55354@aslan.scsiguy.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 Thank you. You put it exactly right. > > And, finally, while large I/O's may seem to be a good idea, they can > > actually interfere with the time-share mechanisms that smooth system > > operation. > > Large I/Os, while interesting for disks, are often *required* for dealing > with non-disk devices. If I want to read a tape generated from an SGI, > for example, the records may be 1MB in size. Almost all of our PCI SCSI > controllers can perform such a large I/O, but DFLTPHYS prevents you from > servicing such an I/O. On devices like tape, you can't break up the I/O > to the device into chunks smaller than the block size. We *need* a way > to perform I/Os that span more than one buffer so we can avoid the DFLTPHYS > limit. > > -- > Justin > > > 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 Sat Feb 3 13:24:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id ED5A337B401; Sat, 3 Feb 2001 13:24:08 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA30343; Sat, 3 Feb 2001 13:24:00 -0800 Date: Sat, 3 Feb 2001 13:23:58 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: Matt Dillon , Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: <200102032103.f13L3nO55354@aslan.scsiguy.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 BTW- however you want to put it, such large maxphys issues have not been a problem with things like SunOS since 1989. What's the deal with *BSD? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 3 16:27:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 44DC037B503; Sat, 3 Feb 2001 16:26:59 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f140QuD12547; Sat, 3 Feb 2001 16:26:56 -0800 (PST) (envelope-from dillon) Date: Sat, 3 Feb 2001 16:26:56 -0800 (PST) From: Matt Dillon Message-Id: <200102040026.f140QuD12547@earth.backplane.com> To: Matthew Jacob Cc: "Justin T. Gibbs" , Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Thank you. You put it exactly right. : : :> > And, finally, while large I/O's may seem to be a good idea, they can :> > actually interfere with the time-share mechanisms that smooth system :> > operation. :> :> Large I/Os, while interesting for disks, are often *required* for dealing :> with non-disk devices. If I want to read a tape generated from an SGI, :> for example, the records may be 1MB in size. Almost all of our PCI SCSI :> controllers can perform such a large I/O, but DFLTPHYS prevents you from :> servicing such an I/O. On devices like tape, you can't break up the I/O :> to the device into chunks smaller than the block size. We *need* a way :> to perform I/Os that span more than one buffer so we can avoid the DFLTPHYS :> limit. :> :> -- :> Justin This is a reasonable criticism, but putting aside the issue of bloating kernel stack useage from huge struct buf structures there is also the issue of whether any static limit is 'reasonable'. The device driver API supports arbitrary raw read and raw write sizes, but nearly all the device drivers convert read() and write() calls to physio() calls, and those then convert the parameters to struct buf / VOP_STRATEGY() calls. There are only two solutions that I can see: (1) have the SCSI tape device code not convert raw reads and writes to VOP_STRATEGY calls and instead manage the KVA for the I/O via some other mechanism. (2) Modify the 'struct buf' b_pages[] array to instead be a pointer to an array. Include the original static array under another name for compatibility purposes and have the init code default to assigning b_pages to the original embedded static array. Then the physio code could be adjusted to dynamically MALLOC the necessary pages array if the static one in the supplied buffer is insufficient. Increasing DFLTPHYS is not a valid solution. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message