If I had a device driver that, for reasons I won't go into here, needed
to be STREAMS, could I then add a devmap(9E) entry point to additionally
support mmap(2)? (The problem is that for my project, I may have to
support two different semantics -- one which relies on STREAMS, the
other which must support mmap(2).)
My read of the code is that this will work for mmap(2) from userland
applications, but not from kernel layered drivers using ldi_xxx.
However, I suspect that this would represent "weird" functionality --
quite likely never done before. Am I entirely insane for even
contemplating this?
-- Garrett
(PS: The problem in more detail is that we need STREAMS semantics for
legacy Sun audio, but we also want to support OSS applications such as
Skype, which may require support for an mmap(2)-able audio buffer.
Obviously, I'd prefer to dispense with mmap, but in the event that we
discover we can't live without it, it would be nice if all I had to do
was supply a functional devmap(9E) and possibly segmap(9E) interface.)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
