From alanc@sac.sfbay.sun.com Tue Jul 20 21:37:24 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6L4bORX004697 for ; Tue, 20 Jul 2010 21:37:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6L4bNYi027172; Tue, 20 Jul 2010 21:37:24 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5W009014UBP500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Jul 2010 21:37:23 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5W008QZ4UB96B0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Jul 2010 21:37:23 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [10.5.240.67]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6L4bNA5010515; Tue, 20 Jul 2010 21:37:23 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6L4bMfX004692; Tue, 20 Jul 2010 21:37:22 -0700 (PDT) Received: (from alanc@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o6L4bMwX004688; Tue, 20 Jul 2010 21:37:22 -0700 (PDT) Date: Tue, 20 Jul 2010 21:37:22 -0700 (PDT) From: Alan Coopersmith Subject: VGA arbitration kernel driver [PSARC/2010/276 FastTrack timeout 07/28/2010] To: PSARC-ext@sun.com Message-id: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6515 I am sponsoring this case for Henry Zhao of the x86 Platform group. The timeout is set for Wednesday, July 28, 2010. Since this only adds new interfaces a release binding of Patch is requested, though no patch release is planned at this time. -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: VGA arbitration kernel driver 1.2. Name of Document Author/Supplier: Author: Henry Zhao 1.3 Date of This Document: 20 July, 2010 4. Technical Description 4.1. Summary X server/driver's access to a VGA device falls into two categories: legacy accesses and non-legacy accesses. Legacy accesses are accesses whose addresses are hardcoded and shared with different VGA devices, such as framebuffer (legacy MEM access) and VGA ports (legacy IO access). Non-legacy accesses are accesses whose address are distinct in the address space of different VGA devices, such as memory mapping. In a system with multiple server instances running, there is a risk that a legacy access may apply to all VGA devices so that a VGA device may decode data that was not intended for it. To solve this problem, a kernel driver is needed that controls and arbiters all the accesses such that during a legacy access, only the intended device decodes. The kernel driver receives MEM/IO access requests from X server/driver, and resolves these requests using lock/unlock mechanism to ensure that during a legacy access, MEM/IO access is enabled (for decoding) only on the intended device. Enabling/disabling MEM/IO access of a VGA device is done by enabling/disabling MEM/IO bits of its PCI config space, along with the VGA forwarding bit on any bridges on the path to the device. A program needs to acquire a lock on the target VGA device before it can access it, and releases the lock after access completion. To improve performance, two different locks, legacy locks and non-legacy locks, are arranged in the new design. A request for a non-legacy lock is blocked only when some other device already has a legacy lock (on the same resources). A request for a legacy lock is blocked when some other device already has a legacy or non-legacy lock (on the same resource). This means a request for non-legacy lock should not be blocked just because some other device already has a non-legacy lock (on the same resources). Since the accesses of most graphics operations after initialization are non-legacy, this reduces chances of locking hence improves performance. Potential deadlock may occur when a program holds a non-legacy lock while requesting a legacy lock. The problem is prevented by releasing non-legacy lock resources the same program has acquired before going to sleep, and restoring them after wakeup when the requesting legacy lock is acquired. 4.2. Interfaces Both userland and kernel interfaces are provided. The userland interfaces include open, close, read and write system calls. read() returns the status of the target device. write() commands are further divided into operations to set target device, lock/trylock target device, unlock target device, and set decoding attributes to target device. Kernel interfaces, in addition to acquiring/releasing lock and setting decoding attributes, also allow a client to register callback functions to a VGA to device. The callback functions include resetting decoding attributes when there is a change in configuration, and/or doing IRQ related processing when a device's MEM/IO enable/disable status changes. The latter is needed because when MEM access is disabled, any interrupts, if generated, would not be processed. Exported Interfaces ------------------- Interface Classification Comment /devices/vga_arbiter:vga_arbiter Uncommitted device /platform/kernel/drv//vga_arbiter Uncommitted driver /platform/kernel/drv/vga_arbiter.conf Uncommitted config file Userland -------- Use the standard open, close, read, write system calls to access the device, with string format of read/write commands defined as follows: "target " uncommitted write to device to set target "lock " uncommitted write to device to set lock (wait) "trylock " uncommitted write to device to set lock (no wait) "unlock " uncommitted write to device to unlock "unlock all" uncommitted write to device to unlock "decodes " uncommitted write to device to set decoding attr "count:,card_ID,decodes=,owns=,legalocks=(lic:lmc),normlocks=(nic:nmc)" uncommitted read from device is in a format of "PCI:domain:bus:dev.fn" is a string "io+mem+IO+MEM" or a part of it Kernel ------ void vga_set_legacy_decoding(struct pci_dev *pdev, unsigned int decodes) uncommitted set decoding attributes int vga_get(struct pci_dev *pdev, unsigned int rsrc, unsigned int io_norm_cnt, unsigned int mem_norm_cnt, int interruptible); uncommitted acquire a lock (wait) int vga_tryget(struct pci_dev *pdev, unsigned int rsrc) uncommitted acquire a lock (no wait) void vga_put(struct pci_dev *pdev, unsigned int rsrc) uncommitted release a lock int vga_client_register(struct pci_dev *pdev, void *cookie, void (*irq_set_state)(void *cookie, bool state), unsigned int (*set_vga_decode)(void *cookie, bool state)) uncommitted register callback functions 4.3. Implementation * The original code (using one lock) resides in linux kernel tree: drivers/gpr/vga/vgaarb.c drivers/include/linux/vgaarb.h * Code is modified to add an additional lock (non legacy lock) to improve performance when ported to Solaris. * Hot-plugging (to dynamically handle adding/removing vga devices) will be implemented in second phase. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From garrett@damore.org Wed Jul 21 00:19:47 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6L7Jlwn004857 for ; Wed, 21 Jul 2010 00:19:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6L7JkbB006807 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jul 2010 00:19:47 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5W00005CCYGH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 01:19:46 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5W009CDCCY95D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 01:19:46 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6L7HHIo015057 for ; Wed, 21 Jul 2010 07:19:46 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-637907 for PSARC-ext@sun.com; Wed, 21 Jul 2010 07:19:46 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-43576808 for PSARC-ext@sun.com; Wed, 21 Jul 2010 07:19:42 +0000 (Z) Received: from oproxy2-pub.bluehost.com ([67.222.39.60] [67.222.39.60]) by relay1i.sun.com id BT-MMP-30423029 for PSARC-ext@sun.com; Wed, 21 Jul 2010 07:19:42 +0000 (Z) Received: (qmail 32691 invoked by uid 0); Wed, 21 Jul 2010 07:13:02 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy2.bluehost.com with SMTP; Wed, 21 Jul 2010 07:13:02 +0000 Received: from cpe-75-82-74-133.socal.res.rr.com ([75.82.74.133] helo=[192.168.251.102]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ObTUE-0004Lr-5T; Wed, 21 Jul 2010 01:13:02 -0600 Date: Wed, 21 Jul 2010 00:12:15 -0700 From: "Garrett D'Amore" Subject: Re: VGA arbitration kernel driver [PSARC/2010/276 FastTrack timeout 07/28/2010] In-reply-to: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> To: Alan Coopersmith Cc: PSARC-ext@sun.com Message-id: <1279696335.27995.568.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=uDjTX4UDRLUlMbj4SkDpPkBCjWUrxix/o9PcLBlRuI7V3i4y2AyPfjDOEGY+h4z1XA2QxERHpUSbp1kGnYDmbeFVmD5j5Z5MJi9T0CM+J6aIdNNNakc3Aruy8ONfJb8Q; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 75.82.74.133 authed with garrett+damore.org} X-Antispam: No, score=-2.6/5.0, scanned in 3.114sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> Status: RO Content-Length: 7380 I confess that using read/write with textual commands seems awkward and inefficient -- I'd have thought a simple ioctl interface would have been better. It seems like mmap() has facilities that could handle this arbitration elegantly; or is the problem to provide an interface without updating any X server code? (Is this particular interface already in use on Linux?) - Garrett On Tue, 2010-07-20 at 21:37 -0700, Alan Coopersmith wrote: > I am sponsoring this case for Henry Zhao of the x86 Platform group. > The timeout is set for Wednesday, July 28, 2010. > > Since this only adds new interfaces a release binding of Patch is > requested, though no patch release is planned at this time. > > -Alan Coopersmith- alan.coopersmith@oracle.com > Oracle Solaris Platform Engineering: X Window System > > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > VGA arbitration kernel driver > 1.2. Name of Document Author/Supplier: > Author: Henry Zhao > 1.3 Date of This Document: > 20 July, 2010 > 4. Technical Description > 4.1. Summary > > X server/driver's access to a VGA device falls into two categories: > legacy accesses and non-legacy accesses. Legacy accesses are accesses > whose addresses are hardcoded and shared with different VGA devices, > such as framebuffer (legacy MEM access) and VGA ports (legacy IO > access). Non-legacy accesses are accesses whose address are distinct in > the address space of different VGA devices, such as memory mapping. In a > system with multiple server instances running, there is a risk that a > legacy access may apply to all VGA devices so that a VGA device may > decode data that was not intended for it. To solve this problem, a > kernel driver is needed that controls and arbiters all the accesses such > that during a legacy access, only the intended device decodes. > > The kernel driver receives MEM/IO access requests from X server/driver, > and resolves these requests using lock/unlock mechanism to ensure that > during a legacy access, MEM/IO access is enabled (for decoding) only on > the intended device. Enabling/disabling MEM/IO access of a VGA device is > done by enabling/disabling MEM/IO bits of its PCI config space, along > with the VGA forwarding bit on any bridges on the path to the device. > > A program needs to acquire a lock on the target VGA device before it can > access it, and releases the lock after access completion. To improve > performance, two different locks, legacy locks and non-legacy locks, are > arranged in the new design. A request for a non-legacy lock is blocked > only when some other device already has a legacy lock (on the same > resources). A request for a legacy lock is blocked when some other > device already has a legacy or non-legacy lock (on the same resource). > This means a request for non-legacy lock should not be blocked just > because some other device already has a non-legacy lock (on the same > resources). Since the accesses of most graphics operations after > initialization are non-legacy, this reduces chances of locking hence > improves performance. > > Potential deadlock may occur when a program holds a non-legacy lock > while requesting a legacy lock. The problem is prevented by releasing > non-legacy lock resources the same program has acquired before going to > sleep, and restoring them after wakeup when the requesting legacy lock > is acquired. > > 4.2. Interfaces > > Both userland and kernel interfaces are provided. > > The userland interfaces include open, close, read and write system > calls. read() returns the status of the target device. write() > commands are further divided into operations to set target device, > lock/trylock target device, unlock target device, and set decoding > attributes to target device. > > Kernel interfaces, in addition to acquiring/releasing lock and setting > decoding attributes, also allow a client to register callback functions > to a VGA to device. The callback functions include resetting decoding > attributes when there is a change in configuration, and/or doing IRQ > related processing when a device's MEM/IO enable/disable status > changes. The latter is needed because when MEM access is disabled, > any interrupts, if generated, would not be processed. > > Exported Interfaces > ------------------- > > Interface Classification Comment > > /devices/vga_arbiter:vga_arbiter > Uncommitted device > /platform/kernel/drv//vga_arbiter > Uncommitted driver > /platform/kernel/drv/vga_arbiter.conf > Uncommitted config file > > Userland > -------- > > Use the standard open, close, read, write system calls to access the > device, with string format of read/write commands defined as follows: > > "target " uncommitted write to device to set target > "lock " uncommitted write to device to set lock (wait) > "trylock " uncommitted write to device to set lock (no wait) > "unlock " uncommitted write to device to unlock > "unlock all" uncommitted write to device to unlock > "decodes " uncommitted write to device to set decoding attr > "count:,card_ID,decodes=,owns=,legalocks=(lic:lmc),normlocks=(nic:nmc)" > uncommitted read from device > > is in a format of "PCI:domain:bus:dev.fn" > is a string "io+mem+IO+MEM" or a part of it > > Kernel > ------ > > void vga_set_legacy_decoding(struct pci_dev *pdev, unsigned int decodes) > uncommitted set decoding attributes > > int vga_get(struct pci_dev *pdev, unsigned int rsrc, > unsigned int io_norm_cnt, unsigned int mem_norm_cnt, > int interruptible); > uncommitted acquire a lock (wait) > > int vga_tryget(struct pci_dev *pdev, unsigned int rsrc) > uncommitted acquire a lock (no wait) > > void vga_put(struct pci_dev *pdev, unsigned int rsrc) > uncommitted release a lock > > int vga_client_register(struct pci_dev *pdev, void *cookie, > void (*irq_set_state)(void *cookie, bool state), > unsigned int (*set_vga_decode)(void *cookie, bool state)) > uncommitted register callback functions > > 4.3. Implementation > > * The original code (using one lock) resides in linux kernel tree: > > drivers/gpr/vga/vgaarb.c > drivers/include/linux/vgaarb.h > > * Code is modified to add an additional lock (non legacy lock) to > improve performance when ported to Solaris. > > * Hot-plugging (to dynamically handle adding/removing vga devices) will > be implemented in second phase. > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From alan.coopersmith@oracle.com Wed Jul 21 07:14:10 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6LEE9LJ010733 for ; Wed, 21 Jul 2010 07:14:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6LEE9nS012314 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jul 2010 07:14:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5W00E01VJLSS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 08:14:09 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([10.5.240.82]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5W00GFQVJKJKF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 08:14:08 -0600 (MDT) Received: from [129.145.155.53] (sunray-osol-2.SFBay.Sun.COM [129.145.155.53]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o6LEE74P192094; Wed, 21 Jul 2010 07:14:08 -0700 (PDT) Date: Wed, 21 Jul 2010 07:14:07 -0700 From: Alan Coopersmith Subject: Re: VGA arbitration kernel driver [PSARC/2010/276 FastTrack timeout 07/28/2010] In-reply-to: <1279696335.27995.568.camel@velocity> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <4C4700AF.10902@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> <1279696335.27995.568.camel@velocity> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1053 Garrett D'Amore wrote: > I confess that using read/write with textual commands seems awkward and > inefficient -- I'd have thought a simple ioctl interface would have been > better. It seems like mmap() has facilities that could handle this > arbitration elegantly; or is the problem to provide an interface without > updating any X server code? (Is this particular interface already in > use on Linux?) Understood and agreed (I asked the submitter the same thing when preparing the case to make sure I understood it correctly) but this interface is what's already established and in use on Linux, so we'd have to fork the Xorg code to change it. While it may not be a common design pattern in the Solaris kernel, it does seem to be more common in the Linux kernel (see all their /proc interfaces that can be read or written as plain text strings, allowing observability & configuration with nothing more complex than cat & echo). -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From garrett@damore.org Wed Jul 21 08:48:16 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6LFmGBp012779 for ; Wed, 21 Jul 2010 08:48:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6LFmGNi021893 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jul 2010 08:48:16 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5W00B1HZWG9G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 08:48:16 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5W00AHYZWFOD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 08:48:15 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6LFfw5f012418 for ; Wed, 21 Jul 2010 15:48:15 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-100770 for PSARC-ext@sun.com; Wed, 21 Jul 2010 15:48:15 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-36776617 for PSARC-ext@sun.com; Wed, 21 Jul 2010 15:48:14 +0000 (Z) Received: from oproxy2-pub.bluehost.com ([67.222.39.60] [67.222.39.60]) by relay4i.sun.com id BT-MMP-5104593 for PSARC-ext@sun.com; Wed, 21 Jul 2010 15:48:14 +0000 (Z) Received: (qmail 3284 invoked by uid 0); Wed, 21 Jul 2010 15:48:12 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy2.bluehost.com with SMTP; Wed, 21 Jul 2010 15:48:12 +0000 Received: from cpe-75-82-74-133.socal.res.rr.com ([75.82.74.133] helo=[192.168.251.102]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ObbWm-0004oP-Pa; Wed, 21 Jul 2010 09:48:12 -0600 Date: Wed, 21 Jul 2010 08:47:24 -0700 From: "Garrett D'Amore" Subject: Re: VGA arbitration kernel driver [PSARC/2010/276 FastTrack timeout 07/28/2010] In-reply-to: <4C4700AF.10902@oracle.com> To: Alan Coopersmith Cc: PSARC-ext@sun.com Message-id: <1279727244.27995.578.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=LuqUV0VGQRGNXFhZTHZawk9iaZLzBQqlBhIB3fnHMZGTl+ufh4k9NNM2+nyDCZ1NOlZ0OWrYFu6x/q6xOW2NonQLPAA5E/b9p0uwI2Rci7LqONlUU92i5joxlX8Jf8V6; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 75.82.74.133 authed with garrett+damore.org} X-Antispam: No, score=-0.2/5.0, scanned in 0.592sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> <1279696335.27995.568.camel@velocity> <4C4700AF.10902@oracle.com> Status: RO Content-Length: 1329 On Wed, 2010-07-21 at 07:14 -0700, Alan Coopersmith wrote: > Garrett D'Amore wrote: > > I confess that using read/write with textual commands seems awkward and > > inefficient -- I'd have thought a simple ioctl interface would have been > > better. It seems like mmap() has facilities that could handle this > > arbitration elegantly; or is the problem to provide an interface without > > updating any X server code? (Is this particular interface already in > > use on Linux?) > > Understood and agreed (I asked the submitter the same thing when preparing > the case to make sure I understood it correctly) but this interface is what's > already established and in use on Linux, so we'd have to fork the Xorg code > to change it. While it may not be a common design pattern in the Solaris > kernel, it does seem to be more common in the Linux kernel (see all their > /proc interfaces that can be read or written as plain text strings, allowing > observability & configuration with nothing more complex than cat & echo). > Okay, as long as the Solaris "normal" way of doing things was considered, then I don't see anything fundamentally wrong with this case. +1, while I kind of hold my nose. (Because IMO, making a text parser have to be used in the kernel for a strictly IPC interface is kind of ugly.) - Garrett From henry.zhao@oracle.com Wed Jul 21 11:01:53 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6LI1rAc017564 for ; Wed, 21 Jul 2010 11:01:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6LI1rvX013488 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jul 2010 11:01:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L5X00I0R6322O00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 11:01:50 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5X00ACN631OK70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 11:01:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6LI1nwv005714 for ; Wed, 21 Jul 2010 18:01:49 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6K4f06H028639; Wed, 21 Jul 2010 18:01:45 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 424705591279735294; Wed, 21 Jul 2010 11:01:34 -0700 Received: from [10.1.48.91] (/10.1.48.91) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jul 2010 11:01:33 -0700 Date: Wed, 21 Jul 2010 10:59:24 -0700 From: Henry Zhao Subject: Re: VGA arbitration kernel driver [PSARC/2010/276 FastTrack timeout 07/28/2010] In-reply-to: <1279727244.27995.578.camel@velocity> To: "Garrett D'Amore" Cc: Alan Coopersmith , PSARC-ext@sun.com Message-id: <4C47357C.3080701@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C47360A.01C6:SCFMA4539814,ss=1,fgs=0 References: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> <1279696335.27995.568.camel@velocity> <4C4700AF.10902@oracle.com> <1279727244.27995.578.camel@velocity> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1765 Add the following to Alan's comments: If we changed the read/write interface, then it would cause not only difficulties in maintaining and sync'ing of the code in the future, but also require to create a totally different set of userland interface library (in libpciacess) to match the change. It isn't worth it. -Henry On 07/21/10 08:47, Garrett D'Amore wrote: > On Wed, 2010-07-21 at 07:14 -0700, Alan Coopersmith wrote: > >> Garrett D'Amore wrote: >> >>> I confess that using read/write with textual commands seems awkward and >>> inefficient -- I'd have thought a simple ioctl interface would have been >>> better. It seems like mmap() has facilities that could handle this >>> arbitration elegantly; or is the problem to provide an interface without >>> updating any X server code? (Is this particular interface already in >>> use on Linux?) >>> >> Understood and agreed (I asked the submitter the same thing when preparing >> the case to make sure I understood it correctly) but this interface is what's >> already established and in use on Linux, so we'd have to fork the Xorg code >> to change it. While it may not be a common design pattern in the Solaris >> kernel, it does seem to be more common in the Linux kernel (see all their >> /proc interfaces that can be read or written as plain text strings, allowing >> observability& configuration with nothing more complex than cat& echo). >> >> > > Okay, as long as the Solaris "normal" way of doing things was > considered, then I don't see anything fundamentally wrong with this > case. +1, while I kind of hold my nose. (Because IMO, making a text > parser have to be used in the kernel for a strictly IPC interface is > kind of ugly.) > > - Garrett > > > > From alan.coopersmith@oracle.com Fri Jul 30 08:54:08 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6UFs8uK005151 for ; Fri, 30 Jul 2010 08:54:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6UFs3HH015078 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Jul 2010 10:54:07 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L6D0000ZO66WW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Jul 2010 08:54:06 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([10.5.240.82]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L6D00BC9O66CQF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Jul 2010 08:54:06 -0700 (PDT) Received: from [129.145.155.53] (sunray-osol-2.SFBay.Sun.COM [129.145.155.53]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o6UFs66t718987 for ; Fri, 30 Jul 2010 08:54:06 -0700 (PDT) Date: Fri, 30 Jul 2010 08:54:06 -0700 From: Alan Coopersmith Subject: Re: VGA arbitration kernel driver [PSARC/2010/276 FastTrack timeout 07/28/2010] In-reply-to: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> To: PSARC-ext@sun.com Message-id: <4C52F59E.3090406@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <201007210437.o6L4bMwX004688@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 356 Alan Coopersmith wrote: > I am sponsoring this case for Henry Zhao of the x86 Platform group. > The timeout is set for Wednesday, July 28, 2010. The timeout is past, and a +1 was received from Garrett, so this case is now closed approved. -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System