On Tue, Sep 1, 2009 at 12:02 PM, Garrett D'Amore <[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. 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. 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
