On Tue, Sep 1, 2009 at 9:49 PM, Russ Weeks<[email protected]> 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.
>
Hi Russ,
I once did very similar driver - the kernel layer that offloads all
the actual IO to the userland application.
After some experimentation I left all the entry points implementation
inside the kernel and multiplexed all the IO via ioctl()
I imaging that there are other way to skin the cat - but the userland
application could largely handle only read and write and I was limited
with what I could do with it. OTOH I was absolutely free with kernel
side. The overall result was pretty good - that system is shipped to
production environment for a over five years.
I wouldn't do such thing however if I would have a choice not to.
> 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.
>
> I understand that character devices must support read+write and block
> devices can support the aread+awrite entry points. If these points are not
> defined, are all IO operations routed through the strategy entry point
> instead? (If it's not obvious by this point, I'm a complete noob when it
> comes to kernel development).
>
> I understand that such a block device could never be used for swap, also
> that it would exhibit high latency and low bandwidth relative to a kernel
> implementation. I'm OK with all of this. If anybody can think of any other
> caveats, please let me know.
--
Regards,
Cyril
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
