Programming

As far as I know, it doesn't; and you are in error if you think it does. Here is cdevsw from HP-UX 11.0:

Code:

 
/*
 * Character device switch.
 */
struct cdevsw
{
        d_open_t        d_open;
        d_close_t       d_close;
        d_read_t        d_read;
        d_write_t       d_write;
        d_ioctl_t       d_ioctl;
        d_select_t      d_select;
        d_option1_t     d_option1;
        int             d_flags;       /* C_MGR_IS_MP is valid for this field */
        void            *d_drv_info;
        pfilter_t       *d_pfilter_s;
        aio_ops_t       *d_aio_ops;
};

To use d_read as an example, The type of d_read is:
typedef int (*d_read_t) __((dev_t dev, struct uio *uio));
And that typedef does not magically change into a pointer to a qinit structure if the current entry happens to be a streams based driver. Any time the read or readv system call invokes the read routine of a character driver, that read routine is passed a device and a uio structure. Every read of a character device is treated this way. No there no exception for streams-based character drivers.

The cdevsw for osf1 is similiar but with much less type checking:

Code:

struct cdevsw
{
        int     (*d_open)();
        int     (*d_close)();
        int     (*d_read)();
        int     (*d_write)();
        int     (*d_ioctl)();
        int     (*d_stop)();
        int     (*d_reset)();
        struct tty *d_ttys;
        int     (*d_select)();
        int     (*d_mmap)();
        int     d_funnel;       /* serial code compatibility */
        int     (*d_segmap)();          /* xxx_segmap() entry point */
        int     d_flags;                /* if (C_DDIDKI), driver follows
                                           SVR4 DDI/DKI interfaces*/
};

Without strong typechecking it's hard to prove exactly what d_read is. But that DDI/DKI stands for Device Driver Interface/Driver Kernel Interface. You can be sure that a system that supports that standard is not going to turn d_read into a pointer to a qinit structure.

If you post again claiming that your cdevsw has pointers to qinit (or other stream) structures, please also post some evidence as well. I would also like to know which stream structure you think that your d_ioctl points to.

As originally posted by Perderabo
"No there no exception for streams-based character drivers. "

Following is the cdevsw structure that we are using for developing stream device drivers in Sun and Sco unix Servers.
strcut cdevsw {
int (*d_open)( );
int (*d_close)( );
int (*d_read)( );
int (*d_write)( );
int (*d_ioctl)( );
struct tty *d_ttys ;
strcut streamtab *d_str;
char *d_name ;
};
Streams drivers have some similarites with character device drivers. A Stream driver may include init, start , halt and intr entry points.They must include open and close entry points.In addition, there are entry points that are specific to Streams driver: read and write queue service (xxsrv) read and write queue put functions.The put entry points are required with exception of the read side of a driver.The service entry points are optional.The put and service entry points are associated with each queue, and since each module and driver has two queues, each module and driver may have two put and two service entry points.The put routine is called to place a message on a queue and perform any processing that must be done immediately.The Stream head converts a write system call into a message and invokes the put routine for downstream module's write queue.This routine examines the message, performs any processing and either passes the message downstream or places it on its own queue for later processing.The Stream Device driver on the write side must provide a put entry point that may be called by the upstream module to pass message message down the stream.It may provide a write side service routine.On the read side the interrupt or poll takes the data from device and passes it to the driver's read queue or any module upstream.
.....
.....
int xxopen(),xxclose(),...... ;
static struct qinit rinit = { NULL , NULL , xxopen,xxclose,.......} ;
static struct qinit winit = { xxput, xxsrv,NULL,.......};
strcut streamtab xxinfo = {&rinit,&winit,.......};
The qinit structure contians the info for read and write queues.

I do hope I justify my stand quiet clear and sound now.The read and write queue need to be intialized.But I need a bit more of explanation.As in reference to ioctl , I think the context in which it is called is blockable but in case of streams the ioctls are transparent.That's all I know.

Well, I went looking for Sun's cdevsw. It took me several minutes to figure out why I can't find it. They don't have one. Sun uses a structure called cb_ops instead. (Are you getting your driver to compile on a Sun?? Which version of the OS?) But anyway, they do have full prototypes. The read entry is:
int (*cb_read)(dev_t dev, struct uio *uiop, Cred_t *credp)

However, the cb_ops table does indeed contain a pointer to a streamtab strucrure! I just called a friend of mine who has access to an SCO box. He mailed me his conf.h file and sure enough there is a pointer to a streamtab structure there. Like you, I don't understand what that pointer is for.

Looking at Sun's website, I found this SunOS streams-based pty driver and I can't believe what I see. They are setting cb_read and cb_write to nodev!! I can only guess that the read() system call will notice the "nodev" and the presence of the streamtab pointer and then do what is needed to invoke the read queue directly.

I don't understand this implementation but apparently, if you establish the proper streamtab and qinit structures it's gonna work on a Sun. And maybe that's how SCO works as well.

As originally posted by Perderabo
"No there no exception for streams-based character drivers. "
I guess I'll have to eat those words. It would seem to depend on the specific OS.