> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > K - so what? I'm guessing what you want me to see is that these
> > implement multiple channels. Is there a reason that eia001stat couldn't be
> > implemented as
> >
> > f=open("/dev/eia001ctl",O_RDWR);
> > write(f,"stat\n");
> > status=read(f); /* returns "stat foo\n" */
>
> Less convenient.
True enough.
> > We don't want to implement a separate device node for every OOB ioctl that
> > returns data, do we? Why should stat be any different?
>
> For every? Probably not. Forcing all of them together? I bet that in many
> cases it will be damn inconvenient. You are forcing the policy on all
> drivers. For no good reason, AFAICS.
No - I'm merely pointing out that it's sufficient. And I'm pretty sure we
want to make additional control or stream interfaces the exception rather
than the rule. And having a standard read and write protocol of some sort
for ctl devices is more or less mandatory, otherwise they will all work
differently. This is not to say driver writers aren't allowed to depart
from it, just that it'll be more work if they do.
> > /dev/draw is interesting but largely irrelevant. And again, colormap and
> > refresh - why are they not part of ctl? You've got to select on refresh
> > anyway, might as well accept asynchronous messages through ctl.
>
> You've got to do _what_ on refresh?
I'm guessing some sort of poll or select on the refresh device, assuming a
single-threaded app. But no, I've never used 9 nor am I especially
interested in exploring it in depth, given its license and lack of
community.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/