I'm not sure you really need to call out the public DDI interfaces used
by the project. Apart from the weird line breaks in the e-mail, the
opinion looks good to me.
-- Garrett
Mark Martin wrote:
>
> After conclusion of the business vote on 6/25 for PSARC 2008/097
> "sosd: SCSI Object-based Storage Device driver", I would like to offer
> for your review the following final opinion draft. I'll set the timer
> for 1 week: 2008-07-03.
>
>
> Sun
> Microsystems Systems Architecture Committee
>
> _________________________________________________________________
>
>
> Subject: sosd: SCSI Object-based Storage Device driver
>
>
>
>
> Submitted by: Mark Martin
>
> File: PSARC/2008/097/opinion.ms <http://opinion.ms>
>
>
> Date: March 11th, 2008.
>
>
> Committee: Mark Carlson (opinion written by Mark Martin)
>
>
> (Members present: Glenn Skinner, Garrett D'Amore,
>
> Joseph Kowalski, Kais Belgaied)
>
>
> Product Approval Committee:
> Solaris PAC
>
> solaris-pac-opinion at sun.com <mailto:solaris-pac-opinion at
> sun.com>
>
>
>
>
> 1. Summary
>
> The project implements a new SCSI target driver (sosd) that binds
>
>
> to object-based SCSI devices conforming to the ANSI T10 OSD-2
>
> standard. The new target driver will allow filesystems and
>
>
> applications to interact with the OSD devices using object
> semantics instead of block semantics. This driver will be a peer
>
>
> of the existing SCSI target drivers sd, st and sgen.
>
>
>
> 2. Decision & Precedence Information
>
>
>
> The project is approved as specified in reference [1].
>
> The project may be delivered in a patch release.
>
>
>
>
> 3. Interfaces
>
> The project exports the following interfaces.
>
>
> Exported Interfaces
>
>
> ______________________________________________________________________
> Interface | Classification | Comments
>
>
> ___________________________________|________________|_________________
>
>
>
> osd_setup_format_osd | |
> osd_setup_create_partition | | These interfaces
>
> osd_setup_remove_partition | | are available to
>
>
>
>
> osd_setup_create_object | | kernel clients
> osd_setup_remove_object | | (filesystems)
>
> osd_setup_create_and_write | | through scsi_osd
>
>
>
>
> osd_setup_create_and_write_bp | | module
> osd_setup_write | |
> osd_setup_write_bp | CONTRACTED |
>
> osd_setup_read | CONSOLIDATION |
>
>
>
>
> osd_setup_read_bp | PRIVATE |
> osd_setup_append | |
> osd_setup_append_bp | |
>
> osd_setup_flush | |
>
>
>
>
> osd_setup_flush_osd | |
> osd_setup_clear | |
> osd_setup_punch | |
>
> osd_setup_object_structure_check | |
>
>
>
>
> osd_setup_set_attr | |
> osd_setup_get_attr | |
> | |
>
> osd_add_set_page_1attr_cdb | |
>
>
>
>
> osd_add_set_page_1attr_to_req | |
> osd_add_get_page_attr_to_req | |
> osd_add_set_list_entry_to_req | |
>
> osd_add_get_list_entry_to_req | |
>
>
>
>
> osd_add_capability_security_to_req | |
> osd_add_flags_to_req | |
> | |
>
> osd_submit_req | |
>
>
>
>
> | |
> osd_get_result | |
> | |
>
> osd_free_req | |
>
>
>
>
> | |
> osd_open_by_name | |
> osd_close | |
>
> | |
>
>
>
>
> osd_get_max_dma_size | |
> osd_get_api_version | |
> ___________________________________|__________________________________
>
>
>
>
> The project imports the following interfaces.
>
>
>
>
> Imported Interfaces
> _____________________________________________________________________
> Interface | Classification | Comments
>
>
> ____________________|____________________|___________________________
>
>
>
> Solaris DDI | |
> Solaris LDI | |
> scsi_init_pkt | |
>
>
> scsi_destroy_pkt | |
> scsi_transport | |
>
>
>
> scsi_dmafree | |
> scsi_probe | |
> scsi_unprobe | |
>
>
> scsi_ifgetcap | |
> scsi_ifsetcap | |
>
>
>
> scsi_log | |
> makedevice | |
> getminor | |
>
>
> physio | All are Committed | Interfaces defined in
>
>
> bioinit | |
>
> biowait | interfaces | sections 9F or 9S of
> bioerror | |
>
>
> biodone | | solaris man pages
>
>
> biofini | |
>
> buf | |
> bp_mapout | |
>
>
> getrbuf | |
> freerbuf | |
>
>
> kmem_cache_create | |
>
> kmem_cache_alloc | |
> kmem_cache_free | |
>
>
> kmem_cache_destroy | |
> kmem_zalloc | |
>
>
> kmem_free | |
>
> mod_install | |
> mod_info | |
>
>
> mod_remove | |
> mod_modname | |
>
>
> bcopy | |
>
> bzero | |
> bcmp | |
>
>
> mutex_init | |
> mutex_enter | |
>
>
> mutex_exit | |
>
> mutex_owned | |
> mutex_destroy | |
>
>
> sema_init | |
> sema_p | |
>
>
> sema_v | |
>
> sema_destroy | |
> kstat_create | |
>
>
> kstat_install | |
> kstat_named_init | |
>
>
> kstat_delete | |
>
> ____________________|____________________|____________________________
>
>
>
> The project uses the following interfaces for kernel module and driver
> communication internally.
>
>
>
> Internal Interfaces
>
> ______________________________________________________________________
>
>
> Interface | Classification | Comments
> __________________________|____________________|______________________
>
>
> osd_iotask_alloc | |
>
> osd_iotask_start | | These are used
>
>
> osd_iotask_free | PROJECT | internally for
> osd_register_library | PRIVATE | kernel module and
>
>
> osd_deregister_library | | driver communication
>
>
>
> osd_add_cap_sec_to_iotask | |
> __________________________|____________________|______________________
>
>
>
> 4. Opinion
>
>
> 4.1. Existing clients planned
>
> During inception discussion, it was noted that the ARC discourages
>
>
>
> producing APIs which do not have any clients. The project team indicated
> that the Shared QFS will deliver as a client of this API at a later date.
>
>
> See PSARC 2007/588.
>
>
> 5. Minority Opinion(s)
>
>
>
> None.
>
>
> 6. Advisory Information
>
> 6.1. Bi-directional support and atomic transactions.
>
> During inception review, the lack of support for bi-directional
>
>
> communication caused concern, especially with regard for supporting atomic
>
>
>
> transactions.
>
> The project team acknowleges that while this is a limitation in the
> existing framework, Shared QFS does not have a requirement to support
>
>
> bi-directional commands. Any other client that wishes to use the sosd driver
>
>
>
> must be aware of the bi-directional support limitation in SCSA.
>
> The committee would advise the project team to clearly state the
>
>
> limitation that if another client (apart from Shared QFS) wants to use this
>
>
> interface, such client may not assume bidirectional support and should know
>
> that lack of bidirectional support may have issues with atomicity of a
>
>
> 'client-initiated-split-command' to achieve the net effect of a bidirectional
>
>
> command. The driver will _never_ split any command on behalf of the client.
>
>
> Shared/Concurrent access will have to be managed by filesystem and OSD
>
>
> target with OSD protocol support or QFS semantics and out of scope.
>
>
>
> 7. Appendices
>
> 7.1. Appendix A: Technical Changes Required
>
>
> None.
>
> 7.2. Appendix B: Technical Changes Advised
>
>
> None.
>
>
> 7.3. Appendix C: Reference Material
>
> Unless stated otherwise, path names are relative to the case
>
>
> directory PSARC/2008/097.
>
>
> 1 Onepager
> File: onepager
>
> 2 Inception minutes
>
> File: 20080227-2008-097-inception
>
>
> 3 Issues
> File: issues
>
> 4 PSARC 20 Questions.
>
>
> File: final.materials/20q
>
>
> 5 Security
> File: final.materials/security.txt
>
>
> 6 SCSI OSD Driver Design
> File: final.materials/sosd_design_v3.pdf
>
>
> 7 ANSI project T10/11729-D standard
>
>
> http://www.t10.org/ftp/t10/drafts/osd/osd2r03.pdf
>
>
>
>
> PSARC/2008/097 Copyright 2008 Sun Microsystems
>
>
>
>
