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..
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/9928c492/attachment.html>
