From owner-freebsd-arch Mon Nov 4 1:37: 8 2002 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 DFD5937B401 for ; Mon, 4 Nov 2002 01:37:07 -0800 (PST) Received: from apache.metrocom.ru (www.metrocom.ru [195.5.128.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08D2C43E42 for ; Mon, 4 Nov 2002 01:37:06 -0800 (PST) (envelope-from alex@metrocom.ru) Received: from apache.metrocom.ru (localhost [127.0.0.1]) by apache.metrocom.ru (8.12.3/8.12.3) with ESMTP id gA49b4pn017158 for ; Mon, 4 Nov 2002 12:37:04 +0300 (MSK) Received: from localhost (alex@localhost) by apache.metrocom.ru (8.12.3/8.12.3/Submit) with ESMTP id gA49b4Cl017155 for ; Mon, 4 Nov 2002 12:37:04 +0300 (MSK) X-Authentication-Warning: apache.metrocom.ru: alex owned process doing -bs Date: Mon, 4 Nov 2002 12:37:04 +0300 (MSK) From: Varshavchick Alexander To: Subject: D-Link DGE-550T NIC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi people, did anybody use it with FreeBSD 4.5? The problem is that the system doesn't see it, however 'nge' and 'miibus' support are included into the kernel. Is it correct that it must be 'nge', because as described in the man page, only DGE-500T card is supported by nge, however both DGE-550T and DGE-500T use the same DP83820 chip. Or am I missing something here? Thanks ---- Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 5 12:40:22 2002 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 533E837B406 for ; Tue, 5 Nov 2002 12:40:21 -0800 (PST) Received: from smtp.noos.fr (claudel.noos.net [212.198.2.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id C07A543E6E for ; Tue, 5 Nov 2002 12:40:19 -0800 (PST) (envelope-from cyrille.lefevre@laposte.net) Received: (qmail 89324908 invoked by uid 0); 5 Nov 2002 20:40:18 -0000 Received: from unknown (HELO mail.gits.dyndns.org) ([212.198.231.27]) (envelope-sender ) by 212.198.2.83 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Nov 2002 20:40:18 -0000 Received: from gits.gits.fr.invalid (50nkwn4u9n06s4fl@localhost [127.0.0.1]) by mail.gits.dyndns.org (8.12.6/8.12.6) with ESMTP id gA5KeHpB056588 for ; Tue, 5 Nov 2002 21:40:18 +0100 (CET) (envelope-from cyrille.lefevre@laposte.net) Date: Tue, 5 Nov 2002 21:40:13 +0100 To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021105204013.GC56253@gits.dyndns.org> References: <20021027021440.GB58312@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< X-Delivery-Agent: TMDA/0.61 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Oct 27, 2002 at 12:33:41AM -0400, Robert Watson wrote: > > On Sat, 26 Oct 2002, David O'Brien wrote: > > > > (1) All references to lukemftpd as "the ftpd" be corrected to indicate > > > lukemftpd is not the default. Most of these are leaked references > > > from lukemftpd man pages that were not updated in the import. > > > > We typically don't rewrite contrib'ed vendor branch code. On some of my > > systems lukemftp is THE ftpd, so they do apply. > > Just to make it completely clear what I'm talking about here: we do have a > "the ftpd", because we install it as /usr/libexec/ftpd. Lukemftpd is > installed as /usr/libexec/lukemftpd. Documentation should refer to the > binaries and man pages correctly. One specific example of this is > ftpd.conf(5), which incorrectly stats: how about the following PR ? http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/39676 Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 11:37: 2 2002 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 22FDD37B406 for ; Wed, 6 Nov 2002 11:37:00 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id ADF8D43E88 for ; Wed, 6 Nov 2002 11:36:55 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 15328 invoked by uid 1000); 6 Nov 2002 19:36:55 -0000 Date: Wed, 6 Nov 2002 11:36:55 -0800 (PST) From: Nate Lawson To: Jeff Roberson Cc: Poul-Henning Kamp , arch@freebsd.org Subject: malloc(9) performance In-Reply-To: <20021106141427.J1374-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Jeff Roberson wrote: > On Fri, 1 Nov 2002, Poul-Henning Kamp wrote: > > > phk 2002/11/01 10:58:13 PST > > > > Modified files: > > sys/sys malloc.h > > sys/kern kern_malloc.c > > Log: > > Introduce malloc_last_fail() which returns the number of seconds since > > malloc(9) failed last time. This is intended to help code adjust > > memory usage to the current circumstances. > > > > A typical use could be: > > if (malloc_last_fail() < 60) > > reduce_cache_by_one(); > > > > Revision Changes Path > > 1.113 +16 -0 src/sys/kern/kern_malloc.c > > 1.68 +1 -0 src/sys/sys/malloc.h > > > > I would like to add a 'flush' callback to uma. So each zone could get a > callback when the system is low on memory and it could reduce it's memory > footprint. This would be very effective for something like the vnode > cache or the directory cache, etc. > > What do you think of this? It would be trivial to add. > > Cheers, > Jeff Yes, I think this would be useful but also, if appropriate, portions of the kernel that traditionally used their own freelists should go back to just malloc/free if the new malloc is fast enough(*) for their use. Not trying to hijack the conversation so please keep it on track, but this brought up a question I never heard answered. The new malloc(9) is supposed to be quick enough(*) that drivers should stop using their own freelists. Does anyone have performance numbers on this? I want to check latency for small and big allocations. I am specifying my own malloc type so I assume malloc(9) will chain recently-used objects before coalescing. Followups to arch@ -Nate (*) For me, fast enough means sustaining 100000 small (400 byte) and big (64k) allocations/frees per second (one every 10 us). Maximum memory in use at any point in time would be a few MB. Latency is my main concern and memory fragmentation much less so. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 13: 5:55 2002 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 6386537B401; Wed, 6 Nov 2002 13:05:54 -0800 (PST) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id F32E543E42; Wed, 6 Nov 2002 13:05:53 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0355.cvx40-bradley.dialup.earthlink.net ([216.244.43.100] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 189XMy-0001S5-00; Wed, 06 Nov 2002 13:05:49 -0800 Message-ID: <3DC983D9.B94F1474@mindspring.com> Date: Wed, 06 Nov 2002 13:04:25 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Lawson Cc: Jeff Roberson , Poul-Henning Kamp , arch@freebsd.org Subject: Re: malloc(9) performance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Lawson wrote: > (*) For me, fast enough means sustaining 100000 small (400 byte) and big > (64k) allocations/frees per second (one every 10 us). Maximum memory in > use at any point in time would be a few MB. Latency is my main concern > and memory fragmentation much less so. For me, the number is closer to 600,000: theoretically, this should be the combined mbuf and tcpcb connection struct allocation rate, given the maximum possible connection per second rate on a Gigabit ethernet's packets-per-secon throughput. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 13:21:30 2002 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 D852637B401 for ; Wed, 6 Nov 2002 13:21:29 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 14F3743E42 for ; Wed, 6 Nov 2002 13:21:29 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 15878 invoked by uid 1000); 6 Nov 2002 21:21:29 -0000 Date: Wed, 6 Nov 2002 13:21:29 -0800 (PST) From: Nate Lawson To: Terry Lambert Cc: arch@freebsd.org Subject: Re: malloc(9) performance In-Reply-To: <3DC983D9.B94F1474@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Terry Lambert wrote: > Nate Lawson wrote: > > (*) For me, fast enough means sustaining 100000 small (400 byte) and big > > (64k) allocations/frees per second (one every 10 us). Maximum memory in > > use at any point in time would be a few MB. Latency is my main concern > > and memory fragmentation much less so. > > For me, the number is closer to 600,000: theoretically, this should > be the combined mbuf and tcpcb connection struct allocation rate, > given the maximum possible connection per second rate on a Gigabit > ethernet's packets-per-secon throughput. I'm going to get really flamed for this but I did a short test of the userland malloc and found that I get 33000 mallocs/sec when grabbing 64k (and then touching one byte on each page) compared to 1800/s when I add in the small mallocs (one 608 byte, one 400 byte). So I may be sticking with a private freelist for the small allocations and use malloc for the large buf. Of course, profiling and real tests would be much better but I just need to make a quick decision for now. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 13:40:21 2002 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 D866B37B401 for ; Wed, 6 Nov 2002 13:40:19 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15E3343E3B for ; Wed, 6 Nov 2002 13:40:19 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id gA6LeAT86865; Wed, 6 Nov 2002 16:40:10 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 6 Nov 2002 16:40:10 -0500 (EST) From: Jeff Roberson To: Nate Lawson Cc: Terry Lambert , Subject: Re: malloc(9) performance In-Reply-To: Message-ID: <20021106163703.X1374-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Nate Lawson wrote: > On Wed, 6 Nov 2002, Terry Lambert wrote: > > Nate Lawson wrote: > > > (*) For me, fast enough means sustaining 100000 small (400 byte) and big > > > (64k) allocations/frees per second (one every 10 us). Maximum memory in > > > use at any point in time would be a few MB. Latency is my main concern > > > and memory fragmentation much less so. > > > > For me, the number is closer to 600,000: theoretically, this should > > be the combined mbuf and tcpcb connection struct allocation rate, > > given the maximum possible connection per second rate on a Gigabit > > ethernet's packets-per-secon throughput. > > I'm going to get really flamed for this but I did a short test of the > userland malloc and found that I get 33000 mallocs/sec when grabbing 64k > (and then touching one byte on each page) compared to 1800/s when I add in > the small mallocs (one 608 byte, one 400 byte). So I may be sticking with > a private freelist for the small allocations and use malloc for the large > buf. Of course, profiling and real tests would be much better but I just > need to make a quick decision for now. > > -Nate > I do not currently have performance numbers for malloc(9). They will not have anything at all to do with the performance of the library malloc. It has to do semi expensive system calls to do its job. I only did system level benchmarks against the old malloc and it did very well. The fast path for malloc is only the overhead of a lock, poping an item off of a stack, and an unlock. It should be quite fast. It would be trivial to write a module that would time malloc and print out some results. Could you try this? If not I can put it on my to do list. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 14:20:15 2002 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 3B44537B406; Wed, 6 Nov 2002 14:20:13 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6857B43E3B; Wed, 6 Nov 2002 14:20:12 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA01204; Wed, 6 Nov 2002 14:04:58 -0800 (PST) Date: Wed, 6 Nov 2002 14:04:56 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Cc: "Long, Scott" , re@freebsd.org, Murray Stokely Subject: Bluetooth code In-Reply-To: <20021106013455.F51538@freebsdmall.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Murray Stokely wrote: > Thanks also for taking the time to work with the submitter and get > this integrated. Please be more patient in the future, though. In > addition to talking over the technical issues and sorting out the best > place to do the import, please think about what needs to be > documented, who is going to document it, etc. The commit includes quite a few man pages. > > To move forward on this, can you post a message to arch@ about your > intentions, hardware this has been tested with, and a link to the > latest snapshot? The submitter's earlier posts to net@ didn't seem to > get much response (except from you), and so a targeted call for > review from arch@ is needed. In the mean time, re@ can try to figure > out where we stand with DP2, and when we should import this. Several people have tested it on a variety of devices.. I have asked them to send me exact info. In the meanwhile we need more testers and as I see it, the best way to do this is to make the code easily available to users. The code is completely self contained so can not break anything. Especially as it is not compiled by default. You need to cgo compile it specially and then load the modules before you face any danger and even then it seem sto work.... The current patch is at: http://www.geocities.com/m_evmenkin/ngbt-commit-2002-11-05.tar.gz Though some slight Makefile changes will happen by the time of a commit. Specifically, the Makefiles for the modules are in sys/netgraph/bluetooth at the moment but will be in /modules/netgraph/bluetooth at commit and the man pages are also presently in the source but would be committed in the correct place. These, and the Makefiles are currently where they are to allow testers to unpack test, and delete everything in one place, and I don't consider changing their location as being relevent for a discussion of whether to commit. I'm impressed by the completeness of the code and the fact that documentation is included. I'd like to see it committed before DP2 so that others can try it. This would be needed before we can claim that 5.0 has bluetooth support, which would be nice for the specs. The driver for the 3com card would not be immediatly committed as we are still in discussion with 3com regarding the ability to distribute a binary of the firmware with the driver. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 14:34: 8 2002 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 E6F8C37B401 for ; Wed, 6 Nov 2002 14:34:06 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9FB0C43E42 for ; Wed, 6 Nov 2002 14:34:06 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 16208 invoked by uid 1000); 6 Nov 2002 22:34:07 -0000 Date: Wed, 6 Nov 2002 14:34:07 -0800 (PST) From: Nate Lawson To: Jeff Roberson Cc: arch@FreeBSD.ORG Subject: Re: malloc(9) performance In-Reply-To: <20021106163703.X1374-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Jeff Roberson wrote: > On Wed, 6 Nov 2002, Nate Lawson wrote: > > > On Wed, 6 Nov 2002, Terry Lambert wrote: > > > Nate Lawson wrote: > > > > (*) For me, fast enough means sustaining 100000 small (400 byte) and big > > > > (64k) allocations/frees per second (one every 10 us). Maximum memory in > > > > use at any point in time would be a few MB. Latency is my main concern > > > > and memory fragmentation much less so. > > > > > > For me, the number is closer to 600,000: theoretically, this should > > > be the combined mbuf and tcpcb connection struct allocation rate, > > > given the maximum possible connection per second rate on a Gigabit > > > ethernet's packets-per-secon throughput. > > > > I'm going to get really flamed for this but I did a short test of the > > userland malloc and found that I get 33000 mallocs/sec when grabbing 64k > > (and then touching one byte on each page) compared to 1800/s when I add in > > the small mallocs (one 608 byte, one 400 byte). So I may be sticking with > > a private freelist for the small allocations and use malloc for the large > > buf. Of course, profiling and real tests would be much better but I just > > need to make a quick decision for now. > > > > -Nate > > I do not currently have performance numbers for malloc(9). They will not > have anything at all to do with the performance of the library malloc. It I understand this. I only posted because I was surprised by the 18x difference between 1 large malloc(3) and that plus two small malloc(3)'s. > has to do semi expensive system calls to do its job. I don't see how the syscall would result in 18x degradation, especially since once the brk() happens, the allocation should just be a list access. But I am not familiar with the internals of either malloc(3) or (9). > I only did system > level benchmarks against the old malloc and it did very well. The fast > path for malloc is only the overhead of a lock, poping an item off of a > stack, and an unlock. It should be quite fast. Agreed. > It would be trivial to write a module that would time malloc and print out > some results. Could you try this? If not I can put it on my to do list. I'll take care of this and then you can point out any degradation in my approach. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 15:15:10 2002 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 6DB8937B401 for ; Wed, 6 Nov 2002 15:15:09 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0EC543E42 for ; Wed, 6 Nov 2002 15:15:08 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA6NF80N003806 for ; Wed, 6 Nov 2002 15:15:08 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA6NFIvY001597 for ; Wed, 6 Nov 2002 15:15:18 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gA6NFI0A001596 for arch@FreeBSD.org; Wed, 6 Nov 2002 15:15:18 -0800 (PST) Date: Wed, 6 Nov 2002 15:15:18 -0800 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: Suggestion: modules: ARCHS variable in makefiles Message-ID: <20021106231518.GA1505@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gang, Johns sweep over the drivers to clean up some warnings triggered a thought in me. But enough about that, what about the following: :-) The way we define SUBDIR in src/sys/modules/Makefile has annoyed me enough that I'm willing to spend a not-completely-unlimited time to handle it roughly the same as we do for ports: The makefile for a module lists the architectures it's supposed to work on and is simply skipped if the current (target) architecture is not in the list. The top-level modules Makefile simply lists *all* modules, possibly adjusted by some unrelated knob (such as WANT_EXT2FS_MODULE or NO_IPFILTER). Pros: 1. sys/modules/Makefile will be much cleaner with less duplication. 2. Modules can more easily be build in alphabetical order (ie without making the makefile unreadable). 3. More control for the module specific makefile (localized history). 4. Less tweaking in the top-level makefile when new architectures are being introduced. Cons: 1. Build-time overhead to recurse all modules, including the ones that aren't being built. 2. More work to enable true MI modules (assuming opt-in only) Q: Do people think it's a good approach (ie worth to spend time on)? Q: Is this something that may benefit 5.0-RELEASE or is it something that can better wait (ie spend time now on)? Just a thought, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 15:46:29 2002 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 9211137B401 for ; Wed, 6 Nov 2002 15:46:28 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57FD243E4A for ; Wed, 6 Nov 2002 15:46:28 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 34234AE2C5; Wed, 6 Nov 2002 15:46:28 -0800 (PST) Date: Wed, 6 Nov 2002 15:46:28 -0800 From: Alfred Perlstein To: Marcel Moolenaar Cc: arch@FreeBSD.org Subject: Re: Suggestion: modules: ARCHS variable in makefiles Message-ID: <20021106234628.GH24139@elvis.mu.org> References: <20021106231518.GA1505@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021106231518.GA1505@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Marcel Moolenaar [021106 15:15] wrote: > Gang, > > Johns sweep over the drivers to clean up some warnings triggered a > thought in me. But enough about that, what about the following: :-) > > The way we define SUBDIR in src/sys/modules/Makefile has annoyed me > enough that I'm willing to spend a not-completely-unlimited time > to handle it roughly the same as we do for ports: The makefile for > a module lists the architectures it's supposed to work on and is > simply skipped if the current (target) architecture is not in the > list. The top-level modules Makefile simply lists *all* modules, > possibly adjusted by some unrelated knob (such as WANT_EXT2FS_MODULE > or NO_IPFILTER). This sounds interesting, how about a default rule though that without the ARCH line the module will build on all arches, have an include and exclude option. #MODULE_ARCHES= ${ALL_ARCH} # implicit. MODULE_NOARCHS= alpha # build on all but alpha. MODULE_ARCHS= i386 alpha pc98 # only build on i386, alpha and pc98. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 17: 0:12 2002 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 7870737B401; Wed, 6 Nov 2002 17:00:11 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id D78FC43E77; Wed, 6 Nov 2002 17:00:10 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA02033; Wed, 6 Nov 2002 16:58:30 -0800 (PST) Date: Wed, 6 Nov 2002 16:58:29 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Cc: "Long, Scott" , re@freebsd.org, Murray Stokely Subject: Re: Bluetooth code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Julian Elischer wrote: > > > On Wed, 6 Nov 2002, Murray Stokely wrote: > > Several people have tested it on a variety of devices.. > I have asked them to send me exact info. 4 card or dongles that have been used.. TDK TDK Bluetooth USB Adapter, rev 1.10/1.34, addr 2 3Com product 0x00a0, rev 1.10/1.15, addr 3 (3CREB96) "3COM" "3CRWB60-A" "Bluetooth PC Card" Epox-BT-DG02 vendor 0x0a12 product 0x0001, rev 1.10/2.72, addr 2 Mitsumi product 0x641f, rev 1.10/1.14, addr 2 (MITSUMI-USB-dongle) MSI-MS-6967 vendor 0x0db0 product 0x1967, rev 1.10/3.73, addr 2 however I don't know the full story on these devices. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 18:56:38 2002 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 A440737B401 for ; Wed, 6 Nov 2002 18:56:36 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71CDF43E6E for ; Wed, 6 Nov 2002 18:56:31 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA72uJ0N004321; Wed, 6 Nov 2002 18:56:22 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA72uTvY002119; Wed, 6 Nov 2002 18:56:29 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gA72uGtb002118; Wed, 6 Nov 2002 18:56:16 -0800 (PST) Date: Wed, 6 Nov 2002 18:56:16 -0800 From: Marcel Moolenaar To: Alfred Perlstein Cc: arch@FreeBSD.org Subject: Re: Suggestion: modules: ARCHS variable in makefiles Message-ID: <20021107025616.GB2005@dhcp01.pn.xcllnt.net> References: <20021106231518.GA1505@dhcp01.pn.xcllnt.net> <20021106234628.GH24139@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021106234628.GH24139@elvis.mu.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Nov 06, 2002 at 03:46:28PM -0800, Alfred Perlstein wrote: > > This sounds interesting, how about a default rule though that without > the ARCH line the module will build on all arches, have an include > and exclude option. Agreed. It addresses con#2. > #MODULE_ARCHES= ${ALL_ARCH} # implicit. > MODULE_NOARCHS= alpha # build on all but alpha. > MODULE_ARCHS= i386 alpha pc98 # only build on i386, alpha and pc98. Do you think there's value to allow specifying MACHINE_ARCH and MACHINE. So that one can say (different naming introduced only for clarity): MACHINE_EXCLUDE=i386 # Does not build on i386 machine, but does # build on pc98. MACHINE_ARCH_EXCLUDE=i386 # Does not build on any i386 based archs, # including pc98. Or likewise: MACHINE_INCLUDE=i386 # Builds for i386; not pc98 MACHINE_ARCH_INCLUDE=i386 # Builds on all i386 based archs. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 6 21:53:36 2002 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 C468E37B401 for ; Wed, 6 Nov 2002 21:53:35 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id C421743E3B for ; Wed, 6 Nov 2002 21:53:34 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gA75rVC4064636; Wed, 6 Nov 2002 21:53:32 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gA75rVRt064635; Wed, 6 Nov 2002 21:53:31 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 6 Nov 2002 21:53:31 -0800 From: David Schultz To: Nate Lawson Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: malloc(9) performance Message-ID: <20021107055331.GA63812@HAL9000.homeunix.com> Mail-Followup-To: Nate Lawson , Jeff Roberson , arch@FreeBSD.ORG References: <20021106163703.X1374-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Nate Lawson : > I understand this. I only posted because I was surprised by the 18x > difference between 1 large malloc(3) and that plus two small malloc(3)'s. > > > has to do semi expensive system calls to do its job. > > I don't see how the syscall would result in 18x degradation, especially > since once the brk() happens, the allocation should just be a list > access. But I am not familiar with the internals of either malloc(3) or > (9). When you make a single small allocation with malloc(3), you're effectively making a page allocation and then fiddling with a bitmap of free space within that page, so it takes longer than allocating full pages. The effort required is inversely proportional to the size of the allocation for sub-pagesize allocations. The routine could be micro-optimized, e.g. by replacing 'while (i >>= 1) j++;' with 'ffs(i & i-1);' and by adding a hint to speed up searching of the bitmap, but I'm skeptical that these tweaks would be worthwhile. I don't know anything about malloc(9), but I suspect it is orthogonal. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 6:37:23 2002 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 A5A5C37B401 for ; Thu, 7 Nov 2002 06:37:21 -0800 (PST) Received: from web11201.mail.yahoo.com (web11201.mail.yahoo.com [216.136.131.171]) by mx1.FreeBSD.org (Postfix) with SMTP id 54A0143E6E for ; Thu, 7 Nov 2002 06:37:21 -0800 (PST) (envelope-from gathorpe79@yahoo.com) Message-ID: <20021107143721.74192.qmail@web11201.mail.yahoo.com> Received: from [24.114.70.137] by web11201.mail.yahoo.com via HTTP; Thu, 07 Nov 2002 09:37:21 EST Date: Thu, 7 Nov 2002 09:37:21 -0500 (EST) From: Gary Thorpe Subject: Re: malloc(9) performance To: David Schultz Cc: freebsd-arch@freebsd.org In-Reply-To: <20021107055331.GA63812@HAL9000.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- David Schultz wrote: > Thus spake Nate Lawson : > > I understand this. I only posted because I was surprised by the > 18x > > difference between 1 large malloc(3) and that plus two small > malloc(3)'s. > > > > > has to do semi expensive system calls to do its job. > > > > I don't see how the syscall would result in 18x degradation, > especially > > since once the brk() happens, the allocation should just be a list > > access. But I am not familiar with the internals of either > malloc(3) or > > (9). > > When you make a single small allocation with malloc(3), you're > effectively making a page allocation and then fiddling with a > bitmap of free space within that page, so it takes longer than > allocating full pages. The effort required is inversely > proportional to the size of the allocation for sub-pagesize > allocations. The routine could be micro-optimized, e.g. by > replacing 'while (i >>= 1) j++;' with 'ffs(i & i-1);' and by > adding a hint to speed up searching of the bitmap, but I'm > skeptical that these tweaks would be worthwhile. I don't know > anything about malloc(9), but I suspect it is orthogonal. Shouldn't page allocations be minimized to the situation where there is not enough memory in partially free pages to satisfy the request? If this is the case, then the first small malloc() would have to allocate a page and set up bitmaps, but subsequent malloc()'s would only have to manipulate the bitmap as long as they can hold in the same page (slower than page-aligned malloc()'s when a new page is needed but it should be otherwise faster). Since the kernel also does internal management of its address space, would the same logic apply? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 11: 0:22 2002 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 3AED437B401 for ; Thu, 7 Nov 2002 11:00:21 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6FD843E4A for ; Thu, 7 Nov 2002 11:00:19 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA7J0Gpk023107 for ; Thu, 7 Nov 2002 12:00:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Nov 2002 11:59:36 -0700 (MST) Message-Id: <20021107.115936.40770874.imp@bsdimp.com> To: arch@freebsd.org Subject: Simple patch to make __sF suck less on -stable From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG http://people.freebsd.org/~imp/sf-patch This causes stable to generate __std{in,out,err}p references in preference to __sF. If you rebuild with this patch, then you'll not have __sF references in your libraries. This will allow new us to share 4.x and 5.x libraries w/o the need for a gnarly version bump of everything, provided we don't change the sizeof FILE in a released version before 6.0. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 11: 6:11 2002 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 9A1F837B401 for ; Thu, 7 Nov 2002 11:06:10 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BE0643E42 for ; Thu, 7 Nov 2002 11:06:10 -0800 (PST) (envelope-from bmah@employees.org) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021107190609.DCLA12281.rwcrmhc52.attbi.com@bmah.dyndns.org>; Thu, 7 Nov 2002 19:06:09 +0000 Received: from intruder.bmah.org (localhost [IPv6:::1]) by bmah.dyndns.org (8.12.6/8.12.6) with ESMTP id gA7J68u5043605; Thu, 7 Nov 2002 11:06:08 -0800 (PST) (envelope-from bmah@intruder.bmah.org) Received: (from bmah@localhost) by intruder.bmah.org (8.12.6/8.12.6/Submit) id gA7J688E043599; Thu, 7 Nov 2002 11:06:08 -0800 (PST) Message-Id: <200211071906.gA7J688E043599@intruder.bmah.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: arch@FreeBSD.ORG Subject: Re: Simple patch to make __sF suck less on -stable In-Reply-To: <20021107.115936.40770874.imp@bsdimp.com> References: <20021107.115936.40770874.imp@bsdimp.com> Comments: In-reply-to "M. Warner Losh" message dated "Thu, 07 Nov 2002 11:59:36 -0700." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_770759342P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 2002 11:06:08 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --==_Exmh_770759342P Content-Type: text/plain; charset=us-ascii If memory serves me right, "M. Warner Losh" wrote: > http://people.freebsd.org/~imp/sf-patch That didn't look like a patch to me...did I miss something? Bruce. --==_Exmh_770759342P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) Comment: Exmh version 2.5+ 20020506 iD8DBQE9yrmf2MoxcVugUsMRAmxnAJ4jzttum82D3COz2nRsF9dDoU4rqACg4a19 z3mb/pOcsImt9ZgxrJFpCyI= =sx2g -----END PGP SIGNATURE----- --==_Exmh_770759342P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 12: 2:51 2002 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 889B737B401 for ; Thu, 7 Nov 2002 12:02:50 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CCE443E77 for ; Thu, 7 Nov 2002 12:02:50 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 01D4DAE340; Thu, 7 Nov 2002 12:02:49 -0800 (PST) Date: Thu, 7 Nov 2002 12:02:49 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Simple patch to make __sF suck less on -stable Message-ID: <20021107200249.GC39178@elvis.mu.org> References: <20021107.115936.40770874.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107.115936.40770874.imp@bsdimp.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * M. Warner Losh [021107 11:00] wrote: > http://people.freebsd.org/~imp/sf-patch > > This causes stable to generate __std{in,out,err}p references in > preference to __sF. If you rebuild with this patch, then you'll not > have __sF references in your libraries. This will allow new us to > share 4.x and 5.x libraries w/o the need for a gnarly version bump of > everything, provided we don't change the sizeof FILE in a released > version before 6.0. The whole idea was to allow struct file to change in 5.0. :( -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 12:54: 0 2002 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 F31F937B401; Thu, 7 Nov 2002 12:53:58 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84F6C43E4A; Thu, 7 Nov 2002 12:53:58 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gA7Krr1H064659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Nov 2002 12:53:55 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <031401c2869f$db71b720$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" , Cc: "Long, Scott" , , "Murray Stokely" References: Subject: Re: Bluetooth code Date: Thu, 7 Nov 2002 12:54:24 -0800 Organization: Errno Consulting 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I made a quick pass over this code. It's not clear to me why this stuff is or should be dependent on netgraph. The code looks to support a new protocol domain and sockets within that domain so it would seem possible for it to stand apart from netgraph. A bluetooth implementation that was not tied to netgraph would be preferrable as freebsd users would get the benefits of additional (non-freebsd users) working with the code. Specific stuff: 1. Why isn't btsockstat integrated into netstat? 2. l2test, hcdump, and hcinfo are missing (cited in man pages). 3. A bluetooth(4) man page would be useful. It's unclear to me how this support is used. There are no user-level applications that make use of it and I don't recognize existing applications that could use it. I suggest that w/o a "real user" adding this stuff to the system is premature. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 13: 6:14 2002 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 C332637B401; Thu, 7 Nov 2002 13:06:13 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CDA43E6E; Thu, 7 Nov 2002 13:06:12 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gA7L5eOr004260; Thu, 7 Nov 2002 22:05:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Sam Leffler" Cc: "Julian Elischer" , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, "Murray Stokely" Subject: Re: Bluetooth code In-Reply-To: Your message of "Thu, 07 Nov 2002 12:54:24 PST." <031401c2869f$db71b720$52557f42@errno.com> Date: Thu, 07 Nov 2002 22:05:40 +0100 Message-ID: <4259.1036703140@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <031401c2869f$db71b720$52557f42@errno.com>, "Sam Leffler" writes: >I made a quick pass over this code. It's not clear to me why this stuff is >or should be dependent on netgraph. The code looks to support a new >protocol domain and sockets within that domain so it would seem possible for >it to stand apart from netgraph. A bluetooth implementation that was not >tied to netgraph would be preferrable as freebsd users would get the >benefits of additional (non-freebsd users) working with the code. > >Specific stuff: > >1. Why isn't btsockstat integrated into netstat? Actually, isn't netstat(8) hairy enough as it is ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 13:18:36 2002 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 7AE9D37B401; Thu, 7 Nov 2002 13:18:35 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1159843E42; Thu, 7 Nov 2002 13:18:35 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gA7LIU1H064807 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Nov 2002 13:18:30 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <035101c286a3$4a7ccf80$52557f42@errno.com> From: "Sam Leffler" To: "Poul-Henning Kamp" Cc: "Julian Elischer" , , "Long, Scott" , , "Murray Stokely" References: <4259.1036703140@critter.freebsd.dk> Subject: Re: Bluetooth code Date: Thu, 7 Nov 2002 13:19:00 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > In message <031401c2869f$db71b720$52557f42@errno.com>, "Sam Leffler" writes: > >I made a quick pass over this code. It's not clear to me why this stuff is > >or should be dependent on netgraph. The code looks to support a new > >protocol domain and sockets within that domain so it would seem possible for > >it to stand apart from netgraph. A bluetooth implementation that was not > >tied to netgraph would be preferrable as freebsd users would get the > >benefits of additional (non-freebsd users) working with the code. > > > >Specific stuff: > > > >1. Why isn't btsockstat integrated into netstat? > > Actually, isn't netstat(8) hairy enough as it is ? > I understand why btsockstat was written as a standalone program. However I think it would be better to integrate it into the program people know to use to view active sockets. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 13:22:34 2002 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 0780837B401; Thu, 7 Nov 2002 13:22:33 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AF1443E42; Thu, 7 Nov 2002 13:22:32 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gA7LMNOr004524; Thu, 7 Nov 2002 22:22:23 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Sam Leffler" Cc: "Julian Elischer" , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, "Murray Stokely" Subject: Re: Bluetooth code In-Reply-To: Your message of "Thu, 07 Nov 2002 13:19:00 PST." <035101c286a3$4a7ccf80$52557f42@errno.com> Date: Thu, 07 Nov 2002 22:22:23 +0100 Message-ID: <4523.1036704143@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <035101c286a3$4a7ccf80$52557f42@errno.com>, "Sam Leffler" writes: >> In message <031401c2869f$db71b720$52557f42@errno.com>, "Sam Leffler" >writes: >> >I made a quick pass over this code. It's not clear to me why this stuff >is >> >or should be dependent on netgraph. The code looks to support a new >> >protocol domain and sockets within that domain so it would seem possible >for >> >it to stand apart from netgraph. A bluetooth implementation that was not >> >tied to netgraph would be preferrable as freebsd users would get the >> >benefits of additional (non-freebsd users) working with the code. >> > >> >Specific stuff: >> > >> >1. Why isn't btsockstat integrated into netstat? >> >> Actually, isn't netstat(8) hairy enough as it is ? >> > >I understand why btsockstat was written as a standalone program. However I >think it would be better to integrate it into the program people know to use >to view active sockets. Yeah, I agree about the principle, but I really think that netstat (and ifconfig) for that matter needs to either get modularized somehow (maybe along the lines of mount) or at least washed and dried so people can actually read the damn source without getting migraine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 13:38:41 2002 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 D264637B401; Thu, 7 Nov 2002 13:38:40 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C461943E75; Thu, 7 Nov 2002 13:38:36 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA7LcZpk024178; Thu, 7 Nov 2002 14:38:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Nov 2002 14:37:58 -0700 (MST) Message-Id: <20021107.143758.98192622.imp@bsdimp.com> To: bmah@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: Simple patch to make __sF suck less on -stable From: "M. Warner Losh" In-Reply-To: <200211071906.gA7J688E043599@intruder.bmah.org> References: <20021107.115936.40770874.imp@bsdimp.com> <200211071906.gA7J688E043599@intruder.bmah.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200211071906.gA7J688E043599@intruder.bmah.org> "Bruce A. Mah" writes: : If memory serves me right, "M. Warner Losh" wrote: : > http://people.freebsd.org/~imp/sf-patch : : That didn't look like a patch to me...did I miss something? No, I did. The correct patch should be there now. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 13:40:54 2002 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 368B037B401 for ; Thu, 7 Nov 2002 13:40:53 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BDDB43E4A for ; Thu, 7 Nov 2002 13:40:52 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA7Leppk024198; Thu, 7 Nov 2002 14:40:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 07 Nov 2002 14:40:13 -0700 (MST) Message-Id: <20021107.144013.48607310.imp@bsdimp.com> To: bright@mu.org Cc: arch@freebsd.org Subject: Re: Simple patch to make __sF suck less on -stable From: "M. Warner Losh" In-Reply-To: <20021107200249.GC39178@elvis.mu.org> References: <20021107.115936.40770874.imp@bsdimp.com> <20021107200249.GC39178@elvis.mu.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021107200249.GC39178@elvis.mu.org> Alfred Perlstein writes: : * M. Warner Losh [021107 11:00] wrote: : > http://people.freebsd.org/~imp/sf-patch : > : > This causes stable to generate __std{in,out,err}p references in : > preference to __sF. If you rebuild with this patch, then you'll not : > have __sF references in your libraries. This will allow new us to : > share 4.x and 5.x libraries w/o the need for a gnarly version bump of : > everything, provided we don't change the sizeof FILE in a released : > version before 6.0. : : The whole idea was to allow struct file to change in 5.0. :( Well, we f***'d up. We can't do that now. If we'd done the patch that is now at the above URL back in Aug 2001 we'd likely be able to, but we missed doing that. I'm thinking seriously of putting __sF back into libc for the 5.x series of releases, and killing it with 6.0. I know people wanted to kill it for 5.0, and have the freedom to change sizeof FILE, but we're going to have to live with it as the same size for one more major release. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 14: 3:11 2002 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 2178F37B401; Thu, 7 Nov 2002 14:03:09 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F3B43E3B; Thu, 7 Nov 2002 14:03:08 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA06987; Thu, 7 Nov 2002 13:48:12 -0800 (PST) Date: Thu, 7 Nov 2002 13:48:11 -0800 (PST) From: Julian Elischer To: Sam Leffler Cc: arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Maksim Yevmenkin , Murray Stokely Subject: Re: Bluetooth code In-Reply-To: <031401c2869f$db71b720$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Nov 2002, Sam Leffler wrote: > I made a quick pass over this code. It's not clear to me why this stuff is > or should be dependent on netgraph. The code looks to support a new > protocol domain and sockets within that domain so it would seem possible for > it to stand apart from netgraph. Yes, though bluetooth includes other dimensions that don't fit into that mold so easily. The author decided that he'd develop it under netgraph as it made his job easier. (as it was designed to do). When the code is fully functional, it would be a relatively simple matter to 'un-netgraph it should that be required. (personally I see no reason to do so). It's designed to allow that (should that be seen as a good idea (I don't think it matters). Netgraph is designed for rapid prototyping and development, but it still uses the standard mbufs etc. so that code developed under netgraph conforms to standard networking rules. With the new TAG code this is more true than ever. The bluetooth code however is not at that stage yet. > A bluetooth implementation that was not > tied to netgraph would be preferrable as freebsd users would get the > benefits of additional (non-freebsd users) working with the code. > NetBSD have their own bluetooth code that goes in /sys/dev/bluetooth. You are free to port that when (if) it's ready, in fact we are using netgraph/bluetooth specifically to not collide with that. It is much easier to develop under netgraph than not, as you have all the tools to independently test modules, unload them, change them, reload tehm, and pass captured packets through them. Netgraph supplies all the framework that allows protocol code to be developed easily It is designed for link-level packet manipulation and the socket code is particularly lousy at that, having been developed for network and transport level protocols. The two are actually a good fit. (for example whiel one COULD make a TCP stack in Netgraph (and in fact someone is trying to do that just for fun), it doesn;t gain you anything, but it DOES gain you a lot to do lower level manipulations through netgraph, as you can do various link-level tricks using common components at that level and the multiplexing requirements are different. > Specific stuff: > > 1. Why isn't btsockstat integrated into netstat? So that no standard programs need be altered.. when the dust settles it can be done. > 2. l2test, hcdump, and hcinfo are missing (cited in man pages). their functionality has been absorbed into other programs.. the man page should be updated. > 3. A bluetooth(4) man page would be useful. true. > > It's unclear to me how this support is used. There are no user-level > applications that make use of it and I don't recognize existing applications > that could use it. I suggest that w/o a "real user" adding this stuff to > the system is premature. There is no point in user apps until there is kernel support. it's a chicken and egg thing and I'd like to break the cycle by adding this code now. > > Sam > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 14: 3:39 2002 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 E311F37B401; Thu, 7 Nov 2002 14:03:37 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B4F43E6E; Thu, 7 Nov 2002 14:03:37 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA06995; Thu, 7 Nov 2002 13:51:38 -0800 (PST) Date: Thu, 7 Nov 2002 13:51:37 -0800 (PST) From: Julian Elischer To: Sam Leffler Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Maksim Yevmenkin , Murray Stokely Subject: Re: Bluetooth code In-Reply-To: <035101c286a3$4a7ccf80$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Nov 2002, Sam Leffler wrote: > > In message <031401c2869f$db71b720$52557f42@errno.com>, "Sam Leffler" > writes: > > >I made a quick pass over this code. It's not clear to me why this stuff > is > > >or should be dependent on netgraph. The code looks to support a new > > >protocol domain and sockets within that domain so it would seem possible > for > > >it to stand apart from netgraph. A bluetooth implementation that was not > > >tied to netgraph would be preferrable as freebsd users would get the > > >benefits of additional (non-freebsd users) working with the code. > > > > > >Specific stuff: > > > > > >1. Why isn't btsockstat integrated into netstat? > > > > Actually, isn't netstat(8) hairy enough as it is ? > > > > I understand why btsockstat was written as a standalone program. However I > think it would be better to integrate it into the program people know to use > to view active sockets. As I mantioned elsewhere the bluetooth code has all been written to completely be standalone and not alter any existing code, even Makefiles. I agree that later when the whole code is less experimental it could be merged into netstat. In the meanwhile it makes sense to have a separate program. > > Sam > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 14:10:41 2002 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 0837237B401 for ; Thu, 7 Nov 2002 14:10:41 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A7FF43E6E for ; Thu, 7 Nov 2002 14:10:40 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id gA7MAUHG101676; Thu, 7 Nov 2002 17:10:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20021107.115936.40770874.imp@bsdimp.com> References: <20021107.115936.40770874.imp@bsdimp.com> Date: Thu, 7 Nov 2002 17:10:29 -0500 To: "M. Warner Losh" , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Simple patch to make __sF suck less on -stable Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:59 AM -0700 11/7/02, M. Warner Losh wrote: >http://people.freebsd.org/~imp/sf-patch > >This causes stable to generate __std{in,out,err}p references in >preference to __sF. If you rebuild with this patch, then you'll >not have __sF references in your libraries. Assuming this works, would it be useful to have this included in the "-security" branch(es)? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 14:42:34 2002 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 6BF9D37B401; Thu, 7 Nov 2002 14:42:30 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E974D43E4A; Thu, 7 Nov 2002 14:42:29 -0800 (PST) (envelope-from Maksim.Yevmenkin@exodus.net) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 14:42:29 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 14:42:29 -0800 Message-ID: <3DCAEC54.8DA9179A@exodus.net> Date: Thu, 07 Nov 2002 14:42:28 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Sam Leffler , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Murray Stokely Subject: Re: Bluetooth code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2002 22:42:29.0515 (UTC) FILETIME=[F3F50DB0:01C286AE] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Julian Elischer wrote: > > On Thu, 7 Nov 2002, Sam Leffler wrote: > > > I made a quick pass over this code. It's not clear to me why this stuff is > > or should be dependent on netgraph. The code looks to support a new > > protocol domain and sockets within that domain so it would seem possible for > > it to stand apart from netgraph. > > Yes, though bluetooth includes other dimensions that don't fit into that > mold so easily. right. new protocol domain and sockets is just the one part of the code (optional). the code also includes support for low level Bluetooth procotols such as 1) HCI (Host Controller Interface) transport layers: H4 and UBT 2) HCI (Host Controller Interface) - not a network protocol, but a generic framework to talk to any Bluetooth device 3) L2CAP (Link Layer Control and Apaptation Protocol) - connection oriented procotol that runs over Bluetooth ACL (asynhronuous) data link. > The author decided that he'd develop it under netgraph as it made his > job easier. (as it was designed to do). When the code is fully > functional, it would be a relatively simple matter > to 'un-netgraph it should that be required. (personally I see no > reason to do so). It's designed to allow that (should that be seen as a > good idea (I don't think it matters). right. this code is a proof of concept that Netgraph can be used to do more then just a link layer protocol. it gives you advantage to use all flexiblity of Netgraph. it gives you a choice which modules you want to use. in fact one can throw away L2CAP and sockets and work directly on HCI layer (if so required). > Netgraph is designed for rapid prototyping and development, but it still > uses the standard mbufs etc. so that code developed under netgraph > conforms to standard networking rules. With the new TAG > code this is more true than ever. The bluetooth code however is not > at that stage yet. hmm... not sure what is "new TAG code", but i will look into it. > > A bluetooth implementation that was not > > tied to netgraph would be preferrable as freebsd users would get the > > benefits of additional (non-freebsd users) working with the code. > > > > NetBSD have their own bluetooth code that goes in /sys/dev/bluetooth. > You are free to port that when (if) it's ready, in fact > we are using netgraph/bluetooth specifically to not collide with that. right. i'm not sure what is the status of Bluetooth code in NetBSD, but CVSweb does not have much. i always wanted to keep my code under netgraph/ for two reasons 1) to indicate the fact that this is a Netgraph code 2) to make sure this code will not collide with any future Bluetooth stack in FreeBSD > It is much easier to develop under netgraph than not, > as you have all the tools to independently test modules, unload them, > change them, reload tehm, and pass captured packets through them. > Netgraph supplies all the framework that allows protocol code to be > developed easily It is designed for link-level packet manipulation and > the socket code is particularly lousy at that, having been developed for > network and transport level protocols. The two are actually a good fit. > (for example whiel one COULD make a TCP stack in Netgraph (and in fact > someone is trying to do that just for fun), it doesn;t gain you > anything, but it DOES gain you a lot to do lower level manipulations > through netgraph, as you can do various link-level tricks using common > components at that level and the multiplexing requirements are > different. > > > > Specific stuff: > > > > 1. Why isn't btsockstat integrated into netstat? > > So that no standard programs need be altered.. > when the dust settles it can be done. the project was advertised as separate from FreeBSD. i do not want to alter existing FreeBSD code in any way (well, perhast just a little bit to add new TTY line discipline and socket family). another reason is that btsockstat tied to btsocket module. i'm not sure that btsocket will be one and only Bluetooth socket implementation. this code is an optional. > > 2. l2test, hcdump, and hcinfo are missing (cited in man pages). > > their functionality has been absorbed into other programs.. > the man page should be updated. right. i should fix the man pages. > > 3. A bluetooth(4) man page would be useful. > > true. agree. i will write it. > > It's unclear to me how this support is used. There are no user-level > > applications that make use of it and I don't recognize existing applications > > that could use it. I suggest that w/o a "real user" adding this stuff to > > the system is premature. > > There is no point in user apps until there is kernel support. > it's a chicken and egg thing and I'd like to break the cycle > by adding this code now. i'm not sure what do you mean by user-level application. if you are talking about setup/control utility (a-la ifconfig) then hccontrol is everything you need. also Bluetooth has something called RFCOMM with is serial port over Bluetooth. user-space application localy works with /dev/tty just like it always did, but internally all communication is done via Bluetooth wireless link. Note: RFCOMM currentlly done in user-space, but it will be moved to kernel. another thing is a BNEP (Bluetooth Network Encapsulation Protocol) (not implemented yet). it is sort of Ethernet over Bluetooth. for each Bluetooth device there is a virtual Ethernet interface + Ethernet bridge. nodes can talk as soon as they in RF proximity. right now you can 1) run PPP over Bluetooth (LAN profile). 2) use Bluetooth to talk to your cell phone and use cell phone as wireless modem. DUN (Dial-UP networking) profile. 3) the OBEX server support is coming soon, so one can sync cell phone (or PDA) over Bluetooth. get pictures from digital camera, etc. most of these stuff was ported from Linux BlueZ stack and will be incuded (hopefully) into FreeBSD ports/ tree. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 15: 6:36 2002 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 357E937B401; Thu, 7 Nov 2002 15:06:34 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38DFB43E6E; Thu, 7 Nov 2002 15:06:33 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gA7N6Q1H065431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Nov 2002 15:06:26 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <038501c286b2$5efb1890$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" Cc: , "Long, Scott" , , "Maksim Yevmenkin" , "Murray Stokely" References: Subject: Re: Bluetooth code Date: Thu, 7 Nov 2002 15:06:56 -0800 Organization: Errno Consulting 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Thu, 7 Nov 2002, Sam Leffler wrote: > > A bluetooth implementation that was not > > tied to netgraph would be preferrable as freebsd users would get the > > benefits of additional (non-freebsd users) working with the code. > > > > NetBSD have their own bluetooth code that goes in /sys/dev/bluetooth. > You are free to port that when (if) it's ready, in fact > we are using netgraph/bluetooth specifically to not collide with that. > > <...netgraph PR deleted...> > I don't want to see multiple instances of Bluetooth support in the system. As you noted there's a netbsd implementation already. Having multiple incompatible implementations of the same protocol stack is silly. If this one is better than the netbsd one then great, but I want to see answers to these questions. Using netgraph for prototyping is fine. Using it for a final version means only freebsd users can make use of it. There aren't enough *bsd users around to not _TRY_ to get everyone sharing code. Perhaps you should port netgraph to other bsd's? > > It's unclear to me how this support is used. There are no user-level > > applications that make use of it and I don't recognize existing applications > > that could use it. I suggest that w/o a "real user" adding this stuff to > > the system is premature. > > There is no point in user apps until there is kernel support. > it's a chicken and egg thing and I'd like to break the cycle > by adding this code now. > No, this is not a chicken and egg problem. If the bluetooth support is useful then it must be useful for something. If there's nothing users can do with the support then it'll languish. You've already noted this stuff is loadable as modules so there is no barrier to the code coming in later or being maintained separately. As Maksim noted however there is an OBEX server coming soon. _THIS_ is justification for having the support in the kernel. I like this work. I think it deserves inclusion in the system somewhere. I'm not keen on it being tied to netgraph but undoing that is obviously major work. What I'd most like to understand is how it compares to the netbsd implementation and if it's going to be actively used and maintained. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 15:20:17 2002 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 9F2FD37B404; Thu, 7 Nov 2002 15:20:16 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 121C543E3B; Thu, 7 Nov 2002 15:20:16 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA07565; Thu, 7 Nov 2002 15:11:14 -0800 (PST) Date: Thu, 7 Nov 2002 15:11:13 -0800 (PST) From: Julian Elischer To: Maksim Yevmenkin Cc: Sam Leffler , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Murray Stokely Subject: Re: Bluetooth code In-Reply-To: <3DCAEC54.8DA9179A@exodus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sam, On Thu, 7 Nov 2002, Maksim Yevmenkin wrote: > Hello, > > Julian Elischer wrote: > > > > right now you can > > 1) run PPP over Bluetooth (LAN profile). > 2) use Bluetooth to talk to your cell phone and use cell phone > as wireless modem. DUN (Dial-UP networking) profile. > 3) the OBEX server support is coming soon, so one can sync > cell phone (or PDA) over Bluetooth. get pictures from > digital camera, etc. > > most of these stuff was ported from Linux BlueZ stack and will be > incuded (hopefully) into FreeBSD ports/ tree. As I said, it's a chicken and egg thing.. We need the kernel support in before we check in the ports. if we required teh ports before being allowed to check in the kernel support, that would be rather silly no? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 15:40:37 2002 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 84DB737B401 for ; Thu, 7 Nov 2002 15:40:35 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id A02E243E6E for ; Thu, 7 Nov 2002 15:40:34 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gA7NeXC4067272; Thu, 7 Nov 2002 15:40:33 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gA7NeX1b067271; Thu, 7 Nov 2002 15:40:33 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Thu, 7 Nov 2002 15:40:33 -0800 From: David Schultz To: Gary Thorpe Cc: freebsd-arch@FreeBSD.ORG Subject: Re: malloc(9) performance Message-ID: <20021107234033.GA67211@HAL9000.homeunix.com> Mail-Followup-To: Gary Thorpe , freebsd-arch@FreeBSD.ORG References: <20021107055331.GA63812@HAL9000.homeunix.com> <20021107143721.74192.qmail@web11201.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107143721.74192.qmail@web11201.mail.yahoo.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Gary Thorpe : > > When you make a single small allocation with malloc(3), you're > > effectively making a page allocation and then fiddling with a > > bitmap of free space within that page, so it takes longer than > > allocating full pages. The effort required is inversely > > proportional to the size of the allocation for sub-pagesize > > allocations. The routine could be micro-optimized, e.g. by > > replacing 'while (i >>= 1) j++;' with 'ffs(i & i-1);' and by > > adding a hint to speed up searching of the bitmap, but I'm > > skeptical that these tweaks would be worthwhile. I don't know > > anything about malloc(9), but I suspect it is orthogonal. > > Shouldn't page allocations be minimized to the situation where there is > not enough memory in partially free pages to satisfy the request? If > this is the case, then the first small malloc() would have to allocate > a page and set up bitmaps, but subsequent malloc()'s would only have to > manipulate the bitmap as long as they can hold in the same page (slower > than page-aligned malloc()'s when a new page is needed but it should be > otherwise faster). Since the kernel also does internal management of > its address space, would the same logic apply? Remember that I was talking about malloc(3), which doesn't know anything about memory pressure on the VM system. For purposes relevant to this discussion, it's allocating from an infinite pool of virtual memory, which just happens to become backed by physical memory when the program steps on it. It does not easily run out of pages that it can allocate; rather, it runs out of space among the pages it has already requested from the operating system. Specifically, it keeps lazily-allocated pools of memory in sizes that are powers of two. You're suggesting that it should preallocate bitmaps for the entire address space (but not fault them in, hopefully). While this approach would reduce copying and mmaping, there are a number of practical problems with it. First of all, you can't know ahead of time whether to make bitmaps for 512 byte allocations or for 2048 byte allocations, or some other size. Second, the application can manipulate the address space in ways that are not under the control of malloc(), e.g. via mmap() or sbrk(). I don't know enough about the kernel allocator to answer your last question, but certainly the problem of not knowing in advance what allocations will be used for and how big they will be is present. Maybe you could do something clever with a radix tree bitmap, but I'm not sure how worthwhile that would be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 15:40:57 2002 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 580F637B401; Thu, 7 Nov 2002 15:40:54 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95B4D43E3B; Thu, 7 Nov 2002 15:40:53 -0800 (PST) (envelope-from Maksim.Yevmenkin@exodus.net) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 15:40:53 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 15:40:53 -0800 Message-ID: <3DCAFA04.7B605725@exodus.net> Date: Thu, 07 Nov 2002 15:40:52 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler Cc: Julian Elischer , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Murray Stokely Subject: Re: Bluetooth code References: <038501c286b2$5efb1890$52557f42@errno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2002 23:40:53.0328 (UTC) FILETIME=[1C647D00:01C286B7] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sam, > > On Thu, 7 Nov 2002, Sam Leffler wrote: > > > A bluetooth implementation that was not > > > tied to netgraph would be preferrable as freebsd users would get the > > > benefits of additional (non-freebsd users) working with the code. > > > > > > > NetBSD have their own bluetooth code that goes in /sys/dev/bluetooth. > > You are free to port that when (if) it's ready, in fact > > we are using netgraph/bluetooth specifically to not collide with that. > > > > <...netgraph PR deleted...> > > > > I don't want to see multiple instances of Bluetooth support in the system. > As you noted there's a netbsd implementation already. Having multiple > incompatible implementations of the same protocol stack is silly. If this > one is better than the netbsd one then great, but I want to see answers to > these questions. i'm not aware of *any* *working* Bluetooth code for the NetBSD. all i can see is /dev/bluetooth directory with some *very* basic code. no HCI support, no L2CAP support, even no drivers for USB and/or serial based Bluetooth cards. all i can say is that there is *work in progress*. its quite different from "implementation". > Using netgraph for prototyping is fine. Using it for a final version means > only freebsd users can make use of it. There aren't enough *bsd users > around to not _TRY_ to get everyone sharing code. Perhaps you should port > netgraph to other bsd's? i personally think that porting Netgraph (especially -stable version) will be easy thing to do. in fact, i probably will need to port my code back to -stable Netgraph version anyway. few people actually wanted version for -stable. > > > It's unclear to me how this support is used. There are no user-level > > > applications that make use of it and I don't recognize existing > applications > > > that could use it. I suggest that w/o a "real user" adding this stuff > to > > > the system is premature. > > > > There is no point in user apps until there is kernel support. > > it's a chicken and egg thing and I'd like to break the cycle > > by adding this code now. > > > > No, this is not a chicken and egg problem. If the bluetooth support is > useful then it must be useful for something. If there's nothing users can > do with the support then it'll languish. You've already noted this stuff is > loadable as modules so there is no barrier to the code coming in later or > being maintained separately. but you *can* use it now. you *can* run PPP over Bluetooth and, for example, browse Internet from the Bluetooth enabled PDA. you *can* use your laptop to dial out via Bluetooth enabled cell phone and then again run PPP. this is one of the things Bluetooth was designed for. like i said soon you will be able to do even more, i.e. transfer files, business cards etc via OBEX. and as soon as there is in-kernel RFCOMM implementation *any* legacy application that uses serial ports will be able to take advantage of Bluetooth *without* any changes. what people asked so far is 1) is to be able to connect to local access point via Bluetooth, i.e. as soon as user comes into RF proximity PPP link gets established and away you go - read mail, print, transfer files (via FTP or whatever) etc. 2) get stuff on/off the cell phones, PDA etc. via Bluetooth. pictures, address books, etc. actually, i'm planing to get one of the Bluetooth-enabled cell phones to see what i can do with it :) > As Maksim noted however there is an OBEX server coming soon. _THIS_ is > justification for having the support in the kernel. > > I like this work. I think it deserves inclusion in the system somewhere. > I'm not keen on it being tied to netgraph but undoing that is obviously > major work. What I'd most like to understand is how it compares to the > netbsd implementation and if it's going to be actively used and maintained. thanks, but then again the code in NetBSD is hardly an implementation. take a look for yourself. personally i'm all 100% for shared *BSD Bluetooth stack. i *do not* insist on my implementation and gladly will donate my free time to work on the shared code. that is what i told to Lennart Augustsson. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 15:54:44 2002 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 1057537B404; Thu, 7 Nov 2002 15:54:43 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9234D43E88; Thu, 7 Nov 2002 15:54:42 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0030.cvx40-bradley.dialup.earthlink.net ([216.244.42.30] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 189wTW-0007RA-00; Thu, 07 Nov 2002 15:54:15 -0800 Message-ID: <3DCAFCA8.DF1FF47A@mindspring.com> Date: Thu, 07 Nov 2002 15:52:08 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler Cc: Julian Elischer , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Maksim Yevmenkin , Murray Stokely Subject: Re: Bluetooth code References: <038501c286b2$5efb1890$52557f42@errno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sam Leffler wrote: > I don't want to see multiple instances of Bluetooth support in the system. > As you noted there's a netbsd implementation already. Having multiple > incompatible implementations of the same protocol stack is silly. If this > one is better than the netbsd one then great, but I want to see answers to > these questions. Usually, I'm on the same page with you... but this time, no. There are a *lot* of FreeBSD-specific changes that have gone into FreeBSD without going into NetBSD/OpenBSD/BSI/OS-X, and there was not a lot of complaining (except by a few of us) when those changes went in. Complaining when someone makes NetBSD-specific changes, and then doesn't port them to FreeBSD, is, well, not really sane. > Using netgraph for prototyping is fine. Using it for a final version means > only freebsd users can make use of it. There aren't enough *bsd users > around to not _TRY_ to get everyone sharing code. Perhaps you should port > netgraph to other bsd's? It's really easy to make the same argument about the VM system in FreeBSD, the VM system in NetBSD, or the VFS changes in FreeBSD that made it impossible to share VFS modules between FreeBSD and NetBSD -- an ongoing process that started in 1994, when FreeBSD and NetBSD adopted different parameter definitions for the cookie support in VOP_READDIR() for restarting directory enumerations over NFS. The counterargument is "port NetGraph to NetBSD, OpenBSD, and BSDI". The issue that's being raised here is "Who gets to lead the parade?"; the answer "Be a follower, not a leader" isn't very satisfying to anyone. > I like this work. I think it deserves inclusion in the system somewhere. > I'm not keen on it being tied to netgraph but undoing that is obviously > major work. What I'd most like to understand is how it compares to the > netbsd implementation and if it's going to be actively used and maintained. I think the most salient comparison is "It runs on FreeBSD, and the NetBSD implementation does not"; all other considerations must be secondary to rough consensus and working code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 16:53:44 2002 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 CC8ED37B401 for ; Thu, 7 Nov 2002 16:53:41 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2690543E4A for ; Thu, 7 Nov 2002 16:53:41 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gA80rd1H065805 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Nov 2002 16:53:40 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <03fc01c286c1$59e2a170$52557f42@errno.com> From: "Sam Leffler" To: "Terry Lambert" Cc: "Julian Elischer" , , "Long, Scott" , , "Maksim Yevmenkin" , "Murray Stokely" References: <038501c286b2$5efb1890$52557f42@errno.com> <3DCAFCA8.DF1FF47A@mindspring.com> Subject: Re: Bluetooth code Date: Thu, 7 Nov 2002 16:54:10 -0800 Organization: Errno Consulting 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Sam Leffler wrote: > > I don't want to see multiple instances of Bluetooth support in the system. > > As you noted there's a netbsd implementation already. Having multiple > > incompatible implementations of the same protocol stack is silly. If this > > one is better than the netbsd one then great, but I want to see answers to > > these questions. > > Usually, I'm on the same page with you... but this time, no. > Careful, "He's got opinions and he's not afraid to use 'em!" > There are a *lot* of FreeBSD-specific changes that have gone into > FreeBSD without going into NetBSD/OpenBSD/BSI/OS-X, and there was > not a lot of complaining (except by a few of us) when those changes > went in. > > Complaining when someone makes NetBSD-specific changes, and then > doesn't port them to FreeBSD, is, well, not really sane. > What I was doing was questioning the blind acceptance of a large piece of work that appeared to have no application and potentially overlaps with work going on elsewhere. Maksim has answered my questions in this regard and I'm satisfied. Bottom line: when you want to add something to the system, be prepared to justify it. > > > Using netgraph for prototyping is fine. Using it for a final version means > > only freebsd users can make use of it. There aren't enough *bsd users > > around to not _TRY_ to get everyone sharing code. Perhaps you should port > > netgraph to other bsd's? > > It's really easy to make the same argument about the VM system in > FreeBSD, the VM system in NetBSD, or the VFS changes in FreeBSD > that made it impossible to share VFS modules between FreeBSD and > NetBSD -- an ongoing process that started in 1994, when FreeBSD > and NetBSD adopted different parameter definitions for the cookie > support in VOP_READDIR() for restarting directory enumerations over > NFS. > > The counterargument is "port NetGraph to NetBSD, OpenBSD, and BSDI". > > The issue that's being raised here is "Who gets to lead the parade?"; > the answer "Be a follower, not a leader" isn't very satisfying to > anyone. > The issue is should we commit something to the source tree that may be of limited use to people. If the software provides functionality to a significant group of people then I'm open to its inclusion regardless of whether it's present in any other system. However one must not lose sight that adding code to the source tree has a cost, independent of whether it is "hooked up to the build". If the code doesn't have someone to maintain it as the system changes then it can become a boat anchor. Code rot is unhealthy for maintaining quality software. Code rot happens quickly when noone uses it. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 17:14: 6 2002 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 9AF6137B401; Thu, 7 Nov 2002 17:14:04 -0800 (PST) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3E4C43E4A; Thu, 7 Nov 2002 17:14:03 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0030.cvx40-bradley.dialup.earthlink.net ([216.244.42.30] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 189xic-0005qS-00; Thu, 07 Nov 2002 17:13:55 -0800 Message-ID: <3DCB0EF9.617D66B5@mindspring.com> Date: Thu, 07 Nov 2002 17:10:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler Cc: Julian Elischer , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Maksim Yevmenkin , Murray Stokely Subject: Re: Bluetooth code References: <038501c286b2$5efb1890$52557f42@errno.com> <3DCAFCA8.DF1FF47A@mindspring.com> <03fc01c286c1$59e2a170$52557f42@errno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sam Leffler wrote: > > The counterargument is "port NetGraph to NetBSD, OpenBSD, and BSDI". > > > > The issue that's being raised here is "Who gets to lead the parade?"; > > the answer "Be a follower, not a leader" isn't very satisfying to > > anyone. > > The issue is should we commit something to the source tree that may be of > limited use to people. If the software provides functionality to a > significant group of people then I'm open to its inclusion regardless of > whether it's present in any other system. However one must not lose sight > that adding code to the source tree has a cost, independent of whether it is > "hooked up to the build". If the code doesn't have someone to maintain it > as the system changes then it can become a boat anchor. Well, the Bluetooth code has an active developer, it has some applications that are available for it already, and it's severable from the main source tree in a way that boat anchors aren't. There's some small argument that's valid, that if ports are written to use a Netgraph bluetooth stack, they won't be that portable to other BSD's that don't have Netgraph. This is a valid argument, but it appears that NetBSD doesn't even have real Bluetooth at this, point, so it's kind of moot. > Code rot is unhealthy for maintaining quality software. Code rot > happens quickly when noone uses it. I disagree. There is no such thing as code rot. There are only jerks who changes working interfaces, and fail to maintain the code that uses them. I have an example list a mile long on that one, too. Institutionalizing the acceptability of "code rot" is institutionalizing the acceptability of being a jerk. It's a completely seperate issue from whether or not code falls into disuse. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 7 17:31:51 2002 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 B66FD37B401; Thu, 7 Nov 2002 17:31:49 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 543C943E6E; Thu, 7 Nov 2002 17:31:45 -0800 (PST) (envelope-from Maksim.Yevmenkin@exodus.net) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 17:31:44 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 17:31:44 -0800 Message-ID: <3DCB13FF.14F7BD79@exodus.net> Date: Thu, 07 Nov 2002 17:31:43 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Sam Leffler , Julian Elischer , arch@FreeBSD.ORG, "Long, Scott" , re@FreeBSD.ORG, Murray Stokely Subject: Re: Bluetooth code References: <038501c286b2$5efb1890$52557f42@errno.com> <3DCAFCA8.DF1FF47A@mindspring.com> <03fc01c286c1$59e2a170$52557f42@errno.com> <3DCB0EF9.617D66B5@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2002 01:31:44.0068 (UTC) FILETIME=[988AE040:01C286C6] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Sam Leffler wrote: > > > The counterargument is "port NetGraph to NetBSD, OpenBSD, and BSDI". > > > > > > The issue that's being raised here is "Who gets to lead the parade?"; > > > the answer "Be a follower, not a leader" isn't very satisfying to > > > anyone. > > > > The issue is should we commit something to the source tree that may be of > > limited use to people. If the software provides functionality to a > > significant group of people then I'm open to its inclusion regardless of > > whether it's present in any other system. However one must not lose sight > > that adding code to the source tree has a cost, independent of whether it is > > "hooked up to the build". If the code doesn't have someone to maintain it > > as the system changes then it can become a boat anchor. > > Well, the Bluetooth code has an active developer, it has some > applications that are available for it already, and it's severable > from the main source tree in a way that boat anchors aren't. > > There's some small argument that's valid, that if ports are written > to use a Netgraph bluetooth stack, they won't be that portable to > other BSD's that don't have Netgraph. This is a valid argument, > but it appears that NetBSD doesn't even have real Bluetooth at this, > point, so it's kind of moot. the ports *will not* be tied to the Netgraph. they *never were*. there is no reason to re-invent the wheel. my current ports are from Linux BlueZ include SDP, RFCOMM, hcidump and l2test. ports *do use* similar API - Bluetooth sockets. what i do is 1) remove autoconf 2) fix #include's 3) fix constant's etc. 4) remove/rewrite some Linux specific stuff it usually takes about 4 hours to make a complete working port (including basic interoperability testing). BlueZ author and i currently discussing common API to make porting even easier. Linux is more advanced in Bluetooth (Linux has three(!) stacks: BlueZ, Affix and OpenBT). i'm trying to learn from them and do not make the same mistakes. > > Code rot is unhealthy for maintaining quality software. Code rot > > happens quickly when noone uses it. > > I disagree. There is no such thing as code rot. There are only > jerks who changes working interfaces, and fail to maintain the > code that uses them. I have an example list a mile long on that > one, too. Institutionalizing the acceptability of "code rot" is > institutionalizing the acceptability of being a jerk. It's a > completely seperate issue from whether or not code falls into > disuse. max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 8 5:34: 7 2002 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 7C98437B404 for ; Fri, 8 Nov 2002 05:34:06 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4685743E9E for ; Fri, 8 Nov 2002 05:34:04 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id gA8DXJOo062010; Fri, 8 Nov 2002 08:33:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 8 Nov 2002 08:33:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Cyrille Lefevre Cc: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: <20021105204013.GC56253@gits.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Nov 2002, Cyrille Lefevre wrote: > On Sun, Oct 27, 2002 at 12:33:41AM -0400, Robert Watson wrote: > > > > On Sat, 26 Oct 2002, David O'Brien wrote: > > > > > > (1) All references to lukemftpd as "the ftpd" be corrected to indicate > > > > lukemftpd is not the default. Most of these are leaked references > > > > from lukemftpd man pages that were not updated in the import. > > > > > > We typically don't rewrite contrib'ed vendor branch code. On some of my > > > systems lukemftp is THE ftpd, so they do apply. > > > > Just to make it completely clear what I'm talking about here: we do have a > > "the ftpd", because we install it as /usr/libexec/ftpd. Lukemftpd is > > installed as /usr/libexec/lukemftpd. Documentation should refer to the > > binaries and man pages correctly. One specific example of this is > > ftpd.conf(5), which incorrectly stats: > > how about the following PR ? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/39676 This PR looks like it would pretty cleanly address the first set of problems I identified regarding the man pages being inaccurate. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 8 17:33:17 2002 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 E4DD637B401; Fri, 8 Nov 2002 17:33:16 -0800 (PST) Received: from out017.verizon.net (out017pub.verizon.net [206.46.170.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10BC443E7B; Fri, 8 Nov 2002 17:33:16 -0800 (PST) (envelope-from arlankfo@verizon.net) Received: from verizon.net ([138.88.151.200]) by out017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021109013315.QBRC3572.out017.verizon.net@verizon.net>; Fri, 8 Nov 2002 19:33:15 -0600 To: arch@freebsd.org Cc: phk@freebsd.org Subject: From: "Andrew Lankford" Reply-To: "Andrew Lankford" Date: Fri, 08 Nov 2002 20:33:44 -0500 Message-Id: <20021109013315.QBRC3572.out017.verizon.net@verizon.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >In message <20021108164651.6e839063.fearow@attbi.com>, Anti writes: >> >how are you supposed to get rid of devfs? > >You're not. Just out of curiosity, what's the main motivation for doing that? Does UFS2 not support device nodes? Or is it no longer possible to extricate DEVFS code from the legacy code at compile time? Would the average embedded BSD user to notice any difference in memory usage? I gather that the advantage of making GEOM standard will greatly reduce code redundancy in the long run, but it's nice to be able to config out other major OS components like INET6 and maybe even INET in some cases, even if support for a no-"INET" config may inevitably "wither on the vine" in some future release, just like matcd and (god willing) floppy disks. Incidently, the last time I removed 'option INET' in my config was 2.2.2 (the dark ages). Hope I'm not resurrecting a "bikeshed". -CURRENT DEVFS works great, and I look forward to using it in 5-STABLE. But a '/etc/MAKEDEV all' on a FFS partition still works as expected too. And why shouldn't it? Andrew Lankford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 8 18:12:28 2002 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 B93DD37B401 for ; Fri, 8 Nov 2002 18:12:27 -0800 (PST) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 144F543E88 for ; Fri, 8 Nov 2002 18:12:27 -0800 (PST) (envelope-from arlankfo@verizon.net) Received: from verizon.net ([138.88.151.200]) by out012.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021109021226.ORJQ1488.out012.verizon.net@verizon.net> for ; Fri, 8 Nov 2002 20:12:26 -0600 To: arch@freebsd.org Subject: Re: getting rid of devfs From: "Andrew Lankford" Reply-To: "Andrew Lankford" Date: Fri, 08 Nov 2002 21:12:54 -0500 Message-Id: <20021109021226.ORJQ1488.out012.verizon.net@verizon.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >In message <20021108164651.6e839063.fearow@attbi.com>, Anti writes: >> >how are you supposed to get rid of devfs? > >You're not. Just out of curiosity, what's the main motivation for doing that? Does UFS2 not support device nodes? Or is it no longer possible to extricate DEVFS code from the legacy code at compile time? Would the average embedded BSD user to notice any difference in memory usage? I gather that the advantage of making GEOM standard will greatly reduce code redundancy in the long run, but it's nice to be able to config out other major OS components like INET6 and maybe even INET in some cases, even if support for a no-"INET" config may inevitably "wither on the vine" in some future release, just like matcd and (god willing) floppy disks. Incidently, the last time I removed 'option INET' in my config was 2.2.2 (the dark ages). Hope I'm not resurrecting a "bikeshed". -CURRENT DEVFS works great, and I look forward to using it in 5-STABLE. But a '/etc/MAKEDEV all' on a FFS partition still works as expected too. And why shouldn't it? Andrew Lankford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 8 23:12:36 2002 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 E611D37B401 for ; Fri, 8 Nov 2002 23:12:34 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F4DA43E3B for ; Fri, 8 Nov 2002 23:12:34 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA97CWpk035794 for ; Sat, 9 Nov 2002 00:12:33 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 09 Nov 2002 00:12:25 -0700 (MST) Message-Id: <20021109.001225.94555950.imp@bsdimp.com> To: arch@freebsd.org Subject: Re: bluetooth From: "M. Warner Losh" In-Reply-To: <038501c286b2$5efb1890$52557f42@errno.com> References: <038501c286b2$5efb1890$52557f42@errno.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <038501c286b2$5efb1890$52557f42@errno.com> "Sam Leffler" writes: : > On Thu, 7 Nov 2002, Sam Leffler wrote: : > > A bluetooth implementation that was not : > > tied to netgraph would be preferrable as freebsd users would get the : > > benefits of additional (non-freebsd users) working with the code. : > > : > : > NetBSD have their own bluetooth code that goes in /sys/dev/bluetooth. : > You are free to port that when (if) it's ready, in fact : > we are using netgraph/bluetooth specifically to not collide with that. : > : > <...netgraph PR deleted...> : > : : I don't want to see multiple instances of Bluetooth support in the system. : As you noted there's a netbsd implementation already. Having multiple : incompatible implementations of the same protocol stack is silly. If this : one is better than the netbsd one then great, but I want to see answers to : these questions. I'd go one step farther. I'd say that it would be insane to have more than one bluetooth stack for FreeBSD. I'd go farther and say that it would be insane to have more than one bluetooth stack for *BSD. Bluetooth is too big and specailized for there to be much benefit in competing stacks. I mean look how far the multiple ATM stacks got us. It was a dump idea to have more than one in the system, and now both aren't very supported. People had to beg and plead to get the drivers updated, and only one of the two stacks survived (if I read my commit mail correctly). And look at OLDCARD and NEWCARD. When both were being worked on, both suffered. OLDCARD got all the bug fixes and new features for a while when we'd be more ahead today if I'd ported NEWCARD to -stable and pc98 instead. Having two implementations there was more of a liability than an asset I sometimes think. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 0:20:13 2002 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 E5AC037B401 for ; Sat, 9 Nov 2002 00:20:10 -0800 (PST) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1134043E9E for ; Sat, 9 Nov 2002 00:20:10 -0800 (PST) (envelope-from mheffner@vt.edu) Received: from steiner.cc.vt.edu (IDENT:mirapoint@steiner-lb.cc.vt.edu [10.1.1.14]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id gA98K9c120051; Sat, 9 Nov 2002 03:20:09 -0500 (EST) Received: from enterprise.muriel.penguinpowered.com ([199.3.139.243]) by steiner.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ASB84139 (AUTH mheffner); Sat, 9 Nov 2002 03:20:09 -0500 (EST) Message-ID: X-Mailer: XFMail 1.5.3 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.3.FreeBSD:20021109031937:13589=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: Date: Sat, 09 Nov 2002 03:19:37 -0500 (EST) From: Mike Heffner To: Garance A Drosihn Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.3.FreeBSD:20021109031937:13589=_ Content-Type: text/plain; charset=us-ascii On 25-Oct-2002 Garance A Drosihn wrote: | At 11:42 AM +0930 10/25/02, Greg 'groggy' Lehey wrote: |>On Thursday, 24 October 2002, Giorgos Keramidas wrote: |> > I'm not exactly suggesting anything here (like someone jumping up |>> and saying "I will"); just making sure that the author of lukemftp |>> and lukemftpd is contacted before any decision is made. |> |>Luke is also very concerned about compatibility between the BSDs. |>It's understandable that lukemftpd (currently) doesn't support |>FreeBSD-specific features, but I'm sure that he'd be interested in |>maintaining the features in some form. Has anybody asked him? | | All reports are that Luke is a nice guy, and willing to work with | freebsd. The problem is finding someone in freebsd who is willing | to work on comparing freebsd-ftp to lukemftpd. Philosophically I'm | all for the idea, but I am another person who can't commit to doing | any useful work on it at the moment. | | If we can't find someone on our side to do the necessary work, then | we probably do have to "play down" lukemftpd for the upcoming 5.0 | release. So we need to find that willing volunteer sometime soon, | and someone who has the time right now... | Sorry to come in late on this discussion. I was originally one of the people who was interested in the importing of lukemftpd and merging in some of the FreeBSD'isms, etc.. Unfortunately, due to school and $ work I haven't had the time necessary that I had hoped to devote to it. However, as soon as I get a -current box together I plan to continue where I left off with this. Yes, as many people have mentioned, Luke is more than willing to merge in changes from FreeBSD to lukemftpd (take for example the many changes to lukemftp that he accepted and then released a new version of). Luke is typically very busy, but I've generally found that if a patch is produced that is acceptable and doesn't require much time on his part to integrate, he will merge it into lukemftp[d]. I plan to pick up the PRs that have been opened against it and remove the ambiguities that lukemftpd is 'the ftpd'. I will also try to merge as many of the critical aspects from ftpd as possible (eg, the login.conf support) before 5.0-R. If anyone else has worked on any of these, please let me know so that we can coordinate. Thanks, Mike -- Mike Heffner --_=XFMail.1.5.3.FreeBSD:20021109031937:13589=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE9zMUYFokZQs3sv5kRAlr4AJ43hTOK6JQRQizJdviht3JkqA81dACdGLWi IsbJsdn1VmLgdqo2tZV5yYc= =WjFh -----END PGP SIGNATURE----- --_=XFMail.1.5.3.FreeBSD:20021109031937:13589=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 1:24:41 2002 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 98AB537B401 for ; Sat, 9 Nov 2002 01:24:40 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E5543E3B for ; Sat, 9 Nov 2002 01:24:39 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gA99O4Or063215; Sat, 9 Nov 2002 10:24:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Andrew Lankford" Cc: arch@FreeBSD.ORG Subject: Re: getting rid of devfs In-Reply-To: Your message of "Fri, 08 Nov 2002 21:12:54 EST." <20021109021226.ORJQ1488.out012.verizon.net@verizon.net> Date: Sat, 09 Nov 2002 10:24:04 +0100 Message-ID: <63214.1036833844@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20021109021226.ORJQ1488.out012.verizon.net@verizon.net>, "Andrew La nkford" writes: >>In message <20021108164651.6e839063.fearow@attbi.com>, Anti writes: >>> >>how are you supposed to get rid of devfs? >> >>You're not. > >Just out of curiosity, what's the main motivation for doing that? DEVFS and GEOM are quite intrusive infrastructure parts, and maintaining the ability to run with/without is more comparable to having two different networkstacks than to running with/without INET for instance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 4: 7:16 2002 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 E837B37B401 for ; Sat, 9 Nov 2002 04:07:14 -0800 (PST) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81FEF43E6E for ; Sat, 9 Nov 2002 04:07:14 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0007.cvx22-bradley.dialup.earthlink.net ([209.179.198.7] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18AUOI-0007gL-00; Sat, 09 Nov 2002 04:07:07 -0800 Message-ID: <3DCCFA1F.7B5F4C01@mindspring.com> Date: Sat, 09 Nov 2002 04:05:51 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: bluetooth References: <038501c286b2$5efb1890$52557f42@errno.com> <20021109.001225.94555950.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > I'd go one step farther. I'd say that it would be insane to have more > than one bluetooth stack for FreeBSD. I'd go farther and say that it > would be insane to have more than one bluetooth stack for *BSD. > Bluetooth is too big and specailized for there to be much benefit in > competing stacks. I'll go further... it's insane to have more than one Bluetooh stack period. Are people actively trying to ignore the example of the success of TCP/IP, or what? > I mean look how far the multiple ATM stacks got us. It was a dump > idea to have more than one in the system, and now both aren't very > supported. People had to beg and plead to get the drivers updated, > and only one of the two stacks survived (if I read my commit mail > correctly). I think this had more to do with ATM sucking, more than anything else. I note that NetBEUI isn't supported, even though there was a full stack written by MITRE for FreeBSD, and that X.25 and OSI both have very poor support in FreeBSD, ever since they were both orphaned by the routing code not being updated in those stacks at the same time it was updated in the TCP/IP stack. So ATM isn't really a good negative example for multiple stacks, as much as it's a negative example for useful protocol design. > And look at OLDCARD and NEWCARD. When both were being worked on, both > suffered. OLDCARD got all the bug fixes and new features for a while > when we'd be more ahead today if I'd ported NEWCARD to -stable and > pc98 instead. Having two implementations there was more of a > liability than an asset I sometimes think. Again, I think the problem with both of them has been a serious lack of documentation, more than anything else. The Bus Space code is another good example of code that's not documented well enough for people to use it usefully, or FreeBSD would already support more than 2G of memory on Alpha systems. The problem there is more one of letting replacement code into the kernel, without replacement documentation for the new code that at least matches the documentation for the old code. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 18: 6:39 2002 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 6A56937B401 for ; Sat, 9 Nov 2002 18:06:37 -0800 (PST) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACA5143E3B for ; Sat, 9 Nov 2002 18:06:35 -0800 (PST) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (hiten@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id gAA2635N024564; Sat, 9 Nov 2002 21:06:03 -0500 (EST) X-Authentication-Warning: angelica.unixdaemons.com: Host hiten@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id gAA2638t024559; Sat, 9 Nov 2002 21:06:03 -0500 (EST) (envelope-from hiten) Date: Sat, 9 Nov 2002 21:06:03 -0500 From: Hiten Pandya To: Terry Lambert Cc: "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: bluetooth Message-ID: <20021109210603.A23872@angelica.unixdaemons.com> References: <038501c286b2$5efb1890$52557f42@errno.com> <20021109.001225.94555950.imp@bsdimp.com> <3DCCFA1F.7B5F4C01@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DCCFA1F.7B5F4C01@mindspring.com>; from tlambert2@mindspring.com on Sat, Nov 09, 2002 at 04:05:51AM -0800 X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Nov 09, 2002 at 04:05:51AM -0800, Terry Lambert wrote the words in effect of: > "M. Warner Losh" wrote: > > I'd go one step farther. I'd say that it would be insane to have more > > than one bluetooth stack for FreeBSD. I'd go farther and say that it > > would be insane to have more than one bluetooth stack for *BSD. > > Bluetooth is too big and specailized for there to be much benefit in > > competing stacks. > > I'll go further... it's insane to have more than one Bluetooh stack > period. > > Are people actively trying to ignore the example of the success of > TCP/IP, or what? > > > > I mean look how far the multiple ATM stacks got us. It was a dump > > idea to have more than one in the system, and now both aren't very > > supported. People had to beg and plead to get the drivers updated, > > and only one of the two stacks survived (if I read my commit mail > > correctly). > > I think this had more to do with ATM sucking, more than anything > else. I note that NetBEUI isn't supported, even though there was > a full stack written by MITRE for FreeBSD, and that X.25 and OSI > both have very poor support in FreeBSD, ever since they were both > orphaned by the routing code not being updated in those stacks at > the same time it was updated in the TCP/IP stack. > > So ATM isn't really a good negative example for multiple stacks, > as much as it's a negative example for useful protocol design. > > > > And look at OLDCARD and NEWCARD. When both were being worked on, both > > suffered. OLDCARD got all the bug fixes and new features for a while > > when we'd be more ahead today if I'd ported NEWCARD to -stable and > > pc98 instead. Having two implementations there was more of a > > liability than an asset I sometimes think. > > Again, I think the problem with both of them has been a serious > lack of documentation, more than anything else. The Bus Space > code is another good example of code that's not documented well > enough for people to use it usefully, or FreeBSD would already > support more than 2G of memory on Alpha systems. > > The problem there is more one of letting replacement code into > the kernel, without replacement documentation for the new code > that at least matches the documentation for the old code. > I am not sure how right my answer is, but if someone really wanted to know about bus_space(9), than they can just look it up the NetBSD manual page. It is very well documented, and not a whole lot if different. In fact, I had started some work to port the manual page to FreeBSD about 5 weeks ago, and then stopped because of studies. If you are interested in ongoing work: http://www.unixdaemons.com/~hiten/work/diffs/netbsd-bus_space.9 Cheers. -- Hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 19:20:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id AAC7D37B401; Sat, 9 Nov 2002 19:20:23 -0800 (PST) To: imp@bsdimp.com Subject: Re: bluetooth Cc: arch@freebsd.org In-Reply-To: <20021109.001225.94555950.imp@bsdimp.com> Message-Id: <20021110032023.AAC7D37B401@hub.freebsd.org> Date: Sat, 9 Nov 2002 19:20:23 -0800 (PST) From: julian@FreeBSD.ORG (Julian Elischer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'd go one step farther. I'd say that it would be insane to have more > than one bluetooth stack for FreeBSD. I'd go farther and say that it > would be insane to have more than one bluetooth stack for *BSD. > Bluetooth is too big and specailized for there to be much benefit in > competing stacks. The Netgraph stack is more an idea than code at this stage.. are you suggesting that we do not commit our working stack because they might sometime write a stack? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 20:38: 5 2002 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 5AA5837B401; Sat, 9 Nov 2002 20:38:04 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5542043E42; Sat, 9 Nov 2002 20:38:03 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gAA4c2pk069054; Sat, 9 Nov 2002 21:38:02 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 09 Nov 2002 21:37:56 -0700 (MST) Message-Id: <20021109.213756.23012360.imp@bsdimp.com> To: julian@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: bluetooth From: "M. Warner Losh" In-Reply-To: <20021110032023.AAC7D37B401@hub.freebsd.org> References: <20021109.001225.94555950.imp@bsdimp.com> <20021110032023.AAC7D37B401@hub.freebsd.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021110032023.AAC7D37B401@hub.freebsd.org> julian@FreeBSD.ORG (Julian Elischer) writes: : : > I'd go one step farther. I'd say that it would be insane to have more : > than one bluetooth stack for FreeBSD. I'd go farther and say that it : > would be insane to have more than one bluetooth stack for *BSD. : > Bluetooth is too big and specailized for there to be much benefit in : > competing stacks. : : The Netgraph stack is more an idea than code at this stage.. are you : suggesting that we do not commit our working stack because they might : sometime write a stack? If the code is so horrible, why commit it at all? FreeBSD isn't a dumping ground for any old code that people happen to come up with. You can't argue that we should commit it to FreeBSD, because it is about ready and at the same time argue that the code sucks, so you don't have to do any work. You can't have your cake and eat it too. Either it is just about ready for prime time and you need to properly integrate it into the tree, or it is an experimental hack that has no business being in the tree. It can't be both. I'm not suggesting that we shouldn't commit this code because NetBSD might someday come up with a better stack. I'm saying that we need to be open to sharing with NetBSD/OpenBSD. I'm saying that you need to be open to integrating it completely into the tree. I'm saying that we should make efforts to allow our NetBSD bretheren to pick up the stack. Didn't you read the rest of my post? FreeBSD has plenty of examples where code was committed prematurely and then it rotted to worthlessness. Sometimes this was because there were multiple similar things in the tree, other times the original developer fell off the face of the earth. In any event, it has caused us problems. BTW, looking at the stack it appears to me that this code is getting close to being real enough for inclusion in the tree. Don't take my comments above as thinking that code in question is horrible. I'm just pointing out how contradictory your arguments are, which is why people are giving you a hard time about how you want to integrate the code. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 21:50: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 8DC0937B404; Sat, 9 Nov 2002 21:50:05 -0800 (PST) To: imp@bsdimp.com, julian@FreeBSD.ORG Subject: Re: bluetooth Cc: arch@FreeBSD.ORG In-Reply-To: <20021109.213756.23012360.imp@bsdimp.com> Message-Id: <20021110055005.8DC0937B404@hub.freebsd.org> Date: Sat, 9 Nov 2002 21:50:05 -0800 (PST) From: julian@FreeBSD.ORG (Julian Elischer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG oops I meant the NetBSD code is more an idea than code teh NetGRAPH code is working code.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 21:53:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 4AA8E37B401; Sat, 9 Nov 2002 21:53:16 -0800 (PST) To: imp@bsdimp.com, julian@FreeBSD.ORG Subject: Re: bluetooth Cc: arch@FreeBSD.ORG In-Reply-To: <20021109.213756.23012360.imp@bsdimp.com> Message-Id: <20021110055316.4AA8E37B401@hub.freebsd.org> Date: Sat, 9 Nov 2002 21:53:16 -0800 (PST) From: julian@FreeBSD.ORG (Julian Elischer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > : > : The Netgraph stack is more an idea than code at this stage.. are you oops, I meant NETBSD!!! My fingers automatically typed the wrong ending.. > : suggesting that we do not commit our working stack because they might > : sometime write a stack? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 21:58:50 2002 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 4946137B401; Sat, 9 Nov 2002 21:58:49 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CBE843EA9; Sat, 9 Nov 2002 21:58:48 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gAA5wlpk036090; Sat, 9 Nov 2002 22:58:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 09 Nov 2002 22:58:42 -0700 (MST) Message-Id: <20021109.225842.28782696.imp@bsdimp.com> To: julian@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: bluetooth From: "M. Warner Losh" In-Reply-To: <20021110055316.4AA8E37B401@hub.freebsd.org> References: <20021109.213756.23012360.imp@bsdimp.com> <20021110055316.4AA8E37B401@hub.freebsd.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021110055316.4AA8E37B401@hub.freebsd.org> julian@FreeBSD.ORG (Julian Elischer) writes: : > : : > : The Netgraph stack is more an idea than code at this stage.. are you : oops, : I meant NETBSD!!! My fingers automatically typed the wrong ending.. OK. That makes more sense now. I was confused. Forget I said anything. It is clear that we should move forward with the bluetooth stack that's almost complete. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 22:12:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id 8945737B401; Sat, 9 Nov 2002 22:12:11 -0800 (PST) To: imp@bsdimp.com, julian@FreeBSD.ORG Subject: Re: bluetooth Cc: arch@FreeBSD.ORG In-Reply-To: <20021109.213756.23012360.imp@bsdimp.com> Message-Id: <20021110061211.8945737B401@hub.freebsd.org> Date: Sat, 9 Nov 2002 22:12:11 -0800 (PST) From: julian@FreeBSD.ORG (Julian Elischer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [note my quote corrected] > : > : > I'd go one step farther. I'd say that it would be insane to have more > : > than one bluetooth stack for FreeBSD. I'd go farther and say that it > : > would be insane to have more than one bluetooth stack for *BSD. > : > Bluetooth is too big and specailized for there to be much benefit in > : > competing stacks. > : > : The NetBSD stack is more an idea than code at this stage.. are you > : suggesting that we do not commit our working stack because they might > : sometime write a stack? > If the code is so horrible, why commit it at all? FreeBSD isn't a > dumping ground for any old code that people happen to come up with. Our code is not terrible on the contrary the Netgaph bluetooth code is really very clean I think. The NETBSD code is what doesn;t work yet. > You can't argue that we should commit it to FreeBSD, because it is > about ready and at the same time argue that the code sucks, so you > don't have to do any work. You can't have your cake and eat it too. > Either it is just about ready for prime time and you need to properly > integrate it into the tree, or it is an experimental hack that has no > business being in the tree. It can't be both. Oh for gods sake Warner.. I just misttyped NETGRAPH instead of NETBSD.. Your whole argulemt is about a typo so far. > I'm not suggesting that we shouldn't commit this code because NetBSD > might someday come up with a better stack. I'm saying that we need to > be open to sharing with NetBSD/OpenBSD. I'm saying that you need to > be open to integrating it completely into the tree. I'm saying that > we should make efforts to allow our NetBSD bretheren to pick up the > stack. There is a netgraph port for NetBSD. They haven't taken it because it wasn't in BSD4.4 (they are purists you know). I don't see why we shouldn't use appropriate technologies within FreeBSD just because NetBSD doesn't have them? > Didn't you read the rest of my post? FreeBSD has plenty of examples > where code was committed prematurely and then it rotted to > worthlessness. Sometimes this was because there were multiple similar > things in the tree, other times the original developer fell off the > face of the earth. In any event, it has caused us problems. This is not such a case. > BTW, looking at the stack it appears to me that this code is getting > close to being real enough for inclusion in the tree. Don't take my > comments above as thinking that code in question is horrible. I'm > just pointing out how contradictory your arguments are, which is why > people are giving you a hard time about how you want to integrate the > code. > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 9 22:16:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 508) id B1E0437B401; Sat, 9 Nov 2002 22:16:39 -0800 (PST) To: imp@bsdimp.com, julian@FreeBSD.ORG Subject: Re: bluetooth Cc: arch@FreeBSD.ORG In-Reply-To: <20021109.225842.28782696.imp@bsdimp.com> Message-Id: <20021110061639.B1E0437B401@hub.freebsd.org> Date: Sat, 9 Nov 2002 22:16:39 -0800 (PST) From: julian@FreeBSD.ORG (Julian Elischer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > : > : > : > : The Netgraph stack is more an idea than code at this stage.. are you > : oops, > : I meant NETBSD!!! My fingers automatically typed the wrong ending.. > > OK. That makes more sense now. I was confused. Forget I said > anything. It is clear that we should move forward with the bluetooth > stack that's almost complete. > OK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message