From Fri Mar 7 16:07:38 2008 Date: Fri, 7 Mar 2008 16:07:38 -0800 (PST) From: Postmaster Subject: Message from mail server Content-Length: 95 Mime-Version: 1.0 Status: RO X-IMAP: 1204934858 22 Delete. This is a system message. --END+PSEUDO-- From tl41329@sac.sfbay.sun.com Tue Mar 4 01:04:51 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2494pto006527 for ; Tue, 4 Mar 2008 01:04:51 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2494oHw008976; Tue, 4 Mar 2008 01:04:50 -0800 (PST) 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 <0JX700D0H7W2YO00@nwk-avmta-2.sfbay.sun.com>; Tue, 04 Mar 2008 01:04:50 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX700BP77W1KA40@nwk-avmta-2.sfbay.sun.com>; Tue, 04 Mar 2008 01:04:49 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2494n98064290; Tue, 04 Mar 2008 01:04:49 -0800 (PST) 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 m248vITT006328; Tue, 04 Mar 2008 00:57:18 -0800 (PST) Received: (from tl41329@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m248vIkW006324; Tue, 04 Mar 2008 00:57:18 -0800 (PST) Date: Tue, 04 Mar 2008 00:57:18 -0800 (PST) From: Tzongyu Paul Lee Subject: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: PSARC-ext@sun.com Message-id: <200803040857.m248vIkW006324@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Content-Length: 5775 Status: RO X-Status: $$$$ X-UID: 0000000001 I am sponsoring this fast-track for Raymond Chen. Requested release binding is minor, and the timer is set to 03/11/2008. Regards, T.Paul Lee Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Integrate libsane and sane into Solaris 1.2. Name of Document Author/Supplier: Author: Raymond Chen 1.3 Date of This Document: 04 March, 2008 4. Technical Description Summary This project integrates libsane and sane into Solaris. This project requests a minor binding. 4.1 Details SANE is an application programming interface (API) that provides standardized access to any raster image scanner hardware. The standardized interface makes it possible to write just one driver for each scanner device instead of one driver for each scanner and application. SANE is clearly separated into applications(frontends) and scanner drivers(backends). A SANE backend provides an interface with the hardware and describes a number of options which drive each scanner. sane, in this proposal, refers to applications that are delivered by SANE community, http://www.sane-project.org/. "sane-backends" package of FOSS project SANE contains backends, documentation, networking support and the command line frontend "scanimage". In this project, the following components will be ported and integrated into Solaris: 1)sane-backends sane-backends contain drivers for popular scanners on the market. This project proposes to only support local USB scanners. As an effort to enrich desktop applications for Indiana, SANE network feature is not considered essential and hence out of scope for this project. A future case may support this functionality. 2)libsane Standard SANE APIs are provided by libsane. Different frontends are developed on the base of such set of API. 3)sane documentation User manuals. 4)scanimage scanimage is a command-line interface to control image acquisition devices. It is one of the SANE frontends. 5)xscanimage xscanimage provides a graphical user interface to control an image acquisition device such as scanner. It allows previewing and scanning individual images. SANE depends on the scanner's device special file for access control. For USB interface scanners, by default only users on console or superuser have permission to access the devnode, which is controlled by logindevperm(4). It is also possible to restrict access to a scanner using Solaris device allocation subsystem. Sysadmin can enable BSM and put scanner device special file (exported by ugen(7D)) in device_map and device_allocate(4), so that the scanner is allocatable and then can be used by only one qualified user at a time. 4.2 Interface description All interfaces in sane.h and saneopts.h are exported as Volatile. Exported interfaces ------------------- SUNWsane Uncommitted SANE frontends SUNWsane-backends Uncommitted SANE backends -- library and drivers /usr/include/sane/sane.h Volatile SANE API header file /usr/include/sane/saneopts.h Volatile SANE options header file /usr/lib/libsane.so.1.0.19 Volatile SANE library /usr/lib/sane/* Volatile SANE backends /etc/sane.d/dll.conf Volatile Contain backend names /etc/sane.d/*.conf Volatile Each backend has a .conf /usr/bin/scanimage Volatile SANE CLI frontend /usr/bin/xscanimage Volatile SANE GUI frontend /usr/bin/sane-config Volatile Utility to get information about installed libsane /usr/bin/sane-find-scanner Volatile Utility to find scanners /usr/share/man/man1/scanimage.1 Volatile manual /usr/share/man/man1/xscanimage.1 Volatile manual /usr/share/man/man1/sane-find-scanner.1 Volatile manual /usr/share/man/man1/sane-config.1 Volatile manual /usr/share/man/man7/sane.7 Volatile manual /usr/share/man/man5/sane-*.5 Volatile Sane backends manual --------------- SANE C API ---------------------------------------- sane_init Volatile Initialize the backend sane_exit Volatile Terminate use of a backend sane_get_devices Volatile Query the list of devices sane_open Volatile Establish association with a particular device sane_close Volatile Terminates the above association sane_get_option_descriptor Volatile Access option descriptors sane_control_option Volatile Set/query the current value of option number sane_get_parameters Volatile Obtain the current scan parameters sane_start Volatile Initiates acquisition of an image sane_read Volatile Read image data from the device sane_cancel Volatile Cancel the pending operation sane_set_io_mode Volatile Set the I/O mode sane_get_select_fd Volatile Obtain file-descriptor from handle sane_strstatus Volatile Translate SANE status code into printable string Imported Interfaces -------------------- libusb Volatile User-space USB device management library libjpeg Uncommitted JPEG image compression and decompression libtiff Uncommitted Reading and writing TIFF files GTK+ Volatile GNOME Desktop Library GDK Volatile GNOME Desktop Library 5. References [1] http://www.sane-project.org/ [2] LSARC/2006/734 GNOME 2.16 [3] LSARC 2003/085 libtiff, libjpeg and libpng. [4] PSARC 2003/721 libusb: user level usb library [5] LSARC 2007/018 Sane-backends and Xsane 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Kenny@sun.com Tue Mar 4 01:26:42 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m249QfTD006662 for ; Tue, 4 Mar 2008 01:26:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m249QZJ7010663 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 Mar 2008 17:26:40 +0800 (SGT) 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 <0JX700B038WEAU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 02:26:38 -0700 (MST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX700LN68WCY6E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 02:26:37 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m249QaKa010101 for ; Tue, 04 Mar 2008 09:26:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX7002018H6LS00@fe-emea-10.sun.com> (original mail from Darren.Kenny@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 09:26:36 +0000 (GMT) Received: from [129.156.226.196] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX700BQE8W7CJ90@fe-emea-10.sun.com>; Tue, 04 Mar 2008 09:26:32 +0000 (GMT) Date: Tue, 04 Mar 2008 09:26:10 +0000 From: Darren Kenny Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803040857.m248vIkW006324@sac.sfbay.sun.com> Sender: Darren.Kenny@sun.com To: Tzongyu Paul Lee Cc: PSARC-ext@sun.com Message-id: <47CD15B2.5080806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Content-Length: 6390 Status: RO X-Status: $$$$ X-UID: 0000000002 Hi, Is there any chance that libsane could be elevated to the stability level of at least Uncommitted so that it would be usable by other projects? Specifically, I'm thinking of GNOME Scan or GIMP, but also possibly OpenOffice/StarOffice (but I'm not 100% sure here). Thanks, Darren. Tzongyu Paul Lee wrote: > I am sponsoring this fast-track for Raymond Chen. > Requested release binding is minor, and the timer is set to > 03/11/2008. > > Regards, > T.Paul Lee > > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Integrate libsane and sane into Solaris > 1.2. Name of Document Author/Supplier: > Author: Raymond Chen > 1.3 Date of This Document: > 04 March, 2008 > 4. Technical Description > Summary > This project integrates libsane and sane into Solaris. > This project requests a minor binding. > > 4.1 Details > > SANE is an application programming interface (API) that provides > standardized access to any raster image scanner hardware. The > standardized interface makes it possible to write just one > driver for each scanner device instead of one driver for each > scanner and application. > > SANE is clearly separated into applications(frontends) and scanner > drivers(backends). A SANE backend provides an interface with the > hardware and describes a number of options which drive each scanner. > sane, in this proposal, refers to applications that > are delivered by SANE community, http://www.sane-project.org/. > > "sane-backends" package of FOSS project SANE contains backends, > documentation, networking support and the command line frontend > "scanimage". > > In this project, the following components will be ported and > integrated into Solaris: > > 1)sane-backends > sane-backends contain drivers for popular scanners on the > market. This project proposes to only support local USB > scanners. > As an effort to enrich desktop applications for Indiana, > SANE network feature is not considered essential and hence > out of scope for this project. A future case may support > this functionality. > > 2)libsane > Standard SANE APIs are provided by libsane. Different > frontends are developed on the base of such set of API. > > 3)sane documentation > User manuals. > > 4)scanimage > scanimage is a command-line interface to control image > acquisition devices. It is one of the SANE frontends. > > 5)xscanimage > xscanimage provides a graphical user interface to control > an image acquisition device such as scanner. It allows > previewing and scanning individual images. > > SANE depends on the scanner's device special file for access control. > For USB interface scanners, by default only users on console or > superuser have permission to access the devnode, which is controlled > by logindevperm(4). It is also possible to restrict access to a > scanner using Solaris device allocation subsystem. Sysadmin can enable > BSM and put scanner device special file (exported by ugen(7D)) in > device_map and device_allocate(4), so that the scanner is allocatable > and then can be used by only one qualified user at a time. > > > 4.2 Interface description > > All interfaces in sane.h and saneopts.h are exported as Volatile. > > Exported interfaces > ------------------- > SUNWsane Uncommitted SANE frontends > SUNWsane-backends Uncommitted SANE backends -- > library and drivers > /usr/include/sane/sane.h Volatile SANE API header file > /usr/include/sane/saneopts.h Volatile SANE options header file > /usr/lib/libsane.so.1.0.19 Volatile SANE library > /usr/lib/sane/* Volatile SANE backends > /etc/sane.d/dll.conf Volatile Contain backend names > /etc/sane.d/*.conf Volatile Each backend has a .conf > > /usr/bin/scanimage Volatile SANE CLI frontend > /usr/bin/xscanimage Volatile SANE GUI frontend > /usr/bin/sane-config Volatile Utility to get information > about installed libsane > /usr/bin/sane-find-scanner Volatile Utility to find scanners > > /usr/share/man/man1/scanimage.1 Volatile manual > /usr/share/man/man1/xscanimage.1 Volatile manual > /usr/share/man/man1/sane-find-scanner.1 Volatile manual > /usr/share/man/man1/sane-config.1 Volatile manual > /usr/share/man/man7/sane.7 Volatile manual > /usr/share/man/man5/sane-*.5 Volatile Sane backends manual > > --------------- SANE C API ---------------------------------------- > sane_init Volatile Initialize the backend > sane_exit Volatile Terminate use of a backend > sane_get_devices Volatile Query the list of devices > sane_open Volatile Establish association with a > particular device > sane_close Volatile Terminates the above association > sane_get_option_descriptor Volatile Access option descriptors > sane_control_option Volatile Set/query the current value of > option number > sane_get_parameters Volatile Obtain the current scan parameters > sane_start Volatile Initiates acquisition of an image > sane_read Volatile Read image data from the device > sane_cancel Volatile Cancel the pending operation > sane_set_io_mode Volatile Set the I/O mode > sane_get_select_fd Volatile Obtain file-descriptor from handle > sane_strstatus Volatile Translate SANE status code into > printable string > > Imported Interfaces > -------------------- > libusb Volatile User-space USB device management > library > libjpeg Uncommitted JPEG image compression and > decompression > libtiff Uncommitted Reading and writing TIFF files > GTK+ Volatile GNOME Desktop Library > GDK Volatile GNOME Desktop Library > > > 5. References > [1] http://www.sane-project.org/ > [2] LSARC/2006/734 GNOME 2.16 > [3] LSARC 2003/085 libtiff, libjpeg and libpng. > [4] PSARC 2003/721 libusb: user level usb library > [5] LSARC 2007/018 Sane-backends and Xsane > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > sfw > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From Raymond.Chen@sun.com Tue Mar 4 03:05:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m24B50k8009755 for ; Tue, 4 Mar 2008 03:05:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m24B4sXK018822 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 Mar 2008 19:04:59 +0800 (SGT) 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 <0JX700C09DG9N400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 03:04:57 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX700CKYDG87E00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 03:04:57 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m24B51gi001751 for ; Tue, 04 Mar 2008 11:05:01 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JX700001D6JX500@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 19:04:55 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX700BYQDG6MFQA@mail-apac.sun.com>; Tue, 04 Mar 2008 19:04:55 +0800 (SGT) Date: Tue, 04 Mar 2008 19:12:02 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CD15B2.5080806@Sun.COM> Sender: Raymond.Chen@sun.com To: Darren Kenny Cc: Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <47CD2E82.3080805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Content-Length: 7098 Status: RO X-Status: $$$$ X-UID: 0000000003 Darren Kenny wrote: > Hi, > > Is there any chance that libsane could be elevated to the stability level of at > least Uncommitted so that it would be usable by other projects? > The stable SANE standard is at version 1.04 and it has been there for some time. But there's also a new SANE standard under development[1]. I'm not sure when the new version will be applied. Per my understanding of interface stability level, use of Uncommitted and Volatile interfaces has not much difference[2]. Do you have information about Volatile interface usage limitation? Regards, Lei Chen [1] http://www.sane-project.org/docs.html [2]http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ > Specifically, I'm thinking of GNOME Scan or GIMP, but also possibly > OpenOffice/StarOffice (but I'm not 100% sure here). > > Thanks, > > Darren. > > Tzongyu Paul Lee wrote: > >> I am sponsoring this fast-track for Raymond Chen. >> Requested release binding is minor, and the timer is set to >> 03/11/2008. >> >> Regards, >> T.Paul Lee >> >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Integrate libsane and sane into Solaris >> 1.2. Name of Document Author/Supplier: >> Author: Raymond Chen >> 1.3 Date of This Document: >> 04 March, 2008 >> 4. Technical Description >> Summary >> This project integrates libsane and sane into Solaris. >> This project requests a minor binding. >> >> 4.1 Details >> >> SANE is an application programming interface (API) that provides >> standardized access to any raster image scanner hardware. The >> standardized interface makes it possible to write just one >> driver for each scanner device instead of one driver for each >> scanner and application. >> >> SANE is clearly separated into applications(frontends) and scanner >> drivers(backends). A SANE backend provides an interface with the >> hardware and describes a number of options which drive each scanner. >> sane, in this proposal, refers to applications that >> are delivered by SANE community, http://www.sane-project.org/. >> >> "sane-backends" package of FOSS project SANE contains backends, >> documentation, networking support and the command line frontend >> "scanimage". >> >> In this project, the following components will be ported and >> integrated into Solaris: >> >> 1)sane-backends >> sane-backends contain drivers for popular scanners on the >> market. This project proposes to only support local USB >> scanners. >> As an effort to enrich desktop applications for Indiana, >> SANE network feature is not considered essential and hence >> out of scope for this project. A future case may support >> this functionality. >> >> 2)libsane >> Standard SANE APIs are provided by libsane. Different >> frontends are developed on the base of such set of API. >> >> 3)sane documentation >> User manuals. >> >> 4)scanimage >> scanimage is a command-line interface to control image >> acquisition devices. It is one of the SANE frontends. >> >> 5)xscanimage >> xscanimage provides a graphical user interface to control >> an image acquisition device such as scanner. It allows >> previewing and scanning individual images. >> >> SANE depends on the scanner's device special file for access control. >> For USB interface scanners, by default only users on console or >> superuser have permission to access the devnode, which is controlled >> by logindevperm(4). It is also possible to restrict access to a >> scanner using Solaris device allocation subsystem. Sysadmin can enable >> BSM and put scanner device special file (exported by ugen(7D)) in >> device_map and device_allocate(4), so that the scanner is allocatable >> and then can be used by only one qualified user at a time. >> >> >> 4.2 Interface description >> >> All interfaces in sane.h and saneopts.h are exported as Volatile. >> >> Exported interfaces >> ------------------- >> SUNWsane Uncommitted SANE frontends >> SUNWsane-backends Uncommitted SANE backends -- >> library and drivers >> /usr/include/sane/sane.h Volatile SANE API header file >> /usr/include/sane/saneopts.h Volatile SANE options header file >> /usr/lib/libsane.so.1.0.19 Volatile SANE library >> /usr/lib/sane/* Volatile SANE backends >> /etc/sane.d/dll.conf Volatile Contain backend names >> /etc/sane.d/*.conf Volatile Each backend has a .conf >> >> /usr/bin/scanimage Volatile SANE CLI frontend >> /usr/bin/xscanimage Volatile SANE GUI frontend >> /usr/bin/sane-config Volatile Utility to get information >> about installed libsane >> /usr/bin/sane-find-scanner Volatile Utility to find scanners >> >> /usr/share/man/man1/scanimage.1 Volatile manual >> /usr/share/man/man1/xscanimage.1 Volatile manual >> /usr/share/man/man1/sane-find-scanner.1 Volatile manual >> /usr/share/man/man1/sane-config.1 Volatile manual >> /usr/share/man/man7/sane.7 Volatile manual >> /usr/share/man/man5/sane-*.5 Volatile Sane backends manual >> >> --------------- SANE C API ---------------------------------------- >> sane_init Volatile Initialize the backend >> sane_exit Volatile Terminate use of a backend >> sane_get_devices Volatile Query the list of devices >> sane_open Volatile Establish association with a >> particular device >> sane_close Volatile Terminates the above association >> sane_get_option_descriptor Volatile Access option descriptors >> sane_control_option Volatile Set/query the current value of >> option number >> sane_get_parameters Volatile Obtain the current scan parameters >> sane_start Volatile Initiates acquisition of an image >> sane_read Volatile Read image data from the device >> sane_cancel Volatile Cancel the pending operation >> sane_set_io_mode Volatile Set the I/O mode >> sane_get_select_fd Volatile Obtain file-descriptor from handle >> sane_strstatus Volatile Translate SANE status code into >> printable string >> >> Imported Interfaces >> -------------------- >> libusb Volatile User-space USB device management >> library >> libjpeg Uncommitted JPEG image compression and >> decompression >> libtiff Uncommitted Reading and writing TIFF files >> GTK+ Volatile GNOME Desktop Library >> GDK Volatile GNOME Desktop Library >> >> >> 5. References >> [1] http://www.sane-project.org/ >> [2] LSARC/2006/734 GNOME 2.16 >> [3] LSARC 2003/085 libtiff, libjpeg and libpng. >> [4] PSARC 2003/721 libusb: user level usb library >> [5] LSARC 2007/018 Sane-backends and Xsane >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> sfw >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> From carlsonj@phorcys.east.sun.com Tue Mar 4 04:41:08 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m24Cf7HU012473 for ; Tue, 4 Mar 2008 04:41:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m24CeYuO008221; Tue, 4 Mar 2008 12:41:04 GMT 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 <0JX700M0FHWDCX00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 04 Mar 2008 04:41:01 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX700CXMHWC7H80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 04 Mar 2008 04:41:01 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m24Cex1H018865; Tue, 04 Mar 2008 07:40:59 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m24CexfA018862; Tue, 04 Mar 2008 07:40:59 -0500 (EST) Date: Tue, 04 Mar 2008 07:40:59 -0500 From: James Carlson Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CD2E82.3080805@sun.com> To: Lei Chen Cc: Darren Kenny , Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <18381.17243.561462.575454@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> Content-Length: 1829 Status: RO X-Status: $$$$ X-UID: 0000000004 Lei Chen writes: > Per my understanding of interface stability level, use of Uncommitted > and Volatile interfaces has not much difference[2]. They're quite different. "Uncommitted" means that we don't plan to make incompatible changes in a patch, but may do so on Minor release boundaries (such as Solaris 10 -> Solaris 11). "Volatile" means that we may make incompatible changes at any time, including in patches. Volatile is pretty close to useless for libraries. The only users of such library would be consumers in the same consolidation (treating it as Consolidation Private, which has the same break-at-any-time semantics) and those that use an ARC contract to nail down the interface (effectively treating it as higher than just Volatile). All others would be excluded, on the grounds that you'd end up with fragile software. The situation you describe with the new-release-in-development sounds to me like at least Uncommitted and perhaps even Committed. If the new release is incompatible, then we'll need to figure out a transition in the future -- perhaps. But the strong force making this less likely is that libsane already has consumers who likely aren't going to be happy about retooling for incompatible changes. Popularity is one good guard against that kind of breakage. > Do you have > information about Volatile interface usage limitation? I don't think there's much of a point to integrating libraries -- or anything intended to be used by other programs rather than directly by humans -- as Volatile. It just builds an attractive nuisance. There oughta be a law ... -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Brian.Cameron@sun.com Tue Mar 4 09:28:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m24HSkDn019441 for ; Tue, 4 Mar 2008 09:28:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m24HSelN019597 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 Mar 2008 17:28:45 GMT 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 <0JX700BA5V7X2S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 09:28:45 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX7007TBV7VCXB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 09:28:43 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m24HShr2001825 for ; Tue, 04 Mar 2008 17:28:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX700101U4GQX00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 10:28:43 -0700 (MST) Received: from [192.168.1.64] ([189.137.190.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX700BRAV7SY490@mail-amer.sun.com>; Tue, 04 Mar 2008 10:28:42 -0700 (MST) Date: Tue, 04 Mar 2008 11:28:43 -0600 From: Brian Cameron Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803040857.m248vIkW006324@sac.sfbay.sun.com> Sender: Brian.Cameron@sun.com To: Tzongyu Paul Lee Cc: PSARC-ext@sun.com Message-id: <47CD86CB.8050208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Content-Length: 6595 Status: RO X-Status: $$$$ X-UID: 0000000005 Note that Sane and libsane was previously ARC'ed via LSARC http://sac.eng.sun.com/arc/LSARC/2007/018/ This case was derailed due to some concerns that Gary Winiger had. Therefore, I am not sure that this case will be non-controversial or appropriate for FastTrack. At any rate, effort should be made to make sure that the issues that were raised in the previous ARC case are addressed. Brian > I am sponsoring this fast-track for Raymond Chen. > Requested release binding is minor, and the timer is set to > 03/11/2008. > > Regards, > T.Paul Lee > > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Integrate libsane and sane into Solaris > 1.2. Name of Document Author/Supplier: > Author: Raymond Chen > 1.3 Date of This Document: > 04 March, 2008 > 4. Technical Description > Summary > This project integrates libsane and sane into Solaris. > This project requests a minor binding. > > 4.1 Details > > SANE is an application programming interface (API) that provides > standardized access to any raster image scanner hardware. The > standardized interface makes it possible to write just one > driver for each scanner device instead of one driver for each > scanner and application. > > SANE is clearly separated into applications(frontends) and scanner > drivers(backends). A SANE backend provides an interface with the > hardware and describes a number of options which drive each scanner. > sane, in this proposal, refers to applications that > are delivered by SANE community, http://www.sane-project.org/. > > "sane-backends" package of FOSS project SANE contains backends, > documentation, networking support and the command line frontend > "scanimage". > > In this project, the following components will be ported and > integrated into Solaris: > > 1)sane-backends > sane-backends contain drivers for popular scanners on the > market. This project proposes to only support local USB > scanners. > As an effort to enrich desktop applications for Indiana, > SANE network feature is not considered essential and hence > out of scope for this project. A future case may support > this functionality. > > 2)libsane > Standard SANE APIs are provided by libsane. Different > frontends are developed on the base of such set of API. > > 3)sane documentation > User manuals. > > 4)scanimage > scanimage is a command-line interface to control image > acquisition devices. It is one of the SANE frontends. > > 5)xscanimage > xscanimage provides a graphical user interface to control > an image acquisition device such as scanner. It allows > previewing and scanning individual images. > > SANE depends on the scanner's device special file for access control. > For USB interface scanners, by default only users on console or > superuser have permission to access the devnode, which is controlled > by logindevperm(4). It is also possible to restrict access to a > scanner using Solaris device allocation subsystem. Sysadmin can enable > BSM and put scanner device special file (exported by ugen(7D)) in > device_map and device_allocate(4), so that the scanner is allocatable > and then can be used by only one qualified user at a time. > > > 4.2 Interface description > > All interfaces in sane.h and saneopts.h are exported as Volatile. > > Exported interfaces > ------------------- > SUNWsane Uncommitted SANE frontends > SUNWsane-backends Uncommitted SANE backends -- > library and drivers > /usr/include/sane/sane.h Volatile SANE API header file > /usr/include/sane/saneopts.h Volatile SANE options header file > /usr/lib/libsane.so.1.0.19 Volatile SANE library > /usr/lib/sane/* Volatile SANE backends > /etc/sane.d/dll.conf Volatile Contain backend names > /etc/sane.d/*.conf Volatile Each backend has a .conf > > /usr/bin/scanimage Volatile SANE CLI frontend > /usr/bin/xscanimage Volatile SANE GUI frontend > /usr/bin/sane-config Volatile Utility to get information > about installed libsane > /usr/bin/sane-find-scanner Volatile Utility to find scanners > > /usr/share/man/man1/scanimage.1 Volatile manual > /usr/share/man/man1/xscanimage.1 Volatile manual > /usr/share/man/man1/sane-find-scanner.1 Volatile manual > /usr/share/man/man1/sane-config.1 Volatile manual > /usr/share/man/man7/sane.7 Volatile manual > /usr/share/man/man5/sane-*.5 Volatile Sane backends manual > > --------------- SANE C API ---------------------------------------- > sane_init Volatile Initialize the backend > sane_exit Volatile Terminate use of a backend > sane_get_devices Volatile Query the list of devices > sane_open Volatile Establish association with a > particular device > sane_close Volatile Terminates the above association > sane_get_option_descriptor Volatile Access option descriptors > sane_control_option Volatile Set/query the current value of > option number > sane_get_parameters Volatile Obtain the current scan parameters > sane_start Volatile Initiates acquisition of an image > sane_read Volatile Read image data from the device > sane_cancel Volatile Cancel the pending operation > sane_set_io_mode Volatile Set the I/O mode > sane_get_select_fd Volatile Obtain file-descriptor from handle > sane_strstatus Volatile Translate SANE status code into > printable string > > Imported Interfaces > -------------------- > libusb Volatile User-space USB device management > library > libjpeg Uncommitted JPEG image compression and > decompression > libtiff Uncommitted Reading and writing TIFF files > GTK+ Volatile GNOME Desktop Library > GDK Volatile GNOME Desktop Library > > > 5. References > [1] http://www.sane-project.org/ > [2] LSARC/2006/734 GNOME 2.16 > [3] LSARC 2003/085 libtiff, libjpeg and libpng. > [4] PSARC 2003/721 libusb: user level usb library > [5] LSARC 2007/018 Sane-backends and Xsane > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > sfw > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Norm.Jacobs@sun.com Tue Mar 4 10:56:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m24IuVqk023383 for ; Tue, 4 Mar 2008 10:56:31 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m24IuR3b000395 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 4 Mar 2008 18:56:30 GMT 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 <0JX700F2FZA2TA00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 04 Mar 2008 11:56:27 -0700 (MST) Received: from printing.Eng.Sun.COM ([129.146.178.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX700BBBZ9ZVM70@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 04 Mar 2008 11:56:24 -0700 (MST) Received: from snappy.1149-Donegal-Ln.northbrook.il.us (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.Eng.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m24IvXq1000124; Tue, 04 Mar 2008 10:57:34 -0800 (PST) Date: Tue, 04 Mar 2008 12:55:15 -0600 From: Norm Jacobs Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803040857.m248vIkW006324@sac.sfbay.sun.com> To: Tzongyu Paul Lee Cc: PSARC-ext@sun.com Message-id: <47CD9B13.3060007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080115) Content-Length: 437 Status: RO X-Status: $$$$ X-UID: 0000000006 Tzongyu Paul Lee wrote > 4.2 Interface description > > All interfaces in sane.h and saneopts.h are exported as Volatile. > > Exported interfaces > ------------------- > /usr/lib/libsane.so.1.0.19 Volatile SANE library > As merely a lurker with some interest in integrating software that uses libsane... Are you contemplating consumers outside of this project? Will there be any 64-bit support? -Norm From Raymond.Chen@sun.com Tue Mar 4 17:51:55 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m251psg5005719 for ; Tue, 4 Mar 2008 17:51:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m251pZFf008702 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 09:51:53 +0800 (SGT) 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 <0JX800103IIGR700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 18:51:52 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX800L31IIDOQD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 18:51:50 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m251q5Dc015511 for ; Wed, 05 Mar 2008 01:52:05 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JX800K01IGUAL00@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 09:51:49 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX8006CNIIAKKJH@mail-apac.sun.com>; Wed, 05 Mar 2008 09:51:47 +0800 (SGT) Date: Wed, 05 Mar 2008 09:58:53 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CD86CB.8050208@sun.com> Sender: Raymond.Chen@sun.com To: Brian Cameron Cc: Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <47CDFE5D.4050401@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WPfo9HvZeIT4ZFo2v3/yDQ)" X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD86CB.8050208@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Content-Length: 26809 Status: RO X-Status: $$$$ X-UID: 0000000007 This is a multi-part message in MIME format. --Boundary_(ID_WPfo9HvZeIT4ZFo2v3/yDQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Brian Cameron wrote: > > Note that Sane and libsane was previously ARC'ed via LSARC > > http://sac.eng.sun.com/arc/LSARC/2007/018/ > > This case was derailed due to some concerns that Gary Winiger had. Thank you for bringing up this question. I want to address Gary's concerns here: 1) Device allocation: It is to meet the Solaris object reuse, access and audit requirements. Referencing "Controlling Access to Devices" in "System Administration Guide: Security Services"[1], I think sysadmin can easily put a scanner under the control of device allocation subsystem. If device allocation is desirable, the sysadmin or similar role can enable BSM by bsmconv(1M). Then the sysadmin can put the scanner's device special file in device_map and device_allocate(4), and provide a device-clean script. As Gary had pointed out in the LSARC case, a clean script is sufficient. In my opinion, the clean-script is up to the sysadmin. The ugen(7D) (sane backends access devices trough ugen interface) driver will not cache any data upon close, thus is not necessary to be cleaned. The clean-script may be just a script to print a message to remind user to take away his paper. If ARC think the project is responsible for clean-script, I will provide one. Device allocation can meet the requirements of object reuse, access and audit. 2) HAL If I understand it correctly, I think Gary mentioned HAL in the LSARC because he wanted HAL to support Object Reuse and Audit.I checked the latest stable sane code[2] and don't find any place that SANE uses HAL utility. SANE merely relies on file owner/group/permissions of /dev special files for access control. I think current Solaris audit mechanism has done audit for it: A system call, like open(2), will be recorded. If BSM is enabled, the device allocation subsystem may record more events. SANE does not depend on HAL for device access control. > Therefore, I am not sure that this case will be non-controversial > or appropriate for FastTrack. At any rate, effort should be made For LSARC/2007/018, I don't think it's derailed. From the case's log, I read the following, What Darren meant is that, "If this case is proposing running saned as root then I'm derailing it", in fact, the Project team gave up supporting scanner over the network at last. So Darren agree that there's no need to derail the case. I want to go another case because I will port libsane and sane, which are selected and categorized by Indiana. Xsane is out of the scope for this project. Thanks, Lei Chen [1] http://docs.sun.com/app/docs/doc/816-4557 [2]http://www.sane-project.org/source.html > to make sure that the issues that were raised in the previous ARC > case are addressed. > > Brian > > >> I am sponsoring this fast-track for Raymond Chen. >> Requested release binding is minor, and the timer is set to >> 03/11/2008. >> >> Regards, >> T.Paul Lee >> >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Integrate libsane and sane into Solaris >> 1.2. Name of Document Author/Supplier: >> Author: Raymond Chen >> 1.3 Date of This Document: >> 04 March, 2008 >> 4. Technical Description >> Summary >> This project integrates libsane and sane into Solaris. >> This project requests a minor binding. >> >> 4.1 Details >> >> SANE is an application programming interface (API) that provides >> standardized access to any raster image scanner hardware. The >> standardized interface makes it possible to write just one >> driver for each scanner device instead of one driver for each >> scanner and application. >> >> SANE is clearly separated into applications(frontends) and scanner >> drivers(backends). A SANE backend provides an interface with the >> hardware and describes a number of options which drive each scanner. >> sane, in this proposal, refers to applications that >> are delivered by SANE community, http://www.sane-project.org/. >> >> "sane-backends" package of FOSS project SANE contains backends, >> documentation, networking support and the command line frontend >> "scanimage". >> >> In this project, the following components will be ported and >> integrated into Solaris: >> >> 1)sane-backends >> sane-backends contain drivers for popular scanners on the >> market. This project proposes to only support local USB >> scanners. >> As an effort to enrich desktop applications for Indiana, >> SANE network feature is not considered essential and hence >> out of scope for this project. A future case may support >> this functionality. >> >> 2)libsane >> Standard SANE APIs are provided by libsane. Different >> frontends are developed on the base of such set of API. >> >> 3)sane documentation >> User manuals. >> >> 4)scanimage >> scanimage is a command-line interface to control image >> acquisition devices. It is one of the SANE frontends. >> >> 5)xscanimage >> xscanimage provides a graphical user interface to control >> an image acquisition device such as scanner. It allows >> previewing and scanning individual images. >> >> SANE depends on the scanner's device special file for access >> control. >> For USB interface scanners, by default only users on console or >> superuser have permission to access the devnode, which is controlled >> by logindevperm(4). It is also possible to restrict access to a >> scanner using Solaris device allocation subsystem. Sysadmin can >> enable >> BSM and put scanner device special file (exported by ugen(7D)) in >> device_map and device_allocate(4), so that the scanner is >> allocatable >> and then can be used by only one qualified user at a time. >> >> >> 4.2 Interface description >> >> All interfaces in sane.h and saneopts.h are exported as Volatile. >> >> Exported interfaces >> ------------------- >> SUNWsane Uncommitted SANE frontends >> SUNWsane-backends Uncommitted SANE backends -- >> library and drivers >> /usr/include/sane/sane.h Volatile SANE API header file >> /usr/include/sane/saneopts.h Volatile SANE options header file >> /usr/lib/libsane.so.1.0.19 Volatile SANE library >> /usr/lib/sane/* Volatile SANE backends >> /etc/sane.d/dll.conf Volatile Contain backend names >> /etc/sane.d/*.conf Volatile Each backend has a .conf >> >> /usr/bin/scanimage Volatile SANE CLI frontend >> /usr/bin/xscanimage Volatile SANE GUI frontend >> /usr/bin/sane-config Volatile Utility to get information >> about installed libsane >> /usr/bin/sane-find-scanner Volatile Utility to find scanners >> >> /usr/share/man/man1/scanimage.1 Volatile manual >> /usr/share/man/man1/xscanimage.1 Volatile manual >> /usr/share/man/man1/sane-find-scanner.1 Volatile manual >> /usr/share/man/man1/sane-config.1 Volatile manual >> /usr/share/man/man7/sane.7 Volatile manual >> /usr/share/man/man5/sane-*.5 Volatile Sane backends manual >> >> --------------- SANE C API ---------------------------------------- >> sane_init Volatile Initialize the backend >> sane_exit Volatile Terminate use of a backend >> sane_get_devices Volatile Query the list of devices >> sane_open Volatile Establish association with a >> particular device >> sane_close Volatile Terminates the above association >> sane_get_option_descriptor Volatile Access option descriptors >> sane_control_option Volatile Set/query the current value of >> option number sane_get_parameters >> Volatile Obtain the current scan parameters >> sane_start Volatile Initiates acquisition of an image >> sane_read Volatile Read image data from the device >> sane_cancel Volatile Cancel the pending operation >> sane_set_io_mode Volatile Set the I/O mode >> sane_get_select_fd Volatile Obtain file-descriptor from handle >> sane_strstatus Volatile Translate SANE status code into >> printable string >> Imported Interfaces >> -------------------- >> libusb Volatile User-space USB device management >> library >> libjpeg Uncommitted JPEG image compression and >> decompression >> libtiff Uncommitted Reading and writing TIFF files >> GTK+ Volatile GNOME Desktop Library >> GDK Volatile GNOME Desktop Library >> >> >> 5. References >> [1] http://www.sane-project.org/ >> [2] LSARC/2006/734 GNOME 2.16 >> [3] LSARC 2003/085 libtiff, libjpeg and libpng. >> [4] PSARC 2003/721 libusb: user level usb library >> [5] LSARC 2007/018 Sane-backends and Xsane >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> sfw >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > --Boundary_(ID_WPfo9HvZeIT4ZFo2v3/yDQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Brian Cameron wrote:

Note that Sane and libsane was previously ARC'ed via LSARC

  http://sac.eng.sun.com/arc/LSARC/2007/018/

This case was derailed due to some concerns that Gary Winiger had.
Thank you for bringing up this question. I want to address Gary's concerns here:

1) Device allocation:

     It is to meet the Solaris object reuse, access and audit requirements. Referencing  "Controlling Access to Devices" in "System Administration Guide: Security Services"[1], I think sysadmin can easily put a scanner under the control of device allocation subsystem. If device allocation is desirable, the sysadmin or similar role can enable BSM by bsmconv(1M). Then the sysadmin can put the scanner's device special file in device_map and device_allocate(4), and provide a device-clean script. As Gary had pointed out in the LSARC case, a clean script is sufficient. In my opinion, the clean-script is up to the sysadmin. The ugen(7D) (sane backends access devices trough ugen interface) driver will not cache any data upon close, thus is not necessary to be cleaned. The clean-script may be just a script to print a message to remind user to take away his paper. If ARC think the project is responsible for clean-script, I will provide one.

     Device allocation can meet the requirements of object reuse, access and audit.

    2) HAL
     If I understand it correctly, I think Gary mentioned HAL in the LSARC because he wanted HAL to support Object Reuse and Audit.I checked the latest stable sane code[2] and don't find any place that SANE uses HAL utility. SANE merely relies on file owner/group/permissions of /dev special files for access control. I think current Solaris audit mechanism has done audit for it: A system call, like open(2), will be recorded. If BSM is enabled, the device allocation subsystem may record more events.
    SANE does not depend on HAL for device access control.

