I hate to say it but the STREAMS programming guide is just a horrible way to
learn how to do this.
The Writing Device Drivers book has far better and more useful examples.
It's much easier to read and understand.
I'm again at an impasse. I tried cat /dev/testdriver and the machine
rebooted.
I'm assuming it's because I have no
A) Open procedure
B) Read procedure.
I'm also assuming that the crash occurs because the device driver framework
expects these procedures to be present, not the STREAMS framework.
The Writing Device Drivers book seems to suggest that these procedures be
declared like this:
foo_open(dev_t *devp, int flag, int otyp, cred_t *cred_p)
foo_read(dev_t dev, struct uio *uio_p, cred_t *cred_p)
But the STREAMS framework expects to see functions like this:
lpopen(
queue_t *q, /* read queue */
dev_t *devp,
int flag,
int sflag,
cred_t *credp)
So which one is correct? Do I need two sets of open/read procedures?
There's an extra parameter to the open and read calls in the STREAMS
programming guide.
I tried to follow along the "pts example" in chapter 11 of the STREAMS
Programming Guide which is also missing read() and open() and instead seem
to favor the queue/based IO method. Fine. But if my assumptions are
correct wouldn't the pts driver crash as well?
So which one is correct? Do I need two sets of open/read procedures?
I'm really trying to do something extremely simple as a learning exercise,
and that is:
1) I want to be able to connect to a stream head like this:
open("/dev/testdriver" O_RDWR);
then write() data to it and be able to read() the same data
Basically a stream loopack device.
I can plainly see how this could be implemented purely with a device driver
and completely skipping the STREAMS part.
But I cannot figure out how to tell my driver to treat the open() like a
stream head.
I guess I just don't understand STREAMS. Maybe I should consider not using
them.
-Daniel
On 9/11/07, Daniel Corbe <[EMAIL PROTECTED]> wrote:
>
> Thanks, that did it! Loads now.
>
> -Daniel
>
>
> On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Daniel Corbe wrote:
> > > Okay, did that and this is what the code looks like now:
> > >
> > > http://rafb.net/p/0Ufk6F18.html
> > >
> > > Same problem trying to use add_drv, as seen from the error:
> > >
> > > devfsadm: driver failed to attach: testdriver
> > > Warning: Driver (testdriver) successfully added to system but failed
> > > to attach
> > >
> > > I'm at a loss here, the documentation seems to agree with what I'm
> > > doing :(
> > Hi Daniel,
> > You can not use nodev for your probe routine. This routine is called
> > and since nodev returns an error,
> > your attach is never called. Change the nodev in your dev_ops for probe
> > to nulldev.
> >
> > max
> >
> >
>
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss