Thanks for the advice, Garrett and Cyril. I'll definitely look into blk2scsa integration a bit more. At this point, I think the shortest path is to hook into blk2scsa and then serialize the b2s_requests and push them through one of these new kernel sockets I've been reading about. I'd lose the ability to have FUSE serialize and deserialize the requests for me, but I'd gain the ability to write my user-space implementation in pretty much any language I want, without having to worry about a FUSE binding.
Thanks again for the tips, I'm sure I'll be back with more questions once I look into the details of sda_mem. Russ On Tue, Sep 1, 2009 at 3:28 PM, Garrett D'Amore <[email protected]> wrote: > Russ Weeks wrote: > > On Tue, Sep 1, 2009 at 12:02 PM, Garrett D'Amore <[email protected]<mailto: >> [email protected]>> wrote: >> >> Russ Weeks wrote: >> >> Hi, All. >> >> I'm interested in building a minimal block device driver in >> userspace. My plan is to extend the work in the OpenSolaris >> FUSE project - not the filesystem-specific parts, but the >> kernel<->user message passing parts. I'd like some help to >> identify the minimal set of entry points that I need to >> forward to user space. So far, I've identified these >> operations: open.9e, close.9e, prop_op.9e, strategy.9e and >> ioctl.9e. >> >> I understand that forwarding a call to ioctl.9e might be a >> little tricky due to the nature of the arguments. I hope to >> only support the minimal set of control ops defined in dkio.7i. >> >> >> Good plan. Even better, come up with your own design for passing >> the messages you need to userland, rather than ioctls themselves. >> >> >> Is that an option? I thought I'd have to write at least a basic ioctl >> implementation to get disk geometry and get/set the vtoc. But yeah, I >> figure all of my device-specific configuration can be done entirely in >> userland. >> >> I'd highly recommend seeing if you can use my blk2scsa instead of >> doing this. >> >> Using this framework, you can probably pretty simply implement a >> storage device that is backed in userland, without worry about >> most of the other entry points (strategy, ioctl, etc.) >> >> Best of all, it will appear to the system like an emulated SCSI >> device on its own SCSI bus. (So you can use "sd", and get >> automatic integration with the various userland bits that know >> specific details about sd.) It can even support hotplug (so if >> your userland process exits, it can be emulated as a SCSI device >> detaching :-) >> >> The blk2scsa header is in >> usr/src/uts/common/sys/scsi/adapters/blk2scsa.h. A sample driver >> that uses it is the sdcard stack, but that probably isn't the >> easiest example to follow. >> >> >> That's two votes for blk2scsa - Cyril recommended it to me in a previous >> post. I definitely like the idea of getting much/most of the SCSI command >> set for free. Can you explain the licensing differences between a bundled >> vs. unbundled driver? I'm not too worried about not being able to deploy to >> S10. At the moment I just want to get a prototype up and running, but I'm >> sure my bosses would like to keep their options open, licensing-wise. >> > > To be bundled, you have to agree to give Sun joint ownership in your code. > (You still retain your own ownership.) It makes it hard if you want the > code to be closed, or you want to sell it directly. On the other hand, > being bundled brings its own benefits. > > Its possible that we can arrange for blk2scsa to be part of an exported DDI > for you, so you don't have to make this choice. > > >> I think I get the gist of blk2scsa, instead of providing references to >> entry points in cb_ops it looks like I provide a command processor in the >> nexus info... I have some questions about the other fields in >> b2s_nexus_info; if you could point me to the sdcard driver I might be able >> to clear them up for myself. >> > > usr/src/uts/common/io/sdcard/impl/sda_mem.c is what you want. Its a bit > convoluted, since the driver actually interfaces with blk2scsa *and* with > the SDcard framework. > > - Garrett > >> >> Thanks, >> >> Russ >> >> Let me know if you want to try this, and I'll see if I can help >> you further. >> >> Note that blk2scsa only exists on Solaris Nevada/OpenSolaris (no >> S10), and is technically Consolidation Private. So if you want to >> have an unbundled driver, technically we'd need to find another >> solution, or come up with an "interface contract" for you to use >> it. But if its just for your own experimentation, then you can >> just use it directly. >> >> - Garrett >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> driver-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/driver-discuss >> >> > >
_______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