Therefore, I am not sure that this case will be non-controversial
or appropriate for FastTrack.  At any rate, effort should be made

For LSARC/2007/018, I don't think it's derailed. From the case's log, I read the following, 
What Darren meant is that, "If this case is proposing running saned as
root then I'm derailing it", in fact, the Project team gave up
supporting scanner over the network at last. So Darren agree that
there's no need to derail the case.
I want to go another case because I will port libsane and sane, which are selected and categorized by Indiana. Xsane is out of the scope for this project.

Thanks,
Lei Chen

[1] http://docs.sun.com/app/docs/doc/816-4557
[2]http://www.sane-project.org/source.html

to make sure that the issues that were raised in the previous ARC
case are addressed.

Brian


I am sponsoring this fast-track for Raymond Chen.
Requested release binding is minor, and the timer is set to
03/11/2008.

Regards,
T.Paul Lee


Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
     Integrate libsane and sane into Solaris
    1.2. Name of Document Author/Supplier:
     Author:  Raymond Chen
    1.3  Date of This Document:
    04 March, 2008
4. Technical Description
Summary
    This project integrates libsane and sane into Solaris.
    This project requests a minor binding.
    
4.1 Details
    
    SANE is an application programming interface (API) that provides
    standardized access to any raster image scanner hardware. The
    standardized interface  makes  it possible to write just one
    driver for each scanner device instead of one driver for each
    scanner and application.
    
    SANE is clearly separated into applications(frontends) and scanner
    drivers(backends). A SANE backend provides an interface with the
    hardware and describes a number of options which drive each scanner.
    sane, in this proposal, refers to applications that
    are delivered by SANE community, http://www.sane-project.org/.

    "sane-backends" package of FOSS project SANE contains backends,
    documentation, networking support and the command line frontend
    "scanimage".

    In this project, the following components will be ported and
    integrated into Solaris:

        1)sane-backends
            sane-backends contain drivers for popular scanners on the
        market. This project proposes to only support local USB
        scanners.
        As an effort to enrich desktop applications for Indiana,
        SANE network feature is not considered essential and hence
        out of scope for this project. A future case may support
        this functionality.

        2)libsane
            Standard SANE APIs are provided by libsane. Different
        frontends are developed on the base of such set of API.

        3)sane documentation
            User manuals.

        4)scanimage
            scanimage is a command-line interface to control image
        acquisition devices. It is one of the SANE frontends.

        5)xscanimage
            xscanimage provides a graphical user interface to control
        an image acquisition device such as scanner. It allows
        previewing and scanning individual images.
    
    SANE depends on the scanner's device special file for access control.
    For USB interface scanners, by default only users on console or
    superuser have permission to access the devnode, which is controlled
    by logindevperm(4). It is also possible to restrict access to a
    scanner using Solaris device allocation subsystem. Sysadmin can enable
    BSM and put scanner device special file (exported by ugen(7D)) in
    device_map and device_allocate(4), so that the scanner is allocatable
    and then can be used by only one qualified user at a time.

 
