From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 02:14:19 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B7EF16A4DE for ; Sun, 9 Jul 2006 02:14:19 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB78643D45 for ; Sun, 9 Jul 2006 02:14:18 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002748567.msg for ; Sun, 09 Jul 2006 03:14:25 +0100 Message-ID: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Sun, 9 Jul 2006 03:13:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Sun, 09 Jul 2006 03:14:25 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Sun, 09 Jul 2006 03:14:26 +0100 Subject: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 02:14:19 -0000 My fight to get one of our machines stable after a disk failure continues. First it seems the raid / ide driver was causing issues due to too large a disk now I'm getting kernel panics after replacing the disk again with one of the same size. Kernel panic is as follows: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc93d049c fault code = superviser write, page not present instruction pointer = 0x20:0xc065d644 stack pointer = 0x29:0xe4f56b74 frame pointer = 0x29:0xe4f56b84 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres1, def32 1, dran 1 processor eflags = resume, IOPL = 0 current process = 15 (swi1: net) trap number = 12 panic: page fault cpuid = 1 Anyone got any ideas on this? This machine has been running 6.0 without issue for months. I'll post a dmesg when the machine has been restarted ( remote hands at the data center on that atm ). Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 03:03:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9754016A4DF for ; Sun, 9 Jul 2006 03:03:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73FFF43D46 for ; Sun, 9 Jul 2006 03:03:03 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002748657.msg for ; Sun, 09 Jul 2006 04:02:52 +0100 Message-ID: <000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk> Date: Sun, 9 Jul 2006 04:02:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Sun, 09 Jul 2006 04:02:52 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Sun, 09 Jul 2006 04:02:53 +0100 Cc: Subject: Re: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 03:03:04 -0000 Dmesg for machine: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE-p3 #0: Sun Jul 9 03:55:57 UTC 2006 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1266.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2147418112 (2047 MB) avail memory = 2100658176 (2003 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) fxp0: port 0xa000-0xa03f mem 0xf8141000-0xf8141fff,0xf8100000-0xf811ffff irq 18 at device 8.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:a2:e8:bd atapci0: port 0xa400-0xa407,0xa800-0xa803,0xac00-0xac07,0xb000-0xb003,0xb400-0xb43f mem 0xf8120000-0xf813ffff irq 18 at device 12.0 on pci0 ata2: on atapci0 ata3: on atapci0 fxp1: port 0xb800-0xb83f mem 0xf8140000-0xf8140fff,0xf8000000-0xf80fffff irq 19 at device 13.0 on pci0 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:30:48:41:53:f9 isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbc00-0xbc0f at device 17.1 on pci0 ata0: on atapci1 ata1: on atapci1 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xcc000-0xd67ff,0xd7000-0xdefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounters tick every 5.000 msec ad4: 114473MB at ata2-master UDMA100 ad5: 114473MB at ata2-slave UDMA100 ad6: 114473MB at ata3-master UDMA100 ad7: 114473MB at ata3-slave UDMA100 ar0: 228946MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (master) using ad5 at ata2-slave ar0: disk2 READY (mirror) using ad6 at ata3-master ar0: disk3 READY (mirror) using ad7 at ata3-slave SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ar0s1a N.B. Kernel that panic'ed was a pure 6.1-RELEASE SMP I've just patched it -p3 to be sure. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 03:09:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B927616A4E0 for ; Sun, 9 Jul 2006 03:09:06 +0000 (UTC) (envelope-from sjr@comcast.net) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5941643D49 for ; Sun, 9 Jul 2006 03:09:06 +0000 (GMT) (envelope-from sjr@comcast.net) Received: from istari.comcast.net (c-69-139-159-113.hsd1.md.comcast.net[69.139.159.113](misconfigured sender)) by comcast.net (rwcrmhc14) with ESMTP id <20060709030905m14009i051e>; Sun, 9 Jul 2006 03:09:05 +0000 Received: from istari.comcast.net (localhost [127.0.0.1]) by istari.comcast.net (8.13.6/8.13.6) with ESMTP id k6938ve2001029 for ; Sat, 8 Jul 2006 23:09:01 -0400 (EDT) (envelope-from sjr@istari.comcast.net) Message-Id: <200607090309.k6938ve2001029@istari.comcast.net> Date: Sat, 8 Jul 2006 23:08:57 -0400 (EDT) From: "Stephen J. Roznowski" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: Inconsistent snapshots? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 03:09:06 -0000 I'm running 6.1-STABLE on an AMD64 current as of a few minutes ago, and I've booted single user and done a fsck on the filesystems. I'm running the following commands: # mksnap_ffs /home /home/.snap/snapshot then # fsck_ffs /home/.snap/snapshot and I get the following errors: ** /home/.snap/snapshot (NO WRITE) ** Last Mounted on /home ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=1507564 (896 should be 864) CORRECT? no INCORRECT BLOCK COUNT I=1507565 (1184 should be 1152) CORRECT? no INCORRECT BLOCK COUNT I=1507566 (3104 should be 2976) CORRECT? no ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=1507560 OWNER=sjr MODE=100600 SIZE=18708 MTIME=Jul 8 22:56 2006 FILE LINKUP IN SNAPSHOT CLEAR? no UNREF FILE I=1507605 OWNER=sjr MODE=100600 SIZE=27571 MTIME=Jul 8 22:56 2006 FILE LINKUP IN SNAPSHOT CLEAR? no UNREF FILE I=1507606 OWNER=sjr MODE=100600 SIZE=38304 MTIME=Jul 8 22:56 2006 FILE LINKUP IN SNAPSHOT CLEAR? no UNREF FILE I=1507607 OWNER=sjr MODE=100600 SIZE=24545 MTIME=Jul 8 22:57 2006 FILE LINKUP IN SNAPSHOT CLEAR? no UNREF FILE I=1507608 OWNER=sjr MODE=100600 SIZE=18099 MTIME=Jul 8 22:57 2006 FILE LINKUP IN SNAPSHOT CLEAR? no ** Phase 5 - Check Cyl groups CANNOT ADJUST NUMBER OF FREE BLOCKS: -8 CONTINUE? [yn] n Othertimes when I run the same commands, I get a consistent snapshot. Am I doing something wrong? Thanks, -SR -- Stephen J. Roznowski (sjr@comcast.net) From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 04:40:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFA7916A4E0 for ; Sun, 9 Jul 2006 04:40:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D1643D45 for ; Sun, 9 Jul 2006 04:40:54 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k694dQfT009039; Sat, 8 Jul 2006 21:39:26 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k694dMa0009038; Sat, 8 Jul 2006 21:39:22 -0700 (PDT) (envelope-from sgk) Date: Sat, 8 Jul 2006 21:39:22 -0700 From: Steve Kargl To: Steven Hartland Message-ID: <20060709043922.GA9021@troutmask.apl.washington.edu> References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk> <000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 04:40:55 -0000 On Sun, Jul 09, 2006 at 04:02:12AM +0100, Steven Hartland wrote: > > N.B. Kernel that panic'ed was a pure 6.1-RELEASE SMP I've just > patched it -p3 to be sure. > Add debugging to your kernel and send a backtrace > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > Please remove this stupid disclaimer. You sent your email to a public mailing list. Not to mention, the disclaimer has no legal relevance. -- Steve From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 09:46:59 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F079916A504 for ; Sun, 9 Jul 2006 09:46:59 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4579943D46 for ; Sun, 9 Jul 2006 09:46:58 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k699krIR087758 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 9 Jul 2006 11:46:53 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k699kr4l087757 for hackers@freebsd.org; Sun, 9 Jul 2006 11:46:53 +0200 (CEST) Date: Sun, 9 Jul 2006 11:46:53 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060709094653.GA87677@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: gdb able to debug both fbsd and linux binaries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 09:47:00 -0000 hi, is it able to somehow make gdb be able to debug fbsd and linux binaries at the same time? I mean.. alter somehow the way its built in buildworld or something thnx roman ---------------------- www.liberalnistrana.cz From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 16:03:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD5B616A4DA for ; Sun, 9 Jul 2006 16:03:30 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F08443D45 for ; Sun, 9 Jul 2006 16:03:29 +0000 (GMT) (envelope-from jiashiun@gmail.com) Received: by ug-out-1314.google.com with SMTP id e2so490997ugf for ; Sun, 09 Jul 2006 09:03:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sCL1VOHyMoLCt4C/RIDrGs/PUtAsJO+PZd6dtTee/XKhqGxYX7pVPZ1lrKA7uO/mx3zioLYRVODWIPrLsPZfXc48IFoCbiXJOikjUgMYCANGGLKev6Czh2WW8t8SyIwwCy04Ek2o6j75CnHvWrOfHWfQ0guZHpLUKMzn756Fb+4= Received: by 10.78.136.7 with SMTP id j7mr1362613hud; Sun, 09 Jul 2006 09:03:28 -0700 (PDT) Received: by 10.78.120.3 with HTTP; Sun, 9 Jul 2006 09:03:28 -0700 (PDT) Message-ID: <1d6d20bc0607090903v77007d5erc432ef0345484628@mail.gmail.com> Date: Mon, 10 Jul 2006 00:03:28 +0800 From: "Jia-Shiun Li" To: "=?ISO-8859-1?Q?S=F8ren_Schmidt?=" In-Reply-To: <44AE23B6.7000607@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> <20060706195504.GA1252@freebie.xs4all.nl> <44AD7FF9.8010405@samsco.org> <20060706230808.GA55294@megan.kiwi-computer.com> <44AE23B6.7000607@freebsd.org> Cc: freebsd-hackers@freebsd.org, rick-freebsd@kiwi-computer.com Subject: Re: SATA300 Controllers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 16:03:30 -0000 On 7/7/06, S=F8ren Schmidt wrote: > Rick C. Petty wrote: > > I'm using a few "Promise PDC40718 SATA300 controller" with identical > > SATA300 drives and it seems to work well. My only gripe is the channel= s > > are misnumbered: > > port #1 maps to channel 3 > > port #2 maps to channel 1 > > port #3 maps to channel 0 > > port #4 maps to channel 2 > > > > I had to use the serial numbers to make sure I was writing on the corre= ct > > drives, so that was annoying. > > > Actually its the channel numbering printed on the card thats flawed, it > doesn't match the physical channel numbers that the chip uses (and hence > ATA channel numbers). > I have no idea why they did that on some of their controllers, but I > suspect historical reasons as they older controllers had the physical > connectors in that order (3 1 0 2), but the guy that did the silkscreen > layout probably ordered them "nicely" at some point :) Maybe they did it in order to be pin-compatible with older 20318 and 40518. On SATA150 TX4 (which used 20318) chip is directly connected to ports in parallel circuits but labeled in correct order (4, 2, 1, 3). On SATAII150 TX4 (40518) instead they 'worked around' switching the order in BIOS, windows and linux driver, and label the same ports as (1, 2, 3, 4). I did not know if this make any sense, since they sells most add-on cards with their own brand. Changing the board layout would be a lot easier and eliminate confusions. But if any OEM customers use these chips and did not notice odd channel order, it could be the only way to be backward 'compatible'. ;) In contrast it would be inconvenient to unofficial driver vendors like FreeBSD, which has a generic architecture for all ATA derivatives. Jia-Shiun. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 17:50:36 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A993816A580 for ; Sun, 9 Jul 2006 17:50:36 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3693643D45 for ; Sun, 9 Jul 2006 17:50:36 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so519791wri for ; Sun, 09 Jul 2006 10:50:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=peeKKn2T8Hin8mtxeeaRWz3tF74QFNz3ItnPfVmLSIo0Io/AdkWliUMpGQzMjfC2juS2nw9NOhzdOMU7lJyedqLmhM1fti5B+P99dcKg9RrBRXaxGJHyT+XzyFdpE0Zbeg/KeI83TNcblA/YbR/nG9fyLn3Oj+falCfaOHepmQU= Received: by 10.65.212.4 with SMTP id o4mr3918949qbq; Sun, 09 Jul 2006 10:50:35 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Sun, 9 Jul 2006 10:50:35 -0700 (PDT) Message-ID: Date: Sun, 9 Jul 2006 10:50:35 -0700 From: "Kip Macy" To: "Divacky Roman" In-Reply-To: <20060709094653.GA87677@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060709094653.GA87677@stud.fit.vutbr.cz> Cc: hackers@freebsd.org Subject: Re: gdb able to debug both fbsd and linux binaries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 17:50:36 -0000 They have quite different ptrace interfaces, the binaries will have different elf brands, etc. Making a single GDB work on both would require a great deal of FreeBSD specific surgery on GDB. -Kip On 7/9/06, Divacky Roman wrote: > hi, > > is it able to somehow make gdb be able to debug fbsd and linux binaries at the > same time? I mean.. alter somehow the way its built in buildworld or something > > thnx > > roman > > > ---------------------- > www.liberalnistrana.cz > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 23:26:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E1B116A4DD for ; Sun, 9 Jul 2006 23:26:25 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1A8943D45 for ; Sun, 9 Jul 2006 23:26:24 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002751206.msg for ; Mon, 10 Jul 2006 00:26:08 +0100 Message-ID: <001401c6a3ae$f9a142d0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk> <000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk> <20060709043922.GA9021@troutmask.apl.washington.edu> Date: Mon, 10 Jul 2006 00:25:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Mon, 10 Jul 2006 00:26:08 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 10 Jul 2006 00:26:09 +0100 Subject: Re: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 23:26:25 -0000 Steve Kargl wrote: > On Sun, Jul 09, 2006 at 04:02:12AM +0100, Steven Hartland wrote: >> >> N.B. Kernel that panic'ed was a pure 6.1-RELEASE SMP I've just >> patched it -p3 to be sure. >> > > Add debugging to your kernel and send a backtrace I've been trying to obtain one but am having no luck. These are the options of added to the kernel as well as enabling dump using dumpon="AUTO" in rc.conf: makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KTRACE # ktrace(1) support options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Unfortunately these are having some very strange results. With the above make -j8 buildworld now hangs using 100 of a processor at the following point: [hang 100%] mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc [/hang 100%] [top] PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1439 root 1 100 0 4620K 568K CPU1 0 5:02 99.17% cc1plus [/top] I know a dual 1.2Ghz PIII is not quick but after 10mins it should be done with this simple step. Other testing has shown that the crashes may be related to the RAID in 0+1. After the first crash the raid is in critical and from then no matter what I try I cant force the panic. > Please remove this stupid disclaimer. You sent your email to > a public mailing list. Not to mention, the disclaimer has no > legal relevance. Please ignore its added by the mail servers and doesnt even deserve commenting on, like most of the sigs you see on the list. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 23:50:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36DB016A4DA for ; Sun, 9 Jul 2006 23:50:15 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 722D643D5A for ; Sun, 9 Jul 2006 23:50:14 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002751270.msg for ; Mon, 10 Jul 2006 00:50:17 +0100 Message-ID: <004401c6a3b2$59bad340$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk><000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk><20060709043922.GA9021@troutmask.apl.washington.edu> <001401c6a3ae$f9a142d0$b3db87d4@multiplay.co.uk> Date: Mon, 10 Jul 2006 00:49:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Mon, 10 Jul 2006 00:50:17 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 10 Jul 2006 00:50:19 +0100 Subject: Re: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 23:50:15 -0000 Removing the following fixes the compile hang yet results in the array going offline with WRITE_DMA errors. options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN I'm rapidly coming to the conclusion there is something quite broken with driver support for 0+1 on this chipset ( Promise PDC20267 ). Steven Hartland wrote: > I've been trying to obtain one but am having no luck. > > These are the options of added to the kernel as well as > enabling dump using dumpon="AUTO" in rc.conf: > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > symbols > options KTRACE # ktrace(1) support > options KDB > options DDB > options GDB > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_SKIPSPIN > > Unfortunately these are having some very strange results. > With the above make -j8 buildworld now hangs using 100 of > a processor at the following point: > [hang 100%] > mkdep -f > .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include > -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/usr/src/gnu/usr.bin/gperf > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc [/hang > 100%] > > [top] > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND 1439 root 1 100 0 4620K 568K CPU1 0 5:02 > 99.17% cc1plus [/top] > > I know a dual 1.2Ghz PIII is not quick but after 10mins it should be > done with this simple step. > > Other testing has shown that the crashes may be related to > the RAID in 0+1. After the first crash the raid is in critical > and from then no matter what I try I cant force the panic. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 02:09:55 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73A9F16A4DA for ; Mon, 10 Jul 2006 02:09:55 +0000 (UTC) (envelope-from zb10948@oss.unist.hr) Received: from palunko.srce.hr (palunko.srce.hr [161.53.2.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBD643D49 for ; Mon, 10 Jul 2006 02:09:54 +0000 (GMT) (envelope-from zb10948@oss.unist.hr) Received: from cmung5680.cmu.carnet.hr (cmung5680.cmu.carnet.hr [193.198.150.92]) by palunko.srce.hr (8.13.7/8.13.6) with ESMTP id k6A25wwC024732 for ; Mon, 10 Jul 2006 04:05:59 +0200 (CEST) Date: Mon, 10 Jul 2006 04:09:15 -0700 To: freebsd-hackers@freebsd.org From: "zarko bulatovic" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.50 (Win32, build 7700) X-Scanned-By: MIMEDefang 2.55 on 161.53.2.67 Subject: FreeBSD MIDI support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 02:09:55 -0000 Are there any projects regarding this topic? I recently started coding kernel modules, however, there are some design issues involving "way" of MIDI implementation, so i hoped to contact somebody who's working on the same thing, or to join develop. team if there is any project underway. Anyways, the first dillema i have is about softsynth rendering, naturally early-stage drivers wouldn't use sc's onboard wavetables and their hardware means of MIDI rendering, so i would rather use software MIDI playback. Usage of hardware functionality should come later. The thing that bugs me, is it worth coding this inside of kernel module? Meaning that some /dev device inputs midi messages to kern.module, witch uses built-in software synthessis based on SF2 specification for MIDI rendering. There are already userland programs that do that, like timidiy and fluidsynth. Maybe it would be better to start on hardware functionalty at once, eg. pure device drivers that control soundcard's MIDI port, however, allaround kernel module should bring a decent degree of standardization. This is the way software MIDI is implemented on Windows and MacOSX, kernel mode rendering through software synthersizer (altrough i think they use DLS synthessis rather than SF2, but that really isnt important). So the question is, what is the best goal for MIDI on FreeBSD, a quickest way of controlling external synths/MIDI hardware (meaning ditch the software synth and set your mind on various hardware specs), or an all-around MIDI drivers providing playback without "3rd party" userland apps? Thank you in advance. Zarko Bulatovic From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 02:25:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 968DC16A4DA for ; Mon, 10 Jul 2006 02:25:10 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCFC143D45 for ; Mon, 10 Jul 2006 02:25:09 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002751823.msg for ; Mon, 10 Jul 2006 03:25:06 +0100 Message-ID: <002f01c6a3c7$f82b8960$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <000f01c6a2fd$51da1470$b3db87d4@multiplay.co.uk><000b01c6a304$1797aa50$b3db87d4@multiplay.co.uk><20060709043922.GA9021@troutmask.apl.washington.edu><001401c6a3ae$f9a142d0$b3db87d4@multiplay.co.uk> <004401c6a3b2$59bad340$b3db87d4@multiplay.co.uk> Date: Mon, 10 Jul 2006 03:24:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Mon, 10 Jul 2006 03:25:06 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 10 Jul 2006 03:25:07 +0100 Subject: Re: 6.1 kernel panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 02:25:10 -0000 Steven Hartland wrote: > Removing the following fixes the compile hang yet results > in the array going offline with WRITE_DMA errors. > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_SKIPSPIN > > I'm rapidly coming to the conclusion there is something quite > broken with driver support for 0+1 on this chipset ( Promise PDC20267 > ). Well that crash totally destoryed the array. / is missing loads of files including /etc and most of /lib so its a full reinstall time. I'd like to get 6.1 working but I may have to go back to something else like 5.4 if in fact that actually works, it may be that the machine has just not been under this type of load before. Soren or anyone anyone else got any ideas? N.B. I've a second machine which also died doing the same rsync so I'm fairly sure its just specific to the array setup + controller and not faulty hardware in anyway. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 04:00:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32B2516A500 for ; Mon, 10 Jul 2006 04:00:57 +0000 (UTC) (envelope-from brad.mailing@adam.com.au) Received: from levanto.mail.adnap.net.au (levanto.mail.adnap.net.au [203.6.132.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id CACF943D5C for ; Mon, 10 Jul 2006 04:00:56 +0000 (GMT) (envelope-from brad.mailing@adam.com.au) Received: from [219.90.130.151] (219-90-130-151.ip.adam.com.au [219.90.130.151]) by levanto.mail.adnap.net.au (Postfix) with ESMTP id CEEF25DF9 for ; Mon, 10 Jul 2006 13:30:54 +0930 (CST) Message-ID: <44B1D0F6.1050809@adam.com.au> Date: Mon, 10 Jul 2006 13:30:54 +0930 From: Brad Falzon User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: File Mirror Software X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 04:00:57 -0000 Hey guys, Currently, we're building our replacement file mirror box. (Its a beefy 5TB Server) Anyway, currently, we use the application 'mirror' to handle ftp mirrors and our own rsynctool which connects to a database for our rsync mirrors. However, this is beginning to be a pain, ie no reports are generated, hard to maintain etc. I was wondering if anybody has similar experiences and can recommend any software that could handle ftp and rsync mirrors better than our home grown scripts. I've spent along time researching this, but could never get a good enough google query. Simba seems to have much potential, however, being version 0.8 has more than its fair share of bugs at the moment. And the only other ftp mirror utility (weex) can only handle ftp mirrors, not rsync. Does anyone have any recommended ports that we should be looking into before making our final choice. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 07:18:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C92616A4DD; Mon, 10 Jul 2006 07:18:29 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E21A43D49; Mon, 10 Jul 2006 07:18:27 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from demon.hhp.local by mx.gfk.ru (MDaemon PRO v9.0.5) with ESMTP id md50000325619.msg; Mon, 10 Jul 2006 11:18:08 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jul 2006 11:18:02 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD MIDI support Thread-Index: AcajxisqVIS83SYvTHeccNc6Y178DwAIlGZA From: "Yuriy Tsibizov" To: "zarko bulatovic" , X-Spam-Processed: mx.gfk.ru, Mon, 10 Jul 2006 11:18:08 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.8 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDAV-Processed: mx.gfk.ru, Mon, 10 Jul 2006 11:18:09 +0400 Cc: freebsd-hackers@freebsd.org Subject: RE: FreeBSD MIDI support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 07:18:29 -0000 > Are there any projects regarding this topic? I recently=20 > started coding =20 > kernel modules, however, there are some design issues=20 > involving "way" of =20 > MIDI implementation, so i hoped to contact somebody who's=20 > working on the =20 > same thing, or to join develop. team if there is any project underway. MIDI support in HEAD does not have maintainer, and, as I know, noone was willing to continue its development. Hardware support is limited to two or three cards. If you know MIDI well, you can take this project in your hands. >=20 > Anyways, the first dillema i have is about softsynth=20 > rendering, naturally =20 > early-stage drivers wouldn't use sc's onboard wavetables and their =20 > hardware means of MIDI rendering, so i would rather use=20 > software MIDI =20 > playback. Usage of hardware functionality should come later.=20 > The thing =20 > that bugs me, is it worth coding this inside of kernel=20 > module? Meaning =20 > that some /dev device inputs midi messages to kern.module,=20 > witch uses =20 > built-in software synthessis based on SF2 specification for MIDI =20 > rendering. There are already userland programs that do that,=20 > like timidiy =20 > and fluidsynth.=20 I don't use this software right now, but if they can listen on a pipe = for MIDI sequence than kernel "softsynth" module will not be very useful for me. > Maybe it would be better to start on hardware=20 > functionalty =20 > at once, eg. pure device drivers that control soundcard's MIDI port, =20 > however, allaround kernel module should bring a decent degree of =20 > standardization. This is the way software MIDI is implemented=20 > on Windows =20 > and MacOSX, kernel mode rendering through software=20 > synthersizer (altrough =20 > i think they use DLS synthessis rather than SF2, but that=20 > really isnt =20 > important). So the question is, what is the best goal for=20 > MIDI on FreeBSD, =20 > a quickest way of controlling external synths/MIDI hardware=20 > (meaning ditch =20 > the software synth and set your mind on various hardware=20 > specs), It should work in -CURRENT, but supportred sound card list is short. It should be easy to add midi HW driver for your sound card, because MIDI I/O needs only to "put byte" and "get byte"/"get status" to & from=20 MIDI port. > or an all-around MIDI drivers providing playback without "3rd=20 > party" userland apps? Not shure about this... It will be very limited, because most consumer sound cards does not provide MIDI wavetable synthesizer acceleration. Yuriy. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 9 11:52:40 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADF2716A4DA for ; Sun, 9 Jul 2006 11:52:40 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F38F43D4C for ; Sun, 9 Jul 2006 11:52:39 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so492508wri for ; Sun, 09 Jul 2006 04:52:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=DME9TFEMojZ/vxSpHoCQeFmW5TEo2HwIchr4KdA7PIgBLG0Jt6w31uHMiQzccUUaHSHkftb1HSzs1HSPjunBjUC7+NBaacOLJ7cbbq6agkVIlCMqXhHn28SzLUJyZhRTn5bDUDNP0MR2AHCO290CbrEf8DTIjUw5wucGXGux8YQ= Received: by 10.65.213.14 with SMTP id p14mr3709093qbq; Sun, 09 Jul 2006 04:52:39 -0700 (PDT) Received: from kan.dnsalias.net ( [24.63.93.195]) by mx.gmail.com with ESMTP id q15sm2303070qbq.2006.07.09.04.52.37; Sun, 09 Jul 2006 04:52:38 -0700 (PDT) Date: Sun, 9 Jul 2006 07:52:32 -0400 From: Alexander Kabaev To: Divacky Roman Message-ID: <20060709075232.71750dfe@kan.dnsalias.net> In-Reply-To: <20060709094653.GA87677@stud.fit.vutbr.cz> References: <20060709094653.GA87677@stud.fit.vutbr.cz> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_mDCf.BaFNBmE6Rq/nNmv2ah"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Mailman-Approved-At: Mon, 10 Jul 2006 12:22:52 +0000 Cc: hackers@freebsd.org Subject: Re: gdb able to debug both fbsd and linux binaries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2006 11:52:40 -0000 --Sig_mDCf.BaFNBmE6Rq/nNmv2ah Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 9 Jul 2006 11:46:53 +0200 Divacky Roman wrote: > hi, >=20 > is it able to somehow make gdb be able to debug fbsd and linux > binaries at the same time? I mean.. alter somehow the way its built > in buildworld or something >=20 > thnx >=20 > roman > =20 > ---------------------- > www.liberalnistrana.cz Just use Linux gdb to debug Linux binaries. Unless something broke recently, it should work fine. --=20 Alexander Kabaev --Sig_mDCf.BaFNBmE6Rq/nNmv2ah Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEsO4EQ6z1jMm+XZYRAtFiAKCvewE6GK+/v9131eGcZU8HQV7m3gCgyjyv EMFBhlf6IjmXa9s24mNk33g= =98W/ -----END PGP SIGNATURE----- --Sig_mDCf.BaFNBmE6Rq/nNmv2ah-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 09:23:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEECD16A4EC; Mon, 10 Jul 2006 09:23:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 425B143D5C; Mon, 10 Jul 2006 09:23:34 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D4EC.dip.t-dialin.net [84.165.212.236]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k6A9EZQW096632; Mon, 10 Jul 2006 11:14:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k6A9NXM2092251; Mon, 10 Jul 2006 11:23:33 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 10 Jul 2006 11:23:33 +0200 Message-ID: <20060710112333.zb9ivxetuog4ows8@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 10 Jul 2006 11:23:33 +0200 From: Alexander Leidinger To: zarko bulatovic References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Mon, 10 Jul 2006 12:26:25 +0000 Cc: freebsd-hackers@freebsd.org, multimedia@freebsd.org Subject: Re: FreeBSD MIDI support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 09:23:40 -0000 Quoting zarko bulatovic (from Mon, 10 Jul 2006 =20 04:09:15 -0700): [CCing multimedia@, where more people interested in this topic listen] > Are there any projects regarding this topic? I recently started coding I'm not aware of one. > kernel modules, however, there are some design issues involving "way" > of MIDI implementation, so i hoped to contact somebody who's working on > the same thing, or to join develop. team if there is any project > underway. I just imported the old "new" midi code. It was not finished, but can =20 at least be used for some situations. Any patches which improve the =20 midi code are welcome. Bye, Alexander. The rest of the mail for the benefit of multimadia@: > Anyways, the first dillema i have is about softsynth rendering, > naturally early-stage drivers wouldn't use sc's onboard wavetables and > their hardware means of MIDI rendering, so i would rather use software > MIDI playback. Usage of hardware functionality should come later. The > thing that bugs me, is it worth coding this inside of kernel module? > Meaning that some /dev device inputs midi messages to kern.module, > witch uses built-in software synthessis based on SF2 specification for > MIDI rendering. There are already userland programs that do that, like > timidiy and fluidsynth. Maybe it would be better to start on hardware > functionalty at once, eg. pure device drivers that control soundcard's > MIDI port, however, allaround kernel module should bring a decent > degree of standardization. This is the way software MIDI is implemented > on Windows and MacOSX, kernel mode rendering through software > synthersizer (altrough i think they use DLS synthessis rather than SF2, > but that really isnt important). So the question is, what is the best > goal for MIDI on FreeBSD, a quickest way of controlling external > synths/MIDI hardware (meaning ditch the software synth and set your > mind on various hardware specs), or an all-around MIDI drivers > providing playback without "3rd party" userland apps? > > Thank you in advance. > Zarko Bulatovic > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --=20 Capital punishment means never having to say "YOU AGAIN?" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 14:09:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E00E16A4DF for ; Mon, 10 Jul 2006 14:09:31 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A1743D46 for ; Mon, 10 Jul 2006 14:09:30 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id C4DE5F1788 for ; Mon, 10 Jul 2006 22:09:35 +0800 (CST) X-KSVirus-check: 0 References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> In-Reply-To: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> From: mag@intron.ac To: "Joseph Koshy" Date: Mon, 10 Jul 2006 21:53:42 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152540567.99616@origin.intron.ac> Cc: freebsd-hackers@freebsd.org, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 14:09:31 -0000 Joseph Koshy wrote: > >> I would write my kernel module in C++, just like IOKit >> of OpenDarwin. Thus, all conflicts against C++ in current >> FreeBSD kernel source must be swept out firstly. > > Your patch is missing the following: > > - runtime support for static constructors and destructors > - runtime support for C++ exceptions > - support for RTTI > > Don't forget that these need to work in kernel modules > too. > > -- > FreeBSD Volunteer, http://people.freebsd.org/~jkoshy You are quite right. But those C++ features should be implemented step by step. Actually, Apple hasn't implemented all C++ features in Darwin/Mac OS X so far. See Apple's document: http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/chapter_2_section_6.html My original motivation to write FreeBSD kernel module in C++ is to create a more handy object model inside FreeBSD kernel. Naturally, I choose OpenDarwin's IOKit as an example. But I wouldn't consider it to be ideal, because it is still obscure to learn/master. I will implement C++ features you pointed one by one in the future. Especially for RTTI, I always regard virtual member function as part of C++'s soul. If you agree with me, please commit 4 patches in the following base64-encoded bzip2-ed tarball ("b64decode -p testcpp.b64|tar xjvf -"). ------------------------------------------------------------------------ From Beijing, China begin-base64 644 - QlpoOTFBWSZTWQQR74sAB/9/2NywAMh/f///f//fv///3/8EIAQAEAAACGAHvvj0cj0a9eh0PTQ6 D0AUIaaRTICYmEYgyaDJpoNGmnqMjINABoAAGgBqIFPIYJM1PQI2oxMmJgAACANDBGTBDTCBoUwE FDTQGmmhoAaAGQAAAAAAAA4GgNBo0DJoADQAGJoaaBpoAaNGgAaNBtSSnqeRoI0Bo0NB6QAAAAAA AGmg0ANBIkTQmTRoCCYATSZTZPRpQ2hhT1HqGmnqMnpqbSD00hk7AqBWkN0pVeqpRRHXwWQMOBoh CClgx0oXk/CkHuShIDICUgaVoawcmJQHxnzNYzTJRN/YHt9i0nb7ldbYmIZ7IUG4mLKxI64fN4s3 eCZ8Z+AEKxfizsIIJjKqogn3xExEKUAPvc3210ojMw2aIOrSxWzLNaUHKM/FF2M9Hg1OlnlOZMu6 pmdFbGPmnkrVr6ZE+mIasdoys+Uqyues5Ul1CX6RYwJZwogYHCHPr29n49p/bMoWgazxWctprus+ 3f6Js+B3Pcf7DHqoBWWsjzvvrmfQjd2BynE9i4hcXb8GRxKUHAeT8Cqga7ph0WC1A1cu2y21Vh3I mBIFSggzBPlgw5hSewj5hTZiKPgL7MQGlqhSB6QXKOQ/NdsRrXHHnlfTpzKtXfDBgwoxctNNJ8w8 +U7+JWqrUscWOu0u6csD09qR4HkIL7rqjwl5mttqWDteYa2yfy7FyBQ/buEsovSMp74KAVGWBsg/ K+A06YIiCQNKoZnAyjMePs196dA8niZYrL9IpE03GYXwbrUaCp3Eqkd1Tpaqx4colcmFXQBSA0xi GsdGrzm70cug5qclVXXVlriMYN9hYyp2bcRuvJQD8TzpG8klx50Ma6Wbsg1kipHuUzo28Ts10Ok5 TFaChzuWx8p4+/2gcTpfWS/ZjyAxol1BqRZVHfzdwm/Hvn1FYWbkfSiJcukRRXv0I5VgVaJoNcEh 11C/gEU0QSZZR+AzyauI8hisVPp9RInocpy7anDNJFDzZUHWkBhvxzucwn1kvAko7FwJKiHKDCFT 8sumy9tVChCAPLilfURGZLPWNSmRISouoqlEUoTSb3q5G+62AsSgj3QRGwCEFXimAQZJpIcSgQjj SNsCdyyOcuAgQ9lrZFthdJFZl3u4nlwoYYS9d1UmlfozVZ8BugUZFQpVpTnQCkiizY1FeNpJhbhL JOJ5ErKV1VOjA8xFhIpZbomLcNM7puMLgyYSvisqBlxSCuqzrb06cgXqymo9vl9hhhnZm/fkh3ma V8KUei5psexByJM8gCADTL40jfNQUVeKEgQBNQSrM1DdDUEIVqwHDPi/kIhHYhn/dnyR9ChmkPw+ Qjq9RbZbbErU/Ke89JMn955zHcnj6ff4veYl52iX+iZRPhGZCXv2lRB7z4fAmVV2DPpjNgHw9xvr zWHfD6+QrNejMymkmE7LWlgbcVnGVJ3BnsNfALKUMhZkINn3/P6Dj2Iv0mWC2ZoXdwGDwweksgID gckAKOnYZIRMLtETDJkwXlwHqINMCJG6g4wnkrFUZuXVQq8PgEcOBMXmPkLyWJMir64NRv5ygz/F Y2T2+XujpkoN+0ghP7C/MxWaImDocz8XxHkoI2k5UClIKLFN4TkSDdLhCyQyMli8ONx4WgqJJBSU nOL+BVNGgKP1/cs/pj61/YAhexfCCdDusl2YXEm0QM1hkZw1Z+mqSKxlZaWwf3LV6jrWnKjDo+Ud 2PSqw2oX6qFR5IHKsbLJkLw8nYZTf1LUJVMJuAYta4CZwbs1IWPAicrD2mB3jGDDZWjMDkTwkYDa USEyjpy16RUg4vtA9Ghb5yiqQqSEICIlERtKkDBWFyVZJajRgdWITCcHMqZQxLwPbIL5oXWXrMiz BHHsrOY+kOAC5nBBUI3VMOeYERwV5xZCoL8DcJc5tEro+4CgtIm81oxkHOYoFqRvXDIB2BxY8D1r Rl4+AkSLsgZwLDMMMuJYGwOeMoxrOIkS9W7CwWhpbuUJI+IA0BvGokrJMeqxInhImic4aiLRTT1Q IE+PSZLMoigpYpQylKEkkSLgM4XXWmwLDaZwmuSqrP4ssg0qM+4FslWhjZKD/ghwJsYpimhnjgDt WoskH6GFh6NBg50Blm/er2E0A7hwIGrFM84ta3dKSv3TSR20CZVvdSMoHCmpINSVy+mxuA5hb4X6 EuE8B3CQ21z9FSRknJV7PGKwNxRh9TLS+5JWmkNAAXiN5ZTQBb3ThSzhMpaoAgM+QJoZULZdw/OO EZCSyBQMwi4wTExnrSYVqrfKjKhkRVrCfVwqxV9rVvMcKtLqUygqBkqS1qrYTQrrwqUiVhpXYFlz edK9W7RohsYmNYqG4MxWbuenp0uAIGhQMmQTSdIX7FMZo2+61ahVfvJgKwLktHJ8Ca0BgmphQCoQ 1wy0otXGG+X/kWrKjn4RYI+dGCzH8Trn0AUvKLQi4JMGvzSuqXIaeItNHGiP2wDkSHIVRta/NKek Ci5VyrqZX4RsYcC8JwLp2iNIHEjAD4jAZBH9V6z0SJpVJp/rPog8E22+kL/F3JFOFCQBBHviwA== ==== From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 19:45:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2798516A4E2 for ; Mon, 10 Jul 2006 19:45:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE0B843D73 for ; Mon, 10 Jul 2006 19:45:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 10 Jul 2006 12:45:46 -0700 Message-ID: <44B2AE69.4080703@elischer.org> Date: Mon, 10 Jul 2006 12:45:45 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mag@intron.ac References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> In-Reply-To: <1152540567.99616@origin.intron.ac> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 19:45:50 -0000 mag@intron.ac wrote: > Joseph Koshy wrote: > >> >>> I would write my kernel module in C++, just like IOKit >>> of OpenDarwin. Thus, all conflicts against C++ in current >>> FreeBSD kernel source must be swept out firstly. >> >> While the idea of using C++ in the kernel made me very nervous, I have seen some places where an official subset might be useful. is it worth having a discussion about what features of C++ (or modular C) we would want to support and what would remain "illegal" in the kernel? Inherritance would be noce but there are traps.. e.g. How do you cope with classes depending on superclasses that may be from a different module and may have been compiled at a different time? (i.e. the base structure may have changed) > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 21:38:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92DF316A4E0 for ; Mon, 10 Jul 2006 21:38:54 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id E207443D49 for ; Mon, 10 Jul 2006 21:38:53 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (yjwwo46bklxrhv61@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k6ALcgW1041478; Mon, 10 Jul 2006 14:38:42 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k6ALcfTu041477; Mon, 10 Jul 2006 14:38:41 -0700 (PDT) (envelope-from jmg) Date: Mon, 10 Jul 2006 14:38:41 -0700 From: John-Mark Gurney To: Brad Falzon Message-ID: <20060710213841.GP734@funkthat.com> Mail-Followup-To: Brad Falzon , freebsd-hackers@freebsd.org References: <44B1D0F6.1050809@adam.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B1D0F6.1050809@adam.com.au> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: File Mirror Software X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 21:38:54 -0000 Brad Falzon wrote this message on Mon, Jul 10, 2006 at 13:30 +0930: > Currently, we're building our replacement file mirror box. (Its a beefy > 5TB Server) Anyway, currently, we use the application 'mirror' to handle > ftp mirrors and our own rsynctool which connects to a database for our > rsync mirrors. However, this is beginning to be a pain, ie no reports > are generated, hard to maintain etc. > > I was wondering if anybody has similar experiences and can recommend any > software that could handle ftp and rsync mirrors better than our home > grown scripts. > > I've spent along time researching this, but could never get a good > enough google query. > > Simba seems to have much potential, however, being version 0.8 has more > than its fair share of bugs at the moment. And the only other ftp mirror > utility (weex) can only handle ftp mirrors, not rsync. > > Does anyone have any recommended ports that we should be looking into > before making our final choice. If you're looking for software to do mirroring, I'd recommend you look at cvsup... Yes, this software is a general mirroring tool, and a few orders of a magnitude faster than rsync... It does have issues with really large files (like 2gb+) as the 10/15 minute timeout can be shorter than the time taken to generate a checksum for the file... Though w/ faster cpu's these days, it's probably no longer the case.. A number of years back, we used it to mirror 140GB of data between sites.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 21:41:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9180516A4DA for ; Mon, 10 Jul 2006 21:41:31 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id E889843D45 for ; Mon, 10 Jul 2006 21:41:30 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (nd7255lc3mp32f2y@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k6ALfUEW041544; Mon, 10 Jul 2006 14:41:30 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k6ALfTws041543; Mon, 10 Jul 2006 14:41:29 -0700 (PDT) (envelope-from jmg) Date: Mon, 10 Jul 2006 14:41:29 -0700 From: John-Mark Gurney To: zarko bulatovic Message-ID: <20060710214129.GQ734@funkthat.com> Mail-Followup-To: zarko bulatovic , freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD MIDI support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 21:41:31 -0000 zarko bulatovic wrote this message on Mon, Jul 10, 2006 at 04:09 -0700: > Are there any projects regarding this topic? I recently started coding > kernel modules, however, there are some design issues involving "way" of > MIDI implementation, so i hoped to contact somebody who's working on the > same thing, or to join develop. team if there is any project underway. I'd recommend doing minimal work in the kernel, and move the real work to userland.. When I wrote my HDTV capture card driver, I made the kernel just do enough to set bits, and handle the transfer (which requires writing a RISC program) and it works really well.. We are no longer in the age where we need the kernel to do everything for us... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 22:21:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC4E916A4DA for ; Mon, 10 Jul 2006 22:21:36 +0000 (UTC) (envelope-from V.Haisman@sh.cvut.cz) Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC27743D45 for ; Mon, 10 Jul 2006 22:21:33 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service.sh.cvut.cz (Postfix) with ESMTP id 44AF21A333C; Tue, 11 Jul 2006 00:21:32 +0200 (CEST) Received: from service.sh.cvut.cz ([127.0.0.1]) by localhost (service [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29039-03; Tue, 11 Jul 2006 00:21:29 +0200 (CEST) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (Postfix) with ESMTP id 09D0C1A3322; Tue, 11 Jul 2006 00:21:29 +0200 (CEST) Received: from [192.168.1.2] (localhost [127.0.0.1]) by logout.sh.cvut.cz (Postfix) with ESMTP id A72A961C4D; Tue, 11 Jul 2006 00:21:28 +0200 (CEST) Message-ID: <44B2D2DF.2000401@sh.cvut.cz> Date: Tue, 11 Jul 2006 00:21:19 +0200 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Julian Elischer References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> In-Reply-To: <44B2AE69.4080703@elischer.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=733031B4 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUnMzWJm5S+0864pn5r blp/hnW2up7X7uqftbNRVUrW1LGBdGfHwJqPi3ScoYtBQzhDxGEwAAAAB3RJTUUH1QoQDDgyQtx8 HQAAAkNJREFUeJzFU0toU0EUPYu66CpGdCUUmoUJkpUDQUoNBVEUrBJsq1Ki2EIKIUZ8mydBhYi0 wVUXJVCLCrFN4DIEQdxIqdBIFsMkWD9YJClCRGKjJaviynjfe8RPogtXPcObuXPOPXd+PHj+Aeyo QNmobGLXVeANGM+GsP0B2yqHHNVoCD2LwLglVGZx7yXSlADR0uZu9C4Bpy3hUxPvH/cuUw6UoPCL h64I8KAJuMpwRU8uUMJy0OIpHVeXmulZoCc/t0LlTbJLEY1EudPRcnVjgAP5Osdl4K5HVP4+2bAI okaUA0Iq6Q59+Zy2eMWN6EpFTsa3+uD1+JKj4TPHuYTSMaLScLAaqk94YJqG4ds30hojOVgYoNJc NTztNU2TBYbhu9Aafnq08ORja37da1NwBrN/b7NVEc+b8yecuYkp08vNvLYneVZRaSH1vS0UnfHm OUPzWaZufHPmCWSdWrfeGVQQKmcsO4If8pAdXJ/xF4QQAeOVY1AQQcfirwkLUWeWVTgi6vaGt2xe BGzBEIMQorru8RxgPqY1V6uxYnwVBRZEI1ytCm3dE8mC2DgcbzCJGHdBEVDKuWDSwsrSGoqzJmNt 2jJpNueIH0qS8/0JrDKnVBdvOzIsdVr4zaX9dn9xcLLKdCtQGfutVacLE9Ja+yfbDvO4aMWrklfK /JYv15C8Kw9S10kup5Bys0N1bLdcn4HvTl/Xlh6Fpllwj5/XpH9BUXn/ym0Dvv7Rt2MywojpYiSi i7Hsscaa19zZ//y/hR+BT/ns80nmJAAAAABJRU5ErkJggg== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig18E5729BA044AC2C766A8AE3" X-Virus-Scanned: by amavisd-new at sh.cvut.cz X-Spam-Status: No, hits=-5.9 tagged_above=-255.0 required=5.0 tests=ALL_TRUSTED, BAYES_00 X-Spam-Level: Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 22:21:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig18E5729BA044AC2C766A8AE3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Julian Elischer wrote, On 10.7.2006 21:45: > mag@intron.ac wrote: >=20 >> Joseph Koshy wrote: >> >>>> I would write my kernel module in C++, just like IOKit >>>> of OpenDarwin. Thus, all conflicts against C++ in current >>>> FreeBSD kernel source must be swept out firstly. >>> > While the idea of using C++ in the kernel made me very nervous, > I have seen some places where an official subset might be useful. > is it worth having a discussion about what features of C++ (or modular = C) > we would want to support and what would remain "illegal" in the kernel?= >=20 > Inherritance would be noce but there are traps.. e.g. > How do you cope with classes depending on superclasses that may be from= > a different > module and may have been compiled at a different time? > (i.e. the base structure may have changed) Binary compatibility is always a problem, no mater the language used. Besides, doesn't the FreeBSD kernel build system always compile all modul= es? Deciding that some features are bad beforehand, before you evaluate them is IMO bad idea. Let interested people write a bunch of C++ modules with the complete language before deciding on what shouldn't be used. My $0.05... -- Vaclav Haisman --------------enig18E5729BA044AC2C766A8AE3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRLLS6ENOZDESBK8FAQIFnwgAl72K3xCG+YWMSHXUm/e5ioVrB9JRFOnq iy9LDZRd4lN8TZ9ORGxwpIyXO0nKorNutL8EOA8/i71ETPSrZyQfvHRCKpk7YHtP aw+B4Qb2MO1+x+QQH0LjXEvk3bCo7qXTbQ9QxsFqrkp/cI4BMIlDNNbqaQzVI+41 0KVzw6CEbUh8cJFT/fpwj5dvIQUTYV6RUc0Q25RuCsEnjh2JoOjq/Oq4/n7iE7x2 hAHQVkBCxP/KL3pNRU+kacFRzheFN4F0TbVg4Rp8UYY1c5xwHo5j0j9+4QWtlXFt ugx0UlsXVIGHtgO4AttO3w93e9ZYbXAmolc8u+E/+3+20XnjLl0ltg== =0bFX -----END PGP SIGNATURE----- --------------enig18E5729BA044AC2C766A8AE3-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 10 22:27:17 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C74F16A4DA for ; Mon, 10 Jul 2006 22:27:17 +0000 (UTC) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2CF443D45 for ; Mon, 10 Jul 2006 22:27:16 +0000 (GMT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id BDB869B49B; Tue, 11 Jul 2006 07:57:15 +0930 (CST) Date: Tue, 11 Jul 2006 07:57:15 +0930 From: Greg 'groggy' Lehey To: Alexander Kabaev Message-ID: <20060710222715.GL1458@wantadilla.lemis.com> References: <20060709094653.GA87677@stud.fit.vutbr.cz> <20060709075232.71750dfe@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3xQkynibq3FKlJyM" Content-Disposition: inline In-Reply-To: <20060709075232.71750dfe@kan.dnsalias.net> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 VoIP: sip:0871270137@sip.internode.on.net WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Divacky Roman , hackers@freebsd.org Subject: Re: gdb able to debug both fbsd and linux binaries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 22:27:17 -0000 --3xQkynibq3FKlJyM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 9 July 2006 at 7:52:32 -0400, Alexander Kabaev wrote: > On Sun, 9 Jul 2006 11:46:53 +0200 > Divacky Roman wrote: > >> is it able to somehow make gdb be able to debug fbsd and linux >> binaries at the same time? I mean.. alter somehow the way its built >> in buildworld or something > > Just use Linux gdb to debug Linux binaries. Unless something broke > recently, it should work fine. This used to work, even for kernel debugging. If it doesn't any more, it's a regression. Greg -- See complete headers for address and phone numbers. --3xQkynibq3FKlJyM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEstRDIubykFB6QiMRAl72AJ95UxvS/1Ll+QOwuot2F6P+QVszbQCfRHxR t/4P8s7PRLugJg5JxkP3CC0= =Xy27 -----END PGP SIGNATURE----- --3xQkynibq3FKlJyM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 06:51:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B523B16A4DE for ; Tue, 11 Jul 2006 06:51:59 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33A0D43D46 for ; Tue, 11 Jul 2006 06:51:58 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C94CF2086; Tue, 11 Jul 2006 08:51:54 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id BA4FE2085; Tue, 11 Jul 2006 08:51:54 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 941C833C1F; Tue, 11 Jul 2006 08:51:54 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: =?iso-8859-1?Q?V=E1clav?= Haisman References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> Date: Tue, 11 Jul 2006 08:51:54 +0200 In-Reply-To: <44B2D2DF.2000401@sh.cvut.cz> (=?iso-8859-1?Q?V=E1clav?= Haisman's message of "Tue, 11 Jul 2006 00:21:19 +0200") Message-ID: <86sll8zl9x.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, Julian Elischer , mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 06:51:59 -0000 V=E1clav Haisman writes: > Deciding that some features are bad beforehand, before you evaluate > them is IMO bad idea. Let interested people write a bunch of C++ > modules with the complete language before deciding on what shouldn't > be used. It's not that simple. The complete language requires a ton of support code which must be written and tested. Are you volunteering to do that? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 08:27:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5074B16A4ED for ; Tue, 11 Jul 2006 08:27:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E7FB43DB1 for ; Tue, 11 Jul 2006 08:26:38 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 0F3ED2088; Tue, 11 Jul 2006 10:26:32 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id F31402087; Tue, 11 Jul 2006 10:26:31 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id B536033C1F; Tue, 11 Jul 2006 10:26:31 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: mag@intron.ac References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> Date: Tue, 11 Jul 2006 10:26:31 +0200 In-Reply-To: (mag@intron.ac's message of "Tue, 11 Jul 2006 16:13:48 +0800") Message-ID: <86fyh8zgw8.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, Julian Elischer Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 08:27:15 -0000 mag@intron.ac writes: > But prior to long-term discussion, please commit my 4 patches > firstly. They are nearly CPP-independent and do no harm to current > FreeBSD kernel. We don't do the kind of changes you propose without discussion. > --- kern.mk.orig Fri Jun 30 05:15:25 2006 > +++ kern.mk Mon Jul 10 18:42:43 2006 > @@ -88,7 +88,7 @@ > .if ${CC} =3D=3D "icc" > CFLAGS+=3D -nolib_inline > .else > -CFLAGS+=3D -ffreestanding > +CFLAGS+=3D -fno-builtin > .endif Are you sure this is correct? I'm pretty certain it isn't. The kernel's C environment is not a hosted implementation. > --- systm.h.orig Mon Jul 10 05:42:58 2006 > +++ systm.h Mon Jul 10 18:44:01 2006 > @@ -203,7 +203,7 @@ > int suword16(void *base, int word); > int suword32(void *base, int32_t word); > int suword64(void *base, int64_t word); > -intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t new); > +intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t __new__); This is a namespace violation. A simpler solution is to leave out argument names entirely. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 10:05:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B23716A4E0 for ; Tue, 11 Jul 2006 10:05:14 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D800B43D53 for ; Tue, 11 Jul 2006 10:05:08 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 515F3F1C73 for ; Tue, 11 Jul 2006 18:05:12 +0800 (CST) X-KSVirus-check: 0 References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> In-Reply-To: <86fyh8zgw8.fsf@xps.des.no> From: mag@intron.ac To: des@des.no Date: Tue, 11 Jul 2006 18:01:56 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152612305.19369@origin.intron.ac> Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, Julian Elischer Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 10:05:14 -0000 Dag-Erling [iso-8859-1] Sm grav wrote: > mag@intron.ac writes: >> But prior to long-term discussion, please commit my 4 patches >> firstly. They are nearly CPP-independent and do no harm to current >> FreeBSD kernel. > > We don't do the kind of changes you propose without discussion. > >> --- kern.mk.orig Fri Jun 30 05:15:25 2006 >> +++ kern.mk Mon Jul 10 18:42:43 2006 >> @@ -88,7 +88,7 @@ >> .if ${CC} == "icc" >> CFLAGS+= -nolib_inline >> .else >> -CFLAGS+= -ffreestanding >> +CFLAGS+= -fno-builtin >> .endif > > Are you sure this is correct? I'm pretty certain it isn't. The > kernel's C environment is not a hosted implementation. GCC manual page gcc(1) says: -ffreestanding Compile for a freestanding environment; this implies the `-fno- builtin' option, and implies that main has no special require- ments. GCC manual says: (http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C-Dialect-Options.html) -ffreestanding Assert that compilation takes place in a freestanding environment. This implies -fno-builtin. A freestanding environment is one in which the standard library may not exist, and program startup may not necessarily be at main. The most obvious example is an OS kernel. This is equivalent to -fno-hosted. But "-ffreestanding" doesn't work with C++. According to above explanation, "-fno-builtin" is a subset of "-ffreestanding" and it's enough for kernel. In /usr/src/contrib/gcc/c-opts.c, "-ffreestanding" is recognized as: case OPT_ffreestanding: value = !value; /* Fall through.... */ case OPT_fhosted: flag_hosted = value; flag_no_builtin = !value; /* warn_main will be 2 if set by -Wall, 1 if set by -Wmain */ if (!value && warn_main == 2) warn_main = 0; break; In /usr/src/contrib/gcc/c-decl.c, "-ffreestanding" takes effects as: if (MAIN_NAME_P (DECL_NAME (fndecl)) && flag_hosted) { if (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (fndecl))) != integer_type_node) { /* If warn_main is 1 (-Wmain) or 2 (-Wall), we have already warned. If warn_main is -1 (-Wno-main) we don't want to be warned. */ if (!warn_main) pedwarn ("%Jreturn type of '%D' is not `int'", fndecl, fndecl); } else { #ifdef DEFAULT_MAIN_RETURN /* Make it so that `main' always returns success by default. */ DEFAULT_MAIN_RETURN; #else if (flag_isoc99) c_expand_return (integer_zero_node); #endif } } >From above code we can conclude that "-ffreestanding" can affect only something about main() more than "-fno-builtin". I have compiled the whole FreeBSD kernel with "-fno-builtin" and met no problems. Now I am running the kernel with "-fno-builtin" to write to you with Linux ABI Mozilla-GTK1 1.7.12 and NVIDIA X11 driver 1.0-8762. > >> --- systm.h.orig Mon Jul 10 05:42:58 2006 >> +++ systm.h Mon Jul 10 18:44:01 2006 >> @@ -203,7 +203,7 @@ >> int suword16(void *base, int word); >> int suword32(void *base, int32_t word); >> int suword64(void *base, int64_t word); >> -intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t new); >> +intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t __new__); > > This is a namespace violation. A simpler solution is to leave out > argument names entirely. If the code style permits, I agree with you. GCC support library usually uses "namespace" to add various prefixes to its built-in functions/variables in order to avoid conflicts against user code. In ELF binary file, built-in functions/variables' names are much longer than "__new__". See files in /usr/src/contrib/libstdc++/libsupc++/. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 11:19:26 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 039D816A4DF for ; Tue, 11 Jul 2006 11:19:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 765EF43D46 for ; Tue, 11 Jul 2006 11:19:25 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 06E842083; Tue, 11 Jul 2006 13:19:19 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 795312082; Tue, 11 Jul 2006 13:19:18 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 3960233C1F; Tue, 11 Jul 2006 13:19:18 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: mag@intron.ac References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> Date: Tue, 11 Jul 2006 13:19:18 +0200 In-Reply-To: (mag@intron.ac's message of "Tue, 11 Jul 2006 18:01:56 +0800") Message-ID: <868xn0z8w9.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, Julian Elischer Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 11:19:26 -0000 mag@intron.ac writes: > But "-ffreestanding" doesn't work with C++. While the C++ standard does define hosted and freestanding implementations, its definition is different from (and less useful than) that in the C standard. For instance, the C++ standard requires the existence of abort(), atexit() and exit() even in a freestanding implementation. Basically, one cannot indiscriminately use the same compiler flags for C and C++, because they are very different languages - far more different than they seem on the surface. Modern C++ is very poorly suited for low-level code. > According to above explanation, "-fno-builtin" is a subset of > "-ffreestanding" and it's enough for kernel. No, it isn't. I think you would do wisely to acquire a little more knowledge of and experience with C, C++ and kernel programming before you pursue this topic any further. Most importantly, we already have an working object model in the FreeBSD kernel, with classes, inheritance, and all that jazz, implemented partly in C and partly in a custom IDL which is translated into C by src/sys/tools/makeobjops.awk. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 08:53:05 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C9816A4E1 for ; Tue, 11 Jul 2006 08:53:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8C4C43D45 for ; Tue, 11 Jul 2006 08:53:03 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 32709EB2357; Tue, 11 Jul 2006 16:52:56 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id K1IzR0Qp6+Yn; Tue, 11 Jul 2006 16:52:53 +0800 (CST) Received: from [10.217.12.96] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 9E32CEB231B; Tue, 11 Jul 2006 16:52:50 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type: organization:date:message-id:mime-version:x-mailer; b=Mf/QpqtXMqqmqIgHD8hkR8r6bwnN8lkFexmVEr0jI7Cf6jDVXI5IO6g8mp3T5i5e1 KHalurGqndD8mzbrFEAFQ== From: Xin LI To: mag@intron.ac In-Reply-To: References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-g2jNqYSpUv7auB1C2Vor" Organization: The FreeBSD Project Date: Tue, 11 Jul 2006 16:51:48 +0800 Message-Id: <1152607908.980.8.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port X-Mailman-Approved-At: Tue, 11 Jul 2006 11:22:17 +0000 Cc: des@des.no, Julian Elischer , freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 08:53:05 -0000 --=-g2jNqYSpUv7auB1C2Vor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2006-07-11=E4=BA=8C=E7=9A=84 16:13 +0800=EF=BC=8Cmag@intron.ac=E5= =86=99=E9=81=93=EF=BC=9A [...] > I agree with you. Firstly, we may keep up with OpenDarwin, just as > what's on >=20 > http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFu= ndamentals/Features/chapter_2_section_6.html=20 >=20 > At the same time, we may port/rewrite C++ support library for GNU CC or > Intel C++ Compiler step by step as we really need. >=20 > But prior to long-term discussion, please commit my 4 patches > firstly. They are nearly CPP-independent and do no harm to current > FreeBSD kernel. No. These patches are incomplete, see below. > --- kern.mk.orig Fri Jun 30 05:15:25 2006 > +++ kern.mk Mon Jul 10 18:42:43 2006 > @@ -88,7 +88,7 @@ > .if ${CC} =3D=3D "icc" > CFLAGS+=3D -nolib_inline > .else > -CFLAGS+=3D -ffreestanding > +CFLAGS+=3D -fno-builtin > .endif > =20 > .if ${CC} =3D=3D "icc" It is wrong to remove -ffreestanding here, at least for now. > --- libkern.h.orig Fri Oct 7 03:06:07 2005 > +++ libkern.h Mon Jul 10 18:50:23 2006 > @@ -115,7 +115,7 @@ > static __inline uint32_t > crc32_raw(const void *buf, size_t size, uint32_t crc) > { > - const uint8_t *p =3D buf; > + const uint8_t *p =3D (const uint8_t *) buf; > =20 > while (size--) > crc =3D crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8); This change hides an API problem here. We really should be more careful here. > --- systm.h.orig Mon Jul 10 05:42:58 2006 > +++ systm.h Mon Jul 10 18:44:01 2006 > @@ -203,7 +203,7 @@ > int suword16(void *base, int word); > int suword32(void *base, int32_t word); > int suword64(void *base, int64_t word); > -intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t new); > +intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t __new__); > =20 > void realitexpire(void *); __ is typically reserved for compilers. How can you assume that __new__ does not stand for a constructor in some compliers? Also the change would break the code consistency, and it is incomplete. I have take some time to investigate the kernel code and there are multiple instances of "new" as an identifier across the kernel source, and changing it here and leave others alone does not make the code better, IMHO. So, I think we should move the discussion to -arch@ and no change should be made until we have worked out a right way. Cheers, --=20 Xin LI http://www.delphij.net/ --=-g2jNqYSpUv7auB1C2Vor Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBEs2akhcUczkLqiksRAi9uAKDRyY+GVELhYdtzNLgn5btHeZdQpACfd2/O EfrXE4AUfdGPzX0Xpx6NMHs= =r/1F -----END PGP SIGNATURE----- --=-g2jNqYSpUv7auB1C2Vor-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 12:22:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6966B16A4DE for ; Tue, 11 Jul 2006 12:22:56 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E96E43D45 for ; Tue, 11 Jul 2006 12:22:55 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 11 Jul 2006 12:22:53 -0000 Received: from p509119C4.dip0.t-ipconnect.de (EHLO m2a2.dyndns.org) [80.145.25.196] by mail.gmx.net (mp035) with SMTP; 11 Jul 2006 14:22:53 +0200 X-Authenticated: #428038 Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 6CB5220057F; Tue, 11 Jul 2006 14:22:50 +0200 (CEST) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27073-12; Tue, 11 Jul 2006 14:22:47 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 5D4C5200690; Tue, 11 Jul 2006 10:38:37 +0200 (CEST) From: Matthias Andree To: =?iso-8859-15?Q?V=E1clav?= Haisman In-Reply-To: <44B2D2DF.2000401@sh.cvut.cz> (=?iso-8859-15?Q?V=E1clav?= Haisman's message of "Tue, 11 Jul 2006 00:21:19 +0200") References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Tue, 11 Jul 2006 10:38:37 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: amavisd-new at emma.line.org X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, Julian Elischer , mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 12:22:57 -0000 V=E1clav Haisman writes: > Binary compatibility is always a problem, no mater the language used. > Besides, doesn't the FreeBSD kernel build system always compile all > modules? It can be configured in make.conf if you want only a subset of modules. > Deciding that some features are bad beforehand, before you evaluate them > is IMO bad idea. Let interested people write a bunch of C++ modules with > the complete language before deciding on what shouldn't be used. No, that won't work -- plus you need a bunch of run-time support (libstdc++ isn't exactly something that belongs into the kernel you know). --=20 Matthias Andree From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 14:27:41 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55BA416A4DE for ; Tue, 11 Jul 2006 14:27:41 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9664843D6B for ; Tue, 11 Jul 2006 14:27:40 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lmrwvm@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6BERTXY079209; Tue, 11 Jul 2006 16:27:39 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6BERTNc079208; Tue, 11 Jul 2006 16:27:29 +0200 (CEST) (envelope-from olli) Date: Tue, 11 Jul 2006 16:27:29 +0200 (CEST) Message-Id: <200607111427.k6BERTNc079208@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, artifact.one@googlemail.com In-Reply-To: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 11 Jul 2006 16:27:39 +0200 (CEST) X-Mailman-Approved-At: Tue, 11 Jul 2006 14:30:09 +0000 Cc: Subject: Re: Stop further socket() or connect() calls. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 14:27:41 -0000 mal content wrote: > I was looking for a way to write a small wrapper program > that disables network access and then exec()'s a given > program. Sorry for the late reply, but ... The easiest way to do what you described is to run the program in a jail which has a jail IP that doesn't exist and isn't routed. Then the program cannot perform any network access. For example: jail / foo 127.0.0.2 /your/program All attempts to access the network should result in an error "no route to host" (errno EHOSTUNREACH). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 14:47:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1C7D16A4DA for ; Tue, 11 Jul 2006 14:47:28 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6AB843D67 for ; Tue, 11 Jul 2006 14:47:24 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 9F0E8F19B2 for ; Tue, 11 Jul 2006 22:47:30 +0800 (CST) X-KSVirus-check: 0 References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> In-Reply-To: <868xn0z8w9.fsf@xps.des.no> From: mag@intron.ac To: des@des.no Date: Tue, 11 Jul 2006 22:45:52 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152629241.24779@origin.intron.ac> Cc: freebsd-hackers@freebsd.org, Matthias Andree , delphij@delphij.net, Julian Elischer Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 14:47:28 -0000 Dag-Erling [iso-8859-1] Sm grav wrote: > mag@intron.ac writes: >> But "-ffreestanding" doesn't work with C++. > > While the C++ standard does define hosted and freestanding > implementations, its definition is different from (and less useful > than) that in the C standard. For instance, the C++ standard requires > the existence of abort(), atexit() and exit() even in a freestanding > implementation. > > Basically, one cannot indiscriminately use the same compiler flags for > C and C++, because they are very different languages - far more > different than they seem on the surface. Modern C++ is very poorly > suited for low-level code. Just as you said, C++ is more complicated than C. However, without C++ exception and other advanced features, it hasn't brought much complexity to C++ runtime library. Early C++ compiler even translates C++ code into C code before real compilation. We can judge whether a C++ feature can or cannot be imported into FreeBSD kernel by assemble code generated by GNU CC. For example, I think C++ exception handling is really poorly suited for low-level code. > >> According to above explanation, "-fno-builtin" is a subset of >> "-ffreestanding" and it's enough for kernel. > > No, it isn't. I think you would do wisely to acquire a little more > knowledge of and experience with C, C++ and kernel programming before > you pursue this topic any further. > > Most importantly, we already have an working object model in the > FreeBSD kernel, with classes, inheritance, and all that jazz, > implemented partly in C and partly in a custom IDL which is translated > into C by src/sys/tools/makeobjops.awk. Is the "object model" described in FreeBSD Architecture Handbook? (http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/kernel-objects.html) But the "object model" is still obscure to understand no matter how many people all over the world master C++. What's more, can the "object model" function really as OpenDarwin's IOKit class model? (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) Now, OpenDarwin has owned a C++-based kernel object model. But why cannot FreeBSD? > > DES > -- > Dag-Erling Sm grav - des@des.no > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on FreeBSD's actuality: so weak USB support (kernel crash easier than many other OSs that we laughed at and that we are laughing at), so weak PCI device support. But how difficult to write a device driver for FreeBSD? We have only incomplete FreeBSD documents, and we must search FreeBSD source code that probably has little relationship to the hardware device. If still confused, we must search Google and submit a question in mailing lists just like an ignorant pupil. A really terrible style of FreeBSD device driver is REPEATING so many codes similar to other device drivers. Please look at files in /sys/dev/usb/. Why do so many USB device drivers repeat: err = usbd_device2interface_handle( ... ); ... for( ... ) { ... ed = usbd_interface2endpoint_descriptor( ... ); ... } Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI device drivers repeat: pci_read_config( ... ) ... sc->vr_res = bus_alloc_resource_any( ... ); ... sc->vr_irq = bus_alloc_resource_any( ... ); ... Is this kind of awful writing just of FreeBSD's style? In contrast, with C++, we can avoid many code repeating among device drivers. Many USB/PCI driver need only override a member function like "OnUSBMatch()" and "OnPCIProbe()" to identify a deivce by Vendor/Product ID. After matching, in many device drivers, a default member function of base class like "OnUSBAttach()" or "OnPCIAttach()" can do attaching operations in the most common way. Most of driver writes needn't override default "OnXXXAttach()", and they can indicate its own IRQ, I/O address, USB bulk in/out pipe by some member variables like "m_nIRQ", "m_nIOAddr", "m_nUSBBulkIn" and "m_nUSBBulkOut", inherited from base class. Userland program may call read() and write() while device driver may simply submit/obtain a packet or a stream section to/from special member functions without concerning buffering or not, O_NONBLOCK or not, O_ASYNC or not. If we would have constructed an object model in C++, a programmer who master Microsoft MFC, Darwin I/O Kit could easily write a device drive with the device's hardware data sheet. At that time, FreeBSD can win support from hardware manufacturers more easily. You can LOOK DOWN UPON me again and again. But is it really your patent, a FreeBSD security team member's patent: you know what FreeBSD kernel and C++ is, but I am too BRAINLESS to understand FreeBSD kernel and C++? ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 14:57:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D85BD16A4DD for ; Tue, 11 Jul 2006 14:57:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 502C743D49 for ; Tue, 11 Jul 2006 14:57:15 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A3E292083; Tue, 11 Jul 2006 16:57:11 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 2B8C72082; Tue, 11 Jul 2006 16:57:11 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 0FED633C1F; Tue, 11 Jul 2006 16:57:11 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: mag@intron.ac References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> Date: Tue, 11 Jul 2006 16:57:10 +0200 In-Reply-To: (mag@intron.ac's message of "Tue, 11 Jul 2006 22:45:52 +0800") Message-ID: <86zmfg42bd.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthias Andree , delphij@delphij.net, Julian Elischer Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 14:57:17 -0000 mag@intron.ac writes: > Dag-Erling [iso-8859-1] Sm grav wrote: > >> mag@intron.ac writes: >>> But "-ffreestanding" doesn't work with C++. >> While the C++ standard does define hosted and freestanding >> implementations, its definition is different from (and less useful >> than) that in the C standard. For instance, the C++ standard requires >> the existence of abort(), atexit() and exit() even in a freestanding >> implementation. >> Basically, one cannot indiscriminately use the same compiler flags >> for >> C and C++, because they are very different languages - far more >> different than they seem on the surface. Modern C++ is very poorly >> suited for low-level code. > > Just as you said, C++ is more complicated than C. However, without > C++ exception and other advanced features, it hasn't brought much > complexity to C++ runtime library. Early C++ compiler even translates > C++ code into C code before real compilation. Several C++ compilers still do that, but that is irrelevant. What is relevant is the size and complexity of the runtime support library. > For example, I think C++ exception handling is really poorly suited for > low-level code. Exception handling is required by the standard, even for freestanding implementations. > Is the "object model" described in FreeBSD Architecture Handbook? > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/kernel-ob= jects.html) Yes. > But the "object model" is still obscure to understand no matter how many > people all over the world master C++. The fact that you don't understand it doesn't mean it's bad. > What's more, can the "object model" function really as OpenDarwin's > IOKit class model? Does it need to? > Now, OpenDarwin has owned a C++-based kernel object model. But why > cannot FreeBSD? Look, if you want MacOS X, you know where to find it. > Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on > FreeBSD's actuality: so weak USB support (kernel crash easier than many > other OSs that we laughed at and that we are laughing at), so weak PCI > device support. Please provide references to the PRs you filed about these issues. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 15:22:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF3FE16A4DD for ; Tue, 11 Jul 2006 15:22:47 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A74043D64 for ; Tue, 11 Jul 2006 15:22:47 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 4CC6235707 for ; Tue, 11 Jul 2006 17:22:43 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 223976CFD6; Tue, 11 Jul 2006 17:22:31 +0200 (CEST) Date: Tue, 11 Jul 2006 17:22:31 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20060711152231.GB1487@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <1152629241.24779@origin.intron.ac> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1152629241.24779@origin.intron.ac> User-Agent: Mutt/1.5.11 Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 15:22:48 -0000 On Tue, Jul 11, 2006 at 10:45:52PM +0800, mag@intron.ac wrote: > Just as you said, C++ is more complicated than C. However, without > C++ exception and other advanced features, it hasn't brought much > complexity to C++ runtime library. Early C++ compiler even translates > C++ code into C code before real compilation. RTTI, allocation, exceptions and static allocators all add complexity for the runtime library. If you really want to use C++ for a kernel, you must likely want to use all of them as well. > For example, I think C++ exception handling is really poorly suited for > low-level code. Bullshit. With a proper implementation exceptions add no overhead as long an exception is not thrown in terms of speed. It does matter somewhat in terms of code (or better: data) size, but the very same information is useful to generate much better tracebacks as well. RTTI is highly useful for debugging and semi-optional consistent checks, which should not be neglected either. I don't care about the abuse of explicitly comparing object types etc., but the ability to decide what exactly a certain object is. > But the "object model" is still obscure to understand no matter how many > people all over the world master C++. What's more, can the "object model" > function really as OpenDarwin's IOKit class model? > (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) The kobj implementation has the same feature set as a lightweight C++, e.g. inheritance and virtual functions. That's basically what IOKit is using as well. It is not obscure, just a Domain Specific Language. > Now, OpenDarwin has owned a C++-based kernel object model. But why > cannot FreeBSD? Because the kernel is C and not many points to incrementally add C++ have been made, which makes it a worthwhile goal. And if you want to complain about redundancy in drivers, carefully look for differences which often far outweight the common functionality. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 15:24:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 553EB16A4E0 for ; Tue, 11 Jul 2006 15:24:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93FE643D6D for ; Tue, 11 Jul 2006 15:24:55 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6BFO4N3075157; Tue, 11 Jul 2006 11:24:04 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 11 Jul 2006 11:15:58 -0400 User-Agent: KMail/1.9.1 References: <200607092136.k69LaNDX055391@www.freebsd.org> <86zmfg42bd.fsf@xps.des.no> In-Reply-To: <86zmfg42bd.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607111115.59844.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 11 Jul 2006 11:24:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1591/Mon Jul 10 15:41:02 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Matthias Andree , delphij@delphij.net, Julian Elischer , mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 15:24:56 -0000 On Tuesday 11 July 2006 10:57, Dag-Erling Sm=F8rgrav wrote: > > For example, I think C++ exception handling is really poorly suited for > > low-level code. >=20 > Exception handling is required by the standard, even for freestanding > implementations. Standards aside, in Darwin, the C++ Apple uses does not have any exception handling or RTTI (and maybe not even templates). They use their own set of meta classes to implement an RTTI-like system that allows for future changes in the ABI. You would also benefit from doing some of your own research. > > But the "object model" is still obscure to understand no matter how many > > people all over the world master C++. >=20 > The fact that you don't understand it doesn't mean it's bad. No, but it is obtuse. And very underused. How many device drivers do you know of that use kobj inheritance? > > What's more, can the "object model" function really as OpenDarwin's > > IOKit class model? >=20 > Does it need to? He's trying to port IOKit to FreeBSD for his exercise (if you had read his first e-mail you'd know that). > > Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on > > FreeBSD's actuality: so weak USB support (kernel crash easier than many > > other OSs that we laughed at and that we are laughing at), so weak PCI > > device support. >=20 > Please provide references to the PRs you filed about these issues. USB crashes are not that uncommon, and compared to other OS's (such as Wind= ows=20 and OS X both of which I've written a PCI driver for) we require device=20 driver writers to go through a lot more hoops to do certain things like=20 allocate resources. At the very least there is much that can be improved i= n=20 our driver model. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 15:29:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6D0516A4DF for ; Tue, 11 Jul 2006 15:29:54 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 9BC0643D77 for ; Tue, 11 Jul 2006 15:29:53 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 11 Jul 2006 15:29:51 -0000 Received: from p509119C4.dip0.t-ipconnect.de (EHLO m2a2.dyndns.org) [80.145.25.196] by mail.gmx.net (mp010) with SMTP; 11 Jul 2006 17:29:51 +0200 X-Authenticated: #428038 Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id BE0FB200580; Tue, 11 Jul 2006 17:29:50 +0200 (CEST) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02273-15; Tue, 11 Jul 2006 17:29:49 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 19565200DC4; Tue, 11 Jul 2006 17:29:49 +0200 (CEST) Date: Tue, 11 Jul 2006 17:29:49 +0200 From: Matthias Andree To: mag@intron.ac Message-ID: <20060711152949.GB1463@merlin.emma.line.org> References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11-2006-07-09 X-Virus-Scanned: amavisd-new at emma.line.org X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 15:29:55 -0000 (please don't Cc me on list replies; chopping down the Cc list) On Tue, 11 Jul 2006, mag@intron.ac wrote: > Just as you said, C++ is more complicated than C. However, without > C++ exception and other advanced features, it hasn't brought much > complexity to C++ runtime library. Early C++ compiler even translates > C++ code into C code before real compilation. But what's the point of C++ if it is mutilated below minimum standard compliance levels so that you can no longer call it C++? This discussion has been through for other systems such as Linux long ago, and it wasn't lack of manpower, but lack of technical feasibility, or in other words, what was still useful for a kernel wasn't that much different from C any more. C99 already adressed several concerns of C89, and ISTR that FreeBSD kernels are C99 code these days. > We can judge whether a C++ feature can or cannot be imported into FreeBSD > kernel by assemble code generated by GNU CC. Great, make the whole kernel depend on compiler internals. Can you imagine a single vendor who'd have interest in hauling so many dependencies into their software and handle all the support? I can't. Write a C stub and put the rest into userspace where C++ works. > For example, I think C++ exception handling is really poorly suited for > low-level code. Which chops off one of C++'s legs to stand on. > Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on > FreeBSD's actuality: so weak USB support (kernel crash easier than many > other OSs that we laughed at and that we are laughing at), so weak PCI > device support. Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT) with Linux and plugged TWO devices into it and see Linux fail to talk to the device you plugged in later? No? If so, you have zero clue how bad USB support can get. And that's not the only problem Linux USB has had or still has. > Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI > device drivers repeat: > > pci_read_config( ... ) > ... > sc->vr_res = bus_alloc_resource_any( ... ); > ... > sc->vr_irq = bus_alloc_resource_any( ... ); > ... > > Is this kind of awful writing just of FreeBSD's style? > > In contrast, with C++, we can avoid many code repeating among device > drivers. How would C++ avoid such? Generic programming, RTTI support and such stuff requires an awful lot of compile-time code generation and runtime library support. > If we would have constructed an object model in C++, a programmer who > master Microsoft MFC, Darwin I/O Kit could easily write a device drive > with the device's hardware data sheet. And errata, and talking to the device happens in C-like programming anyways... -- Matthias Andree From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 16:14:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23F9616A4DA for ; Tue, 11 Jul 2006 16:14:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD45843D55 for ; Tue, 11 Jul 2006 16:14:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BGDtai043185; Tue, 11 Jul 2006 10:13:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 10:14:03 -0600 (MDT) Message-Id: <20060711.101403.-928138940.imp@bsdimp.com> To: V.Haisman@sh.cvut.cz From: "M. Warner Losh" In-Reply-To: <44B2D2DF.2000401@sh.cvut.cz> References: <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 10:13:56 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, julian@elischer.org, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 16:14:57 -0000 In message: <44B2D2DF.2000401@sh.cvut.cz> V=E1clav Haisman writes: : Deciding that some features are bad beforehand, before you evaluate t= hem : is IMO bad idea. Let interested people write a bunch of C++ modules w= ith : the complete language before deciding on what shouldn't be used. There's actually a fair amount of experience with people doing C++ in FreeBSD kernels. People have been doing things with it for about 8 years now. There are significant performance issues with even C code compiled as C++. It is possible to write fast C++ for kernel work, but it is also very easy to write really bad C++ for kernel work. Easier than bad C code. There's reasons that people here are somewhat skeptical about using C++ in the kernel. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 16:18:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E3116A4DD for ; Tue, 11 Jul 2006 16:18:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D8B43D72 for ; Tue, 11 Jul 2006 16:18:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BGGJYc043228; Tue, 11 Jul 2006 10:16:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 10:16:28 -0600 (MDT) Message-Id: <20060711.101628.1678774797.imp@bsdimp.com> To: mag@intron.ac From: "M. Warner Losh" In-Reply-To: <1152612305.19369@origin.intron.ac> References: <86fyh8zgw8.fsf@xps.des.no> <1152612305.19369@origin.intron.ac> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 10:16:20 -0600 (MDT) Cc: des@des.no, delphij@delphij.net, julian@elischer.org, freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 16:18:03 -0000 In message: <1152612305.19369@origin.intron.ac> mag@intron.ac writes: : >> --- systm.h.orig Mon Jul 10 05:42:58 2006 : >> +++ systm.h Mon Jul 10 18:44:01 2006 : >> @@ -203,7 +203,7 @@ : >> int suword16(void *base, int word); : >> int suword32(void *base, int32_t word); : >> int suword64(void *base, int64_t word); : >> -intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t new); : >> +intptr_t casuptr(intptr_t *p, intptr_t old, intptr_t __new__); : > : > This is a namespace violation. A simpler solution is to leave out : > argument names entirely. : : If the code style permits, I agree with you. : : GCC support library usually uses "namespace" to add various prefixes : to its built-in functions/variables in order to avoid conflicts against : user code. In ELF binary file, built-in functions/variables' names are : much longer than "__new__". See files in : /usr/src/contrib/libstdc++/libsupc++/. __new__ is bogus. _new if you must. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 16:34:06 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46FE416A4DE for ; Tue, 11 Jul 2006 16:34:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C206B43D82 for ; Tue, 11 Jul 2006 16:33:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BGVsfw043396; Tue, 11 Jul 2006 10:31:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 10:32:03 -0600 (MDT) Message-Id: <20060711.103203.635732778.imp@bsdimp.com> To: mag@intron.ac From: "M. Warner Losh" In-Reply-To: <1152629241.24779@origin.intron.ac> References: <868xn0z8w9.fsf@xps.des.no> <1152629241.24779@origin.intron.ac> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 10:31:54 -0600 (MDT) Cc: des@des.no, matthias.andree@gmx.de, delphij@delphij.net, julian@elischer.org, freebsd-hackers@FreeBSD.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 16:34:06 -0000 In message: <1152629241.24779@origin.intron.ac> mag@intron.ac writes: : You can LOOK DOWN UPON me again and again. But is it really your patent, : a FreeBSD security team member's patent: you know what FreeBSD kernel : and C++ is, but I am too BRAINLESS to understand FreeBSD kernel and C++? I don't think anybody thinks you are brainless to understand kernel and C++. Many people here have actually done C++ experiements with the FreeBSD kernel, and to date those experiments have all failed badly. If you'd like to do such an experiment yourself, please by all means feel free. When you have more experimental evidence to support the claims you are making, we'd love to see it. However, given then extreme pain than many of the kernel developers have had with C++ in the kernel, the burdon of proof will be on those advocating C++ as being better proving with real code their assertions. As to your other points, the resource allocation repetition has been improved with bus_alloc_resources. the trouble is that many drivers haven't been converted to use the new api. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 16:35:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5FE916A597 for ; Tue, 11 Jul 2006 16:35:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 684D843D6A for ; Tue, 11 Jul 2006 16:35:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BGXIcx043446; Tue, 11 Jul 2006 10:33:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 10:33:27 -0600 (MDT) Message-Id: <20060711.103327.-8650905.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200607111115.59844.jhb@freebsd.org> References: <86zmfg42bd.fsf@xps.des.no> <200607111115.59844.jhb@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 10:33:18 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, mag@intron.ac, matthias.andree@gmx.de, julian@elischer.org, des@des.no, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 16:35:59 -0000 In message: <200607111115.59844.jhb@freebsd.org> John Baldwin writes: : and OS X both of which I've written a PCI driver for) we require device : driver writers to go through a lot more hoops to do certain things like : allocate resources. At the very least there is much that can be improved in : our driver model. bus_alloc_resources goes a long ways in this respect. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 16:45:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E77016A4E2 for ; Tue, 11 Jul 2006 16:45:53 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp2.263.net (263.net.cn [211.150.96.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 574CB43D45 for ; Tue, 11 Jul 2006 16:45:52 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp2.263.net (Postfix) with ESMTP id A6126229945 for ; Wed, 12 Jul 2006 00:45:51 +0800 (CST) X-KSVirus-check: 0 References: <200607092136.k69LaNDX055391@www.freebsd.org> <86zmfg42bd.fsf@xps.des.no> <200607111115.59844.jhb@freebsd.org> In-Reply-To: <200607111115.59844.jhb@freebsd.org> From: mag@intron.ac To: John Baldwin Date: Wed, 12 Jul 2006 00:43:43 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152636351.27575@origin.intron.ac> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 16:45:53 -0000 John Baldwin wrote: > On Tuesday 11 July 2006 10:57, Dag-Erling Sm grav wrote: >> > For example, I think C++ exception handling is really poorly suited for >> > low-level code. >> >> Exception handling is required by the standard, even for freestanding >> implementations. > > Standards aside, in Darwin, the C++ Apple uses does not have any exception > handling or RTTI (and maybe not even templates). They use their own set of > meta classes to implement an RTTI-like system that allows for future changes > in the ABI. You would also benefit from doing some of your own research. Yeah. Besides inspection to OpenDarwin, my motivation comes from my inspection to assemble code generated by GNU CC. Many object-oriented directives have been implemented in .o file by compiler. > >> > But the "object model" is still obscure to understand no matter how many >> > people all over the world master C++. >> >> The fact that you don't understand it doesn't mean it's bad. > > No, but it is obtuse. And very underused. How many device drivers do you > know of that use kobj inheritance? Of course many (with bus_if.h and device_if.h generated). But if I am writing a member function, I am not enough grammartically prompted that it belongs to a class. What I see is a C function pointer list (static device_method_t). And when I access a context-specific variable in a member function, I must write variable name "sc->XXX" after obtain the context pointer. > >> > What's more, can the "object model" function really as OpenDarwin's >> > IOKit class model? >> >> Does it need to? > > He's trying to port IOKit to FreeBSD for his exercise (if you had read his > first e-mail you'd know that). You're somewhat right. Now, I would only submit some MINOR patches to FreeBSD, only to sweep out some conflicts against C++ language. These patches are also irrelevant to C++ runtime library. There patches do ABSOLUTELY NO HARM to current FreeBSD kernel. Before I do enough experiments, naturally I would never talk about this thing. I don't know why Dag-Erling C. Smo/rgrav is so unfriendly to me ??? !!! > >> > Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on >> > FreeBSD's actuality: so weak USB support (kernel crash easier than many >> > other OSs that we laughed at and that we are laughing at), so weak PCI >> > device support. >> >> Please provide references to the PRs you filed about these issues. > > USB crashes are not that uncommon, and compared to other OS's (such as Windows > and OS X both of which I've written a PCI driver for) we require device > driver writers to go through a lot more hoops to do certain things like > allocate resources. At the very least there is much that can be improved in > our driver model. If manufactures would write FreeBSD driver itself, they must do their best, just as NVIDIA. We should provide a good kernel environment for them. But now some FreeBSD drivers by volunteers, even expert at FreeBSD, are somewhat rough. > > -- > John Baldwin ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 16:46:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B329016A4FC; Tue, 11 Jul 2006 16:46:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF2A343D45; Tue, 11 Jul 2006 16:46:34 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E44072086; Tue, 11 Jul 2006 18:46:29 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id B71272082; Tue, 11 Jul 2006 18:46:28 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 8F59D33C1F; Tue, 11 Jul 2006 18:46:28 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: John Baldwin References: <200607092136.k69LaNDX055391@www.freebsd.org> <86zmfg42bd.fsf@xps.des.no> <200607111115.59844.jhb@freebsd.org> Date: Tue, 11 Jul 2006 18:46:28 +0200 In-Reply-To: <200607111115.59844.jhb@freebsd.org> (John Baldwin's message of "Tue, 11 Jul 2006 11:15:58 -0400") Message-ID: <86ejwsqecb.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthias Andree , delphij@delphij.net, Julian Elischer , mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 16:46:52 -0000 John Baldwin writes: > On Tuesday 11 July 2006 10:57, Dag-Erling Sm=F8rgrav wrote: > > mag@intron.ac writes: > > > What's more, can the "object model" function really as OpenDarwin's > > > IOKit class model? > > Does it need to? > He's trying to port IOKit to FreeBSD for his exercise (if you had read his > first e-mail you'd know that). I saw no such thing in his first email, nor in any of his subsequent messages; all I see is variations on "FreeBSD sucks, but luckily for you I'm here to tell you how to fix it" which is not going to fly. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 17:41:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDF2C16A4DF for ; Tue, 11 Jul 2006 17:41:00 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C6B443D5C for ; Tue, 11 Jul 2006 17:40:59 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id C7846F1840 for ; Wed, 12 Jul 2006 01:40:58 +0800 (CST) X-KSVirus-check: 0 References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <1152629241.24779@origin.intron.ac> <20060711152231.GB1487@britannica.bec.de> In-Reply-To: <20060711152231.GB1487@britannica.bec.de> From: mag@intron.ac To: Joerg Sonnenberger Date: Wed, 12 Jul 2006 01:40:01 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152639658.28572@origin.intron.ac> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 17:41:01 -0000 Joerg Sonnenberger wrote: > On Tue, Jul 11, 2006 at 10:45:52PM +0800, mag@intron.ac wrote: >> Just as you said, C++ is more complicated than C. However, without >> C++ exception and other advanced features, it hasn't brought much >> complexity to C++ runtime library. Early C++ compiler even translates >> C++ code into C code before real compilation. > > RTTI, allocation, exceptions and static allocators all add complexity > for the runtime library. If you really want to use C++ for a kernel, you > must likely want to use all of them as well. > >> For example, I think C++ exception handling is really poorly suited for >> low-level code. > > Bullshit. With a proper implementation exceptions add no overhead as > long an exception is not thrown in terms of speed. It does matter > somewhat in terms of code (or better: data) size, but the very same > information is useful to generate much better tracebacks as well. > RTTI is highly useful for debugging and semi-optional consistent checks, > which should not be neglected either. I don't care about the abuse of > explicitly comparing object types etc., but the ability to decide what > exactly a certain object is. Aside from the complexity of C++ exception support, in FreeBSD kernel, every exception must be carefully processed, simple exception throw and catch may lay memory leak and resource non-freeing inside kernel if the programmer fails to pay enough attention. Even if C++ code is carefully written for FreeBSD kernel, outer exception catch is so difficult to help deep inner exception. > >> But the "object model" is still obscure to understand no matter how many >> people all over the world master C++. What's more, can the "object model" >> function really as OpenDarwin's IOKit class model? >> (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) > > The kobj implementation has the same feature set as a lightweight C++, > e.g. inheritance and virtual functions. That's basically what IOKit is > using as well. It is not obscure, just a Domain Specific Language. A domain specific language, C function pointer list, software context and other independent kernel functions are obscure enough for FreeBSD newbies. > >> Now, OpenDarwin has owned a C++-based kernel object model. But why >> cannot FreeBSD? > > Because the kernel is C and not many points to incrementally add C++ > have been made, which makes it a worthwhile goal. > > And if you want to complain about redundancy in drivers, carefully look > for differences which often far outweight the common functionality. If there's only small differences, there operations can be packed into a function tunable by some arguments. > > Joerg > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 17:06:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC4016A4DD for ; Tue, 11 Jul 2006 17:06:41 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (smtp.x263.net [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B516043D6D for ; Tue, 11 Jul 2006 17:06:40 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id A0901F16A1 for ; Wed, 12 Jul 2006 01:06:39 +0800 (CST) X-KSVirus-check: 0 References: <200607092136.k69LaNDX055391@www.freebsd.org> <86zmfg42bd.fsf@xps.des.no> <200607111115.59844.jhb@freebsd.org> <86ejwsqecb.fsf@xps.des.no> In-Reply-To: <86ejwsqecb.fsf@xps.des.no> From: mag@intron.ac To: des@des.no Date: Wed, 12 Jul 2006 01:05:10 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152637599.28035@origin.intron.ac> X-Mailman-Approved-At: Tue, 11 Jul 2006 18:10:41 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 17:06:41 -0000 Dag-Erling [iso-8859-1] Sm grav wrote: > John Baldwin writes: >> On Tuesday 11 July 2006 10:57, Dag-Erling Sm grav wrote: >> > mag@intron.ac writes: >> > > What's more, can the "object model" function really as OpenDarwin's >> > > IOKit class model? >> > Does it need to? >> He's trying to port IOKit to FreeBSD for his exercise (if you had read his >> first e-mail you'd know that). > > I saw no such thing in his first email, nor in any of his subsequent > messages; all I see is variations on "FreeBSD sucks, but luckily for > you I'm here to tell you how to fix it" which is not going to fly. > > DES > -- > Dag-Erling Sm grav - des@des.no > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Can you mistake my meaning even if you haven't seen my previous messages? Have you any evidence besides your assumption to prove that I did as you said? ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 18:28:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 188A116A4DF for ; Tue, 11 Jul 2006 18:28:04 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBC4243D62 for ; Tue, 11 Jul 2006 18:27:57 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id F0F87F17DE for ; Wed, 12 Jul 2006 02:27:55 +0800 (CST) X-KSVirus-check: 0 References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> In-Reply-To: <20060711152949.GB1463@merlin.emma.line.org> From: mag@intron.ac To: Matthias Andree Date: Wed, 12 Jul 2006 02:25:21 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152642474.29859@origin.intron.ac> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 18:28:04 -0000 Why do you all consider importing C++ code to FreeBSD kernel to be so complicated at the beginning? Matthias Andree wrote: > (please don't Cc me on list replies; chopping down the Cc list) > > On Tue, 11 Jul 2006, mag@intron.ac wrote: > >> Just as you said, C++ is more complicated than C. However, without >> C++ exception and other advanced features, it hasn't brought much >> complexity to C++ runtime library. Early C++ compiler even translates >> C++ code into C code before real compilation. > > But what's the point of C++ if it is mutilated below minimum standard > compliance levels so that you can no longer call it C++? > > This discussion has been through for other systems such as Linux long > ago, and it wasn't lack of manpower, but lack of technical feasibility, > or in other words, what was still useful for a kernel wasn't that much > different from C any more. C99 already adressed several concerns of C89, > and ISTR that FreeBSD kernels are C99 code these days. > >> We can judge whether a C++ feature can or cannot be imported into FreeBSD >> kernel by assemble code generated by GNU CC. > > Great, make the whole kernel depend on compiler internals. > Can you imagine a single vendor who'd have interest in hauling so many > dependencies into their software and handle all the support? I can't. Please complain about the portability of runtime library after reading codes in /usr/src/contrib/libstdc++/libsupc++/. Are they really so difficult to port? > > Write a C stub and put the rest into userspace where C++ works. > >> For example, I think C++ exception handling is really poorly suited for >> low-level code. > > Which chops off one of C++'s legs to stand on. Aside from the complexity of implementing C++ exception, in kernel, every exception must be carefully processed. A simple exception throw may lay memory leak and unfreed resource allocation. And outer exception catch is difficult to help inner exception. > >> Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on >> FreeBSD's actuality: so weak USB support (kernel crash easier than many >> other OSs that we laughed at and that we are laughing at), so weak PCI >> device support. > > Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT) > with Linux and plugged TWO devices into it and see Linux fail to talk to > the device you plugged in later? No? If so, you have zero clue how bad > USB support can get. And that's not the only problem Linux USB has had > or still has. Actually, what I would talk about is Microsoft Windows 2000/XP. We should ignore Microsoft's superiority just because we love FreeBSD. > >> Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI >> device drivers repeat: >> >> pci_read_config( ... ) >> ... >> sc->vr_res = bus_alloc_resource_any( ... ); >> ... >> sc->vr_irq = bus_alloc_resource_any( ... ); >> ... >> >> Is this kind of awful writing just of FreeBSD's style? >> >> In contrast, with C++, we can avoid many code repeating among device >> drivers. > > How would C++ avoid such? Generic programming, RTTI support and such > stuff requires an awful lot of compile-time code generation and runtime > library support. > Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkits? Good packages for various APIs are much easier to learn/debug than those original APIs. >> If we would have constructed an object model in C++, a programmer who >> master Microsoft MFC, Darwin I/O Kit could easily write a device drive >> with the device's hardware data sheet. > > And errata, and talking to the device happens in C-like programming > anyways... > > -- > Matthias Andree ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 18:41:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5B6516A4E2 for ; Tue, 11 Jul 2006 18:41:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF0FC43D7C for ; Tue, 11 Jul 2006 18:41:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6BIf967076262; Tue, 11 Jul 2006 14:41:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Tue, 11 Jul 2006 14:13:35 -0400 User-Agent: KMail/1.9.1 References: <200607111115.59844.jhb@freebsd.org> <20060711.103327.-8650905.imp@bsdimp.com> In-Reply-To: <20060711.103327.-8650905.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607111413.37238.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 11 Jul 2006 14:41:11 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1591/Mon Jul 10 15:41:02 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, mag@intron.ac, matthias.andree@gmx.de, julian@elischer.org, des@des.no, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 18:41:37 -0000 On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: > In message: <200607111115.59844.jhb@freebsd.org> > John Baldwin writes: > : and OS X both of which I've written a PCI driver for) we require device > : driver writers to go through a lot more hoops to do certain things like > : allocate resources. At the very least there is much that can be improved in > : our driver model. > > bus_alloc_resources goes a long ways in this respect. Yes, but in OS X I didn't even have to do that. All I had to do was ask it to map a BAR if I wanted to use it. It already "allocated" all the resources regardless. Windows was the same way (though a bit weirder, you get a message that lists all your resources and you have to map them if you want to use them). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 18:50:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DD0016A4E1 for ; Tue, 11 Jul 2006 18:50:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D43A43D6E for ; Tue, 11 Jul 2006 18:50:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BIm2i3045119; Tue, 11 Jul 2006 12:48:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 12:48:11 -0600 (MDT) Message-Id: <20060711.124811.1878034486.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200607111413.37238.jhb@freebsd.org> References: <200607111115.59844.jhb@freebsd.org> <20060711.103327.-8650905.imp@bsdimp.com> <200607111413.37238.jhb@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 12:48:02 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, mag@intron.ac, matthias.andree@gmx.de, julian@elischer.org, des@des.no, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 18:50:54 -0000 In message: <200607111413.37238.jhb@freebsd.org> John Baldwin writes: : On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: : > In message: <200607111115.59844.jhb@freebsd.org> : > John Baldwin writes: : > : and OS X both of which I've written a PCI driver for) we require device : > : driver writers to go through a lot more hoops to do certain things like : > : allocate resources. At the very least there is much that can be improved : in : > : our driver model. : > : > bus_alloc_resources goes a long ways in this respect. : : Yes, but in OS X I didn't even have to do that. All I had to do was ask it to : map a BAR if I wanted to use it. It already "allocated" all the resources : regardless. Windows was the same way (though a bit weirder, you get a : message that lists all your resources and you have to map them if you want to : use them). What's the difference in asking for a resource to be mapped, and calling a routine that allocates and maps the resource? Also, in FreeBSD, the resources are already allocated by the bus code. It just changes ownership to the child when the request comes in... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 19:07:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFC7A16A4DA for ; Tue, 11 Jul 2006 19:07:38 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from mail.ki.iif.hu (ki.iif.hu [193.6.222.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64A4643D46 for ; Tue, 11 Jul 2006 19:07:37 +0000 (GMT) (envelope-from mohacsi@niif.hu) Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 5C7EF55D7; Tue, 11 Jul 2006 21:07:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5B5D9555C for ; Tue, 11 Jul 2006 21:07:35 +0200 (CEST) Date: Tue, 11 Jul 2006 21:07:35 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: freebsd-hackers@freebsd.org Message-ID: <20060711210332.X43372@mignon.ki.iif.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Intel Vanderpool (VT) on FreeBSD or FreeBSD Xen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:07:39 -0000 Dear All, Does anybody succeed to boot FreeBSD on an Intel Vanderpool capable machine? My colleague tried it and the result is a BTX halt as can be seen on the screenshots on page linked. He successfully run unmodified Linux, Windows 2003 under Xen virtual machines, but FreeBSD failed in the boot phase. http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd.png http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd2.png By the way what is the state of Xen port of FreeBSD? I already asked these questions on FreeBSD-stable but no answers... Thanks, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 19:09:05 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D4C316A4E8; Tue, 11 Jul 2006 19:09:05 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B63FE43D58; Tue, 11 Jul 2006 19:09:04 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6BJ92RG016268; Tue, 11 Jul 2006 15:09:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1152636351.27575@origin.intron.ac> References: <200607092136.k69LaNDX055391@www.freebsd.org> <86zmfg42bd.fsf@xps.des.no> <200607111115.59844.jhb@freebsd.org> <1152636351.27575@origin.intron.ac> Date: Tue, 11 Jul 2006 15:09:01 -0400 To: mag@intron.ac, John Baldwin From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-hackers@FreeBSD.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:09:05 -0000 At 12:43 AM +0800 7/12/06, mag@intron.ac wrote: >Before I do enough experiments, naturally I would never >talk about this thing. > >I don't know why Dag-Erling C. Smo/rgrav is so unfriendly >to me ??? !!! He is commenting on your patches. Do not take those as personal attacks on you. You seem to be assuming that no one here has worked with C++, but that is not true. Some previous C++ experiments did not go well, so it might seem that we are quick to put down you want to do. It's not really that we're hostile to you, it is just that we want to go slow enough with any major change, to make sure we know what is going on. (me, I don't know enough about C++ to comment on your changes. I'm just saying that objections to your updates do not mean anyone is mad at you personally) -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 19:25:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1CE416A4DE for ; Tue, 11 Jul 2006 19:25:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEFCB43D6A for ; Tue, 11 Jul 2006 19:25:36 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by py-out-1112.google.com with SMTP id c63so3841622pyc for ; Tue, 11 Jul 2006 12:25:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FVMbXDm0DGHPwGaSETumwFFJZTWLHVn+6yiz3mF8LfjWESYzAj4BAgb+h9iBLKp+lP1bch8eifGYZ4TFvqnqoaB9XxdRSxUHBSoRve5pYcxN50eItFjnobzSia9Id65M43si75cus3RbkiUQ9VSxr0S54agHQntkifYEueLYw3Y= Received: by 10.35.78.9 with SMTP id f9mr6645424pyl; Tue, 11 Jul 2006 12:25:36 -0700 (PDT) Received: by 10.35.16.8 with HTTP; Tue, 11 Jul 2006 12:25:35 -0700 (PDT) Message-ID: Date: Tue, 11 Jul 2006 12:25:35 -0700 From: "Kip Macy" To: "Mohacsi Janos" In-Reply-To: <20060711210332.X43372@mignon.ki.iif.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060711210332.X43372@mignon.ki.iif.hu> Cc: freebsd-hackers@freebsd.org Subject: Re: Intel Vanderpool (VT) on FreeBSD or FreeBSD Xen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:25:37 -0000 I asked the person who wrote vtxassist (only SVM supports paged real mode) - he thinks that it broke when support for big real mode was added. He did not seem particularly inclined to fix it. It may be that Xen's VT-x support is considered less interesting to his organization now that VMware is free (as in beer). -Kip On 7/11/06, Mohacsi Janos wrote: > Dear All, > Does anybody succeed to boot FreeBSD on an Intel Vanderpool > capable machine? My colleague tried it and the result is a BTX halt as can > be seen on the screenshots on page linked. He successfully run unmodified > Linux, Windows 2003 under Xen virtual machines, but FreeBSD failed in the > boot phase. > http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd.png > http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd2.png > > By the way what is the state of Xen port of FreeBSD? > > I already asked these questions on FreeBSD-stable but no > answers... > > Thanks, > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 20:18:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 806D516A4DD for ; Tue, 11 Jul 2006 20:18:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3706A43D68 for ; Tue, 11 Jul 2006 20:18:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6BKILLO077005; Tue, 11 Jul 2006 16:18:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: mag@intron.ac Date: Tue, 11 Jul 2006 15:50:00 -0400 User-Agent: KMail/1.9.1 References: <200607111413.37238.jhb@freebsd.org> <1152645913.31340@origin.intron.ac> In-Reply-To: <1152645913.31340@origin.intron.ac> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607111550.00346.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 11 Jul 2006 16:18:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1591/Mon Jul 10 15:41:02 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:18:30 -0000 On Tuesday 11 July 2006 15:21, mag@intron.ac wrote: > John Baldwin wrote: > > > On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: > >> In message: <200607111115.59844.jhb@freebsd.org> > >> John Baldwin writes: > >> : and OS X both of which I've written a PCI driver for) we require device > >> : driver writers to go through a lot more hoops to do certain things like > >> : allocate resources. At the very least there is much that can be improved > > in > >> : our driver model. > >> > >> bus_alloc_resources goes a long ways in this respect. > > > > Yes, but in OS X I didn't even have to do that. All I had to do was ask it to > > map a BAR if I wanted to use it. It already "allocated" all the resources > > regardless. Windows was the same way (though a bit weirder, you get a > > message that lists all your resources and you have to map them if you want to > > use them). > > > > -- > > John Baldwin > > Do you mean that the kernel pre-allocate resources for all devices whether > a device has been attached by a device driver? > Does BIOS do the same thing before OS boots? Maybe (kernel can allocate it once probe has succeeded perhaps, or just always do it) and Yes (if PNP OS is set to No, that is what PNP OS means, is if the OS is smart enough to alloc the resources on its own). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 20:18:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7303816A4DD for ; Tue, 11 Jul 2006 20:18:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2A6C43D72 for ; Tue, 11 Jul 2006 20:18:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6BKILLN077005; Tue, 11 Jul 2006 16:18:21 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Tue, 11 Jul 2006 15:48:39 -0400 User-Agent: KMail/1.9.1 References: <200607111115.59844.jhb@freebsd.org> <200607111413.37238.jhb@freebsd.org> <20060711.124811.1878034486.imp@bsdimp.com> In-Reply-To: <20060711.124811.1878034486.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607111548.40898.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 11 Jul 2006 16:18:23 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1591/Mon Jul 10 15:41:02 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, mag@intron.ac, matthias.andree@gmx.de, julian@elischer.org, des@des.no, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 20:18:59 -0000 On Tuesday 11 July 2006 14:48, M. Warner Losh wrote: > In message: <200607111413.37238.jhb@freebsd.org> > John Baldwin writes: > : On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: > : > In message: <200607111115.59844.jhb@freebsd.org> > : > John Baldwin writes: > : > : and OS X both of which I've written a PCI driver for) we require device > : > : driver writers to go through a lot more hoops to do certain things like > : > : allocate resources. At the very least there is much that can be improved > : in > : > : our driver model. > : > > : > bus_alloc_resources goes a long ways in this respect. > : > : Yes, but in OS X I didn't even have to do that. All I had to do was ask it to > : map a BAR if I wanted to use it. It already "allocated" all the resources > : regardless. Windows was the same way (though a bit weirder, you get a > : message that lists all your resources and you have to map them if you want to > : use them). > > What's the difference in asking for a resource to be mapped, and > calling a routine that allocates and maps the resource? It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's no separate bus_alloc_resource/bus_setup_intr for interrupts though for example, just bus_setup_intr() equivalent. This is pretty simple though: /* OS X */ IOMemoryMap *myBarMap; void *myBar; u_int32_t reg; /* BAR 0 */ myBarMap = provider->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); myBar = myBarMap->getVirtualAddress(); reg = OSReadLittleInt32(myBar, FOO_REG); reg |= BAR_FLAG; OSWriteLittleIntew(myBar, FOO_REG, reg); myBar->release(); In FreeBSD-7 this is something like: struct resource *res; int rid; u_int32_t reg; rid = PCIR_BAR(0); res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); /* XXX: Not sure about endian.. stream_read maybe? */ reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, SYS_RES_MEMORY, rid, res); Which is very similar though there is some clutter (bus_release_resource() should take fewer args, like just dev and res, and it would be nice to say something like map_bar(dev, PCIR_BAR(0)) and get back a resource *). Older FreeBSD looks like this: struct resource *res; bus_space_tag_t tag; bus_space_handle_t hnd; int rid; u_int32_t reg; rid = 0x10; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0ul, ~0ul, 1, RF_ACTIVE); tag = rman_get_bustag(res); hnd = rman_get_bushandle(res); reg = bus_space_read_4(tag, hnd, FOO_REG); reg |= BAR_FLAG; bus_space_write_4(tag, hnd, FOO_REG, reg); bus_release_resource(dev, SYS_RES_MEMORY, rid, res); Usually drivers come up with macros to hide the bus handles and tags which is an indication that they were quite unsightly (thankfully that's been fixed in 7). :) I don't recall the Windows syntax off the top of my head. Note though that what verboseness there is in the OS X case comes from the really long and descriptive function names. Shorter function names would make it far more compact. Both Windows and OS X also allow you to only submap part of a bar if you want, and to specify the caching mode (UC, WC, WB, WT, etc.) when you map the bar. Oh, and just because I'm on my soapbox, on OS X you can mmap device memory (or any sort of malloc'd memory) _really_ easily in userland using an arbitrary mapping type, because their mmap-type operation (clientForMemoryType on an IOUserClient) just asks the device driver to provide an IOMemoryMap (which describes the backing physical addresses along with the cache mode etc.) and then takes care of mapping that into UVA, but I digress on that point. Anyways, if you took FreeBSD-7 and cut down some of the gunk similar to OS X you'd have something like: struct resource *res; u_int32_t reg; res = pci_alloc_bar(dev, PCIR_BAR(0)); /* XXX: endian question again */ reg = bus_read_4(res, FOO_REG); reg |= BAR_FLAG; bus_write_4(res, FOO_REG, reg); bus_release_resource(dev, res); Which is at least somewhat better I think. > Also, in FreeBSD, the resources are already allocated by the bus > code. It just changes ownership to the child when the request comes > in... Yes, this has been a recent improvement. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 21:00:00 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12A7916A4E8 for ; Tue, 11 Jul 2006 21:00:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB0143D45 for ; Tue, 11 Jul 2006 20:59:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BKuWpZ046714; Tue, 11 Jul 2006 14:56:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 14:56:32 -0600 (MDT) Message-Id: <20060711.145632.41678446.imp@bsdimp.com> To: jhb@FreeBSD.org From: Warner Losh In-Reply-To: <200607111548.40898.jhb@freebsd.org> References: <200607111413.37238.jhb@freebsd.org> <20060711.124811.1878034486.imp@bsdimp.com> <200607111548.40898.jhb@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 14:56:32 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org, mag@intron.ac, matthias.andree@gmx.de, julian@elischer.org, des@des.no, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:00:00 -0000 > It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's > no separate bus_alloc_resource/bus_setup_intr for interrupts though for > example, just bus_setup_intr() equivalent. This is pretty simple though: > > /* OS X */ > IOMemoryMap *myBarMap; > void *myBar; > u_int32_t reg; > > /* BAR 0 */ > myBarMap = provider->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); > myBar = myBarMap->getVirtualAddress(); > > reg = OSReadLittleInt32(myBar, FOO_REG); > reg |= BAR_FLAG; > OSWriteLittleIntew(myBar, FOO_REG, reg); > > myBar->release(); > > In FreeBSD-7 this is something like: > > struct resource *res; > int rid; > u_int32_t reg; uint32_t is the standards compliant spelling :-) > rid = PCIR_BAR(0); > res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); The above should be shortenable to: res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE); because we don't need to have rid be a pointer. > /* XXX: Not sure about endian.. stream_read maybe? */ no. bus_read is correct, because the pci bus is little endian by definition. bus_stream_read will read/write from native endian to bus endian. > reg = bus_read_4(res, FOO_REG); > reg |= BAR_FLAG; > bus_write_4(res, FOO_REG, reg); > > bus_release_resource(dev, SYS_RES_MEMORY, rid, res); We should be able to shorten that to: bus_release_resource(dev, res); these days. > Which is very similar though there is some clutter (bus_release_resource() > should take fewer args, like just dev and res, and it would be nice to say > something like map_bar(dev, PCIR_BAR(0)) and get back a resource *). Agreed. If you have mutliple resources, you can stack them up as well. > Usually drivers come up with macros to hide the bus handles and tags which is > an indication that they were quite unsightly (thankfully that's been fixed in > 7). :) I usually do: #define RD4(sc, r) bus_read_4(sc->res, (r)) #define WR4(sc, r, v) bus_write_4(sc->res, (r), (v)) which makes usage even shorter. It also helps me hid cross-version differences... > Anyways, if you took FreeBSD-7 and cut down some of the gunk similar to OS X > you'd have something like: > > struct resource *res; > u_int32_t reg; > > res = pci_alloc_bar(dev, PCIR_BAR(0)); > > /* XXX: endian question again */ > reg = bus_read_4(res, FOO_REG); > reg |= BAR_FLAG; > bus_write_4(res, FOO_REG, reg); > > bus_release_resource(dev, res); > > Which is at least somewhat better I think. In the case where you don't care what kind of mapping you get, that would work great. It wouldn't be too hard to implement a pci_alloc_bar that does the default allocation and mapping. Changing some of the other APIs would be more difficult... > > Also, in FreeBSD, the resources are already allocated by the bus > > code. It just changes ownership to the child when the request comes > > in... > > Yes, this has been a recent improvement. Yes. We also do it in a lazy way so that if the resource is allocated or not is transparent to the driver and the system. If it could be decoded, we reserve it. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 21:30:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCD4F16A4DA for ; Tue, 11 Jul 2006 21:30:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFDB543D64 for ; Tue, 11 Jul 2006 21:30:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BLQSUl047236; Tue, 11 Jul 2006 15:26:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 15:26:38 -0600 (MDT) Message-Id: <20060711.152638.-1625881074.imp@bsdimp.com> To: mag@intron.ac From: "M. Warner Losh" In-Reply-To: <1152642474.29859@origin.intron.ac> References: <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 15:26:29 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, matthias.andree@gmx.de Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:30:07 -0000 In message: <1152642474.29859@origin.intron.ac> mag@intron.ac writes: : Why do you all consider importing C++ code to FreeBSD kernel to be so : complicated at the beginning? Many people reading this list have conducted experiments in the past at various employers. Everyone who has conducted the experiments reports that the 'trivial' parts of C++ are trivial to do in the kernel. new/delete support is easy. Subclassing is easy, so long as it is single inheritance. Some limited template support is possible. Exceptions can be made to be not too bad, but at the expense of much of the exception functionality. If you look at the number of weasil words I used here to describe the functionality, you'll see that the 'easy' parts of C++ aren't a very large subset of the entire language, and many would argue aren't a useful enough subset to be worth the efforts to clean up the code and make it production quality. However, C++ has so many standard libraries and interfaces that importing them into the kernel is a daunting task. STL is right out, for example, as are the insertion and extraction operators. Also, g++ has traditionally produced worse code for C++ than for C, even when the source is identical. This stems mainly from subtle differences in the semantics of the two languages. This was true in 2.3 times, in 2.4 times, and is still true with 3.4.4 that we have in current, although a few simple tests indicates that things have gotten much better. Basically, people here have tried it in the past and given up. They are very leery of any changes in this direction, and need some sort of proof to be convinced otherwise. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 21:34:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B8DF16A4DA; Tue, 11 Jul 2006 21:34:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1227C43D58; Tue, 11 Jul 2006 21:34:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BLTPPK047248; Tue, 11 Jul 2006 15:29:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 15:29:34 -0600 (MDT) Message-Id: <20060711.152934.-894584780.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200607111550.00346.jhb@freebsd.org> References: <200607111413.37238.jhb@freebsd.org> <1152645913.31340@origin.intron.ac> <200607111550.00346.jhb@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 15:29:26 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:34:07 -0000 In message: <200607111550.00346.jhb@freebsd.org> John Baldwin writes: : On Tuesday 11 July 2006 15:21, mag@intron.ac wrote: : > John Baldwin wrote: : > : > > On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: : > >> In message: <200607111115.59844.jhb@freebsd.org> : > >> John Baldwin writes: : > >> : and OS X both of which I've written a PCI driver for) we require device : > >> : driver writers to go through a lot more hoops to do certain things like : > >> : allocate resources. At the very least there is much that can be : improved : > > in : > >> : our driver model. : > >> : > >> bus_alloc_resources goes a long ways in this respect. : > > : > > Yes, but in OS X I didn't even have to do that. All I had to do was ask : it to : > > map a BAR if I wanted to use it. It already "allocated" all the resources : > > regardless. Windows was the same way (though a bit weirder, you get a : > > message that lists all your resources and you have to map them if you want : to : > > use them). : > > : > > -- : > > John Baldwin : > : > Do you mean that the kernel pre-allocate resources for all devices whether : > a device has been attached by a device driver? : > Does BIOS do the same thing before OS boots? : : Maybe (kernel can allocate it once probe has succeeded perhaps, or just always : do it) and Yes (if PNP OS is set to No, that is what PNP OS means, is if the : OS is smart enough to alloc the resources on its own). For FreeBSD, the kernel pre-allocates all resources that the BIOS allocated in the pci bus. We then give them out to the driver as the driver requests them. If the driver requests a resource that hasn't been pre-allocated, FreeBSD will attempt to allocate then and there that resource, and if successful return it. Generally, PnPOS == no means 'allocate everything you possibly can for these devices' while PnPOS == yes means 'allocate just enough to boot and leave the rest to the OS'. FreeBSD copes with both settings, as well as really old BIOSes that always allocated and new ones where you can't set PnPOS to "no". Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 21:37:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BB0416A4DA for ; Tue, 11 Jul 2006 21:37:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315CD43D64 for ; Tue, 11 Jul 2006 21:37:53 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id h30so1577432wxd for ; Tue, 11 Jul 2006 14:37:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FVlFJ3+Hn/cn3YayuPTF0g/AU/3cP+xE7kM8d2l1/4zD02dc7R54pOBbljDP1vVOGEK4urVmiVzv++YY5tpM6J1agST1+rrg1bv48m88ovxCNWwpbF8B4jvVK+h1nWeiz+O6+/AfGvP3wF4CvST8vwxiW+h0e+P6h1TLPCUqDGU= Received: by 10.70.80.1 with SMTP id d1mr8172897wxb; Tue, 11 Jul 2006 14:37:52 -0700 (PDT) Received: by 10.70.11.15 with HTTP; Tue, 11 Jul 2006 14:37:52 -0700 (PDT) Message-ID: <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> Date: Tue, 11 Jul 2006 23:37:52 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "mag@intron.ac" In-Reply-To: <1152642474.29859@origin.intron.ac> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> X-Google-Sender-Auth: 8a4ee785531a3df4 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:37:58 -0000 2006/7/11, mag@intron.ac : > Why do you all consider importing C++ code to FreeBSD kernel to be so > complicated at the beginning? > > Matthias Andree wrote: > > > (please don't Cc me on list replies; chopping down the Cc list) > > > > On Tue, 11 Jul 2006, mag@intron.ac wrote: > > > >> Just as you said, C++ is more complicated than C. However, without > >> C++ exception and other advanced features, it hasn't brought much > >> complexity to C++ runtime library. Early C++ compiler even translates > >> C++ code into C code before real compilation. > > > > But what's the point of C++ if it is mutilated below minimum standard > > compliance levels so that you can no longer call it C++? > > > > This discussion has been through for other systems such as Linux long > > ago, and it wasn't lack of manpower, but lack of technical feasibility, > > or in other words, what was still useful for a kernel wasn't that much > > different from C any more. C99 already adressed several concerns of C89, > > and ISTR that FreeBSD kernels are C99 code these days. > > > >> We can judge whether a C++ feature can or cannot be imported into FreeBSD > >> kernel by assemble code generated by GNU CC. > > > > Great, make the whole kernel depend on compiler internals. > > Can you imagine a single vendor who'd have interest in hauling so many > > dependencies into their software and handle all the support? I can't. > > Please complain about the portability of runtime library after reading > codes in /usr/src/contrib/libstdc++/libsupc++/. > Are they really so difficult to port? > > > > > Write a C stub and put the rest into userspace where C++ works. > > > >> For example, I think C++ exception handling is really poorly suited for > >> low-level code. > > > > Which chops off one of C++'s legs to stand on. > > Aside from the complexity of implementing C++ exception, in kernel, every > exception must be carefully processed. A simple exception throw may lay > memory leak and unfreed resource allocation. And outer exception catch > is difficult to help inner exception. Even if I have no proof-of-concepts (so maybe somebody can show that this is not fair), if we have setjmp/longjmp in the kernel we can have a correct exception handling mechanism without not great problems. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 22:24:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CA9C16A4DE; Tue, 11 Jul 2006 22:24:06 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 276E943D5D; Tue, 11 Jul 2006 22:24:04 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.180.239] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1G0QeA3Pn5-0002Z1; Wed, 12 Jul 2006 00:24:04 +0200 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Wed, 12 Jul 2006 00:24:00 +0200 User-Agent: KMail/1.9.1 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org Subject: FreeBSD Status Report Second Quarter 2006 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 22:24:06 -0000 --Boundary-00=_CUCtEMHd7mLwLaH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_CUCtEMHd7mLwLaH Content-Type: text/plain; charset="us-ascii"; name="report-apr-2006-jun-2006.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="report-apr-2006-jun-2006.txt" April-June 2006 Status Report Introduction With the release of FreeBSD 5.5 and FreeBSD 6.1, the second quarter of 2006 has been productive. Google is sponsoring 14 students to work on FreeBSD as part of their Summer of Code Program (most of which already submitted a report for elaboration on their projects). Sun's open-source software is starting to make its way into FreeBSD as a port of DTrace is nearing completion and a port to the UltraSparc T1 processor (which gives a great push to the ongoing SMP efforts). Having a powerful debugging tool combined with a CPU that can run up to 32 concurrent threads helps to identify scalability issues. BSDCan 2006 was yet again a smashing success and much was covered in the 2-day developer summit. As a product of the conference, a new focus on FreeBSD for the embedded sector has started. Various ARM boards are targeted, a MIPS32 port is gearing up and people are looking for other interesting platforms to port FreeBSD to. Preparation for the EuroBSDCon (in Milan, Italy) on November has already issued a call for papers. In addition, a lot of spring cleaning is taking place in the network stack. After conclusion of the KAME project, IPv6 code integration has been refocused and a fully locked port of SCTP is in the final stage of integration. Of course, all this goes without noting all the progress made with the other network projects. Please read below for more detailed news on the projects that happened in FreeBSD during the last three months. If you are interested in helping, consider the "Open Tasks lists" provided with some reports. In addition we would like to point you at the list of projects and ideas for volunteers and hope to receive a status report from you next time. Thanks to all reporters for your excellent work and timing!. Enjoy reading. _________________________________________________________________ Google summer of code * BSNMP Bridge module * gvirstor * Improving Ports Collection * Interrupt handling * IPv6 Vulnerabilities * Jail Resource Limits * K Kernel Meta-Language * Linuxolator kernel update to match functionality of 2.6.x * Nss-LDAP importing and nsswitch subsystem improvement Projects * DTrace * Embedded FreeBSD * TrustedBSD Audit Network infrastructure * FAST_IPSEC Upgrade * FreeBSD NFS Status Report * IPv6 cleanup * Multi-IP v4/v6 jails * SCTP Integration * Wireless Networking Kernel * Giant-Less UFS with Quotas * Giant-Less USB framework * GJournal * Gvinum improvements * Sound subsystem improvements * SSE2 Kernel support * XFS for FreeBSD Documentation * FreeBSD list of projects and ideas for volunteers * Hungarian translation of the webpages Userland programs * Low-overhead performance monitoring tools Architectures * PowerPC Port Ports * FreshPorts * Ports Collection * Update of the Linux userland infrastructure in the Ports Collection Vendor / 3rd Party Software * BSDInstaller * pfSense * xscale board buy Miscellaneous * BSDCan * EuroBSDCon 2006 - November 10th - 12th, Milan, Italy * FreeBSD Security Officer and Security Team * Release Engineering _________________________________________________________________ BSDCan URL: http://www.bsdcan.org/ Contact: Dan Langille BSDCan 2006 continues to impress. Again this year, we had a good collection of talks from a wide range of speakers. In all, we had over 200 people from 14 different countries. Our sponsorship pool continues to grow. This year we had sponsorship from: * USENIX * The FreeBSD Foundation * PARSE * iXsystems * O'Reilly * Stevens Institute of Technology * nCircle The t-shirts were very popular, with all of them going in very short time. Of course, it helped that this year they were free, courtesy of PARSE. The 2007 planning has already begun and we look forward to another popular and successful event. My thanks to the 2006 program committee, the speakers, the volunteers, the sponsors, and, of course, the attendees. See you at BSDCan 2007. _________________________________________________________________ BSDInstaller URL: http://wikitest.freebsd.org/moin.cgi/BSDInstaller Contact: Andrew Turner Since the last status report ports have been created for all parts of the BSDInstaller except the backend. A snapshot of the BSDInstaller was released during this quarter. This has shown a number of bugs with the installation process. Most have now been fixed. _________________________________________________________________ BSNMP Bridge module URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/soc %2dshteryana/bsnmp/usr.sbin/bsnmpd/modules/snmp%5fbridge URL: http://wiki.freebsd.org/SnmpBridgeModule Contact: Shteryana Shopova As part of my SoC 2006 project I am working on implementing a BRIDGE monitoring module for FreeBSD's BSNMP daemon. Initial prototyping is done and some kernel changes are coming to be able to access all needed data. In addition to IETF RFC 4188, which was designed for monitoring a single bridge, this snmp module will support monitoring of multiple bridge devices as supported by FreeBSD. Open tasks: 1. Finish kernel changes and the code for the snmp module. 2. Testing. _________________________________________________________________ DTrace URL: http://people.freebsd.org/~jb/dtrace/index.html Contact: John Birrell Anonymous enablings now work. There is a new option in the boot loader menu to load the DTrace modules and trace the kernel boot process. Sun Microsystems has been very supportive of the FreeBSD port and has generously provided a Sun Fire T2000 server to allow Kip Macy's sun4v port to be merged into the DTrace project tree. The DTrace project tree sources are now exported to cvsup10.freebsd.org Refer to the project page for more details. Open tasks: 1. Current effort centres around making DTrace useful for the sun4v porting effort which has shown up scalability issues with the current FreeBSD SMP implementation. DTrace should be ideal for analysing those issues. _________________________________________________________________ Embedded FreeBSD URL: http://www.embeddedfreebsd.org/ Contact: George Neville-Neil There are several projects moving forward in the embedded area. For now the main location for new information is www.embeddedfreebsd.org. We have also created a new mailing list, freebsd-embedded@freebsd.org , which is meant to eventually replace the freebsd-small. A call was put out on small for people to move to embedded. Open tasks: 1. Update Developers Handbook with information on building embedded versions of FreeBSD 2. Help with the MIPS port 3. Help with the ARM port 4. Investigate an SH port (requested by folks in Japan where the Hitachi SH processor is quite popular in embedded) _________________________________________________________________ EuroBSDCon 2006 - November 10th - 12th, Milan, Italy URL: http://www.eurobsdcon.org Contact: Massimiliano Stucchi This year's EuroBSDCon will be held in Milan, Italy, on November 10th through 12th. Hosted in the foggy northern Italy, the fifth EuroBSDCon aims at being a new successful chapter in the itinerant series of European BSD conferences. EuroBSDCon represents the biggest gathering for BSD developers from the old continent, as well as users and passionates from around the World. It is also a chance to share experiences, know-how, and cultures. For the first time, parallel to the main event, an event for wives/girlfriends/friends will be organised. It will consist of guided tours of the city of Milan, a probable trip to Como and visits to various museums. We're also working towards offering a show at the Teatro alla Scala. The FreeBSD developer summit will be also held on November 10th. Open tasks: 1. The Call For Papers is out, so everybody is invited to send in papers or tutorials that might be of interest to the community 2. The Conference Organisers are also looking for sponsors. Feel free to contact oc@eurobsdcon.org in order to discover the different sponsoring opportunities. _________________________________________________________________ =46AST_IPSEC Upgrade URL: http://sources.zabbadoz.net/freebsd/ipv6/fast-ipsec.html Contact: George Neville-Neil Contact: Bjoern A. Zeeb Continuing to add IPv6 support to FAST_IPSEC. Test environment is now stable. Can build and run kernels with FAST_IPSEC and INET6 enabled but IPSec in IPv6 is now broken and being worked on. Open tasks: 1. Complete move to FAST_IPSEC type processing for IPv6. This is complicated by the structure of the IPv6 code itself which, unlike IPv4 splits transport and tunnel mode processing across the output routine. _________________________________________________________________ =46reeBSD list of projects and ideas for volunteers URL: http://www.FreeBSD.org/projects/ideas/ Contact: Joel Dahl Contact: Alexander Leidinger The FreeBSD list of projects and ideas for volunteers is doing well. Several items were picked up by volunteers and have found their way into the tree. Others are under review or in progress. We are looking forward to hear about new ideas, people willing to act as technical contacts for generic topics such as USB or specific entries (already existing or newly created) and suggestions for existing entries or completion reports for (parts of) an entry. Open tasks: 1. Add more ideas. 2. Find more technical contacts. 3. Find people willing to review/test implementations of (somewhat) finished items. _________________________________________________________________ =46reeBSD NFS Status Report Contact: Chuck Lever Mohan Srinivas committed his changes to make the NFSv2/3 client MP safe to HEAD this quarter. Changes may be back-ported to 6.x soon. Robert Watson and Chuck Lever held a discussion about the future of the in-kernel NFSv4 client during BSDCan 2006. The current NFSv4 client is unmaintained. Chuck also pointed out the long series of unfixed PRs against the legacy client (NFSv2/3). These are at the top of his priority list. Robert is also interested in making NFSv4-style ACLs the lingua franca for FreeBSD file systems. There was some discussion about integrating Rick Maclem's NFSv4 server into 7.x. Chuck Lever became a full source committer during this quarter. _________________________________________________________________ =46reeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff -listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In the time since the last status report, four security advisories have been issued concerning problems in the base system of FreeBSD; of these, one problem was "contributed" code, while three were in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 71 new entries have been added, bringing the total up to 757. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.11, FreeBSD 5.3, FreeBSD 5.4, FreeBSD 5.5, FreeBSD 6.0, and FreeBSD 6.1. The respective End of Life dates of supported releases are listed on the web site; of particular note, FreeBSD 5.3 and FreeBSD 5.4 will cease to be supported at the end of October 2006, while FreeBSD 6.0 will cease to be supported at the end of November 2006. _________________________________________________________________ =46reshPorts URL: http://www.freshports.org/ Contact: Dan Langille FreshPorts has seen several new features recently: * caching implemented at web application level to reduce load on the database server and to serve pages faster * searching expanded to find all the ports that this maintainer maintains, and all the commits by a particular committer Most of the work lately has been optimisation, either at the database level or at the web application level. A 2U server was recently donated to the FreshPorts / FreshSource / FreeBSD Diary / BSDCan group. We have also received a RAID card. Now we're looking for some hard drives. Over the past few weeks, work has concentrated on benchmarking the new server and getting it ready for production. Eventually it will need a new home as I don't really want it running in my basement all the time (it's really loud!). Thanks to iXsystems and 3Ware for their contributions to this project. Open tasks: 1. We would like some more hardware (CPUs and HDD). Details here _________________________________________________________________ Giant-Less UFS with Quotas URL: http://people.freebsd.org/~kib/quotagiant Contact: Konstantin Belousov The patches to allow UFS operate with quotas in Giant-less mode are brewed for long now. Since recent huge pile of fixes into snapshots code, I think the problems you could encounter are caused solely by the patch. Aside performance benefits, patch has another one, much more valuable. It makes UFS operating in one locking regime whatever options are compiled into kernel. I think, in long term, that would lead to better stability of the system. Open tasks: 1. I need testers feedback. Both stability reports and performance measurements are welcomed ! _________________________________________________________________ Giant-Less USB framework URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects /usb/src/sys/dev/usb&HIDEDEL=3DNO URL: http://www.turbocat.net/~hselasky/usb4bsd Contact: Hans Petter Sirevaag Selasky For some time now I have been working on converting the existing USB device drivers to my new and mutex enabled USB API. I have converted "ulpt", "ums", "uhid", "ukbd", "ugen", "uaudio", and a few others. Around 10 USB device drivers are left to convert. Most of these are network device drivers. At the present moment I am working on getting scatter and gathering support working for all USB host controllers. Scatter and gathering means that one allocates PAGE_SIZE bytes of memory at a time, and then fills these memory blocks up as much as possible with USB host controller structures and buffers. This should solve problems allocating DMA-able memory when the system memory becomes fragmented. Open tasks: 1. If anyone wants to help convert the remaining USB device drivers, please drop me an e-mail. _________________________________________________________________ GJournal URL: http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html URL: http://people.freebsd.org/~pjd/patches/gjournal.patch URL: http://people.freebsd.org/~pjd/patches/gjournal6.patch Contact: Pawel Jakub Dawidek GJournal is a GEOM class which provides journaling for GEOM providers. It can also be used to journal various file system with just a minimal filesystem-specific portion of code. Currently only UFS journaling is implemented on top of gjournal. Being filesystem-independent and operating below the file system level, gjournal has no way to distinguish data from metadata, thus it journal both. One of the nice things about gjournal is that it works reliable even on disks with enabled write cache, which is often not the case for journalled file system. And remember... fsck no more. Open tasks: 1. I'm looking for feedback from users who can test gjournal in various workloads. _________________________________________________________________ Gvinum improvements Contact: Ulf Lilleengen I have been working on porting missing features in gvinum from vinum, as well as adding new features. So far the resetconfig, detach, dumpconfig, setstate (on plexes and volumes) and stop commands have been implemented, as well as some other minor fixes. The attach command is currently being implemented, and started on disk-grouping. Currently most of this is in p4, but patches will be submitted as soon as possible. _________________________________________________________________ gvirstor URL: http://wikitest.freebsd.org/gvirstor Contact: Ivan Voras The purpose of gvirstor module is to provide the ability to create a virtual storage device of arbitrarily large size (typically several terabytes) which consists of an arbitrary number of physical storage devices (actually any lower-level GEOM providers, including RAID devices) of arbitrary size (typically 50 GB - 400 GB hard drives). Storage space from these components is carved into small chunks (for example 4 MB) and allocated (committed) to the virtual device on as-needed basis. Development has started and progressing as planned (though a little bit slow). Metadata format and virtual storage allocation formats have been defined and more serious coding is in progress. Open tasks: 1. Much user testing will be needed (though not currently) _________________________________________________________________ Hungarian translation of the webpages URL: http://gabor.t-hosting.hu/data/hu/ Contact: G=E1bor K=F6vesd=E1n The translated webpage is almost ready now. This Hungarian translation is a "lite" version of the original English webpages, since there are parts that are irrelevant for the Hungarian community, or has pieces of data that change quickly, so it's no use to translate these pages now, maybe later, if we have more Hungarian contributors, but this webpage would be a good starting point in translating the documentations, and we need a good place to put translated documentations anyway. I'm going to be very busy with SoC this summer, but I'll try to find people that can help me out in this project. Any help appreciated. Open tasks: 1. The remaining important pages should be translated. 2. The press/media/news sections should be restructured somehow to being fed from the English webapges, since we don't have too much Hungarian resource to make these up to date. 3. There's a rendering issue when browsing the pages with JavaScipt enabled, but this can be server-side for me, this should be investigated as well. _________________________________________________________________ Improving Ports Collection URL: http://wikitest.freebsd.org/G%C3%A1borK%C3%B6vesd%C3%A1n URL: http://wikitest.freebsd.org/DESTDIR URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/98105 Contact: G=E1bor K=F6vesd=E1n The improved support for the i386 binaries are ready for -exp run. It only allows installing such ports on amd64 and ia64 when there's a compatibility layer compiled into the kernel and the 32-bit libraries are installed under /usr/lib32. The DESTDIR support are in progress. It works for the simplest ports without USE_* that don't have a [pre|do|post]-install target. There are more complicated issues with e.g. conflict checking in DESTDIR, deinstalling from DESTDIR, those have to be fixed as well. Open tasks: 1. DESTDIR issues should be fixed. 2. All ports should be examined whether they respect CC/CFLAGS, and the erroneous ones should be fixed. 3. Fetch scripts should be taken out of bsd.port.mk to be separate scripts. 4. A tool should be written that makes possible to cross-compile ports. 5. A good plist generator tool should be written for porters or the old one in ports/Tools/scripts should be updated. _________________________________________________________________ Interrupt handling Contact: Paolo Pisati With the introduction of fine grained locking in the SMPng project, the FreeBSD kernel went under a major redesign, and many subsystem changed significantly with it. In particular, device driver's interrupt context ("the bottom half") had the necessity to synchronise with process context ("the top half") and share data in a consistent manner without using spl*(). To overcome this problem, a new interrupt model based around interrupt threads was employed, together with a fast interrupt model dedicated to particular driver handlers that don't block on locks (i.e. serial port, clock, etcetc). Unfortunately, even if the interrupt thread model proved to be a reliable solutions, its performance were not on par with the pre SMPng era (4.x), and thus others solutions were investigated, with interrupt filtering being one of that. As part of my Summer of Code 2006 work, i'm implementing interrupt filtering for FreeBSD, and when the framework will be in place i'll compare the performance of filters, against all the previous models: pre-SMPng(4.x), ithread and polling. The most important modifications to the src tree so far where: * made PPC accepts more than one FAST handler per irq line (previously INTR_FAST implied INTR_EXCL) * converted all the INTR_FAST handlers to be filters: return an error code to note what they did (FILTER_HANDLED/FILTER_STRAY) and if they need more work to do (FILTER_SCHEDULE_THREAD) * moved part of the interrupt execution code from MD code to kern_intr.c::intr_filter_loop() * broke newbus API: bus_setup_intr() grew a new filter parameter of type "int driver_filter_t(void*)". * converted all the bus that override bus_setup_intr() to handle filters * converted all the normal ithread driver to provide a NULL filter funcion The next milestone is to have all the different models (filters only, ithread only and filter + ithread) work together reliably. Open tasks: 1. Arm is largely untested 2. Sparc64 needs more work on low level (.s) interrupt routine _________________________________________________________________ IPv6 cleanup URL: http://sources.zabbadoz.net/freebsd/ipv6/ URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/bz/ ipv6 Contact: Bjoern A. Zeeb Initial changes include: * Changed ip6_sprintf to no longer return a static buffer. * Started to adopt in6_pcb* code to what we have for legacy IP. Next steps will be to reduce the number of global variables and caches. Open tasks: 1. Cleanup code. 2. Make everything MPSafe. 3. Enhance things and add new features. _________________________________________________________________ IPv6 Vulnerabilities URL: http://wiki.freebsd.org/ClementLecigne Contact: George Neville-Neil Contact: Cl=E9ment Lecigne Clement has been working both with libnet and gnn's Python based packet library (PCS) to produce code to test for vulnerabilities in IPv6. To Clement has found some issues, all of which have been reported to his mentor and to Security Officer at FreeBSD.org Vulnerabilities will not be reported here. Open tasks: 1. Get 0.1 of PCS on to SourceForge for wider use. _________________________________________________________________ Jail Resource Limits Contact: Chris Jones Project is in development with initial working software expected mid-July 2006. CPU limits will be implemented with a hierarchical scheduler: (initially) using a round-robin scheduler to select which jail to run a task in and then delegating which task in the jail to be run to a per-jail scheduler. Open tasks: 1. Complete round-robin inter-jail scheduler (with existing 4BSD schedulers implemented per jail). 2. Add hooks for memory tracking. _________________________________________________________________ K Kernel Meta-Language URL: http://wikitest.freebsd.org/SpencerWhitman Contact: Spencer Whitman Contact: Poul-Henning Kamp A simple lexer and parser have almost been completed. Also significant planing for future additions to K have been thought up. Open tasks: 1. Finish the lexer and parser 2. Implement the #! preprocessor function 3. Add lint like functionality to the preprocessor 4. Add style(9) checking to the preprocessor 5. Allow for detection of unused #includes _________________________________________________________________ Linuxolator kernel update to match functionality of 2.6.x URL: http://wiki.freebsd.org/RomanDivacky Contact: Roman Divacky Contact: Alexander Leidinger FreeBSD linux emulation layer (linuxolator) currently implements most of the functionality necessary to emulate 2.4.2 linux kernel, but linux world has moved forward and current linux world requires 2.6.x features. The aim of this SoC task is to make Fedora Core 4 linux-base to be able to run with 2.6.x kernel. Currently this means extending clone() syscall and implement pthread related things. This involves TLS implementation (sys_set_thread_area syscall) and possibly tid manipulation (used for pthread_join etc.) and finally futexes (linux fast user-space mutexes implementation). This should enable pthread-linked programs to work. After this is done there may be other things necessary to implement however, only time will tell. I am funded by google.com in their SoC to do this work and I'll continue to work on this after the summer hopefully as a part of my MSc. thesis. Open tasks: 1. Finish the TLS thing + other thread related things (tid comes to mind and looks necessary for pthread to work) 2. Futexes also look necessary for pthread to work 3. maybe other things to be able to run basic programs under 2.6.16 linuxolator _________________________________________________________________ Low-overhead performance monitoring tools URL: http://wiki.freebsd.org/LibElf URL: http://wiki.freebsd.org/PmcTools URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement/ Contact: Joseph Koshy As an intermediate step towards implementing support for callgraphs and cross-architecture performance measurements, I am creating a BSD-licensed library for ELF parsing & manipulation. This library will implement the SysV/SVR4 (g)ELF[3] API. Current status: Implementation of the library is in progress. A TET-based test suite for the API and manual pages documenting the library's interfaces are being concurrently created. Work is being done in FreeBSD's Perforce repository. I hope to be ready for general review by the end of July '06. Open tasks: 1. Reviewers are needed for the code and the test suite. If you have extensions to the stock SysV/SVR4 ELF(3) API that you would like to see in -lelf, please send mail. _________________________________________________________________ Multi-IP v4/v6 jails URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/bz/ jail Contact: Bjoern A. Zeeb As an intermediate step until FreeBSD will have full network stack virtualisation this work shall provide support for multi-IP IPv4/v6 jails. These changes are based on Pawel Jakub Dawidek's work for multi-IPv4 jails and some initial work from Olivier Houchard for single-IPv6 jails. The changes need some more testing but basically things work. This is not considered to be the right thing todo so do not ask for official support or if this will be committed to the FreeBSD source repository. After some more cleanup of non-jail related IPv6 changes I will publish a patch for HEAD and perhaps RELENG_6 for everyone who wants to give it a try anyway. Open tasks: 1. (IPv6) related security checks. 2. Write some tests. Especially IPv6 changes need more testing. 3. Check what general changes might need merging to HEAD. _________________________________________________________________ Nss-LDAP importing and nsswitch subsystem improvement URL: http://wikitest.freebsd.org/LdapCachedDetailedDescription URL: http://wikitest.freebsd.org/MichaelBushkov Contact: Michael Bushkov The basic goals of this SoC 2006 project are moving nsswitch-modules out of the libc, extending the caching daemon and importing nss_ldap into the base source tree. 2 milestones of the project are currently completed. 1. Nss-modules were successfully moved out of the libc into the separate dynamic libraries. In order for static binaries to work properly (they can't use dynamic nss-modules), nss-modules are linked statically into the libc.a. As the side-effect of nss-modules separation, getipnodeby***() functions were rewritten to use gethostby***() functions and not the nsdispatch(3) call. Caching daemon's "perform-actual-lookups" option was extended to support all implemented nsswitch databases. 2. A set of regressions tests was made to test nsswitch-related functions. These tests are also capable of testing the stability of these functions' behaviour after the system upgrade. Open tasks: 1. Import nss_ldap into the sources tree. 2. Improve the caching daemon's performance. _________________________________________________________________ pfSense URL: http://www.pfsense.com Contact: Scott Ullrich pfSense is rapidly approaching release. We are down to a handfull of bugs that should be fixed in the coming weeks. We should have a release around the time of our 2nd annual hackathon which is taking place on July 21st - July 28th. Many exciting sub-projects are taking place within pfSense and the project is gaining new developers monthly. Open tasks: 1. http://cvstrac.pfsense.com/rptview?rn=3D6 lists the remaining open bugs. _________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports / URL: http://portsmon.FreeBSD.org/index.html URL: http://people.freebsd.org/~fenner/portsurvey/ URL: http://beta.inerd.com/portscout/ URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Erwin Lansing Contact: Mark Linimon During this time, a huge number of ports PRs were committed, bringing us back down below 800 for the first time since the 5.5/6.1 release cycle. This is due to a great deal of work, especially from some of our newest committers. This is all the more notable given the fact that we have been adding new ports at a rapidly accelerating rate. We have now exceeded the 15,000 port mark! Three sets of changes have been added to the infrastructure, including updates of default versions of MySQL, PHP, LDAP, and linux_base, and numerous bugfixes and improvements. About 2 dozen portmgr PRs were closed due to this. In addition, a large-impact commit was made that attempts to move us to a single libtool that is as unmodified from 'stock' libtool as we can. Plans are also in place to do this for the autotools. Several people are at work on implementing the modularised xorg ports. Most of the work is done but several key pieces remain. Once this is finished, an -exp regression test will be needed (most likely, more than one :-) ) It is possible that before this we will need to do a regression test that moves X11BASE back into LOCALBASE. This is still under study. Gabor Kovesdan started a Google Summer of Code project on some highly needed improvements on the ports infrastructure (see elsewhere in this report). As this is a long term project, gtetlow kindly imported the most important ports infrastructure files into perforce to ease development. Other developers are encouraged to use perforce for ports development, especially as it can help keeping patches up-to-date while going stale in GNATS. Even though linimon has been pushing hard on running experimental builds on the test cluster, it will take some time to work through the backlog. erwin added a ports section to the list of projects and ideas for volunteers at the FreeBSD website. Have a look if you want to work on the ports system. Don't hesitate to send additional ideas, and committers are encouraged to add themselves as technical contacts. sem adopted portupgrade after it had been neglected for some time and has been very active on upgrades and bugfixing. dougb has continued to enhance his portmaster script and people are finding success with it; although not designed to be as full-featured as portupgrade, it does seem to be easier to understand and use. shaun has contributed portscout, a scanner for updated distfiles, to the ports collection. marcus upgraded GNOME to 2.14.1. As well, there have been new releases of the ports tinderbox code. edwin has been hard at work on a PR-autoassigner for ports PRs, which has saved a lot of time and been well-received. It has now been installed on a freebsd.org machine (hub). linimon has been more active in pursuing maintainer-timeouts, and has reset a number of inactive maintainers, with more in the pipeline. The intent is to try to reduce the number of PRs that sit around unanswered for two weeks. In almost all cases the resets are due to no response at all; maintainers who are merely "busy" are not the source of most of these problems, and deserve the benefit of the doubt. Some of the maintainers that have been reset haven't contributed in months or even years. We have added 10 (!) new committers since the last report. Open tasks: 1. We need help getting back to our modern low of 500 PRs. 2. We have over 4,000 unmaintained ports (see, for instance, the list on portsmon ). We are always looking for dedicated volunteers to adopt at least a few ports. 3. We can always use help with infrastructural enhancements. See the ports section of the list of projects and ideas . _________________________________________________________________ PowerPC Port URL: http://www.freebsd.org/platforms/ppc.html Contact: Peter Grehan The project is slowly starting to ramp up after a long move-induced hiatus. Alan Cox has almost completed making the pmap module Giant-free. _________________________________________________________________ Release Engineering URL: http://www.freebsd.org/releng/ URL: http://www.freebsd.org/releases/ URL: http://www.freebsd.org/snapshots/ Contact: Release Engineering Team The release engineering (RE) team announced the availability of FreeBSD 5.5 and 6.1, both in May 2006. FreeBSD 5.5 is the last planned release from the RELENG_5 branch in CVS. For the most part, its main features consist of bugfixes, security patches, and minor updates. We encourage users to move towards the 6.x series of releases whenever practical. FreeBSD 6.1 is the latest of the releases to come from the RELENG_6 branch in CVS. It includes (among many other things) improved support for WiFi devices, additional network and disk controller drivers, and a number of fixes for filesystem stability. The next release to be issued from this branch will be FreeBSD 6.2, which is currently scheduled for September 2006. The RE team is currently in a ``between releases'' mode. Current activities include working with security-team@ on some errata fixes for the RELENG_6_1 branch and producing snapshots of HEAD and RELENG_6 at the start of each month. Several personnel changes have taken place recently. Scott Long has stepped down from his position on the RE team; we thank him for his considerable efforts over the past four years. In his place, Ken Smith has taken over the role of lead release engineer. Bruce A. Mah has rejoined the RE team after a two-year sabbatical. _________________________________________________________________ SCTP Integration URL: http://www.sctp.org/ Contact: George Neville-Neil Contact: Randall Stewart For the last several months Randall Stewart has been working in HEAD and STABLE to get us ready to integrate the SCTP protocol (Stream Transmission Control Protocol) into FreeBSD. He is currently working on a patch to share with a wider audience but needs to do some integration work first. Randall has a provisional commit bit and will be working with gnn on getting code committed to the HEAD of the tree. Open tasks: 1. When this gets integrated it needs lots of testers. _________________________________________________________________ Sound subsystem improvements URL: http://people.FreeBSD.org/~ariff/ URL: http://www.FreeBSD.org/projects/ideas/ URL: http://www.leidinger.net/FreeBSD/hdac_20060525.tbz Contact: Ariff Abdullah Contact: Alexander Leidinger Contact: Multimedia Mailinglist Since the last status report we fixed some more bugs, added basic support for envy24 chips and cleaned up the source for the emu10kx driver in the ports to make it ready for import into the base system. We also got some patches with a little bit of infrastructure for Intel HDA support. It's not finished and also not usable by end users yet. Open tasks: 1. Have a look at the sound related entries on the ideas list. 2. sndctl(1): tool to control non-mixer parts of the sound system (e.g. spdif switching, virtual-3D effects) by an user (instead of the sysctl approach in -current); pcmplay(1), pcmrec(1), pcmutil(1). 3. Plugable FEEDER infrastructure. For ease of debugging various feeder stuff and/or as userland library and test suite. 4. Support for new hardware (envy24, Intel HDA). _________________________________________________________________ SSE2 Kernel support URL: http://www.freebsd.org/projects/ideas/#p-memcpy URL: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2006-05/msg00109. html Contact: Attilio Rao Some FPU system and kernel memcpy/copyin/copyout changes have been performed. In particular, a per-CPU save area has been introduced (protected with an interlock) in order to assure a stable saving mechanism. copyout/copyin have changed in order to use vectorised version of memcpy and an xmm version of memcpy has been provided. Open tasks: 1. Benchmarks on different versions of xmm copy, in particular showing differences between UP and SMP architectures (evaluating possibility to add block prefetch, non-temporal hints usage, etc.) 2. Modifying npxdna trap handler in order to recognise xmm environment usage and replace fxsave with 8-movdqa _________________________________________________________________ TrustedBSD Audit URL: http://www.TrustedBSD.org/audit.html Contact: Robert Watson Contact: Wayne Salamon Contact: Christian Peron TrustedBSD Audit provides fine-grained security event auditing in FreeBSD 7.x, with a planned merge to 6.x for FreeBSD 6.2. Work performed in the last three months: * Per audit pipe preselection allows IDS applications to configure audit record selection per-pipe, new auditpipe.4 document. * audit_submit library call to reduce complexity of adding audit support to applications. * Significant cleanup, bug fixing, locking improvements, token parsing and generation improvements. * Solaris subject token compatibility, extended address support. * Auditing of extended attributes calls, ACL support a work in progress. * OpenBSM 1.0 alpha 7 integrated into CVS. * OpenBSM test tools in progress. * Experimental auditeventd which allows shared object plug-ins to subscribe to live audit events via a shared pipe in order to support the easy authoring of simple intrusion detection and monitoring components. Open tasks: 1. Bring audit event daemon API and implementation to maturity. Currently these are not installed by default in the CVS-merged version. 2. Complete system call coverage. 3. Allow finer-grained configuration of what is audited: implement control flags regarding paths, execve arguments, environmental variables. 4. Support for auditing MAC policy data. 5. Additional user space application coverage, such as application layer audit events from adduser, rmuser, pw, etc. _________________________________________________________________ Update of the Linux userland infrastructure in the Ports Collection Contact: Boris Samorodov Contact: Alexander Leidinger Contact: Emulation Mailinglist We updated the default linux base port to Fedora Core 4 and the default linux X11 libs port to the X.org RPM in FC4. An update to FC5 or FC6 has to wait until the kernel got support for syscalls of a newer linux kernel. See the corresponding SoC project report for more. _________________________________________________________________ Wireless Networking Contact: Sam Leffler The wireless suport has been stable for a while so most work has focused on bug fixing and improving legacy drivers. Max Laier and I worked on improving support for Intel wireless cards. The results of this work included significant improvements to the iwi(4) driver (for 2195/2200 parts) and the firmware(9) facility for managing loadable device firmware. There is also an updated ipw(4) that has improvements similar to those done for iwi that is in early test. Support for the latest Intel devices, the 3945 pci-express cards, is planned for later this summer. Atheros support was updated with a new hal that fixes a few minor issues and provides known working builds for SPARC, PPC, and ARM platforms. There is also working MIPS support that will be used when the MIPS port is ready to test. Otherwise one useful bug was fixed that affected AP operation with associated stations operating in power save mode. wpa_supplicant and hostapd were updated to the latest stable build releases from Jouni Malinen. Experimental changes to support injection of raw 802.11 frames using bpf were posted for comment. This work was done in collaboration with Andrea Bittau. Open tasks: 1. Legacy drivers such as wi are languishing and need maintainers. This is prerequisite to bringing in new 802.11 features such as improved scanning and virtual ap. _________________________________________________________________ XFS for FreeBSD URL: http://people.freebsd.org/~rodrigc/xfs/ Contact: Russell Cattelan Contact: Alexander Kabaev Contact: Craig Rodrigues The XFS for FreeBSD project is an effort to port the publically available GPL'd sources to SGI's XFS filesystem to FreeBSD. In December, we imported a version of XFS into FreeBSD-CURRENT which allows FreeBSD to mount an XFS filesystem as read-only. As a side effort, we have been continuing on the work that PHK started to clean up the mount code in FreeBSD. We can use the existing FreeBSD mount(8) utility to mount an XFS partition, without introducing a new mount_xfs utility. Open tasks: 1. We need to implement support for writing to XFS partitions _________________________________________________________________ xscale board buy URL: http://www.gateworks.com/avila_gw2348_4.htm URL: http://www.netgate.com Contact: Sam Leffler With the help of Jim Thompson of Netgate ( http://www.netgate.com/ ) the FreeBSD Foundation arranged a purchase of xscale-based boards for folks interested in ARM support. Developers were able to purchase boards at a reduced cost. The goals were to accelerate and/or improve support for the ARM platform and to set forth at least one board as a reference platform for the ARM support. Netgate will be stocking lower-cost models of the board later in the year (a special order was made for boards with only 2 mini-pci slots). _________________________________________________________________ Legal Notices | =A9 1995-2006 The FreeBSD Project. All rights reserved. --Boundary-00=_CUCtEMHd7mLwLaH-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 22:46:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2102716A4DE for ; Tue, 11 Jul 2006 22:46:29 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 731FC43D45 for ; Tue, 11 Jul 2006 22:46:28 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 93403 invoked by uid 2001); 11 Jul 2006 22:46:27 -0000 Date: Tue, 11 Jul 2006 17:46:27 -0500 From: "Rick C. Petty" To: mag@intron.ac Message-ID: <20060711224627.GA93273@megan.kiwi-computer.com> References: <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1152642474.29859@origin.intron.ac> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 22:46:29 -0000 On Wed, Jul 12, 2006 at 02:25:21AM +0800, mag@intron.ac wrote: > > Matthias Andree wrote: > > Why would people write Windows application with rather MFC/ATL/.NET > Framework than direct Windows API? Because they like buggy code? (Not that the basic API is much better) > Why is gtkmm created for GTK+? Because they enjoy extremely long compile times? And they like wrappers around wrappers around wrappers? > Would you write a X11 application with original X11 API, without QT or > other X11 toolkits? Comparing KDE/Qt to GNOME/GTK+ is comparing C++ to C. I personally prefer the GTK API (GDK is quite similar to the X11 API) over Qt. My preference is mostly due to the overhead and complexity of C++. C++ and Java are great for Applications, not as much so for kernels. I don't mean to drag this into a KDE vs. GNOME flame war. Also this is not a fair comparison because these toolkits augment what X11 provides, much like how userland augments a kernel. Write the front-end in whatever language/toolkit you prefer; you're still calling Xlib to pass packets to/from the X server. > Good packages for various APIs are much easier to learn/debug than those > original APIs. What makes you say that C++ would provide a good API? I think perhaps the problem may be that the current kernel APIs in C are insufficient... but introducing the complexity of C++ both from a language perspective and from a standard library perspective seems silly to me. When on the device driver level, I would rather know precisely when my code is being called and manage my own memory, etc. and other nitty-gritty details. I agree that a good API is crucial! But I also believe that C provides this better than others. You can always write code in C++ which calls C functions, but the converse is quite tricky. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 23:03:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC4CB16A4DA for ; Tue, 11 Jul 2006 23:03:36 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id E80E743D46 for ; Tue, 11 Jul 2006 23:03:35 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 58999 invoked by uid 1001); 11 Jul 2006 23:03:34 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Tue, 11 Jul 2006 19:03:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17588.11845.706643.154947@bhuda.mired.org> Date: Tue, 11 Jul 2006 19:03:33 -0400 To: rick-freebsd@kiwi-computer.com In-Reply-To: <20060711224627.GA93273@megan.kiwi-computer.com> References: <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <20060711224627.GA93273@megan.kiwi-computer.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 23:03:36 -0000 In <20060711224627.GA93273@megan.kiwi-computer.com>, Rick C. Petty typed: > On Wed, Jul 12, 2006 at 02:25:21AM +0800, mag@intron.ac wrote: > > Good packages for various APIs are much easier to learn/debug than those > > original APIs. > What makes you say that C++ would provide a good API? Good point. About the only thing C++ has going for it as an OO language is popularity. If the goal is just to provide better API in the kernel, then there are certainly better languages to add. D comes to mind. I'd much rather write D than C++ - but that's got more to do with C++ than D, as it's true for most substitutes for D. But D is OO - done much better than C++ - and has a front end available for GCC. It may not be a good choice, as I haven't looked at it seriously. But I certainly wouldn't start trying to improve the FreeBDS kernel by adding support for a new language without doing so. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 19:00:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A50C616A4DD for ; Tue, 11 Jul 2006 19:00:40 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC69343D7F for ; Tue, 11 Jul 2006 19:00:35 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 04785F15B6 for ; Wed, 12 Jul 2006 03:00:34 +0800 (CST) X-KSVirus-check: 0 References: <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <20060711.101403.-928138940.imp@bsdimp.com> In-Reply-To: <20060711.101403.-928138940.imp@bsdimp.com> From: mag@intron.ac To: "M. Warner Losh" Date: Wed, 12 Jul 2006 02:57:20 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152644432.30488@origin.intron.ac> X-Mailman-Approved-At: Wed, 12 Jul 2006 00:08:09 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:00:40 -0000 M. Warner Losh wrote: > In message: <44B2D2DF.2000401@sh.cvut.cz> > V lav Haisman writes: > : Deciding that some features are bad beforehand, before you evaluate them > : is IMO bad idea. Let interested people write a bunch of C++ modules with > : the complete language before deciding on what shouldn't be used. > > There's actually a fair amount of experience with people doing C++ in > FreeBSD kernels. People have been doing things with it for about 8 > years now. There are significant performance issues with even C code > compiled as C++. It is possible to write fast C++ for kernel work, > but it is also very easy to write really bad C++ for kernel work. > Easier than bad C code. Currently, GNU CC has made great advance in binary code execution efficiency. And Intel C++ Compiler is also an excellent one. We can evaluate them by assemble code generated by them. I would repeat several sentences in my last reply. Why would people write Windows application with rather MFC/ATL/.NET Framework than direct Windows API? Why is gtkmm framework created for GTK+? Would you write a X11 application with original X11 API, without QT or other X11 toolkit? I believe the answer is that all programmers are human begins, not machines. Human programmer would reduce brainwork, even if an API package/wrapper slightly reduces running efficiency. > > There's reasons that people here are somewhat skeptical about using > C++ in the kernel. > > Warner > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 19:24:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9AAF16A4DD for ; Tue, 11 Jul 2006 19:24:54 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (smtp.x263.net [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 272DE43D6E for ; Tue, 11 Jul 2006 19:24:52 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 72436F17BC for ; Wed, 12 Jul 2006 03:24:52 +0800 (CST) X-KSVirus-check: 0 References: <200607111115.59844.jhb@freebsd.org> <20060711.103327.-8650905.imp@bsdimp.com> <200607111413.37238.jhb@freebsd.org> In-Reply-To: <200607111413.37238.jhb@freebsd.org> From: mag@intron.ac To: John Baldwin Date: Wed, 12 Jul 2006 03:21:53 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152645891.31335@origin.intron.ac> X-Mailman-Approved-At: Wed, 12 Jul 2006 00:08:20 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:24:54 -0000 John Baldwin wrote: > On Tuesday 11 July 2006 12:33, M. Warner Losh wrote: >> In message: <200607111115.59844.jhb@freebsd.org> >> John Baldwin writes: >> : and OS X both of which I've written a PCI driver for) we require device >> : driver writers to go through a lot more hoops to do certain things like >> : allocate resources. At the very least there is much that can be improved > in >> : our driver model. >> >> bus_alloc_resources goes a long ways in this respect. > > Yes, but in OS X I didn't even have to do that. All I had to do was ask it to > map a BAR if I wanted to use it. It already "allocated" all the resources > regardless. Windows was the same way (though a bit weirder, you get a > message that lists all your resources and you have to map them if you want to > use them). > > -- > John Baldwin Do you mean that the kernel pre-allocate resources for all devices whether a device has been attached by a device driver? Does BIOS do the same thing before OS boots? ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 19:26:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D839016A4E2 for ; Tue, 11 Jul 2006 19:26:10 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32710.mail.mud.yahoo.com (web32710.mail.mud.yahoo.com [68.142.207.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 3296E43D5F for ; Tue, 11 Jul 2006 19:26:10 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 14146 invoked by uid 60001); 11 Jul 2006 19:26:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=S5PH14BlyZ4l9h0Pr8iIbdToanebTUZXHZJd7ufYs7fe8urd9uu6z7Pe0MLaYPtVPqR0bCuOTbUAYJc7k2xJZos2N3UaeKOFLIrOw19QAcBKrSxyvwqxAbrHzd4E69IZn74UxMV8qbJ7RrPwWuHI/s2dvPhwXAdXyk9p+Aq9dxY= ; Message-ID: <20060711192609.14144.qmail@web32710.mail.mud.yahoo.com> Received: from [200.118.70.231] by web32710.mail.mud.yahoo.com via HTTP; Tue, 11 Jul 2006 21:26:09 CEST Date: Tue, 11 Jul 2006 21:26:09 +0200 (CEST) From: To: freebsd-hackers@freebsd.org, mag@intron.ac MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailman-Approved-At: Wed, 12 Jul 2006 00:08:38 +0000 Cc: Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:26:11 -0000 FWIW and just IMHO; I think it would be really nice to have the IOKit, or a lookalike that uses kobj(), available on FreeBSD. Another interesting experiment that I've mentioned before is OpenBFS: http://www.bug-br.org.br/openbfs/index.phtml?section=development "OpenBFS, as all file systems under BeOS, is being developed as a kernel add-on. Unlike all other file systems (and kernel add-ons in general), it is being developed in C++. Contrary to popular belief, it is possible to use C++ in the kernel provided you play by the book and follow some rules: - No exceptions - (Almost) no virtuals (well, the Query code in OpenBFS uses them) - It's basically only the C++ syntax, and type checking - Since one tend to encapsulate everything in classes, it has a slightly higher memory overhead This is acceptable as we get some benefits out of it: - Nicer code - Easier to maintain " cheers, Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 01:54:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99B9A16A4DA for ; Wed, 12 Jul 2006 01:54:06 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2258843D49 for ; Wed, 12 Jul 2006 01:54:05 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6C1rvlA020032; Tue, 11 Jul 2006 21:53:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <17588.11845.706643.154947@bhuda.mired.org> References: <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <20060711224627.GA93273@megan.kiwi-computer.com> <17588.11845.706643.154947@bhuda.mired.org> Date: Tue, 11 Jul 2006 21:53:56 -0400 To: Mike Meyer , rick-freebsd@kiwi-computer.com From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-hackers@freebsd.org, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 01:54:06 -0000 At 7:03 PM -0400 7/11/06, Mike Meyer wrote: >In <20060711224627.GA93273@megan.kiwi-computer.com>, Rick C. Petty > typed: >> On Wed, Jul 12, 2006 at 02:25:21AM +0800, mag@intron.ac wrote: > > > Good packages for various APIs are much easier to learn/debug > > > than those original APIs. > > > What makes you say that C++ would provide a good API? > >Good point. About the only thing C++ has going for it as an OO >language is popularity. If the goal is just to provide better API >in the kernel, then there are certainly better languages to add. > >D comes to mind. I'd much rather write D than C++ - but that's >got more to do with C++ than D, as it's true for most substitutes >for D. But D is OO - done much better than C++ - and has a front >end available for GCC. This would be an interesting idea. I haven't used D for anything myself, but some friends of mine have and think that it is quite good. They say the available libraries are still "a little thin" in what they implement, but maybe it'd be better to start with some kind of "thin" environment, and see how that works out. I guess that wouldn't help out much with supporting IOKit, though, if IOKit is already written using C++. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 02:06:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78AAD16A4DD for ; Wed, 12 Jul 2006 02:06:28 +0000 (UTC) (envelope-from raistlin@tacorp.net) Received: from mail.tacorp.net (mail.tacorp.net [64.254.140.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97ADB43D46 for ; Wed, 12 Jul 2006 02:06:18 +0000 (GMT) (envelope-from raistlin@tacorp.net) Received: from localhost (localhost [127.0.0.1]) by mail.tacorp.net (Postfix) with ESMTP id 1E8D31B5032; Tue, 11 Jul 2006 22:06:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at tacorp.net Received: from mail.tacorp.net ([127.0.0.1]) by localhost (mail.tacorp.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxRMJTxD5Na1; Tue, 11 Jul 2006 22:06:15 -0400 (EDT) Received: by mail.tacorp.net (Postfix, from userid 1002) id D884E1B5027; Tue, 11 Jul 2006 22:06:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.tacorp.net (Postfix) with ESMTP id D530A1B5008; Tue, 11 Jul 2006 22:06:15 -0400 (EDT) Date: Tue, 11 Jul 2006 22:06:15 -0400 (EDT) From: Jason Slagle To: mag@intron.ac In-Reply-To: <1152644432.30488@origin.intron.ac> Message-ID: <20060711220348.X4444@mail.tacorp.net> References: <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <20060711.101403.-928138940.imp@bsdimp.com> <1152644432.30488@origin.intron.ac> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 02:06:28 -0000 On Wed, 12 Jul 2006, mag@intron.ac wrote: > I would repeat several sentences in my last reply. > Why would people write Windows application with rather MFC/ATL/.NET Framework > than direct Windows API? Why is gtkmm framework created for GTK+? Would you > write a X11 application with original X11 API, without QT or other X11 > toolkit? > I believe the answer is that all programmers are human begins, not > machines. Human programmer would reduce brainwork, even if an API > package/wrapper slightly reduces running efficiency. And this is why office 2003 takes longer to load on a 2.4ghz machine then office 97 did on a 233. I don't think that is a comparison you can safely make and retain any creditability. If you want to keep the changes you made in a local tree or a p4 tree or whatever, and show us we're all wrong when you're done, thats fine. But expecting committers to drop your code into the tree for such a purpose is silly. Jason -- Jason Slagle /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 03:01:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1AB516A4DE for ; Wed, 12 Jul 2006 03:01:56 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (smtp.x263.net [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA05543D68 for ; Wed, 12 Jul 2006 03:01:53 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 345BEF1977 for ; Wed, 12 Jul 2006 11:01:56 +0800 (CST) X-KSVirus-check: 0 References: <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <20060711.101403.-928138940.imp@bsdimp.com> <1152644432.30488@origin.intron.ac> <20060711220348.X4444@mail.tacorp.net> In-Reply-To: <20060711220348.X4444@mail.tacorp.net> From: "Intron" To: Jason Slagle Date: Wed, 12 Jul 2006 10:57:09 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152673311.40364@origin.intron.ac> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 03:01:56 -0000 Jason Slagle wrote: > On Wed, 12 Jul 2006, mag@intron.ac wrote: > >> I would repeat several sentences in my last reply. >> Why would people write Windows application with rather MFC/ATL/.NET >> Framework than direct Windows API? Why is gtkmm framework created for >> GTK+? Would you write a X11 application with original X11 API, without QT >> or other X11 toolkit? I believe the answer is that all programmers are >> human begins, not >> machines. Human programmer would reduce brainwork, even if an API >> package/wrapper slightly reduces running efficiency. > > And this is why office 2003 takes longer to load on a 2.4ghz machine then > office 97 did on a 233. > > I don't think that is a comparison you can safely make and retain any > creditability. > > If you want to keep the changes you made in a local tree or a p4 tree or > whatever, and show us we're all wrong when you're done, thats fine. But > expecting committers to drop your code into the tree for such a purpose is > silly. > > Jason > > > -- > Jason Slagle > /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > \ / ASCII Ribbon Campaign . > X - NO HTML/RTF in e-mail . > / \ - NO Word docs in e-mail . > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Why don't you say that Office 2003 is more powerful than Office 97? We are discussing C++ and other object-oriented encapsulation for kernel module here. If you want to complain that your Office 2003 is slower than Office 97, please leave your grouse for Microsoft technical support staff. You even haven't known what we are discussing and what I would commit. Actually my patches has little relationship to C++. Read previous mails first before your great speech here! ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 02:59:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E5BD16A4E9 for ; Wed, 12 Jul 2006 02:59:02 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C1D743D5F for ; Wed, 12 Jul 2006 02:58:59 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 7894FF193D for ; Wed, 12 Jul 2006 10:59:00 +0800 (CST) X-KSVirus-check: 0 References: <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <20060711.101403.-928138940.imp@bsdimp.com> <1152644432.30488@origin.intron.ac> <20060711220348.X4444@mail.tacorp.net> In-Reply-To: <20060711220348.X4444@mail.tacorp.net> From: mag@intron.ac To: Jason Slagle Date: Wed, 12 Jul 2006 10:57:09 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152673136.40289@origin.intron.ac> X-Mailman-Approved-At: Wed, 12 Jul 2006 03:08:29 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 02:59:02 -0000 Jason Slagle wrote: > On Wed, 12 Jul 2006, mag@intron.ac wrote: > >> I would repeat several sentences in my last reply. >> Why would people write Windows application with rather MFC/ATL/.NET >> Framework than direct Windows API? Why is gtkmm framework created for >> GTK+? Would you write a X11 application with original X11 API, without QT >> or other X11 toolkit? I believe the answer is that all programmers are >> human begins, not >> machines. Human programmer would reduce brainwork, even if an API >> package/wrapper slightly reduces running efficiency. > > And this is why office 2003 takes longer to load on a 2.4ghz machine then > office 97 did on a 233. > > I don't think that is a comparison you can safely make and retain any > creditability. > > If you want to keep the changes you made in a local tree or a p4 tree or > whatever, and show us we're all wrong when you're done, thats fine. But > expecting committers to drop your code into the tree for such a purpose is > silly. > > Jason > > > -- > Jason Slagle > /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > \ / ASCII Ribbon Campaign . > X - NO HTML/RTF in e-mail . > / \ - NO Word docs in e-mail . > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Why don't you say that Office 2003 is more powerful than Office 97? We are discussing C++ and other object-oriented encapsulation for kernel module here. If you want to complain that your Office 2003 is slower than Office 97, please leave your grouse for Microsoft technical support staff. You even haven't known what we are discussing and what I would commit. Actually my patches has little relationship to C++. Read previous mails first before your great speech here! ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 08:10:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 036B816A4DA; Wed, 12 Jul 2006 08:10:53 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from diri.bris.ac.uk (diri.bris.ac.uk [137.222.10.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FBFE43D46; Wed, 12 Jul 2006 08:10:52 +0000 (GMT) (envelope-from jan.grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by diri.bris.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1G0Zo1-0005eJ-UC; Wed, 12 Jul 2006 09:10:51 +0100 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:50257) by mail.ilrt.bris.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50) id 1G0Znq-00020Z-Qj; Wed, 12 Jul 2006 09:10:44 +0100 Date: Wed, 12 Jul 2006 09:10:33 +0100 (BST) From: Jan Grant X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: Attilio Rao In-Reply-To: <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> Message-ID: <20060712090552.Q82414@tribble.ilrt.bris.ac.uk> References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spamassassin: mail.ilrt.bris.ac.uk X-Spam-Score: 0.0 X-Spam-Level: / X-Spam-Score: -1.4 X-Spam-Level: - Cc: freebsd-hackers@freebsd.org, "mag@intron.ac" Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 08:10:53 -0000 On Tue, 11 Jul 2006, Attilio Rao wrote: > Even if I have no proof-of-concepts (so maybe somebody can show that > this is not fair), if we have setjmp/longjmp in the kernel we can have > a correct exception handling mechanism without not great problems. You'd think that, but at least one issue is that not all kernel resources are manageable via RAII*. So whilst you might be able to stack unwind, you're still left with a really hairy resource management problem - potentially at every frame - which often doesn't improve on the error checking and throwing idioms as expressed in C. I think it'd be interesting to try to address this but "I don't think you want to start from here". jan * for the non-C++ buffs, "Resource Acquisition Is Initialisation": using automatic variables of types with destructors that clean up the underlying resources when they go out of scope. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ YKYBPTMRogueW... you try to move diagonally in vi. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 08:40:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7774616A4DD for ; Wed, 12 Jul 2006 08:40:24 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1281D43D45 for ; Wed, 12 Jul 2006 08:40:23 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by wr-out-0506.google.com with SMTP id 69so63270wri for ; Wed, 12 Jul 2006 01:40:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=UGWP78Vlv5e/7ZHJ0VcXNOUGtl1aK21GydNL8oIKDM85MjVcCGY7Qu9oBY3T+K+KzLNrdD8RI+6gR+liVH3ZF+avg9NJAzYbDVH21WIdBA1rVf3rZODzP0gIqCPQglH72VbzczAB3vTxhdeOILgqHbKI+t54rIScPXLbjXRAONc= Received: by 10.82.103.11 with SMTP id a11mr31335buc; Wed, 12 Jul 2006 01:40:23 -0700 (PDT) Received: by 10.78.43.9 with HTTP; Wed, 12 Jul 2006 01:40:23 -0700 (PDT) Message-ID: <8e96a0b90607120140u22f8ee01h9370dcaa1a4763c5@mail.gmail.com> Date: Wed, 12 Jul 2006 09:40:23 +0100 From: "mal content" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: /boot/boot, where? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 08:40:24 -0000 Can anybody tell me where /boot/boot is built in the source tree? I'm trying to put together a customised bootable image for qemu but can't find this missing piece. MC From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 08:51:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E92AB16A4DE for ; Wed, 12 Jul 2006 08:51:00 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4799343D46 for ; Wed, 12 Jul 2006 08:51:00 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2A6872088; Wed, 12 Jul 2006 10:50:56 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 9E8DC2085; Wed, 12 Jul 2006 10:50:55 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 7992E33C31; Wed, 12 Jul 2006 10:50:55 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "mal content" References: <8e96a0b90607120140u22f8ee01h9370dcaa1a4763c5@mail.gmail.com> Date: Wed, 12 Jul 2006 10:50:55 +0200 In-Reply-To: <8e96a0b90607120140u22f8ee01h9370dcaa1a4763c5@mail.gmail.com> (mal content's message of "Wed, 12 Jul 2006 09:40:23 +0100") Message-ID: <86lkqzdx5c.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: /boot/boot, where? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 08:51:01 -0000 "mal content" writes: > Can anybody tell me where /boot/boot is built in the source > tree? src/sys/boot DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 08:55:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 032F216A4DA for ; Wed, 12 Jul 2006 08:55:47 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86E5843D46 for ; Wed, 12 Jul 2006 08:55:46 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by wr-out-0506.google.com with SMTP id 69so66172wri for ; Wed, 12 Jul 2006 01:55:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mwn6m5ZJGoU/1O6c9ibOxsD/fYwMe48AqzW+1JWfr1mmp5DSAb7VpWODdDAl6VfjhOyTOqyIvnPI7Ubriy2a0YVmIe/gSU8DxEZSlGs9GGbCGUiG607xr9S0S0V2iwqoFA2miPZpEx/jgmKQ+kqzgOTUIuYtfSkCGCvKPtpLvmg= Received: by 10.82.103.11 with SMTP id a11mr33316buc; Wed, 12 Jul 2006 01:55:45 -0700 (PDT) Received: by 10.78.43.9 with HTTP; Wed, 12 Jul 2006 01:55:45 -0700 (PDT) Message-ID: <8e96a0b90607120155j417be96dr59f94bf392969c3a@mail.gmail.com> Date: Wed, 12 Jul 2006 09:55:45 +0100 From: "mal content" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lkqzdx5c.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8e96a0b90607120140u22f8ee01h9370dcaa1a4763c5@mail.gmail.com> <86lkqzdx5c.fsf@xps.des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: /boot/boot, where? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 08:55:47 -0000 On 12/07/06, Dag-Erling Sm=F8rgrav wrote: > "mal content" writes: > > Can anybody tell me where /boot/boot is built in the source > > tree? > > src/sys/boot > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > Argh! I must have looked just about everywhere else... thanks! MC From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 09:00:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CF6F16A4DE for ; Wed, 12 Jul 2006 09:00:36 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id C337D43D49 for ; Wed, 12 Jul 2006 09:00:34 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6C90JZ0018273 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jul 2006 19:00:24 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6C90Jab002103; Wed, 12 Jul 2006 19:00:19 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6C90J9o002102; Wed, 12 Jul 2006 19:00:19 +1000 (EST) (envelope-from peter) Date: Wed, 12 Jul 2006 19:00:19 +1000 From: Peter Jeremy To: pfgshield-freebsd@yahoo.com Message-ID: <20060712090019.GA723@turion.vk2pj.dyndns.org> References: <20060711192609.14144.qmail@web32710.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20060711192609.14144.qmail@web32710.mail.mud.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 09:00:36 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Jul-11 21:26:09 +0200, pfgshield-freebsd@yahoo.com wrote: >I think it would be really nice to have the IOKit, or a lookalike that uses >kobj(), available on FreeBSD. Another interesting experiment that I've >mentioned before is OpenBFS: I think the general concensus is that it's up to one of the proponents of this to actually implement it and demonstrate that it works and has no undesirable side-effects. >http://www.bug-br.org.br/openbfs/index.phtml?section=3Ddevelopment =2E.. >- Nicer code=20 >- Easier to maintain=20 These are both very subjective. For someone who isn't comfortable with C++, I doubt either are true. --=20 Peter Jeremy --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEtLoi/opHv/APuIcRAuUzAJsHXDWw9E8jHe29Y6frjfqKlz6saQCfcvPr Fom48m482FPSNhHFmghCc5Q= =Aex4 -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 08:06:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1004716A4DE; Wed, 12 Jul 2006 08:06:15 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10D3843D53; Wed, 12 Jul 2006 08:06:13 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D619.dip.t-dialin.net [84.165.214.25]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k6C7uoZ9011943; Wed, 12 Jul 2006 09:56:50 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k6C86CUv094262; Wed, 12 Jul 2006 10:06:12 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 12 Jul 2006 10:06:12 +0200 Message-ID: <20060712100612.o2ne00ezs0og4ckg@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 12 Jul 2006 10:06:12 +0200 From: Alexander Leidinger To: "M. Warner Losh" References: <868xn0z8w9.fsf@xps.des.no> <1152629241.24779@origin.intron.ac> <20060711.103203.635732778.imp@bsdimp.com> In-Reply-To: <20060711.103203.635732778.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Wed, 12 Jul 2006 11:31:16 +0000 Cc: freebsd-hackers@freebsd.org, joel@freebsd.org Subject: improving drivers (was: Re: kern/99979: Get Ready for Kernel Module in C++) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 08:06:15 -0000 Quoting "M. Warner Losh" (from Tue, 11 Jul 2006 10:32:03 -0600 (MDT)): > As to your other points, the resource allocation repetition has been > improved with bus_alloc_resources. the trouble is that many drivers > haven't been converted to use the new api. Would you please come up with a plain text version what needs to be done suitable for our ideas list (http://www.freebsd.org/projects/ideas/)? It sounds like a junior kernel hacker task and so far we get a lot of good results out of the ideas list. Bye, Alexander. -- "You can't have everything. Where would you put it?" -- Steven Wright http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 11:35:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60A6C16A4DE for ; Wed, 12 Jul 2006 11:35:29 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D539543D46 for ; Wed, 12 Jul 2006 11:35:28 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 9DE3F35707 for ; Wed, 12 Jul 2006 13:35:27 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 3D08D6D139; Wed, 12 Jul 2006 13:35:16 +0200 (CEST) Date: Wed, 12 Jul 2006 13:35:16 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20060712113516.GC2162@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> User-Agent: Mutt/1.5.11 Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 11:35:29 -0000 On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote: > Even if I have no proof-of-concepts (so maybe somebody can show that > this is not fair), if we have setjmp/longjmp in the kernel we can have > a correct exception handling mechanism without not great problems. ROFL. Sorry, but using setjmp/longjmp is one of the worst possible implementation of exceptions since it is very expensive for the hot path, where you don't expect exceptions. They are called "exception" for a reason. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 13:03:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1865A16A4DA for ; Wed, 12 Jul 2006 13:03:11 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B5EA43D4C for ; Wed, 12 Jul 2006 13:03:10 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so231835pyc for ; Wed, 12 Jul 2006 06:03:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Em29SxAu7dWCuYCYMIiJRtJOEwHFsCbCpp47cyYZmMkVaar1EnmnEGWTorXg4mNlpDtzjEWdLxBOIT8HIkbImzMIaokdlJ9N7VDC35XfZwSIEO3RMOfYoMMmsPIkd7chwvprMjsV4/Gi8x0Zu3pAPhDivHF7i9VGH786oOgg/gg= Received: by 10.35.111.14 with SMTP id o14mr784680pym; Wed, 12 Jul 2006 06:03:09 -0700 (PDT) Received: by 10.35.34.9 with HTTP; Wed, 12 Jul 2006 06:03:09 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 18:33:09 +0530 From: "Kamal R. Prasad" Sender: kamalpr@gmail.com To: freebsd-hackers@freebsd.org In-Reply-To: <20060712113516.GC2162@britannica.bec.de> MIME-Version: 1.0 References: <44B2D2DF.2000401@sh.cvut.cz> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> X-Google-Sender-Auth: 31e2d612aa466499 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 13:03:11 -0000 On 7/12/06, Joerg Sonnenberger wrote: > On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote: > > Even if I have no proof-of-concepts (so maybe somebody can show that > > this is not fair), if we have setjmp/longjmp in the kernel we can have > > a correct exception handling mechanism without not great problems. > > ROFL. Sorry, but using setjmp/longjmp is one of the worst possible > implementation of exceptions since it is very expensive for the hot > path, where you don't expect exceptions. They are called "exception" for > a reason. so how is exception handling in C++ more efficient than setjmp()/longjmp() -in either paths? thanks -kamal > Joerg > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 13:21:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6525816A4DD for ; Wed, 12 Jul 2006 13:21:15 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A222C43D45 for ; Wed, 12 Jul 2006 13:21:14 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 38B2835707 for ; Wed, 12 Jul 2006 15:21:11 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id B09F96D214; Wed, 12 Jul 2006 15:20:59 +0200 (CEST) Date: Wed, 12 Jul 2006 15:20:59 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20060712132059.GA3906@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 13:21:15 -0000 On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote: > On 7/12/06, Joerg Sonnenberger wrote: > > >On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote: > >> Even if I have no proof-of-concepts (so maybe somebody can show that > >> this is not fair), if we have setjmp/longjmp in the kernel we can have > >> a correct exception handling mechanism without not great problems. > > > >ROFL. Sorry, but using setjmp/longjmp is one of the worst possible > >implementation of exceptions since it is very expensive for the hot > >path, where you don't expect exceptions. They are called "exception" for > >a reason. > > > so how is exception handling in C++ more efficient than setjmp()/longjmp() > -in either paths? The common implementations are based on two assumptions: - try {} is used often through out the tree and nested - exceptions are raised seldomly. This means that the desire to catch an exception should be cheap and the implementation optimised for that. What happens is that the compiler creates a table which allows automatic stack unwinding and matching of the instruction pointers. The former is necessary to handle frame pointer vs. frame pointer-less stack frames, the latter is used to determine where an exception should be cought. Consider: void bar() { throw "foo"; } void foo() { try { bar(); } catch(...) { cerr << "error"; } } (don't try that, I haven't written C++ for ages) The compiler creates: - an entry for the range of bar to annotate that it doesn't have use a frame pointer - an entry for foo, with the same annotation - the address when bar is called in foo (or the address directly following) to annotate that it should jump to catch, when an exception is raised. When an exception is raised, it looks at the current instruction pointer and begins unwinding the stack until a catch is found. This can be relatively cheap compared to longjmp, since the register content does not have to be restored. It does not add any slowdown, as long as exceptions are not raised. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 14:10:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CEFD16A4DE for ; Wed, 12 Jul 2006 14:10:48 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32707.mail.mud.yahoo.com (web32707.mail.mud.yahoo.com [68.142.207.251]) by mx1.FreeBSD.org (Postfix) with SMTP id 0B3BE43D6A for ; Wed, 12 Jul 2006 14:10:43 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 35241 invoked by uid 60001); 12 Jul 2006 14:10:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=a1ZgO1j52bm28ly82gndVWUBCbVcfZBUw1XFCBbr8iS/GGILSm7Il2OJby5tl+FG2QxspTrktDHSaXphpddJ7GtHyX7V7DnET5YvRoPGuTVL/CSCwYb1HKCcWopANF0r06RsQkCM7DstVYDmQrg7ppjJ4kXAEzTKstZzHeIrZNk= ; Message-ID: <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> Received: from [200.118.70.231] by web32707.mail.mud.yahoo.com via HTTP; Wed, 12 Jul 2006 16:10:29 CEST Date: Wed, 12 Jul 2006 16:10:29 +0200 (CEST) From: To: Peter Jeremy In-Reply-To: <20060712090019.GA723@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailman-Approved-At: Wed, 12 Jul 2006 14:19:20 +0000 Cc: freebsd-hackers@freebsd.org, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 14:10:48 -0000 --- Peter Jeremy ha scritto: ... > > I think the general concensus is that it's up to one of the proponents > of this to actually implement it and demonstrate that it works and has > no undesirable side-effects. > I only wanted to point out that Darwin modules are not the only port candidates that want to use C++. While existing code will not be revamped to C++, we must weight exactly what we find acceptable for use in the kernel, and I'm glad the people doing the port brought this up before expecting to commit undesired features. > >http://www.bug-br.org.br/openbfs/index.phtml?section=development > ... > >- Nicer code > >- Easier to maintain > > These are both very subjective. For someone who isn't comfortable with > C++, I doubt either are true. > Yes. it's subjective. I admitedly prefer C over C++, and I'm glad to have kobj() but it remains to be seen if it can really replace C++ for all our needs. C++ is the de-facto standard for OO: a lot of people know how to use it and since it was always meant to be an extension to C, C programs are expected to build just the same (I know ... C99 broke some of this). cheers, Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 14:28:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD71F16A4DE for ; Wed, 12 Jul 2006 14:28:10 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 11E9D43D45 for ; Wed, 12 Jul 2006 14:28:09 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 67079 invoked by uid 1001); 12 Jul 2006 14:28:09 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Wed, 12 Jul 2006 10:28:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17589.1784.567790.215719@bhuda.mired.org> Date: Wed, 12 Jul 2006 10:28:08 -0400 To: pfgshield-freebsd@yahoo.com In-Reply-To: <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: mag@intron.ac, freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 14:28:10 -0000 In <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com>, pfgshield-freebsd@yahoo.com typed: > C++ is the de-facto standard for OO: a lot of people know how to use it Oh gods, does this bring to mind lots (and *lots*) of scathing commentary. I'll restrict myself to just one: Windows is the de-facto standard OS: a lot of people know how to use it. We're bright enough to know that popularity doesn't imply technical excellence, otherwise we wouldn't be on a FreeBSD list. Having avoided that trap in the choice of platform, doesn't it behoove us to avoid it elswhere? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 14:48:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE16316A4DA for ; Wed, 12 Jul 2006 14:48:33 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 15B5043D46 for ; Wed, 12 Jul 2006 14:48:28 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 99502 invoked by uid 2001); 12 Jul 2006 14:48:27 -0000 Date: Wed, 12 Jul 2006 09:48:27 -0500 From: "Rick C. Petty" To: pfgshield-freebsd@yahoo.com Message-ID: <20060712144827.GA99296@megan.kiwi-computer.com> References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 14:48:33 -0000 On Wed, Jul 12, 2006 at 04:10:29PM +0200, pfgshield-freebsd@yahoo.com wrote: > > C++ is the de-facto standard for OO That is just sad. So many other languages do a much better job of implementing OO (Smalltalk, Java, Python, even Scheme). While we're at it, why not implement a bytecode interpreter for all of these languages into the kernel? That would be sweet.. I'm being facetious here; OO has some merit but aside from that, there's very little utility an additional language can provide. Granted, it's easier (read: lazier) to use: try { ... } catch (...) ... than it is to do: error = some_fn_which_could_error(); if (error) return error; ... While I haven't looked at kobj, I have seen some good implementations of OO in plain C (GTK's gobject comes to mind). I believe at least basic OO framework is available and doesn't require a huge performance hit, as undoubtedly a C++ solution would provide (at least from my experience). For all C++ gives you, I believe the potential is there to do the same things in C. I'm all for making kernel code free of C++ reserved words (although I'd recommend changing "new" to "new_obj", etc. instead of "_new" or similar). This would allow C++ developers to write drivers and such. But I don't feel there is any benefit to commit C++ code into the "pristine" kernel source. Also, I thought the C++ "standard" was still being argued about and thus is incomplete?? (I certainly know there are C-isms which don't appear in any C++ standard as of yet) Not to pick on the gcc/g++ folks, but it's difficult to find a decent C++ compiler which implements all/most of the language standard and also reliably compiles/cross-compiles on various systems. OTOH, gcc does an excellent job! For this reason, BSD shouldn't bend over backwards for C++ developers any more than it should for Python or Ruby developers. The implied stability and consistency of a finished language is exactly what is needed for a stable and consistent OS (kernel). Pick a language (let's call it "C") that isn't likely to evolve any further. Oh wait, we already did :-P -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 15:46:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8330216A4DF for ; Wed, 12 Jul 2006 15:46:44 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id C001043D9A for ; Wed, 12 Jul 2006 15:46:43 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 68119 invoked by uid 1001); 12 Jul 2006 15:46:42 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Wed, 12 Jul 2006 11:46:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17589.6498.456179.132004@bhuda.mired.org> Date: Wed, 12 Jul 2006 11:46:42 -0400 To: rick-freebsd@kiwi-computer.com In-Reply-To: <20060712144827.GA99296@megan.kiwi-computer.com> References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> <20060712144827.GA99296@megan.kiwi-computer.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, pfgshield-freebsd@yahoo.com Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 15:46:44 -0000 In <20060712144827.GA99296@megan.kiwi-computer.com>, Rick C. Petty typed: > On Wed, Jul 12, 2006 at 04:10:29PM +0200, pfgshield-freebsd@yahoo.com wrote: > > C++ is the de-facto standard for OO > That is just sad. So many other languages do a much better job of > implementing OO (Smalltalk, Java, Python, even Scheme). While we're at > it, why not implement a bytecode interpreter for all of these languages > into the kernel? That would be sweet.. Who needs a byte code interpreter? My favorite Scheme implementation (back when I wrote a lot of Scheme) was DECWRL's Scheme->C, which compiled Scheme to C. Likewise, most Eiffel implementations (if you want a good OO langauge, that's the one I'd pick) compile to C. Of course, the right way to access those languages from the kernel is to put stubs in the kernel to call userland code to do the work, as has already been suggested. That works. There are file systems written in Python. > I'm being facetious here; OO has some merit but aside from that, there's > very little utility an additional language can provide. Not true. I'll take a moment to point out that my comments about not picking C++ just because it's popular apply to OO as well. The functional programming folks make a good argument that their style is as or more productive than OO - at least for people who understand it. In particular, the high-end functional languages provide facilities that don't exist in most languages: a turing complete system for code creation at compile time. Ok, C++'s STL has it, but it's *really* hard to use, and I don't think anyone wants STL in the kernel. > For this reason, BSD shouldn't bend over backwards for C++ developers any > more than it should for Python or Ruby developers. The implied stability > and consistency of a finished language is exactly what is needed for a > stable and consistent OS (kernel). Pick a language (let's call it "C") > that isn't likely to evolve any further. Oh wait, we already did :-P I know you're kidding, but someone might not realize it. BSD Unix didn't pick C; we inherited it from AT&T Unix. K&R didn't pick C either; they wrote it so they'd have a good high-level (well, for the time) language for writing systems code in. It evolved significantly well after the first kernels were written in it (anyone else remember =+?). In fact, it evolved to meet the needs of the peoplel writing code in it. This argues for picking a *less* popular/stable language than C++: BSD would be a bigger part of the community, and thus have more say in how the language evolved. And, to reference back to your comment about interpreters, the predecessor to C was B, which was interpreted. The predecessor to B was BCPL, which is why the successor to C should be P, not D. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 16:08:04 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E320916A4EE for ; Wed, 12 Jul 2006 16:08:04 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B15B43D58 for ; Wed, 12 Jul 2006 16:08:01 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (uhktgb@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6CG7suB029651; Wed, 12 Jul 2006 18:08:00 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6CG7sdG029650; Wed, 12 Jul 2006 18:07:54 +0200 (CEST) (envelope-from olli) Date: Wed, 12 Jul 2006 18:07:54 +0200 (CEST) Message-Id: <200607121607.k6CG7sdG029650@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, rick-freebsd@kiwi-computer.com In-Reply-To: <20060712144827.GA99296@megan.kiwi-computer.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 12 Jul 2006 18:08:00 +0200 (CEST) Cc: Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 16:08:05 -0000 Rick C. Petty wrote: > pfgshield-freebsd@yahoo.com wrote: > > > > C++ is the de-facto standard for OO > > That is just sad. So many other languages do a much better job of > implementing OO (Smalltalk, Java, Python, even Scheme). That's true. At OOPSLA '97, Alan Kay (an OO pioneer) said: "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." However, none of the languages you mentioned is really well- suited for FreeBSD kernel development. Just for the record, there are a lot of C-like languages that could be used, in theory. For example Objective-C (which has a nice, Smalltalk-like OO implementation, and it is even completely backwards-compatible to C). Another neat language is Cyclone ( http://cyclone.thelanguage.org ), which is intended to be a "safe" dialect of C, because it prevents buffer overflows, dangling pointer accesses etc., and even has modern features such as pattern matching and type inference, and it even borrowed a few things from C++ (it uses gcc as the backend and is easy to interface with standard C code). Note that I do _not_ imply to actually use any of the above mentioned languages for FreeBSD kernel programming. Perso- nally I prefer to stick with plain C. > I'm all for making kernel code free of C++ reserved words (although I'd > recommend changing "new" to "new_obj", etc. instead of "_new" or similar). > This would allow C++ developers to write drivers and such. But I don't > feel there is any benefit to commit C++ code into the "pristine" kernel > source. The biggest problem is that using C++ code in the kernel would reduce the number of potential maintainers signifi- cantly. It would also make debugging more difficult, especially for non-experts who try to submit useful PRs. That's a very important point to consider. Just my 2 cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 14:50:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B4C016A4DD for ; Wed, 12 Jul 2006 14:50:10 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32701.mail.mud.yahoo.com (web32701.mail.mud.yahoo.com [68.142.207.245]) by mx1.FreeBSD.org (Postfix) with SMTP id 9029443D46 for ; Wed, 12 Jul 2006 14:50:09 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 79161 invoked by uid 60001); 12 Jul 2006 14:50:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=POitKmmdnVVy6rPqQ3URQkW5Z2Qvp2ey5T/yPRTVqk7E532TU1xd1CTpvGX5pNjs+c0hx8QnxOGCDB/kHNVa7KVhmazrl6nInA5KVgQAGoGy5Ran99f0dlmiSpDH22oesErvZC4UD4w2njSibdhbclckQjAgCtT4AHdAouTgP6o= ; Message-ID: <20060712145009.79159.qmail@web32701.mail.mud.yahoo.com> Received: from [200.118.70.231] by web32701.mail.mud.yahoo.com via HTTP; Wed, 12 Jul 2006 16:50:09 CEST Date: Wed, 12 Jul 2006 16:50:09 +0200 (CEST) From: To: Mike Meyer In-Reply-To: <17589.1784.567790.215719@bhuda.mired.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailman-Approved-At: Wed, 12 Jul 2006 16:40:12 +0000 Cc: mag@intron.ac, freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 14:50:10 -0000 --- Mike Meyer ha scritto: ... > > Windows is the de-facto standard OS: a lot of people know how to use > it. > Well... I wish several commercial CAD software producers thought otherwise. > We're bright enough to know that popularity doesn't imply technical > excellence, otherwise we wouldn't be on a FreeBSD list. Having avoided > that trap in the choice of platform, doesn't it behoove us to avoid it > elswhere? > Is someone still using SPIN/modula?? ;-). If it were easy to replace C++ with C + kobj() than I'd say... leave things as they are. But if it's not difficult to make some C++ modules work than we should be bright enough to evaluate the changes. I don't have any real opinion of the patches though, so I'll leave the matter here. cheers, Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 15:14:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D6CE16A4DE for ; Wed, 12 Jul 2006 15:14:56 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB9A43D46 for ; Wed, 12 Jul 2006 15:14:56 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms170.mailsrvcs.net ([192.168.1.3]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J2A004TSQC81L0D@vms044.mailsrvcs.net> for freebsd-hackers@freebsd.org; Wed, 12 Jul 2006 10:14:32 -0500 (CDT) Date: Wed, 12 Jul 2006 10:14:31 -0500 (CDT) From: Sergey Babkin To: mag@intron.ac, Jason Slagle Message-id: <14577791.354951152717272061.JavaMail.root@vms170.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 12 Jul 2006 16:40:25 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 15:14:56 -0000 >From: mag@intron.ac >Jason Slagle wrote: > >> On Wed, 12 Jul 2006, mag@intron.ac wrote: >> >>> I would repeat several sentences in my last reply. >>> Why would people write Windows application with rather MFC/ATL/.NET >>> Framework than direct Windows API? Why is gtkmm framework created for >>> GTK+? Would you write a X11 application with original X11 API, without QT >>> or other X11 toolkit? I believe the answer is that all programmers are >>> human begins, not >>> machines. Human programmer would reduce brainwork, even if an API >>> package/wrapper slightly reduces running efficiency. >> >> And this is why office 2003 takes longer to load on a 2.4ghz machine then >> office 97 did on a 233. >> >Why don't you say that Office 2003 is more powerful than Office 97? Hm, is it? I've never noticed, I guess I just don't have the need for the more powerful parts of it. >You even haven't known what we are discussing and what I would commit. >Actually my patches has little relationship to C++. What many C++ programmers don't realize is that lots of the C++ functionality (inheritance etc.) can be done in C almost as good and easy (and sometimes just as good and easy). And it's done, and people have pointed it out. There are some things in C++ that really are a great advantage over C (STL, for an easy example) but these tend to be pretty heavyweight to put them into the kernel. Then again, there are things in C++ that are very convenient and lightweight. One of them would be the automatic calling of destructors when exiting a block. Makes the tracking of the locks much easier. I'm not so sure that the exceptions get into this category. -SB From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 18:43:55 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC44C16A4E1 for ; Wed, 12 Jul 2006 18:43:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA3143D46 for ; Wed, 12 Jul 2006 18:43:51 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wr-out-0506.google.com with SMTP id 69so188419wra for ; Wed, 12 Jul 2006 11:43:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jMe2UW33zRtALcFyBVI3t0LKNmON6Gn9g9k4FLENAmH826EDThu6jiEux+8FfSAtdEHPoNxuioAN4iT8PqIoBx2Cnl8FkMzZiwdE1toXxIC+HvON5QB91LxznKP2BnrUNsI2o1fGDNYukh4o3StOxsoNT1jGnl85KL9QBPjmulI= Received: by 10.54.149.14 with SMTP id w14mr1134752wrd; Wed, 12 Jul 2006 11:43:50 -0700 (PDT) Received: by 10.70.11.15 with HTTP; Wed, 12 Jul 2006 11:43:50 -0700 (PDT) Message-ID: <3bbf2fe10607121143n1a5fba00ueee37ecfe14a1ce1@mail.gmail.com> Date: Wed, 12 Jul 2006 20:43:50 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: freebsd-hackers@freebsd.org In-Reply-To: <20060712113516.GC2162@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B2D2DF.2000401@sh.cvut.cz> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> X-Google-Sender-Auth: db2de2fe30528c93 Cc: joerg@britannica.bec.de Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 18:43:55 -0000 2006/7/12, Joerg Sonnenberger : > On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote: > > Even if I have no proof-of-concepts (so maybe somebody can show that > > this is not fair), if we have setjmp/longjmp in the kernel we can have > > a correct exception handling mechanism without not great problems. > > ROFL. Sorry, but using setjmp/longjmp is one of the worst possible > implementation of exceptions since it is very expensive for the hot > path, where you don't expect exceptions. They are called "exception" for > a reason. Well, this is not what I meant. As exceptions are performed through stack unrolling (which is the basic mechanism of setjmp/longjmp) it might not be impossible to implement the correct try/catch mechanism in a correct way (even in freestanding). That's all. No reference to how to do it :) Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 19:22:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 328C816A4DF for ; Wed, 12 Jul 2006 19:22:15 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A31743D4C for ; Wed, 12 Jul 2006 19:22:14 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 99ECAF1AD1 for ; Thu, 13 Jul 2006 03:22:12 +0800 (CST) X-KSVirus-check: 0 References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> <17589.1784.567790.215719@bhuda.mired.org> In-Reply-To: <17589.1784.567790.215719@bhuda.mired.org> From: "Intron" To: Mike Meyer Date: Thu, 13 Jul 2006 03:19:48 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152732131.57858@origin.intron.ac> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 19:22:15 -0000 Mike Meyer wrote: > In <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com>, pfgshield-freebsd@yahoo.com typed: >> C++ is the de-facto standard for OO: a lot of people know how to use it > > Oh gods, does this bring to mind lots (and *lots*) of scathing > commentary. I'll restrict myself to just one: > > Windows is the de-facto standard OS: a lot of people know how to use > it. > > We're bright enough to know that popularity doesn't imply technical > excellence, otherwise we wouldn't be on a FreeBSD list. Having avoided > that trap in the choice of platform, doesn't it behoove us to avoid it > elswhere? I believe that your idea is identical to those of FreeBSD patriarchs. CSRG of UC Berkeley has been disbanded for 10 years. The fair aureole has been removed for ever. Now, FreeBSD is only an OS product, playing a real part somewhat similar to that of GNU/Linux, Microsoft Windows or other OS's. Today, desktop PC and professional multi-CPU server are becoming more and more powerful, and more and more complicated. If you take USB PC camera, MP3 player, digital camera, digital vidicon, video decoder (E.g. Philips 7130/7134), USB MIDI, USB xDSL MODEM, AC97 MODEM in laptop, 802.11 wireless adapter and many others all as toys, then, can FreeBSD support NUMA feature of multi-CPU server? Can FreeBSD support parallel computing interconnection device? Can FreeBSD support PCMCIA GSM/CDMA module useful for outdoor worker? ... Without keeping up with this epoch, even if FreeBSD's code is kept absolutely "pristine", "neat" and "high-blooded", FreeBSD will become an antique only to enjoy in old hands. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 19:54:55 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9792416A4DE for ; Wed, 12 Jul 2006 19:54:55 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 76DEC43D5C for ; Wed, 12 Jul 2006 19:54:54 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 72052 invoked by uid 1001); 12 Jul 2006 19:54:53 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Wed, 12 Jul 2006 15:54:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17589.21389.539839.559389@bhuda.mired.org> Date: Wed, 12 Jul 2006 15:54:53 -0400 To: "Intron" In-Reply-To: <1152732131.57858@origin.intron.ac> References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> <17589.1784.567790.215719@bhuda.mired.org> <1152732131.57858@origin.intron.ac> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 19:54:55 -0000 In <1152732131.57858@origin.intron.ac>, Intron typed: > Mike Meyer wrote: > > In <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com>, pfgshield-freebsd@yahoo.com typed: > >> C++ is the de-facto standard for OO: a lot of people know how to use it > > We're bright enough to know that popularity doesn't imply technical > > excellence, otherwise we wouldn't be on a FreeBSD list. Having avoided > > that trap in the choice of platform, doesn't it behoove us to avoid it > > elswhere? > I believe that your idea is identical to those of FreeBSD patriarchs. I believe you don't understand my idea at all. I'm not saying don't add things to the kernel. Nuts, I'm not even saying don't add support for writing kernel code in other languages. I'm saying, don't make that other language C++ just because it's currently favored by PHBs. There are much better OO languages (pretty much *any* of them) to choose from. C++ may be the best choice because of it's roots in C, but there are better OO languages with roots in C as well. Even taking all that into account, C++ may be the best choice. But don't simply settle on C++ (or OO, for that matter) without evaluating the other choices. > can FreeBSD support NUMA feature of multi-CPU server? > Can FreeBSD support parallel computing interconnection device? > Can FreeBSD support PCMCIA GSM/CDMA module useful for outdoor worker? What does adding support for any and/or all of these have to do whether we add C++, Eiffel, or nothing to what languages you can write kernel code in? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 20:16:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6F7E16A4DA for ; Wed, 12 Jul 2006 20:16:31 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id D56AE43D4C for ; Wed, 12 Jul 2006 20:16:30 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D619.dip.t-dialin.net [84.165.214.25]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k6CK73OL014607; Wed, 12 Jul 2006 22:07:03 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k6CKGV94098777; Wed, 12 Jul 2006 22:16:31 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Wed, 12 Jul 2006 22:17:41 +0200 From: Alexander Leidinger To: Mike Meyer Message-ID: <20060712221741.5359258b@Magellan.Leidinger.net> In-Reply-To: <17589.21389.539839.559389@bhuda.mired.org> References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> <17589.1784.567790.215719@bhuda.mired.org> <1152732131.57858@origin.intron.ac> <17589.21389.539839.559389@bhuda.mired.org> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Wed, 12 Jul 2006 20:18:03 +0000 Cc: freebsd-hackers@freebsd.org, Intron Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 20:16:31 -0000 Quoting Mike Meyer (Wed, 12 Jul 2006 15:54:53 -0400): > C++ may be the best choice > because of it's roots in C, but there are better OO languages with > roots in C as well. Even taking all that into account, C++ may be the > best choice. But don't simply settle on C++ (or OO, for that matter) > without evaluating the other choices. Are the involved parties aware of one of our current Google SoC 2006 projects? I suggest to look at http://wiki.freebsd.org/ and search for "K". No need to keep me CCed in this discussion... Bye, Alexander. -- 'You're your own worst enemy, Rincewind,' said the sword. Rincewind looked up at the grinning men. 'Bet?' (Colour of Magic) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 21:58:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FE7916A4DE for ; Wed, 12 Jul 2006 21:58:15 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73EC343D5D for ; Wed, 12 Jul 2006 21:58:09 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so12422pyb for ; Wed, 12 Jul 2006 14:58:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=b2Vr6Jv88t6LN28/ksfojZS6erSeuKBAUDR8n3F6E1cli+SoRG6E4lCZxLef8FBUZXRoP4wlSWXAS3Rrnm7VuIqSWqMycz4Hqm2U9IrEgto/1Z/bw1GsKXNX8oHe8NvC+H+C/n1t8yyoGoOGZ8vGwcMTw7vL/X7LQ71niS3rmdQ= Received: by 10.35.21.1 with SMTP id y1mr51714pyi; Wed, 12 Jul 2006 14:58:06 -0700 (PDT) Received: by 10.35.117.14 with HTTP; Wed, 12 Jul 2006 14:58:06 -0700 (PDT) Message-ID: <70e8236f0607121458k38f91fb2vfd402bb45334fc71@mail.gmail.com> Date: Wed, 12 Jul 2006 22:58:06 +0100 From: "Joao Barros" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Sysinstall: Write the FreeBSD version at the top of the display X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 21:58:15 -0000 Hi all, I was browsing the list of projects and ideas and stumbled upon one that's rather simple and which would have been useful in the past: Write the FreeBSD version at the top of the display (or somewhere similar visible) - so lazy users know what they are installing (version: release, stable, snapshot + arch: i386, amd64, etc) even when the CD is unlabeled. I'm changing the title of the Main menu using sysctlbyname to: "FreeBSD - sysinstall Main Menu" The result would be: "FreeBSD 7.0-CURRENT i386 - sysinstall Main Menu" Screenshot of the result: http://img55.imageshack.us/img55/980/sysintall17vv.png If this is what is pretended I'll post the patch. -- Joao Barros From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 12 22:13:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21AC016A4E5 for ; Wed, 12 Jul 2006 22:13:30 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 689BB43D5D for ; Wed, 12 Jul 2006 22:13:27 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 7EFF099AAEE; Thu, 13 Jul 2006 00:13:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mg9E8Alw+cUA; Thu, 13 Jul 2006 00:13:13 +0200 (CEST) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 22F9E99A6D5; Thu, 13 Jul 2006 00:13:13 +0200 (CEST) Message-ID: <44B573F3.4020400@FreeBSD.org> Date: Thu, 13 Jul 2006 00:13:07 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Joao Barros References: <70e8236f0607121458k38f91fb2vfd402bb45334fc71@mail.gmail.com> In-Reply-To: <70e8236f0607121458k38f91fb2vfd402bb45334fc71@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Sysinstall: Write the FreeBSD version at the top of the display X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gabor@t-hosting.hu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 22:13:30 -0000 Joao Barros wrote: > Hi all, > > I was browsing the list of projects and ideas and stumbled upon one > that's rather simple and which would have been useful in the past: > Write the FreeBSD version at the top of the display (or somewhere > similar visible) - so lazy users know what they are installing > (version: release, stable, snapshot + arch: i386, amd64, etc) even > when the CD is unlabeled. > > I'm changing the title of the Main menu using sysctlbyname to: > "FreeBSD - sysinstall Main Menu" > The result would be: > "FreeBSD 7.0-CURRENT i386 - sysinstall Main Menu" > Screenshot of the result: > http://img55.imageshack.us/img55/980/sysintall17vv.png > > If this is what is pretended I'll post the patch. > I think this is pretended, but anyway, it's a nice feature, so I suggest you send-pr-ing the patch by all. Cheers, Gabor From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 02:39:21 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91E5216A4DE for ; Thu, 13 Jul 2006 02:39:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D9843D4C for ; Thu, 13 Jul 2006 02:39:21 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 12 Jul 2006 19:39:21 -0700 Message-ID: <44B5B258.3030701@elischer.org> Date: Wed, 12 Jul 2006 19:39:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: tim's talk starting now. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 02:39:21 -0000 rtsp://jello.ironport.com:80/bafug-live.sdp From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 05:53:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D948916A4DD for ; Thu, 13 Jul 2006 05:53:08 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 839A543D95 for ; Thu, 13 Jul 2006 05:52:47 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: by py-out-1112.google.com with SMTP id d42so106877pyd for ; Wed, 12 Jul 2006 22:52:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=dqxZdEgyWsHTzUefnsFndzr7qguXNNq6CaLwD6mcz1zo7SzUR6WOEAHFid7IlAEM4fwnU/bSRs4hpoWDTEBWKYWtJcxjzPloSWJs0N3LH6GxbxnapAQ5e/Zl7JxC8qNeXml/hz9WWutQ8wK/nKmeEVwyrhlRtns+xsFV537oW/g= Received: by 10.35.21.1 with SMTP id y1mr190603pyi; Wed, 12 Jul 2006 22:46:18 -0700 (PDT) Received: by 10.35.34.9 with HTTP; Wed, 12 Jul 2006 22:46:18 -0700 (PDT) Message-ID: Date: Thu, 13 Jul 2006 11:16:18 +0530 From: "Kamal R. Prasad" Sender: kamalpr@gmail.com To: freebsd-hackers@freebsd.org In-Reply-To: <20060712132059.GA3906@britannica.bec.de> MIME-Version: 1.0 References: <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> <20060712132059.GA3906@britannica.bec.de> X-Google-Sender-Auth: 21aafc56b31bacb7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 05:53:09 -0000 Im sorry I didn't understand you. setjmp() stores a few register contents [notably ip] in a jmpbuf -which are restored after a longjmp(). How is the try/catch mechanism more efficient than a setjmp()/longjmp() in terms of space/time complexity? thanks -kamal On 7/12/06, Joerg Sonnenberger wrote: > > On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote: > > On 7/12/06, Joerg Sonnenberger wrote: > > > > >On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote: > > >> Even if I have no proof-of-concepts (so maybe somebody can show that > > >> this is not fair), if we have setjmp/longjmp in the kernel we can > have > > >> a correct exception handling mechanism without not great problems. > > > > > >ROFL. Sorry, but using setjmp/longjmp is one of the worst possible > > >implementation of exceptions since it is very expensive for the hot > > >path, where you don't expect exceptions. They are called "exception" > for > > >a reason. > > > > > > so how is exception handling in C++ more efficient than > setjmp()/longjmp() > > -in either paths? > > The common implementations are based on two assumptions: > - try {} is used often through out the tree and nested > - exceptions are raised seldomly. > This means that the desire to catch an exception should be cheap and the > implementation optimised for that. > > What happens is that the compiler creates a table which allows automatic > stack unwinding and matching of the instruction pointers. The former is > necessary to handle frame pointer vs. frame pointer-less stack frames, > the latter is used to determine where an exception should be cought. > > Consider: > void bar() > { > throw "foo"; > } > > void foo() > { > try { > bar(); > } catch(...) { > cerr << "error"; > } > } > > (don't try that, I haven't written C++ for ages) > > The compiler creates: > - an entry for the range of bar to annotate that it doesn't have use a > frame pointer > - an entry for foo, with the same annotation > - the address when bar is called in foo (or the address directly > following) to annotate that it should jump to catch, when an exception > is raised. > > When an exception is raised, it looks at the current instruction pointer > and begins unwinding the stack until a catch is found. This can be > relatively cheap compared to longjmp, since the register content does > not have to be restored. It does not add any slowdown, as long as > exceptions are not raised. > > Joerg > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 09:08:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14B5A16A4DA for ; Thu, 13 Jul 2006 09:08:40 +0000 (UTC) (envelope-from martin@gneto.com) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AF7E43D4C for ; Thu, 13 Jul 2006 09:08:38 +0000 (GMT) (envelope-from martin@gneto.com) Received: from ua-83-227-181-30.cust.bredbandsbolaget.se ([83.227.181.30] [83.227.181.30]) by mxfep01.bredband.com with ESMTP id <20060713090837.SLZM9682.mxfep01.bredband.com@ua-83-227-181-30.cust.bredbandsbolaget.se> for ; Thu, 13 Jul 2006 11:08:37 +0200 Received: from euklides.gneto.com (euklides.gneto.com [192.168.10.11]) by ua-83-227-181-30.cust.bredbandsbolaget.se (Postfix) with ESMTP id DAD6167922 for ; Thu, 13 Jul 2006 11:08:36 +0200 (CEST) From: Martin Nilsson To: freebsd-hackers@freebsd.org Date: Thu, 13 Jul 2006 11:08:37 +0200 User-Agent: KMail/1.9.3 References: <70e8236f0607121458k38f91fb2vfd402bb45334fc71@mail.gmail.com> In-Reply-To: <70e8236f0607121458k38f91fb2vfd402bb45334fc71@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607131108.37968.martin@gneto.com> Subject: Re: Sysinstall: Write the FreeBSD version at the top of the display X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 09:08:40 -0000 On Wednesday 12 July 2006 23:58, Joao Barros wrote: > Hi all, > > I was browsing the list of projects and ideas and stumbled upon one > that's rather simple and which would have been useful in the past: > Write the FreeBSD version at the top of the display (or somewhere > similar visible) - so lazy users know what they are installing > (version: release, stable, snapshot + arch: i386, amd64, etc) even > when the CD is unlabeled. > > I'm changing the title of the Main menu using sysctlbyname to: > "FreeBSD - sysinstall Main Menu" > The result would be: > "FreeBSD 7.0-CURRENT i386 - sysinstall Main Menu" > Screenshot of the result: > http://img55.imageshack.us/img55/980/sysintall17vv.png > > If this is what is pretended I'll post the patch. Excellent, it was something like that I thought of when submitting my "small sysinstall renovation" idea! Thanks, Martin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 12:14:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C95E016A4E2 for ; Thu, 13 Jul 2006 12:14:50 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7370443D78 for ; Thu, 13 Jul 2006 12:14:43 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms064.mailsrvcs.net ([192.168.1.1]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J2C009C9COF1913@vms044.mailsrvcs.net> for freebsd-hackers@freebsd.org; Thu, 13 Jul 2006 07:14:39 -0500 (CDT) Received: from 198.190.8.100 ([198.190.8.100]) by vms064.mailsrvcs.net (Verizon Webmail) with HTTP; Thu, 13 Jul 2006 07:14:39 -0500 (CDT) Date: Thu, 13 Jul 2006 07:14:39 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [198.190.8.100] To: "Kamal R. Prasad" , freebsd-hackers@freebsd.org Message-id: <15622933.140331152792879114.JavaMail.root@vms064.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 13 Jul 2006 13:07:12 +0000 Cc: Subject: Re: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 12:14:51 -0000 >From: "Kamal R. Prasad" >Im sorry I didn't understand you. setjmp() stores a few register contents >[notably ip] in a jmpbuf -which are restored after a longjmp(). How is the >try/catch mechanism more efficient than a setjmp()/longjmp() in terms of >space/time complexity? try/catch stores less. Besides, longjmp() is nothing like try/catch. The whole point of try/catch is that as the stack gets unwound, all the auto-class objects get properly destroyed. When you do longjmp, you just move the instruction pointer and stack pointer, and if any of the objects on the stack contained pointers to any dynamically allocated memory, it gets lost. If there were any file descriptors opened along the way, they are left open too. If there were any locks held, they stay locked. To prevent this loss with longjmp, you have to track all these objects manually. Note that even with try/catch it's a Real Bad Idea to throw exceptions from constructors and destructors, as this causes complications. -SB >On 7/12/06, Joerg Sonnenberger wrote: >> >> On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote: >> > On 7/12/06, Joerg Sonnenberger wrote: >> > >> > >On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote: >> > >> Even if I have no proof-of-concepts (so maybe somebody can show that >> > >> this is not fair), if we have setjmp/longjmp in the kernel we can >> have >> > >> a correct exception handling mechanism without not great problems. >> > > >> > >ROFL. Sorry, but using setjmp/longjmp is one of the worst possible >> > >implementation of exceptions since it is very expensive for the hot >> > >path, where you don't expect exceptions. They are called "exception" >> for >> > >a reason. >> > >> > >> > so how is exception handling in C++ more efficient than >> setjmp()/longjmp() >> > -in either paths? >> >> The common implementations are based on two assumptions: >> - try {} is used often through out the tree and nested >> - exceptions are raised seldomly. >> This means that the desire to catch an exception should be cheap and the >> implementation optimised for that. >> >> What happens is that the compiler creates a table which allows automatic >> stack unwinding and matching of the instruction pointers. The former is >> necessary to handle frame pointer vs. frame pointer-less stack frames, >> the latter is used to determine where an exception should be cought. >> >> Consider: >> void bar() >> { >> throw "foo"; >> } >> >> void foo() >> { >> try { >> bar(); >> } catch(...) { >> cerr << "error"; >> } >> } >> >> (don't try that, I haven't written C++ for ages) >> >> The compiler creates: >> - an entry for the range of bar to annotate that it doesn't have use a >> frame pointer >> - an entry for foo, with the same annotation >> - the address when bar is called in foo (or the address directly >> following) to annotate that it should jump to catch, when an exception >> is raised. >> >> When an exception is raised, it looks at the current instruction pointer >> and begins unwinding the stack until a catch is found. This can be >> relatively cheap compared to longjmp, since the register content does >> not have to be restored. It does not add any slowdown, as long as >> exceptions are not raised. >> >> Joerg >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 16:12:50 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2F8416A4DF for ; Thu, 13 Jul 2006 16:12:49 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6092443D55 for ; Thu, 13 Jul 2006 16:12:48 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6DGCfmd068675 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 13 Jul 2006 18:12:42 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6DGCeVb068674 for hackers@freebsd.org; Thu, 13 Jul 2006 18:12:40 +0200 (CEST) Date: Thu, 13 Jul 2006 18:12:40 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060713161240.GA68016@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: [SoC]: question about execve() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 16:12:50 -0000 hi, durin my work on SoC I happened to be in a need of "catching" the transition of execve() from fbsd binary to linux binary and back. Kostik Belousov suggested using the process_exit handler event but it doesnt contain information necessary to distinguish such a switch. He proposes extending typedef void (*execlist_fn)(void *, struct proc *); with a 3rd param "struct image_params" and extending this structure with a brand info. That would let us see such brand switches by investigating p->p_sysent and imgp->brand_type. is this ok? or is there any better solution? thnx for answer roman ---------------------- www.liberalnistrana.cz From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 16:22:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4018416A4DD; Thu, 13 Jul 2006 16:22:33 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A37E43D49; Thu, 13 Jul 2006 16:22:27 +0000 (GMT) (envelope-from daichi@freebsd.org) Received: from [192.168.1.101] (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 73D7C244C46; Fri, 14 Jul 2006 01:22:26 +0900 (JST) Message-ID: <44B67340.1080405@freebsd.org> Date: Fri, 14 Jul 2006 01:22:24 +0900 From: Daichi GOTO User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org, rodrigc@crodrigues.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: daichi@freebsd.org, ozawa@ongs.co.jp Subject: [ANN] unionfs patchset-16 release, it is ready for the merge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 16:22:33 -0000 Hi Guys! It is my pleasure and honor to announce the availability of the unionfs patchset-16. The p16 is an important milestone. It is ready for the merge. Patchset-16: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p16.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p16.diff Changes in unionfs-p16.diff - changed source code style and naming rules for fitting to FreeBSD kernel src style. - committed the patch for sys/ufs/ufs/ufs_lookup.c to current tree. So the patch for sys/ufs/ufs/ufs_lookup.c is removed from unionfs-p16.diff. - changed the patch for sys/fs/unionfs/union_subr.c fitting to changing in current tree. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) The patchset-16 has extensive trials, good stability and source code quality enough to get the merge. I'll commit it to FreeBSD base system after writing up the manual. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 13 16:33:39 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5931A16A4DD for ; Thu, 13 Jul 2006 16:33:39 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AAD243D58 for ; Thu, 13 Jul 2006 16:33:27 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6DGWsoc069321 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 13 Jul 2006 18:32:54 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6DGWsax069320 for hackers@freebsd.org; Thu, 13 Jul 2006 18:32:54 +0200 (CEST) Date: Thu, 13 Jul 2006 18:32:54 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060713163254.GA69302@stud.fit.vutbr.cz> References: <20060713161240.GA68016@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060713161240.GA68016@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: Re: [SoC]: question about execve() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 16:33:39 -0000 On Thu, Jul 13, 2006 at 06:12:40PM +0200, Divacky Roman wrote: > hi, > > durin my work on SoC I happened to be in a need of "catching" the transition of > execve() from fbsd binary to linux binary and back. > > Kostik Belousov suggested using the process_exit handler event but it doesnt ^^^^ exec handler sorry From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 06:56:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F5A916A4DD; Fri, 14 Jul 2006 06:56:58 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC9E343D49; Fri, 14 Jul 2006 06:56:57 +0000 (GMT) (envelope-from daichi@freebsd.org) Received: from [192.168.1.101] (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id DF927244C48; Fri, 14 Jul 2006 15:56:56 +0900 (JST) Message-ID: <44B74036.6060101@freebsd.org> Date: Fri, 14 Jul 2006 15:56:54 +0900 From: Daichi GOTO User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: <44B67340.1080405@freebsd.org> In-Reply-To: <44B67340.1080405@freebsd.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: rodrigc@crodrigues.org, ozawa@ongs.co.jp Subject: Re: [ANN] unionfs patchset-16 release, it is ready for the merge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 06:56:58 -0000 Daichi GOTO wrote: > Patchset-16: > For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p16.diff > > For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p16.diff I'm sorry, how silly of me. I updated miss edited things. I updated correct things now. Please check it :) -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 07:44:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DE3D16A4E0 for ; Fri, 14 Jul 2006 07:44:36 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1492143D53 for ; Fri, 14 Jul 2006 07:44:36 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (wlan033212.uni-rostock.de [139.30.33.212]) by hydra.bec.de (Postfix) with ESMTP id 90A6C35707 for ; Fri, 14 Jul 2006 09:44:32 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 267BD6D093; Fri, 14 Jul 2006 09:44:19 +0200 (CEST) Date: Fri, 14 Jul 2006 09:44:19 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20060714074419.GC14113@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> <20060712132059.GA3906@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 07:44:36 -0000 On Thu, Jul 13, 2006 at 11:16:18AM +0530, Kamal R. Prasad wrote: > Im sorry I didn't understand you. setjmp() stores a few register contents > [notably ip] in a jmpbuf -which are restored after a longjmp(). How is the > try/catch mechanism more efficient than a setjmp()/longjmp() in terms of > space/time complexity? Because you have to run setjmp for *every* try{}, independent of whether it is ever actually needed. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 13:50:06 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B999316A4ED for ; Fri, 14 Jul 2006 13:50:06 +0000 (UTC) (envelope-from mykola.stryebkov@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA82743D76 for ; Fri, 14 Jul 2006 13:50:00 +0000 (GMT) (envelope-from mykola.stryebkov@gmail.com) Received: by wx-out-0102.google.com with SMTP id s13so263656wxc for ; Fri, 14 Jul 2006 06:50:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=OLzlSClfJb6vSBkdJ8FKnOqMmFsJDKyj1CCQcmL9UqQNqtWsJn07qKOOlyWQ9yJsdGbhwPuMf3zpkkA58j0Sxy8P2x/6IsDpKMcBBRm6MuhzLG7HMsNUMiOmxiUkcTln1OkwcU3/OOBVfMd4M+8qMdD0U/layTEQQb7GFQdVwqo= Received: by 10.70.8.4 with SMTP id 4mr3138128wxh; Fri, 14 Jul 2006 06:49:59 -0700 (PDT) Received: from localhost ( [70.86.106.246]) by mx.gmail.com with ESMTP id h37sm3584388wxd.2006.07.14.06.49.57; Fri, 14 Jul 2006 06:49:58 -0700 (PDT) Date: Fri, 14 Jul 2006 16:49:53 +0300 From: Mykola Stryebkov To: hackers@freebsd.org Message-ID: <20060714134953.GA2404@taran.infoua.com.ua> Mail-Followup-To: Mykola Stryebkov , hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: fork inside ip_input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 13:50:06 -0000 Hi all. Have a strange question: is it possible to create new process (using fork or fork1) from inside of ip_input()? In kernel sources i found example of using fork1 in init_main.c but looking into ip_input.c i do not understand where i can get pointers to a thread and parent process to pass it into fork1. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 13:56:14 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD45816A518 for ; Fri, 14 Jul 2006 13:56:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FDA43D8C for ; Fri, 14 Jul 2006 13:56:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.114]) by a50.ironport.com with ESMTP; 14 Jul 2006 06:56:12 -0700 Message-ID: <44B7A27B.4040301@elischer.org> Date: Fri, 14 Jul 2006 06:56:11 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mykola Stryebkov References: <20060714134953.GA2404@taran.infoua.com.ua> In-Reply-To: <20060714134953.GA2404@taran.infoua.com.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: fork inside ip_input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 13:56:14 -0000 Mykola Stryebkov wrote: >Hi all. > >Have a strange question: is it possible to create new process (using >fork or fork1) from inside of ip_input()? > >In kernel sources i found example of using fork1 in init_main.c but >looking into ip_input.c i do not understand where i can get pointers to >a thread and parent process to pass it into fork1. > > > you want to create a new kernel thread.. look at kthread_{xxx} use curthread as your thread. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 13:57:46 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 449BC16A4FD for ; Fri, 14 Jul 2006 13:57:46 +0000 (UTC) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD13C43DA7 for ; Fri, 14 Jul 2006 13:57:34 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id D6E3E8D449; Fri, 14 Jul 2006 15:57:32 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11295-05-5; Fri, 14 Jul 2006 15:57:32 +0200 (CEST) Received: from [84.155.243.109] (p549BF36D.dip.t-dialin.net [84.155.243.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id 549F48C311; Fri, 14 Jul 2006 15:57:32 +0200 (CEST) Message-ID: <44B7A2C8.7050407@fs.ei.tum.de> Date: Fri, 14 Jul 2006 15:57:28 +0200 From: Simon 'corecode' Schubert User-Agent: Mail/News 1.5.0.4 (X11/20060619) MIME-Version: 1.0 To: Mykola Stryebkov , hackers@freebsd.org References: <20060714134953.GA2404@taran.infoua.com.ua> In-Reply-To: <20060714134953.GA2404@taran.infoua.com.ua> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig915844A8B1C460A79C610A45" X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: Subject: Re: fork inside ip_input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 13:57:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig915844A8B1C460A79C610A45 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Mykola Stryebkov wrote: > Hi all. >=20 > Have a strange question: is it possible to create new process (using > fork or fork1) from inside of ip_input()? i don't think so. > In kernel sources i found example of using fork1 in init_main.c but > looking into ip_input.c i do not understand where i can get pointers to= > a thread and parent process to pass it into fork1. only a process can fork, but ip_input is run from interrupt, not in a pro= cess context. which process do you want to fork anyways? cheers simon --=20 Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1 +++= Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ --------------enig915844A8B1C460A79C610A45 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (DragonFly) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEt6LKr5S+dk6z85oRAqb4AKDGfxjm+5LxNtNsrCdVce0bcHB7eQCdGx6J UPjQF+Pvw2SedW0MKKgr0hw= =GHI5 -----END PGP SIGNATURE----- --------------enig915844A8B1C460A79C610A45-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 14:35:26 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E00016A4DA for ; Fri, 14 Jul 2006 14:35:26 +0000 (UTC) (envelope-from mykola.stryebkov@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ACBB43D49 for ; Fri, 14 Jul 2006 14:35:25 +0000 (GMT) (envelope-from mykola.stryebkov@gmail.com) Received: by wx-out-0102.google.com with SMTP id s13so272400wxc for ; Fri, 14 Jul 2006 07:35:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=kUxDnCo7a0qQa+iRppnx2mVQQ29mWyh+ouxPsVckLsXvOp04EN11hCULlqaSNyQXDYYTHhAPB5cySzHih3D39mB3/ugS+TS/sW5DCNgEh6dX6Y6YYxqW6HbpsWGIGz0QLHsnTNyiSPklte/jOHK2cSq09ii0VyRUPpn8YsaxN8Y= Received: by 10.70.98.2 with SMTP id v2mr3164398wxb; Fri, 14 Jul 2006 07:35:22 -0700 (PDT) Received: from localhost ( [70.86.106.246]) by mx.gmail.com with ESMTP id i18sm3384883wxd.2006.07.14.07.35.16; Fri, 14 Jul 2006 07:35:18 -0700 (PDT) Date: Fri, 14 Jul 2006 17:35:14 +0300 To: Simon 'corecode' Schubert Message-ID: <20060714143514.GA2838@taran.infoua.com.ua> Mail-Followup-To: nick@humgat.org, Simon 'corecode' Schubert , Mykola Stryebkov , hackers@freebsd.org References: <20060714134953.GA2404@taran.infoua.com.ua> <44B7A2C8.7050407@fs.ei.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: <44B7A2C8.7050407@fs.ei.tum.de> User-Agent: Mutt/1.4.2.1i From: mykola.stryebkov@gmail.com Cc: hackers@freebsd.org, Mykola Stryebkov Subject: Re: fork inside ip_input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 14:35:26 -0000 On 14.07.2006 15:57:28, Simon 'corecode' Schubert wrote: > Mykola Stryebkov wrote: > >Hi all. > > > >Have a strange question: is it possible to create new process (using > >fork or fork1) from inside of ip_input()? > > i don't think so. > > >In kernel sources i found example of using fork1 in init_main.c but > >looking into ip_input.c i do not understand where i can get pointers to > >a thread and parent process to pass it into fork1. > > only a process can fork, but ip_input is run from interrupt, not in a > process context. which process do you want to fork anyways? I want to start user-level process on first incoming RTP packet to install and keep TCP control connection. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 16:51:17 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B86EF16A51E for ; Fri, 14 Jul 2006 16:51:17 +0000 (UTC) (envelope-from Roland.Dittel@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2114C43D45 for ; Fri, 14 Jul 2006 16:51:17 +0000 (GMT) (envelope-from Roland.Dittel@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate02.web.de (Postfix) with ESMTP id 877818CA7FF for ; Fri, 14 Jul 2006 18:51:15 +0200 (CEST) Received: from [88.64.224.55] (helo=freebsd.localnet) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.107 #114) id 1G1Qsk-0004gD-00 for hackers@freebsd.org; Fri, 14 Jul 2006 18:51:14 +0200 Received: from [192.168.99.21] (apple.localnet [192.168.99.21]) by freebsd.localnet (8.13.6/8.13.1) with ESMTP id k6EGpACJ044877 for ; Fri, 14 Jul 2006 18:51:10 +0200 (CEST) (envelope-from Roland.Dittel@web.de) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: quoted-printable Message-Id: <62d3f75eb4400604406fdea341d91e41@web.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: hackers@freebsd.org From: Roland Dittel Date: Fri, 14 Jul 2006 18:51:08 +0200 X-Mailer: Apple Mail (2.624) Sender: Roland.Dittel@web.de X-Sender: Roland.Dittel@web.de Cc: Subject: dlsym() on implicit loaded symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 16:51:17 -0000 Hi all, We have a issue with dlsym() on symbols imported by a library that was =20= loaded with dlopen(). Our code loads the libssl with dlopen() and then =20= do a dlsym() on several symbols. This works for all symbols exported by =20= libssl itself but fails for symbols exported by libcrypto. Libssl is =20 dynamically linked to libcrypto and should be loaded for libssl. I did =20= a truss and the FreeBSD loader loads libcrypto but does not read =20 anything from the file pointer. This is the truss output: access("/prod/lib/fbsd-i386/libssl.so",0) =3D 0 (0x0) open("/prod/lib/fbsd-i386/libssl.so",0x0,027757760020) =3D 3 (0x3) fstat(3,0xbfbfe010) =3D 0 (0x0) fstatfs(0x3,0xbfbfde30) =3D 0 (0x0) read(3,"=7FELF=01=01=01 ",4096) =3D 4096 = (0x1000) mmap(0x0,229376,(0x5)PROT_READ|PROT_EXEC,(0x20002)MAP_NOCORE|MAP_PRIVATE=20= ,3,0x0) =3D 674971648 (0x283b4000) mprotect(0x283e7000,4096,(0x7)PROT_READ|PROT_WRITE|PROT_EXEC) =3D 0 = (0x0) mprotect(0x283e7000,4096,(0x5)PROT_READ|PROT_EXEC) =3D 0 (0x0) mmap(0x283e8000,16384,(0x3)PROT_READ|PROT_WRITE,(0x12)MAP_FIXED|MAP_PRIV=20= ATE,3,0x33000) =3D 675184640 (0x283e8000) close(3) =3D 0 (0x0) access("/prod/lib/fbsd-i386/libcrypto.so.0.9.8",0) =3D 0 (0x0) open("/prod/lib/fbsd-i386/libcrypto.so.0.9.8",0x0,05005664564) =3D 3 = (0x3) fstat(3,0xbfbfdfe0) =3D 0 (0x0) close(3) =3D 0 (0x0) mmap(0x0,5528,(0x3)PROT_READ|PROT_WRITE,(0x1000)MAP_ANON,-1,0x0) =3D =20 675201024 (0x283ec000) munmap(0x283ec000,5528) =3D 0 (0x0) On solaris, linux and irix the same code works fine and the libcrypto =20= symbols are implicit loaded and usable. Does anyone know why FreeBSD =20 behaves differently that other Unixes? Thanks, Roland From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 21:53:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1853A16A4DD for ; Fri, 14 Jul 2006 21:53:02 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93FCF43D45 for ; Fri, 14 Jul 2006 21:53:01 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so802610pyc for ; Fri, 14 Jul 2006 14:53:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cj1R2LNUUDTQFIWAHxznh43jCNSaaHtrsLA5SIhVWt+jnS+PeF50sDOQ8DU7ZlGUrm8/Qx52S2tamA37cez/VP5wTOUl0nmDr3W9TlVcNlAoJ5RMtHhgvgMpzNYDmyGg7hoD/iT+pWInVd/u7BkAMf2WKhrZtsiQQfUpXxxg230= Received: by 10.35.61.2 with SMTP id o2mr19158pyk; Fri, 14 Jul 2006 14:52:59 -0700 (PDT) Received: by 10.35.117.14 with HTTP; Fri, 14 Jul 2006 14:52:59 -0700 (PDT) Message-ID: <70e8236f0607141452h10c93503i4c07d3ade1a64257@mail.gmail.com> Date: Fri, 14 Jul 2006 22:52:59 +0100 From: "Joao Barros" To: gabor@t-hosting.hu, "Martin Nilsson" In-Reply-To: <44B573F3.4020400@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <70e8236f0607121458k38f91fb2vfd402bb45334fc71@mail.gmail.com> <44B573F3.4020400@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Sysinstall: Write the FreeBSD version at the top of the display X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 21:53:02 -0000 On 7/12/06, G=E1bor K=F6vesd=E1n wrote: > Joao Barros wrote: > > Hi all, > > > > I was browsing the list of projects and ideas and stumbled upon one > > that's rather simple and which would have been useful in the past: > > Write the FreeBSD version at the top of the display (or somewhere > > similar visible) - so lazy users know what they are installing > > (version: release, stable, snapshot + arch: i386, amd64, etc) even > > when the CD is unlabeled. > > > > I'm changing the title of the Main menu using sysctlbyname to: > > "FreeBSD - sysinstall Main Menu" > > The result would be: > > "FreeBSD 7.0-CURRENT i386 - sysinstall Main Menu" > > Screenshot of the result: > > http://img55.imageshack.us/img55/980/sysintall17vv.png > > > > If this is what is pretended I'll post the patch. > > > I think this is pretended, but anyway, it's a nice feature, so I suggest > you send-pr-ing the patch by all. Hi, Here's the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D100309 --=20 Joao Barros From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 14 20:38:05 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71B4F16A4E0 for ; Fri, 14 Jul 2006 20:38:05 +0000 (UTC) (envelope-from wolfie@xnet.co.nz) Received: from oberon.wxnz.net (oberon.wxnz.net [58.28.6.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B0343D45 for ; Fri, 14 Jul 2006 20:38:04 +0000 (GMT) (envelope-from wolfie@xnet.co.nz) Received: from xnet.co.nz (callisto.wxnz.net [58.28.6.10]) by oberon.wxnz.net (Postfix) with ESMTP id 2ECDD2B9934 for ; Sat, 15 Jul 2006 08:37:59 +1200 (NZST) Received: from ip-58-28-128-125.ubs-dsl.xnet.co.nz (ip-58-28-128-125.ubs-dsl.xnet.co.nz [58.28.128.125]) by webmail.xnet.co.nz (Horde MIME library) with HTTP; Sat, 15 Jul 2006 08:37:59 +1200 Message-ID: <20060715083759.k6znpbil1wswcsc8@webmail.xnet.co.nz> Date: Sat, 15 Jul 2006 08:37:59 +1200 From: wolfie@xnet.co.nz To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-Mailman-Approved-At: Fri, 14 Jul 2006 23:19:09 +0000 Subject: Genius slimstar pro keyboard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 20:38:05 -0000 Hey all, I have a Genius slimstar pro USB keyboard. I am having the same =20 problems as other people are having =20 (http://www.google.com/bsd?hl=3Den&lr=3D&q=3Dgenius+slimstar+pro&btnG=3DSear= ch) with =20 this keyboard. There seems to be no resolution to this problem short =20 of buying a new keyboard. The problem I'm having is when you hit any key, other than enter, on =20 the USB keyboard, it outputs garbage (extended ASCII characters like =20 the spades symbol, for example). If I hit d, it is the same as hitting =20 ctrl+d. It does output the same symbols for each key, so at least =20 there is some consistency :) I also have a AT keyboard plugged in which works as it should until I =20 hit a key on the USB keyboard. If I hit a key on the USB keyboard, the =20 AT keyboard starts outputting the same characters as the USB keyboard. =20 I have also tried without the AT keyboard plugged in, there is no =20 change. I read in another post that disabling all legacy AT support in the =20 kernel could fix this. I tried this to no avail. When I use kbdcontrol -i for any keyboard, I get the following =20 message: kbdcontrol: unable to obtain keyboard information: =20 Inappropriate ioctl for device. When I try a kbdcontrol -k /dev/ukbd0 =20 I get the message: kbdcontrol: cannot open /dev/ukbd0: Device busy. =20 When I try to disconnect the USB keyboard from the kbmux, I get: =20 kbdcontrol: unable to obtain keyboard information: Inappropriate ioctl =20 for device. The important lines at boot up, in order of appearance, are: kbd1 at kbdmux0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ukbd0: vendor 0x0458 ABBHOME, rev 1.10/1.01, addr 3, iclass 3/1 kbd2 at ukbd0 What I would find really helpful from you people is any idea's about =20 how to move forward with/resolve this problem. I am happy to trawl =20 through and modify any code. One idea I have, and correct me if I'm wrong, is to get each =20 individual keyscan code from the keyboard and map this into the =20 relating file, ukbd.c or one of the related header files? If anyone is needing any additional info on this one, just yell out =20 and I will get this to you. Thanks in advanced, Sam. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 15 14:01:10 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 716B216A4DE for ; Sat, 15 Jul 2006 14:01:10 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5E0143D45 for ; Sat, 15 Jul 2006 14:01:08 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6FE13V2075645 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 15 Jul 2006 16:01:03 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6FE12HW075644 for hackers@freebsd.org; Sat, 15 Jul 2006 16:01:02 +0200 (CEST) Date: Sat, 15 Jul 2006 16:01:02 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060715140102.GA75503@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: linux gdb doesnt work at all, fbsd one with problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 14:01:10 -0000 hi linux gdb doesnt work at all with internal error (some assert condition doesnt hold), this is manifested by simple: gdb /bin/ls run (sorry cant paste the output now because currently linuxolator panics for me on every load :)) fbsd gdb is not able to attach to a running process: witten ~# cat & [1] 969 witten ~# gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". (gdb) attach 969 Attaching to process 969 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) is there anyone with a GDB fu who can tell me if its gdb's fault, fbsd's fault or my fault? thnx roman ---------------------- www.liberalnistrana.cz From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 15 18:11:47 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0D7C16A508 for ; Sat, 15 Jul 2006 18:11:47 +0000 (UTC) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C4D43D45 for ; Sat, 15 Jul 2006 18:11:41 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id 7FFD88D67D; Sat, 15 Jul 2006 20:11:40 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03803-09-5; Sat, 15 Jul 2006 20:11:40 +0200 (CEST) Received: from [84.155.235.49] (p549BEB31.dip.t-dialin.net [84.155.235.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id F3D188D106; Sat, 15 Jul 2006 20:11:39 +0200 (CEST) Message-ID: <44B92FD7.90801@fs.ei.tum.de> Date: Sat, 15 Jul 2006 20:11:35 +0200 From: Simon 'corecode' Schubert User-Agent: Mail/News 1.5.0.4 (X11/20060619) MIME-Version: 1.0 To: Roland Dittel References: <62d3f75eb4400604406fdea341d91e41@web.de> In-Reply-To: <62d3f75eb4400604406fdea341d91e41@web.de> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB94E27FC8F767EF529D341F7" X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: hackers@freebsd.org Subject: Re: dlsym() on implicit loaded symbols X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 18:11:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB94E27FC8F767EF529D341F7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Roland Dittel wrote: > Hi all, >=20 > We have a issue with dlsym() on symbols imported by a library that was = > loaded with dlopen(). Our code loads the libssl with dlopen() and then = > do a dlsym() on several symbols. This works for all symbols exported by= =20 > libssl itself but fails for symbols exported by libcrypto. Libssl is=20 > dynamically linked to libcrypto and should be loaded for libssl. I did = a=20 > truss and the FreeBSD loader loads libcrypto but does not read anything= =20 > from the file pointer. could you post a sample code fragment which illustrates the problem you a= re seeing? cheers simon --=20 Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1 +++= Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ --------------enigB94E27FC8F767EF529D341F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (DragonFly) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuS/ar5S+dk6z85oRArdiAKDhtRk45v1bvfX8+nhsOVwK3SCPNACgm0i4 iIuLdRSWUvoGex16+QBOW6s= =fs/r -----END PGP SIGNATURE----- --------------enigB94E27FC8F767EF529D341F7-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 15 19:47:37 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 466A216A4DE for ; Sat, 15 Jul 2006 19:47:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3CCA43D46 for ; Sat, 15 Jul 2006 19:47:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6FJihkY042628; Sat, 15 Jul 2006 13:44:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 15 Jul 2006 13:44:56 -0600 (MDT) Message-Id: <20060715.134456.63053925.imp@bsdimp.com> To: joerg@britannica.bec.de From: "M. Warner Losh" In-Reply-To: <20060714074419.GC14113@britannica.bec.de> References: <20060712132059.GA3906@britannica.bec.de> <20060714074419.GC14113@britannica.bec.de> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 15 Jul 2006 13:44:44 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 19:47:37 -0000 In message: <20060714074419.GC14113@britannica.bec.de> Joerg Sonnenberger writes: : On Thu, Jul 13, 2006 at 11:16:18AM +0530, Kamal R. Prasad wrote: : > Im sorry I didn't understand you. setjmp() stores a few register contents : > [notably ip] in a jmpbuf -which are restored after a longjmp(). How is the : > try/catch mechanism more efficient than a setjmp()/longjmp() in terms of : > space/time complexity? : : Because you have to run setjmp for *every* try{}, independent of whether : it is ever actually needed. It is worse than even that. You have to run setjmp for every frame, because there could be an exception thrown from a lower frame to an upper frame and you have to cleanup your frame when that happens. Variables go out of scope, and must be destructed, etc. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 15 19:47:38 2006 Return-Path: X-Original-To: hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EE0716A4DF for ; Sat, 15 Jul 2006 19:47:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C36643D46 for ; Sat, 15 Jul 2006 19:47:37 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6FJjYQB042633; Sat, 15 Jul 2006 13:45:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 15 Jul 2006 13:45:47 -0600 (MDT) Message-Id: <20060715.134547.1159135432.imp@bsdimp.com> To: mykola.stryebkov@gmail.com From: "M. Warner Losh" In-Reply-To: <20060714143514.GA2838@taran.infoua.com.ua> References: <20060714134953.GA2404@taran.infoua.com.ua> <44B7A2C8.7050407@fs.ei.tum.de> <20060714143514.GA2838@taran.infoua.com.ua> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 15 Jul 2006 13:45:35 -0600 (MDT) Cc: hackers@FreeBSD.ORG, corecode@fs.ei.tum.de Subject: Re: fork inside ip_input X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 19:47:38 -0000 In message: <20060714143514.GA2838@taran.infoua.com.ua> mykola.stryebkov@gmail.com writes: : On 14.07.2006 15:57:28, Simon 'corecode' Schubert wrote: : > Mykola Stryebkov wrote: : > >Hi all. : > > : > >Have a strange question: is it possible to create new process (using : > >fork or fork1) from inside of ip_input()? : > : > i don't think so. : > : > >In kernel sources i found example of using fork1 in init_main.c but : > >looking into ip_input.c i do not understand where i can get pointers to : > >a thread and parent process to pass it into fork1. : > : > only a process can fork, but ip_input is run from interrupt, not in a : > process context. which process do you want to fork anyways? : : I want to start user-level process on first incoming RTP packet to : install and keep TCP control connection. Why not start it at boot, and signal/kick it somehow when RTP connections need to be managed... warner From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 15 20:21:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27FDC16A4DA for ; Sat, 15 Jul 2006 20:21:34 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63FA543D46 for ; Sat, 15 Jul 2006 20:21:32 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail09.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6FKLS5o020572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 16 Jul 2006 06:21:28 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6FKLR48018095; Sun, 16 Jul 2006 06:21:27 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6FKLRRV018094; Sun, 16 Jul 2006 06:21:27 +1000 (EST) (envelope-from peter) Date: Sun, 16 Jul 2006 06:21:27 +1000 From: Peter Jeremy To: "Kamal R. Prasad" Message-ID: <20060715202126.GA741@turion.vk2pj.dyndns.org> References: <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> <20060712113516.GC2162@britannica.bec.de> <20060712132059.GA3906@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 20:21:34 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2006-Jul-13 11:16:18 +0530, Kamal R. Prasad wrote: >Im sorry I didn't understand you. setjmp() stores a few register contents This varies with the CPU - from 48 bytes (i386 and sparc64) to 656 bytes (alpha). In addition, setjmp() stores the signal mask - and accessing this requires a system call - which is comparatively expensive. --=20 Peter Jeremy --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEuU5F/opHv/APuIcRAuWhAJ9vDKiab2w1WaK5GM/61Yv1HC8c9ACfQ0Tw JnkER/YAnBmiGUXG/TA/EjA= =QoVu -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 15 23:58:41 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62CEF16A4DD for ; Sat, 15 Jul 2006 23:58:41 +0000 (UTC) (envelope-from V.Haisman@sh.cvut.cz) Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A3AB43D45 for ; Sat, 15 Jul 2006 23:58:39 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service.sh.cvut.cz (Postfix) with ESMTP id CD4DE1A32F7; Sun, 16 Jul 2006 01:58:38 +0200 (CEST) Received: from service.sh.cvut.cz ([127.0.0.1]) by localhost (service [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32571-02; Sun, 16 Jul 2006 01:58:34 +0200 (CEST) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (Postfix) with ESMTP id 96A211A32EB; Sun, 16 Jul 2006 01:58:34 +0200 (CEST) Received: from [192.168.1.2] (localhost [127.0.0.1]) by logout.sh.cvut.cz (Postfix) with ESMTP id 1C38661C20; Sun, 16 Jul 2006 01:58:33 +0200 (CEST) Message-ID: <44B9811D.4050609@sh.cvut.cz> Date: Sun, 16 Jul 2006 01:58:21 +0200 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Divacky Roman References: <20060715140102.GA75503@stud.fit.vutbr.cz> In-Reply-To: <20060715140102.GA75503@stud.fit.vutbr.cz> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=733031B4 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUnMzWJm5S+0864pn5r blp/hnW2up7X7uqftbNRVUrW1LGBdGfHwJqPi3ScoYtBQzhDxGEwAAAAB3RJTUUH1QoQDDgyQtx8 HQAAAkNJREFUeJzFU0toU0EUPYu66CpGdCUUmoUJkpUDQUoNBVEUrBJsq1Ki2EIKIUZ8mydBhYi0 wVUXJVCLCrFN4DIEQdxIqdBIFsMkWD9YJClCRGKjJaviynjfe8RPogtXPcObuXPOPXd+PHj+Aeyo QNmobGLXVeANGM+GsP0B2yqHHNVoCD2LwLglVGZx7yXSlADR0uZu9C4Bpy3hUxPvH/cuUw6UoPCL h64I8KAJuMpwRU8uUMJy0OIpHVeXmulZoCc/t0LlTbJLEY1EudPRcnVjgAP5Osdl4K5HVP4+2bAI okaUA0Iq6Q59+Zy2eMWN6EpFTsa3+uD1+JKj4TPHuYTSMaLScLAaqk94YJqG4ds30hojOVgYoNJc NTztNU2TBYbhu9Aafnq08ORja37da1NwBrN/b7NVEc+b8yecuYkp08vNvLYneVZRaSH1vS0UnfHm OUPzWaZufHPmCWSdWrfeGVQQKmcsO4If8pAdXJ/xF4QQAeOVY1AQQcfirwkLUWeWVTgi6vaGt2xe BGzBEIMQorru8RxgPqY1V6uxYnwVBRZEI1ytCm3dE8mC2DgcbzCJGHdBEVDKuWDSwsrSGoqzJmNt 2jJpNueIH0qS8/0JrDKnVBdvOzIsdVr4zaX9dn9xcLLKdCtQGfutVacLE9Ja+yfbDvO4aMWrklfK /JYv15C8Kw9S10kup5Bys0N1bLdcn4HvTl/Xlh6Fpllwj5/XpH9BUXn/ym0Dvv7Rt2MywojpYiSi i7Hsscaa19zZ//y/hR+BT/ns80nmJAAAAABJRU5ErkJggg== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B46AF12C218139E3A98183D" X-Virus-Scanned: by amavisd-new at sh.cvut.cz X-Spam-Status: No, hits=-5.9 tagged_above=-255.0 required=5.0 tests=ALL_TRUSTED, BAYES_00 X-Spam-Level: Cc: hackers@freebsd.org Subject: Re: linux gdb doesnt work at all, fbsd one with problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 23:58:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B46AF12C218139E3A98183D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Divacky Roman wrote, On 15.7.2006 16:01: > hi >=20 > linux gdb doesnt work at all with internal error (some assert condition= doesnt > hold), this is manifested by simple: >=20 > gdb /bin/ls > run >=20 > (sorry cant paste the output now because currently linuxolator panics f= or me > on every load :)) >=20 > fbsd gdb is not able to attach to a running process: >=20 > witten ~# cat & > [1] 969 > witten ~# gdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and yo= u are > welcome to change it and/or distribute copies of it under certain condi= tions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > This GDB was configured as "i386-marcel-freebsd". > (gdb) attach 969 > Attaching to process 969 > /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.= c:1443: > internal-error: legacy_fetch_link_map_offsets called without legacy lin= k_map > support enabled. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) >=20 > is there anyone with a GDB fu who can tell me if its gdb's fault, fbsd'= s fault > or my fault? >=20 > thnx >=20 > roman >=20 > ---------------------- > www.liberalnistrana.cz GDB 6.1.1 is pretty ancient. I have had some problems with it dying on certain programmes, too. I didn't get any response on PRs that I filled, so I installed GDB 6.4 by hand and it works fine. So I suggest that, try newest GDB. -- VH --------------enig8B46AF12C218139E3A98183D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRLmBKUNOZDESBK8FAQIU5wf/d0XsIAjgzvdgs8mpSCTxuec1Pi3/3w+A r7WrOvSUPFvZA3tzbEPdN7HFhtIgSfhQ70Q1XUajwfbxV1MJvB7oSYZGahcXPJ9V ejK//FZybekyaM7Ha+lsXVsCD7iCBoEa6/+mZAJrCjid5gbPrnpHtVlyL8KWUK0z Y7j42kcscq8IUnxRnfO8S4CUPBKgX21lBtWRlq2cqsrCPfhaj6iKtfSZi6TSTKPk sPCWv7RhFwUhF6Q8mDonhng47ywFMxuC5CtWJc6e137nRFsjFCoLlpW/9kX9kEti 9B6w7qUOMIaSjopl3ON8wgBUo4hwb3e9D1BksUOqDVZlyD97W4epTg== =+LNf -----END PGP SIGNATURE----- --------------enig8B46AF12C218139E3A98183D--