From owner-freebsd-arch@FreeBSD.ORG Sun Jun 6 07:12:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CC5716A4CE for ; Sun, 6 Jun 2004 07:12:03 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE05043D1D for ; Sun, 6 Jun 2004 07:12:02 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from mp3 (2zzdxehp@mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i56EBqu515758754; Sun, 6 Jun 2004 18:11:52 +0400 (MSD) Date: Sun, 6 Jun 2004 18:11:52 +0400 (MSD) From: Maxim Konovalov To: Yar Tikhiy In-Reply-To: <20040605204823.GC692@comp.chem.msu.su> Message-ID: <20040606181135.R25373@mp3files.int.ru> References: <20040605204823.GC692@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: signal(SIGCHLD, SIG_IGN) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 14:12:03 -0000 On Sun, 6 Jun 2004, 00:48+0400, Yar Tikhiy wrote: > Hi folks, > > The SysV way to get rid of child zombies seems to have been supported > by CURRENT for about 2 years, but I can see no pointers to it in > the man pages. Can we conclude that the testing of the feature has > succeeded, and finally document it? Yes, please. -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Sun Jun 6 07:46:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD6B216A4CE; Sun, 6 Jun 2004 07:46:53 -0700 (PDT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F82D43D31; Sun, 6 Jun 2004 07:46:53 -0700 (PDT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [80.119.152.214]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id 2589617B44F; Sun, 6 Jun 2004 16:47:54 +0200 (CEST) Message-ID: <02e701c44bd5$1a883d70$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: , "Garance A Drosihn" References: <200406041933.i54JX23v052074@mail.gits.dyndns.org> Date: Sun, 6 Jun 2004 16:46:50 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: gad@freebsd.org Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 14:46:53 -0000 "Garance A Drosihn" wrote: > At 10:12 PM +0200 6/3/04, Cyrille Lefevre wrote: > >why this message does not reach -arch ? > >don't know if Garance reeived it also ? > > Hmm? Both my message (the one you are replying to) and your > reply to it showed up in my mailbox via the arch mailing list. looking into the archive, only the 3rd resent reached the mailing-list ! you where only CC'ed on the initial submission and on the first resent. > Did you see my other replies in this thread? I think they yes, I got them. [snip] > Yes, I do have some of them. For a few of those, it looks like I > was sending to > "Cyrille Lefevre" this one directly goes to my machine through sendmail, > which must have been your return address on whatever message I > was replying to. But the most important ones look like they > were sent to > Cyrille Lefevre and this one, to one of my ISPs that I fetch using fetchmail. > would messages to that address be likely to get lost? don't know. unfortunatelly, I've plenty of spam messages and spam filters. maybe some messages where deleted by inadvertence. however, I just received 5 messages from you (2 forwards and 3 replies), thanks. I'll reply to all of them if required. CC gad Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Sun Jun 6 08:45:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B92616A4CE; Sun, 6 Jun 2004 08:45:06 -0700 (PDT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56E9C43D58; Sun, 6 Jun 2004 08:45:06 -0700 (PDT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [80.119.152.214]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id AF08417B4AA; Sun, 6 Jun 2004 17:46:05 +0200 (CEST) Message-ID: <031a01c44bdd$3ba7e110$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: , "Garance A Drosihn" References: <200406041933.i54JX9kj040764@mail.gits.dyndns.org> Date: Sun, 6 Jun 2004 17:45:02 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: gad@freebsd.org Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 15:45:06 -0000 "Garance A Drosihn" wrote: > At 10:13 PM +0200 6/3/04, Cyrille Lefevre wrote: [snip] > frankly, polishing off the error-messages for INVALID input is not > high on my list of priorities right now. It just isn't. And no, > it would not be trivial to "just drop in" the massive update you > had written (particularly when parts of it don't seem to work for > me). it seems to be massive because I've moved the getopt loop from the the main function to the parseopts one and also because I rewrote the keyword table. appart than this, the rest of the patch isn't so big. > From my point of view, I've gone more than a month without replies > to email that I sent when I was eager to follow up on some of your > work. Eventually I decided to just go ahead. I'm still interested, > but not interested enough to throw out the updates I have been > testing just so I can start over from scratch. well, in one of the followed messages, you said the sysctl nodes where missing, humm! I'm surprised, but you are right, sorry. I'll submit an all in one patch set from scratch (cvs diff) instead of incremental ones, so, I'm sure I'll not forget something for a reason or another. > Once I get my upcoming changes to newsyslog sorted out, then I will > drop back to working on my upcoming changes to `ps'. Any other what kind of changes ? > minor parsing issues will be fixed as time permits. I'm just a > volunteer here, I am afraid I only have a little spare time that as I am. > I can spend on freebsd. so, why don't you take some time to see ontributions instead of writing stuff from scratch ! CC gad Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Sun Jun 6 11:13:52 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE80116A4CE for ; Sun, 6 Jun 2004 11:13:52 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id F415B43D3F for ; Sun, 6 Jun 2004 11:13:51 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i56IB3TX049835 for arch@FreeBSD.org.checked; (8.12.8/vak/2.1) Sun, 6 Jun 2004 22:11:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i56I9orm049778; (8.12.8/vak/2.1) Sun, 6 Jun 2004 22:09:50 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C35C80.5080900@cronyx.ru> Date: Sun, 06 Jun 2004 22:03:44 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Roman Kurakin References: <40B74840.5090600@cronyx.ru> In-Reply-To: <40B74840.5090600@cronyx.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit cc: arch@FreeBSD.org cc: Robert Watson Subject: Re: Network Stack Locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 18:13:52 -0000 Roman Kurakin пишет: > Robert Watson wrote: > >> SPPP Roman Kurakin >> Userspace build Roman Kurakin >> >> > //depot/users/rik/netperf/... > > I don't have it on the web, but I'll put it soon. http://people.freebsd.org/~rik/ > > > Best regards, > Roman Kurakin > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 11:25:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBFC016A4CE for ; Mon, 7 Jun 2004 11:25:57 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC8E43D41 for ; Mon, 7 Jun 2004 11:25:54 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i57BPmca002272; Mon, 7 Jun 2004 15:25:48 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i57BPlxF002271; Mon, 7 Jun 2004 15:25:47 +0400 (MSD) (envelope-from yar) Date: Mon, 7 Jun 2004 15:25:46 +0400 From: Yar Tikhiy To: Maxim Konovalov Message-ID: <20040607112546.GA1270@comp.chem.msu.su> References: <20040605204823.GC692@comp.chem.msu.su> <20040606181135.R25373@mp3files.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040606181135.R25373@mp3files.int.ru> User-Agent: Mutt/1.5.6i cc: arch@FreeBSD.org Subject: Re: signal(SIGCHLD, SIG_IGN) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:25:57 -0000 On Sun, Jun 06, 2004 at 06:11:52PM +0400, Maxim Konovalov wrote: > On Sun, 6 Jun 2004, 00:48+0400, Yar Tikhiy wrote: > > > The SysV way to get rid of child zombies seems to have been supported > > by CURRENT for about 2 years, but I can see no pointers to it in > > the man pages. Can we conclude that the testing of the feature has > > succeeded, and finally document it? > > Yes, please. Done in sigaction(2), wait(2), signal(3). -- Yar From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 11:30:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E981A16A4CE; Mon, 7 Jun 2004 11:30:39 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D723843D39; Mon, 7 Jun 2004 11:30:36 +0000 (GMT) (envelope-from cyrille.lefevre@laposte.net) Received: from pc2k (149-59-118-80.kaptech.net [80.118.59.149]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id B505517C00F; Mon, 7 Jun 2004 13:31:37 +0200 (CEST) Message-ID: <05a201c44c82$d94fc680$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: "Garance A Drosihn" , References: Date: Mon, 7 Jun 2004 02:31:10 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: "gnats-submit @FreeBSD.org" Subject: Re: Re: ps enhencements (posix syntax, and more) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:30:40 -0000 Garance A Drosihn wrote: >At 12:03 PM +0200 4/27/04, Cyrille Lefevre wrote: >>here is a description of the last PR#64803 updates : > >The latest info I see in PR #65803 does not match some >things that you describe in the rest of this message. >The following comments are based on what I have looked >at in the updates in the PR. I have not had much sleep, >so this message may be a little confusing in parts. > >>*** the kernel part has been reworked and validated in >> the last patch set. ...OpenBSD -k ... > >I haven't looked at what you have for -k, but I did try >what you had for KERN_PROC_SESSION and it didn't seem to >work. using the all in one kernel patch I've just submited, all would work as expected. it seems I forgot some important part to what I've submitted, sorry. >> implement KERN_PROC_SESSION in /sys/kern/kern_proc.c >> as well as system processes filtering in KERN_PROC_PROC >> (not sure about that). both features have not been >> tested yet, but will be soon. > >I am skipping the change to KERN_PROC_PROC for now. I >suspect we will want that for at least some situations, >but I haven't decided what situations yet. as I'm writting the email, all the submitted stuffs have been tested and works well. >>bug fix : -L is missing a break. > >It does not need one in the present FreeBSD source, but I >did not check to see if there is some reason it needs one >in your updated source. this was related to my ps patches. I'll submit a new all in one patch related to the the -current ps, so, you could try again the new stuffs w/o conflicts and w/o missing pieces, is any :( >>*** this is the last patch set before dynamic sizing... > >I expect that I am missing this 'the last patch set' >which you refer to here. the emul keyword :) >>kernel level added features : >>KERN_PROC_SESSION, KERN_PROC_GID and KERN_PROC_RGID have >>been implemented at kernel level as well as > >I also wanted KERN_PROC_RGID, so I had added the similar >clause to the case statement. Your KERN_PROC_SESSION and >this KERN_PROC_RGID which I added did not seem to work, so >I looked around a bit and decided I needed to add four >SYSCTL_NODE() entries. With those added, the new features >seem to work fine. see my above comment. >>KERN_PROC_TTY_NODEV and KERN_PROC_TTY_REVOKED (the last >>two are based on what NetBSD does but differently since >>we have to lock p_session). > >I obviously did not add these, or KERN_PROC_GID, since the >update I have does not include them. They sound like >reasonable things to add. there are in the all in one kernel patch. >>KERN_PROC_PROC now handles KERN_PROC_INC_THREADS and, in >>this case, is similar to KERN_PROC_ALL. > >I have been awake many hours due to work, so I may not be >thinking clearly right now. But the above does not sound >right to me. Wasn't the whole point of KERN_PROC_PROC to >*not* include threads? > >Also, there are other commands which call the same routine, >so I don't think we can just blindly rework everything. We >are now working towards a "5.x-stable" release, so I do not >want to make incompatible changes in any API's unless there >is some pretty major benefit. If all we are doing is getting >rid of an unnecessary variable, I do not believe that will be >worth the trouble at this point. top ignore system processes by default except if you uses -S. unfortunatelly, w/ this implementation of KERN_PROC_PROC, -H will be needed to see kernel threads. well, a better way would have to add a new macro like KERN_PROC_INC_KTHREADS to get or not system processes (aka kernel threads) appart than user threads ? >>P_SYSTEM processes aren't selected by default (as OpenBSD). > >I think this is a repeat of what you said earlier in this >message. I will want to think about that. no, this isn't a repeat. this is the way system processes are ignored at user level before to be implemented using KERN_PROC_PROC w/o KERN_PROC_INC_THREADS at kernel level. >>PS : take care about the struct kinfo alignment. as >> currently implemented, ki_spare has been validated >> under i386 and ia64 (and should work under ...) > >I have some changes to improve the checking of struct-kinfo >size & alignment, but they aren't finished. the ones from NetBSD/OpenBSD ? :) >>-G may now uses KERN_PROC_RGID if WITH_RGID is defined. >>-s may now uses KERN_PROC_SESSION if WITH_SESSION is >> defined. > >Note that for the base-system version of `ps', we do not >have to clutter things up with a lot of #if's. Either >the matching system supports a feature, or it doesn't. The I've added these #if's to help you to distinguish changes between them and to have the ability to test the base patch w/ or w/o kernel support :P >few '#if's that I added in my update were just placemarkers, >for something that I intend to pick up on with my later >updates. > >>some int variables have been changed to size_t >> (list->count, prtheader, i, lineno, nkept, nselectors). > >What was the advantage in that? For some of those, it is >pretty much impossible that the value will get over MAX_INT. it's just to match the system calls expected arguments or return values. using the right types avoid many bugs. >'nselectors' is the number of selectors that the user has >typed in as parameters to the `ps' command. If they type >in more than 32767 different selectors, they will run into >problems with command-line length long before they overflow >some of these counters. > >>-j now have sid by default. > >Hmm. Yeah, I *think* there was a PR about that. One of >those format-groups, at least. > >>PS : Garance, if you want a fresh patch set, let me know. > >I probably should, but I fear that before I have the time to >read & understand & test & install those updates, you will >just have rewritten them all over again. This is a bit I didn't understant why you want to reinvent the weel ? >frustrating, as I have much more modest goals for `ps' than yes, I'm frustrated to have worked hours and days w/o knowing if it's not for nothing... >you seem to. I like a lot of what you have done, but I am >not likely to pick it all up, and it is bound to irritate >you if you rewrite something six or seven times and then I >only install pieces of it. And I still have my own updates >which I need to merge in, as well going through all the work >you have been doing. could you submit your pending updates somewhere ? >>the current size of ps is (optimized and stripped and >>w/o extra aliases) : >>-current : 30788 >>this one : 38776 > >I am certainly hoping to keep `ps' smaller than that... When >I started out on my earlier big update, I was able to keep >the size down to 28000 for most the time I worked on it. But >in the last few days I worked on it, the size ballooned up >by about 15% without me noticing it. That still annoys me! I >would actually like to get the size back down, if I could. >I suspect that I will not be able to, but I will not want to >add *another* 24% to the size. whith todays so big disks, I didn't really understand why such limitations ? for instance, IMHO, the problem is more the kernel size which grow by more than 100% between 4.x and 5.x ! CC -arch, -gnats Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 11:39:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A1E716A4CE for ; Mon, 7 Jun 2004 11:39:16 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D2A43D2D for ; Mon, 7 Jun 2004 11:39:15 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp3 (mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i57Bcvu516005007; Mon, 7 Jun 2004 15:38:58 +0400 (MSD) Date: Mon, 7 Jun 2004 15:38:51 +0400 (MSD) From: Maxim Konovalov To: Yar Tikhiy In-Reply-To: <20040607112546.GA1270@comp.chem.msu.su> Message-ID: <20040607153808.B46536@mp3files.int.ru> References: <20040605204823.GC692@comp.chem.msu.su> <20040606181135.R25373@mp3files.int.ru> <20040607112546.GA1270@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: signal(SIGCHLD, SIG_IGN) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:39:16 -0000 On Mon, 7 Jun 2004, 15:25+0400, Yar Tikhiy wrote: > On Sun, Jun 06, 2004 at 06:11:52PM +0400, Maxim Konovalov wrote: > > On Sun, 6 Jun 2004, 00:48+0400, Yar Tikhiy wrote: > > > > > The SysV way to get rid of child zombies seems to have been supported > > > by CURRENT for about 2 years, but I can see no pointers to it in > > > the man pages. Can we conclude that the testing of the feature has > > > succeeded, and finally document it? > > > > Yes, please. > > Done in sigaction(2), wait(2), signal(3). Thanks. -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 16:53:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2F2E16A4CE for ; Mon, 7 Jun 2004 16:53:50 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5285243D4C for ; Mon, 7 Jun 2004 16:53:50 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i57GrnIX019596; Mon, 7 Jun 2004 12:53:49 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <05a201c44c82$d94fc680$7890a8c0@dyndns.org> References: <05a201c44c82$d94fc680$7890a8c0@dyndns.org> Date: Mon, 7 Jun 2004 12:53:47 -0400 To: "Cyrille Lefevre" , From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Re: ps enhencements (posix syntax, and more) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:53:50 -0000 At 2:31 AM +0200 6/7/04, Cyrille Lefevre wrote: >Garance A Drosihn wrote: >>At 12:03 PM +0200 4/27/04, Cyrille Lefevre wrote: >>>here is a description of the last PR#64803 updates : >> >>The latest info I see in PR #65803 does not match some >>things that you describe in the rest of this message. >>The following comments are based on what I have looked >>at in the updates in the PR. I have not had much sleep, >>so this message may be a little confusing in parts. >> >>>*** the kernel part has been reworked and validated in >>> the last patch set. ...OpenBSD -k ... >> >>I haven't looked at what you have for -k, but I did try >>what you had for KERN_PROC_SESSION and it didn't seem to > >work. Please do not take my private messages and reply to them in public. If I thought we had to hash out every little detail in public, I would have sent my messages to the mailing list... > > I probably should, but I fear that before I have the > > time to read & understand & test & install those > > updates, you will just have rewritten them all over > > again. This is a bit frustrating... > >I didn't understand why you want to reinvent the wheel ? There is a key point that you are overlooking. I was already working on my own large updates to `ps' before you sent any messages to any mailing lists. I was discussing those publicly on the mailing lists. The major changes that I committed in April was just the "safe part" of the larger work I was doing. It was the parts of my larger change that I felt were safe to MFC into 4.x-stable. At the time I was pushing those in to 5.x-current so I could have them adequately tested in time to MFC them before 4.10-release shipped. I did manage to do that. I then hit end-of-semester here at RPI, at which point I have zero free time. None. The remaining changes were things that I doubt I will ever MFC (just because there are too many differences between `ps' in 4.x vs 5.x). Right near the end of the public testing of that first set of changes, you showed up with your update, wishing that someone would pick up the update. You were probably not on the mailing list where my earlier discussion had been going on (freebsd-standards), so you missed that I was already working on `ps'. I am not "reinventing the wheel" after you wrote your update. I am not doing that any more (or any less) than you were. We just both happened to start working on this at about the same time. Things like this just happen from time-to-time... I am continuing with updates I was already working on before you presented your huge update. You were quite enthusiastic about your changes, so initially I put my work on hold and asked you various issues I saw in your updates. I sent multiple messages. I got no answers. After a few weeks of waiting, I finally had some free time again so I decided to go back to the work I was already doing. I did that because I tried various parts of your update and THEY DID NOT WORK. Thus, it is much *LESS* work for me to continue with the updates that I already understood (because I am writing them...), than to figure out what all 4,000 lines of your update was doing, and all the side-effects of that update. My updates do not address everything that your massive update addresses, but then your massive update does not cover some of the things I have in the pipelines. No matter how we slice it, it will take work to combine the two streams. If I am the one doing the commits, then I need to understand the code I am committing. The biggest mistakes I have made have happened when I committed someone else's update because "it looks OK", without really understanding what it did. I do not intend to make that mistake again. It will take me a fair amount of time to understand all that is done by your update -- and I am not going to commit any of it until I am sure that I understand it. If my name is on the commit, then I will be the person responsible for it. I am still interested in looking over your changes, so I will check the PR. Right now I am actually focused on newsyslog, but I'll look at these when I get back to looking at `ps'. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 10:08:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04A1716A4CE for ; Wed, 9 Jun 2004 10:08:49 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2788643D31 for ; Wed, 9 Jun 2004 10:08:48 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i59A8lAf053638 for ; Wed, 9 Jun 2004 12:08:47 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 09 Jun 2004 12:08:47 +0200 Message-ID: <53637.1086775727@critter.freebsd.dk> Subject: COMPAT_SUNOS lovers anywere ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 10:08:49 -0000 Any objections to nuking the COMPAT_SUNOS option ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 11:16:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA2AC16A4CE for ; Wed, 9 Jun 2004 11:16:44 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 006D243D49 for ; Wed, 9 Jun 2004 11:16:44 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i59BGUPv053994 for ; Wed, 9 Jun 2004 13:16:30 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 09 Jun 2004 13:16:30 +0200 Message-ID: <53993.1086779790@critter.freebsd.dk> Subject: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 11:16:44 -0000 I have an item on my TODO list which says "fix dev_t / udev_t kernel confusion before 5-STABLE ?". The confusions is that in userland dev_t is an integer type which encodes the major+minor number of a device, in the kernel it it a pointer to "struct cdev" which represents the device to the kernel. Back when dev_t became a struct pointer, I counted the number of kernel source files which used the kernel dev_t vs the ones that used the useland dev_t and found something like 325:25. Since we share a number of device drivers with other OSs, and following the simple plurality, I called the userland dev_t "udev_t" in the kernel. And therefore, "dev_t" in userland and "dev_t" in the kernel are entirely different. We had a discussion about fixing this some point back, and I am not sure if we really reached closure on it. The change proposed is more or less to do: s/dev_t/struct cdev */ s/udev_t/dev_t/ over all the kernel sources (366 files or so). The benefit is that we get the dev_t/udev_t confusion solved, the disadvantage (apart from the churn) is that we reduce the already limited direct source compatibility with other BSDs a bit further. Personally I'm pretty 50/50 on this issue, but if we want to do it, we want to do it before 5-STABLE, not after (to avoid the FreeBSD3 syndrome). Personally I don't think there is much need for a long discussion and I would prefer to see simply a show of hands for yes and no, and any hear any really heavy duty arguments pro et contra. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 12:43:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BDDD716A4E6; Wed, 9 Jun 2004 12:43:10 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i59ChAv5014599; Wed, 9 Jun 2004 08:43:10 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i59Ch91U014598; Wed, 9 Jun 2004 08:43:09 -0400 (EDT) (envelope-from green) Date: Wed, 9 Jun 2004 08:43:08 -0400 From: Brian Feldman To: Poul-Henning Kamp Message-ID: <20040609124308.GC11475@green.homeunix.org> References: <53993.1086779790@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53993.1086779790@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 12:43:11 -0000 On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: > [...] > The change proposed is more or less to do: > s/dev_t/struct cdev */ > s/udev_t/dev_t/ > over all the kernel sources (366 files or so). > [....] One yes vote, please. The dev_t structure is not treated as opaque, so as long as people are going to->dereference it, it deserves to be a struct *. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 14:24:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B23B116A4CE for ; Wed, 9 Jun 2004 14:24:21 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 926FD43D31 for ; Wed, 9 Jun 2004 14:24:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6315 invoked from network); 9 Jun 2004 14:24:17 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Jun 2004 14:24:17 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i59EODVa018208; Wed, 9 Jun 2004 10:24:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 9 Jun 2004 09:55:45 -0400 User-Agent: KMail/1.6 References: <53993.1086779790@critter.freebsd.dk> <20040609124308.GC11475@green.homeunix.org> In-Reply-To: <20040609124308.GC11475@green.homeunix.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406090955.49190.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Brian Feldman cc: Poul-Henning Kamp cc: arch@FreeBSD.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 14:24:21 -0000 On Wednesday 09 June 2004 08:43 am, Brian Feldman wrote: > On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: > > [...] > > The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > > over all the kernel sources (366 files or so). > > [....] > > One yes vote, please. The dev_t structure is not treated as opaque, > so as long as people are going to->dereference it, it deserves to be > a struct *. Seconded. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 14:24:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155B216A4CE for ; Wed, 9 Jun 2004 14:24:22 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEA8043D2F for ; Wed, 9 Jun 2004 14:24:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6315 invoked from network); 9 Jun 2004 14:24:17 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Jun 2004 14:24:17 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i59EODVa018208; Wed, 9 Jun 2004 10:24:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 9 Jun 2004 09:55:45 -0400 User-Agent: KMail/1.6 References: <53993.1086779790@critter.freebsd.dk> <20040609124308.GC11475@green.homeunix.org> In-Reply-To: <20040609124308.GC11475@green.homeunix.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406090955.49190.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Brian Feldman cc: Poul-Henning Kamp cc: arch@FreeBSD.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 14:24:22 -0000 On Wednesday 09 June 2004 08:43 am, Brian Feldman wrote: > On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: > > [...] > > The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > > over all the kernel sources (366 files or so). > > [....] > > One yes vote, please. The dev_t structure is not treated as opaque, > so as long as people are going to->dereference it, it deserves to be > a struct *. Seconded. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 14:28:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D4D16A4CE; Wed, 9 Jun 2004 14:28:01 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A745343D2F; Wed, 9 Jun 2004 14:28:01 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id D8A6F5C867; Wed, 9 Jun 2004 07:27:56 -0700 (PDT) Date: Wed, 9 Jun 2004 16:27:56 +0200 From: Maxime Henrion To: Brian Feldman Message-ID: <20040609142756.GU9228@elvis.mu.org> References: <53993.1086779790@critter.freebsd.dk> <20040609124308.GC11475@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040609124308.GC11475@green.homeunix.org> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 14:28:01 -0000 Brian Feldman wrote: > On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: > > [...] > > The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > > over all the kernel sources (366 files or so). > > [....] > > One yes vote, please. The dev_t structure is not treated as opaque, > so as long as people are going to->dereference it, it deserves to be > a struct *. This reflects what I think perfectly. Cheers, Maxime From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 14:29:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26F4D16A4CE for ; Wed, 9 Jun 2004 14:29:10 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86B4443D2F for ; Wed, 9 Jun 2004 14:29:09 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.30) id 1BY47d-0001mv-WE; Wed, 09 Jun 2004 21:32:10 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i59ETBVf046678; Wed, 9 Jun 2004 21:29:11 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i59ETBJR046656; Wed, 9 Jun 2004 21:29:11 +0700 (NOVST) (envelope-from danfe) Date: Wed, 9 Jun 2004 21:29:11 +0700 From: Alexey Dokuchaev To: Poul-Henning Kamp Message-ID: <20040609142911.GA43972@regency.nsu.ru> References: <53993.1086779790@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53993.1086779790@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 14:29:10 -0000 On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: > > I have an item on my TODO list which says "fix dev_t / udev_t kernel > confusion before 5-STABLE ?". > > The confusions is that in userland dev_t is an integer type which > encodes the major+minor number of a device, in the kernel it it a > pointer to "struct cdev" which represents the device to the kernel. Go for solving the confusion, phk. I'd sacrifice compatibility with other BSDs here in sake of coherency. ./danfe From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 14:58:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C062916A4CE for ; Wed, 9 Jun 2004 14:58:31 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72EDF43D58 for ; Wed, 9 Jun 2004 14:58:31 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i59EvPls006911; Wed, 9 Jun 2004 10:57:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i59EvPh4006908; Wed, 9 Jun 2004 10:57:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 9 Jun 2004 10:57:24 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <53993.1086779790@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 14:58:31 -0000 On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > Personally I don't think there is much need for a long discussion and I > would prefer to see simply a show of hands for yes and no, and any hear > any really heavy duty arguments pro et contra. Sounds good to me -- I ran into this recently with the audit implementation because Solaris embeds a "udev_t" in the BSM audit format. Since the format is handled by the kernel as well as user space, I had to do the usual gymnastics to work around the udev_t confusion. I'd love to see that resolved, thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 15:15:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 439AC16A4CE for ; Wed, 9 Jun 2004 15:15:39 +0000 (GMT) Received: from tara.freenix.org (keltia.freenix.org [82.224.56.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id C301C43D49 for ; Wed, 9 Jun 2004 15:15:36 +0000 (GMT) (envelope-from roberto@keltia.freenix.fr) Received: by tara.freenix.org (Postfix/TLS, from userid 101) id 723C32E2A; Wed, 9 Jun 2004 17:15:33 +0200 (CEST) Date: Wed, 9 Jun 2004 17:15:33 +0200 From: Ollivier Robert To: arch@freebsd.org Message-ID: <20040609151533.GA68949@tara.freenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: MacOS X / PowerBook G4 - FreeBSD 5.0 / 2x PIII/800 SMP User-Agent: Mutt/1.5.6i Subject: NTP import coming question: location of crypto keys for ntpd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 15:15:39 -0000 I'm preparing the upcoming ntp 4.2.0 import into what-will-be 5.3 and am wondering on this. In the past, the preconfigured location for crypto keys is "/usr/local/etc", in-sync with what is used by the net/ntp port. For the base system, I was thinking of maybe change it to something close to "/etc/ntp" (in line with /etc/ppp & /etc/ssh). Is it worth the HEADS-UP/UPDATING note I'd need to put or do I just keep it that way? PS: they have renamed a lot of files from .htm to .html (I hate such gratuituous changes) and I must say that Arch[1] made it very easy to see the changes & renames... ----- [1] http://gnuarch.org/ a distributed VCS close to BitKeeper but free. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin snuadh.freenix.org Kernel Version 7.4.0: Wed May 12 16:58:24 PDT 2004 From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 15:56:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1260D16A4CE for ; Wed, 9 Jun 2004 15:56:03 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C14043D49 for ; Wed, 9 Jun 2004 15:56:02 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i59FtxLg055791 for ; Wed, 9 Jun 2004 17:56:00 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Jun 2004 13:16:30 +0200." <53993.1086779790@critter.freebsd.dk> Date: Wed, 09 Jun 2004 17:55:59 +0200 Message-ID: <55790.1086796559@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 15:56:03 -0000 In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: >The change proposed is more or less to do: > s/dev_t/struct cdev */ > s/udev_t/dev_t/ >over all the kernel sources (366 files or so). Looks like a "yea" so far, so I have a couple of follow-up questions: struct cdev currently has members named si_* because it used to be called "specinfo", do we want to change that inconsistency at the same time ? (either by reverting to the specinfo name or by changing to a cd_ prefix ? cdevsw->ioctl() takes a caddr_t pointer argument which really should be a void *, do we want to change that as well (since it is all the same files we'll have to change). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 16:23:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 212AF16A4CE for ; Wed, 9 Jun 2004 16:23:17 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id F00E043D5D for ; Wed, 9 Jun 2004 16:23:16 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24378 invoked from network); 9 Jun 2004 16:23:16 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Jun 2004 16:23:16 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i59GND5h018994; Wed, 9 Jun 2004 12:23:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 9 Jun 2004 12:24:04 -0400 User-Agent: KMail/1.6 References: <55790.1086796559@critter.freebsd.dk> In-Reply-To: <55790.1086796559@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406091224.04653.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: arch@FreeBSD.org cc: Poul-Henning Kamp Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:23:17 -0000 On Wednesday 09 June 2004 11:55 am, Poul-Henning Kamp wrote: > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: > >The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > >over all the kernel sources (366 files or so). > > Looks like a "yea" so far, so I have a couple of follow-up questions: > > struct cdev currently has members named si_* because it > used to be called "specinfo", do we want to change that > inconsistency at the same time ? (either by reverting to > the specinfo name or by changing to a cd_ prefix ? Sure, maybe dev_foo prefix? cd_ is fine though, just pick one and be consistent. > cdevsw->ioctl() takes a caddr_t pointer argument which > really should be a void *, do we want to change that > as well (since it is all the same files we'll have to > change). Ok with me. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 16:23:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2257116A4D0 for ; Wed, 9 Jun 2004 16:23:17 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFF7043D5C for ; Wed, 9 Jun 2004 16:23:16 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24378 invoked from network); 9 Jun 2004 16:23:16 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Jun 2004 16:23:16 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i59GND5h018994; Wed, 9 Jun 2004 12:23:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 9 Jun 2004 12:24:04 -0400 User-Agent: KMail/1.6 References: <55790.1086796559@critter.freebsd.dk> In-Reply-To: <55790.1086796559@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406091224.04653.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: arch@FreeBSD.org cc: Poul-Henning Kamp Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:23:17 -0000 On Wednesday 09 June 2004 11:55 am, Poul-Henning Kamp wrote: > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: > >The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > >over all the kernel sources (366 files or so). > > Looks like a "yea" so far, so I have a couple of follow-up questions: > > struct cdev currently has members named si_* because it > used to be called "specinfo", do we want to change that > inconsistency at the same time ? (either by reverting to > the specinfo name or by changing to a cd_ prefix ? Sure, maybe dev_foo prefix? cd_ is fine though, just pick one and be consistent. > cdevsw->ioctl() takes a caddr_t pointer argument which > really should be a void *, do we want to change that > as well (since it is all the same files we'll have to > change). Ok with me. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 16:42:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8537F16A4CE for ; Wed, 9 Jun 2004 16:42:40 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1292543D49 for ; Wed, 9 Jun 2004 16:42:40 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i59GgdVu004571; Wed, 9 Jun 2004 12:42:39 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040609124308.GC11475@green.homeunix.org> References: <53993.1086779790@critter.freebsd.dk> <20040609124308.GC11475@green.homeunix.org> Date: Wed, 9 Jun 2004 12:42:38 -0400 To: Poul-Henning Kamp From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:42:40 -0000 At 8:43 AM -0400 6/9/04, Brian Feldman wrote: >On Wed, Jun 09, 2004, Poul-Henning Kamp wrote: > > [...] >> The change proposed is more or less to do: >> s/dev_t/struct cdev */ >> s/udev_t/dev_t/ >> over all the kernel sources (366 files or so). >> [....] > >One yes vote, please. The dev_t structure is not treated as >opaque, so as long as people are going to->dereference it, it >deserves to be a struct *. This sounds like the right path to me. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 16:43:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE01716A4DC for ; Wed, 9 Jun 2004 16:43:34 +0000 (GMT) Received: from mail.tiscali.cz (stateless2.tiscali.cz [213.235.135.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB3D43D46 for ; Wed, 9 Jun 2004 16:43:34 +0000 (GMT) (envelope-from hsn@netmag.cz) Received: from asura.bsd (212.11.96.191) by mail.tiscali.cz (6.7.021) id 40B1F786006F6FEC for freebsd-arch@freebsd.org; Wed, 9 Jun 2004 18:43:33 +0200 Received: from hsn@localhost by asura.bsd (Exim 4.33_1 FreeBSD) id 1BY5Bw-000G5i-6y for ; Wed, 09 Jun 2004 17:40:40 +0200 Date: Wed, 9 Jun 2004 17:40:40 +0200 From: Radim Kolar To: freebsd-arch@freebsd.org Message-ID: <20040609154040.GA26229@asura.bsd> Mail-Followup-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:43:35 -0000 I have submitted pr http://www.freebsd.org/cgi/query-pr.cgi?pr=65402 with patch which makes fflush() on read only descriptors do not return error code. Reasons for this patch: 1 - Do not breaks ISO C standard 2 - Makes FreeBSD undefined behavior compatible with other operation systems 3 - Correct some programs depending on this 4 - Makes fflush() and fsync() behavior identical - avoids programmer's confusion. 5 - If there are no data to flush() then flush operation (dummy) succeeds, not failed. Against this patch: Programs which rely upon fflush() not returning an error when passed a file which is opened read-only are broken, and should be fixed. Colin Percival Are there any other reasons for non commiting it? I think that in this case pro > cons. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 16:48:29 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3645816A4CE for ; Wed, 9 Jun 2004 16:48:29 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C4AE43D1F for ; Wed, 9 Jun 2004 16:48:29 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 641F55C850; Wed, 9 Jun 2004 09:48:12 -0700 (PDT) Date: Wed, 9 Jun 2004 18:48:12 +0200 From: Maxime Henrion To: Poul-Henning Kamp Message-ID: <20040609164812.GW9228@elvis.mu.org> References: <53993.1086779790@critter.freebsd.dk> <55790.1086796559@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55790.1086796559@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:48:29 -0000 Poul-Henning Kamp wrote: > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: > > >The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > >over all the kernel sources (366 files or so). > > Looks like a "yea" so far, so I have a couple of follow-up questions: > > struct cdev currently has members named si_* because it > used to be called "specinfo", do we want to change that > inconsistency at the same time ? (either by reverting to > the specinfo name or by changing to a cd_ prefix ? Sounds reasonable. > cdevsw->ioctl() takes a caddr_t pointer argument which > really should be a void *, do we want to change that > as well (since it is all the same files we'll have to > change). Yes, please! :-) Cheers, Maxime From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 17:03:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BB3716A4CE for ; Wed, 9 Jun 2004 17:03:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E296543D1D for ; Wed, 9 Jun 2004 17:03:24 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i59H5hH1003017; Wed, 9 Jun 2004 11:05:44 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C742A0.5090704@freebsd.org> Date: Wed, 09 Jun 2004 11:02:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <55790.1086796559@critter.freebsd.dk> In-Reply-To: <55790.1086796559@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 17:03:25 -0000 Poul-Henning Kamp wrote: > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: > > >>The change proposed is more or less to do: >> s/dev_t/struct cdev */ >> s/udev_t/dev_t/ >>over all the kernel sources (366 files or so). > > > Looks like a "yea" so far, so I have a couple of follow-up questions: > > struct cdev currently has members named si_* because it > used to be called "specinfo", do we want to change that > inconsistency at the same time ? (either by reverting to > the specinfo name or by changing to a cd_ prefix ? Sounds fine to me. No prefix at all would work too. > > cdevsw->ioctl() takes a caddr_t pointer argument which > really should be a void *, do we want to change that > as well (since it is all the same files we'll have to > change). > Is this going to have any consequences on COMPAT_LINUX code or anything else that calls ioctl() through obscure means? Scott From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 17:25:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ECD016A4CE; Wed, 9 Jun 2004 17:25:53 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DF4C43D31; Wed, 9 Jun 2004 17:25:52 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i59HPfXD056599; Wed, 9 Jun 2004 19:25:42 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Jun 2004 11:02:24 MDT." <40C742A0.5090704@freebsd.org> Date: Wed, 09 Jun 2004 19:25:41 +0200 Message-ID: <56598.1086801941@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 17:25:53 -0000 In message <40C742A0.5090704@freebsd.org>, Scott Long writes: >> cdevsw->ioctl() takes a caddr_t pointer argument which >> really should be a void *, do we want to change that >> as well (since it is all the same files we'll have to >> change). >> > >Is this going to have any consequences on COMPAT_LINUX code or anything >else that calls ioctl() through obscure means? Well, it has more impact for the places which implement the ioctl, in particular if they do pointer arithmetic on the pointer (legal on caddr_t but illegal on void *). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 17:33:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F75116A4CE for ; Wed, 9 Jun 2004 17:33:25 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0097343D1D for ; Wed, 9 Jun 2004 17:33:25 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 935AC72DF4; Wed, 9 Jun 2004 10:33:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 9135C72DF2; Wed, 9 Jun 2004 10:33:13 -0700 (PDT) Date: Wed, 9 Jun 2004 10:33:13 -0700 (PDT) From: Doug White To: Ollivier Robert In-Reply-To: <20040609151533.GA68949@tara.freenix.org> Message-ID: <20040609103051.X41021@carver.gumbysoft.com> References: <20040609151533.GA68949@tara.freenix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: NTP import coming question: location of crypto keys for ntpd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 17:33:25 -0000 On Wed, 9 Jun 2004, Ollivier Robert wrote: > I'm preparing the upcoming ntp 4.2.0 import into what-will-be 5.3 and am > wondering on this. In the past, the preconfigured location for crypto keys > is "/usr/local/etc", in-sync with what is used by the net/ntp port. > > For the base system, I was thinking of maybe change it to something close > to "/etc/ntp" (in line with /etc/ppp & /etc/ssh). Sounds like a fine place for me. As long as you don't move ntp.conf, I don't think people are going to notice, and other platforms have /etc/ntp already. > Is it worth the HEADS-UP/UPDATING note I'd need to put or do I just keep it > that way? A heads-up for the import in general is probably warranted. NTP can break in strange and unusual ways and it can be hard to notice :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:24:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC65916A4CE; Wed, 9 Jun 2004 18:24:19 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5926243D2D; Wed, 9 Jun 2004 18:24:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004060918234901100fn8dle>; Wed, 9 Jun 2004 18:23:51 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA58947; Wed, 9 Jun 2004 11:23:50 -0700 (PDT) Date: Wed, 9 Jun 2004 11:23:48 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp In-Reply-To: <57019.1086804305@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_proc.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:24:20 -0000 On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > > >On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > >> In message , Ju > >> lian Elischer writes: > >> > >> >As I've said before and will continue to say.. > >> >"We need a more formal model of dealing with reference counts" > >> > > >> >i.e. > >> > > >> >we should get a set of reference counting primatives and make it WELL > >> >DOCUMENTED as to how they should be used.. > >> > >> And as others have replied: It is seldom worth it from code clarity > >> or performance wise. > > > >few have replied in that way.. > >most have agreed that it is worth persuing.. > > Then do so :-) I do actually agree that a general purpose reference counting API is very difficult to use in every situation and that there are situations where you just HAVE to roll your own.. The question is whether there are enough "simpler" cases around to make it worth spending resources on making an API to use.. several possible points that need to be kept in mind that have complicated my previous attempts to do so are: If you reference count EVERYWHERE, then you need to be able to add and subtract references very cheaply because you might end up doing it a lot. You also need to consider than in the kernel, the last referenc to somethign could easily occur in an interrupt routine, so the 'free' actions need to either be runnable at that time, or a mechanism needs to be developed to defer teh actual freeing to another time. Anyhow if anyone is interested I'll take this to -arch.. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:32:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45A6116A4CE for ; Wed, 9 Jun 2004 18:32:24 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AE443D46 for ; Wed, 9 Jun 2004 18:32:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i59IUjWG046042; Wed, 9 Jun 2004 12:30:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Jun 2004 12:31:01 -0600 (MDT) Message-Id: <20040609.123101.08394961.imp@bsdimp.com> To: danfe@nsu.ru From: "M. Warner Losh" In-Reply-To: <20040609142911.GA43972@regency.nsu.ru> References: <53993.1086779790@critter.freebsd.dk> <20040609142911.GA43972@regency.nsu.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org cc: phk@phk.freebsd.dk Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:32:24 -0000 In message: <20040609142911.GA43972@regency.nsu.ru> Alexey Dokuchaev writes: : On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: : > : > I have an item on my TODO list which says "fix dev_t / udev_t kernel : > confusion before 5-STABLE ?". : > : > The confusions is that in userland dev_t is an integer type which : > encodes the major+minor number of a device, in the kernel it it a : > pointer to "struct cdev" which represents the device to the kernel. : : Go for solving the confusion, phk. I'd sacrifice compatibility with : other BSDs here in sake of coherency. Actually, this makes us more compatible with other BSDs. They never went down this path. However, it does add costs to those companies (like the one I work for) that have to have drivers for both 4.x and 5.x. These costs can be managed, but it is a bit of a pain. Luckily for me, it looks like the conversion cost of other parts of the driver is high in comparison to this change, which incrementally increases it. I'm not sure that I like the churn this causes, but I'm not going to fight it. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:35:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEE2D16A4CE for ; Wed, 9 Jun 2004 18:35:10 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 787C743D1F for ; Wed, 9 Jun 2004 18:35:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i59IWr2a046054; Wed, 9 Jun 2004 12:32:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Jun 2004 12:33:09 -0600 (MDT) Message-Id: <20040609.123309.98422136.imp@bsdimp.com> To: roberto@keltia.freenix.fr From: "M. Warner Losh" In-Reply-To: <20040609151533.GA68949@tara.freenix.org> References: <20040609151533.GA68949@tara.freenix.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: NTP import coming question: location of crypto keys for ntpd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:35:11 -0000 In message: <20040609151533.GA68949@tara.freenix.org> Ollivier Robert writes: : For the base system, I was thinking of maybe change it to something close : to "/etc/ntp" (in line with /etc/ppp & /etc/ssh). Seems good to me. : Is it worth the HEADS-UP/UPDATING note I'd need to put or do I just keep it : that way? I'd do both. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:35:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AA2016A4CE for ; Wed, 9 Jun 2004 18:35:43 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 401D143D54 for ; Wed, 9 Jun 2004 18:35:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <200406091835400130097dhie>; Wed, 9 Jun 2004 18:35:41 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA59232 for ; Wed, 9 Jun 2004 11:35:42 -0700 (PDT) Date: Wed, 9 Jun 2004 11:35:40 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:35:43 -0000 There are several goals that need to be kept in mind. * Operations should be quick.. * Atomic operations can be slow in some architectures. * the last free may need to occur at an inconvenient time. (in sched-lock or an interrupt routine). * There may need to be more than one kind of schedlock, for different cases, though I'd hope that they'd have the same methods.. (A reference count scheme that doesn't have to ever consider the fact that the object may be freed in an interrupt handler might be considereably smaller/quicker than one that needs to take that possibility into account. ) Here's an API I mentionned once before.. I'm only showing this as an example to start discussion... it doesn't cover everything we'd need.. For example how would you do deferred free? ------------------quoted old email------------------ I have seen and liked a refcount API which was (from memory something like): void * refcnt_add(offsetof(struct obj, refcnt), void ** object_p) which takes a pointer to the object pointer you are copying, and atomically increments it and returns the contents of the pointer. If the contents of the pointer are NULL, then it returns NULL and doesn't increment anything.. The reference decrement atomically reduced the reference count and zapped the pointer, and retunred a copy of the pointer if the reference count had gone to 0 (or NULL if not). So usage was: struct xx *globalpointer; /* has its own owner somewhere */ mypointer = refcnt_add(offsetof(xx, refcnt), globalptr) if (mypointer == NULL) { printf("didn't find an object\n" return (-1); } manipulate(mypointer) if ((tmppointer = refcnt_drop(&mypointer, &globalpointer))) { free(tmppointer); } someone else who owns the globalpointer reference might might in the meanwhile do: if ((tmppointer = refcnt_drop(globalpointer->refcnt, &globalpointer))) { free(tmppointer); } and you were guaranteed to get a predictable result. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:37:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA15A16A4CE for ; Wed, 9 Jun 2004 18:37:19 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 580F243D46 for ; Wed, 9 Jun 2004 18:37:19 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id B9D8AACAF4; Wed, 9 Jun 2004 20:37:03 +0200 (CEST) Date: Wed, 9 Jun 2004 20:37:03 +0200 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20040609183703.GX12007@darkness.comp.waw.pl> References: <57019.1086804305@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KZCIPwrNpw38UenM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/kern kern_proc.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:37:19 -0000 --KZCIPwrNpw38UenM Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2004 at 11:23:48AM -0700, Julian Elischer wrote: +> I do actually agree that a general purpose reference counting=20 +> API is very difficult to use in every situation and that there=20 +> are situations where you just HAVE to roll your own.. Maybe we can use macros to do this, something like: #define REFCNT_MTX(foo, prefix, type, mtx_field, refcnt_field, destroy_func= ) \ foo void \ prefix ## _hold(type *obj) \ { \ \ mtx_lock(&obj->mtx_field); \ obj->refcnt_field++; \ mtx_unlock(&obj->mtx_field); \ } \ \ foo void \ prefix ## _free(type *obj) \ { \ int refcnt; \ \ mtx_lock(&obj->mtx_field); \ refcnt =3D --obj->refcnt_field; \ mtx_unlock(&obj->mtx_field); \ if (refcnt =3D=3D 0) \ destroy_func(obj); \ } And the same for REFCNT_ATOMIC() and REFCNT_SPIN()? 'foo' could be for example 'static' or 'static __inline'. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --KZCIPwrNpw38UenM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAx1jPForvXbEpPzQRAq2JAJ47cECI0Tkw1cnV2Ve2XhDn+TN0YQCeJ5aQ Vvxce9IR1yBIH5qvHGtFTsU= =g99S -----END PGP SIGNATURE----- --KZCIPwrNpw38UenM-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:39:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F52416A4CE for ; Wed, 9 Jun 2004 18:39:09 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6019543D49 for ; Wed, 9 Jun 2004 18:39:08 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i59Id4eY057611; Wed, 9 Jun 2004 20:39:04 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Jun 2004 11:35:40 PDT." Date: Wed, 09 Jun 2004 20:39:04 +0200 Message-ID: <57610.1086806344@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:39:09 -0000 In message , Ju lian Elischer writes: > >There are several goals that need to be kept in mind. Please, whatever you do, show that your API will deal with the refcounting of struct tty. Pay particular attention to the sysctl function which makes the difference between a CS-101 assignment and the real world. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:46:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 482D516A4CE for ; Wed, 9 Jun 2004 18:46:34 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3630343D2F for ; Wed, 9 Jun 2004 18:46:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <20040609184611013009f1p8e>; Wed, 9 Jun 2004 18:46:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA59410 for ; Wed, 9 Jun 2004 11:46:11 -0700 (PDT) Date: Wed, 9 Jun 2004 11:46:09 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:46:34 -0000 Eak! was I on something my head said "ref-count" and my fongers typed "schedlock" s/schedlock/ref-count/ On Wed, 9 Jun 2004, Julian Elischer wrote: > > There are several goals that need to be kept in mind. > > * Operations should be quick.. > * Atomic operations can be slow in some architectures. > * the last free may need to occur at an inconvenient time. > (in sched-lock or an interrupt routine). > * There may need to be more than one kind of schedlock, > for different cases, though I'd hope that they'd have the same > methods.. > (A reference count scheme that doesn't have to ever consider the > fact that the object may be freed in an interrupt handler > might be considereably smaller/quicker than one that needs to > take that possibility into account. ) > > Here's an API I mentionned once before.. I'm only showing this as an > example to start discussion... > it doesn't cover everything we'd need.. > > For example how would you do deferred free? > > > ------------------quoted old email------------------ > > I have seen and liked > a refcount API which was (from memory something like): > > void * refcnt_add(offsetof(struct obj, refcnt), void ** object_p) > > which takes a pointer to the object pointer you are copying, and > atomically increments it and returns the contents of the pointer. > If the contents of the pointer are NULL, then it returns NULL > and doesn't increment anything.. > > The reference decrement atomically reduced the reference count and > zapped the pointer, and retunred a copy of the pointer if > the reference count had gone to 0 (or NULL if not). > > So usage was: > struct xx *globalpointer; /* has its own owner somewhere */ > > mypointer = refcnt_add(offsetof(xx, refcnt), globalptr) > if (mypointer == NULL) { > printf("didn't find an object\n" > return (-1); > > } > manipulate(mypointer) > if ((tmppointer = refcnt_drop(&mypointer, &globalpointer))) { > free(tmppointer); > } > > > > someone else who owns the globalpointer reference might might in > the meanwhile do: > > if ((tmppointer = refcnt_drop(globalpointer->refcnt, &globalpointer))) { > free(tmppointer); > } > > and you were guaranteed to get a predictable result. > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:49:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8643E16A4CE for ; Wed, 9 Jun 2004 18:49:15 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C0CF43D31 for ; Wed, 9 Jun 2004 18:49:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <2004060918490501300995u2e>; Wed, 9 Jun 2004 18:49:05 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA59443; Wed, 9 Jun 2004 11:49:06 -0700 (PDT) Date: Wed, 9 Jun 2004 11:49:05 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp In-Reply-To: <57610.1086806344@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:49:15 -0000 On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > > >There are several goals that need to be kept in mind. > > Please, whatever you do, show that your API will deal with the > refcounting of struct tty. Pay particular attention to the > sysctl function which makes the difference between a CS-101 > assignment and the real world. yes this is the kind of thing that makes for 'fun'.. So, having just dealt with it, how would you go about describing the general case that your example falls into (for example if you were writing a textbook)? From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 18:59:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E55616A4CE for ; Wed, 9 Jun 2004 18:59:09 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EFD43D45 for ; Wed, 9 Jun 2004 18:59:08 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i59Iwv47057801; Wed, 9 Jun 2004 20:58:57 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Jun 2004 11:49:05 PDT." Date: Wed, 09 Jun 2004 20:58:57 +0200 Message-ID: <57800.1086807537@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 18:59:09 -0000 In message , Ju lian Elischer writes: >> Please, whatever you do, show that your API will deal with the >> refcounting of struct tty. Pay particular attention to the >> sysctl function which makes the difference between a CS-101 >> assignment and the real world. > >yes this is the kind of thing that makes for 'fun'.. >So, having just dealt with it, >how would you go about describing the general case that your example >falls into (for example if you were writing a textbook)? I am not in favour of a dedicated API for refcounts. A dedicated API works if the refcount is a detached property of the object, and that is not normally the case outside OO+GC implementations. Our reference counts will almost invariably be integral properties of our objects and therefore has to interact with the remaining object locking. I simply do not belive that a "refcount API" will have that many uses in our kernel, most places we will have to hand-roll anyway. So before you spend too much time on this, I suggest you define what the API will look like, write the manpage and forget the implementation. Then use that definition to see how it would be used in actual kernel code. If the result of that is that code becomes more clear and easier to get correct for the programmers, then we can move ahead and see how to implement it, but if we end up with too many REF_YOU_CAN_NOT_REMEMBER_HOW_TO_USE_THIS(foo->ref, REF_MAGIC23) Then you can save the time spent thinking about the implementation. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 19:00:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED1216A4CE; Wed, 9 Jun 2004 19:00:43 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C2E943D49; Wed, 9 Jun 2004 19:00:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <200406091900350130096uoje>; Wed, 9 Jun 2004 19:00:35 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA59653; Wed, 9 Jun 2004 12:00:32 -0700 (PDT) Date: Wed, 9 Jun 2004 12:00:30 -0700 (PDT) From: Julian Elischer To: Pawel Jakub Dawidek In-Reply-To: <20040609183703.GX12007@darkness.comp.waw.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/kern kern_proc.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 19:00:43 -0000 On Wed, 9 Jun 2004, Pawel Jakub Dawidek wrote: > On Wed, Jun 09, 2004 at 11:23:48AM -0700, Julian Elischer wrote: > +> I do actually agree that a general purpose reference counting > +> API is very difficult to use in every situation and that there > +> are situations where you just HAVE to roll your own.. > > Maybe we can use macros to do this, something like: > > #define REFCNT_MTX(foo, prefix, type, mtx_field, refcnt_field, destroy_func) \ > foo void \ > prefix ## _hold(type *obj) \ > { \ > \ > mtx_lock(&obj->mtx_field); \ > obj->refcnt_field++; \ > mtx_unlock(&obj->mtx_field); \ > } \ > \ > foo void \ > prefix ## _free(type *obj) \ > { \ > int refcnt; \ > \ > mtx_lock(&obj->mtx_field); \ > refcnt = --obj->refcnt_field; \ > mtx_unlock(&obj->mtx_field); \ > if (refcnt == 0) \ > destroy_func(obj); \ > } > > And the same for REFCNT_ATOMIC() and REFCNT_SPIN()? > 'foo' could be for example 'static' or 'static __inline'. I certainly agree that there is the possibility that there may need to be several kinds of refcounts.. there are also examples where several operations need to be done "atomically" but only one of those operations is the reference count. Such cases need a lock to be held anyhow. (or a critical section or something) For these sorts of things plain increments and decrements would suffice. As I mentionned before, it is also tricky how one handles the freeing of a reference to an object when you are in some spinlock'd region or an interrupt handler.. These various cases may require reference counts of different types. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 19:05:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0D4716A4CE for ; Wed, 9 Jun 2004 19:05:58 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id A07A143D41 for ; Wed, 9 Jun 2004 19:05:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040609190555012002l9h6e>; Wed, 9 Jun 2004 19:05:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA59750; Wed, 9 Jun 2004 12:05:55 -0700 (PDT) Date: Wed, 9 Jun 2004 12:05:53 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp In-Reply-To: <57800.1086807537@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 19:05:59 -0000 On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > >> Please, whatever you do, show that your API will deal with the > >> refcounting of struct tty. Pay particular attention to the > >> sysctl function which makes the difference between a CS-101 > >> assignment and the real world. > > > >yes this is the kind of thing that makes for 'fun'.. > >So, having just dealt with it, > >how would you go about describing the general case that your example > >falls into (for example if you were writing a textbook)? > > I am not in favour of a dedicated API for refcounts. > > A dedicated API works if the refcount is a detached property of the > object, and that is not normally the case outside OO+GC implementations. > > Our reference counts will almost invariably be integral properties > of our objects and therefore has to interact with the remaining > object locking. > > I simply do not belive that a "refcount API" will have that many uses > in our kernel, most places we will have to hand-roll anyway. > > So before you spend too much time on this, I suggest you define > what the API will look like, write the manpage and forget the > implementation. > > Then use that definition to see how it would be used in actual > kernel code. > > If the result of that is that code becomes more clear and easier > to get correct for the programmers, then we can move ahead and > see how to implement it, but if we end up with too many > > REF_YOU_CAN_NOT_REMEMBER_HOW_TO_USE_THIS(foo->ref, REF_MAGIC23) > > Then you can save the time spent thinking about the implementation. I agree with this sentiment and I think I already mentionned that the pivotal factor is whether there are enough cases in the kernel where such an API could be used.. My gut feeling is that there are probably just enough to make it worth while because of the number of times that I've implemented ref countes and the number of times I've thought "There should be an API to do this for me". However that is not a very scientific basis, so definitly it is worht looking as a cross-section of all the reference counts in the kernel. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 19:40:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B4E416A4CE for ; Wed, 9 Jun 2004 19:40:59 +0000 (GMT) Received: from mail021.syd.optusnet.com.au (mail021.syd.optusnet.com.au [211.29.132.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24B0D43D55 for ; Wed, 9 Jun 2004 19:40:58 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i59JdqH11410; Thu, 10 Jun 2004 05:39:52 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i59JdpVd027606; Thu, 10 Jun 2004 05:39:51 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i59JdoSO027605; Thu, 10 Jun 2004 05:39:50 +1000 (EST) (envelope-from pjeremy) Date: Thu, 10 Jun 2004 05:39:50 +1000 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20040609193950.GF1596@cirb503493.alcatel.com.au> References: <53993.1086779790@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53993.1086779790@critter.freebsd.dk> User-Agent: Mutt/1.4.2i cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 19:40:59 -0000 On Wed, 2004-Jun-09 13:16:30 +0200, Poul-Henning Kamp wrote: >The benefit is that we get the dev_t/udev_t confusion solved, the >disadvantage (apart from the churn) is that we reduce the already >limited direct source compatibility with other BSDs a bit further. Getting rid of the confusing situation where the same type name means totally different things in userland and kernel is a big win. We can always try to convince the other BSDs to follow suit. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 20:04:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A55F516A4CE for ; Wed, 9 Jun 2004 20:04:09 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AD0643D54 for ; Wed, 9 Jun 2004 20:04:09 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i59K65Qj004025; Wed, 9 Jun 2004 14:06:05 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C76CE5.9080204@freebsd.org> Date: Wed, 09 Jun 2004 14:02:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <53993.1086779790@critter.freebsd.dk> <20040609193950.GF1596@cirb503493.alcatel.com.au> In-Reply-To: <20040609193950.GF1596@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 20:04:09 -0000 Peter Jeremy wrote: > On Wed, 2004-Jun-09 13:16:30 +0200, Poul-Henning Kamp wrote: > >>The benefit is that we get the dev_t/udev_t confusion solved, the >>disadvantage (apart from the churn) is that we reduce the already >>limited direct source compatibility with other BSDs a bit further. > > > Getting rid of the confusing situation where the same type name > means totally different things in userland and kernel is a big win. > We can always try to convince the other BSDs to follow suit. The other BSDs use dev_t in both kernel and userland to mean the same thing, which is equivalent to how we use udev_t. Fixing this has a lot of benefits and I'm totally in favor of it. I share Warner's concern about 4.x/5.x compatibility, but I gave up on that in my drivers long ago since the API have changed to much. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 20:54:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1911416A4CE for ; Wed, 9 Jun 2004 20:54:43 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ECB543D53 for ; Wed, 9 Jun 2004 20:54:43 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 17C6372DF2; Wed, 9 Jun 2004 13:54:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 1371472DB5; Wed, 9 Jun 2004 13:54:32 -0700 (PDT) Date: Wed, 9 Jun 2004 13:54:32 -0700 (PDT) From: Doug White To: Radim Kolar In-Reply-To: <20040609154040.GA26229@asura.bsd> Message-ID: <20040609135401.V41595@carver.gumbysoft.com> References: <20040609154040.GA26229@asura.bsd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 20:54:43 -0000 On Wed, 9 Jun 2004, Radim Kolar wrote: > 2 - Makes FreeBSD undefined behavior compatible with other operation systems For the record, which operating systems implement the behavior this way? Just to make sure you've done your homework :-) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 22:26:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9905716A4CE for ; Wed, 9 Jun 2004 22:26:49 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D14D43D45 for ; Wed, 9 Jun 2004 22:26:49 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i59MQjVu027140; Wed, 9 Jun 2004 18:26:45 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <200406041933.i54JX9kj040764@mail.gits.dyndns.org> Date: Wed, 9 Jun 2004 18:26:43 -0400 To: "Cyrille Lefevre" , From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 22:26:49 -0000 At 5:34 PM -0400 6/4/04, Garance A Drosihn wrote: >At 10:13 PM +0200 6/3/04, Cyrille Lefevre wrote: >> >>ok, let's try another issue : >> >># ps -G " nobody " >> PID TT STAT TIME COMMAND >>75483 con- S 0:10.97 /usr/local/sbin/junkbuster configfile >># ps -G ,nobody, >>ps: Invalid (zero-length) group name >>ps: Invalid (zero-length) group name >># ps -G , >>ps: Invalid (zero-length) group name >>ps: Invalid (zero-length) group name > > >>why do you make a difference while parsing commas and spaces ? When I first read this, I thought you meant that my latest `ps' was not accepting blanks somewhere that it should have. Now that I read it closer, it seems that you want me to treat a comma the same as a blank. The spec that I am reading from talks about "in the form of a or comma-separated list". To me, that means "a list which is separated by one or more spaces or tabs, or by a comma". Thus, one comma must be a separator between two elements in a list. So, `ps -G ,nobody,' is a list with three elements, two of which are null. Null elements are an error. So, you get two error messages. As I sit here right now, I still think that is the correct and reasonable behavior, so I have no plans to change it. I can see that it could be argued that leading or trailing blanks should also be considered a separator, and should also cause an error. I prefer the present behavior, but I will change that to generate an error if people really think it should be. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 23:37:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DFDB16A4CE; Wed, 9 Jun 2004 23:37:13 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80DC043D45; Wed, 9 Jun 2004 23:37:13 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 46866881B; Wed, 9 Jun 2004 16:37:00 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Wed, 9 Jun 2004 16:37:00 -0700 User-Agent: KMail/1.6.1 References: <55790.1086796559@critter.freebsd.dk> In-Reply-To: <55790.1086796559@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406091637.00032.peter@wemm.org> cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 23:37:13 -0000 On Wednesday 09 June 2004 08:55 am, Poul-Henning Kamp wrote: > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: > >The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > >over all the kernel sources (366 files or so). > > Looks like a "yea" so far, so I have a couple of follow-up questions: I had a slight preference for 'kdev_t *' in the kernel, but 'struct cdev *' works for me as well so I've changed my mind. No objection from me then. > struct cdev currently has members named si_* because it > used to be called "specinfo", do we want to change that > inconsistency at the same time ? (either by reverting to > the specinfo name or by changing to a cd_ prefix ? Whatever works. > cdevsw->ioctl() takes a caddr_t pointer argument which > really should be a void *, do we want to change that > as well (since it is all the same files we'll have to > change). Yes from me. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed Jun 9 23:37:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DFDB16A4CE; Wed, 9 Jun 2004 23:37:13 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80DC043D45; Wed, 9 Jun 2004 23:37:13 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 46866881B; Wed, 9 Jun 2004 16:37:00 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Wed, 9 Jun 2004 16:37:00 -0700 User-Agent: KMail/1.6.1 References: <55790.1086796559@critter.freebsd.dk> In-Reply-To: <55790.1086796559@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406091637.00032.peter@wemm.org> cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 23:37:13 -0000 On Wednesday 09 June 2004 08:55 am, Poul-Henning Kamp wrote: > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp writes: > >The change proposed is more or less to do: > > s/dev_t/struct cdev */ > > s/udev_t/dev_t/ > >over all the kernel sources (366 files or so). > > Looks like a "yea" so far, so I have a couple of follow-up questions: I had a slight preference for 'kdev_t *' in the kernel, but 'struct cdev *' works for me as well so I've changed my mind. No objection from me then. > struct cdev currently has members named si_* because it > used to be called "specinfo", do we want to change that > inconsistency at the same time ? (either by reverting to > the specinfo name or by changing to a cd_ prefix ? Whatever works. > cdevsw->ioctl() takes a caddr_t pointer argument which > really should be a void *, do we want to change that > as well (since it is all the same files we'll have to > change). Yes from me. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 02:09:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B187416A4CE for ; Thu, 10 Jun 2004 02:09:23 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E40243D39 for ; Thu, 10 Jun 2004 02:09:23 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 9532365219; Thu, 10 Jun 2004 03:09:22 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04668-02; Thu, 10 Jun 2004 03:09:22 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E20A365213; Thu, 10 Jun 2004 03:09:21 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id B7D50610F; Thu, 10 Jun 2004 03:09:19 +0100 (BST) Date: Thu, 10 Jun 2004 03:09:18 +0100 From: Bruce M Simpson To: Poul-Henning Kamp Message-ID: <20040610020918.GF4623@empiric.dek.spc.org> References: <53993.1086779790@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53993.1086779790@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 02:09:23 -0000 On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote: > Personally I don't think there is much need for a long discussion > and I would prefer to see simply a show of hands for yes and no, > and any hear any really heavy duty arguments pro et contra. I'd say yes. I find the names device_t and dev_t overly confusing in the kernel; one refers to NEWBUS, the other to cdev. Going to an explicit structure pointer I would find less confusing. I also find the use of the same type name differently in kernel and userland confusing. Regards BMS From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 02:14:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8451F16A4D0 for ; Thu, 10 Jun 2004 02:14:04 +0000 (GMT) Received: from VARK.homeunix.com (ar59.lsanca2-4.27.98.47.lsanca2.dsl-verizon.net [4.27.98.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4795243D2D for ; Thu, 10 Jun 2004 02:14:04 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i5A2DuiT005997 for ; Wed, 9 Jun 2004 19:13:56 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i5A2DuDD005996 for freebsd-arch@freebsd.org; Wed, 9 Jun 2004 19:13:56 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 9 Jun 2004 19:13:56 -0700 From: David Schultz To: freebsd-arch@FreeBSD.ORG Message-ID: <20040610021356.GA4990@VARK.homeunix.com> Mail-Followup-To: freebsd-arch@freebsd.org References: <20040609154040.GA26229@asura.bsd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040609154040.GA26229@asura.bsd> Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 02:14:04 -0000 On Wed, Jun 09, 2004, Radim Kolar wrote: > I have submitted pr http://www.freebsd.org/cgi/query-pr.cgi?pr=65402 with patch > which makes fflush() on read only descriptors do not return error code. > > Reasons for this patch: > 1 - Do not breaks ISO C standard > 2 - Makes FreeBSD undefined behavior compatible with other operation systems > 3 - Correct some programs depending on this Are there any such programs? > 4 - Makes fflush() and fsync() behavior identical - avoids programmer's confusion. > 5 - If there are no data to flush() then flush operation (dummy) succeeds, not failed. > > Against this patch: > Programs which rely upon fflush() not returning an error > when passed a file which is opened read-only are broken, > and should be fixed. > > Colin Percival I don't see how that's an argument against it. Programs that call fflush() on a read-only stream are broken either way. > Are there any other reasons for non commiting it? I think that in this case > pro > cons. Well, I think all those other operating systems (Solaris, HP-UX, Linux, etc.) are wrong in this case, but it would probably behoove us to conform to the /de facto/ standard. From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 02:53:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA65316A4CE for ; Thu, 10 Jun 2004 02:53:13 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0053043D31 for ; Thu, 10 Jun 2004 02:53:13 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.216.230) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA0038665D for freebsd-arch@freebsd.org; Thu, 10 Jun 2004 12:53:12 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id CAEF341F4; Thu, 10 Jun 2004 12:54:39 +1000 (EST) Date: Thu, 10 Jun 2004 12:54:39 +1000 From: Tim Robbins To: freebsd-arch@freebsd.org Message-ID: <20040610025439.GA11655@cat.robbins.dropbear.id.au> References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610021356.GA4990@VARK.homeunix.com> User-Agent: Mutt/1.4.1i Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 02:53:13 -0000 On Wed, Jun 09, 2004 at 07:13:56PM -0700, David Schultz wrote: > On Wed, Jun 09, 2004, Radim Kolar wrote: > > I have submitted pr http://www.freebsd.org/cgi/query-pr.cgi?pr=65402 with patch > > which makes fflush() on read only descriptors do not return error code. > > > > Reasons for this patch: > > 1 - Do not breaks ISO C standard > > 2 - Makes FreeBSD undefined behavior compatible with other operation systems > > 3 - Correct some programs depending on this > > Are there any such programs? > > > 4 - Makes fflush() and fsync() behavior identical - avoids programmer's confusion. > > 5 - If there are no data to flush() then flush operation (dummy) succeeds, not failed. > > > > Against this patch: > > Programs which rely upon fflush() not returning an error > > when passed a file which is opened read-only are broken, > > and should be fixed. > > > > Colin Percival > > I don't see how that's an argument against it. Programs that call > fflush() on a read-only stream are broken either way. > > > Are there any other reasons for non commiting it? I think that in this case > > pro > cons. > > Well, I think all those other operating systems (Solaris, HP-UX, > Linux, etc.) are wrong in this case, but it would probably behoove > us to conform to the /de facto/ standard. This patch has already been discussed, and I thought it was pretty obvious that it had been rejected. The behaviour of fflush() on a read-only stream is not defined by any relevant standards, and there is no consensus on what it should do. It is a no-op on 7th edition UNIX (this may have just been to simplify implementing the other functions; rewind() calls fflush() regardless of mode.) It discards unread buffered data (like fpurge()) in the Microsoft C library. I think other MS-DOS and Windows libraries behaved similarly to Microsoft's. In my experience, fflush() is only called on input streams when the Microsoft behaviour is expected. Some people are taught to write C like this: int j; scanf("%d", &j); fflush(stdin); /* ... more scanf() calls ... */ ... which is wrong, and silently does something other than what the programmer expected on many systems. Bottom line: learn C, fix your code. Tim From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 06:32:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B4A816A4CE; Thu, 10 Jun 2004 06:32:45 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56CE543D2F; Thu, 10 Jun 2004 06:32:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i5A6Wf5v019804; Thu, 10 Jun 2004 16:32:41 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i5A6Wb2O005887; Thu, 10 Jun 2004 16:32:39 +1000 Date: Thu, 10 Jun 2004 16:32:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Wemm In-Reply-To: <200406091637.00032.peter@wemm.org> Message-ID: <20040610161500.G7696@gamplex.bde.org> References: <55790.1086796559@critter.freebsd.dk> <200406091637.00032.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Poul-Henning Kamp cc: freebsd-arch@FreeBSD.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 06:32:45 -0000 On Wed, 9 Jun 2004, Peter Wemm wrote: > On Wednesday 09 June 2004 08:55 am, Poul-Henning Kamp wrote: > > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp > writes: > > >The change proposed is more or less to do: > > > s/dev_t/struct cdev */ > > > s/udev_t/dev_t/ > > >over all the kernel sources (366 files or so). > > > > Looks like a "yea" so far, so I have a couple of follow-up questions: > > I had a slight preference for 'kdev_t *' in the kernel, but 'struct cdev > *' works for me as well so I've changed my mind. No objection from me > then. This would be a large style bug (more of a design error, but not doing it is documented in style(9)): %%% STYLE(9) FreeBSD Kernel Developer's Manual STYLE(9) NAME style -- kernel source file style guide ... Avoid using typedefs for structure types. Typedefs are problematic because they do not properly hide their underlying type; for example you need to know if the typedef is the structure itself or a pointer to the structure. In addition they must be declared exactly once, whereas an incomplete structure type can be mentioned as many times as necessary. Typedefs are difficult to use in stand-alone header files: the header that defines the typedef must be included before the header that uses it, or by the header that uses it (which causes namespace pollution), or there must be a back-door mechanism for obtaining the typedef. %%% Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 06:32:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B4A816A4CE; Thu, 10 Jun 2004 06:32:45 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56CE543D2F; Thu, 10 Jun 2004 06:32:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i5A6Wf5v019804; Thu, 10 Jun 2004 16:32:41 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i5A6Wb2O005887; Thu, 10 Jun 2004 16:32:39 +1000 Date: Thu, 10 Jun 2004 16:32:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Wemm In-Reply-To: <200406091637.00032.peter@wemm.org> Message-ID: <20040610161500.G7696@gamplex.bde.org> References: <55790.1086796559@critter.freebsd.dk> <200406091637.00032.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Poul-Henning Kamp cc: freebsd-arch@FreeBSD.org Subject: Re: dev_t / udev_t confusion ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 06:32:45 -0000 On Wed, 9 Jun 2004, Peter Wemm wrote: > On Wednesday 09 June 2004 08:55 am, Poul-Henning Kamp wrote: > > In message <53993.1086779790@critter.freebsd.dk>, Poul-Henning Kamp > writes: > > >The change proposed is more or less to do: > > > s/dev_t/struct cdev */ > > > s/udev_t/dev_t/ > > >over all the kernel sources (366 files or so). > > > > Looks like a "yea" so far, so I have a couple of follow-up questions: > > I had a slight preference for 'kdev_t *' in the kernel, but 'struct cdev > *' works for me as well so I've changed my mind. No objection from me > then. This would be a large style bug (more of a design error, but not doing it is documented in style(9)): %%% STYLE(9) FreeBSD Kernel Developer's Manual STYLE(9) NAME style -- kernel source file style guide ... Avoid using typedefs for structure types. Typedefs are problematic because they do not properly hide their underlying type; for example you need to know if the typedef is the structure itself or a pointer to the structure. In addition they must be declared exactly once, whereas an incomplete structure type can be mentioned as many times as necessary. Typedefs are difficult to use in stand-alone header files: the header that defines the typedef must be included before the header that uses it, or by the header that uses it (which causes namespace pollution), or there must be a back-door mechanism for obtaining the typedef. %%% Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 12:52:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E13C516A4CE for ; Thu, 10 Jun 2004 12:52:00 +0000 (GMT) Received: from hourri.hittite.isp.9tel.net (hourri.hittite.isp.9tel.net [62.62.156.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4411243D1F for ; Thu, 10 Jun 2004 12:52:00 +0000 (GMT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [84.97.138.178]) by hourri.hittite.isp.9tel.net (Postfix) with SMTP id 07C55157636; Thu, 10 Jun 2004 15:33:37 +0200 (CEST) Message-ID: <03a601c44ee9$92fa4c00$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: , "Garance A Drosihn" References: <05a201c44c82$d94fc680$7890a8c0@dyndns.org> Date: Thu, 10 Jun 2004 14:50:55 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: ps enhencements (posix syntax, and more) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 12:52:01 -0000 "Garance A Drosihn" wrote: > At 2:31 AM +0200 6/7/04, Cyrille Lefevre wrote: > >Garance A Drosihn wrote: > >>At 12:03 PM +0200 4/27/04, Cyrille Lefevre wrote: > >>>here is a description of the last PR#64803 updates : > >> > >>The latest info I see in PR #65803 does not match some > >>things that you describe in the rest of this message. > >>The following comments are based on what I have looked > >>at in the updates in the PR. I have not had much sleep, > >>so this message may be a little confusing in parts. > >> > >>>*** the kernel part has been reworked and validated in > >>> the last patch set. ...OpenBSD -k ... > >> > >>I haven't looked at what you have for -k, but I did try > >>what you had for KERN_PROC_SESSION and it didn't seem to > > >work. > > Please do not take my private messages and reply to them in > public. If I thought we had to hash out every little detail > in public, I would have sent my messages to the mailing list... sorry, I though it was an error to not replying to all. > > > I probably should, but I fear that before I have the > > > time to read & understand & test & install those > > > updates, you will just have rewritten them all over > > > again. This is a bit frustrating... > > > >I didn't understand why you want to reinvent the wheel ? > > There is a key point that you are overlooking. I was already > working on my own large updates to `ps' before you sent any > messages to any mailing lists. I was discussing those publicly > on the mailing lists. The major changes that I committed in > April was just the "safe part" of the larger work I was doing. > It was the parts of my larger change that I felt were safe to > MFC into 4.x-stable. At the time I was pushing those in to > 5.x-current so I could have them adequately tested in time > to MFC them before 4.10-release shipped. I did manage to do > that. I then hit end-of-semester here at RPI, at which point > I have zero free time. None. > > The remaining changes were things that I doubt I will ever > MFC (just because there are too many differences between `ps' > in 4.x vs 5.x). Right near the end of the public testing > of that first set of changes, you showed up with your update, > wishing that someone would pick up the update. You were > probably not on the mailing list where my earlier discussion > had been going on (freebsd-standards), so you missed that I > was already working on `ps'. > > I am not "reinventing the wheel" after you wrote your update. > I am not doing that any more (or any less) than you were. We > just both happened to start working on this at about the same > time. Things like this just happen from time-to-time... ok, I did not understand you already does some work which conflict w/ my work. It was not really clear you already had done most your work. I understand you had implemented some work and though about some other work and you that you want to implement them your way. well, it's not exactly what I want to say, but a sort of. > I am continuing with updates I was already working on before > you presented your huge update. You were quite enthusiastic > about your changes, so initially I put my work on hold and > asked you various issues I saw in your updates. I sent multiple > messages. I got no answers. After a few weeks of waiting, I as said before, it was too bad I didn't receive all your messages which probably point the fact that the PR was missing some pieces. right now, I'll check that when I sent something, it reach its destination. > finally had some free time again so I decided to go back to the > work I was already doing. I did that because I tried various > parts of your update and THEY DID NOT WORK. Thus, it is much > *LESS* work for me to continue with the updates that I already > understood (because I am writing them...), than to figure out > what all 4,000 lines of your update was doing, and all the > side-effects of that update. hope that you'll be happy w/ the last all in one patches I sent. PS : I had to sent two times the userlang part ! I still didn't understand why some of my emails goes to the limbs :( > My updates do not address everything that your massive update > addresses, but then your massive update does not cover some > of the things I have in the pipelines. No matter how we slice > it, it will take work to combine the two streams. If I am the > one doing the commits, then I need to understand the code I am > committing. The biggest mistakes I have made have happened > when I committed someone else's update because "it looks OK", > without really understanding what it did. I do not intend to > make that mistake again. It will take me a fair amount of > time to understand all that is done by your update -- and I am > not going to commit any of it until I am sure that I understand > it. If my name is on the commit, then I will be the person > responsible for it. ok, take your time :) if you need some explaination, don't hesitate to ask me. > I am still interested in looking over your changes, so I will > check the PR. Right now I am actually focused on newsyslog, > but I'll look at these when I get back to looking at `ps'. so, we where not on the same wavelength and please accept my apologies regarding my comments. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 15:59:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0087916A4CE for ; Thu, 10 Jun 2004 15:59:49 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 987DE43D4C for ; Thu, 10 Jun 2004 15:59:48 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i5AFxhVu026796; Thu, 10 Jun 2004 11:59:43 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <03a601c44ee9$92fa4c00$7890a8c0@dyndns.org> References: <05a201c44c82$d94fc680$7890a8c0@dyndns.org> <03a601c44ee9$92fa4c00$7890a8c0@dyndns.org> Date: Thu, 10 Jun 2004 11:59:42 -0400 To: "Cyrille Lefevre" , From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: ps enhencements (posix syntax, and more) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 15:59:49 -0000 At 2:50 PM +0200 6/10/04, Cyrille Lefevre wrote: >"Garance A Drosihn" wrote: > > >> Please do not take my private messages and reply to them in >> public. If I thought we had to hash out every little detail >> in public, I would have sent my messages to the mailing list... > >sorry, I though it was an error to not replying to all. Hmm. I was pretty sure that the message you replied to was a message that I sent only to you, but maybe I sent it to the list. If so, my apologies. It is certainly reasonable to do a "reply to all". -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Jun 11 20:15:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A072A16A4D0 for ; Fri, 11 Jun 2004 20:15:25 +0000 (GMT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F1A243D5C for ; Fri, 11 Jun 2004 20:15:25 +0000 (GMT) (envelope-from reddevil69@cox.net) Received: from c1l9u0 ([68.99.19.120]) by lakermmtao02.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with SMTP id <20040611201524.OSEE13835.lakermmtao02.cox.net@c1l9u0> for ; Fri, 11 Jun 2004 16:15:24 -0400 Message-ID: <000801c44ff0$e012f2a0$78136344@om.cox.net> From: "reddevil69" To: Date: Fri, 11 Jun 2004 15:15:43 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Platforms X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 20:15:25 -0000 Hello there. I am very tired of all the problems with Windows and am = interested in stabilizing my machine with a better OS. I still want to = play my Windows games, but I'm totally fed up with all the bs I have to = put up with running Windows. My question has to do with platform types, = and which port I need for my rig ( AMD Athalon XP 2400+, Gigabyte = Ga-7VM400M Mobo) . Could someone please tell me, in plain, non-geek = English, which non 64bit platform I need to use that would allow me to = run a stable rig that would still let me play my games? (i.e. FreeBSD, = Lindows, Mandrake, whatever?) Thank you very much for your assistance. From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 14:01:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F6D916A4CE for ; Sat, 12 Jun 2004 14:01:11 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAC1343D41 for ; Sat, 12 Jun 2004 14:01:10 +0000 (GMT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (67-61-118-80.kaptech.net [80.118.61.67]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id 0137617B6CE; Sat, 12 Jun 2004 16:01:38 +0200 (CEST) Message-ID: <038901c45085$a08bde90$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: , "Garance A Drosihn" References: <200406041933.i54JX9kj040764@mail.gits.dyndns.org> Date: Sat, 12 Jun 2004 16:00:32 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 14:01:11 -0000 "Garance A Drosihn" wrote: > At 5:34 PM -0400 6/4/04, Garance A Drosihn wrote: > >At 10:13 PM +0200 6/3/04, Cyrille Lefevre wrote: > >> > >>ok, let's try another issue : > >> > >># ps -G " nobody " > >> PID TT STAT TIME COMMAND > >>75483 con- S 0:10.97 /usr/local/sbin/junkbuster configfile > >># ps -G ,nobody, > >>ps: Invalid (zero-length) group name > >>ps: Invalid (zero-length) group name > >># ps -G , > >>ps: Invalid (zero-length) group name > >>ps: Invalid (zero-length) group name > > > > > >>why do you make a difference while parsing commas and spaces ? > > When I first read this, I thought you meant that my latest `ps' was > not accepting blanks somewhere that it should have. > > Now that I read it closer, it seems that you want me to treat a > comma the same as a blank. The spec that I am reading from talks > about "in the form of a or comma-separated list". To me, > that means "a list which is separated by one or more spaces or > tabs, or by a comma". Thus, one comma must be a separator between > two elements in a list. no, it means by one or more spaces, tabs or commas, not just one or more spaces or tabs, or only one a comma. let's see what other OSes does : $ uname -a HP-UX spe173 B.11.23 U ia64 2124664568 unlimited-user license $ ps -p " 1432 1434 " ps: wrong PID number PID TTY TIME CMD 1432 ? 00:00 nfsd 1434 ? 00:00 nfsd $ ps -p "1432 1434 " PID TTY TIME CMD 1432 ? 00:00 nfsd 1434 ? 00:00 nfsd $ ps -p "1432 1434" PID TTY TIME CMD 1432 ? 00:00 nfsd 1434 ? 00:00 nfsd $ ps -p , # or "" ps: wrong PID number same results using one or more commas in place of one or more spaces. well, HP-UX seems to be broken a lot, sine it doesn't accept a leading space ! $ uname -a OSF1 spe147.testdrive.hp.com V5.1 2650 alpha $ ps -p " 1197 1204 " PID TTY S TIME CMD 1197 ?? I 0:00.16 /usr/dt/bin/dtfile -dir ~ -geometry +700+0 1204 ?? I 0:00.00 /usr/dt/bin/dtfile -dir ~ -geometry +700+0 $ ps -p ",,1197,,1204,," PID TTY S TIME CMD 1197 ?? I 0:00.16 /usr/dt/bin/dtfile -dir ~ -geometry +700+0 1204 ?? I 0:00.00 /usr/dt/bin/dtfile -dir ~ -geometry +700+0 $ ps -p , # or "" (all processes !) well, tru64 seems to be broken here, since -p "" means -e ! $ uname -a SunOS ss20 5.8 Generic_108528-05 sun4m sparc SUNW,SPARCstation-20 $ ps -p " 465 466 " PID TTY TIME CMD 465 ? 0:00 httpd 466 ? 0:00 httpd $ ps -p ",,465,,466,," PID TTY TIME CMD 465 ? 0:00 httpd 466 ? 0:00 httpd $ ps -p , # or "" ps: is an invalid non-numeric argument for -p option (usage string) I have no irix boxes under my hand, but the manual irix page is more clear about what ps does regarding how it handle lists arguments : http://minilien.com/?kL0OU9x9y6 or http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/ps.z&srch=ps "options accept names or lists as arguments. Arguments can be either separated from one another by commas or enclosed in double quotes and separated from one another by commas or spaces." > So, `ps -G ,nobody,' is a list with three elements, two of which > are null. Null elements are an error. So, you get two error > messages. As I sit here right now, I still think that is the > correct and reasonable behavior, so I have no plans to change it. think about not well formed shell script. it isn't necessary to display an error message like this, more important, ps should not stop on such error, al least, it should display process info for non- empty elements. however, it's far better than to believe ,, means 0 :) imagine something like : ps -o pid= ,, | xargs kill > I can see that it could be argued that leading or trailing blanks > should also be considered a separator, and should also cause an > error. I prefer the present behavior, but I will change that to > generate an error if people really think it should be. except HP-UX which isn't homegeneous (warn about a leading space, but don't on a terminating one !), all other OSes ignore leading and terminating spaces or commas, and consider multiple spaces or commas as one w/o unnecessary warnings. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 15:28:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90C0616A4CE for ; Sat, 12 Jun 2004 15:28:47 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F96843D1D for ; Sat, 12 Jun 2004 15:28:47 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i5CFRxVu024551; Sat, 12 Jun 2004 11:28:00 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <038901c45085$a08bde90$7890a8c0@dyndns.org> References: <200406041933.i54JX9kj040764@mail.gits.dyndns.org> <038901c45085$a08bde90$7890a8c0@dyndns.org> Date: Sat, 12 Jun 2004 11:27:58 -0400 To: "Cyrille Lefevre" , From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 15:28:47 -0000 At 4:00 PM +0200 6/12/04, Cyrille Lefevre wrote: > > So, `ps -G ,nobody,' is a list with three elements, two of which >> are null. Null elements are an error. So, you get two error >> messages. As I sit here right now, I still think that is the >> correct and reasonable behavior, so I have no plans to change it. > >think about not well formed shell script. it isn't necessary to >display an error message like this, more important, ps should not >stop on such error, al least, it should display process info for >non- empty elements. however, it's far better than to believe ,, >means 0 :) imagine something like : ps -o pid= ,, | xargs kill If `ps -p ,' is an error instead of process zero (which is a change that I just made after you pointed it out to me), then `ps -p 1,' is also an error. I *am* thinking about shell-scripts which are not well-formed. My thought is that I should not be second-guessing what the script-writer "probably meant". If they can't get the right parameters to `ps', then `ps' should treat that as an error. So, I still have no plans to change this behavior. The behavior that is there is, I believe, both correct and reasonable -- even if other OS's do it some other way. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 19:16:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC0D816A4CE for ; Sat, 12 Jun 2004 19:16:43 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D5B43D31 for ; Sat, 12 Jun 2004 19:16:43 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i5CJFLN0012224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 12 Jun 2004 12:15:21 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i5CJFLoG045384 for freebsd-arch@freebsd.org; Sat, 12 Jun 2004 12:15:21 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 12 Jun 2004 12:15:21 -0700 (PDT) From: John Polstra To: freebsd-arch@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.091382, version=0.14.5 Subject: RFC: API change for sema_timedwait X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 19:16:44 -0000 Before 5.x becomes -stable, I'd like to change the API of sema_timedwait(9). This function is used in only 3 places in the kernel, all in "dev/ips/ips_commands.c". Currently, sema_timedwait returns 0 if the operation fails due to a timeout. On success, it returns a non-zero value. This is precisely the opposite of the standard convention in the kernel, where 0 means success and a non-zero value (taken from ) means failure. The convention exists because most functions can succeed in only one way but can fail in several different ways. The reason I care about this is because I'd like to add new functions sema_wait_sig() and sema_timedwait_sig() which can be interrupted by a signal. Then sema_timedwait_sig could fail in two different ways: as a result of a timeout or as a result of a signal. If these functions returned proper errno values on failure, it would be easy to distinguish between the two failure cases. This change would also make the return values of sema_timedwait, sema_wait_sig, and sema_timedwait_sig consistent with the analogous condition variable operations cv_timedwait, cv_wait_sig, and cv_timedwait_sig and with tsleep and msleep. Does this change sound OK to you folks? John From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 19:32:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59DD816A4CE for ; Sat, 12 Jun 2004 19:32:05 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1378843D4C for ; Sat, 12 Jun 2004 19:32:05 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5CJUeQp094867; Sat, 12 Jun 2004 15:30:40 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5CJUeLc094864; Sat, 12 Jun 2004 15:30:40 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 12 Jun 2004 15:30:40 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: RFC: API change for sema_timedwait X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 19:32:05 -0000 On Sat, 12 Jun 2004, John Polstra wrote: > The reason I care about this is because I'd like to add new functions > sema_wait_sig() and sema_timedwait_sig() which can be interrupted by a > signal. Then sema_timedwait_sig could fail in two different ways: as a > result of a timeout or as a result of a signal. If these functions > returned proper errno values on failure, it would be easy to distinguish > between the two failure cases. > > This change would also make the return values of sema_timedwait, > sema_wait_sig, and sema_timedwait_sig consistent with the analogous > condition variable operations cv_timedwait, cv_wait_sig, and > cv_timedwait_sig and with tsleep and msleep. > > Does this change sound OK to you folks? This sounds entirely sensible to me. Make sure to update the man page :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 19:35:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72E6616A4CE for ; Sat, 12 Jun 2004 19:35:26 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2747443D31 for ; Sat, 12 Jun 2004 19:35:26 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5CJY0YD094932; Sat, 12 Jun 2004 15:34:00 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5CJXuuL094929; Sat, 12 Jun 2004 15:34:00 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 12 Jun 2004 15:33:56 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <57800.1086807537@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Julian Elischer Subject: Re: reference counting.. continued.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 19:35:26 -0000 On Wed, 9 Jun 2004, Poul-Henning Kamp wrote: > I am not in favour of a dedicated API for refcounts. > > A dedicated API works if the refcount is a detached property of the > object, and that is not normally the case outside OO+GC implementations. > > Our reference counts will almost invariably be integral properties of > our objects and therefore has to interact with the remaining object > locking. I don't have a strong feeling about the general need for a refcount API, but I can confirm that many of the interesting objects in the kernel wouldn't lend themselves to such an API. There are many cases where we'll want to protect the reference count using an existing lock, in which case locking built into the reference count API becomes a liability. Socket reference counting is one example of this: in some ways, it's a general purpose reference count, but the GC behavior is specific to sockets and depends on additional uncounted references from file descriptors and the prototocol layer. That said, I think making sure people get reference counts right is important: at the very least, I think it would be useful to have a refcount(9) man page with a well thought out example of a simple reference count implementation, or a pointer at such an implementation (ucred isn't bad). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 19:38:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A0C916A4CE; Sat, 12 Jun 2004 19:38:42 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF0B943D31; Sat, 12 Jun 2004 19:38:41 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i5CJcLml012413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jun 2004 12:38:21 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i5CJcLrj045414; Sat, 12 Jun 2004 12:38:21 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 12 Jun 2004 12:38:21 -0700 (PDT) From: John Polstra To: Robert Watson X-Bogosity: No, tests=bogofilter, spamicity=0.156850, version=0.14.5 cc: freebsd-arch@freebsd.org Subject: Re: RFC: API change for sema_timedwait X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 19:38:42 -0000 On 12-Jun-2004 Robert Watson wrote: > > This sounds entirely sensible to me. Make sure to update the man page >:-). Will do. Speaking of which ... it's _great_ how many man pages there are for the kernel APIs these days! The folks who have created them deserve a lot of gratitude. John From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 20:08:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8702A16A4CE for ; Sat, 12 Jun 2004 20:08:11 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0915E43D39 for ; Sat, 12 Jun 2004 20:08:11 +0000 (GMT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (67-61-118-80.kaptech.net [80.118.61.67]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id 1811118060A; Sat, 12 Jun 2004 18:04:50 +0200 (CEST) Message-ID: <042401c45096$d68f2b80$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: , "Garance A Drosihn" References: <200406041933.i54JX9kj040764@mail.gits.dyndns.org> <038901c45085$a08bde90$7890a8c0@dyndns.org> Date: Sat, 12 Jun 2004 18:03:43 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: Change to "kludge option processing" in /bin/ps X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 20:08:11 -0000 "Garance A Drosihn" wrote: > At 4:00 PM +0200 6/12/04, Cyrille Lefevre wrote: > > > So, `ps -G ,nobody,' is a list with three elements, two of which > >> are null. Null elements are an error. So, you get two error > >> messages. As I sit here right now, I still think that is the > >> correct and reasonable behavior, so I have no plans to change it. > > > >think about not well formed shell script. it isn't necessary to > >display an error message like this, more important, ps should not > >stop on such error, al least, it should display process info for > >non- empty elements. however, it's far better than to believe ,, > >means 0 :) imagine something like : ps -o pid= ,, | xargs kill > > If `ps -p ,' is an error instead of process zero (which is a change > that I just made after you pointed it out to me), then `ps -p 1,' no, the cases are differents, in the first case, you have no process id at all, in the second case, you have one process id. and it seems normal to bail out if you have no process id to list and not normal if there is at least one process id to list. > is also an error. I *am* thinking about shell-scripts which are not > well-formed. My thought is that I should not be second-guessing > what the script-writer "probably meant". If they can't get the > right parameters to `ps', then `ps' should treat that as an error. > > So, I still have no plans to change this behavior. The behavior > that is there is, I believe, both correct and reasonable -- even > if other OS's do it some other way. Cyrille Lefevre. -- mailto:clefevre-lists@9online.fr