4.2 Interface description

    All interfaces in sane.h and saneopts.h are exported as Volatile.

    Exported interfaces
    -------------------
    SUNWsane            Uncommitted    SANE frontends
    SUNWsane-backends        Uncommitted    SANE backends --
                            library and drivers
    /usr/include/sane/sane.h    Volatile    SANE API header file
    /usr/include/sane/saneopts.h    Volatile SANE options header file
    /usr/lib/libsane.so.1.0.19    Volatile    SANE library
    /usr/lib/sane/*        Volatile    SANE backends
    /etc/sane.d/dll.conf    Volatile    Contain backend names
    /etc/sane.d/*.conf        Volatile    Each backend has a .conf

    /usr/bin/scanimage        Volatile    SANE CLI frontend
    /usr/bin/xscanimage        Volatile    SANE GUI frontend
    /usr/bin/sane-config    Volatile    Utility to get information
                            about installed libsane
    /usr/bin/sane-find-scanner    Volatile    Utility to find scanners

    /usr/share/man/man1/scanimage.1    Volatile    manual
    /usr/share/man/man1/xscanimage.1    Volatile    manual
    /usr/share/man/man1/sane-find-scanner.1    Volatile    manual
    /usr/share/man/man1/sane-config.1    Volatile    manual
    /usr/share/man/man7/sane.7    Volatile    manual
    /usr/share/man/man5/sane-*.5    Volatile    Sane backends manual

    --------------- SANE C API ----------------------------------------
    sane_init        Volatile    Initialize the backend
    sane_exit        Volatile    Terminate use of a backend
    sane_get_devices    Volatile    Query the list of devices
    sane_open        Volatile    Establish association with a
                        particular device
    sane_close        Volatile    Terminates the above association     sane_get_option_descriptor    Volatile    Access option descriptors
    sane_control_option    Volatile    Set/query the current value of
                        option number     sane_get_parameters    Volatile    Obtain the current scan parameters
    sane_start        Volatile    Initiates acquisition of an image
    sane_read        Volatile    Read image data from the device
    sane_cancel        Volatile    Cancel the pending operation
    sane_set_io_mode    Volatile    Set the I/O mode
    sane_get_select_fd    Volatile    Obtain file-descriptor from handle
    sane_strstatus    Volatile    Translate SANE status code into
                        printable string
    Imported Interfaces
    --------------------
    libusb        Volatile    User-space USB device management
                        library
    libjpeg        Uncommitted    JPEG image compression and
                        decompression
    libtiff        Uncommitted     Reading and writing TIFF files
    GTK+        Volatile        GNOME Desktop Library      GDK            Volatile        GNOME Desktop Library


5. References
    [1] http://www.sane-project.org/
    [2] LSARC/2006/734 GNOME 2.16
    [3] LSARC 2003/085 libtiff, libjpeg and libpng.
    [4] PSARC 2003/721 libusb: user level usb library
    [5] LSARC 2007/018 Sane-backends and Xsane

6. Resources and Schedule
    6.4. Steering Committee requested information
       6.4.1. Consolidation C-team Name:
        sfw
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org


--Boundary_(ID_WPfo9HvZeIT4ZFo2v3/yDQ)-- From Raymond.Chen@sun.com Tue Mar 4 18:00:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2520DRr006070 for ; Tue, 4 Mar 2008 18:00:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m25206iK026119 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 02:00:12 GMT 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 <0JX80062DIWA3T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 18:00:10 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX8003NYIW8JZ20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 18:00:09 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2520Doc025236 for ; Wed, 05 Mar 2008 02:00:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JX800301IULI900@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 10:00:08 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX8006EOIW2KKKH@mail-apac.sun.com>; Wed, 05 Mar 2008 10:00:07 +0800 (SGT) Date: Wed, 05 Mar 2008 10:07:09 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CD9B13.3060007@Sun.COM> Sender: Raymond.Chen@sun.com To: Norm Jacobs Cc: Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <47CE004D.5080207@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Content-Length: 747 Status: RO X-Status: $$$$ X-UID: 0000000008 Norm Jacobs wrote: > Tzongyu Paul Lee wrote >> 4.2 Interface description >> >> All interfaces in sane.h and saneopts.h are exported as Volatile. >> >> Exported interfaces >> ------------------- >> /usr/lib/libsane.so.1.0.19 Volatile SANE library >> > As merely a lurker with some interest in integrating software that > uses libsane... > Are you contemplating consumers outside of this project? I will update the proposal to promote the stability level. > Will there be any 64-bit support? No, because libusb, one of the dependent library of libsane, is lack of 64 bit version. Please file a RFE in solaris/library/libusb and mention libsane if you have strong requirements. Thanks, Lei Chen > > -Norm From jyri@buye.red.iplanet.com Tue Mar 4 18:20:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m252KXDt006712 for ; Tue, 4 Mar 2008 18:20:34 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m252KEi1018402; Wed, 5 Mar 2008 10:20:28 +0800 (SGT) 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 <0JX800A01JTZ9N00@nwk-avmta-2.sfbay.sun.com>; Tue, 04 Mar 2008 18:20:23 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX800967JTZK050@nwk-avmta-2.sfbay.sun.com>; Tue, 04 Mar 2008 18:20:23 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m252KMc7007303; Tue, 04 Mar 2008 18:20:22 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m252KM2X007302; Tue, 04 Mar 2008 18:20:22 -0800 (PST) Date: Tue, 04 Mar 2008 18:20:22 -0800 From: Jyri Virkki Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <18381.17243.561462.575454@gargle.gargle.HOWL> To: James Carlson Cc: Lei Chen , Darren Kenny , Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <20080305022022.GF5817@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> User-Agent: Mutt/1.5.11 Content-Length: 773 Status: RO X-Status: $$$$ X-UID: 0000000009 James Carlson wrote: > > Lei Chen writes: > > Per my understanding of interface stability level, use of Uncommitted > > and Volatile interfaces has not much difference[2]. > > They're quite different. "Uncommitted" means that we don't plan to > make incompatible changes in a patch, but may do so on Minor release > boundaries (such as Solaris 10 -> Solaris 11). "Volatile" means that > we may make incompatible changes at any time, including in patches. At some point there's going to have to be either a new intermediate level or some different interpretation, given that neither of these two we have today applies sanely (ha ha) to the vast majority of these open source projects being integrated. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From scott.rotondo@sun.com Tue Mar 4 18:41:26 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m252fPqC007869 for ; Tue, 4 Mar 2008 18:41:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m252fNZO063507; Tue, 4 Mar 2008 19:41:24 -0700 (MST) 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 <0JX800B0BKSZ8V00@nwk-avmta-2.sfbay.sun.com>; Tue, 04 Mar 2008 18:41:23 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX8009ZHKSZK0B0@nwk-avmta-2.sfbay.sun.com>; Tue, 04 Mar 2008 18:41:23 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m252fMHV725051; Tue, 04 Mar 2008 18:41:23 -0800 (PST) Date: Tue, 04 Mar 2008 18:41:22 -0800 From: Scott Rotondo Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CE004D.5080207@sun.com> To: Lei Chen Cc: PSARC-ext@sun.com Message-id: <47CE0852.2050805@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Content-Length: 577 Status: RO X-Status: $$$$ X-UID: 0000000010 Lei Chen wrote: > Norm Jacobs wrote: >> Are you contemplating consumers outside of this project? > I will update the proposal to promote the stability level. > >> Will there be any 64-bit support? > No, because libusb, one of the dependent library of libsane, is lack of > 64 bit version. Please file a RFE in solaris/library/libusb and mention > libsane if you have strong requirements. This is probably answered in another ARC case, but is there any good reason we don't have a 64-bit version of libusb? Shouldn't that be a requirement for all libraries? Scott From Raymond.Chen@sun.com Tue Mar 4 19:01:23 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2531McB008914 for ; Tue, 4 Mar 2008 19:01:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2531C7j003597 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 11:01:22 +0800 (SGT) 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 <0JX800C0BLQ9EW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 19:01:21 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX800C7XLQ7D400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Mar 2008 19:01:20 -0800 (PST) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2531OHY029970 for ; Wed, 05 Mar 2008 03:01:24 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JX800I01L93WL00@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 11:01:19 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX8004WZLQ6ART0@mail-apac.sun.com>; Wed, 05 Mar 2008 11:01:19 +0800 (SGT) Date: Wed, 05 Mar 2008 11:08:25 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CE0852.2050805@sun.com> Sender: Raymond.Chen@sun.com To: Scott Rotondo Cc: PSARC-ext@sun.com Message-id: <47CE0EA9.7050001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> <47CE0852.2050805@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Content-Length: 864 Status: RO X-Status: $$$$ X-UID: 0000000011 Scott Rotondo wrote: > Lei Chen wrote: >> Norm Jacobs wrote: >>> Are you contemplating consumers outside of this project? >> I will update the proposal to promote the stability level. >> >>> Will there be any 64-bit support? >> No, because libusb, one of the dependent library of libsane, is lack >> of 64 bit version. Please file a RFE in solaris/library/libusb and >> mention libsane if you have strong requirements. > > This is probably answered in another ARC case, but is there any good > reason we don't have a 64-bit version of libusb? I checked the PSARC case log of libusb and didn't find any discussion about 64-bit version. I don't have much background knowledge of this issue either, sorry. > > > Shouldn't that be a requirement for all libraries? Could you please send me a pointer for such requirements? Thanks, Lei Chen > > Scott From Raymond.Chen@sun.com Wed Mar 5 00:17:29 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m258HSgK017631 for ; Wed, 5 Mar 2008 00:17:28 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m258HRWJ003728 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 00:17:28 -0800 (PST) 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 <0JX90051L0D30N00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 00:17:27 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX9003020D09T10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 00:17:25 -0800 (PST) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m258HeNC015879 for ; Wed, 05 Mar 2008 08:17:40 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JX90090107F7S00@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 16:17:23 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JX900IRV0CYP9J0@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 16:17:23 +0800 (SGT) Date: Wed, 05 Mar 2008 16:24:30 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <18381.17243.561462.575454@gargle.gargle.HOWL> Sender: Raymond.Chen@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <47CE58BE.9040801@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_nn0r7rqNocEybl/IC174mg)" X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Content-Length: 4154 Status: RO X-Status: $$$$ X-UID: 0000000012 This is a multi-part message in MIME format. --Boundary_(ID_nn0r7rqNocEybl/IC174mg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi James, I think I'd better copy my reply to this alias, in order not to cause confusion of my expression in last email. Sorry for duplication. Thanks, Lei Chen James Carlson wrote: > Lei Chen writes: > >> Per my understanding of interface stability level, use of Uncommitted >> > --Boundary_(ID_nn0r7rqNocEybl/IC174mg) Content-type: message/rfc822; name="Integrate libsane and sane into Solaris [PSARC_2008_170 FastTrack timeout03_11_2008].eml" Date: Wed, 05 Mar 2008 09:23:33 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <18381.17243.561462.575454@gargle.gargle.HOWL> To: James Carlson Cc: Darren Kenny , Tzongyu Paul Lee Message-id: <47CDF615.1070909@sun.com> X-Envelope-from: Raymond.Chen@Sun.COM X-Envelope-to: PSARC-ext <@smarthost.sun.com:PSARC-ext@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) [to reduce traffic in psarc-ext, I remove it from the CC list] James Carlson wrote: > Lei Chen writes: > >> Per my understanding of interface stability level, use of Uncommitted >> and Volatile interfaces has not much difference[2]. >> > > They're quite different. "Uncommitted" means that we don't plan to > make incompatible changes in a patch, but may do so on Minor release > boundaries (such as Solaris 10 -> Solaris 11). "Volatile" means that > we may make incompatible changes at any time, including in patches. > Thank you for the explanation. I'm happy that's also my understanding of these two glossaries. Maybe my expression of "use" causes the confusion. By "use", I meant to say that if a user, like GIMP, wants to use libsane, it also has to sign a contract for Uncommitted interface, as for the Volatile interface. "The opinion allowing any project to import an Uncommitted interface must explain why it is acceptable, and a contract must be put into place allowing this use", cited from interface taxonomy[1]. Please correct me if I'm wrong. Since the SANE is from an open source community and not controlled by Sun, I will update the proposal to promote its stability to Uncommitted if other projects can easily import SANE. What's your opinions? Thanks, Lei Chen [1] http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ > Volatile is pretty close to useless for libraries. The only users of > such library would be consumers in the same consolidation (treating it > as Consolidation Private, which has the same break-at-any-time > semantics) and those that use an ARC contract to nail down the > interface (effectively treating it as higher than just Volatile). All > others would be excluded, on the grounds that you'd end up with > fragile software. > > The situation you describe with the new-release-in-development sounds > to me like at least Uncommitted and perhaps even Committed. If the > new release is incompatible, then we'll need to figure out a > transition in the future -- perhaps. But the strong force making this > less likely is that libsane already has consumers who likely aren't > going to be happy about retooling for incompatible changes. > Popularity is one good guard against that kind of breakage. > > >> Do you have >> information about Volatile interface usage limitation? >> > > I don't think there's much of a point to integrating libraries -- or > anything intended to be used by other programs rather than directly by > humans -- as Volatile. It just builds an attractive nuisance. > > There oughta be a law ... > > --Boundary_(ID_nn0r7rqNocEybl/IC174mg)-- From carlsonj@phorcys.east.sun.com Wed Mar 5 07:25:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25FPkcM028172 for ; Wed, 5 Mar 2008 07:25:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m25FPgg7052821; Wed, 5 Mar 2008 08:25:43 -0700 (MST) 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 <0JX900L09K6TWL00@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 08:25:41 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX900DA7K6TP150@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 08:25:41 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m25FPe7x006969; Wed, 05 Mar 2008 10:25:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m25FPeVe006966; Wed, 05 Mar 2008 10:25:40 -0500 (EST) Date: Wed, 05 Mar 2008 10:25:40 -0500 From: James Carlson Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <20080305022022.GF5817@sun.com> To: Jyri Virkki , Lei Chen Cc: Darren Kenny , Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <18382.47988.49216.590440@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> <47CE58BE.9040801@sun.com> <20080305022022.GF5817@sun.com> Content-Length: 4007 Status: RO X-Status: $$$$ X-UID: 0000000013 Jyri Virkki writes: > At some point there's going to have to be either a new intermediate > level or some different interpretation, given that neither of these > two we have today applies sanely (ha ha) to the vast majority of these > open source projects being integrated. An intermediate level *where*? Between Volatile and Uncommitted? I don't see how that helps. In fact, I think that'd make things dramatically worse than they are today. I'm beginning to believe that the only way out of this mess is to eliminate Volatile from the taxonomy, as a substantial majority of the uses of it seems to represent abuse. The underlying issue is that we're consistently misrepresenting our delivered product because of a persistent misunderstanding of the nature of open source itself and of open source development. I don't think that the ARC can fix this, but it ought to at least put a stop to it. The stability levels have nothing to do with "control" over the open source code itself, and I suspect that's at the core of the misunderstanding. They have everything to do with correctly representing what we *deliver*. Those upstream providers don't force new binaries onto our DVDs or web sites; we do that. We need to document what we're putting there -- or we just shouldn't be in that business. In fact, most open source projects I've dealt with are either keenly aware of the stability issues, or are quite stable and dormant, or are so hemmed in by their own popularity that they can't make incompatible changes even if they wanted to. Slapping them all with the pejorative "Volatile" label is wrong. It misrepresents what they deliver and creates havoc for consumers who will be forced by the ARC to prepare for changes that will simply never arrive. Are we just dumping bits over a wall or are we trying to build a system? Lei Chen writes: > I think I'd better copy my reply to this alias, in order not to > cause confusion of my expression in last email. Sorry for duplication. I already responded privately. A summary here. > Thank you for the explanation. I'm happy that's also my understanding of > these two glossaries. Maybe my expression of "use" causes the confusion. > By "use", I meant to say that if a user, like GIMP, wants to use > libsane, it also has to sign a contract for Uncommitted interface, as > for the Volatile interface. "The opinion allowing any project to import > an Uncommitted interface must explain why it is acceptable, and a > contract must be put into place allowing this use", cited from interface > taxonomy[1]. Please correct me if I'm wrong. With a plausible explanation of how changes are properly dealt with on a Minor release boundary, and how the builds themselves don't just start falling apart, I think I could be happy with a case that had a dependency on an Uncommitted interface. It depends entirely on context and the details of the situation. Uncommitted is *far* better than Volatile. It restricts chaos to the Minor release boundaries, which are much less frequent than the rate at which we ship patches. > Since the SANE is from an open source community and not controlled by > Sun, I will update the proposal to promote its stability to Uncommitted > if other projects can easily import SANE. What's your opinions? "Control" of the upstream source has nothing whatsoever to do with the problem. Using that as an excuse to force the advertised stability artificially low does a grave disservice to all who consume those interfaces. If that's really the best we can manage, then I'd rather see us give up on architectural review. I think it'd be preferable to do nothing than to turn the process into a farce. At least we won't be misleading anyone when we say nothing at all. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From alan.coopersmith@sun.com Wed Mar 5 07:56:52 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25Fuqtd029034 for ; Wed, 5 Mar 2008 07:56:52 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m25FuqWa010219 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 07:56:52 -0800 (PST) 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 <0JX90010DLMR2000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 07:56:51 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX900KSOLMPPP60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 07:56:50 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-16-206.SFBay.Sun.COM [129.150.16.206]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m25Fui1h026748; Wed, 05 Mar 2008 07:56:45 -0800 (PST) Date: Wed, 05 Mar 2008 07:56:37 -0800 From: Alan Coopersmith Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <18382.47988.49216.590440@gargle.gargle.HOWL> To: James Carlson Cc: Jyri Virkki , Lei Chen , Darren Kenny , Tzongyu Paul Lee , PSARC-ext@sun.com Message-id: <47CEC2B5.2080002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> <47CE58BE.9040801@sun.com> <20080305022022.GF5817@sun.com> <18382.47988.49216.590440@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Content-Length: 784 Status: RO X-Status: $$$$ X-UID: 0000000014 James Carlson wrote: > Uncommitted is *far* better than Volatile. It restricts chaos to the > Minor release boundaries, which are much less frequent than the rate > at which we ship patches. They're also much less frequent than the rate we ship releases these days, with things like SXDE & Indiana being released as snapshots of the under-development-minor-release branch, so that even Uncommitted interfaces in those releases are effectively Volatile until we finally decide to set the "minor release done" flag, committing to those Uncommitted interfaces for the lifetime of that branch, but free to break in the new development branch being started at that point. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From John.Plocher@sun.com Wed Mar 5 10:46:02 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25Ik1L8011272 for ; Wed, 5 Mar 2008 10:46:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m25Ijwnn022185 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 18:46:01 GMT 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 <0JX900729TGN3100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 10:45:59 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX90052STGL2360@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 10:45:57 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m25Ijv9g016152 for ; Wed, 05 Mar 2008 10:45:57 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX900D01SXPXS00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Mar 2008 10:45:57 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX9001NNTGDQR20@fe-sfbay-09.sun.com>; Wed, 05 Mar 2008 10:45:49 -0800 (PST) Date: Wed, 05 Mar 2008 10:45:48 -0800 From: John Plocher Subject: FOSS and Interface Taxonomy levels: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <18382.47988.49216.590440@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: James Carlson Cc: Jyri Virkki , Lei Chen , PSARC-ext@sun.com, Tzongyu Paul Lee , Darren Kenny Message-id: <47CEEA5C.7020606@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> <47CE58BE.9040801@sun.com> <20080305022022.GF5817@sun.com> <18382.47988.49216.590440@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Content-Length: 5121 Status: RO X-Status: $$$$ X-UID: 0000000015 James Carlson wrote: > Uncommitted is *far* better than Volatile. It restricts chaos to the > Minor release boundaries, which are much less frequent than the rate > at which we ship patches. The difference between Volatile and Uncommitted and Committed is in how the *project team* chooses to behave. Software development is, at its heart, a set of producer-consumer relationships. Someone produces the source code, another compiles it. Someone makes packages/tarballs out of the result and another uses them to construct a product... The difference between FOSS development and that "all-done-by-us" is simply that the role of the project team changes from being source code authors to being importers and integrators. As importers, the project team has to decide how often it will import new versions of the source code from its external supplier, what expectations to set for others and what glue and trim they need to come up with to make it fit into our product mix. The interface taxonomy provides some of the words we use in setting those expectations. Our son is studying Algebra in school this year; he might express this as Expectations = f(Behavior(supplier),Promises(project team)) Raymond is focusing on only one component - the supplier's behavior. Jim is focusing on the other. As usual, both of you are right :-) The project team is the final arbiter of /when/ change happens in our components - if they do nothing, then nothing changes. The team could put a version of libsane into the OS now, and decide to never ever put a newer version into the system. The result? libsane would be a very stable interface because the project team committed to never changing it. (it also would get extremely stale over time...) The other end of the spectrum is also "interesting". The project team could decide to integrate a new version of libsane each and every time the supplier dropped off a new one. What would we be able to say about the stability then? Not much, other than "you get whatever the supplier gives - good luck". This is where understanding the supplier's behavior is so important. If they are well behaved, the effective stability might still be stable; if not, it won't be. The middle ground is where we find most projects that we intend to reuse as part of our systems. There, the stability MUST be high enough for us to produce robust systems - if the foundation components aren't stable, the system won't be, either. This requires the project teams to buffer their supplier's behavior to keep it from negatively impacting our derived systems. Buffering implies that the project team's job is harder, and that it may cost the company more resources. As above, that cost is dependent on the actual behavior of the supplier combined with the promises made by the project team. It should be clear by now that there are some combinations of supplier behavior and project team promises that work better than others: Behavior Promises Effect on consumers -------- -------- ----------------------- stable stable low cost, high satisfaction evolving stable short term OK, long term not[1] chaotic stable high cost[2], low satisfaction[1] stable evolving low cost[3], high satisfaction evolving evolving low cost[3], high satisfaction chaotic evolving high cost[2][4], low satisfaction[1] stable chaotic high cost[4], low satisfaction[1] evolving chaotic high cost[4], low satisfaction[1] chaotic chaotic high cost[4], low satisfaction, low use What does this all mean? IMO: Don't misrepresent either the supplier or your own ability (don't promise more than you actually can deliver), If your supplier is chaotic, you must either get involved with the supplier and fix the chaos problem *or* don't bother putting that component into the foundation of our systems, and If you don't intend for the component to be REUSED BY OTHER CORE TEAMS, don't put it into the core components of the OS, where we have stricter requirements for avoiding incompatible changes. On the other hand, if it is intended for reuse, it really must be reusable in a low cost, low risk way. -John ____ [1] satisfaction among consumers will be low because they won't all agree on /which/ of the versions of the supplier's code they should use, thus guaranteeing the eventual uselessness of whatever version the project team chose. [2] high lifetime cost to the project team as they spend more and more resources sustaining their fork over time. [3] As long as the project team makes sure it has a way to roll over to a new, incompatible version, so it doesn't get left behind when its supplier evolves. This means choosing a consolidation that allows incompatible change to the interface taxonomy types that were chosen. It also may imply supporting multiple incompatible versions of the component or having some other transition plan in mind. [4] low cost to the project team, but O(n) to O(n^2) sustaining cost to "n" consumers and to distro producers as a whole From jek3@sun.com Wed Mar 5 12:12:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25KCcIX016325 for ; Wed, 5 Mar 2008 12:12:39 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m25KCWl1007605; Thu, 6 Mar 2008 04:12:32 +0800 (SGT) 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 <0JX900301XGVCC00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 12:12:31 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX9001YLXGVTQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 12:12:31 -0800 (PST) Received: from [129.150.13.155] (vpn-129-150-13-155.SFBay.Sun.COM [129.150.13.155]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m25KCUlA830474; Wed, 05 Mar 2008 12:12:30 -0800 (PST) Date: Wed, 05 Mar 2008 10:10:15 -1000 From: Joseph Kowalski Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <18382.47988.49216.590440@gargle.gargle.HOWL> To: James Carlson Cc: Jyri Virkki , Lei Chen , Darren Kenny , Tzongyu Paul Lee , psarc-ext@sun.com Message-id: <47CEFE27.1030106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD15B2.5080806@Sun.COM> <47CD2E82.3080805@sun.com> <18381.17243.561462.575454@gargle.gargle.HOWL> <47CE58BE.9040801@sun.com> <20080305022022.GF5817@sun.com> <18382.47988.49216.590440@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Content-Length: 3324 Status: RO X-Status: $$$$ X-UID: 0000000016 James Carlson wrote: > Jyri Virkki writes: > >> At some point there's going to have to be either a new intermediate >> level or some different interpretation, given that neither of these >> two we have today applies sanely (ha ha) to the vast majority of these >> open source projects being integrated. >> >> ... >> I don't see how that helps. In fact, I think that'd make things >> dramatically worse than they are today. I'm beginning to believe that >> the only way out of this mess is to eliminate Volatile from the >> taxonomy, as a substantial majority of the uses of it seems to >> represent abuse. >> >> The underlying issue is that we're consistently misrepresenting our >> delivered product because of a persistent misunderstanding of the >> nature of open source itself and of open source development. I don't >> think that the ARC can fix this, but it ought to at least put a stop >> to it. >> >> The stability levels have nothing to do with "control" over the open >> source code itself, and I suspect that's at the core of the >> misunderstanding. They have everything to do with correctly >> representing what we *deliver*. Those upstream providers don't force >> new binaries onto our DVDs or web sites; we do that. We need to >> document what we're putting there -- or we just shouldn't be in that >> business. >> >> In fact, most open source projects I've dealt with are either keenly >> aware of the stability issues, or are quite stable and dormant, or are >> so hemmed in by their own popularity that they can't make incompatible >> changes even if they wanted to. Slapping them all with the pejorative >> "Volatile" label is wrong. It misrepresents what they deliver and >> creates havoc for consumers who will be forced by the ARC to prepare >> for changes that will simply never arrive. >> >> Are we just dumping bits over a wall or are we trying to build a >> system? >> Warning (Will Robinson), hot button pressed (and yes, I know this is psarc-ext)! We *do* seem to want to just dump bits over the wall. The root cause is that we don't have a repository which can make it easy to grab bits of uncertain ancestry (but still quite useful). In a sane world, volatile interfaces would be the exception in "core" Solaris, and would be completely baned for libraries or utilities which encourage/support scripting. The core differentiator of Linux (generically) and Solaris is the stability expected by users. It seems that at least some distros have headed toward greater stability guarantees while Solaris seems to be headed the other way. I'm pretty sure that I'm not alone in this (previous "asides" have found their way into multiple cases). The question is, how do we address this issue. - One way would be to really stir up sfw-discuss (and friends). At least this would get some of the parties into an open discussion. - The only real way is to convince Sun management to spend its dollars more wisely, or at least order the projects. This seems to be a daunting task. This will only have an effect if the non-Sun contributors voice a view on this. So, speaking of "multiple cases", if anyone feels a need to respond, please alter the subject line so that this does not pollute the case mail file. - thanks, - jek3 From scott.rotondo@sun.com Wed Mar 5 15:39:20 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25NdKUg023434 for ; Wed, 5 Mar 2008 15:39:20 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m25NdA9O028569; Wed, 5 Mar 2008 15:39:19 -0800 (PST) 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 <0JXA00C1R71HXD00@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 16:39:17 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA00A7771F8J20@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 16:39:16 -0700 (MST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m25NdF4k867179; Wed, 05 Mar 2008 15:39:15 -0800 (PST) Date: Wed, 05 Mar 2008 15:39:15 -0800 From: Scott Rotondo Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CE0EA9.7050001@sun.com> To: Lei Chen Cc: PSARC-ext@sun.com Message-id: <47CF2F23.60700@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> <47CE0852.2050805@sun.com> <47CE0EA9.7050001@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Content-Length: 1223 Status: RO X-Status: $$$$ X-UID: 0000000017 Lei Chen wrote: > Scott Rotondo wrote: >> Lei Chen wrote: >>> Norm Jacobs wrote: >>>> Will there be any 64-bit support? >>> No, because libusb, one of the dependent library of libsane, is lack >>> of 64 bit version. Please file a RFE in solaris/library/libusb and >>> mention libsane if you have strong requirements. >> >> This is probably answered in another ARC case, but is there any good >> reason we don't have a 64-bit version of libusb? > I checked the PSARC case log of libusb and didn't find any discussion > about 64-bit version. I don't have much background knowledge of this > issue either, sorry. > >> >> >> Shouldn't that be a requirement for all libraries? > Could you please send me a pointer for such requirements? No, I can't. I looked in some of the standard places and couldn't find any written policy about 64-bit support. But it seems self-evident that you would want both 32- and 64-bit programs to be able to link with your library. Then again, a quick examination of /usr/lib and /usr/sfw/lib turns up hundreds of libraries that are 32-bit only. I was quite surprised to see that. PSARC members: Is there a requirement around 64-bit support? Or is it completely optional? Scott From carlsonj@phorcys.east.sun.com Thu Mar 6 04:46:00 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26CjxC8014979 for ; Thu, 6 Mar 2008 04:45:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26CjnHM012346; Thu, 6 Mar 2008 20:45:56 +0800 (SGT) 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 <0JXB0090P7GJSM00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 04:45:55 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB005B87GG0B70@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 04:45:53 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26Cjq9u011854; Thu, 06 Mar 2008 07:45:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26Cjqal011851; Thu, 06 Mar 2008 07:45:52 -0500 (EST) Date: Thu, 06 Mar 2008 07:45:52 -0500 From: James Carlson Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CF2F23.60700@sun.com> To: Scott Rotondo Cc: Lei Chen , psarc-ext@sun.com Message-id: <18383.59264.574075.920478@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> <47CE0852.2050805@sun.com> <47CE0EA9.7050001@sun.com> <47CF2F23.60700@sun.com> Content-Length: 1542 Status: RO X-Status: $$$$ X-UID: 0000000018 Scott Rotondo writes: > PSARC members: Is there a requirement around 64-bit support? Or is it > completely optional? The closest to a "requirement" I know about is the 64-bit readiness question in the PSARC 20questions document. I'd say that the default should be that a Public library ought to support all of the compilation modes that are supported on the system. The rest would be exceptions: - If the library is Private, and the only applications using it are compiled 32-bit (as are most applications), then no 64-bit binary would be needed. - If there's something about the way the library is used that would make a 64-bit application implausible, then the 64-bit version might not be needed. There's no reason to build bits that "nobody" will use. - If the design of the library itself is just not compatible with an LP64 environment (lots of pointers casted to int or longs used as 32-bit quantities), and if the project team can't be pursuaded to fix these bugs (or the cost of fixing them is "very high"), then perhaps a 64-bit version would be unneeded, but I'd suggest filing a bug with the project integration. In this specific case, I could probably believe the second argument above, but if compiling as 64-bit is "not hard," I'd suggest doing it. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Thu Mar 6 11:54:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JsY45000893 for ; Thu, 6 Mar 2008 11:54:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JsWk2009662 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Mar 2008 19:54:33 GMT 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 <0JXB00A01RAWYU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:54:32 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB008GXRAWJPC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:54:32 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26JsWgu029806 for ; Thu, 06 Mar 2008 11:54:32 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00501R2GJN00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:54:28 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB0099IRAN8110@fe-sfbay-10.sun.com>; Thu, 06 Mar 2008 11:54:23 -0800 (PST) Date: Thu, 06 Mar 2008 11:52:08 -0800 From: "Garrett D'Amore" Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47CE0EA9.7050001@sun.com> Sender: Garrett.Damore@sun.com To: Lei Chen Cc: Scott Rotondo , PSARC-ext@sun.com Message-id: <47D04B68.2000004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> <47CE0852.2050805@sun.com> <47CE0EA9.7050001@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Content-Length: 1205 Status: RO X-Status: $$$$ X-UID: 0000000019 Lei Chen wrote: > Scott Rotondo wrote: >> Lei Chen wrote: >>> Norm Jacobs wrote: >>>> Are you contemplating consumers outside of this project? >>> I will update the proposal to promote the stability level. >>> >>>> Will there be any 64-bit support? >>> No, because libusb, one of the dependent library of libsane, is lack >>> of 64 bit version. Please file a RFE in solaris/library/libusb and >>> mention libsane if you have strong requirements. >> >> This is probably answered in another ARC case, but is there any good >> reason we don't have a 64-bit version of libusb? > I checked the PSARC case log of libusb and didn't find any discussion > about 64-bit version. I don't have much background knowledge of this > issue either, sorry. This is a tangent discussion, and yes, it should be addressed (but not necessarily here). All public APIs are supposed to have 64-bit support unless there is some *really* compelling reason why this is not needed. I don't believe that this is the case in the libusb. Lacking ARC approval to not ship 64-bit support, I think this project should file a bug against libusb for 64-bit support, and declare that bug as a dependency. -- Garrett From Nicolas.Williams@sun.com Thu Mar 6 12:31:41 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26KVess003932 for ; Thu, 6 Mar 2008 12:31:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26KVWHa025299; Thu, 6 Mar 2008 20:31:35 GMT 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 <0JXB00E19T0MNC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 12:31:34 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00BC8SYZNB40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 12:30:35 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m26KUZIj004649; Thu, 06 Mar 2008 14:30:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m26KUZBr004648; Thu, 06 Mar 2008 14:30:35 -0600 (CST) Date: Thu, 06 Mar 2008 14:30:35 -0600 From: Nicolas Williams Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D04B68.2000004@sun.com> To: "Garrett D'Amore" Cc: Lei Chen , PSARC-ext@sun.com, Scott Rotondo Mail-followup-to: Garrett D'Amore , Lei Chen , PSARC-ext@sun.com, Scott Rotondo Message-id: <20080306203035.GO986@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> <47CE0852.2050805@sun.com> <47CE0EA9.7050001@sun.com> <47D04B68.2000004@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Content-Length: 921 Status: RO X-Status: $$$$ X-UID: 0000000020 On Thu, Mar 06, 2008 at 11:52:08AM -0800, Garrett D'Amore wrote: > This is a tangent discussion, and yes, it should be addressed (but not > necessarily here). All public APIs are supposed to have 64-bit support > unless there is some *really* compelling reason why this is not needed. > I don't believe that this is the case in the libusb. > > Lacking ARC approval to not ship 64-bit support, I think this project > should file a bug against libusb for 64-bit support, and declare that > bug as a dependency. And explain that 64-bit support will be delivered separately. I think libusb is such a core library that it absolutely should have a 64-bit version. All core libraries, and most utility libraries should have 64-bit versions except where . I too was surprised not to find anything about this in any of the relevant SAC Best Practices documents. Nico -- From Raymond.Chen@sun.com Thu Mar 6 17:55:12 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m271tBSn016526 for ; Thu, 6 Mar 2008 17:55:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m271srE5006054 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 Mar 2008 01:55:10 GMT 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 <0JXC002097ZV0T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 17:55:07 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC000XO7ZUT890@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 17:55:07 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m271tDWJ008661 for ; Fri, 07 Mar 2008 01:55:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXC001017RM1O00@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 Mar 2008 09:55:05 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXC00B8T7ZOMGJQ@mail-apac.sun.com>; Fri, 07 Mar 2008 09:55:01 +0800 (SGT) Date: Fri, 07 Mar 2008 10:02:09 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <20080306203035.GO986@Sun.COM> Sender: Raymond.Chen@sun.com To: Nicolas.Williams@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Scott Rotondo Message-id: <47D0A221.8000400@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7xe0QKdIB3UvrcgU/ETUzA)" X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> <47CD9B13.3060007@Sun.COM> <47CE004D.5080207@sun.com> <47CE0852.2050805@sun.com> <47CE0EA9.7050001@sun.com> <47D04B68.2000004@sun.com> <20080306203035.GO986@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Content-Length: 3307 Status: RO X-Status: $$$$ X-UID: 0000000021 This is a multi-part message in MIME format. --Boundary_(ID_7xe0QKdIB3UvrcgU/ETUzA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi PSARC, As you suggested, I have filed CR6672460 to address your concerns about libsane 64-bit support. I will work on it and deliver both of libusb and libsane 64-bit version in another integration. In this case, I'd like to focus on 32-bit libsane support. Thanks, Lei Chen Nicolas Williams wrote: > On Thu, Mar 06, 2008 at 11:52:08AM -0800, Garrett D'Amore wrote: > >> This is a tangent discussion, and yes, it should be addressed (but not >> necessarily here). All public APIs are supposed to have 64-bit support >> unless there is some *really* compelling reason why this is not needed. >> I don't believe that this is the case in the libusb. >> >> Lacking ARC approval to not ship 64-bit support, I think this project >> should file a bug against libusb for 64-bit support, and declare that >> bug as a dependency. >> > > And explain that 64-bit support will be delivered separately. > > I think libusb is such a core library that it absolutely should have a > 64-bit version. All core libraries, and most utility libraries should > have 64-bit versions except where thread>. > > I too was surprised not to find anything about this in any of the > relevant SAC Best Practices documents. > > Nico > --Boundary_(ID_7xe0QKdIB3UvrcgU/ETUzA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi PSARC,
      As you suggested, I have filed CR6672460 to address your concerns about libsane 64-bit support. I will work on it and deliver both of libusb and libsane 64-bit version in another integration. In this case, I'd like to focus on 32-bit libsane support.

Thanks,
Lei Chen

Nicolas Williams wrote: 
On Thu, Mar 06, 2008 at 11:52:08AM -0800, Garrett D'Amore wrote:
  
This is a tangent discussion, and yes, it should be addressed (but not 
necessarily here).  All public APIs are supposed to have 64-bit support 
unless there is some *really* compelling reason why this is not needed.  
I don't believe that this is the case in the libusb.

Lacking ARC approval to not ship 64-bit support, I think this project 
should file a bug against libusb for 64-bit support, and declare that 
bug as a dependency.
    

And explain that 64-bit support will be delivered separately.

I think libusb is such a core library that it absolutely should have a
64-bit version.  All core libraries, and most utility libraries should
have 64-bit versions except where <see other posts on this topic in this
thread>.

I too was surprised not to find anything about this in any of the
relevant SAC Best Practices documents.

Nico

--Boundary_(ID_7xe0QKdIB3UvrcgU/ETUzA)-- From Tzongyu.Lee@sun.com Thu Mar 6 19:55:53 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m273tqcE019154 for ; Thu, 6 Mar 2008 19:55:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m273tgIW013959 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 Mar 2008 11:55:51 +0800 (SGT) 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 <0JXC00101DL0TP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 19:55:48 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC001UPDKZNM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 19:55:47 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m273trQv017428 for ; Fri, 07 Mar 2008 03:55:53 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXC00G01DKFTU00@mail-apac.sun.com> (original mail from Tzongyu.Lee@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 Mar 2008 11:55:46 +0800 (SGT) Received: from [129.158.218.85] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXC006IMDKXKK4P@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 Mar 2008 11:55:46 +0800 (SGT) Date: Fri, 07 Mar 2008 11:55:02 +0800 From: Tzongyu Paul Lee Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803040857.m248vIkW006324@sac.sfbay.sun.com> Sender: Tzongyu.Lee@sun.com To: PSARC-ext@sun.com Reply-to: Tzongyu.Lee@sun.com Message-id: <47D0BC96.3030605@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_KIoN0aQMFw0np+LXE2hTfQ)" X-PMX-Version: 5.2.0.264296 References: <200803040857.m248vIkW006324@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Content-Length: 12043 Status: RO X-Status: $$$$ X-UID: 0000000022 This is a multi-part message in MIME format. --Boundary_(ID_KIoN0aQMFw0np+LXE2hTfQ) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 8BIT [non-taxonomy discussion thread, interim update] I like to summarize the changes so far per comments and research on the latest data in previous cases: 1) libsane APIs and libsane.so upgraded to Committed. 2) SANE utilities upgraded to Uncommitted. 3) Remove dependency on Gnome, libtiff and libjpeg as they are Committed interfaces now according to the new interface taxonomy. It is unnecessary to explicitly list Committed interfaces in the proposal. 64-bit issue and the corresponding libusb CR will be added to the text in the final spec.txt. Best Regards, T.Paul --- Tzongyu Paul Lee дµÀ: > I am sponsoring this fast-track for Raymond Chen. > Requested release binding is minor, and the timer is set to > 03/11/2008. > > Regards, > T.Paul Lee > > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Integrate libsane and sane into Solaris > 1.2. Name of Document Author/Supplier: > Author: Raymond Chen > 1.3 Date of This Document: > 04 March, 2008 > 4. Technical Description > Summary > This project integrates libsane and sane into Solaris. > This project requests a minor binding. > > 4.1 Details > > SANE is an application programming interface (API) that provides > standardized access to any raster image scanner hardware. The > standardized interface makes it possible to write just one > driver for each scanner device instead of one driver for each > scanner and application. > > SANE is clearly separated into applications(frontends) and scanner > drivers(backends). A SANE backend provides an interface with the > hardware and describes a number of options which drive each scanner. > sane, in this proposal, refers to applications that > are delivered by SANE community, http://www.sane-project.org/. > > "sane-backends" package of FOSS project SANE contains backends, > documentation, networking support and the command line frontend > "scanimage". > > In this project, the following components will be ported and > integrated into Solaris: > > 1)sane-backends > sane-backends contain drivers for popular scanners on the > market. This project proposes to only support local USB > scanners. > As an effort to enrich desktop applications for Indiana, > SANE network feature is not considered essential and hence > out of scope for this project. A future case may support > this functionality. > > 2)libsane > Standard SANE APIs are provided by libsane. Different > frontends are developed on the base of such set of API. > > 3)sane documentation > User manuals. > > 4)scanimage > scanimage is a command-line interface to control image > acquisition devices. It is one of the SANE frontends. > > 5)xscanimage > xscanimage provides a graphical user interface to control > an image acquisition device such as scanner. It allows > previewing and scanning individual images. > > SANE depends on the scanner's device special file for access control. > For USB interface scanners, by default only users on console or > superuser have permission to access the devnode, which is controlled > by logindevperm(4). It is also possible to restrict access to a > scanner using Solaris device allocation subsystem. Sysadmin can enable > BSM and put scanner device special file (exported by ugen(7D)) in > device_map and device_allocate(4), so that the scanner is allocatable > and then can be used by only one qualified user at a time. > > > 4.2 Interface description > > All interfaces in sane.h and saneopts.h are exported as Volatile. > > Exported interfaces > ------------------- > SUNWsane Uncommitted SANE frontends > SUNWsane-backends Uncommitted SANE backends -- > library and drivers > /usr/include/sane/sane.h Volatile SANE API header file > /usr/include/sane/saneopts.h Volatile SANE options header file > /usr/lib/libsane.so.1.0.19 Volatile SANE library > /usr/lib/sane/* Volatile SANE backends > /etc/sane.d/dll.conf Volatile Contain backend names > /etc/sane.d/*.conf Volatile Each backend has a .conf > > /usr/bin/scanimage Volatile SANE CLI frontend > /usr/bin/xscanimage Volatile SANE GUI frontend > /usr/bin/sane-config Volatile Utility to get information > about installed libsane > /usr/bin/sane-find-scanner Volatile Utility to find scanners > > /usr/share/man/man1/scanimage.1 Volatile manual > /usr/share/man/man1/xscanimage.1 Volatile manual > /usr/share/man/man1/sane-find-scanner.1 Volatile manual > /usr/share/man/man1/sane-config.1 Volatile manual > /usr/share/man/man7/sane.7 Volatile manual > /usr/share/man/man5/sane-*.5 Volatile Sane backends manual > > --------------- SANE C API ---------------------------------------- > sane_init Volatile Initialize the backend > sane_exit Volatile Terminate use of a backend > sane_get_devices Volatile Query the list of devices > sane_open Volatile Establish association with a > particular device > sane_close Volatile Terminates the above association > sane_get_option_descriptor Volatile Access option descriptors > sane_control_option Volatile Set/query the current value of > option number > sane_get_parameters Volatile Obtain the current scan parameters > sane_start Volatile Initiates acquisition of an image > sane_read Volatile Read image data from the device > sane_cancel Volatile Cancel the pending operation > sane_set_io_mode Volatile Set the I/O mode > sane_get_select_fd Volatile Obtain file-descriptor from handle > sane_strstatus Volatile Translate SANE status code into > printable string > > Imported Interfaces > -------------------- > libusb Volatile User-space USB device management > library > libjpeg Uncommitted JPEG image compression and > decompression > libtiff Uncommitted Reading and writing TIFF files > GTK+ Volatile GNOME Desktop Library > GDK Volatile GNOME Desktop Library > > > 5. References > [1] http://www.sane-project.org/ > [2] LSARC/2006/734 GNOME 2.16 > [3] LSARC 2003/085 libtiff, libjpeg and libpng. > [4] PSARC 2003/721 libusb: user level usb library > [5] LSARC 2007/018 Sane-backends and Xsane > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > sfw > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > -- Tzongyu Paul Lee, Tzongyu.Lee@Sun.Com or Paul.Lee@Sun.COM BJS05 7225, x84343 http://blogs.sun.com/tpaullee/ Feel the Pulses of China http://tpaullee.blogspot.com/ --Boundary_(ID_KIoN0aQMFw0np+LXE2hTfQ) Content-type: text/plain; name=spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.txt Summary This project integrates libsane and sane into Solaris. This project requests a minor binding. 4.1 Details SANE is an application programming interface (API) that provides standardized access to any raster image scanner hardware. The standardized interface makes it possible to write just one driver for each scanner device instead of one driver for each scanner and application. SANE is clearly separated into applications(frontends) and scanner drivers(backends). A SANE backend provides an interface with the hardware and describes a number of options which drive each scanner. sane, in this proposal, refers to applications that are delivered by SANE community, http://www.sane-project.org/. "sane-backends" package of FOSS project SANE contains backends, documentation, networking support and the command line frontend "scanimage". In this project, the following components will be ported and integrated into Solaris: 1)sane-backends sane-backends contain drivers for popular scanners on the market. This project proposes to only support local USB scanners. As an effort to enrich desktop applications for Indiana, SANE network feature is not considered essential and hence out of scope for this project. A future case may support this functionality. 2)libsane Standard SANE APIs are provided by libsane. Different frontends are developed on the base of such set of API. 3)sane documentation User manuals. 4)scanimage scanimage is a command-line interface to control image acquisition devices. It is one of the SANE frontends. 5)xscanimage xscanimage provides a graphical user interface to control an image acquisition device such as scanner. It allows previewing and scanning individual images. SANE depends on the scanner's device special file for access control. For USB interface scanners, by default only users on console or superuser have permission to access the devnode, which is controlled by logindevperm(4). It is also possible to restrict access to a scanner using Solaris device allocation subsystem. Sysadmin can enable BSM and put scanner device special file (exported by ugen(7D)) in device_map and device_allocate(4), so that the scanner is allocatable and then can be used by only one qualified user at a time. 4.2 Interface description Exported interfaces ------------------- SUNWsane Uncommitted SANE frontends SUNWsane-backends Uncommitted SANE backends -- library and drivers /usr/include/sane/sane.h Committed SANE API header file /usr/include/sane/saneopts.h Committed SANE options header file /usr/lib/libsane.so Committed SANE library symbolic link /usr/lib/libsane.so.1 Uncommitted SANE library symbolic link /usr/lib/libsane.so.1.0.19 Uncommitted SANE library /usr/lib/sane Committed SANE backends location /usr/lib/sane/* Uncommitted SANE backends /etc/sane.d/dll.conf Committed Contain backend names /etc/sane.d/*.conf Uncommitted Each backend has a .conf /usr/bin/scanimage Uncommitted SANE CLI frontend /usr/bin/xscanimage Uncommitted SANE GUI frontend /usr/bin/sane-config Uncommitted Utility to get information about installed libsane /usr/bin/sane-find-scanner Uncommitted Utility to find scanners Documents delivered: /usr/share/man/man1/scanimage.1 /usr/share/man/man1/xscanimage.1 /usr/share/man/man1/sane-find-scanner.1 /usr/share/man/man1/sane-config.1 /usr/share/man/man7/sane.7 /usr/share/man/man5/sane-*.5 --------------- SANE C API ---------------------------------------- sane_init Committed Initialize the backend sane_exit Committed Terminate use of a backend sane_get_devices Committed Query the list of devices sane_open Committed Establish association with a particular device sane_close Committed Terminates the above association sane_get_option_descriptor Committed Access option descriptors sane_control_option Committed Set/query the current value of option number sane_get_parameters Committed Obtain the current scan parameters sane_start Committed Initiates acquisition of an image sane_read Committed Read image data from the device sane_cancel Committed Cancel the pending operation sane_set_io_mode Committed Set the I/O mode sane_get_select_fd Committed Obtain file-descriptor from handle sane_strstatus Committed Translate SANE status code into printable string Imported Interfaces -------------------- libusb Volatile User-space USB device management library 5. References [1] http://www.sane-project.org/ [2] PSARC 2003/721 libusb: user level usb library [3] LSARC 2007/018 Sane-backends and Xsane --Boundary_(ID_KIoN0aQMFw0np+LXE2hTfQ)-- From gww@eng.sun.com Tue Mar 11 20:33:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2C3Xf8q026661 for ; Tue, 11 Mar 2008 20:33:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2C3Xduj018527 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 03:33:40 GMT 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 <0JXL00F01LW3RO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 20:33:39 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL004E7LW2AA90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 20:33:39 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2C3Xbi4058773; Tue, 11 Mar 2008 20:33:37 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2C4XcNr020629; Tue, 11 Mar 2008 20:33:38 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2C4XcFJ020628; Tue, 11 Mar 2008 20:33:38 -0800 (PST) Date: Tue, 11 Mar 2008 20:33:38 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: Brian.Cameron@sun.com, Raymond.Chen@sun.com Cc: PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803120433.m2C4XcFJ020628@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2926 > > Note that Sane and libsane was previously ARC'ed via LSARC > > > > http://sac.eng.sun.com/arc/LSARC/2007/018/ Just what is the relationship between this case and the sited LSARC case? Why is the LSARC case listed as a reference? > 1) Device allocation: > > It is to meet the Solaris object reuse, access and audit > requirements. Referencing "Controlling Access to Devices" in "System > Administration Guide: Security Services"[1], I think sysadmin can easily > put a scanner under the control of device allocation subsystem. If > device allocation is desirable, the sysadmin or similar role can enable > BSM by bsmconv(1M). Then the sysadmin can put the scanner's device > special file in device_map and device_allocate(4), and provide a > device-clean script. As Gary had pointed out in the LSARC case, a clean > script is sufficient. In my opinion, the clean-script is up to the > sysadmin. The ugen(7D) (sane backends access devices trough ugen > interface) driver will not cache any data upon close, thus is not > necessary to be cleaned. The clean-script may be just a script to print > a message to remind user to take away his paper. If ARC think the > project is responsible for clean-script, I will provide one. > > Device allocation can meet the requirements of object reuse, access > and audit. If the project is going to claim that object reuse, access control and audit are met by device allocation, then the project needs to integrate all the needed components to support this case within the device allocation framework as stable components therein. Mimimally that is to ensure that the appropriate device_map and other files are created by the same interfaces on any system where this project is present. That would necessarially also include a "device clean script". > 2) HAL > If I understand it correctly, I think Gary mentioned HAL in the > LSARC because he wanted HAL to support Object Reuse and Audit.I checked Moving forward, HAL supports these for the objects that HAL manages. IIRC, these are generally removalbe media devices. If HAL were the manager for SANE (as it would seem useful to be, since it now manages cpufrequency, system suspend, monitor brightness -- and the kitchen sink), then it is necessary for the SANE project to correctly support object reuse, access control and audit within the HAL framework. > SANE does not depend on HAL for device access control. Why shouldn't it? Isn't it removable media? > > Therefore, I am not sure that this case will be non-controversial > > or appropriate for FastTrack. At any rate, effort should be made > > For LSARC/2007/018, I don't think it's derailed. From the case's log, I > read the following, I don't believe the LSARC case was derailed. It went into waiting need spec. From which it hasn't progressed. Thus my question of the relationship. Gary.. From gww@eng.sun.com Tue Mar 11 20:39:49 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2C3dnsa026713 for ; Tue, 11 Mar 2008 20:39:49 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2C3dm2p008041 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Mar 2008 20:39:49 -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 <0JXL00A0FM6CGX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 20:39:48 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL00JS3M6CZ6D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 20:39:48 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2C3dkPj061165; Tue, 11 Mar 2008 20:39:46 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2C4dm8B020678; Tue, 11 Mar 2008 20:39:48 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2C4dmAa020677; Tue, 11 Mar 2008 20:39:48 -0800 (PST) Date: Tue, 11 Mar 2008 20:39:48 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: Raymond.Chen@sun.com, scott.rotondo@sun.com Cc: PSARC-ext@sun.com Message-id: <200803120439.m2C4dmAa020677@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 739 > Then again, a quick examination of /usr/lib and /usr/sfw/lib turns up > hundreds of libraries that are 32-bit only. I was quite surprised to see > that. > > PSARC members: Is there a requirement around 64-bit support? Or is it > completely optional? Since Wyoming all libraries need to be 64 and 32 bit. Consolidations and base delivery directories. Not having both is analgous to not supporting Solaris ISA's. It's a no no. The only circumstance might be a HW device for which there is only one ISA implementation. This project must deliver all relevant ISA interfaces. If there's some dependency then that dependency needs to be resolved before the project delivers. It's fine to have a delivery dependency. Gary.. From Raymond.Chen@sun.com Tue Mar 11 22:40:04 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2C5e4cX029736 for ; Tue, 11 Mar 2008 22:40:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2C5e3sY004158 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Mar 2008 23:40:04 -0600 (MDT) 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 <0JXL00H01RQQVJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 23:40:02 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL009ODRQNE430@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 23:40:00 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2C5eHki001486 for ; Wed, 12 Mar 2008 05:40:17 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXL00J01RB22E00@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 13:39:57 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXL00BLXRQKMFSL@mail-apac.sun.com>; Wed, 12 Mar 2008 13:39:57 +0800 (SGT) Date: Wed, 12 Mar 2008 13:47:13 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803120433.m2C4XcFJ020628@marduk.eng.sun.com> Sender: Raymond.Chen@sun.com To: Gary Winiger Cc: Brian.Cameron@sun.com, PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D76E61.8060007@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dwpX53dAbNpjzmr1eK1Ujw)" X-PMX-Version: 5.4.1.325704 References: <200803120433.m2C4XcFJ020628@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Status: RO Content-Length: 12076 This is a multi-part message in MIME format. --Boundary_(ID_dwpX53dAbNpjzmr1eK1Ujw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: >>> Note that Sane and libsane was previously ARC'ed via LSARC >>> >>> http://sac.eng.sun.com/arc/LSARC/2007/018/ >>> > > Just what is the relationship between this case and the sited > LSARC case? Why is the LSARC case listed as a reference? > The LSARC is to integrate libsane and Xsane. This case is to cover libsane and sane-frontends. The overlap is libsane. > >> 1) Device allocation: >> >> It is to meet the Solaris object reuse, access and audit >> requirements. Referencing "Controlling Access to Devices" in "System >> Administration Guide: Security Services"[1], I think sysadmin can easily >> put a scanner under the control of device allocation subsystem. If >> device allocation is desirable, the sysadmin or similar role can enable >> BSM by bsmconv(1M). Then the sysadmin can put the scanner's device >> special file in device_map and device_allocate(4), and provide a >> device-clean script. As Gary had pointed out in the LSARC case, a clean >> script is sufficient. In my opinion, the clean-script is up to the >> sysadmin. The ugen(7D) (sane backends access devices trough ugen >> interface) driver will not cache any data upon close, thus is not >> necessary to be cleaned. The clean-script may be just a script to print >> a message to remind user to take away his paper. If ARC think the >> project is responsible for clean-script, I will provide one. >> >> Device allocation can meet the requirements of object reuse, access >> and audit. >> > > If the project is going to claim that object reuse, access control > and audit are met by device allocation, then the project needs > to integrate all the needed components to support this case within > the device allocation framework as stable components therein. > Mimimally that is to ensure that the appropriate device_map > and other files are created by the same interfaces on any system > where this project is present. That would necessarially also > include a "device clean script". > SANE depends on libusb to access scanners. On Solaris, all data communication of libusb is via ugen(7D) interface. The ugen exported device nodes look like this: # ls /dev/usb/4b8.11d/0/ cntrl0@ devstat@ if0in1stat@ if0in2stat@ if0out3stat@ cntrl0stat@ if0in1@ if0in2@ if0out3@ Every scanner has a vendor ID and a product ID. ugen use VID and PID to construct the device node tree, with the top level format:/dev/usb/./0/ . If I need to add scanner's device node to device_map, then I will have to add all the possible scanner's device node. There're more than 1440 models of scanners, with 760 supported by SANE at present[1](Possibly more will appear). More than 760 items will be added to the device_map like this: scanner:\ scanner:\ /dev/usb/4b8.11d/0/cntrl0/dev/usb/4b8.11d/0/cntrl0stat /dev/usb/4b8.11d/0/devstat I'm not sure if it's feasible. > >> 2) HAL >> If I understand it correctly, I think Gary mentioned HAL in the >> LSARC because he wanted HAL to support Object Reuse and Audit.I checked >> > > Moving forward, HAL supports these for the objects that HAL > manages. IIRC, these are generally removalbe media devices. > If HAL were the manager for SANE (as it would seem useful to be, > since it now manages cpufrequency, system suspend, monitor brightness > -- and the kitchen sink), then it is necessary for the SANE project > to correctly support object reuse, access control and audit within > the HAL framework. > If SANE had supported HAL, HAL would be ideal for the above requirements. But SANE merely relies on file owner/group/permissions of /dev special files for access control in its implementation. > >> SANE does not depend on HAL for device access control. >> > > Why shouldn't it? Isn't it removable media? > There was ever discussion of HAL and SANE in the community. But I don't see much progress. The sane developers prefer not depending on HAL. They want sane still work even without HAL running or installed. There's also some argument about "HAL support in SANE vs SANE support in HAL". So far, the sane project only provides a device information file(.fdi) to support HAL. The sane .fdi file is provided for applications who can leverage HAL for device information. If you think it's necessary, the .fdi file can be added to the delivery of this project. Thanks, Lei Chen [1] http://www.sane-project.org/sane-backends.html > >>> Therefore, I am not sure that this case will be non-controversial >>> or appropriate for FastTrack. At any rate, effort should be made >>> >> For LSARC/2007/018, I don't think it's derailed. From the case's log, I >> read the following, >> > > I don't believe the LSARC case was derailed. It went into > waiting need spec. From which it hasn't progressed. Thus > my question of the relationship. > > Gary.. > --Boundary_(ID_dwpX53dAbNpjzmr1eK1Ujw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: 
Note that Sane and libsane was previously ARC'ed via LSARC

  http://sac.eng.sun.com/arc/LSARC/2007/018/
      

	Just what is the relationship between this case and the sited
	LSARC case?   Why is the LSARC case listed as a reference?
The LSARC is to integrate libsane and Xsane. This case is to cover libsane and sane-frontends. The overlap is libsane.

  
1) Device allocation:

     It is to meet the Solaris object reuse, access and audit 
requirements. Referencing  "Controlling Access to Devices" in "System 
Administration Guide: Security Services"[1], I think sysadmin can easily 
put a scanner under the control of device allocation subsystem. If 
device allocation is desirable, the sysadmin or similar role can enable 
BSM by bsmconv(1M). Then the sysadmin can put the scanner's device 
special file in device_map and device_allocate(4), and provide a 
device-clean script. As Gary had pointed out in the LSARC case, a clean 
script is sufficient. In my opinion, the clean-script is up to the 
sysadmin. The ugen(7D) (sane backends access devices trough ugen 
interface) driver will not cache any data upon close, thus is not 
necessary to be cleaned. The clean-script may be just a script to print 
a message to remind user to take away his paper. If ARC think the 
project is responsible for clean-script, I will provide one.

     Device allocation can meet the requirements of object reuse, access 
and audit.
    

	If the project is going to claim that object reuse, access control
	and audit are met by device allocation, then the project needs
	to integrate all the needed components to support this case within
	the device allocation framework as stable components therein.
	Mimimally that is to ensure that the appropriate device_map
	and other files are created by the same interfaces on any system
	where this project is present.  That would necessarially also
	include a "device clean script".
SANE depends on libusb to access scanners. On Solaris, all data communication of libusb is via ugen(7D) interface. The ugen exported device nodes look like this:
# ls /dev/usb/4b8.11d/0/
cntrl0@       devstat@      if0in1stat@   if0in2stat@   if0out3stat@
cntrl0stat@   if0in1@       if0in2@       if0out3@

Every scanner has a vendor ID and a product ID. ugen use VID and PID to construct  the device node tree, with the top level format:/dev/usb/<vid>.<pid>/0/ . If I need to add scanner's device node to device_map, then I will have to add all the possible scanner's device node. There're more than 1440 models of scanners, with 760 supported by SANE at present[1](Possibly more will appear). More than 760 items will be added to the device_map like this:

scanner:\
        scanner:\
        /dev/usb/4b8.11d/0/cntrl0/dev/usb/4b8.11d/0/cntrl0stat  /dev/usb/4b8.11d/0/devstat

I'm not sure if it's feasible.

  
    2) HAL
     If I understand it correctly, I think Gary mentioned HAL in the 
LSARC because he wanted HAL to support Object Reuse and Audit.I checked 
    

	Moving forward, HAL supports these for the objects that HAL
	manages.  IIRC, these are generally removalbe media devices.
	If HAL were the manager for SANE (as it would seem useful to be,
	since it now manages cpufrequency, system suspend, monitor brightness
	-- and the kitchen sink), then it is necessary for the SANE project
	to correctly support object reuse, access control and audit within
	the HAL framework.
If SANE had supported HAL,  HAL would be ideal for the above requirements. But SANE merely relies on file owner/group/permissions of /dev special files for access control in its implementation.

  
    SANE does not depend on HAL for device access control.
    

	Why shouldn't it?  Isn't it removable media?
There was ever discussion of HAL and SANE in the community. But I don't see much progress. The sane developers prefer not depending on HAL. They want sane still work even without HAL running or installed. There's also some argument about "HAL support in SANE  vs SANE support in HAL". So far, the sane project only provides a device information file(.fdi) to support HAL.  The sane .fdi file is provided for applications who can leverage HAL for device information.

If you think it's necessary, the .fdi file can be added to the delivery of this project.

Thanks,
Lei Chen

[1] http://www.sane-project.org/sane-backends.html

  
Therefore, I am not sure that this case will be non-controversial
or appropriate for FastTrack.  At any rate, effort should be made
      
For LSARC/2007/018, I don't think it's derailed. From the case's log, I 
read the following,
    

	I don't believe the LSARC case was derailed.  It went into
	waiting need spec.  From which it hasn't progressed.  Thus
	my question of the relationship.

Gary..


--Boundary_(ID_dwpX53dAbNpjzmr1eK1Ujw)-- From Raymond.Chen@sun.com Wed Mar 12 03:33:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CAXtgC007116 for ; Wed, 12 Mar 2008 03:33:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CAXlIM023233 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 10:33:54 GMT 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 <0JXM00E055CHYU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 03:33:53 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM001PE5CGZJD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 03:33:53 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2CAYAhw027270 for ; Wed, 12 Mar 2008 10:34:10 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXM00B0151VPZ00@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 18:33:49 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXM00B9S5BVMFFM@mail-apac.sun.com>; Wed, 12 Mar 2008 18:33:32 +0800 (SGT) Date: Wed, 12 Mar 2008 18:40:47 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803120439.m2C4dmAa020677@marduk.eng.sun.com> Sender: Raymond.Chen@sun.com To: Gary Winiger Cc: Scott.Rotondo@sun.com, PSARC-ext@sun.com Message-id: <47D7B32F.404@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_w7Vw0KQuI+in7bBKWyCOsA)" X-PMX-Version: 5.4.1.325704 References: <200803120439.m2C4dmAa020677@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Status: RO Content-Length: 2521 This is a multi-part message in MIME format. --Boundary_(ID_w7Vw0KQuI+in7bBKWyCOsA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: >> Then again, a quick examination of /usr/lib and /usr/sfw/lib turns up >> hundreds of libraries that are 32-bit only. I was quite surprised to see >> that. >> >> PSARC members: Is there a requirement around 64-bit support? Or is it >> completely optional? >> > > Since Wyoming all libraries need to be 64 and 32 bit. Consolidations > and base delivery directories. Not having both is analgous to > not supporting Solaris ISA's. It's a no no. The only circumstance > might be a HW device for which there is only one ISA implementation. > > This project must deliver all relevant ISA interfaces. If there's > some dependency then that dependency needs to be resolved before > the project delivers. It's fine to have a delivery dependency. > OK. I'll do that. Thanks, Lei Chen > Gary.. > --Boundary_(ID_w7Vw0KQuI+in7bBKWyCOsA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: 
Then again, a quick examination of /usr/lib and /usr/sfw/lib turns up 
hundreds of libraries that are 32-bit only. I was quite surprised to see 
that.

PSARC members: Is there a requirement around 64-bit support? Or is it 
completely optional?
    

	Since Wyoming all libraries need to be 64 and 32 bit.  Consolidations
	and base delivery directories.  Not having both is analgous to
	not supporting Solaris ISA's.  It's a no no.  The only circumstance
	might be a HW device for which there is only one ISA implementation.

	This project must deliver all relevant ISA interfaces.  If there's
	some dependency then that dependency needs to be resolved before
	the project delivers.  It's fine to have a delivery dependency.
OK. I'll do that.

Thanks,
Lei Chen

Gary..

--Boundary_(ID_w7Vw0KQuI+in7bBKWyCOsA)-- From Darren.Moffat@sun.com Wed Mar 12 04:33:04 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CBX32j009078 for ; Wed, 12 Mar 2008 04:33:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CBWww8020627 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 11:33:03 GMT 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 <0JXM00K03831R400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 04:33:01 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00HE482XOID0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 04:33:00 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CBWvCD012823 for ; Wed, 12 Mar 2008 11:32:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXM00G017CXF600@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 11:32:57 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXM00DGR82UXG00@fe-emea-09.sun.com>; Wed, 12 Mar 2008 11:32:54 +0000 (GMT) Date: Wed, 12 Mar 2008 11:32:54 +0000 From: Darren J Moffat Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803120433.m2C4XcFJ020628@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Brian.Cameron@sun.com, Raymond.Chen@sun.com, PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D7BF66.5080008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803120433.m2C4XcFJ020628@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1451 Gary Winiger wrote: >>> Note that Sane and libsane was previously ARC'ed via LSARC >>> >>> http://sac.eng.sun.com/arc/LSARC/2007/018/ > > Just what is the relationship between this case and the sited > LSARC case? Why is the LSARC case listed as a reference? The LSARC case proposed delivering more. In particular it had a daemon that provided remote scanner access. This case is just the library. >> SANE does not depend on HAL for device access control. > > Why shouldn't it? Isn't it removable media? I don't understand why a scanner would be classed as removable media. Why is it that this case needs to do these things but integration of webcam support, pilot-xter, gphoto etc didn't ? The answer isn't because it was missed it is because they are just end user applications using libusb. This case is JUST an application library (libsane) that runs as the user. As such I don't see how it is any different to any other libusb consumer such as gphoto or gnome-pilot, pilot-xfer. The access control to the libusb provided devices that these libraries and end user programs use is done by the following /etc/logindevperm entry: /dev/console 0600 /dev/usb/[0-9a-f]+[.][0-9a-f]+/[0-9]+/* driver=scsa2usb,usb_mid,usbprn,ugen #libusb/ugen devices If you think that is wrong then the issue is with the whole architecture of libusb and the ugen driver not the architecture of this case. -- Darren J Moffat From Tzongyu.Lee@sun.com Wed Mar 12 08:36:39 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CFadFS016559 for ; Wed, 12 Mar 2008 08:36:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CFaOsm001935 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 08:36:38 -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 <0JXM00DCZJD0MN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 09:36:36 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM008VBJCNR670@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 09:36:25 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2CFaUF7028926 for ; Wed, 12 Mar 2008 15:36:30 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXM00F01JCL1S00@mail-apac.sun.com> (original mail from Tzongyu.Lee@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 23:36:21 +0800 (SGT) Received: from [129.158.148.47] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXM00BI7JCKMFVM@mail-apac.sun.com>; Wed, 12 Mar 2008 23:36:21 +0800 (SGT) Date: Wed, 12 Mar 2008 23:36:21 +0800 From: Tzongyu Paul Lee Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803120439.m2C4dmAa020677@marduk.eng.sun.com> Sender: Tzongyu.Lee@sun.com To: Gary Winiger Cc: Raymond.Chen@sun.com, Scott.Rotondo@sun.com, psarc-ext@sun.com Reply-to: Tzongyu.Lee@sun.com Message-id: <47D7F875.1080106@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_zrKIGOP4HvfdwaBryKm0Ug)" X-PMX-Version: 5.4.1.325704 References: <200803120439.m2C4dmAa020677@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 7383 This is a multi-part message in MIME format. --Boundary_(ID_zrKIGOP4HvfdwaBryKm0Ug) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT As promised in the interim update email and spec.txt, the final spec.txt is updated in the case directory now with references to libusb CR and the 64-bit delivery dependency. If absolute sequencing is required, the project team can deliver the CR fix first before the libsane/sane delivery. Here is the diff from the interim update. -------- -bash-3.00$ diff spec.txt /home/tl41329/ARC/cases/libsane.v4.psarc 73c73 < /usr/lib/libsane.so.1.0.19 Uncommitted SANE library --- > /usr/lib/libsane.so.1.0.19 Uncommitted SANE library[1] 116a117,120 > NOTE: > [1] Due to lack of 64 bit support of the dependent library - libusb, > this case will deliver 32-bit library first. libsane 64-bit support > will be delivered in another integration with CR6672460. 121a126 > [4] CR6672460 - libusb should provide 64-bit support Regards, Paul ------------ Gary Winiger wrote: >> Then again, a quick examination of /usr/lib and /usr/sfw/lib turns up >> hundreds of libraries that are 32-bit only. I was quite surprised to see >> that. >> >> PSARC members: Is there a requirement around 64-bit support? Or is it >> completely optional? >> > > Since Wyoming all libraries need to be 64 and 32 bit. Consolidations > and base delivery directories. Not having both is analgous to > not supporting Solaris ISA's. It's a no no. The only circumstance > might be a HW device for which there is only one ISA implementation. > > This project must deliver all relevant ISA interfaces. If there's > some dependency then that dependency needs to be resolved before > the project delivers. It's fine to have a delivery dependency. > > Gary.. > -- Tzongyu Paul Lee, Tzongyu.Lee@Sun.Com or Paul.Lee@Sun.COM BJS05 7225, x84343 http://blogs.sun.com/tpaullee/ Feel the Pulses of China http://tpaullee.blogspot.com/ --Boundary_(ID_zrKIGOP4HvfdwaBryKm0Ug) Content-type: text/plain; name=spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.txt Summary This project integrates libsane and sane into Solaris. This project requests a minor binding. 4.1 Details SANE is an application programming interface (API) that provides standardized access to any raster image scanner hardware. The standardized interface makes it possible to write just one driver for each scanner device instead of one driver for each scanner and application. SANE is clearly separated into applications(frontends) and scanner drivers(backends). A SANE backend provides an interface with the hardware and describes a number of options which drive each scanner. sane, in this proposal, refers to applications that are delivered by SANE community, http://www.sane-project.org/. "sane-backends" package of FOSS project SANE contains backends, documentation, networking support and the command line frontend "scanimage". In this project, the following components will be ported and integrated into Solaris: 1)sane-backends sane-backends contain drivers for popular scanners on the market. This project proposes to only support local USB scanners. As an effort to enrich desktop applications for Indiana, SANE network feature is not considered essential and hence out of scope for this project. A future case may support this functionality. 2)libsane Standard SANE APIs are provided by libsane. Different frontends are developed on the base of such set of API. 3)sane documentation User manuals. 4)scanimage scanimage is a command-line interface to control image acquisition devices. It is one of the SANE frontends. 5)xscanimage xscanimage provides a graphical user interface to control an image acquisition device such as scanner. It allows previewing and scanning individual images. SANE depends on the scanner's device special file for access control. For USB interface scanners, by default only users on console or superuser have permission to access the devnode, which is controlled by logindevperm(4). It is also possible to restrict access to a scanner using Solaris device allocation subsystem. Sysadmin can enable BSM and put scanner device special file (exported by ugen(7D)) in device_map and device_allocate(4), so that the scanner is allocatable and then can be used by only one qualified user at a time. 4.2 Interface description Exported interfaces ------------------- SUNWsane Uncommitted SANE frontends SUNWsane-backends Uncommitted SANE backends -- library and drivers /usr/include/sane/sane.h Committed SANE API header file /usr/include/sane/saneopts.h Committed SANE options header file /usr/lib/libsane.so Committed SANE library symbolic link /usr/lib/libsane.so.1 Uncommitted SANE library symbolic link /usr/lib/libsane.so.1.0.19 Uncommitted SANE library[1] /usr/lib/sane Committed SANE backends location /usr/lib/sane/* Uncommitted SANE backends /etc/sane.d/dll.conf Committed Contain backend names /etc/sane.d/*.conf Uncommitted Each backend has a .conf /usr/bin/scanimage Uncommitted SANE CLI frontend /usr/bin/xscanimage Uncommitted SANE GUI frontend /usr/bin/sane-config Uncommitted Utility to get information about installed libsane /usr/bin/sane-find-scanner Uncommitted Utility to find scanners Documents delivered: /usr/share/man/man1/scanimage.1 /usr/share/man/man1/xscanimage.1 /usr/share/man/man1/sane-find-scanner.1 /usr/share/man/man1/sane-config.1 /usr/share/man/man7/sane.7 /usr/share/man/man5/sane-*.5 --------------- SANE C API ---------------------------------------- sane_init Committed Initialize the backend sane_exit Committed Terminate use of a backend sane_get_devices Committed Query the list of devices sane_open Committed Establish association with a particular device sane_close Committed Terminates the above association sane_get_option_descriptor Committed Access option descriptors sane_control_option Committed Set/query the current value of option number sane_get_parameters Committed Obtain the current scan parameters sane_start Committed Initiates acquisition of an image sane_read Committed Read image data from the device sane_cancel Committed Cancel the pending operation sane_set_io_mode Committed Set the I/O mode sane_get_select_fd Committed Obtain file-descriptor from handle sane_strstatus Committed Translate SANE status code into printable string Imported Interfaces -------------------- libusb Volatile User-space USB device management library NOTE: [1] Due to lack of 64 bit support of the dependent library - libusb, this case will deliver 32-bit library first. libsane 64-bit support will be delivered in another integration with CR6672460. 5. References [1] http://www.sane-project.org/ [2] PSARC 2003/721 libusb: user level usb library [3] LSARC 2007/018 Sane-backends and Xsane [4] CR6672460 - libusb should provide 64-bit support --Boundary_(ID_zrKIGOP4HvfdwaBryKm0Ug)-- From gww@eng.sun.com Wed Mar 12 08:47:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CFlmJO016884 for ; Wed, 12 Mar 2008 08:47:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CFliRe016661 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 15:47:47 GMT 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 <0JXM00K05JVLOR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 08:47:45 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00DGMJVLHJ90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 08:47:45 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CFlhji032095; Wed, 12 Mar 2008 08:47:43 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2CGljTY021398; Wed, 12 Mar 2008 08:47:45 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2CGljJ0021397; Wed, 12 Mar 2008 08:47:45 -0800 (PST) Date: Wed, 12 Mar 2008 08:47:45 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, Tzongyu.Lee@sun.com Cc: Raymond.Chen@sun.com, Scott.Rotondo@sun.com, PSARC-ext@sun.com Message-id: <200803121647.m2CGljJ0021397@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 247 > and the 64-bit delivery dependency. If absolute sequencing is required, > the project > team can deliver the CR fix first before the libsane/sane delivery. Those a P/C team issues the architectural issue is to deliver for all ISAs. Gary.. From gww@eng.sun.com Wed Mar 12 10:00:27 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CH0RQq021032 for ; Wed, 12 Mar 2008 10:00:27 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CH0O1r003860 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 10:00:27 -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 <0JXM00H0BN8Q9N00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 10:00:26 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00G2XN8K58C0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 10:00:20 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CH0Hor032041; Wed, 12 Mar 2008 10:00:17 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2CI0KqF021504; Wed, 12 Mar 2008 10:00:20 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2CI0KJ8021503; Wed, 12 Mar 2008 10:00:20 -0800 (PST) Date: Wed, 12 Mar 2008 10:00:20 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: Brian.Cameron@sun.com, Raymond.Chen@sun.com, PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 851 > Gary Winiger wrote: > >>> Note that Sane and libsane was previously ARC'ed via LSARC > >>> > >>> http://sac.eng.sun.com/arc/LSARC/2007/018/ > > > > Just what is the relationship between this case and the sited > > LSARC case? Why is the LSARC case listed as a reference? > > The LSARC case proposed delivering more. In particular it had a daemon > that provided remote scanner access. This case is just the library. I'm looking for dependences here. In one hand we have a stalled case that seems to have overlap. > >> SANE does not depend on HAL for device access control. > > > > Why shouldn't it? Isn't it removable media? > > I don't understand why a scanner would be classed as removable media. Because you put removable stuff in it and remove the stuff when done. Solaris Object Reuse needs to be supported. Gary.. From Darren.Moffat@sun.com Wed Mar 12 10:27:04 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CHR4oC024254 for ; Wed, 12 Mar 2008 10:27:04 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CHR2v1013057 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 10:27:04 -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 <0JXM00617OH4AB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 10:27:04 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM0020GOH2O690@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 10:27:03 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CHR1iB021188 for ; Wed, 12 Mar 2008 17:27:01 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXM00I01NN05000@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 17:27:01 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXM00DWXOGLXG10@fe-emea-09.sun.com>; Wed, 12 Mar 2008 17:26:46 +0000 (GMT) Date: Wed, 12 Mar 2008 17:26:45 +0000 From: Darren J Moffat Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Brian.Cameron@sun.com, Raymond.Chen@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D81255.1020501@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1487 Gary Winiger wrote: >> Gary Winiger wrote: >>>>> Note that Sane and libsane was previously ARC'ed via LSARC >>>>> >>>>> http://sac.eng.sun.com/arc/LSARC/2007/018/ >>> Just what is the relationship between this case and the sited >>> LSARC case? Why is the LSARC case listed as a reference? >> The LSARC case proposed delivering more. In particular it had a daemon >> that provided remote scanner access. This case is just the library. > > I'm looking for dependences here. In one hand we have > a stalled case that seems to have overlap. > >>>> SANE does not depend on HAL for device access control. >>> Why shouldn't it? Isn't it removable media? >> I don't understand why a scanner would be classed as removable media. > > Because you put removable stuff in it and remove the stuff when > done. Solaris Object Reuse needs to be supported. Consider that if I grab the libsane source and compile and built all as a normal user; I need no privileges to access the scanner because logindevperm already gave me as the console user ownership of the device nodes. So best I can tell there is nothing this case, it just provides library, can do to change this. How is it different to pilot-xfer or gphoto or any of the other libusb consumers ? I just don't see what the issue is with this case. If there is an object reuse issue then the issue is with logindevperm giving out access to all the ugen provided devices as a user logs in. -- Darren J Moffat From Colin.Zou@sun.com Wed Mar 12 10:41:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CHfAb7024770 for ; Wed, 12 Mar 2008 10:41:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CHf3vo019764 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Mar 2008 11:41:09 -0600 (MDT) 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 <0JXM00L3DP4KTG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 11:41:08 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00JK1P4D9B20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Mar 2008 11:41:02 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2CHf8dm001204 for ; Wed, 12 Mar 2008 17:41:08 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXM00I01P06JJ00@mail-apac.sun.com> (original mail from Colin.Zou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Mar 2008 01:41:01 +0800 (SGT) Received: from [129.153.2.134] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXM00JQ6P4AC7G9@mail-apac.sun.com>; Thu, 13 Mar 2008 01:41:01 +0800 (SGT) Date: Wed, 12 Mar 2008 10:40:46 +0800 From: Colin Zou Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> Sender: Colin.Zou@sun.com To: Gary Winiger Cc: Darren.Moffat@sun.com, Brian.Cameron@sun.com, Raymond.Chen@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D742AE.7000406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 916 > >>>> SANE does not depend on HAL for device access control. >>>> >>> Why shouldn't it? Isn't it removable media? >>> >> I don't understand why a scanner would be classed as removable media. >> > > Because you put removable stuff in it and remove the stuff when > done. Solaris Object Reuse needs to be supported. > Scanners are different with "removable media" we usually think of (e.g., a CD Rom). In CD Rom case, when a CD is inserted, it will be mounted without user operations and HAL addon/callouts will work. In scanner case, nothing will happen when "removable stuff" is put in it. Users run the sane application to start all the jobs. And then, the scan job is done when sane is done. Therefore, sane is just an user application which access scanner device through libusb/ugen stack, that's it. I can not see the "must" relationship between sane and HAL. Colin From sommerfeld@sun.com Wed Mar 12 12:43:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CJhrII000443 for ; Wed, 12 Mar 2008 12:43:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2CJhlOR007610; Thu, 13 Mar 2008 03:43:52 +0800 (SGT) 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 <0JXM00603UT2VV00@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 13:43:50 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00J9DUT19MA0@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 13:43:49 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CJhi9P039754; Wed, 12 Mar 2008 15:43:44 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2CJhiWY002785; Wed, 12 Mar 2008 15:43:44 -0400 (EDT) Date: Wed, 12 Mar 2008 15:43:43 -0400 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205351023.2591.11.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> Status: RO Content-Length: 1138 On Wed, 2008-03-12 at 10:00 -0800, Gary Winiger wrote: > > I don't understand why a scanner would be classed as removable media. > > Because you put removable stuff in it and remove the stuff when > done. Solaris Object Reuse needs to be supported. I'm still not understanding why you think this means "object reuse" applies here; my understanding was that "object reuse" applied to reusable read/write storage like disks & memory -- if user A frees a page, and the system recycles it and gives it to user B, user B better not find any of user A's data in the page. the "removable stuff" in a typical scanner is not writable by the scanner. ("all in one" devices with both scanner and printer typically have separate paper paths for print vs. scan). There is nothing SOFTWARE can do about people who left something on the scanner bed when they logged out and wandered off. What's more, the software being proposed here does not need special privileges to operate; if some sort of device allocation/object reuse controls need to happen, they would need to happen in trusted privileged code at device open time. - Bill From Darren.Moffat@sun.com Wed Mar 12 13:04:59 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CK4wna001373 for ; Wed, 12 Mar 2008 13:04:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CK4wHA024790; Wed, 12 Mar 2008 13:04:58 -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 <0JXM00K1XVSAUD00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 13:04:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM0089QVS6YUC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 13:04:55 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CK4sZR029754; Wed, 12 Mar 2008 20:04:54 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXM00F01VK6SJ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 12 Mar 2008 20:04:53 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXM00D8BVS5XG20@fe-emea-09.sun.com>; Wed, 12 Mar 2008 20:04:53 +0000 (GMT) Date: Wed, 12 Mar 2008 20:04:53 +0000 From: Darren J Moffat Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <1205351023.2591.11.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: Gary Winiger , psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D83765.1050404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> <1205351023.2591.11.camel@thunk> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1079 Bill Sommerfeld wrote: > On Wed, 2008-03-12 at 10:00 -0800, Gary Winiger wrote: >>> I don't understand why a scanner would be classed as removable media. >> Because you put removable stuff in it and remove the stuff when >> done. Solaris Object Reuse needs to be supported. > > I'm still not understanding why you think this means "object reuse" > applies here; my understanding was that "object reuse" applied to > reusable read/write storage like disks & memory -- if user A frees a > page, and the system recycles it and gives it to user B, user B better > not find any of user A's data in the page. > > the "removable stuff" in a typical scanner is not writable by the > scanner. ("all in one" devices with both scanner and printer typically > have separate paper paths for print vs. scan). Not only separate paper paths but they often appear as separate USB devices (using usb_mid(7D) on Solaris, and usbprn(7D) for the printer part). I wonder how we do "object reuse" scrubbing for a webcam ? Ask the user to put a cloth over the camera ;-) -- Darren J Moffat From gww@eng.sun.com Wed Mar 12 14:34:43 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CLYglC004140 for ; Wed, 12 Mar 2008 14:34:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CLYd6F028028; Wed, 12 Mar 2008 15:34:42 -0600 (MDT) 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 <0JXM0060XZXTCI00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 14:34:41 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM005GYZXSMR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 14:34:40 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CLYbFi007097; Wed, 12 Mar 2008 14:34:37 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2CMYdE3022267; Wed, 12 Mar 2008 14:34:39 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2CMYdSZ022266; Wed, 12 Mar 2008 14:34:39 -0800 (PST) Date: Wed, 12 Mar 2008 14:34:39 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, sommerfeld@sun.com Cc: Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803122234.m2CMYdSZ022266@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4719 > On Wed, 2008-03-12 at 10:00 -0800, Gary Winiger wrote: > > > I don't understand why a scanner would be classed as removable media. > > > > Because you put removable stuff in it and remove the stuff when > > done. Solaris Object Reuse needs to be supported. > > I'm still not understanding why you think this means "object reuse" > applies here; my understanding was that "object reuse" applied to > reusable read/write storage like disks & memory -- if user A frees a > page, and the system recycles it and gives it to user B, user B better > not find any of user A's data in the page. Huh: T.RESIDUAL_DATA A user or process may gain unauthorized access to data through reallocation of TOE resources from one user or process to another. O.RESIDUAL_INFORMATION The TOE will ensure that any data contained in a protected resource is not available when the resource is reallocated. Rationale The sharing of hardware resources such as primary and secondary storage components between users introduces the potential for information flow in violation of the TOE security policy when hardware resources are deallocated from one user and allocated to another. In order to prevent such unintended consequences, the TOE prevents the compromise of the TOE security policy through mechanisms that ensure that residual information cannot be accessed after the resource has been reallocated (O.RESIDUAL_INFORMATION). The intent here is to prevent the unauthorized flow of information that would violate the TOE security policy. The intent is not to require explicit scrubbing or overwriting of data prior to reuse of the storage resource. Therefore, the presence of "residual" data in a storage resource is acceptable as long as it cannot be accessed by subsequent users such that a violation of the TOE security policy results. Note, however, that the requirements for storage resources which contain critical cryptographic security parameters differ from the requirements for other types of data. Refer to the appropriate threat, objectives, and requirements rationale for a discussion of the requirements for residual data protection involving critical cryptographic security parameters. Residual Information Protection (FDP_RIP) Full Residual Information Protection (FDP_RIP.2) FDP_RIP.2.1 Refinement: The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] all objects other than those associated with cryptographic keys and critical cryptographic security parameters as described in FCS_CKM.4.1 and FCS_CKM_EXP.2.5. Application Note: This requirement applies to all resources except for cryptographic keys and critical cryptographic security parameters governed by or used by the TSF; it includes resources used to store data and attributes. It also includes the encrypted representation of information. Residual information protection for cryptographic data is covered in class FCS. Application Note: Clearing the content of resources on deallocation is sufficient to satisfy this requirement, provided that unallocated resources will not accumulate new information until they are allocated again. > the "removable stuff" in a typical scanner is not writable by the > scanner. Writability isn't the issue. Consider cryptographic keys that are stored in read only memory. When you give that memory to another process would you want those keys to ge readable by that process? > There is nothing SOFTWARE can do about people who left something on the > scanner bed when they logged out and wandered off. As broken as you may consider removable media management and device allocation are there to address the things that can't be done in other forms. > What's more, the software being proposed here does not need special > privileges to operate; if some sort of device allocation/object reuse > controls need to happen, they would need to happen in trusted privileged > code at device open time. If the device allocation subsystem is in effect, the user is required to be authorized, chkauthattr(3SECDB) to have access to devices under its control. I suppose you could argue that the project teams that integrate devices needing object reuse into Solaris are not responsible. Please convince your (and my) director that the responsibility lies somewhere else. Gary.. From gww@eng.sun.com Wed Mar 12 14:37:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CLbLJa004283 for ; Wed, 12 Mar 2008 14:37:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CLbHdp023897; Wed, 12 Mar 2008 21:37:19 GMT 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 <0JXN00601026L600@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 14:37:18 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN005JY025MO00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 14:37:18 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CLbErL008877; Wed, 12 Mar 2008 14:37:14 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2CMbHoU022279; Wed, 12 Mar 2008 14:37:17 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2CMbHvK022278; Wed, 12 Mar 2008 14:37:17 -0800 (PST) Date: Wed, 12 Mar 2008 14:37:17 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: sommerfeld@sun.com, Darren.Moffat@sun.com Cc: gww@eng.sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803122237.m2CMbHvK022278@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 283 > I wonder how we do "object reuse" scrubbing for a webcam ? Ask the user > to put a cloth over the camera ;-) The same as we do /dev/audio. We reset any state that can be read out to some default state. We also control which user is authorized access to /dev/audio. Gary.. From John.Plocher@sun.com Wed Mar 12 15:03:41 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CM3fFn005164 for ; Wed, 12 Mar 2008 15:03:41 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CM3cKM028301; Wed, 12 Mar 2008 15:03:40 -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 <0JXN009051A45800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:03:40 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN005ZF1A4N910@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:03:40 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CM3esE013616; Wed, 12 Mar 2008 15:03:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXM00D01ZMJYY00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 12 Mar 2008 15:03:40 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXN009MH1A05830@fe-sfbay-09.sun.com>; Wed, 12 Mar 2008 15:03:38 -0700 (PDT) Date: Wed, 12 Mar 2008 15:03:35 -0700 From: John Plocher Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803122237.m2CMbHvK022278@marduk.eng.sun.com> Sender: John.Plocher@sun.com To: Gary Winiger Cc: sommerfeld@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D85337.2040405@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803122237.m2CMbHvK022278@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 537 Gary Winiger wrote: >> I wonder how we do "object reuse" scrubbing for a webcam ? Ask the user >> to put a cloth over the camera ;-) > > The same as we do /dev/audio. We reset any state that can be OK, maybe I'm dense, but what is the perceived failure mode here? Is it "someone left a page on the scanner" or is it something else? If it is the "can't flush page table :-)" problem, what is it that you would expect to be done here? Not allow logout to happen until scan() == empty_scan_platen() or some such? or ...? -John From scott.rotondo@sun.com Wed Mar 12 15:27:08 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CMR8q8005560 for ; Wed, 12 Mar 2008 15:27:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CMR5S3000198; Wed, 12 Mar 2008 15:27:05 -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 <0JXN00B072D4I800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:27:04 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN005XF2D3ML20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:27:03 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2CMR3k6397798; Wed, 12 Mar 2008 15:27:03 -0700 (PDT) Date: Wed, 12 Mar 2008 15:27:03 -0700 From: Scott Rotondo Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803122234.m2CMYdSZ022266@marduk.eng.sun.com> To: Gary Winiger Cc: sommerfeld@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D858B7.3090007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803122234.m2CMYdSZ022266@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1071 Gary Winiger wrote: >> What's more, the software being proposed here does not need special >> privileges to operate; if some sort of device allocation/object reuse >> controls need to happen, they would need to happen in trusted privileged >> code at device open time. > > If the device allocation subsystem is in effect, the user is > required to be authorized, chkauthattr(3SECDB) to have access > to devices under its control. > > I suppose you could argue that the project teams that integrate > devices needing object reuse into Solaris are not responsible. > Please convince your (and my) director that the responsibility > lies somewhere else. Another way to deal with object reuse would be for the driver to ensure that data leftover from one use of the device is not accessible to subsequent users. That seems like a more workable solution than device allocation. A similar argument could be made about /dev/audio. Do we have reason to believe that the proposed implementation doesn't *already* comply with the object reuse requirement? Scott From sommerfeld@sun.com Wed Mar 12 15:29:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CMTsmm005578 for ; Wed, 12 Mar 2008 15:29:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CMTfkZ015339; Wed, 12 Mar 2008 22:29:53 GMT 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 <0JXN00B012HRRE00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:29:51 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN005252HQML30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:29:51 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CMTkGE022896; Wed, 12 Mar 2008 18:29:46 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2CMTj4c003692; Wed, 12 Mar 2008 18:29:45 -0400 (EDT) Date: Wed, 12 Mar 2008 18:29:45 -0400 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803122234.m2CMYdSZ022266@marduk.eng.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205360985.2591.57.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803122234.m2CMYdSZ022266@marduk.eng.sun.com> Status: RO Content-Length: 1134 > I suppose you could argue that the project teams that integrate > devices needing object reuse into Solaris are not responsible. > Please convince your (and my) director that the responsibility > lies somewhere else. Gary, There are two possibilities here, neither of which justifies delaying this case. Either: 1) there is no actual object reuse issue associated with scanners than can be dealt with in software (rather than operational procedures like signs reminding users to remove their documents from the scanner). or: 2) There is an object reuse issue with the inclusion of ugen devices in our default logindevperm by PSARC 2005/187 ("libusb should just work"); that inclusion allows the console user raw access to *any* USB device lacking a more specific driver. Any object reuse issue present with libsane/sane is ALSO present with just raw ugen. No change to the code this project intends to deliver can fix this hypothetical object reuse issue that exists today. This project does not make this hypothetical problem worse. This project cannot make this hypothetical problem better. - Bill From gww@eng.sun.com Wed Mar 12 15:56:14 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CMuElX006104 for ; Wed, 12 Mar 2008 15:56:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CMuDqu048450; Wed, 12 Mar 2008 16:56:14 -0600 (MDT) 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 <0JXN00E0J3PQKT00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:56:14 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN005YQ3PPMI30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 15:56:13 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CMuAVP000890; Wed, 12 Mar 2008 15:56:10 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2CNuCEO022545; Wed, 12 Mar 2008 15:56:13 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2CNuCfL022544; Wed, 12 Mar 2008 15:56:12 -0800 (PST) Date: Wed, 12 Mar 2008 15:56:12 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, John.Plocher@sun.com Cc: sommerfeld@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803122356.m2CNuCfL022544@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1156 > > The same as we do /dev/audio. We reset any state that can be > > > OK, maybe I'm dense, but what is the perceived failure mode here? > Is it "someone left a page on the scanner" or is it something else? It's that there is information remaining in the device that can be accessed after the device has been returned to the system and given to anothe person. > If it is the "can't flush page table :-)" problem, what is it > that you would expect to be done here? Not allow logout to happen > until scan() == empty_scan_platen() or some such? or ...? See allocate(1), deallocate(1), device_allocate(4), device_maps(4), and I thought there was a device_clean man page that I can't find. I expect the project team to supply whatever is necessary to work within the device allocation framework so the device is properly integrated therein. This may include stuff in devfsadm(1m), mkdevalloc(1m), mkdevmaps(1m), providing a clean script/program and so on. This stuff has all been part of SunOS since 5.3. Until recently, there's been very little activity in adding system components that needed special object reuse handling. Gary.. From John.Plocher@sun.com Wed Mar 12 16:23:18 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CNNIQJ007756 for ; Wed, 12 Mar 2008 16:23:18 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CNNHCw018171; Wed, 12 Mar 2008 16:23:18 -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 <0JXN00H0T4YT5P00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 16:23:17 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN005L34YTN950@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Mar 2008 16:23:17 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CNNHSk022669; Wed, 12 Mar 2008 16:23:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXN003014CL4100@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 12 Mar 2008 16:23:17 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXN005NG4YDGH50@fe-sfbay-10.sun.com>; Wed, 12 Mar 2008 16:23:01 -0700 (PDT) Date: Wed, 12 Mar 2008 16:22:59 -0700 From: John Plocher Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803122356.m2CNuCfL022544@marduk.eng.sun.com> Sender: John.Plocher@sun.com To: Gary Winiger Cc: sommerfeld@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D865D3.30809@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803122356.m2CNuCfL022544@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 2388 You are not listening. Or I am not hearing. What do you mean by "information remaining in the device"? Please be explicit. Even after deallocating and reallocating then, o An audio input device still passes on sounds made in its vicinity, o A web camera still shows the images of whatever it is pointed at, and o A scanner still returns images of whatever is placed on its scanning table or run thru its document feeder. I'm pretty sure that we don't require that the audio or web camera interfaces contain code that compares the current audio or video stream with all previously processed streams to preclude the transmission of similar or identical sounds or images - all we require is that copies of those previously captured sounds or images themselves are not exposed. In a scanner, this would mean that the driver needs to dispose of all cached and buffered content, state and what have you when the device is returned to the system, but it would not require a robot arm to open up the scanner lid and remove forgotten documents from the scanning table, shred and burn them when the device is deallocated. Or, would it? -John Gary Winiger wrote: >>> The same as we do /dev/audio. We reset any state that can be >> >> OK, maybe I'm dense, but what is the perceived failure mode here? >> Is it "someone left a page on the scanner" or is it something else? > > It's that there is information remaining in the device that > can be accessed after the device has been returned to the > system and given to anothe person. > >> If it is the "can't flush page table :-)" problem, what is it >> that you would expect to be done here? Not allow logout to happen >> until scan() == empty_scan_platen() or some such? or ...? > > See allocate(1), deallocate(1), device_allocate(4), device_maps(4), > and I thought there was a device_clean man page that I can't find. > > I expect the project team to supply whatever is necessary to > work within the device allocation framework so the device > is properly integrated therein. This may include stuff in > devfsadm(1m), mkdevalloc(1m), mkdevmaps(1m), providing > a clean script/program and so on. > > This stuff has all been part of SunOS since 5.3. Until recently, > there's been very little activity in adding system components > that needed special object reuse handling. > > Gary.. From scott.rotondo@sun.com Wed Mar 12 18:01:41 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2D11eLM009727 for ; Wed, 12 Mar 2008 18:01:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2D11Hdd007154; Thu, 13 Mar 2008 09:01:36 +0800 (SGT) 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 <0JXN0060D9IMC200@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 19:01:34 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN00CBU9IMVLF0@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 19:01:34 -0600 (MDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2D11Xbj419199; Wed, 12 Mar 2008 18:01:33 -0700 (PDT) Date: Wed, 12 Mar 2008 18:01:33 -0700 From: Scott Rotondo Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D865D3.30809@Sun.Com> To: John Plocher Cc: Gary Winiger , sommerfeld@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D87CED.9050708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803122356.m2CNuCfL022544@marduk.eng.sun.com> <47D865D3.30809@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1989 John Plocher wrote: > You are not listening. Or I am not hearing. > > What do you mean by "information remaining in the device"? > > Please be explicit. > > Even after deallocating and reallocating then, > o An audio input device still passes on sounds made in its > vicinity, > o A web camera still shows the images of whatever it is pointed > at, and > o A scanner still returns images of whatever is placed on its > scanning table or run thru its document feeder. > > I'm pretty sure that we don't require that the audio or web camera > interfaces contain code that compares the current audio or video > stream with all previously processed streams to preclude the > transmission of similar or identical sounds or images - all we > require is that copies of those previously captured sounds or > images themselves are not exposed. > > In a scanner, this would mean that the driver needs to > dispose of all cached and buffered content, state and what have > you when the device is returned to the system, but it would > not require a robot arm to open up the scanner lid and remove > forgotten documents from the scanning table, shred and burn them > when the device is deallocated. > > Or, would it? > > -John I think people are making this far more complex than it needs to be. Don't worry about paper left in the scanner or similar types of human error. The issue here is that the device needs to be effectively reset when a new user starts to use it (or at least, it needs to avoid returning data leftover from the previous user). An analogous example is /dev/audio, which has some programmable registers that retain state (e.g, for volume control). You want to make sure that one user doesn't open the device and set the registers to some state, thereby communicating information to the next user who opens the device. As I said, I would hope that the driver can guarantee the right behavior so that device allocation is not needed. Scott From gww@eng.sun.com Wed Mar 12 18:05:30 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2D15TK8010078 for ; Wed, 12 Mar 2008 18:05:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2D15FkM008835; Thu, 13 Mar 2008 09:05:28 +0800 (SGT) 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 <0JXN006039P1NA00@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 19:05:25 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN0063T9P0GI00@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 19:05:25 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2D15MaZ021542; Wed, 12 Mar 2008 18:05:22 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2D25P9m022660; Wed, 12 Mar 2008 18:05:25 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2D25OnU022659; Wed, 12 Mar 2008 18:05:24 -0800 (PST) Date: Wed, 12 Mar 2008 18:05:24 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, sommerfeld@sun.com Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803130205.m2D25OnU022659@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 792 > 2) There is an object reuse issue with the inclusion of ugen devices in > our default logindevperm by PSARC 2005/187 ("libusb should just work"); IIRC, when device allocation is configured logindevperm is largely zapped. The point is when operating within device allocation, that the right thing be done. This may well not the default out of the box, but there are lots of things in Solaris that we do to support "configurations" that are not the default out of the box. IMO, this is one of them. If when device allocation is configured all users have access to all usb devices, that's a bug and will need to be fixed by that project team. Just like other parts of Solaris, it's the delivering project team that needs to supply the parts for existing frameworks. Gary.. From gww@eng.sun.com Wed Mar 12 18:11:43 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2D1BgPv010971 for ; Wed, 12 Mar 2008 18:11:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2D1BWIK011511; Thu, 13 Mar 2008 09:11:41 +0800 (SGT) 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 <0JXN007019ZF5U00@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 19:11:39 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN006HW9ZFGJ00@brm-avmta-1.central.sun.com>; Wed, 12 Mar 2008 19:11:39 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2D1Ba0v024881; Wed, 12 Mar 2008 18:11:36 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2D2Bd4F022669; Wed, 12 Mar 2008 18:11:39 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2D2BcE7022668; Wed, 12 Mar 2008 18:11:38 -0800 (PST) Date: Wed, 12 Mar 2008 18:11:38 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, John.Plocher@sun.com Cc: sommerfeld@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 689 > Please be explicit. The device allocation subsystem is in control. The user only has access to the specific device by allocating it, see allocate(1). The user runs along happily scanning. The user is done and deallocates it, see deallocate(1). The deallocation process (and in TX the allocation process) runs the "device clean" program. This instructs the user to remove any documents from the device and acknowledge they have done so. The "device clean" program (or the device driver) resets the device to defaults so no one accessing the device at a later time can read out device parameters, such as scanning density -- I'm hypothzing here -- at a later time. Gary.. From jek3@sun.com Thu Mar 13 00:36:22 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2D7aMkq020442 for ; Thu, 13 Mar 2008 00:36:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2D7aG8e026447; Thu, 13 Mar 2008 07:36:17 GMT 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 <0JXN0020BRSGSP00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Mar 2008 00:36:16 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN00253RSFOF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Mar 2008 00:36:15 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2D7aEOQ443743; Thu, 13 Mar 2008 00:36:14 -0700 (PDT) Date: Wed, 12 Mar 2008 21:33:45 -1000 From: Joseph Kowalski Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D81255.1020501@Sun.COM> To: Darren J Moffat Cc: Gary Winiger , Brian.Cameron@sun.com, Raymond.Chen@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D8D8D9.6040100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> <47D81255.1020501@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 545 Darren J Moffat wrote: > How is it different to pilot-xfer or gphoto or any of the other > libusb consumers ? > > I just don't see what the issue is with this case. If there is an > object reuse issue then the issue is with logindevperm giving out > access to all the ugen provided devices as a user logs in. I'm guessing that this concern follows from the assertion that a scanner is "removable media" (to which you have already questioned). I'd like to hear if others agree with the "it ain't removable media" classification. - jek3 From Darren.Moffat@sun.com Thu Mar 13 04:52:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DBqrH4026507 for ; Thu, 13 Mar 2008 04:52:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2DBqfxc012931; Thu, 13 Mar 2008 19:52:52 +0800 (SGT) 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 <0JXO00F033O4AR00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 04:52:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO00BPM3O3OJ70@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 04:52:52 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2DBqoQs028136; Thu, 13 Mar 2008 11:52:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXO0010123ONR00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 13 Mar 2008 11:52:50 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXO002KU3N3Y400@fe-emea-09.sun.com>; Thu, 13 Mar 2008 11:52:15 +0000 (GMT) Date: Thu, 13 Mar 2008 11:52:15 +0000 From: Darren J Moffat Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803130205.m2D25OnU022659@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: sommerfeld@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D9156F.60502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130205.m2D25OnU022659@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1788 Gary Winiger wrote: >> 2) There is an object reuse issue with the inclusion of ugen devices in >> our default logindevperm by PSARC 2005/187 ("libusb should just work"); > > IIRC, when device allocation is configured logindevperm is > largely zapped. > The point is when operating within device allocation, that > the right thing be done. > > This may well not the default out of the box, but there are > lots of things in Solaris that we do to support "configurations" > that are not the default out of the box. > > IMO, this is one of them. If when device allocation is configured > all users have access to all usb devices, that's a bug and will > need to be fixed by that project team. > > Just like other parts of Solaris, it's the delivering project > team that needs to supply the parts for existing frameworks. This project does NOTHING with device nodes or permissions what so ever. This project only uses the libusb API from an UNPRIVILEGED process. This project adds no privileged code, no daemons or service and no code that needs to run with privilege. libsane is as responsible for device permissions and security as dd(1) is. There is actually nothing that libsane does that can't already be done by dd(1) directly on the device node or a bit of user compiled C code linked to libusb can't do. There is no new issues that this project brings to the table that don't already exist with libusb and ugen(7D). If ugen(7D) is broken with respect to device allocation then PSARC 2005/187 caused that breakage and needs to be fixed project CAN NOT fix that and should not be held to fixing it. For what it is worth I've been using libsane on Solaris (and MacOS) for a long time and I understand pretty well how it works. -- Darren J Moffat From Darren.Moffat@sun.com Thu Mar 13 04:55:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DBtmLn026808 for ; Thu, 13 Mar 2008 04:55:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DBtjAU013574; Thu, 13 Mar 2008 11:55:46 GMT 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 <0JXO00F0D3SXEY00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 04:55:45 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO00B5Z3SWOI80@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 04:55:45 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2DBthm9024832; Thu, 13 Mar 2008 11:55:43 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXO00M013CY4000@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 13 Mar 2008 11:55:43 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXO002LB3STY400@fe-emea-09.sun.com>; Thu, 13 Mar 2008 11:55:41 +0000 (GMT) Date: Thu, 13 Mar 2008 11:55:41 +0000 From: Darren J Moffat Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803122237.m2CMbHvK022278@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: sommerfeld@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D9163D.9040306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803122237.m2CMbHvK022278@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 731 Gary Winiger wrote: >> I wonder how we do "object reuse" scrubbing for a webcam ? Ask the user >> to put a cloth over the camera ;-) > > The same as we do /dev/audio. We reset any state that can be > read out to some default state. We also control which user > is authorized access to /dev/audio. /dev/audio is completely different. It is a device node looked after by a kernel driver. libsane is a CONSUMER of a device node provided by ugen(7D) [via libusb]. libsane is to the scanner device as /usr/bin/audiorecord is to /dev/audio - an unprivileged userland consumer of the device. It isn't /usr/bin/audiorecord that is responsible for participating in the device allocation / object reuse. -- Darren J Moffat From sommerfeld@sun.com Thu Mar 13 08:59:50 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DFxoKg003836 for ; Thu, 13 Mar 2008 08:59:50 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2DFxhbf016826; Thu, 13 Mar 2008 08:59: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 <0JXO0021TF3KLJ00@brm-avmta-1.central.sun.com>; Thu, 13 Mar 2008 09:59:44 -0600 (MDT) Received: from localhost.east.sun.com ([129.148.19.3]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO00I29F3JEF80@brm-avmta-1.central.sun.com>; Thu, 13 Mar 2008 09:59:43 -0600 (MDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2DFx2Q9021713; Thu, 13 Mar 2008 11:59:02 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2DFx2jp021712; Thu, 13 Mar 2008 11:59:02 -0400 (EDT) Date: Thu, 13 Mar 2008 11:59:01 -0400 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> To: Gary Winiger Cc: John.Plocher@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205423941.21174.43.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 1157 On Wed, 2008-03-12 at 18:11 -0800, Gary Winiger wrote: > The "device clean" program (or the device driver) > resets the device to defaults so no one accessing the device at > a later time can read out device parameters, such as scanning > density -- I'm hypothzing here -- at a later time. So, you have *finally* identified something specific and actionable that could possibly be investigated by the project team. The whole "scanner as removable media" thing was a total distraction/red herring. Project team (or Darren?): is there a portable way with libsane to reset a scanner to its power-on-default or factory-default configuration? Or does this require scanner-model-specific knowledge? I think the pragmatic answer is to not make claims about device allocation as part of the spec for this case. Perhaps we could use some future project to extend device allocation to cope with devices accessed through libusb/ugen and similar frameworks rather than kernel drivers with device-class-specific drivers, and another one to unify the logindevperm mechanism with device allocation. Neither of those seems to be this case. - Bill From sommerfeld@sun.com Thu Mar 13 10:05:31 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DH5VXR006332 for ; Thu, 13 Mar 2008 10:05:31 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2DH5Qbp011736; Thu, 13 Mar 2008 10:05:28 -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 <0JXO0010FI54PM00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 10:05:28 -0700 (PDT) Received: from localhost.east.sun.com ([129.148.19.3]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO000G6I52VV20@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 10:05:26 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2DH4j89022691; Thu, 13 Mar 2008 13:04:45 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2DH4iTY022690; Thu, 13 Mar 2008 13:04:44 -0400 (EDT) Date: Thu, 13 Mar 2008 13:04:44 -0400 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> To: Gary Winiger Cc: John.Plocher@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205427884.21884.7.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 360 On Wed, 2008-03-12 at 18:11 -0800, Gary Winiger wrote: > The deallocation process (and in TX the allocation process) > runs the "device clean" program. device_allocate(4) doesn't mention anything run at deallocation time. It mentions a "device-exec" program invoked by allocate(1). Do we have a man page bug, or a more serious problem? - Bill From sommerfeld@sun.com Thu Mar 13 10:08:29 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DH8Txt006822 for ; Thu, 13 Mar 2008 10:08:29 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2DH8RSg012634; Thu, 13 Mar 2008 10:08:28 -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 <0JXO0070BIA12A00@brm-avmta-1.central.sun.com>; Thu, 13 Mar 2008 11:08:25 -0600 (MDT) Received: from localhost.east.sun.com ([129.148.19.3]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO00I1JI9ZEBE0@brm-avmta-1.central.sun.com>; Thu, 13 Mar 2008 11:08:24 -0600 (MDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2DH7hKG022695; Thu, 13 Mar 2008 13:07:43 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2DH7gwF022694; Thu, 13 Mar 2008 13:07:42 -0400 (EDT) Date: Thu, 13 Mar 2008 13:07:42 -0400 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D76E61.8060007@sun.com> To: Lei Chen Cc: Gary Winiger , PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205428062.21884.10.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803120433.m2C4XcFJ020628@marduk.eng.sun.com> <47D76E61.8060007@sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 755 On Wed, 2008-03-12 at 13:47 +0800, Lei Chen wrote: > If I need to add scanner's device node to device_map, then I will have > to add all the possible scanner's device node. There're more than 1440 > models of scanners, with 760 supported by SANE at present[1](Possibly > more will appear). More than 760 items will be added to the device_map > like this: > > scanner:\ > scanner:\ > /dev/usb/4b8.11d/0/cntrl0/dev/usb/4b8.11d/0/cntrl0stat /dev/usb/4b8.11d/0/devstat > > I'm not sure if it's feasible. I am sure. It's not feasible. In order to meaningfully use device allocation with ugen devices, someone will need to extend the framework to provide some mechanism other than the /dev pathname to identify devices. - Bill From Bart.Blanquart@sun.com Thu Mar 13 10:28:03 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DHS236007691 for ; Thu, 13 Mar 2008 10:28:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DHRsnB000122; Thu, 13 Mar 2008 17:28:01 GMT 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 <0JXO00C09J6NM800@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Mar 2008 10:27:59 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO005BJJ6KVC70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Mar 2008 10:27:57 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2DHRuFH014394; Thu, 13 Mar 2008 17:27:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXO00C01IQ71000@fe-emea-09.sun.com> (original mail from Bart.Blanquart@Sun.COM); Thu, 13 Mar 2008 17:27:56 +0000 (GMT) Received: from [129.159.231.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXO001EBJ5YH070@fe-emea-09.sun.com>; Thu, 13 Mar 2008 17:27:36 +0000 (GMT) Date: Thu, 13 Mar 2008 18:27:31 +0100 From: Bart Blanquart Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <1205427884.21884.7.camel@localhost> Sender: Bart.Blanquart@sun.com To: Bill Sommerfeld Cc: Gary Winiger , John.Plocher@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <9228538D-F75E-4352-8082-DE08258AC67A@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> <1205427884.21884.7.camel@localhost> Status: RO Content-Length: 1845 On 13 Mar 2008, at 18:04, Bill Sommerfeld wrote: > On Wed, 2008-03-12 at 18:11 -0800, Gary Winiger wrote: >> The deallocation process (and in TX the allocation process) >> runs the "device clean" program. > > device_allocate(4) doesn't mention anything run at deallocation time. > It mentions a "device-exec" program invoked by allocate(1). > Do we have a man page bug, or a more serious problem? device-exec The physical device's data purge program to be run any time the device is acted on by allocate(1). This ensures that all usable data is purged from the physical device before it is reused. This field contains the filename of a program in /etc/security/lib or the full pathname of a cleanup script provided by the system administrator. The device_allocate(4) manpage does seem incomplete. Looking at the manpages for allocate(1) and deallocate(1) they do explain that it's run both at allocation and deallocation. The page should probably be updated to read "...any time the device is acted upon by allocate(1) or deallocate(1)". From the other manpages: (allocate(1)) When the system is configured with Trusted Extensions, allo- cate runs the clean program for the device before it grants access to the caller to that device. For devices with remov- able media that have a mountable file system, allocate mounts the media if the caller chooses. (deallocate(1)) The deallocate command frees an allocated device. It resets the ownership and permissions on all device special files associated with the device, disabling access to that device. deallocate runs the device cleaning program for that device as specified in device_allocate(4). (man pages as shipped on S10 8/07) Bart From John.Plocher@sun.com Thu Mar 13 10:28:12 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DHSCAc007705 for ; Thu, 13 Mar 2008 10:28:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2DHS95X003611; Thu, 13 Mar 2008 10:28:12 -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 <0JXO00813J6ZE800@brm-avmta-1.central.sun.com>; Thu, 13 Mar 2008 11:28:11 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO00IFMJ6XEHF0@brm-avmta-1.central.sun.com>; Thu, 13 Mar 2008 11:28:10 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2DHS9cM012473; Thu, 13 Mar 2008 10:28:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXO00001GEHRO00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 13 Mar 2008 10:28:09 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXO00M1VJ6JM010@fe-sfbay-10.sun.com>; Thu, 13 Mar 2008 10:27:56 -0700 (PDT) Date: Thu, 13 Mar 2008 10:27:54 -0700 From: John Plocher Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <1205423941.21174.43.camel@localhost> Sender: John.Plocher@sun.com To: Bill Sommerfeld Cc: Gary Winiger , Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D9641A.2060500@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> <1205423941.21174.43.camel@localhost> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 1692 Bill Sommerfeld wrote: > On Wed, 2008-03-12 at 18:11 -0800, Gary Winiger wrote: >> The "device clean" program (or the device driver) >> resets the device to defaults so no one accessing the device at >> a later time can read out device parameters, such as scanning >> density -- I'm hypothzing here -- at a later time. > > So, you have *finally* identified something specific and actionable that > could possibly be investigated by the project team. I think there are two things here - this is only one... > The whole "scanner as removable media" thing was a total distraction/red > herring. Nope - there was also > runs the "device clean" program. This instructs the user > to remove any documents from the device and acknowledge they > have done so. This is the removable media piece :-) > Perhaps we could use some future project to extend device allocation to > cope with devices accessed through libusb/ugen a We already have an architecture for removable media on USB flash and disk devices that uses HAL. It seems that there is an architectural hole here for "other USB devices that may have persistent state"; without fixing that hole, certain configurations of Solaris (TX etc) won't pass evaluation. Since we already have the approved architectures in place to enable SolarisTX and other "evaluated" configs, it shouldn't be the "device allocation" or "Solaris TX" teams jobs to keep on fixing the new stuff being dumped into OpenSolaris... IMO, the four teams (TX, device allocation, usb and sane) need to go off, butt heads and otherwise figure out what needs to happen. We can't (and shouldn't) invent that architecture here on this alias. -John From scott.rotondo@sun.com Thu Mar 13 10:36:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DHawCP007887 for ; Thu, 13 Mar 2008 10:36:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2DHasbs033533; Thu, 13 Mar 2008 11:36:55 -0600 (MDT) 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 <0JXO0022PJLHHG00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 10:36:53 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO000TOJLFVO40@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 10:36:51 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2DHapKY510675; Thu, 13 Mar 2008 10:36:51 -0700 (PDT) Date: Thu, 13 Mar 2008 10:36:51 -0700 From: Scott Rotondo Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D8D8D9.6040100@sun.com> To: Joseph Kowalski Cc: Darren J Moffat , Gary Winiger , Brian.Cameron@sun.com, Raymond.Chen@sun.com, PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47D96633.2020202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> <47D81255.1020501@Sun.COM> <47D8D8D9.6040100@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 931 Joseph Kowalski wrote: > Darren J Moffat wrote: >> How is it different to pilot-xfer or gphoto or any of the other >> libusb consumers ? >> >> I just don't see what the issue is with this case. If there is an >> object reuse issue then the issue is with logindevperm giving out >> access to all the ugen provided devices as a user logs in. > I'm guessing that this concern follows from the assertion that a scanner > is "removable media" (to which you have already questioned). > > I'd like to hear if others agree with the "it ain't removable media" > classification. > > - jek3 > It's not removable media. The necessary property to satisfy the object reuse requirement is to avoid leaking state information from one use of the device to the next. We have the same requirement all over the OS (think of memory pages or filesystem blocks). Please don't try to use device allocation to solve this problem. Scott From gww@eng.sun.com Thu Mar 13 11:56:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DIuUsR009701 for ; Thu, 13 Mar 2008 11:56:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DIuMBX011507; Thu, 13 Mar 2008 18:56:29 GMT 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 <0JXO00503NA20D00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 11:56:26 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO000X2NA2VS80@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 11:56:26 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DIuN6C029845; Thu, 13 Mar 2008 11:56:23 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2DJuR02023534; Thu, 13 Mar 2008 11:56:27 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2DJuRqO023533; Thu, 13 Mar 2008 11:56:27 -0800 (PST) Date: Thu, 13 Mar 2008 11:56:27 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, sommerfeld@sun.com Cc: John.Plocher@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803131956.m2DJuRqO023533@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 608 > On Wed, 2008-03-12 at 18:11 -0800, Gary Winiger wrote: > > The deallocation process (and in TX the allocation process) > > runs the "device clean" program. > > device_allocate(4) doesn't mention anything run at deallocation time. > > It mentions a "device-exec" program invoked by allocate(1). > > Do we have a man page bug, or a more serious problem? That's the "device clean" program that I referred to in my email and said I couldn't find the man page. [editorial: docs.sun.com search is no help] I know it's documented somewhere and didn't find it yesterday. See device_clean(1M). Gary.. From gww@eng.sun.com Thu Mar 13 12:17:48 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DJHliJ011373 for ; Thu, 13 Mar 2008 12:17:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2DJHeJW025460; Fri, 14 Mar 2008 03:17:46 +0800 (SGT) 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 <0JXO00M01O9JK200@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Mar 2008 12:17:43 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO00557O9IVHF0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Mar 2008 12:17:43 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DJHdEh048362; Thu, 13 Mar 2008 12:17:39 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2DKHhHj023559; Thu, 13 Mar 2008 12:17:43 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2DKHhE5023558; Thu, 13 Mar 2008 12:17:43 -0800 (PST) Date: Thu, 13 Mar 2008 12:17:43 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: sommerfeld@sun.com, Bart.Blanquart@sun.com Cc: gww@eng.sun.com, John.Plocher@sun.com, Darren.Moffat@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803132017.m2DKHhE5023558@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 298 > device-exec See device_clean(5). I may have called it 1M in an earlier mail since docs.sun.com sent me to a TS8 man page. I'm not sure what release first saw this man page. It's dated 14 Jun 2007. http://docs.sun.com/app/docs/doc/816-5175/6mbba7evk?l=en&a=view&q=device_clean Gary.. From sommerfeld@sun.com Thu Mar 13 15:58:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DMwplU018272 for ; Thu, 13 Mar 2008 15:58:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2DMwles024358; Fri, 14 Mar 2008 06:58:51 +0800 (SGT) 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 <0JXO00E07YI11N00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 15:58:49 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO0087MYI07WA0@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Mar 2008 15:58:48 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DMwhwd048427; Thu, 13 Mar 2008 18:58:43 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2DMwgkL001753; Thu, 13 Mar 2008 18:58:43 -0400 (EDT) Date: Thu, 13 Mar 2008 18:58:42 -0400 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <9228538D-F75E-4352-8082-DE08258AC67A@Sun.COM> To: Bart Blanquart Cc: Gary Winiger , John.Plocher@sun.com, Darren.Moffat@sun.com, PSARC-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205449122.557.42.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> <1205427884.21884.7.camel@localhost> <9228538D-F75E-4352-8082-DE08258AC67A@Sun.COM> Status: RO Content-Length: 525 On Thu, 2008-03-13 at 18:27 +0100, Bart Blanquart wrote: > The device_allocate(4) manpage does seem incomplete. Looking at the > manpages for allocate(1) and deallocate(1) they do explain that it's > run both at allocation and deallocation. The page should probably be > updated to read "...any time the device is acted upon by allocate(1) > or deallocate(1)". I agree that there's an obvious inconsistency here so I filed: 6675268 device_allocate(4) inconsistent with deallocate(1) and itself to track it. From Colin.Zou@sun.com Fri Mar 14 13:01:22 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2EK1MIS023758 for ; Fri, 14 Mar 2008 13:01:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2EK1M9M018191; Fri, 14 Mar 2008 14:01:22 -0600 (MDT) 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 <0JXQ00921KYAED00@brm-avmta-1.central.sun.com>; Fri, 14 Mar 2008 14:01:22 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXQ004QSKY70A30@brm-avmta-1.central.sun.com>; Fri, 14 Mar 2008 14:01:21 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2EK1QEJ013171; Fri, 14 Mar 2008 20:01:26 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXQ00M01KW07K00@mail-apac.sun.com> (original mail from Colin.Zou@Sun.COM) ; Sat, 15 Mar 2008 04:01:15 +0800 (SGT) Received: from [207.47.1.113] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXQ00BH2KY0MNES@mail-apac.sun.com>; Sat, 15 Mar 2008 04:01:15 +0800 (SGT) Date: Fri, 14 Mar 2008 13:01:00 +0800 From: Colin Zou Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D9156F.60502@Sun.COM> Sender: Colin.Zou@sun.com To: Darren J Moffat Cc: Gary Winiger , sommerfeld@sun.com, psarc-ext@sun.com, Raymond.Chen@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47DA068C.1060202@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130205.m2D25OnU022659@marduk.eng.sun.com> <47D9156F.60502@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 1613 > > This project does NOTHING with device nodes or permissions what so ever. > > This project only uses the libusb API from an UNPRIVILEGED process. > > This project adds no privileged code, no daemons or service and no > code that needs to run with privilege. > > libsane is as responsible for device permissions and security as dd(1) > is. There is actually nothing that libsane does that can't already > be done by dd(1) directly on the device node or a bit of user compiled > C code linked to libusb can't do. > > There is no new issues that this project brings to the table that > don't already exist with libusb and ugen(7D). If ugen(7D) is broken > with respect to device allocation then PSARC 2005/187 caused that > breakage and needs to be fixed project CAN NOT fix that and should not > be held to fixing it. > Yes, fully agree. The above words tell the key points. While it is good to see this case raised discussion about ugen(7D) related device allocation or object reuse issues, it is out of scope for this case to continue to discuss them. Because this case can neither contribute to the issue nor make it worse. We now know it should be a seperate project to investigate the ugen(7D) issue. USB dev. team is happy to work with people to get ugen investigation done. I am working on USB and I myself would like to contribute to this task. Let's just focus on the interfaces/issues within this case scope. Solaris users are expecting scanner support, we engineers should move forward to make this feature done, and also investigate the ugen issue in parelle. Thanks, Colin From Colin.Zou@sun.com Fri Mar 14 13:38:48 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2EKcls6024290 for ; Fri, 14 Mar 2008 13:38:47 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2EKclTp016366 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 14 Mar 2008 13:38:47 -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 <0JXQ00L07MONFX00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Mar 2008 13:38:47 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXQ00K1IMOKY920@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Mar 2008 13:38:46 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2EKd4l2018718 for ; Fri, 14 Mar 2008 20:39:04 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXQ00901MHRSL00@mail-apac.sun.com> (original mail from Colin.Zou@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 15 Mar 2008 04:38:40 +0800 (SGT) Received: from [207.47.1.113] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXQ00BGIMODMHZP@mail-apac.sun.com>; Sat, 15 Mar 2008 04:38:40 +0800 (SGT) Date: Fri, 14 Mar 2008 13:38:25 +0800 From: Colin Zou Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47D8D8D9.6040100@sun.com> Sender: Colin.Zou@sun.com To: Joseph Kowalski Cc: Darren J Moffat , Gary Winiger , Brian.Cameron@sun.com, Raymond.Chen@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47DA0F51.4090507@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803121800.m2CI0KJ8021503@marduk.eng.sun.com> <47D81255.1020501@Sun.COM> <47D8D8D9.6040100@sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 782 Joseph Kowalski : > Darren J Moffat wrote: >> How is it different to pilot-xfer or gphoto or any of the other >> libusb consumers ? >> >> I just don't see what the issue is with this case. If there is an >> object reuse issue then the issue is with logindevperm giving out >> access to all the ugen provided devices as a user logs in. > I'm guessing that this concern follows from the assertion that a > scanner is "removable media" (to which you have already questioned). > > I'd like to hear if others agree with the "it ain't removable media" > classification. > It's not removable media. To make it easy for people to understand scanner device, it can be looked as a "sensor" because what it does is just to pass what it scanned (sensed) to computer. That's it. Colin From Raymond.Chen@sun.com Sun Mar 16 20:54:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2H3stQc028669 for ; Sun, 16 Mar 2008 20:54:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2H3soQv017421; Mon, 17 Mar 2008 11:54:54 +0800 (SGT) 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 <0JXU0040DW7GAD00@nwk-avmta-2.sfbay.sun.com>; Sun, 16 Mar 2008 20:54:52 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXU003G6W7EVS00@nwk-avmta-2.sfbay.sun.com>; Sun, 16 Mar 2008 20:54:51 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2H3tA7u017494; Mon, 17 Mar 2008 03:55:10 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXU00J01VXNZ600@mail-apac.sun.com> (original mail from Raymond.Chen@Sun.COM); Mon, 17 Mar 2008 11:54:42 +0800 (SGT) Received: from [129.158.218.51] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXU00BTAW73MHKU@mail-apac.sun.com>; Mon, 17 Mar 2008 11:54:40 +0800 (SGT) Date: Mon, 17 Mar 2008 12:02:06 +0800 From: Lei Chen Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <1205423941.21174.43.camel@localhost> Sender: Raymond.Chen@sun.com To: Bill Sommerfeld Cc: Gary Winiger , John.Plocher@sun.com, Darren.Moffat@sun.com, PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47DDED3E.1040606@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> <1205423941.21174.43.camel@localhost> User-Agent: Thunderbird 2.0.0.6 (X11/20070824) Status: RO Content-Length: 1563 Bill Sommerfeld wrote: > The whole "scanner as removable media" thing was a total distraction/red > herring. > > Project team (or Darren?): is there a portable way with libsane to reset > a scanner to its power-on-default or factory-default configuration? Or > does this require scanner-model-specific knowledge? > The reset-to-default behavior depends on the hardware's capability. Some scanners support reset operation. Upon device close/open, a reset command will be sent to the device. For those that don't support hardware reset, the backend will call its own init_options() or similar function to set default parameters for a device upon sane_init(), sane_open() or sane_start()[1], then write such parameters to device to acquire data. Some backend may even use all the methods to set initial state of a scanner. Application can change the parameter values by calling sane_control_option(). So, whenever a user starts to acquire image data from a scanner, the scanner's state is reset. Thanks, Lei Chen [1] http://www.sane-project.org/html/doc013.html > I think the pragmatic answer is to not make claims about device > allocation as part of the spec for this case. > > Perhaps we could use some future project to extend device allocation to > cope with devices accessed through libusb/ugen and similar frameworks > rather than kernel drivers with device-class-specific drivers, and > another one to unify the logindevperm mechanism with device allocation. > > Neither of those seems to be this case. > > - Bill > > > > > > > > From Darren.Moffat@sun.com Mon Mar 17 03:56:27 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HAuQde008071 for ; Mon, 17 Mar 2008 03:56:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2HAuJ0W025064; Mon, 17 Mar 2008 18:56:25 +0800 (SGT) 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 <0JXV00H1JFPZ1M00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 17 Mar 2008 03:56:23 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXV00A8NFPX9970@nwk-avmta-1.sfbay.Sun.COM>; Mon, 17 Mar 2008 03:56:23 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2HAuLOp029246; Mon, 17 Mar 2008 10:56:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXV00H01FC2UG00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 17 Mar 2008 10:56:21 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXV00EAKFPQN900@fe-emea-09.sun.com>; Mon, 17 Mar 2008 10:56:14 +0000 (GMT) Date: Mon, 17 Mar 2008 10:56:14 +0000 From: Darren J Moffat Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <47DDED3E.1040606@sun.com> Sender: Darren.Moffat@sun.com To: Lei Chen Cc: Bill Sommerfeld , Gary Winiger , John.Plocher@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <47DE4E4E.8070400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803130211.m2D2BcE7022668@marduk.eng.sun.com> <1205423941.21174.43.camel@localhost> <47DDED3E.1040606@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1911 Lei Chen wrote: > Bill Sommerfeld wrote: >> The whole "scanner as removable media" thing was a total distraction/red >> herring. >> >> Project team (or Darren?): is there a portable way with libsane to reset >> a scanner to its power-on-default or factory-default configuration? Or >> does this require scanner-model-specific knowledge? >> > The reset-to-default behavior depends on the hardware's capability. Some > scanners support reset operation. Upon device close/open, a reset > command will be sent to the device. For those that don't support > hardware reset, the backend will call its own init_options() or similar > function to set default parameters for a device upon sane_init(), > sane_open() or sane_start()[1], then write such parameters to device to > acquire data. Some backend may even use all the methods to set initial > state of a scanner. Application can change the parameter values by > calling sane_control_option(). So, whenever a user starts to acquire > image data from a scanner, the scanner's state is reset. My understanding of the above summary is that "device clean" is effectively built into the API and to the scanimage(1) command. However given that the devices are managed by logindevperm when not running with Trusted Extensions this is more than should be necessary. When Trusted Extensions is enabled (svcadm enable labeled) the logindevperm entries that give access to the USB scanner devices (via libusb/ugen(7D)) are disabled from logindevperm. This means the system is "safe" though scanner devices can't be allocated. Fixing the allocation of non mass-storage/audio devices when running with Trusted Extensions is very much out of scope for this case. I think such a case is needed; but I don't currently see any value in derailing this case to write an opinion to say so. Instead I've logged bugster CR# 6676059. -- Darren J Moffat From gww@eng.sun.com Tue Mar 18 17:35:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2J0ZQc4026628 for ; Tue, 18 Mar 2008 17:35:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2J0ZLj9015867; Wed, 19 Mar 2008 00:35:25 GMT 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 <0JXY00M03CAZPS00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Mar 2008 17:35:23 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXY00H5SCAY9F70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Mar 2008 17:35:23 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2J0ZJe6036549; Tue, 18 Mar 2008 17:35:19 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2J1ZV13002034; Tue, 18 Mar 2008 17:35:31 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2J1ZVba002033; Tue, 18 Mar 2008 17:35:31 -0800 (PST) Date: Tue, 18 Mar 2008 17:35:31 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: Darren.Moffat@sun.com, Raymond.Chen@sun.com Cc: John.Plocher@sun.com, gww@eng.sun.com, psarc-ext@sun.com, sommerfeld@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803190135.m2J1ZVba002033@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3142 > > The reset-to-default behavior depends on the hardware's capability. Some > > scanners support reset operation. Upon device close/open, a reset > > command will be sent to the device. For those that don't support > > hardware reset, the backend will call its own init_options() or similar > > function to set default parameters for a device upon sane_init(), > > sane_open() or sane_start()[1], then write such parameters to device to > > acquire data. Some backend may even use all the methods to set initial > > state of a scanner. Application can change the parameter values by > > calling sane_control_option(). So, whenever a user starts to acquire > > image data from a scanner, the scanner's state is reset. > > My understanding of the above summary is that "device clean" is > effectively built into the API and to the scanimage(1) command. > However given that the devices are managed by logindevperm when not > running with Trusted Extensions this is more than should be necessary. > > When Trusted Extensions is enabled (svcadm enable labeled) the > logindevperm entries that give access to the USB scanner devices (via > libusb/ugen(7D)) are disabled from logindevperm. This means the system > is "safe" though scanner devices can't be allocated. > > Fixing the allocation of non mass-storage/audio devices when running > with Trusted Extensions is very much out of scope for this case. I > think such a case is needed; but I don't currently see any value in > derailing this case to write an opinion to say so. Instead I've logged > bugster CR# 6676059. As sort of a last word I hope %^}. Object reuse is a Solaris requirement. Object reuse applies to ALL objects within Solaris. (Trusted Extensions has labeling requirements for the import and export of labeled data, the device allocation framework is used to aid in meeting the labeling requirements) The issue, as I see it, is that in this case's materials I noted that there was a potential object reuse issue that didn't seem to be dealt with. The issue deals with both data (documents left in the scanner) and state. While this might be a general USB libusb/ugen() issue, I'd not noticed it before. When I was first looking at this it was for HAL. Devices managed by HAL are configurable to do object reuse (through device allocation). What's the resolution? This project team says "not my job man". Management has given me the impression that the team that integrates is responsible for the fullness of the requirements. Do we unwind libusb/ugen() and have that team (I'm guessing usb/usb_sw/ugen Frits Vanderlinden) complete the work? Do we make this case dependent on that work being done by another project? Or do we say, too bad, that's not going to get done and this case makes it no worse? I don't believe writing an opinion will provide value for this case. As this is doing no more harm than the other things that might currently be present in the non-mass-storage USB world, I'm not going to hold it up. Fixing the missing general USB issues is a problem to be raised to management. Gary.. From sommerfeld@sun.com Wed Mar 19 11:04:29 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JI4S2Q025319 for ; Wed, 19 Mar 2008 11:04:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JI4NO5009900; Thu, 20 Mar 2008 02:04:24 +0800 (SGT) 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 <0JXZ00I09OVBIF00@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 11:04:23 -0700 (PDT) Received: from localhost.east.sun.com ([10.7.251.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00E65OVA36B0@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 11:04:22 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JI3Y8L002207; Wed, 19 Mar 2008 11:03:34 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2JI3XQF002206; Wed, 19 Mar 2008 11:03:33 -0700 (PDT) Date: Wed, 19 Mar 2008 11:03:33 -0700 From: Bill Sommerfeld Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] In-reply-to: <200803190135.m2J1ZVba002033@marduk.eng.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, Raymond.Chen@sun.com, John.Plocher@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <1205949813.1681.48.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803190135.m2J1ZVba002033@marduk.eng.sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 529 On Tue, 2008-03-18 at 17:35 -0800, Gary Winiger wrote: > The issue deals with both data (documents > left in the scanner) and state. While this might be a general > USB libusb/ugen() issue, I'd not noticed it before. This is pretty clearly a bordering-on-intractable USB/libusb/ugen issue; there are no constraints on what sort of state can be retained by USB devices, and no generic USB-level "go clean yourself" action that is guaranteed to do what a device clean operation would be expected to do. - Bill From gww@eng.sun.com Wed Mar 19 12:05:03 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JJ53du027038 for ; Wed, 19 Mar 2008 12:05:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JJ50oh005705; Wed, 19 Mar 2008 12:05:03 -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 <0JXZ00105ROELR00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 13:05:02 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00MBZROCJP20@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 13:05:01 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JJ4wxf041946; Wed, 19 Mar 2008 12:04:58 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2JK5BGs004013; Wed, 19 Mar 2008 12:05:11 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2JK5BkM004012; Wed, 19 Mar 2008 12:05:11 -0800 (PST) Date: Wed, 19 Mar 2008 12:05:11 -0800 (PST) From: Gary Winiger Subject: Re: Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008] To: gww@eng.sun.com, sommerfeld@sun.com Cc: Darren.Moffat@sun.com, Raymond.Chen@sun.com, John.Plocher@sun.com, PSARC-ext@sun.com, tl41329@sac.sfbay.sun.com Message-id: <200803192005.m2JK5BkM004012@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 773 > On Tue, 2008-03-18 at 17:35 -0800, Gary Winiger wrote: > > The issue deals with both data (documents > > left in the scanner) and state. While this might be a general > > USB libusb/ugen() issue, I'd not noticed it before. > > This is pretty clearly a bordering-on-intractable USB/libusb/ugen issue; > there are no constraints on what sort of state can be retained by USB > devices, and no generic USB-level "go clean yourself" action that is > guaranteed to do what a device clean operation would be expected to do. I agree in the general case, USB seems to have no uniform architecture, however for Sun supplied device libraries, I believe we can do better than say: too bad if you use USB devices there is no hope for providing Object Reuse. Gary.. From Tzongyu.Lee@sun.com Wed Mar 19 17:24:19 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2K0OIDE007825 for ; Wed, 19 Mar 2008 17:24:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2K0O1G7024586; Thu, 20 Mar 2008 00:24:17 GMT 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 <0JY00011L6GEVV00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 18:24:14 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY000FIS6GBU5A0@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 18:24:12 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2K0OKKg025391; Thu, 20 Mar 2008 00:24:20 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY000K0166FHW00@mail-apac.sun.com> (original mail from Tzongyu.Lee@Sun.COM); Thu, 20 Mar 2008 08:24:01 +0800 (SGT) Received: from [129.158.148.47] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY000BKU6FZMFQX@mail-apac.sun.com>; Thu, 20 Mar 2008 08:24:01 +0800 (SGT) Date: Thu, 20 Mar 2008 08:24:08 +0800 From: Tzongyu Paul Lee Subject: 2-week+ timer set [Re: Integrate libsane and sane into Solaris[PSARC/2008/170 FastTrack timeout 03/11/2008]] In-reply-to: <200803192005.m2JK5BkM004012@marduk.eng.sun.com> Sender: Tzongyu.Lee@sun.com To: Gary Winiger Cc: sommerfeld@sun.com, Darren.Moffat@sun.com, Raymond.Chen@sun.com, John.Plocher@sun.com, psarc-ext@sun.com, tl41329@sac.sfbay.sun.com Reply-to: Tzongyu.Lee@sun.com Message-id: <47E1AEA8.9040701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803192005.m2JK5BkM004012@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1866 Hi all, 1. This open-source import project integrates sane and libsane to support usb scanner devices. It uses libusb API from an unprivileged process. It does not introduce any device drivers or device nodes. 2. There is an issue needing further investigation in the context of device_allocation support and usb, it is logged by "CR 6676059 Non mass-storage/audio devices need to be allocatable". 3. For the above two issues, this project would neither contribute to it nor make it worse. Since this fast-track case was extended in the 3/12 PSARC meeting, I would propose to explicitly set the timer two weeks from the original proposal 3/11 to 3/25 to incorporate further discussions related to this case. And with hope we can converge based on the same or compatible understandings of the issues raised by this case. Best Regards, Paul Gary Winiger wrote: >> On Tue, 2008-03-18 at 17:35 -0800, Gary Winiger wrote: >> >>> The issue deals with both data (documents >>> left in the scanner) and state. While this might be a general >>> USB libusb/ugen() issue, I'd not noticed it before. >>> >> This is pretty clearly a bordering-on-intractable USB/libusb/ugen issue; >> there are no constraints on what sort of state can be retained by USB >> devices, and no generic USB-level "go clean yourself" action that is >> guaranteed to do what a device clean operation would be expected to do. >> > > I agree in the general case, USB seems to have no uniform > architecture, however for Sun supplied device libraries, I > believe we can do better than say: too bad if you use USB devices > there is no hope for providing Object Reuse. > > Gary.. > -- Tzongyu Paul Lee, Tzongyu.Lee@Sun.Com or Paul.Lee@Sun.COM BJS05 7225, x84343 http://blogs.sun.com/tpaullee/ Feel the Pulses of China http://tpaullee.blogspot.com/