From gd78059@sac.sfbay.sun.com Wed Nov 14 09:46:36 2007 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 lAEHkZLh005904 for ; Wed, 14 Nov 2007 09:46:36 -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 lAEHkUvC004587; Thu, 15 Nov 2007 01:46:34 +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 <0JRI00205C1JZA00@brm-avmta-1.central.sun.com>; Wed, 14 Nov 2007 10:46:31 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRI00KAGC1I3DB0@brm-avmta-1.central.sun.com>; Wed, 14 Nov 2007 10:46:30 -0700 (MST) 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 lAEHkUXV057923; Wed, 14 Nov 2007 09:46:30 -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 lAEHkScf005899; Wed, 14 Nov 2007 09:46:28 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lAEHkSFf005895; Wed, 14 Nov 2007 09:46:28 -0800 (PST) Date: Wed, 14 Nov 2007 09:46:28 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] To: PSARC-ext@Sun.COM Cc: Garrett.Damore@Sun.COM Message-id: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 17479 I'm submitting following fast-track on my own behalf. This may be straddling the boundary of what can pass for a fast-track. If members feel that this is deserving of a full review, please don't hesitate to derail it. (I won't take it personally. :-) Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: blk2scsa 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 14 November, 2007 4. Technical Description Generic Block Device to SCSA Translation Layer Functional Specification Garrett D'Amore (gdamore@sun.com) Nov 13, 2007 CHAPTER 1: Introduction There are an ever growing number of digital memory formats, as well as other kinds of storage media in the market today. Historically, Solaris has had only limited support for most of them, when connected through a USB or IEEE 1394 media reader. Modern laptops and mobile computing devices are now shipping with slots for these readers that are not connected via USB interfaces. Solaris needs needs to provide support for media in these slots in a manner similar to how they are presented via USB. Writing a full block device driver is one possible way, but, unfortunately, it also means implementing a number of components besides the block driver itself, as various userland components exist (such as libsmedia) which only know how to talk to certain block devices. The sd(7d) device driver is the most common mass storage block driver, and it is also how most removable media is presented to the system. Therefore, it already has most of the hooks necessary to support userland volume management, format and VTOC management, etc. Unfortunately, sd(7d) expects to be able to talk to a SCSI disk. Busses such as USB and IEEE1394 often present mass storage using some subset of the SCSI command set, so combined with thin translation layers such as scsa1394 or scsa2usb, it is possible to emulate a SCSI bus sufficiently that these mass storage devices are usable with sd(7d). Many of the intersting media formats, however, do not use any form of SCSI command set. Sometimes the access method is quite different, even though the underlying media is still typically block-oriented. CHAPTER 2: blk2scsa translation layer Our solution to this problem involves the creation of a new kernel/misc module, blk2scsa. This module provides some straight-forward underlying APIs for block-oriented drivers to implement, and maps those APIs to an emulated SCSI bus and one or more emulated SCSI disk drives, so that these devices are now usable with sd(7d). This frees the block device driver from needing to implement most of the labeling, ioctl, or other complex portions of the block device and instead focus on just the core device access functionality. In a sample system, imagine a block device driver called "nvflash". This device driver has two independent flash chips per instance, each of which is block oriented using 512 byte blocks, and can have a separate filesystem on it. The plumbing might look like this: +----------+ | nvflash | | driver | | +----------+ +----------------+ +--------------+ +----+ blk2scsa |----> | (emulated bus) | -+---> | sd, target 0 | +----------+ +----------------+ | +--------------+ | | +--------------+ +---> | sd, target 1 | +--------------+ In the diagram above, the flash chips would be addressable as /dev/{rdsk,dsk}/cXt0d0 and /dev/{rdsk,dsk}/cXt1d0. Note that the actual flash chips could be removable (perhaps as if they were slots on a physical media reader), and the sd driver would handle them properly. This would include automatic volume manager support by userland components, so that when a device is inserted it is automatically mounted and presented in a desktop GNOME session, for example. The emulated HBA will support auto-sense-request (cannot be disabled), and emulated targets will support the removable and hotpluggable properties if they were registered with them. CHAPTER 3: Programming Interface ================================= The following API is provided for target devices. Basic setup ----------- The device driver shall #include The device driver shall add -N misc/blk2scsa to its link line, so that the run-time kernel loader can resolve the sybmols appropriately. Types ----- typedef struct b2s_hba b2s_hba_t; The b2s_hba_t structure is an opaque structure that is used as a handle to the emulated host bus adapter. typedef struct b2s_target b2s_target_t; The b2s_target_t structure is a handle to an emulated SCSI disk. It has the following accessible members: uint16_t target_number; void *target_private; const char *target_vendor; const char *target_product; const char *target_revision; const char *target_serial; uint32_t target_flags; boolean_t (*target_request)(void *, struct b2s_request *); The target_number field is the number to use for the emulated SCSI target. (For example, if target_number == 1, then the emulated disk will be addressed as cXt1d0.) Each target on an emulated HBA must have a unique number. The target_private field is available for the device driver's own use, and should point to per-target state. The target_vendor, target_product, target_revision, and target_serial fields are ASCIIZ strings used to identify the target. Note that this is for the target, and not for any removable media that may be present in the target. These strings are used to formulate the response to SCSI inquiries, so if the device driver is able to, it should use values that are suitable for SCSI-2. (See ANSI X3.131-1994 for more information.) The target_flags field can contain one of two flags: B2S_TARGET_FLAG_REMOVABLE - indicates that the target supports removable media B2S_TARGET_FLAG_HOTPLUGGABLE - indicates that the target can be hot plugged (including either removal or attachment.) The target_request field is the entry point that the device driver implements to handle I/O requests. It is passed target_private as its first argument. The second argument describes the request in further detail. If the driver handles the request (or queues it for handling), then it must return B_TRUE. If the driver is unwilling to accept the request, but a future attempt might be successful, then it should return B_FALSE. typedef struct b2s_request b2s_request_t; This structure is the fundamental handle used for tracking I/O requests between the SCSA layer and the device driver. It has the following accessible members: int br_cmd; uint64_t br_lba; uint64_t br_nblks; b2s_media_t br_media; uint32_t br_flags; The br_cmd field is the command code for the operation. See Commands below for a full explanation. This field is supplied by the blk2scsa. The br_lba field is the logical block address associated with the request. It will be supplied by the blk2scsa framework. It is only valid when the br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. The br_nblks is the number of logical blocks for the request. It will be supplied by the blk2scsa framework. It is only valid when the br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. The br_media field is a description of the media for the target. It is filled out by the driver in response to a B2S_CMD_GETMEDIA request. See the description of b2s_media_t below. The br_flags field is a bitfield of flags associated the request. The public flags, which are read-only supplied by the framework, are B2S_REQUEST_FLAG_POLL - indicates that a synchronous request without use of interrupts should be performed. (Such as when sync()'ing filesystems or performing a crash dump in response to a panic.) B2S_REQUEST_FLAG_HEAD - indicates that the request should be placed at the head of any queue, if possible. B2S_REQUEST_FLAG_LOAD_EJECT - only valid with the B2S_CMD_STOP or B2S_CMD_START commands, it indicates that the media should either be loaded (B2S_CMD_START) or ejected (B2S_CMD_STOP) if possible. B2S_REQUEST_FLAG_IMMED - if present, indicates that the driver should not wait for the operation to complete on the device before returning status with b2s_request_done(). It is only valid with the commands B2S_CMD_FORMAT, B2S_CMD_START, and B2S_CMD_STOP commands. typedef struct b2s_media b2s_media_t; This structure is used in response to B2S_CMD_GETMEDIA. The device driver shall supply information about the media in the following fields: uint64_t media_blksz; uint64_t media_nblks; uint64_t media_flags; The media_blksz and media_nblks fields are used to report the size and total number of logical blocks on the device. The media_flags bit field can have the flag B2S_MEDIA_FLAG_READ_ONLY set to indicate that the media loaded in the target is not writable. Functions --------- int b2s_hba_init(struct modlinkage *); int b2s_hba_fini(struct modlinkage *); These routines are called at _init and _fini respectively, to set up and clean up HBA related entries in the device driver's dev_ops field. As a consquence, a blk2scsa dependent driver need not supply any cb_ops or bus_ops structure on its own behalf. b2s_hba_t *b2s_alloc_hba(int version, dev_info_t *dip, ddi_dma_attr_t *attrp); This allocates an initial emulated HBA structure. The version field shall be set to B2S_VERSION_0. The dip should be the instance structure for the device (the first argument to attach(9e).) The attrp is a pointer to DMA attributes for the IO requests to the device. If the device cannot support DMA, then it shall use the value NULL for attrp. void b2s_free_hba(b2s_hba_t *); This frees an allocated, unattached emulated HBA structure. It will also implicitly free any targets that are still registered with the HBA. b2s_target_t *b2s_alloc_target(void); This allocates an empty target structure. The driver is responsible for populating the public members (see b2s_target_t in Types above), before registering it. void b2s_free_target(b2s_target_t *); This frees an unregistered target structure. int b2s_register_target(b2s_hba_t *hba, b2s_target_t *target); This registers the target with the HBA. If the HBA has been attached, this will appear to the system as an emulated hotplug attach of the disk. It returns DDI_SUCCESS on success, DDI_FAILURE otherwise. int b2s_unregister_target(b2s_target_t *target); This unregisters the target from the HBA. If the HBA is attached, then this will appear to the system as a hotplug removal of the disk. It returns DDI_SUCCESS on success, DDI_FAILURE otherwise. void b2s_request_mapin(b2s_request_t *req, caddr_t *addrp, size_t *lenp); This ensures that the buffer associated with the request is mapped into kernel address space, and returns the address and length of the buffer associated with the request. void b2s_request_dma(b2s_request_t *req, uint_t *num, ddi_dma_cookie_t **c); This returns the number of DMA cookies associated with the request, and a pointer to an array of the actual cookies. Note that requests are pre-mapped by the framework if a suitable DMA attribute was supplied at registration time. Note also that the buffer will always be fully mapped. That is, it will never be necessary for a driver to use ddi_dma_getwin(). void b2s_request_done(b2s_request_t *req, int errno, size_t resid); This is called by the driver when it has completed processing for a request. The errno takes an error code (see Error Codes below), and the resid indicates the number of residual bytes that were not transferred. int b2s_attach_hba(b2s_hba_t *); This attaches the HBA (and any registered targets) to the system. The target driver should call this as part of its attach(9e) processing. It return DDI_SUCCESS on success, DDI_FAILURE otherwise. int b2s_detach_hba(b2s_hba_t *); This detaches the HBA from the system. It returns DDI_SUCCESS on success, DDI_FAILURE otherwise. Commands -------- B2S_CMD_GETMEDIA This command is sent to the driver to retrieve a description of the media currently loaded. The driver shall provide the details in the br_media field of the associated request. B2S_CMD_START This command is used to initialize the device for use. If the B2S_REQUEST_FLAG_LOAD_EJECT is also present, then the device shall load any removable media, if possible. B2S_CMD_STOP This command is used to cease use of the device. (At this point the device may be powered down.) If the B2S_REQUEST_FLAG_LOAD_EJECT is present, then the device should attempt to eject any removable media. This command also implictly includes the effects of B2S_CMD_SYNC. B2S_CMD_LOCK B2S_CMD_UNLOCK These commands are used to engage or release any locking mechanism preventing removal of the media. B2S_CMD_READ B2S_CMD_WRITE These commands read or write blocks to/from the device. The block address to start at is indicated by the br_lba field of the request. The number of blocks to transfer is indicated by the br_nblks field. The actual data region can be determined using either the b2s_request_mapin() or b2s_request_dma() functions (depending on whether or not DMA is to be used.) B2S_CMD_FORMAT This command formats the media. It shall not be possible to format media while a reservation set with B2S_CMD_RESERVE is in effect. No defect list is supplied, so the driver is responsible to take whatever action it deems appropriate. If the B2S_REQUEST_FLAG_IMMED is set, then the device should not wait for the format to complete before calling b2s_request_done(). B2S_CMD_SYNC This command flushes any cached write data from the device to media. Errors ------ The following error codes can be returned in response to a request using b2s_request_done(). B2S_EOK No error. The operation completed successfully. B2S_ENOTSUP The device does not support the requested operation. (This should be returned, if the device does not have a door lock, for example.) B2S_EFORMATTING An attempt to access the device while it was formatting was made. B2S_ENOMEDIA No media is present in a target with removable media. B2S_EMEDIACHG The media may have changed since the last request was made. This is used to prevent accidental overwrites to changed media. B2S_ESTOPPED The target has not been started with B2S_CMD_START yet. B2S_EHARDWARE An unknown hardware error occurred. B2S_ENODEV The target is not present or has been removed. B2S_EMEDIA An error on the medium occurred. B2S_EDOORLOCK The B2S_CMD_STOP failed to eject the media, because the doorlock was engaged. B2S_EWPROTECT The media could not be written to because it is not writable. B2S_EBLKADDR The supplied LBA block address was invalid. B2S_ESTARTING The target is still starting up. Try agin later. B2S_EIO Generic failure. B2S_ERSVD Target reserved. (Internal use only.) B2S_EPARM Bad parameter occurred in the SCSI packet. (Internal use only.) B2S_EBADMSG Invalid SCSI message presented to driver. (Internal use only.) B2S_EINVAL An invalid parameter was present in the SCSI packet. (Internal use only.) CHAPER 4: Interface Table ========================== Imported Interface Level Comments SCSI-2 Committed ANSI X1.131-1994 scsi_hba_tran Committed SCSI HBA API scsi_pkt2bp() Consolidation Private Exported Interface Level Comments sys/scsi/adapters/blk2scsa.h Cons. Private blk2scsa header misc/blk2scsa Consolidation Private kernel module B2S_CMD_* Consolidation Private request command codes B2S_E* Consolidation Private request error codes B2S_REQUEST_FLAG_* Consolidation Private request flags B2S_VERSION_0 Consolidation Private API versioning struct b2s_request Consolidation Private request structure struct b2s_target Consolidation Private target structure struct b2s_hba Consolidation Private hba structure (opaque) struct b2s_media Consolidation Private media description b2s_alloc_hba() Consolidation Private HBA allocation b2s_free_hba() Consolidation Private HBA deallocation b2s_attach_hba() Consolidation Private HBA attachment b2s_detach_hba() Consolidation Private HBA detachment b2s_alloc_target() Consolidation Private target allocation b2s_free_target() Consolidation Private target deallocation b2s_target_register() Consolidation Private target registration b2s_target_unregister() Cons. Private target unregistration b2s_request_mapin() Consolidation Private request buffer PIO access b2s_request_dma() Consolidation Private request buffer DMA access b2s_request_done() Consolidation Private request buffer completion b2s_hba_init() Consolidation Private modlinkage initialization b2s_hba_fini() Condolidation Private modlinkage de-initialization 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Thu Nov 15 08:38:53 2007 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 lAFGcrCh002545 for ; Thu, 15 Nov 2007 08:38:53 -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 lAFGcoem003432 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 15 Nov 2007 08:38:53 -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 <0JRK00K0L3KSVU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 15 Nov 2007 09:38:52 -0700 (MST) 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 <0JRK00HW73KRK030@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 15 Nov 2007 09:38:51 -0700 (MST) 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 lAFGco7J028559 for ; Thu, 15 Nov 2007 08:38:51 -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 <0JRK00C013AQBU00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 15 Nov 2007 08:38:50 -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 <0JRK00GJJ3KM3X50@fe-sfbay-10.sun.com>; Thu, 15 Nov 2007 08:38:46 -0800 (PST) Date: Thu, 15 Nov 2007 08:34:25 -0800 From: "Garrett D'Amore" Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <473C7511.9040609@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 18593 I mis-stated the SCSI-2 standard number. It is X3.131-1994. It can be downloaded in PDF from this URL: http://www.t10.org/ftp/t10/drafts/s2/s2-r10l.pdf Hopefully it wasn't confusing to anyone. If it was, I apologize. -- Garrett Garrett D'Amore - sun microsystems wrote: > I'm submitting following fast-track on my own behalf. This may be straddling > the boundary of what can pass for a fast-track. If members feel that this > is deserving of a full review, please don't hesitate to derail it. (I won't > take it personally. :-) > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > blk2scsa > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 14 November, 2007 > 4. Technical Description > > Generic Block Device to SCSA Translation Layer > Functional Specification > > Garrett D'Amore (gdamore@sun.com) > Nov 13, 2007 > > > CHAPTER 1: Introduction > > There are an ever growing number of digital memory formats, as well as > other kinds of storage media in the market today. Historically, Solaris > has had only limited support for most of them, when connected through a > USB or IEEE 1394 media reader. > > Modern laptops and mobile computing devices are now shipping with slots > for these readers that are not connected via USB interfaces. Solaris needs > needs to provide support for media in these slots in a manner similar to > how they are presented via USB. > > Writing a full block device driver is one possible way, but, unfortunately, > it also means implementing a number of components besides the block > driver itself, as various userland components exist (such as libsmedia) > which only know how to talk to certain block devices. > > The sd(7d) device driver is the most common mass storage block driver, and > it is also how most removable media is presented to the system. Therefore, > it already has most of the hooks necessary to support userland volume > management, format and VTOC management, etc. > > Unfortunately, sd(7d) expects to be able to talk to a SCSI disk. Busses > such as USB and IEEE1394 often present mass storage using some subset of > the SCSI command set, so combined with thin translation layers such as > scsa1394 or scsa2usb, it is possible to emulate a SCSI bus sufficiently > that these mass storage devices are usable with sd(7d). > > Many of the intersting media formats, however, do not use any form of SCSI > command set. Sometimes the access method is quite different, even though > the underlying media is still typically block-oriented. > > > CHAPTER 2: blk2scsa translation layer > > Our solution to this problem involves the creation of a new kernel/misc > module, blk2scsa. This module provides some straight-forward underlying > APIs for block-oriented drivers to implement, and maps those APIs to an > emulated SCSI bus and one or more emulated SCSI disk drives, so that these > devices are now usable with sd(7d). > > This frees the block device driver from needing to implement most of the > labeling, ioctl, or other complex portions of the block device and instead > focus on just the core device access functionality. > > In a sample system, imagine a block device driver called "nvflash". This > device driver has two independent flash chips per instance, each of which > is block oriented using 512 byte blocks, and can have a separate filesystem > on it. The plumbing might look like this: > > > +----------+ > | nvflash | > | driver | > | +----------+ +----------------+ +--------------+ > +----+ blk2scsa |----> | (emulated bus) | -+---> | sd, target 0 | > +----------+ +----------------+ | +--------------+ > | > | +--------------+ > +---> | sd, target 1 | > +--------------+ > > In the diagram above, the flash chips would be addressable as > /dev/{rdsk,dsk}/cXt0d0 and /dev/{rdsk,dsk}/cXt1d0. > > Note that the actual flash chips could be removable (perhaps as if they > were slots on a physical media reader), and the sd driver would handle > them properly. This would include automatic volume manager support > by userland components, so that when a device is inserted it is automatically > mounted and presented in a desktop GNOME session, for example. > > The emulated HBA will support auto-sense-request (cannot be disabled), > and emulated targets will support the removable and hotpluggable properties > if they were registered with them. > > > CHAPTER 3: Programming Interface > ================================= > > The following API is provided for target devices. > > Basic setup > ----------- > > The device driver shall #include > > The device driver shall add -N misc/blk2scsa to its link line, so > that the run-time kernel loader can resolve the sybmols > appropriately. > > > Types > ----- > > typedef struct b2s_hba b2s_hba_t; > > The b2s_hba_t structure is an opaque structure that is used as a handle > to the emulated host bus adapter. > > typedef struct b2s_target b2s_target_t; > > The b2s_target_t structure is a handle to an emulated SCSI disk. It > has the following accessible members: > > uint16_t target_number; > void *target_private; > const char *target_vendor; > const char *target_product; > const char *target_revision; > const char *target_serial; > uint32_t target_flags; > boolean_t (*target_request)(void *, struct b2s_request *); > > The target_number field is the number to use for the emulated SCSI target. > (For example, if target_number == 1, then the emulated disk will be > addressed as cXt1d0.) Each target on an emulated HBA must have a unique > number. > > The target_private field is available for the device driver's own > use, and should point to per-target state. > > The target_vendor, target_product, target_revision, and target_serial > fields are ASCIIZ strings used to identify the target. Note that this > is for the target, and not for any removable media that may be present > in the target. These strings are used to formulate the response to > SCSI inquiries, so if the device driver is able to, it should use > values that are suitable for SCSI-2. (See ANSI X3.131-1994 for more > information.) > > The target_flags field can contain one of two flags: > > B2S_TARGET_FLAG_REMOVABLE - indicates that the target supports removable > media > > B2S_TARGET_FLAG_HOTPLUGGABLE - indicates that the target can be hot > plugged (including either removal or attachment.) > > The target_request field is the entry point that the device driver implements > to handle I/O requests. It is passed target_private as its first argument. > The second argument describes the request in further detail. If the driver > handles the request (or queues it for handling), then it must return > B_TRUE. If the driver is unwilling to accept the request, but a future > attempt might be successful, then it should return B_FALSE. > > typedef struct b2s_request b2s_request_t; > > This structure is the fundamental handle used for tracking I/O requests > between the SCSA layer and the device driver. It has the following > accessible members: > > int br_cmd; > uint64_t br_lba; > uint64_t br_nblks; > b2s_media_t br_media; > uint32_t br_flags; > > The br_cmd field is the command code for the operation. See Commands > below for a full explanation. This field is supplied by the blk2scsa. > > The br_lba field is the logical block address associated with the request. > It will be supplied by the blk2scsa framework. It is only valid when the > br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. > > The br_nblks is the number of logical blocks for the request. It will be > supplied by the blk2scsa framework. It is only valid when the br_cmd field > is B2S_CMD_READ or B2S_CMD_WRITE. > > The br_media field is a description of the media for the target. It is > filled out by the driver in response to a B2S_CMD_GETMEDIA request. > See the description of b2s_media_t below. > > The br_flags field is a bitfield of flags associated the request. The > public flags, which are read-only supplied by the framework, are > > B2S_REQUEST_FLAG_POLL - indicates that a synchronous request without > use of interrupts should be performed. (Such as when sync()'ing > filesystems or performing a crash dump in response to a panic.) > > B2S_REQUEST_FLAG_HEAD - indicates that the request should be placed at > the head of any queue, if possible. > > B2S_REQUEST_FLAG_LOAD_EJECT - only valid with the B2S_CMD_STOP or > B2S_CMD_START commands, it indicates that the media should either be > loaded (B2S_CMD_START) or ejected (B2S_CMD_STOP) if possible. > > B2S_REQUEST_FLAG_IMMED - if present, indicates that the driver should > not wait for the operation to complete on the device before returning > status with b2s_request_done(). It is only valid with the commands > B2S_CMD_FORMAT, B2S_CMD_START, and B2S_CMD_STOP commands. > > typedef struct b2s_media b2s_media_t; > > This structure is used in response to B2S_CMD_GETMEDIA. The device driver > shall supply information about the media in the following fields: > > uint64_t media_blksz; > uint64_t media_nblks; > uint64_t media_flags; > > The media_blksz and media_nblks fields are used to report the size and total > number of logical blocks on the device. > > The media_flags bit field can have the flag B2S_MEDIA_FLAG_READ_ONLY set to > indicate that the media loaded in the target is not writable. > > > Functions > --------- > > int b2s_hba_init(struct modlinkage *); > int b2s_hba_fini(struct modlinkage *); > > These routines are called at _init and _fini respectively, to set up > and clean up HBA related entries in the device driver's dev_ops field. > As a consquence, a blk2scsa dependent driver need not supply any cb_ops > or bus_ops structure on its own behalf. > > b2s_hba_t *b2s_alloc_hba(int version, dev_info_t *dip, ddi_dma_attr_t *attrp); > > This allocates an initial emulated HBA structure. The version field > shall be set to B2S_VERSION_0. The dip should be the instance > structure for the device (the first argument to attach(9e).) The > attrp is a pointer to DMA attributes for the IO requests to the > device. If the device cannot support DMA, then it shall use the > value NULL for attrp. > > void b2s_free_hba(b2s_hba_t *); > > This frees an allocated, unattached emulated HBA structure. It will > also implicitly free any targets that are still registered with the HBA. > > b2s_target_t *b2s_alloc_target(void); > > This allocates an empty target structure. The driver is responsible > for populating the public members (see b2s_target_t in Types above), > before registering it. > > void b2s_free_target(b2s_target_t *); > > This frees an unregistered target structure. > > int b2s_register_target(b2s_hba_t *hba, b2s_target_t *target); > > This registers the target with the HBA. If the HBA has been attached, > this will appear to the system as an emulated hotplug attach of the > disk. It returns DDI_SUCCESS on success, DDI_FAILURE otherwise. > > int b2s_unregister_target(b2s_target_t *target); > > This unregisters the target from the HBA. If the HBA is attached, > then this will appear to the system as a hotplug removal of the disk. > It returns DDI_SUCCESS on success, DDI_FAILURE otherwise. > > void b2s_request_mapin(b2s_request_t *req, caddr_t *addrp, size_t *lenp); > > This ensures that the buffer associated with the request is mapped into > kernel address space, and returns the address and length of the buffer > associated with the request. > > void b2s_request_dma(b2s_request_t *req, uint_t *num, ddi_dma_cookie_t **c); > > This returns the number of DMA cookies associated with the request, and > a pointer to an array of the actual cookies. Note that requests are > pre-mapped by the framework if a suitable DMA attribute was supplied at > registration time. Note also that the buffer will always be fully mapped. > That is, it will never be necessary for a driver to use ddi_dma_getwin(). > > void b2s_request_done(b2s_request_t *req, int errno, size_t resid); > > This is called by the driver when it has completed processing for a request. > The errno takes an error code (see Error Codes below), and the resid > indicates the number of residual bytes that were not transferred. > > int b2s_attach_hba(b2s_hba_t *); > > This attaches the HBA (and any registered targets) to the system. The > target driver should call this as part of its attach(9e) processing. It > return DDI_SUCCESS on success, DDI_FAILURE otherwise. > > int b2s_detach_hba(b2s_hba_t *); > > This detaches the HBA from the system. It returns DDI_SUCCESS on success, > DDI_FAILURE otherwise. > > > Commands > -------- > > B2S_CMD_GETMEDIA > > This command is sent to the driver to retrieve a description of the > media currently loaded. The driver shall provide the details in the > br_media field of the associated request. > > B2S_CMD_START > > This command is used to initialize the device for use. If the > B2S_REQUEST_FLAG_LOAD_EJECT is also present, then the device shall > load any removable media, if possible. > > B2S_CMD_STOP > > This command is used to cease use of the device. (At this point the > device may be powered down.) If the B2S_REQUEST_FLAG_LOAD_EJECT is > present, then the device should attempt to eject any removable media. > This command also implictly includes the effects of B2S_CMD_SYNC. > > B2S_CMD_LOCK > B2S_CMD_UNLOCK > > These commands are used to engage or release any locking mechanism > preventing removal of the media. > > B2S_CMD_READ > B2S_CMD_WRITE > > These commands read or write blocks to/from the device. The block address > to start at is indicated by the br_lba field of the request. The number > of blocks to transfer is indicated by the br_nblks field. The actual > data region can be determined using either the b2s_request_mapin() or > b2s_request_dma() functions (depending on whether or not DMA is to be used.) > > B2S_CMD_FORMAT > > This command formats the media. It shall not be possible to format media > while a reservation set with B2S_CMD_RESERVE is in effect. No defect > list is supplied, so the driver is responsible to take whatever action > it deems appropriate. If the B2S_REQUEST_FLAG_IMMED is set, then the > device should not wait for the format to complete before calling > b2s_request_done(). > > B2S_CMD_SYNC > > This command flushes any cached write data from the device to media. > > > Errors > ------ > > The following error codes can be returned in response to a request using > b2s_request_done(). > > B2S_EOK > > No error. The operation completed successfully. > > B2S_ENOTSUP > > The device does not support the requested operation. (This should be > returned, if the device does not have a door lock, for example.) > > B2S_EFORMATTING > > An attempt to access the device while it was formatting was made. > > B2S_ENOMEDIA > > No media is present in a target with removable media. > > B2S_EMEDIACHG > > The media may have changed since the last request was made. This is > used to prevent accidental overwrites to changed media. > > B2S_ESTOPPED > > The target has not been started with B2S_CMD_START yet. > > B2S_EHARDWARE > > An unknown hardware error occurred. > > B2S_ENODEV > > The target is not present or has been removed. > > B2S_EMEDIA > > An error on the medium occurred. > > B2S_EDOORLOCK > > The B2S_CMD_STOP failed to eject the media, because the doorlock was > engaged. > > B2S_EWPROTECT > > The media could not be written to because it is not writable. > > B2S_EBLKADDR > > The supplied LBA block address was invalid. > > B2S_ESTARTING > > The target is still starting up. Try agin later. > > B2S_EIO > > Generic failure. > > B2S_ERSVD > > Target reserved. (Internal use only.) > > B2S_EPARM > > Bad parameter occurred in the SCSI packet. (Internal use only.) > > B2S_EBADMSG > > Invalid SCSI message presented to driver. (Internal use only.) > > B2S_EINVAL > > An invalid parameter was present in the SCSI packet. (Internal use only.) > > > CHAPER 4: Interface Table > ========================== > > Imported Interface Level Comments > > SCSI-2 Committed ANSI X1.131-1994 > scsi_hba_tran Committed SCSI HBA API > scsi_pkt2bp() Consolidation Private > > > Exported Interface Level Comments > > sys/scsi/adapters/blk2scsa.h Cons. Private blk2scsa header > > misc/blk2scsa Consolidation Private kernel module > B2S_CMD_* Consolidation Private request command codes > B2S_E* Consolidation Private request error codes > B2S_REQUEST_FLAG_* Consolidation Private request flags > B2S_VERSION_0 Consolidation Private API versioning > > struct b2s_request Consolidation Private request structure > struct b2s_target Consolidation Private target structure > struct b2s_hba Consolidation Private hba structure (opaque) > struct b2s_media Consolidation Private media description > > b2s_alloc_hba() Consolidation Private HBA allocation > b2s_free_hba() Consolidation Private HBA deallocation > b2s_attach_hba() Consolidation Private HBA attachment > b2s_detach_hba() Consolidation Private HBA detachment > > b2s_alloc_target() Consolidation Private target allocation > b2s_free_target() Consolidation Private target deallocation > b2s_target_register() Consolidation Private target registration > b2s_target_unregister() Cons. Private target unregistration > > b2s_request_mapin() Consolidation Private request buffer PIO access > b2s_request_dma() Consolidation Private request buffer DMA access > b2s_request_done() Consolidation Private request buffer completion > > b2s_hba_init() Consolidation Private modlinkage initialization > b2s_hba_fini() Condolidation Private modlinkage de-initialization > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From cyril.plisko@gmail.com Sat Nov 17 06:25:25 2007 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 lAHEPOd8001393 for ; Sat, 17 Nov 2007 06:25:24 -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 lAHEPLGE000337 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 22:25:23 +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 <0JRN00207MQ9T000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 06:25:21 -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 <0JRN00NLJMQ80RB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 06:25:21 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAHEPKUc005977 for ; Sat, 17 Nov 2007 14:25:20 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay14i.sun.com with ESMTP id BT-MMP-239507 for PSARC-ext@sun.com; Sat, 17 Nov 2007 14:25:20 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.sun.com with ESMTP id BT-MMP-225802 for PSARC-ext@sun.com; Sat, 17 Nov 2007 14:25:20 +0000 (Z) Received: from py-out-1112.google.com ([64.233.166.182] [64.233.166.182]) by relay1i.sun.com with ESMTP id BT-MMP-746990 for PSARC-ext@sun.com; Sat, 17 Nov 2007 14:25:19 +0000 (Z) Received: by py-out-1112.google.com with SMTP id a25so5306223pyi for ; Sat, 17 Nov 2007 06:25:16 -0800 (PST) Received: by 10.142.215.5 with SMTP id n5mr826416wfg.1195309515225; Sat, 17 Nov 2007 06:25:15 -0800 (PST) Received: by 10.142.170.18 with HTTP; Sat, 17 Nov 2007 06:25:15 -0800 (PST) Date: Sat, 17 Nov 2007 16:25:15 +0200 From: Cyril Plisko Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> Sender: cyril.plisko@gmail.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=A2kmxHXpmRgr33uaVEebtY1MHtlzD5VHbKAC5wnDCPg=; b=lQlbEDfsK0aiBIE0m5soTmLahRko8QhCjvwAq1tgAsCgzqlgTw3vTS8tQ8ENhTU05uHzISSyXMRi2rEx1v1zFEnxOPKWjJzVVSBcp9uxpWvFl5TGHn89/C2JhNA2gHvAhN7IYsMJ+DznCJXQrvtW2xUbiu7Jaa1yD5BCN/ByCRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=KsBwF1deHoNIByKiJJeXJVAiR6jmPgL82WvQYbwo7bEidvidUTyfnQD/6p7mNDATokzXsY0NoJtJzKbe8vZvBbvRS9Dif+G0vl40cwXqPrf0k6Cb7EkTM/kIbv7hJKFmtbZD1SFfx30kLYRo2yAMYZp7zdcGzBukH0x5PHq2CmI= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 52c30e2fef539236 References: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> Status: RO Content-Length: 824 On Nov 14, 2007 7:46 PM, Garrett D'Amore - sun microsystems wrote: > > The b2s_target_t structure is a handle to an emulated SCSI disk. It > has the following accessible members: > > uint16_t target_number; > void *target_private; > const char *target_vendor; > const char *target_product; > const char *target_revision; > const char *target_serial; > uint32_t target_flags; > boolean_t (*target_request)(void *, struct b2s_request *); > Garrett, Provided that this module aims to be generic, how easy will it be to add support for protocol revisions beyond SCSI-2 ? I think that single target_request() callback may not be robust enough in case such functionality addition will be required. -- Regards, Cyril From gdamore@sun.com Sat Nov 17 10:43:38 2007 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 lAHIhbX3010611 for ; Sat, 17 Nov 2007 10:43:37 -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.7/ENSMAIL,v2.2) with ESMTP id lAHIhYdx005886 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 18:43:36 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 <0JRN00H01YONWG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 10:43:35 -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 <0JRN003MMYONZV70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 10:43:35 -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 lAHIhYpg023731 for ; Sat, 17 Nov 2007 10:43:34 -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 <0JRN00801YJZNW00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 10:43:34 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRN001ZDYOKT8D0@fe-sfbay-09.sun.com>; Sat, 17 Nov 2007 10:43:33 -0800 (PST) Date: Sat, 17 Nov 2007 10:39:05 -0800 From: "Garrett D'Amore" Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: Sender: Garrett.Damore@sun.com To: Cyril Plisko Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <473F3549.4020408@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 2017 Cyril Plisko wrote: > On Nov 14, 2007 7:46 PM, Garrett D'Amore - sun microsystems > wrote: > > >> The b2s_target_t structure is a handle to an emulated SCSI disk. It >> has the following accessible members: >> >> uint16_t target_number; >> void *target_private; >> const char *target_vendor; >> const char *target_product; >> const char *target_revision; >> const char *target_serial; >> uint32_t target_flags; >> boolean_t (*target_request)(void *, struct b2s_request *); >> >> > > Garrett, > > Provided that this module aims to be generic, how easy will it > be to add support for protocol revisions beyond SCSI-2 ? > Its generic for a certain class of application... that is block device support. I don't think it will be too difficult to extend to other kinds of block oriented mass storage. (I'm already thinking about using it for other kinds of flash media, such as xD, etc. I think it could be used today for the pcram module as well.) > I think that single target_request() callback may not be robust > enough in case such functionality addition will be required. > I think it would be straight-forward to add other SCSI protocol extensions. I assume you're thinking about mode-sense/select, vital product data, log sense, and maybe even media serial number requests. For those cases I think target_request() is extensible enough. The reason for this is that the b2s_request_t structure is dynamically allocated and thus easily extensible. So it can carry other kinds of fields, the same that it carries br_media today. (In fact, br_media is already a member of a union. I think this does point out to me one thing, which is that I should make sure that the union is the last member of the br_request_t.... so I need to move br_flags in front of it.) Is there some other kind of exchange you perceive where you think this br_request is insufficient? -- Garrett From gdamore@sun.com Sat Nov 17 10:48:01 2007 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 lAHIm0V9010650 for ; Sat, 17 Nov 2007 10:48:01 -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.7/ENSMAIL,v2.2) with ESMTP id lAHIm0vd007478 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 18:48:00 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 <0JRN00K01YVZTZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 11:47:59 -0700 (MST) 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 <0JRN00FOLYVY7610@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 11:47:58 -0700 (MST) 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 lAHIlwBY023763 for ; Sat, 17 Nov 2007 10:47:58 -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 <0JRN00801YJZNW00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Nov 2007 10:47:58 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRN001BJYVYT8E0@fe-sfbay-09.sun.com>; Sat, 17 Nov 2007 10:47:58 -0800 (PST) Date: Sat, 17 Nov 2007 10:43:30 -0800 From: "Garrett D'Amore" Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <473F3549.4020408@sun.com> Sender: Garrett.Damore@sun.com To: Cyril Plisko Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <473F3652.50200@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> <473F3549.4020408@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 2317 I also am going to add two new status codes, B2S_ENOMEM and B2S_ETIMEDOUT. These are used as you would expect, when a request cannot complete due to insufficient memory or timing out. -- Garrett Garrett D'Amore wrote: > Cyril Plisko wrote: >> On Nov 14, 2007 7:46 PM, Garrett D'Amore - sun microsystems >> wrote: >> >> >>> The b2s_target_t structure is a handle to an emulated SCSI disk. It >>> has the following accessible members: >>> >>> uint16_t target_number; >>> void *target_private; >>> const char *target_vendor; >>> const char *target_product; >>> const char *target_revision; >>> const char *target_serial; >>> uint32_t target_flags; >>> boolean_t (*target_request)(void *, struct b2s_request *); >>> >>> >> >> Garrett, >> >> Provided that this module aims to be generic, how easy will it >> be to add support for protocol revisions beyond SCSI-2 ? >> > > Its generic for a certain class of application... that is block device > support. I don't think it will be too difficult to extend to other > kinds of block oriented mass storage. (I'm already thinking about > using it for other kinds of flash media, such as xD, etc. I think it > could be used today for the pcram module as well.) > >> I think that single target_request() callback may not be robust >> enough in case such functionality addition will be required. >> > > I think it would be straight-forward to add other SCSI protocol > extensions. I assume you're thinking about mode-sense/select, vital > product data, log sense, and maybe even media serial number requests. > > For those cases I think target_request() is extensible enough. The > reason for this is that the b2s_request_t structure is dynamically > allocated and thus easily extensible. So it can carry other kinds of > fields, the same that it carries br_media today. (In fact, br_media > is already a member of a union. I think this does point out to me one > thing, which is that I should make sure that the union is the last > member of the br_request_t.... so I need to move br_flags in front of > it.) > > Is there some other kind of exchange you perceive where you think this > br_request is insufficient? > > -- Garrett > From Artem.Kachitchkin@sun.com Sat Nov 17 11:14:50 2007 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 lAHJEnnL012072 for ; Sat, 17 Nov 2007 11:14:49 -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 lAHJEl3r002466 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 18 Nov 2007 03:14:48 +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 <0JRO00N0704M0900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 12:14:46 -0700 (MST) 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 <0JRO00FDJ04M7620@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 12:14:46 -0700 (MST) 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 lAHJEk0x024148 for ; Sat, 17 Nov 2007 11:14:46 -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 <0JRN00001ZTGQY00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 11:14:46 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRO00K0Y04LA7C0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 11:14:46 -0800 (PST) Date: Sat, 17 Nov 2007 11:13:39 -0800 From: Artem Kachitchkine Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> Sender: Artem.Kachitchkin@sun.com To: Garrett.Damore@sun.com Cc: PSARC-ext@sun.com Message-id: <473F3D63.8010109@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 123 > Commands > -------- Does this command set translate into sufficient sd(7D) functionality to be used with ZFS? -Artem From gdamore@sun.com Sat Nov 17 11:38:44 2007 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 lAHJciYU012847 for ; Sat, 17 Nov 2007 11:38:44 -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.7/ENSMAIL,v2.2) with ESMTP id lAHJcgLv023803 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 19:38:43 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 <0JRO0020118I3700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 12:38:42 -0700 (MST) 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 <0JRO00FL918I7G20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 12:38:42 -0700 (MST) 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 lAHJcgpY024489 for ; Sat, 17 Nov 2007 11:38:42 -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 <0JRO00G0114YZ700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 11:38:42 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRO00C9D18HUS20@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 11:38:42 -0800 (PST) Date: Sat, 17 Nov 2007 11:34:14 -0800 From: "Garrett D'Amore" Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <473F3D63.8010109@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <473F4236.10606@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> <473F3D63.8010109@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 859 Artem Kachitchkine wrote: > >> Commands >> -------- > > Does this command set translate into sufficient sd(7D) functionality > to be used with ZFS? > > -Artem I'm not sure about ZFS, but it is good enough for sd(7D) with PCFS. One possible area of concern for ZFS is device id functionality. The devices I'm dealing with don't have device identifiers that live within the SCSI namespace. (Generally they do have a vendor id, product id, and serial number... but these are allocated from an entirely different namespace.) If someone familiar with any specific requirements of ZFS on sd(7D) can speak up, I'd be grateful. Btw, I'm looking into supporting mode-sense. (I need it to report write-protected media back to sd(7D).) But I think I can do that without requiring any additional support from the core blk2scsa target API. -- Garrett From Artem.Kachitchkin@sun.com Sat Nov 17 14:10:55 2007 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 lAHMAsEQ016524 for ; Sat, 17 Nov 2007 14:10:55 -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.7/ENSMAIL,v2.2) with ESMTP id lAHMAqi3012492 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 22:10:53 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 <0JRO006018A54900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 14:10:53 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRO003PE8A4ZXC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 14:10:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAHMAqGJ001163 for ; Sat, 17 Nov 2007 14:10:52 -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 <0JRO00E01867QN00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 14:10:52 -0800 (PST) Received: from [129.150.17.9] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRO00CKV89XUSC0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 14:10:52 -0800 (PST) Date: Sat, 17 Nov 2007 14:09:38 -0800 From: Artem Kachitchkine Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <473F4236.10606@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <473F66A2.3070501@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> <473F3D63.8010109@sun.com> <473F4236.10606@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 988 > I'm not sure about ZFS, but it is good enough for sd(7D) with PCFS. IMO the proposal is incomplete without a clear statement about ZFS, even it it's "unsupported", though I really hope for the opposite: USB storage is the dumbest storage I've ever encountered (so far), yet you can put ZFS on it. I think the only sure way is to try. Given that the estimated engineering effort for this entire project is 1 engineer-week, I suppose it'd take a couple more days to figure this out. > One possible area of concern for ZFS is device id functionality. The > devices I'm dealing with don't have device identifiers that live within > the SCSI namespace. (Generally they do have a vendor id, product id, > and serial number... but these are allocated from an entirely different > namespace.) AFAIK in that case a fabricated devid will be stored in the hidden area of the disk. The same problem exists with USB, see "6422928 devid support is needed for usb harddisk". -Artem From gdamore@Sun.COM Sat Nov 17 21:15:53 2007 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 lAI5Frxd002529 for ; Sat, 17 Nov 2007 21:15:53 -0800 (PST) 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 lAI5Fr3Z025785 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 21:15:53 -0800 (PST) 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 <0JRO00K05RYH2L00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:15:53 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRO00400RYEUQF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:15:50 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAI5FoH4007745 for ; Sat, 17 Nov 2007 21:15:50 -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 <0JRO00H01RYDS600@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:15:50 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRO00AOHRYDGYC0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:15:49 -0800 (PST) Date: Sat, 17 Nov 2007 21:11:20 -0800 From: "Garrett D'Amore" Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <473F66A2.3070501@sun.com> Sender: Garrett.Damore@Sun.COM To: Artem Kachitchkine Cc: Garrett.Damore@Sun.COM, PSARC-ext@Sun.COM Message-id: <473FC978.5010306@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> <473F3D63.8010109@sun.com> <473F4236.10606@sun.com> <473F66A2.3070501@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1454 Artem Kachitchkine wrote: > >> I'm not sure about ZFS, but it is good enough for sd(7D) with PCFS. > > IMO the proposal is incomplete without a clear statement about ZFS, > even it it's "unsupported", though I really hope for the opposite: USB > storage is the dumbest storage I've ever encountered (so far), yet you > can put ZFS on it. > > I think the only sure way is to try. Given that the estimated > engineering effort for this entire project is 1 engineer-week, I > suppose it'd take a couple more days to figure this out. Yes, I intend to try it out. I'm not specifically targetting ZFS, but I can't see why it wouldn't work, other than the device id concern raised below. > >> One possible area of concern for ZFS is device id functionality. The >> devices I'm dealing with don't have device identifiers that live >> within the SCSI namespace. (Generally they do have a vendor id, >> product id, and serial number... but these are allocated from an >> entirely different namespace.) > > AFAIK in that case a fabricated devid will be stored in the hidden > area of the disk. The same problem exists with USB, see "6422928 devid > support is needed for usb harddisk". If I read the code in sd correctly, this won't be done for removable media. So while it isn't a problem for the blk2scsa framework, it is a problem for SDcard media. Its possible that I'll need to figure out a solution here, I'm not sure. -- Garrett From Artem.Kachitchkin@sun.com Sat Nov 17 21:37:29 2007 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 lAI5bT3f002584 for ; Sat, 17 Nov 2007 21:37:29 -0800 (PST) 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 lAI5bS6t002340 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 21:37:29 -0800 (PST) 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 <0JRO0000NSYG3A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:37:28 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRO00LGMSYE2110@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:37:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAI5bQOg008073 for ; Sat, 17 Nov 2007 21:37:26 -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 <0JRO00J01SWBSD00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:37:26 -0800 (PST) Received: from [129.150.16.97] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRO00ATRSYDGYD0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 21:37:26 -0800 (PST) Date: Sat, 17 Nov 2007 21:36:16 -0800 From: Artem Kachitchkine Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <473FC978.5010306@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <473FCF50.8000300@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> <473F3D63.8010109@sun.com> <473F4236.10606@sun.com> <473F66A2.3070501@sun.com> <473FC978.5010306@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 283 > Yes, I intend to try it out. Great. > I'm not specifically targetting ZFS, but I > can't see why it wouldn't work, other than the device id concern raised > below. Another vector to keep an eye on, wrt ZFS, is write cache (6424510 usb ignores DKIOCFLUSHWRITECACHE). -Artem From gdamore@sun.com Sat Nov 17 22:37:39 2007 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 lAI6bcjo003149 for ; Sat, 17 Nov 2007 22:37:39 -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.7/ENSMAIL,v2.2) with ESMTP id lAI6bb32007733 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 18 Nov 2007 06:37:37 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 <0JRO00A0DVQOP600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 23:37:36 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRO00HN9VQNP470@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 23:37:35 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAI6bZ58008925 for ; Sat, 17 Nov 2007 22:37:35 -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 <0JRO00F01V9O8E00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 22:37:35 -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 <0JRO008A6VQMU4C0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 17 Nov 2007 22:37:34 -0800 (PST) Date: Sat, 17 Nov 2007 22:33:05 -0800 From: "Garrett D'Amore" Subject: Re: blk2scsa [PSARC/2007/654 FastTrack timeout 11/21/2007] In-reply-to: <473FCF50.8000300@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <473FDCA1.6050703@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: <200711141746.lAEHkSFf005895@sac.sfbay.sun.com> <473F3D63.8010109@sun.com> <473F4236.10606@sun.com> <473F66A2.3070501@sun.com> <473FC978.5010306@sun.com> <473FCF50.8000300@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 745 Artem Kachitchkine wrote: > >> Yes, I intend to try it out. > > Great. > >> I'm not specifically targetting ZFS, but I can't see why it wouldn't >> work, other than the device id concern raised below. > > Another vector to keep an eye on, wrt ZFS, is write cache (6424510 usb > ignores DKIOCFLUSHWRITECACHE). So does SDcard, but that is only because it has no cache. I added the B2S_CMD_SYNC command in my original proposal for flushing out cache, but I'm starting to wonder if that is too simplistic... SCSI can enable/disable various cache tuning parameters. Maybe I need to support that. Possibly later, if some device that has write cache ever shows up. As I said, right now I don't have it, so its a non-issue. -- Garrett From gdamore@sun.com Tue Nov 27 00:55:06 2007 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 lAR8t5Xv007107 for ; Tue, 27 Nov 2007 00:55:06 -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 lAR8skgO017154 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Nov 2007 08:55: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 <0JS50050JQ3RMO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 00:55:04 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS5006MBQ3R3D60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 00:55:03 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAR8t30U022029 for ; Tue, 27 Nov 2007 00:55:03 -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 <0JS500101Q1XOY00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 00:55:03 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS5008ZRQ3R9UE0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 00:55:03 -0800 (PST) Date: Tue, 27 Nov 2007 00:50:09 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/654 blk2scsa spec change Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <474BDA41.5060301@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 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 19717 I've found in the course of trying to add support for hotplug properly to the blk2scsa driver, that some changes to the API were necessary. While here, I made some other aesthetic changes which are easy to do now, but would require more annoying casework later. A full updated spec is attached. The main differences here relative to the first spec are: * b2s_hba renamed to b2s_nexus * b2s_target renamed to b2s_leaf * structure passed for nexus allocation, instead of array of pointers * request entry point associated with nexus structure instead of leaf * addition of target and lun members to request structure * support for non-zero lun numbers (multiple luns per target) * inquiry data now handled via separate request command, rather than at registration * no separate allocation/deallocation for leaf structure, done by leaf attach/detach automatically (possibly deferred for hotplug safety). I'm extending the case timer another week to allow for the extra review required. Sorry, for the late changes, but thanks! Generic Block Device to SCSA Translation Layer Functional Specification Garrett D'Amore (gdamore@sun.com) Nov 27, 2007 CHAPTER 1: Introduction There are an ever growing number of digital memory formats, as well as other kinds of storage media in the market today. Historically, Solaris has had only limited support for most of them, when connected through a USB or IEEE 1394 media reader. Modern laptops and mobile computing devices are now shipping with slots for these readers that are not connected via USB interfaces. Solaris needs needs to provide support for media in these slots in a manner similar to how they are presented via USB. Writing a full block device driver is one possible way, but, unfortunately, it also means implementing a number of components besides the block driver itself, as various userland components exist (such as libsmedia) which only know how to talk to certain block devices. The sd(7d) device driver is the most common mass storage block driver, and it is also how most removable media is presented to the system. Therefore, it already has most of the hooks necessary to support userland volume management, format and VTOC management, etc. Unfortunately, sd(7d) expects to be able to talk to a SCSI disk. Busses such as USB and IEEE1394 often present mass storage using some subset of the SCSI command set, so combined with thin translation layers such as scsa1394 or scsa2usb, it is possible to emulate a SCSI bus sufficiently that these mass storage devices are usable with sd(7d). Many of the intersting media formats, however, do not use any form of SCSI command set. Sometimes the access method is quite different, even though the underlying media is still typically block-oriented. CHAPTER 2: blk2scsa translation layer Our solution to this problem involves the creation of a new kernel/misc module, blk2scsa. This module provides some straight-forward underlying APIs for block-oriented drivers to implement, and maps those APIs to an emulated SCSI bus and one or more emulated SCSI disk drives, so that these devices are now usable with sd(7d). This frees the block device driver from needing to implement most of the labeling, ioctl, or other complex portions of the block device and instead focus on just the core device access functionality. In a sample system, imagine a block device driver called "nvflash". This device driver has two independent flash chips per instance, each of which is block oriented using 512 byte blocks, and can have a separate filesystem on it. The plumbing might look like this: +----------+ | nvflash | | driver | | +----------+ +----------------+ +--------------+ +----+ blk2scsa |----> | (emulated bus) | -+---> | sd, target 0 | +----------+ +----------------+ | +--------------+ | | +--------------+ +---> | sd, target 1 | +--------------+ In the diagram above, the flash chips would be addressable as /dev/{rdsk,dsk}/cXt0d0 and /dev/{rdsk,dsk}/cXt1d0. Note that the actual flash chips could be removable (perhaps as if they were slots on a physical media reader), and the sd driver would handle them properly. This would include automatic volume manager support by userland components, so that when a device is inserted it is automatically mounted and presented in a desktop GNOME session, for example. The emulated HBA will support auto-sense-request (cannot be disabled), and emulated targets will support the removable and hotpluggable properties if they were registered with them. CHAPTER 3: Programming Interface ================================= The following API is provided for target devices. Basic setup ----------- The device driver shall #include The device driver shall add -N misc/blk2scsa to its link line, so that the run-time kernel loader can resolve the sybmols appropriately. Types ----- typedef struct b2s_nexus b2s_nexus_t; The b2s_nexus_t structure is an opaque structure that is used as a handle to the emulated host bus adapter. typedef struct b2s_leaf b2s_leaf_t; The b2s_leaf_t structure is an opaque structure that is used as a handle to the emulated disk device. typedef struct b2s_nexus_info b2s_nexus_info_t; The b2s_nexus_info structure describes the nexus device that should be allocated. It has the following members: int nexus_version; dev_info_t *nexus_dip; void *nexus_private; ddi_dma_attr_t *nexus_dma_attr; boolean_t (*nexus_request)(void *, struct b2s_request *); The nexus_version field is used for versioning, and represents the version of the API that the device driver is coded for. It must be B2S_VERSION_0 in this specification. The nexus_dip is the device node associated with the driver. The nexus_private field is available for the device driver's own use, and should point to nexus state. The nexus_dma_attr is the DMA attributes describing the DMA capabilities of the driver. It may be NULL if the driver is incapable of DMA. The nexus_request field is the entry point that the device driver implements to handle I/O requests. It is passed nexus_private as its first argument. The second argument describes the request in further detail. If the driver handles the request (or queues it for handling), then it must return B_TRUE. If the driver is unwilling to accept the request, but a future attempt might be successful, then it should return B_FALSE. Please see the description for b2s_request_t below. typedef b2s_leaf_info b2s_leaf_info_t; The b2s_leaf_info structure describes a leaf device (emulated SCSI disk) that should be attached to the system. It has the following members: uint_t leaf_target; uint_t leaf_lun; uint32_t leaf_flags; const char *leaf_unique_id; uint32_t target_flags; boolean_t (*target_request)(void *, struct b2s_request *); The leaf_target and leaf_lun fields are target and lun numbers to use for the emulated SCSI target. (For example, the disk device node /dev/dsk/cXtYdZs2, the leaf_target is represented by Y, and the leaf_lun is represented by Z.) The combination of these two fields must be unique for a given leaf node. The leaf_unique_id field is an ASCIIZ string containing a string that uniquely identifies the device. The system uses this to protect against incorrect hotplug operations. (I.e. insertion of a different leaf target at the specified SCSI address, while the previous leaf was still open by another consumer.) It may be used in the formulation of device identifiers and GUIDs as well. The leaf_flags field can contain one of two flags: B2S_LEAF_REMOVABLE - indicates that the leaf supports removable media B2S_LEAF_HOTPLUGGABLE - indicates that the leaf can be hot plugged (including either removal or attachment.) typedef struct b2s_request b2s_request_t; This structure is the fundamental handle used for tracking I/O requests between the SCSA layer and the device driver. It has the following accessible members: int br_cmd; uint64_t br_lba; uint64_t br_nblks; b2s_media_t br_media; b2s_inquiry_t br_inquiry; uint32_t br_flags; The br_cmd field is the command code for the operation. See Commands below for a full explanation. This field is supplied by the blk2scsa. The br_lba field is the logical block address associated with the request. It will be supplied by the blk2scsa framework. It is only valid when the br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. The br_nblks is the number of logical blocks for the request. It will be supplied by the blk2scsa framework. It is only valid when the br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. The br_media field is a description of the media for the target. It is filled out by the driver in response to a B2S_CMD_GETMEDIA request. See the description of b2s_media_t below. The br_inquiry field contains inquiry data for the target, to be filled out by the device driver in response to a B2S_CMD_INQUIRY request. See the description of b2s_inquiry_t below. The br_flags field is a bitfield of flags associated the request. The public flags, which are read-only supplied by the framework, are B2S_REQUEST_FLAG_POLL - indicates that a synchronous request without use of interrupts should be performed. (Such as when sync()'ing filesystems or performing a crash dump in response to a panic.) B2S_REQUEST_FLAG_HEAD - indicates that the request should be placed at the head of any queue, if possible. B2S_REQUEST_FLAG_LOAD_EJECT - only valid with the B2S_CMD_STOP or B2S_CMD_START commands, it indicates that the media should either be loaded (B2S_CMD_START) or ejected (B2S_CMD_STOP) if possible. B2S_REQUEST_FLAG_IMMED - if present, indicates that the driver should not wait for the operation to complete on the device before returning status with b2s_request_done(). It is only valid with the commands B2S_CMD_FORMAT, B2S_CMD_START, and B2S_CMD_STOP commands. typedef struct b2s_media b2s_media_t; This structure is used in response to B2S_CMD_GETMEDIA. The device driver shall supply information about the media in the following fields: uint64_t media_blksz; uint64_t media_nblks; uint64_t media_flags; The media_blksz and media_nblks fields are used to report the size and total number of logical blocks on the device. The media_flags bit field can have the flag B2S_MEDIA_FLAG_READ_ONLY set to indicate that the media loaded in the target is not writable. typedef struct b2s_inquiry b2s_inquiry_t; This structure is used in rsponse to B2S_CMD_INQUIRY. The device driver shall set the following fields for data to include in a standard SCSI inquiry: const char *inq_vendor; const char *inq_product; const char *inq_revision; const char *inq_serial; The inq_vendor, inq_product, inq_revision, and inq_serial fields are ASCIIZ strings used to identify the device. Note that this is for the target, and not for any removable media that may be present in the target. These strings are used to formulate the response to SCSI inquiries, so if the device driver is able to, it should use values that are suitable for SCSI-2. (See ANSI X3.131-1994 for more information.) Note that the driver need not pad these strings with spaces. Functions --------- int b2s_mod_init(struct modlinkage *); int b2s_mod_fini(struct modlinkage *); These routines are called at _init and _fini respectively, to set up and clean up HBA related entries in the device driver's dev_ops field. As a consquence, a blk2scsa dependent driver need not supply any cb_ops or bus_ops structure on its own behalf. b2s_nexus_t *b2s_alloc_nexus(b2s_nexus_info_t *); This allocates an initial emulated HBA structure, using the supplied information. void b2s_free_nexus(b2s_nexus_t *); This frees an unattached emulated HBA structure. b2s_leaf_t *b2s_attach_leaf(b2s_nexus_t *, b2s_leaf_info_t *); This indicates that a leaf (disk) device has been physically attached to the nexus (HBA). Appropriate hotplug actions will be performed to make the device accessible, if possible. It returns an opaque handle to the leaf on success, or NULL on failure. void b2s_detach_leaf(b2s_leaf_t *leaf); This indicates that a leaf device has been physically detached from the nexus, and exists solely to support hotplug operation. void b2s_request_mapin(b2s_request_t *req, caddr_t *addrp, size_t *lenp); This ensures that the buffer associated with the request is mapped into kernel address space, and returns the address and length of the buffer associated with the request. void b2s_request_dma(b2s_request_t *req, uint_t *num, ddi_dma_cookie_t **c); This returns the number of DMA cookies associated with the request, and a pointer to an array of the actual cookies. Note that requests are pre-mapped by the framework if a suitable DMA attribute was supplied at registration time. Note also that the buffer will always be fully mapped. That is, it will never be necessary for a driver to use ddi_dma_getwin(). void b2s_request_done(b2s_request_t *req, int errno, size_t resid); This is called by the driver when it has completed processing for a request. The errno takes an error code (see Error Codes below), and the resid indicates the number of residual bytes that were not transferred. int b2s_attach_nexus(b2s_nexus_t *); This attaches the HBA (and any registered leaves) to the system. The target driver should call this as part of its attach(9e) processing. It return DDI_SUCCESS on success, DDI_FAILURE otherwise. int b2s_detach_nexus(b2s_nexus_t *); This detaches the HBA from the system. It returns DDI_SUCCESS on success, DDI_FAILURE otherwise. Commands -------- B2S_CMD_INQUIRY This command is sent to the driver to retrieve a description of the device in response to a SCSI inquiry. The driver shall provide the details in the br_inquiry field of the associated request. B2S_CMD_GETMEDIA This command is sent to the driver to retrieve a description of the media currently loaded. The driver shall provide the details in the br_media field of the associated request. B2S_CMD_START This command is used to initialize the device for use. If the B2S_REQUEST_FLAG_LOAD_EJECT is also present, then the device shall load any removable media, if possible. B2S_CMD_STOP This command is used to cease use of the device. (At this point the device may be powered down.) If the B2S_REQUEST_FLAG_LOAD_EJECT is present, then the device should attempt to eject any removable media. This command also implictly includes the effects of B2S_CMD_SYNC. B2S_CMD_LOCK B2S_CMD_UNLOCK These commands are used to engage or release any locking mechanism preventing removal of the media. B2S_CMD_READ B2S_CMD_WRITE These commands read or write blocks to/from the device. The block address to start at is indicated by the br_lba field of the request. The number of blocks to transfer is indicated by the br_nblks field. The actual data region can be determined using either the b2s_request_mapin() or b2s_request_dma() functions (depending on whether or not DMA is to be used.) B2S_CMD_FORMAT This command formats the media. It shall not be possible to format media while a reservation set with B2S_CMD_RESERVE is in effect. No defect list is supplied, so the driver is responsible to take whatever action it deems appropriate. If the B2S_REQUEST_FLAG_IMMED is set, then the device should not wait for the format to complete before calling b2s_request_done(). B2S_CMD_SYNC This command flushes any cached write data from the device to media. Errors ------ The following error codes can be returned in response to a request using b2s_request_done(). B2S_EOK No error. The operation completed successfully. B2S_ENOTSUP The device does not support the requested operation. (This should be returned, if the device does not have a door lock, for example.) B2S_EFORMATTING An attempt to access the device while it was formatting was made. B2S_ENOMEDIA No media is present in a target with removable media. B2S_EMEDIACHG The media may have changed since the last request was made. This is used to prevent accidental overwrites to changed media. B2S_ESTOPPED The target has not been started with B2S_CMD_START yet. B2S_EHARDWARE An unknown hardware error occurred. B2S_ENODEV The target is not present or has been removed. B2S_EMEDIA An error on the medium occurred. B2S_EDOORLOCK The B2S_CMD_STOP failed to eject the media, because the doorlock was engaged. B2S_EWPROTECT The media could not be written to because it is not writable. B2S_EBLKADDR The supplied LBA block address was invalid. B2S_ESTARTING The target is still starting up. Try agin later. B2S_EIO Generic failure. B2S_ERSVD Target reserved. (Internal use only.) B2S_EPARM Bad parameter occurred in the SCSI packet. (Internal use only.) B2S_EBADMSG Invalid SCSI message presented to driver. (Internal use only.) B2S_EINVAL An invalid parameter was present in the SCSI packet. (Internal use only.) CHAPER 4: Interface Table ========================== Imported Interface Level Comments SCSI-2 Committed ANSI X1.131-1994 scsi_hba_tran Committed SCSI HBA API scsi_pkt2bp() Consolidation Private Exported Interface Level Comments sys/scsi/adapters/blk2scsa.h Cons. Private blk2scsa header misc/blk2scsa Consolidation Private kernel module B2S_CMD_* Consolidation Private request command codes B2S_E* Consolidation Private request error codes B2S_REQUEST_FLAG_* Consolidation Private request flags B2S_VERSION_0 Consolidation Private API versioning struct b2s_request Consolidation Private request structure struct b2s_leaf Consolidation Private leaf (disk) structure (opaque) struct b2s_nexus Consolidation Private nexus (hba) structure (opaque) struct b2s_leaf_info Consolidation Private leaf (disk) attach information struct b2s_nexus_info Consolidation Private nexus (hba) registration struct b2s_media Consolidation Private media description struct b2s_inquiry Consolidation Private SCSI inquiry data b2s_alloc_nexus() Consolidation Private nexus (hba) allocation b2s_free_nexus() Consolidation Private nexus (hba) deallocation b2s_attach_nexus() Consolidation Private nexus (hba) attachment b2s_detach_nexus() Consolidation Private nexus (hba) detachment b2s_attach_leaf() Consolidation Private leaf (disk) connection b2s_detach_leaf() Consolidation Private leaf (disk) disconnection b2s_request_mapin() Consolidation Private request buffer PIO access b2s_request_dma() Consolidation Private request buffer DMA access b2s_request_done() Consolidation Private request buffer completion b2s_mod_init() Consolidation Private modlinkage initialization b2s_mod_fini() Condolidation Private modlinkage de-initialization From edward.pilatowicz@sun.com Tue Nov 27 13:55:02 2007 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 lARLt0FL022211 for ; Tue, 27 Nov 2007 13:55:01 -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 lARLsqx4010101; Wed, 28 Nov 2007 05:54:56 +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 <0JS600J1NQ7IB100@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Nov 2007 13:54:54 -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 <0JS6000HUQ7G9M60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Nov 2007 13:54:52 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lARLsq3u171343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 13:54:52 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id lARLsq5p171342; Tue, 27 Nov 2007 13:54:52 -0800 (PST) Date: Tue, 27 Nov 2007 13:54:52 -0800 From: Edward Pilatowicz Subject: Re: PSARC 2007/654 blk2scsa spec change In-reply-to: <474BDA41.5060301@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <20071127215452.GI795073@eng.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: <474BDA41.5060301@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 20796 will the /devices/ paths for blk2scsa devices use generic names or will the /devices paths contain driver names? an example of a generic name (for a usb disk device) is: /devices/pci@0,0/pci104d,81e6@1d,7/storage@3/disk@0,0:g an example of a non-generic name (for an ata disk device) is: /devices/pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0:h ed On Tue, Nov 27, 2007 at 12:50:09AM -0800, Garrett D'Amore wrote: > I've found in the course of trying to add support for hotplug properly > to the blk2scsa driver, that some changes to the API were necessary. > While here, I made some other aesthetic changes which are easy to do > now, but would require more annoying casework later. > > A full updated spec is attached. > > The main differences here relative to the first spec are: > > * b2s_hba renamed to b2s_nexus > * b2s_target renamed to b2s_leaf > * structure passed for nexus allocation, instead of array of pointers > * request entry point associated with nexus structure instead of leaf > * addition of target and lun members to request structure > * support for non-zero lun numbers (multiple luns per target) > * inquiry data now handled via separate request command, rather than at > registration > * no separate allocation/deallocation for leaf structure, done by leaf > attach/detach automatically (possibly deferred for hotplug safety). > > I'm extending the case timer another week to allow for the extra review > required. Sorry, for the late changes, but thanks! > > > Generic Block Device to SCSA Translation Layer > Functional Specification > > Garrett D'Amore (gdamore@sun.com) > Nov 27, 2007 > > > CHAPTER 1: Introduction > > There are an ever growing number of digital memory formats, as well as > other kinds of storage media in the market today. Historically, Solaris > has had only limited support for most of them, when connected through a > USB or IEEE 1394 media reader. > > Modern laptops and mobile computing devices are now shipping with slots > for these readers that are not connected via USB interfaces. Solaris needs > needs to provide support for media in these slots in a manner similar to > how they are presented via USB. > > Writing a full block device driver is one possible way, but, unfortunately, > it also means implementing a number of components besides the block > driver itself, as various userland components exist (such as libsmedia) > which only know how to talk to certain block devices. > > The sd(7d) device driver is the most common mass storage block driver, and > it is also how most removable media is presented to the system. Therefore, > it already has most of the hooks necessary to support userland volume > management, format and VTOC management, etc. > > Unfortunately, sd(7d) expects to be able to talk to a SCSI disk. Busses > such as USB and IEEE1394 often present mass storage using some subset of > the SCSI command set, so combined with thin translation layers such as > scsa1394 or scsa2usb, it is possible to emulate a SCSI bus sufficiently > that these mass storage devices are usable with sd(7d). > > Many of the intersting media formats, however, do not use any form of SCSI > command set. Sometimes the access method is quite different, even though > the underlying media is still typically block-oriented. > > > CHAPTER 2: blk2scsa translation layer > > Our solution to this problem involves the creation of a new kernel/misc > module, blk2scsa. This module provides some straight-forward underlying > APIs for block-oriented drivers to implement, and maps those APIs to an > emulated SCSI bus and one or more emulated SCSI disk drives, so that these > devices are now usable with sd(7d). > > This frees the block device driver from needing to implement most of the > labeling, ioctl, or other complex portions of the block device and instead > focus on just the core device access functionality. > > In a sample system, imagine a block device driver called "nvflash". This > device driver has two independent flash chips per instance, each of which > is block oriented using 512 byte blocks, and can have a separate filesystem > on it. The plumbing might look like this: > > > +----------+ > | nvflash | > | driver | > | +----------+ +----------------+ +--------------+ > +----+ blk2scsa |----> | (emulated bus) | -+---> | sd, target 0 | > +----------+ +----------------+ | +--------------+ > | > | +--------------+ > +---> | sd, target 1 | > +--------------+ > > In the diagram above, the flash chips would be addressable as > /dev/{rdsk,dsk}/cXt0d0 and /dev/{rdsk,dsk}/cXt1d0. > > Note that the actual flash chips could be removable (perhaps as if they > were slots on a physical media reader), and the sd driver would handle > them properly. This would include automatic volume manager support > by userland components, so that when a device is inserted it is > automatically > mounted and presented in a desktop GNOME session, for example. > > The emulated HBA will support auto-sense-request (cannot be disabled), > and emulated targets will support the removable and hotpluggable properties > if they were registered with them. > > > CHAPTER 3: Programming Interface > ================================= > > The following API is provided for target devices. > > Basic setup > ----------- > > The device driver shall #include > > The device driver shall add -N misc/blk2scsa to its link line, so > that the run-time kernel loader can resolve the sybmols > appropriately. > > > Types > ----- > > typedef struct b2s_nexus b2s_nexus_t; > > The b2s_nexus_t structure is an opaque structure that is used as a handle > to the emulated host bus adapter. > > typedef struct b2s_leaf b2s_leaf_t; > > The b2s_leaf_t structure is an opaque structure that is used as a handle > to the emulated disk device. > > typedef struct b2s_nexus_info b2s_nexus_info_t; > > The b2s_nexus_info structure describes the nexus device that should be > allocated. It has the following members: > > int nexus_version; > dev_info_t *nexus_dip; > void *nexus_private; > ddi_dma_attr_t *nexus_dma_attr; > boolean_t (*nexus_request)(void *, struct b2s_request *); > > The nexus_version field is used for versioning, and represents the version > of the API that the device driver is coded for. It must be B2S_VERSION_0 > in this specification. > > The nexus_dip is the device node associated with the driver. > > The nexus_private field is available for the device driver's own > use, and should point to nexus state. > > The nexus_dma_attr is the DMA attributes describing the DMA > capabilities of > the driver. It may be NULL if the driver is incapable of DMA. > > The nexus_request field is the entry point that the device driver > implements > to handle I/O requests. It is passed nexus_private as its first argument. > The second argument describes the request in further detail. If the > driver > handles the request (or queues it for handling), then it must return > B_TRUE. If the driver is unwilling to accept the request, but a future > attempt might be successful, then it should return B_FALSE. Please see > the description for b2s_request_t below. > > typedef b2s_leaf_info b2s_leaf_info_t; > > The b2s_leaf_info structure describes a leaf device (emulated SCSI > disk) that should be attached to the system. It has the following > members: > > uint_t leaf_target; > uint_t leaf_lun; > uint32_t leaf_flags; > const char *leaf_unique_id; > > uint32_t target_flags; > boolean_t (*target_request)(void *, struct b2s_request *); > > The leaf_target and leaf_lun fields are target and lun numbers to > use for the emulated SCSI target. (For example, the disk device node > /dev/dsk/cXtYdZs2, the leaf_target is represented by Y, and the leaf_lun > is represented by Z.) The combination of these two fields must be unique > for a given leaf node. > > The leaf_unique_id field is an ASCIIZ string containing a string that > uniquely identifies the device. The system uses this to protect against > incorrect hotplug operations. (I.e. insertion of a different leaf target > at the specified SCSI address, while the previous leaf was still open > by another consumer.) It may be used in the formulation of device > identifiers and GUIDs as well. > > The leaf_flags field can contain one of two flags: > > B2S_LEAF_REMOVABLE - indicates that the leaf supports removable > media > > B2S_LEAF_HOTPLUGGABLE - indicates that the leaf can be hot > plugged (including either removal or attachment.) > > typedef struct b2s_request b2s_request_t; > > This structure is the fundamental handle used for tracking I/O requests > between the SCSA layer and the device driver. It has the following > accessible members: > > int br_cmd; > uint64_t br_lba; > uint64_t br_nblks; > b2s_media_t br_media; > b2s_inquiry_t br_inquiry; > uint32_t br_flags; > > The br_cmd field is the command code for the operation. See Commands > below for a full explanation. This field is supplied by the blk2scsa. > > The br_lba field is the logical block address associated with the request. > It will be supplied by the blk2scsa framework. It is only valid when the > br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. > > The br_nblks is the number of logical blocks for the request. It will be > supplied by the blk2scsa framework. It is only valid when the br_cmd > field > is B2S_CMD_READ or B2S_CMD_WRITE. > > The br_media field is a description of the media for the target. It is > filled out by the driver in response to a B2S_CMD_GETMEDIA request. > See the description of b2s_media_t below. > > > The br_inquiry field contains inquiry data for the target, to be filled > out by the device driver in response to a B2S_CMD_INQUIRY request. > See the description of b2s_inquiry_t below. > > The br_flags field is a bitfield of flags associated the request. The > public flags, which are read-only supplied by the framework, are > > B2S_REQUEST_FLAG_POLL - indicates that a synchronous request without > use of interrupts should be performed. (Such as when sync()'ing > filesystems or performing a crash dump in response to a panic.) > > B2S_REQUEST_FLAG_HEAD - indicates that the request should be placed at > the head of any queue, if possible. > > B2S_REQUEST_FLAG_LOAD_EJECT - only valid with the B2S_CMD_STOP or > B2S_CMD_START commands, it indicates that the media should either be > loaded (B2S_CMD_START) or ejected (B2S_CMD_STOP) if possible. > > B2S_REQUEST_FLAG_IMMED - if present, indicates that the driver should > not wait for the operation to complete on the device before returning > status with b2s_request_done(). It is only valid with the commands > B2S_CMD_FORMAT, B2S_CMD_START, and B2S_CMD_STOP commands. > > typedef struct b2s_media b2s_media_t; > > This structure is used in response to B2S_CMD_GETMEDIA. The device driver > shall supply information about the media in the following fields: > > uint64_t media_blksz; > uint64_t media_nblks; > uint64_t media_flags; > > The media_blksz and media_nblks fields are used to report the size and > total > number of logical blocks on the device. > > The media_flags bit field can have the flag B2S_MEDIA_FLAG_READ_ONLY > set to > indicate that the media loaded in the target is not writable. > > typedef struct b2s_inquiry b2s_inquiry_t; > > This structure is used in rsponse to B2S_CMD_INQUIRY. The device driver > shall set the following fields for data to include in a standard SCSI > inquiry: > > const char *inq_vendor; > const char *inq_product; > const char *inq_revision; > const char *inq_serial; > > The inq_vendor, inq_product, inq_revision, and inq_serial > fields are ASCIIZ strings used to identify the device. Note that this > is for the target, and not for any removable media that may be present > in the target. These strings are used to formulate the response to > SCSI inquiries, so if the device driver is able to, it should use > values that are suitable for SCSI-2. (See ANSI X3.131-1994 for more > information.) Note that the driver need not pad these strings with > spaces. > > > Functions > --------- > > int b2s_mod_init(struct modlinkage *); > int b2s_mod_fini(struct modlinkage *); > > These routines are called at _init and _fini respectively, to set up > and clean up HBA related entries in the device driver's dev_ops field. > As a consquence, a blk2scsa dependent driver need not supply any cb_ops > or bus_ops structure on its own behalf. > > b2s_nexus_t *b2s_alloc_nexus(b2s_nexus_info_t *); > > This allocates an initial emulated HBA structure, using the supplied > information. > > void b2s_free_nexus(b2s_nexus_t *); > > This frees an unattached emulated HBA structure. > > b2s_leaf_t *b2s_attach_leaf(b2s_nexus_t *, b2s_leaf_info_t *); > > This indicates that a leaf (disk) device has been physically > attached to the nexus (HBA). Appropriate hotplug actions will be > performed to make the device accessible, if possible. It returns > an opaque handle to the leaf on success, or NULL on failure. > > void b2s_detach_leaf(b2s_leaf_t *leaf); > > This indicates that a leaf device has been physically detached from > the nexus, and exists solely to support hotplug operation. > > void b2s_request_mapin(b2s_request_t *req, caddr_t *addrp, size_t *lenp); > > This ensures that the buffer associated with the request is mapped into > kernel address space, and returns the address and length of the buffer > associated with the request. > > void b2s_request_dma(b2s_request_t *req, uint_t *num, ddi_dma_cookie_t **c); > > This returns the number of DMA cookies associated with the request, and > a pointer to an array of the actual cookies. Note that requests are > pre-mapped by the framework if a suitable DMA attribute was supplied at > registration time. Note also that the buffer will always be fully mapped. > That is, it will never be necessary for a driver to use ddi_dma_getwin(). > > void b2s_request_done(b2s_request_t *req, int errno, size_t resid); > > This is called by the driver when it has completed processing for a > request. > The errno takes an error code (see Error Codes below), and the resid > indicates the number of residual bytes that were not transferred. > > int b2s_attach_nexus(b2s_nexus_t *); > > This attaches the HBA (and any registered leaves) to the system. The > target driver should call this as part of its attach(9e) processing. It > return DDI_SUCCESS on success, DDI_FAILURE otherwise. > > int b2s_detach_nexus(b2s_nexus_t *); > > This detaches the HBA from the system. It returns DDI_SUCCESS on success, > DDI_FAILURE otherwise. > > > Commands > -------- > > B2S_CMD_INQUIRY > > This command is sent to the driver to retrieve a description of the > device in response to a SCSI inquiry. The driver shall provide the > details > in the br_inquiry field of the associated request. > > B2S_CMD_GETMEDIA > > This command is sent to the driver to retrieve a description of the > media currently loaded. The driver shall provide the details in the > br_media field of the associated request. > > B2S_CMD_START > > This command is used to initialize the device for use. If the > B2S_REQUEST_FLAG_LOAD_EJECT is also present, then the device shall > load any removable media, if possible. > > B2S_CMD_STOP > > This command is used to cease use of the device. (At this point the > device may be powered down.) If the B2S_REQUEST_FLAG_LOAD_EJECT is > present, then the device should attempt to eject any removable media. > This command also implictly includes the effects of B2S_CMD_SYNC. > > B2S_CMD_LOCK > B2S_CMD_UNLOCK > > These commands are used to engage or release any locking mechanism > preventing removal of the media. > > B2S_CMD_READ > B2S_CMD_WRITE > > These commands read or write blocks to/from the device. The block address > to start at is indicated by the br_lba field of the request. The number > of blocks to transfer is indicated by the br_nblks field. The actual > data region can be determined using either the b2s_request_mapin() or > b2s_request_dma() functions (depending on whether or not DMA is to be > used.) > > B2S_CMD_FORMAT > > This command formats the media. It shall not be possible to format media > while a reservation set with B2S_CMD_RESERVE is in effect. No defect > list is supplied, so the driver is responsible to take whatever action > it deems appropriate. If the B2S_REQUEST_FLAG_IMMED is set, then the > device should not wait for the format to complete before calling > b2s_request_done(). > > B2S_CMD_SYNC > > This command flushes any cached write data from the device to media. > > > Errors > ------ > > The following error codes can be returned in response to a request using > b2s_request_done(). > > B2S_EOK > > No error. The operation completed successfully. > > B2S_ENOTSUP > > The device does not support the requested operation. (This should be > returned, if the device does not have a door lock, for example.) > > B2S_EFORMATTING > > An attempt to access the device while it was formatting was made. > > B2S_ENOMEDIA > > No media is present in a target with removable media. > > B2S_EMEDIACHG > > The media may have changed since the last request was made. This is > used to prevent accidental overwrites to changed media. > > B2S_ESTOPPED > > The target has not been started with B2S_CMD_START yet. > > B2S_EHARDWARE > > An unknown hardware error occurred. > > B2S_ENODEV > > The target is not present or has been removed. > > B2S_EMEDIA > > An error on the medium occurred. > > B2S_EDOORLOCK > > The B2S_CMD_STOP failed to eject the media, because the doorlock was > engaged. > > B2S_EWPROTECT > > The media could not be written to because it is not writable. > > B2S_EBLKADDR > > The supplied LBA block address was invalid. > > B2S_ESTARTING > > The target is still starting up. Try agin later. > > B2S_EIO > > Generic failure. > > B2S_ERSVD > > Target reserved. (Internal use only.) > > B2S_EPARM > > Bad parameter occurred in the SCSI packet. (Internal use only.) > > B2S_EBADMSG > > Invalid SCSI message presented to driver. (Internal use only.) > > B2S_EINVAL > > An invalid parameter was present in the SCSI packet. (Internal use only.) > > > CHAPER 4: Interface Table > ========================== > > Imported Interface Level Comments > > SCSI-2 Committed ANSI X1.131-1994 > scsi_hba_tran Committed SCSI HBA API > scsi_pkt2bp() Consolidation Private > > > Exported Interface Level Comments > > sys/scsi/adapters/blk2scsa.h Cons. Private blk2scsa header > > misc/blk2scsa Consolidation Private kernel module > B2S_CMD_* Consolidation Private request command codes > B2S_E* Consolidation Private request error codes > B2S_REQUEST_FLAG_* Consolidation Private request flags > B2S_VERSION_0 Consolidation Private API versioning > > struct b2s_request Consolidation Private request structure > struct b2s_leaf Consolidation Private leaf (disk) structure (opaque) > struct b2s_nexus Consolidation Private nexus (hba) structure > (opaque) > struct b2s_leaf_info Consolidation Private leaf (disk) attach > information > struct b2s_nexus_info Consolidation Private nexus (hba) registration > struct b2s_media Consolidation Private media description > struct b2s_inquiry Consolidation Private SCSI inquiry data > > b2s_alloc_nexus() Consolidation Private nexus (hba) allocation > b2s_free_nexus() Consolidation Private nexus (hba) deallocation > b2s_attach_nexus() Consolidation Private nexus (hba) attachment > b2s_detach_nexus() Consolidation Private nexus (hba) detachment > > b2s_attach_leaf() Consolidation Private leaf (disk) connection > b2s_detach_leaf() Consolidation Private leaf (disk) disconnection > > b2s_request_mapin() Consolidation Private request buffer PIO access > b2s_request_dma() Consolidation Private request buffer DMA access > b2s_request_done() Consolidation Private request buffer completion > > b2s_mod_init() Consolidation Private modlinkage initialization > b2s_mod_fini() Condolidation Private modlinkage de-initialization From Artem.Kachitchkin@sun.com Tue Nov 27 19:20:47 2007 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 lAS3KlgK006494 for ; Tue, 27 Nov 2007 19:20:47 -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 lAS3Kijk026840 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 03:20:45 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 <0JS700K035AJLV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:20:43 -0700 (MST) 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 <0JS7008RS5AIE7E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:20:43 -0700 (MST) 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 lAS3KgUQ019751 for ; Tue, 27 Nov 2007 19:20:42 -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 <0JS700F0157SQW00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 19:20:42 -0800 (PST) Received: from [129.150.21.179] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS7003RD5AIDOE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 19:20:42 -0800 (PST) Date: Tue, 27 Nov 2007 19:18:47 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2007/654 blk2scsa spec change In-reply-to: <474BDA41.5060301@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <474CDE17.3020009@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: <474BDA41.5060301@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 39 Any update on that pesky ZFS? -Artem From gdamore@sun.com Tue Nov 27 20:46:07 2007 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 lAS4k4uU007601 for ; Tue, 27 Nov 2007 20:46:06 -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 lAS4jvLu003905 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 12:46:04 +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 <0JS700L0598RAS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:46:03 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS700JMM98QLHD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:46:02 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAS4k2BO000484 for ; Tue, 27 Nov 2007 20:46:02 -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 <0JS700M0198L9W00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:46:02 -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 <0JS700JX498Q4SA0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:46:02 -0800 (PST) Date: Tue, 27 Nov 2007 20:41:05 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/654 blk2scsa spec change In-reply-to: <474CDE17.3020009@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: PSARC-ext@sun.com Message-id: <474CF161.9070204@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: <474BDA41.5060301@sun.com> <474CDE17.3020009@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 267 Artem Kachitchkine wrote: > > Any update on that pesky ZFS? > > -Artem Not yet. I have been loathe to clobber my PCFS partition on my SD card during testing (because then I have no way to easily recreate it), but I think I'll try it out tomorrow. -- Garrett From gdamore@sun.com Tue Nov 27 20:49:00 2007 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 lAS4mwDF007620 for ; Tue, 27 Nov 2007 20:48:59 -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 lAS4mta5004842 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 12:48:58 +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 <0JS700L019DKT900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:48:56 -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 <0JS700JEX9DKLFF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:48:56 -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 lAS4mtCJ022173 for ; Tue, 27 Nov 2007 20:48:55 -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 <0JS700A0199PE700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:48:55 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS700L199DJ81F0@fe-sfbay-09.sun.com>; Tue, 27 Nov 2007 20:48:55 -0800 (PST) Date: Tue, 27 Nov 2007 20:43:58 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/654 blk2scsa spec change In-reply-to: <20071127215452.GI795073@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: PSARC-ext@sun.com Message-id: <474CF20E.7040800@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: <474BDA41.5060301@sun.com> <20071127215452.GI795073@eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 21931 Edward Pilatowicz wrote: > will the /devices/ paths for blk2scsa devices use generic names > or will the /devices paths contain driver names? > > an example of a generic name (for a usb disk device) is: > /devices/pci@0,0/pci104d,81e6@1d,7/storage@3/disk@0,0:g > > an example of a non-generic name (for an ata disk device) is: > /devices/pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0:h > The portion of the path that blk2scsa controls will use generic names. Actually, I'm using scsi_hba_nodename_compatible_get() to generate both the nodename and the compatible names. (Originally I started out with just "disk" for the node name and "sd" for the compatible name hardcoded, but a comment from Joerg Schilling convinced me that it might be better to offer the other SCSI bindings so that folks could associate a driver other than "sd" with a blk2scsa device if they really wanted to.) -- Garrett > ed > > On Tue, Nov 27, 2007 at 12:50:09AM -0800, Garrett D'Amore wrote: > >> I've found in the course of trying to add support for hotplug properly >> to the blk2scsa driver, that some changes to the API were necessary. >> While here, I made some other aesthetic changes which are easy to do >> now, but would require more annoying casework later. >> >> A full updated spec is attached. >> >> The main differences here relative to the first spec are: >> >> * b2s_hba renamed to b2s_nexus >> * b2s_target renamed to b2s_leaf >> * structure passed for nexus allocation, instead of array of pointers >> * request entry point associated with nexus structure instead of leaf >> * addition of target and lun members to request structure >> * support for non-zero lun numbers (multiple luns per target) >> * inquiry data now handled via separate request command, rather than at >> registration >> * no separate allocation/deallocation for leaf structure, done by leaf >> attach/detach automatically (possibly deferred for hotplug safety). >> >> I'm extending the case timer another week to allow for the extra review >> required. Sorry, for the late changes, but thanks! >> >> >> Generic Block Device to SCSA Translation Layer >> Functional Specification >> >> Garrett D'Amore (gdamore@sun.com) >> Nov 27, 2007 >> >> >> CHAPTER 1: Introduction >> >> There are an ever growing number of digital memory formats, as well as >> other kinds of storage media in the market today. Historically, Solaris >> has had only limited support for most of them, when connected through a >> USB or IEEE 1394 media reader. >> >> Modern laptops and mobile computing devices are now shipping with slots >> for these readers that are not connected via USB interfaces. Solaris needs >> needs to provide support for media in these slots in a manner similar to >> how they are presented via USB. >> >> Writing a full block device driver is one possible way, but, unfortunately, >> it also means implementing a number of components besides the block >> driver itself, as various userland components exist (such as libsmedia) >> which only know how to talk to certain block devices. >> >> The sd(7d) device driver is the most common mass storage block driver, and >> it is also how most removable media is presented to the system. Therefore, >> it already has most of the hooks necessary to support userland volume >> management, format and VTOC management, etc. >> >> Unfortunately, sd(7d) expects to be able to talk to a SCSI disk. Busses >> such as USB and IEEE1394 often present mass storage using some subset of >> the SCSI command set, so combined with thin translation layers such as >> scsa1394 or scsa2usb, it is possible to emulate a SCSI bus sufficiently >> that these mass storage devices are usable with sd(7d). >> >> Many of the intersting media formats, however, do not use any form of SCSI >> command set. Sometimes the access method is quite different, even though >> the underlying media is still typically block-oriented. >> >> >> CHAPTER 2: blk2scsa translation layer >> >> Our solution to this problem involves the creation of a new kernel/misc >> module, blk2scsa. This module provides some straight-forward underlying >> APIs for block-oriented drivers to implement, and maps those APIs to an >> emulated SCSI bus and one or more emulated SCSI disk drives, so that these >> devices are now usable with sd(7d). >> >> This frees the block device driver from needing to implement most of the >> labeling, ioctl, or other complex portions of the block device and instead >> focus on just the core device access functionality. >> >> In a sample system, imagine a block device driver called "nvflash". This >> device driver has two independent flash chips per instance, each of which >> is block oriented using 512 byte blocks, and can have a separate filesystem >> on it. The plumbing might look like this: >> >> >> +----------+ >> | nvflash | >> | driver | >> | +----------+ +----------------+ +--------------+ >> +----+ blk2scsa |----> | (emulated bus) | -+---> | sd, target 0 | >> +----------+ +----------------+ | +--------------+ >> | >> | +--------------+ >> +---> | sd, target 1 | >> +--------------+ >> >> In the diagram above, the flash chips would be addressable as >> /dev/{rdsk,dsk}/cXt0d0 and /dev/{rdsk,dsk}/cXt1d0. >> >> Note that the actual flash chips could be removable (perhaps as if they >> were slots on a physical media reader), and the sd driver would handle >> them properly. This would include automatic volume manager support >> by userland components, so that when a device is inserted it is >> automatically >> mounted and presented in a desktop GNOME session, for example. >> >> The emulated HBA will support auto-sense-request (cannot be disabled), >> and emulated targets will support the removable and hotpluggable properties >> if they were registered with them. >> >> >> CHAPTER 3: Programming Interface >> ================================= >> >> The following API is provided for target devices. >> >> Basic setup >> ----------- >> >> The device driver shall #include >> >> The device driver shall add -N misc/blk2scsa to its link line, so >> that the run-time kernel loader can resolve the sybmols >> appropriately. >> >> >> Types >> ----- >> >> typedef struct b2s_nexus b2s_nexus_t; >> >> The b2s_nexus_t structure is an opaque structure that is used as a handle >> to the emulated host bus adapter. >> >> typedef struct b2s_leaf b2s_leaf_t; >> >> The b2s_leaf_t structure is an opaque structure that is used as a handle >> to the emulated disk device. >> >> typedef struct b2s_nexus_info b2s_nexus_info_t; >> >> The b2s_nexus_info structure describes the nexus device that should be >> allocated. It has the following members: >> >> int nexus_version; >> dev_info_t *nexus_dip; >> void *nexus_private; >> ddi_dma_attr_t *nexus_dma_attr; >> boolean_t (*nexus_request)(void *, struct b2s_request *); >> >> The nexus_version field is used for versioning, and represents the version >> of the API that the device driver is coded for. It must be B2S_VERSION_0 >> in this specification. >> >> The nexus_dip is the device node associated with the driver. >> >> The nexus_private field is available for the device driver's own >> use, and should point to nexus state. >> >> The nexus_dma_attr is the DMA attributes describing the DMA >> capabilities of >> the driver. It may be NULL if the driver is incapable of DMA. >> >> The nexus_request field is the entry point that the device driver >> implements >> to handle I/O requests. It is passed nexus_private as its first argument. >> The second argument describes the request in further detail. If the >> driver >> handles the request (or queues it for handling), then it must return >> B_TRUE. If the driver is unwilling to accept the request, but a future >> attempt might be successful, then it should return B_FALSE. Please see >> the description for b2s_request_t below. >> >> typedef b2s_leaf_info b2s_leaf_info_t; >> >> The b2s_leaf_info structure describes a leaf device (emulated SCSI >> disk) that should be attached to the system. It has the following >> members: >> >> uint_t leaf_target; >> uint_t leaf_lun; >> uint32_t leaf_flags; >> const char *leaf_unique_id; >> >> uint32_t target_flags; >> boolean_t (*target_request)(void *, struct b2s_request *); >> >> The leaf_target and leaf_lun fields are target and lun numbers to >> use for the emulated SCSI target. (For example, the disk device node >> /dev/dsk/cXtYdZs2, the leaf_target is represented by Y, and the leaf_lun >> is represented by Z.) The combination of these two fields must be unique >> for a given leaf node. >> >> The leaf_unique_id field is an ASCIIZ string containing a string that >> uniquely identifies the device. The system uses this to protect against >> incorrect hotplug operations. (I.e. insertion of a different leaf target >> at the specified SCSI address, while the previous leaf was still open >> by another consumer.) It may be used in the formulation of device >> identifiers and GUIDs as well. >> >> The leaf_flags field can contain one of two flags: >> >> B2S_LEAF_REMOVABLE - indicates that the leaf supports removable >> media >> >> B2S_LEAF_HOTPLUGGABLE - indicates that the leaf can be hot >> plugged (including either removal or attachment.) >> >> typedef struct b2s_request b2s_request_t; >> >> This structure is the fundamental handle used for tracking I/O requests >> between the SCSA layer and the device driver. It has the following >> accessible members: >> >> int br_cmd; >> uint64_t br_lba; >> uint64_t br_nblks; >> b2s_media_t br_media; >> b2s_inquiry_t br_inquiry; >> uint32_t br_flags; >> >> The br_cmd field is the command code for the operation. See Commands >> below for a full explanation. This field is supplied by the blk2scsa. >> >> The br_lba field is the logical block address associated with the request. >> It will be supplied by the blk2scsa framework. It is only valid when the >> br_cmd field is B2S_CMD_READ or B2S_CMD_WRITE. >> >> The br_nblks is the number of logical blocks for the request. It will be >> supplied by the blk2scsa framework. It is only valid when the br_cmd >> field >> is B2S_CMD_READ or B2S_CMD_WRITE. >> >> The br_media field is a description of the media for the target. It is >> filled out by the driver in response to a B2S_CMD_GETMEDIA request. >> See the description of b2s_media_t below. >> >> >> The br_inquiry field contains inquiry data for the target, to be filled >> out by the device driver in response to a B2S_CMD_INQUIRY request. >> See the description of b2s_inquiry_t below. >> >> The br_flags field is a bitfield of flags associated the request. The >> public flags, which are read-only supplied by the framework, are >> >> B2S_REQUEST_FLAG_POLL - indicates that a synchronous request without >> use of interrupts should be performed. (Such as when sync()'ing >> filesystems or performing a crash dump in response to a panic.) >> >> B2S_REQUEST_FLAG_HEAD - indicates that the request should be placed at >> the head of any queue, if possible. >> >> B2S_REQUEST_FLAG_LOAD_EJECT - only valid with the B2S_CMD_STOP or >> B2S_CMD_START commands, it indicates that the media should either be >> loaded (B2S_CMD_START) or ejected (B2S_CMD_STOP) if possible. >> >> B2S_REQUEST_FLAG_IMMED - if present, indicates that the driver should >> not wait for the operation to complete on the device before returning >> status with b2s_request_done(). It is only valid with the commands >> B2S_CMD_FORMAT, B2S_CMD_START, and B2S_CMD_STOP commands. >> >> typedef struct b2s_media b2s_media_t; >> >> This structure is used in response to B2S_CMD_GETMEDIA. The device driver >> shall supply information about the media in the following fields: >> >> uint64_t media_blksz; >> uint64_t media_nblks; >> uint64_t media_flags; >> >> The media_blksz and media_nblks fields are used to report the size and >> total >> number of logical blocks on the device. >> >> The media_flags bit field can have the flag B2S_MEDIA_FLAG_READ_ONLY >> set to >> indicate that the media loaded in the target is not writable. >> >> typedef struct b2s_inquiry b2s_inquiry_t; >> >> This structure is used in rsponse to B2S_CMD_INQUIRY. The device driver >> shall set the following fields for data to include in a standard SCSI >> inquiry: >> >> const char *inq_vendor; >> const char *inq_product; >> const char *inq_revision; >> const char *inq_serial; >> >> The inq_vendor, inq_product, inq_revision, and inq_serial >> fields are ASCIIZ strings used to identify the device. Note that this >> is for the target, and not for any removable media that may be present >> in the target. These strings are used to formulate the response to >> SCSI inquiries, so if the device driver is able to, it should use >> values that are suitable for SCSI-2. (See ANSI X3.131-1994 for more >> information.) Note that the driver need not pad these strings with >> spaces. >> >> >> Functions >> --------- >> >> int b2s_mod_init(struct modlinkage *); >> int b2s_mod_fini(struct modlinkage *); >> >> These routines are called at _init and _fini respectively, to set up >> and clean up HBA related entries in the device driver's dev_ops field. >> As a consquence, a blk2scsa dependent driver need not supply any cb_ops >> or bus_ops structure on its own behalf. >> >> b2s_nexus_t *b2s_alloc_nexus(b2s_nexus_info_t *); >> >> This allocates an initial emulated HBA structure, using the supplied >> information. >> >> void b2s_free_nexus(b2s_nexus_t *); >> >> This frees an unattached emulated HBA structure. >> >> b2s_leaf_t *b2s_attach_leaf(b2s_nexus_t *, b2s_leaf_info_t *); >> >> This indicates that a leaf (disk) device has been physically >> attached to the nexus (HBA). Appropriate hotplug actions will be >> performed to make the device accessible, if possible. It returns >> an opaque handle to the leaf on success, or NULL on failure. >> >> void b2s_detach_leaf(b2s_leaf_t *leaf); >> >> This indicates that a leaf device has been physically detached from >> the nexus, and exists solely to support hotplug operation. >> >> void b2s_request_mapin(b2s_request_t *req, caddr_t *addrp, size_t *lenp); >> >> This ensures that the buffer associated with the request is mapped into >> kernel address space, and returns the address and length of the buffer >> associated with the request. >> >> void b2s_request_dma(b2s_request_t *req, uint_t *num, ddi_dma_cookie_t **c); >> >> This returns the number of DMA cookies associated with the request, and >> a pointer to an array of the actual cookies. Note that requests are >> pre-mapped by the framework if a suitable DMA attribute was supplied at >> registration time. Note also that the buffer will always be fully mapped. >> That is, it will never be necessary for a driver to use ddi_dma_getwin(). >> >> void b2s_request_done(b2s_request_t *req, int errno, size_t resid); >> >> This is called by the driver when it has completed processing for a >> request. >> The errno takes an error code (see Error Codes below), and the resid >> indicates the number of residual bytes that were not transferred. >> >> int b2s_attach_nexus(b2s_nexus_t *); >> >> This attaches the HBA (and any registered leaves) to the system. The >> target driver should call this as part of its attach(9e) processing. It >> return DDI_SUCCESS on success, DDI_FAILURE otherwise. >> >> int b2s_detach_nexus(b2s_nexus_t *); >> >> This detaches the HBA from the system. It returns DDI_SUCCESS on success, >> DDI_FAILURE otherwise. >> >> >> Commands >> -------- >> >> B2S_CMD_INQUIRY >> >> This command is sent to the driver to retrieve a description of the >> device in response to a SCSI inquiry. The driver shall provide the >> details >> in the br_inquiry field of the associated request. >> >> B2S_CMD_GETMEDIA >> >> This command is sent to the driver to retrieve a description of the >> media currently loaded. The driver shall provide the details in the >> br_media field of the associated request. >> >> B2S_CMD_START >> >> This command is used to initialize the device for use. If the >> B2S_REQUEST_FLAG_LOAD_EJECT is also present, then the device shall >> load any removable media, if possible. >> >> B2S_CMD_STOP >> >> This command is used to cease use of the device. (At this point the >> device may be powered down.) If the B2S_REQUEST_FLAG_LOAD_EJECT is >> present, then the device should attempt to eject any removable media. >> This command also implictly includes the effects of B2S_CMD_SYNC. >> >> B2S_CMD_LOCK >> B2S_CMD_UNLOCK >> >> These commands are used to engage or release any locking mechanism >> preventing removal of the media. >> >> B2S_CMD_READ >> B2S_CMD_WRITE >> >> These commands read or write blocks to/from the device. The block address >> to start at is indicated by the br_lba field of the request. The number >> of blocks to transfer is indicated by the br_nblks field. The actual >> data region can be determined using either the b2s_request_mapin() or >> b2s_request_dma() functions (depending on whether or not DMA is to be >> used.) >> >> B2S_CMD_FORMAT >> >> This command formats the media. It shall not be possible to format media >> while a reservation set with B2S_CMD_RESERVE is in effect. No defect >> list is supplied, so the driver is responsible to take whatever action >> it deems appropriate. If the B2S_REQUEST_FLAG_IMMED is set, then the >> device should not wait for the format to complete before calling >> b2s_request_done(). >> >> B2S_CMD_SYNC >> >> This command flushes any cached write data from the device to media. >> >> >> Errors >> ------ >> >> The following error codes can be returned in response to a request using >> b2s_request_done(). >> >> B2S_EOK >> >> No error. The operation completed successfully. >> >> B2S_ENOTSUP >> >> The device does not support the requested operation. (This should be >> returned, if the device does not have a door lock, for example.) >> >> B2S_EFORMATTING >> >> An attempt to access the device while it was formatting was made. >> >> B2S_ENOMEDIA >> >> No media is present in a target with removable media. >> >> B2S_EMEDIACHG >> >> The media may have changed since the last request was made. This is >> used to prevent accidental overwrites to changed media. >> >> B2S_ESTOPPED >> >> The target has not been started with B2S_CMD_START yet. >> >> B2S_EHARDWARE >> >> An unknown hardware error occurred. >> >> B2S_ENODEV >> >> The target is not present or has been removed. >> >> B2S_EMEDIA >> >> An error on the medium occurred. >> >> B2S_EDOORLOCK >> >> The B2S_CMD_STOP failed to eject the media, because the doorlock was >> engaged. >> >> B2S_EWPROTECT >> >> The media could not be written to because it is not writable. >> >> B2S_EBLKADDR >> >> The supplied LBA block address was invalid. >> >> B2S_ESTARTING >> >> The target is still starting up. Try agin later. >> >> B2S_EIO >> >> Generic failure. >> >> B2S_ERSVD >> >> Target reserved. (Internal use only.) >> >> B2S_EPARM >> >> Bad parameter occurred in the SCSI packet. (Internal use only.) >> >> B2S_EBADMSG >> >> Invalid SCSI message presented to driver. (Internal use only.) >> >> B2S_EINVAL >> >> An invalid parameter was present in the SCSI packet. (Internal use only.) >> >> >> CHAPER 4: Interface Table >> ========================== >> >> Imported Interface Level Comments >> >> SCSI-2 Committed ANSI X1.131-1994 >> scsi_hba_tran Committed SCSI HBA API >> scsi_pkt2bp() Consolidation Private >> >> >> Exported Interface Level Comments >> >> sys/scsi/adapters/blk2scsa.h Cons. Private blk2scsa header >> >> misc/blk2scsa Consolidation Private kernel module >> B2S_CMD_* Consolidation Private request command codes >> B2S_E* Consolidation Private request error codes >> B2S_REQUEST_FLAG_* Consolidation Private request flags >> B2S_VERSION_0 Consolidation Private API versioning >> >> struct b2s_request Consolidation Private request structure >> struct b2s_leaf Consolidation Private leaf (disk) structure (opaque) >> struct b2s_nexus Consolidation Private nexus (hba) structure >> (opaque) >> struct b2s_leaf_info Consolidation Private leaf (disk) attach >> information >> struct b2s_nexus_info Consolidation Private nexus (hba) registration >> struct b2s_media Consolidation Private media description >> struct b2s_inquiry Consolidation Private SCSI inquiry data >> >> b2s_alloc_nexus() Consolidation Private nexus (hba) allocation >> b2s_free_nexus() Consolidation Private nexus (hba) deallocation >> b2s_attach_nexus() Consolidation Private nexus (hba) attachment >> b2s_detach_nexus() Consolidation Private nexus (hba) detachment >> >> b2s_attach_leaf() Consolidation Private leaf (disk) connection >> b2s_detach_leaf() Consolidation Private leaf (disk) disconnection >> >> b2s_request_mapin() Consolidation Private request buffer PIO access >> b2s_request_dma() Consolidation Private request buffer DMA access >> b2s_request_done() Consolidation Private request buffer completion >> >> b2s_mod_init() Consolidation Private modlinkage initialization >> b2s_mod_fini() Condolidation Private modlinkage de-initialization >> From Seth.Goldberg@sun.com Tue Nov 27 23:30:28 2007 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 lAS7URlp010805 for ; Tue, 27 Nov 2007 23:30:28 -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 lAS7UHvM021150 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 07:30:26 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 <0JS700F07GUO7700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 23:30:24 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS700M6TGUNUT90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 23:30:23 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAS7UN0e005296 for ; Tue, 27 Nov 2007 23:30:23 -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 <0JS700301GRJOZ00@fe-sfbay-09.sun.com> (original mail from Seth.Goldberg@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 23:30:23 -0800 (PST) Received: from kasha ([10.1.48.74]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS7007LKGUMGI70@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 23:30:23 -0800 (PST) Date: Tue, 27 Nov 2007 23:30:05 -0800 (PST) From: Seth Goldberg Subject: Re: PSARC 2007/654 blk2scsa spec change In-reply-to: <474CF161.9070204@sun.com> Sender: Seth.Goldberg@sun.com X-X-Sender: sethg@bergsoft.west.sun.com. To: "Garrett D'Amore" Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474BDA41.5060301@sun.com> <474CDE17.3020009@sun.com> <474CF161.9070204@sun.com> Status: RO Content-Length: 465 Doesn't mkfs -F pcfs work for your driver? if not, just dd the raw blocks off the device first. --S Quoting Garrett D'Amore, who wrote the following on Tue, 27 Nov 2007: > Artem Kachitchkine wrote: >> >> Any update on that pesky ZFS? >> >> -Artem > Not yet. I have been loathe to clobber my PCFS partition on my SD card > during testing (because then I have no way to easily recreate it), but I > think I'll try it out tomorrow. > > -- Garrett > > From gdamore@sun.com Wed Nov 28 08:35:40 2007 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 lASGZd0G021603 for ; Wed, 28 Nov 2007 08:35:40 -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 lASGZdw9046513 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 09:35:39 -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 <0JS800H0563FE300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:35:39 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS8001P363D3IA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:35:37 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lASGZbEO026660 for ; Wed, 28 Nov 2007 08:35:37 -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 <0JS800A0160SF000@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 08:35:37 -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 <0JS800JTS635YN50@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 08:35:29 -0800 (PST) Date: Wed, 28 Nov 2007 08:30:32 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/654 blk2scsa spec change In-reply-to: Sender: Garrett.Damore@sun.com To: Seth Goldberg Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <474D97A8.7000207@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: <474BDA41.5060301@sun.com> <474CDE17.3020009@sun.com> <474CF161.9070204@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 742 Seth Goldberg wrote: > > Doesn't mkfs -F pcfs work for your driver? if not, just dd the raw > blocks off the device first. It should work. I've not tried. (The devices I've been working with have already been formatted.) Once mkfs is run, if it doesn't work for some reason though, I'm probably dead. As I said, I'll try it out today. -- Garrett > > --S > > Quoting Garrett D'Amore, who wrote the following on Tue, 27 Nov 2007: > >> Artem Kachitchkine wrote: >>> >>> Any update on that pesky ZFS? >>> >>> -Artem >> Not yet. I have been loathe to clobber my PCFS partition on my SD >> card during testing (because then I have no way to easily recreate >> it), but I think I'll try it out tomorrow. >> >> -- Garrett >> >> From gdamore@sun.com Wed Dec 5 08:08:30 2007 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 lB5G8UpE002790 for ; Wed, 5 Dec 2007 08:08:30 -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 lB5G8TBf012172 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Dec 2007 08:08:29 -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 <0JSL00L093I35X00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Dec 2007 08:08:27 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00IJ83I2RM40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Dec 2007 08:08:26 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5G8QWk000365 for ; Wed, 05 Dec 2007 08:08:26 -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 <0JSL00I013GEVA00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Dec 2007 08:08:26 -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 <0JSL00KGC3I1YX80@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Dec 2007 08:08:25 -0800 (PST) Date: Wed, 05 Dec 2007 08:03:12 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/654 blk2scsa Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <4756CBC0.9070609@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 User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 335 Just a quick question on blk2scsa.... at the last meeting the members asked for more time (don't know which members they were, as I arrived a couple of minutes late). What I don't know is whether enough time has passed yet or not. Do any of the members still want more time on this, or can I close it approved? -- Garrett From Artem.Kachitchkin@sun.com Wed Dec 5 11:30:44 2007 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 lB5JUi6w011130 for ; Wed, 5 Dec 2007 11:30:44 -0800 (PST) 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 lB5JUclV025397 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Dec 2007 12:30:44 -0700 (MST) 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 <0JSL0054LCV6ZL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 05 Dec 2007 11:30:42 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00I6CCV4UE40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 05 Dec 2007 11:30:40 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5JUeAV029586 for ; Wed, 05 Dec 2007 11:30:40 -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 <0JSL00M01CCAHG00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 05 Dec 2007 11:30:40 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL00JX5CUS8I60@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 05 Dec 2007 11:30:29 -0800 (PST) Date: Wed, 05 Dec 2007 11:29:52 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2007/654 blk2scsa In-reply-to: <4756CBC0.9070609@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: psarc-ext@sun.com Message-id: <4756FC30.2060606@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: <4756CBC0.9070609@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 421 Garrett D'Amore wrote: > Just a quick question on blk2scsa.... at the last meeting the members > asked for more time (don't know which members they were, as I arrived a > couple of minutes late). What I don't know is whether enough time has > passed yet or not. Do any of the members still want more time on this, > or can I close it approved? I hate to be a nag, but... you know what I'm going to ask :) -Artem From gdamore@sun.com Wed Dec 5 21:57:55 2007 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 lB65vsue024217 for ; Wed, 5 Dec 2007 21:57: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 lB65vp24023782 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 13:57: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 <0JSM000095WHI700@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 05 Dec 2007 22:57:53 -0700 (MST) 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 <0JSM000PK5WGGCD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 05 Dec 2007 22:57:53 -0700 (MST) 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 lB65vqoj026532 for ; Wed, 05 Dec 2007 21:57:52 -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 <0JSM004015NHJT00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 05 Dec 2007 21:57:52 -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 <0JSM00NJZ5WG3W20@fe-sfbay-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 05 Dec 2007 21:57:52 -0800 (PST) Date: Wed, 05 Dec 2007 21:52:37 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/654 blk2scsa In-reply-to: <4756FC30.2060606@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: psarc-ext@sun.com Message-id: <47578E25.4030007@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: <4756CBC0.9070609@sun.com> <4756FC30.2060606@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 764 Artem Kachitchkine wrote: > Garrett D'Amore wrote: >> Just a quick question on blk2scsa.... at the last meeting the members >> asked for more time (don't know which members they were, as I arrived >> a couple of minutes late). What I don't know is whether enough time >> has passed yet or not. Do any of the members still want more time on >> this, or can I close it approved? > > I hate to be a nag, but... you know what I'm going to ask :) > > -Artem I just tested it. It works. As expected. Yay. I haven't tested hotplug interaction yet, but then I'm still debugging event delivery with hotplug, so give me a little bit on that one, okay? (And in case anyone else didn't figure it out, we're talking about using ZFS on SDcard.) -- Garrett From Garrett.Damore@sun.com Wed Dec 12 10:22:51 2007 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 lBCIMolQ009749 for ; Wed, 12 Dec 2007 10:22:50 -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 lBCIMn2Q022592 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Dec 2007 18:22:49 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 <0JSY00F1F8E0IQ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 12 Dec 2007 10:22:48 -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 <0JSY009KM8DZTV30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 12 Dec 2007 10:22:47 -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 lBCIMlkB010404 for ; Wed, 12 Dec 2007 10:22:47 -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 <0JSY00F018DIOA00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 12 Dec 2007 10:22:47 -0800 (PST) Received: from [129.153.2.14] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSY0081H8DYMI30@fe-sfbay-09.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 12 Dec 2007 10:22:47 -0800 (PST) Date: Wed, 12 Dec 2007 10:22:46 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/654 blk2scsa In-reply-to: <47578E25.4030007@sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" Cc: Artem Kachitchkine , psarc-ext@sun.com Message-id: <476026F6.4060801@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: <4756CBC0.9070609@sun.com> <4756FC30.2060606@sun.com> <47578E25.4030007@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 65 FYI, this case was approved at today's meeting. -- Garrett